hbase是乙個強一致性資料庫，不是「最終一致性」資料庫，官網給出的介紹：
「strongly consistent reads/writes: hbase is not an 「eventually consistent」 datastore. this makes it very suitable for tasks such as high-speed counter aggregation.」這裡要先提一下分布式系統的cap原理:
定理：任何分布式系統只可同時滿足二點，沒法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分布式系統，而是應該進行取捨。
hbase是cap系統中的cp系統。
對於一致性，可以分為從客戶端和服務端兩個不同的視角。
如果w+r<=n，則是弱一致性。例如對於一主一備非同步複製的關係型資料庫，n=2,w=1,r=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的資料，所以是弱一致性。
對於分布式系統，為了保證高可用性，一般設定n>=3。不同的n,w,r組合，是在可用性和一致性之間取乙個平衡，以適應不同的應用場景。
hbase具有以下特點
聯絡上文提到的一致性特點，可以得出hbase是強一致性系統的結論。
hbase的資料分為兩部分
對於第一部分資料：
資料最終儲存在hdfs上，修改元資料由zk的一致性（通過2pc實現）來保證一致性
對於第二部分資料：
關於原文後半部分的hbase的強一致性和hdfs的多副本
講的主要是
感覺和強一致性關聯不大，此處刪除
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
保證一致性嗎 Kafka的一致性保證
魚和熊掌不可兼得。系統設計需要根據具體的應用場景做出權衡。系統設計者可以通過配置kafka，來得到不同程度的需求滿足。每個kafka主題 topic 都分為多個分割槽 partitions 每個分割槽可以具有多個副本 replica 其中乙個副本是主分割槽 leader 所有讀寫請求都由主分割槽提供...
一致性雜湊
直接貼出一篇介紹的很清楚的博文。關鍵字一致性雜湊 平衡性，單調性，分散性，負載 其實說白了，就是解決把請求分散到不同的機器上運算，怎麼做分散的平均，機器少一台多一台，或者壞掉一台，成很好的自適應和拓展。最簡單的實現分布式演算法，取模嘛，但是它就上述的一些問題，所以不算好的雜湊函式。一致性雜湊演算法，...