參考文檔: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中尚未重新執行的請求的丟失。

?

轉載于:https://www.cnblogs.com/dyf6372/p/3536696.html

總結

以上是生活随笔為你收集整理的Cassandra1.2文档学习（12）—— hint机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。