Cassandra 配置详解，这主要用于防止一个逻
文章目录
- Hints
- Batchlog
- 请求调度属性
- Thrift
- Key 缓存与全局属性
- 计数器缓存
- 性能调优
- CommitLog
- Compaction
- Memtable
- 缓存与索引
- 磁盘设置
- 网络超时设置
- 节点间的设置
- 本地传输（CQL二进制协议）
- 故障检测设置
- 结束
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级别)
结束
内容太多了,累死我了都… …
后续再补充 … …