Cassandra 配置详解

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

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

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.

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级别)

结束

内容太多了,累死我了都… …

后续再补充 … …