Cassandra1.2文档学习（12）—— hint机制

参考文档:http://www.datastax.com/documentation/cassandra/1.2/webhelp/index.html#cassandra/dml/dml_about_hh_c.html

　　Hint机制是Cassandra的特性当一致性不要求时保证了写入的高可用性。但临时故障发生如网络问题，Hint机制显著地提升了反应的一致性。通过配置cassandra.yaml文件，你选择是否启用Hint机制。

 

一、Hint机制是如何工作的

　　当一个写入发生，应当被写入的副本节点被感应到发生了故障或者没有响应写入请求，协调者会在本地存储一个hint，放入到system.hints表中。这个hint表明，对于不可用的节点，写入请求需要被重新执行。

　　hint包含了：

　　•发生了故障的副本节点位置

　　•哪一行需要被重新写入

　　•需要被写入的实际数据

　　默认情况下，当副本发生故障后，hint会被存储3个小时。因为如果一个副本节点发生故障的时间大于3个小时，这个节点可能永久性的故障了。这种情况下，在故障发生前，请运行修复去重新复制数据。你可以配置这个时间，通过配置cassandra.yaml文件的max_hint_window_in_ms属性。

　　节点A有节点B的hint，当节点A通过 gossip发现另一个节点B恢复了，节点A将发送hint对应的数据行发送给B。另外，节点A通过gossip每隔十分钟检查被故障检测机制通知的超时hint。一个hint并不计入一致性级别需求是ONE、QUORUM或者是ALL。协调者节点存储挂掉副本节点的hint无论一致性级别除非hint机制没有被启用。如果没有足够的存活的副本去满足一致性级别，一个UnavailableException异常会被抛出。相比于 Dynamo的复制模型，这是一个重要的不同点。

　　例如，在集群中有两个节点A和B，复制因子为1：每一行存储在一个节点上。假设当我们将行K写给节点A时节点A宕机了且一致性级别为one，写入会失败因为读会影响最新的写入当：

　　W-nodes + R > 复制因子

　　W是写阻塞的节点的数目，R是读阻塞的节点的数目。Cassandra不会在节点B写一个hint然后返回写入成功因为Cassandra在任何一致性级别下都读不到数据直到A恢复了然后B把数据转发给A。

 

二、极致的写入可用性

　　对于那些希望Cassandra能够接受写入请求即使所有的副本节点都已经宕机的应用程序来说，如果一致性级别ONE也不能满足的话，Cassandra提供了一致性级别ANY。ANY保证写入是持久的并且可读的当一个合适的副本节点变得可用并且接收到hint。

 

三、性能

　　设计上，hint机制使得Cassandra 能够持续的支持相同数目的读写请求即便集群的工作能力降低。让你的集群的运行最大能力而不考虑故障是一个坏主意。hint机制设计用来最小化集群的额外负担。

　　一个给定副本节点的所有的hint会被存储在一个单一的分区键，因此执行hint是一个简单的顺序读过程，因此对性能影响最低。如果一个副本节点负载过重或者不可用并且故障检测机制还未标注，预期情况下大部分或者所有的想那个节点发出的写入请求会失败直到因为 write_request_timeout_in_ms（默认为10秒）被触发超时，在那段时间内，Cassandra超时的时候会写hint。

　　如果多个节点同时发生的话会在协调者节点上出现内存压力。所以协调者会跟踪有多少个hint正在写，如果这个数目比较大的话它会暂时性拒绝那些不正确的副本节点的写入。

 

四、hint的移除

　　当使用nodetool removenode命令从集群中移除一个节点的时候，Cassandra自动移除不再存在的节点的hint。Cassandra也会移除被删除表的hint。

 

五、每周计划性修复

　　第一眼，可能认为hint机制让你的数据更加安全而不需要运行修复。仅当硬件故障不发生时这是正确的。

　　硬件故障有下列结果：

　　•已经完成的写入的历史数据丢失。没有集群中其他节点关于节点丢失的数据信息。

　　•发生故障的节点协调的hint中尚未重新执行的请求的丢失。