请 搭配 Cassandra的配置参考
参考: Cassandra 3.x官方文档_cassandra.yaml配置文件
本文基于 3.11

cluster_name
集群的名称。 这主要用于防止一个逻辑集群中的计算机加入另一个逻辑集群。

在 Cassandra 集群中,每一台 节点 都需要加入 集群 , 如果名称不一致,则节点将加入不同的集群环境中。如果出现 需要将 集群 A 的节点加入到 集群 B ,除了修改 该配置之外,还需要修改 seed , 并删除 data 下的数据。

initial_token

这个和 num_tokens 不一样,我们在源码上可以看到:

1
2
3
/* initial token in the ring */
public String initial_token;
public int num_tokens = 1;

可以看到, initial_token 是一个字符串的类型,给到的注释也是 环中的token 的值。 默认是: disabled 。 在一个节点只有一个 token 值的架构中使用,其中一个节点在环空间中拥有一个连续的范围。设置该属性来覆盖 num_tokens 。

num_tokens

这定义了在环上随机分配给该节点的令牌数,相对于其他节点,令牌越多,该节点将存储的数据比例就越大。 您可能希望所有节点都具有相同数量的令牌,前提是它们具有相同的硬件功能。 如果未指定此选项,Cassandra将使用默认令牌1来实现旧版兼容性,并将使用如下所述的num_tokens 指定 num_tokens 将在节点的初始启动时覆盖此设置,在后续启动时,即使设置了初始令牌,此设置也将适用。

关于这个 Token 值,可以参考另一篇博客: Cassandra的负载均衡分析

Hints

hinted_handoff_enabled

是否开启当前 Cassandra 服务器的 HINT 操作。

如果开启该功能, Cassandra 服务器将缓存发送给暂时失效的其他 Cassandra 服务器的数据,等待失效的服务器恢复后,再将缓存的数据发送给恢复的服务器。

hinted_handoff_disabled_datacenters

指定不会执行hinted handoffs的数据中心黑名单。想要每个数据中心启用,需要添加到数据中心列表。例如,hinted_handoff_disabled_datacenters:- DC1 - DC2.

max_hint_window_in_ms

为一个未响应的节点生成 hints 的最大时间。超过了这个时间间隔,新 hints 不会再生成,直到节点回来而且响应了。如果节点再次下线,一个新的间隔开始了。该设置可防止一个节点重新上线对于资源的突然请求,而且集群剩下的节点尝试重播大量的 hinted

hinted_handoff_throttle_in_kb

每秒每个传输线程最大的阈值(kb)。此速率按比例减少了集群中节点的数量。

例如,如果集群中有两个节点,每个交付线程将使用最大速率。如果有三个,每个节点将节流最大值的一半,因为两个预计同时传输 hints

max_hints_delivery_threads

传递 hints 的线程数量。在多数据中心部署中,考虑增加这个数量,因为跨数据中心的 handoff 一般都比较慢

hints_flush_period_in_ms

How often hints should be flushed from the internal buffers to disk.

max_hints_file_size_in_mb

单个 Hints 的文件大小

hints_compression

Hints 文件压缩器。目前支持的 压缩器 有: LZ , Snappy , Deflate . 如果我们不指定 一个压缩器, Hints 文件就不会被压缩

Batchlog

batchlog_replay_throttle_in_kb

总的最大阀门。阀门随着集群的节点数量的减少。

请求调度属性

该选项的属性仅应用于Thrift的传输。他们在本地协议使用CQL协议没有影响

request_scheduler

默认: org.apache.cassandra.scheduler.NoScheduler

根据定义好的策略定义一个调度来处理传入的客户端请求。这个调度对于包含多个 keyspaces 的单个集群的客户端请求的节流是有作用的。该参数尤其对于客户端请求很好,而且不会影响节点间通信。

参考值有:

  • org.apache.cassandra.scheduler.NoScheduler: 不发生调度
  • org.apache.cassandra.scheduler.RoundRobinScheduler: 对于每一个节点的一系列的客户端请求,为每一个 request_scheduler_id 使用一个单独的队列

request_scheduler_options

这里配置的是 关于 request_scheduler 的配置信息:

默认: disable

  • throttle_limit: 每个客户端的in-flight数量。请求超过这个限制的会进入到队列中,直到运行中的请求完成。推荐的值是((并发读数量 + 并发写数量) × 2).
  • default_weight: 每个回合中循环处理有多少请求,默认为: 1
  • weights: 设置每个回合中循环处理有多少请求,基于request_scheduler_id.
    1
    2
    3
    weights:
    keyspace1: 2
    keyspace1: 3
    这里的 weights , 我更偏向与理解为 权重比。

Thrift

commit_failure_policy

提交磁盘故障策略,目前的策略有几种:

  • stop: 关闭 Gossip 和 Thrift,实际上使节点死亡,但是仍然可以通过 JMX 进行检查。
  • die: 关闭 Gossip 和 Thrift 并杀死 JVM ,以便可以替换该节点。
  • stop_commit: 停止 commit log , 但是 写 的 收集 继续提供服务
  • ignore: 忽略致命错误并让批次失败

thrift_framed_transport_size_in_mb

给Thrift的帧的大小(最大字段长度)。帧是应用程序插入的行或者行的一部分

thrift_max_message_length_in_mb

Thrift消息的最大长度(MB),包括所有的字段。Thrift开销(每一帧开销1字节)。消息的长度一般和批处理结合起来使用。一帧的长度大于或等于24,容纳了四个插入的批处理,每一个是24字节。要求的消息的长度大于或等于24+24+24+24+4(帧的数量)

Key 缓存与全局属性

key_cache_keys_to_save

(默认: 禁用 – 所有的key都被保存) 注从key缓存中保存的key的数量

key_cache_size_in_mb

一个表的全局缓存设置。它是key缓存在内存中的最大大小。当未设置值时,缓存会被设置成小于可用堆大小的5%,或者100MB。要想禁用它,就设置为0

key_cache_save_period

(默认: 14400 秒 [4 小时]) key保存在缓存中的秒数持续时间。缓存保存在saved_caches_directory。保存的缓存大大提高了冷启动速度,对I/O影响相对较小。

row_cache_class_name

Row cache implementation class name

  • org.apache.cassandra.cache.OHCProvider: 默认方式, 完全堆外内存
  • org.apache.cassandra.cache.SerializingCacheProvider: 部分堆外内存

row_cache_size_in_mb

(默认: 0- 禁用)行缓存在内存中的最大大小。行缓存可以存储超过key_cache_size_in_mb,但是空间密集,因为它包含了整行。仅仅在热点行或者静态行使用行缓存。如果你减少的太小,你可能在启动的时候得不到最热点的key

row_cache_save_period

(默认: 0- 禁用) Row保存在缓存中的秒数持续时间。缓存保存在saved_caches_directory。该设置有row_cache_size_in_mb描述的限制。

计数器缓存

计数器缓存有助于减少计数器锁对于热点计数单元格的竞争。如果RF = 1,计数器缓存命中会导致Cassandra在完全写之前跳过读。RF > 1计数器缓存命中将有助于减少锁的持续时间,帮助热点计算器单元格更新,但是不允许跳过完全读。只有计数器的本地(时钟,计数)元组存储在内存中,而不是整个计数器,所以它相对便宜.。

减小计数器缓存的值的大小,可能导致不能在启动时获取最热点的key。

counter_cache_size_in_mb

当没有指定值时,最小是堆内存的2.5%或者50MB。如果你执行计数器删除而且依赖gc_grace_seconds,你应该禁用计数器缓存。想禁用它,设置成0.

counter_cache_save_period

Cassandra应该存储计数器缓存的时间。缓存被保存在saved_caches_directory

counter_cache_keys_to_save

从计数器缓存保存的key的数量。如果禁用,所有的key都会被保存。

性能调优

CommitLog

commitlog_sync

Cassandra用来承认毫秒级别内的写操作的方法:

  • periodic:
    • commitlog_sync_period_in_ms: 控制commit log多久一次同步到磁盘。周期性同步是立即承认的
  • batch:
    • commitlog_sync_batch_window_in_ms: 控制Cassandra在同步之前等待其它的写操作多久的时间。当使用这种方法,写操作是不会被承认的,直到同步到磁盘

commitlog_segment_size_in_mb

(默认: 32MB) 设置每个独立的 commitlog 文件段的大小。一个 commitlog 段在它的所有数据都被刷新到 SSTables 以后,可能被存档,删除,或者回收。这个数据量可能包括系统中每一个表的 commitlog 段。默认的大小一般适用于大部分的 commitlog 存档,但是如果你想要一个更细的粒度,8 或者16MB也是合理的。

这个属性决定了最大 mutation 的大小,定义为段大小的一半。如果一个mutation的大小超过了最大 mutation 大小, mutation 就会被拒绝。在增加 commitlog 段之前,调查清楚为什么 mutations 会比预期的要大。寻找访问模式和数据模型潜在的问题,因为增加 commitlog 段大小是一个有限制的调整。

commitlog_compression

如果 commit log 是被压缩的,则设置使用压缩器。可选项:LZ4, Snappy或者Deflate。如果compressor选项未设置,则 commit log 是未被压缩写入的。

commitlog_total_space_in_mb

commit logs 使用的总的空间。如果使用的空间超过了这个值,Cassandra转到下一个最近的段,刷新那些最旧的commitlog 段对应的memtables到磁盘中,删除这些log段。这减少了启动时重播的数据量,防止不经常更新的表不定期的保留commitlog段。一个小的commitlog总空间会导致不活跃的表产生更频繁的刷新活动。

Compaction

concurrent_compactors

Memtable

缓存与索引

磁盘设置

网络超时设置

range_request_timeout_in_ms

协调者等待顺序扫描或者索引扫描完成的时间

read_request_timeout_in_ms

协调者等待读操作完成的时间

counter_write_request_timeout_in_ms

协调者等待计数器写完成的时间

cas_contention_timeout_in_ms

协调者继续重试CAS(compare and set)操作的时间

truncate_request_timeout_in_ms

协调者等待清空数据库完成的时间。一个默认很长的时间,可以允许在移除数据之前先做快照。如果 auto_snapshot 是禁用的(不推荐),你可以减小这个时间。

write_request_timeout_in_ms

协调者等待写操作完成的时间

request_timeout_in_ms

其他操作的默认时间

节点间的设置

本地传输(CQL二进制协议)

start_native_transport

禁用或启用本地传输服务器。使用和 rpc_address 相同的地址,但是端口和 rpc_port 不相同

native_transport_port

客户端监听CQL本地传输的端口

native_transport_max_threads

线程处理请求的最大数量。和rpc_max_threads类似:

  • 默认是不同的(128与不限制)

  • 没有相应的native_transport_min_threads

  • 空闲线程在30秒后停止

native_transport_max_frame_size_in_mb

允许帧的最大大小。帧(请求)大于此的会被当成无效而被拒绝。

native_transport_max_concurrent_connections

指定客户端最大并发连接数。默认的值-1,意思是不限制

native_transport_max_concurrent_connections_per_ip

指定每个源IP的客户最大并发连接数。默认的值-1,意思是不限制

故障检测设置

gc_warn_threshold_in_ms

任何GC暂停时间长于此间隔的,都记录在WARN级别。(默认的,Cassandra把任何GC暂停时间长于200ms的,都记录在INFO级别)