redis很好用，提供快取服務。相比memcached多了新資料結構和主從模式增加可用性。不過redis有一點不能滿足一些網際網路公司開發者需求。
redis集群中，想用快取必須得指明redis伺服器位址去要。這就增加了程式的維護複雜度。因為redis伺服器很可能是需要頻繁變動的。
為什麼不能像操作分布式資料庫或者hadoop那樣，增加乙個**節點，讓它去**所有事情。
所以就開發了這個tair。程式只要跟tair中心節點互動就可以。
還開發了配置伺服器。免去了像操作hadoop那樣，每台hadoop一套一模一樣配置檔案。改配置檔案得整個集群都跟著改。
tair使用了google在bigtable裡面的merge-dump模型。底層儲存可以用redis或者google的leveldb。已經開源了。
分布式 key/value 儲存引擎
持久化和非持久化兩種使用方式
tair 作為乙個分布式系統, 是由乙個中心控制節點和一系列的服務節點組成. 我們稱中心控制節點為config server. 服務節點是data server。
config server 負責管理所有的data server, 維護data server的狀態資訊。
data server 對外提供各種資料服務, 並以心跳的形式將自身狀況匯報給config server。
config server是控制點, 而且是單點, 目前採用一主一備的形式來保證其可靠性。
所有的 data server 地位都是等價的。
tair 的分布採用的是一致性雜湊演算法, 對於所有的key, 分到q個桶中, 桶是負載均衡和資料遷移的基本單位.
config server 根據一定的策略把每個桶指派到不同的data server上. 因為資料按照key做hash演算法, 所以可以認為每個桶中的資料基本是平衡的. 保證了桶分布的均衡性, 就保證了資料分布的均衡性.
當有某台data server故障不可用的時候, config server會發現這個情況, config server負責重新計算一張新的桶在data server上的分布表, 將原來由故障機器服務的桶的訪問重新指派到其它的data server中. 這個時候, 可能會發生資料的遷移.
比如原來由data server a負責的桶, 在新錶中需要由 b負責. 而b上並沒有該桶的資料, 那麼就將資料遷移到b上來. 同時config server會發現哪些桶的備份數目減少了, 然後根據負載情況在負載較低的data server上增加這些桶的備份. 當系統增加data server的時候, config server根據負載, 協調data server將他們控制的部分桶遷移到新的data server上. 遷移完成後調整路由.
當然, 系統中可能出現減少了某些data server 同時增加另外的一些data server. 處理原理同上. 每次路由的變更, config server都會將新的配置資訊推給data server. 在客戶端訪問data server的時候, 會傳送客戶端快取的路由表的版本號. 如果data server發現客戶端的版本號過舊, 則會通知客戶端去config server取一次新的路由表. 如果客戶端訪問某台data server 發生了不可達的情況(該 data server可能宕機了), 客戶端會主動去config server取新的路由表.
當遷移發生的時候, 我們舉個例子, 假設data server a 要把 桶 3,4,5 遷移給data server b. 因為遷移完成前, 客戶端的路由表沒有變化, 客戶端對 3, 4, 5 的訪問請求都會路由到a. 現在假設 3還沒遷移, 4 正在遷移中, 5已經遷移完成. 那麼如果是對3的訪問, 則沒什麼特別, 跟以前一樣. 如果是對5的訪問, 則a會把該請求**給b,並且將b的返回結果返回給客戶, 如果是對4的訪問, 在a處理, 同時如果是對4的修改操作, 會記錄修改log.當桶4遷移完成的時候, 還要把log傳送到b, 在b上應用這些log. 最終a b上對於桶4來說, 資料完全一致才是真正的遷移完成. 當然, 如果是因為某data server宕機而引發的遷移, 客戶端會收到一張中間臨時狀態的分配表. 這張表中, 把宕機的data server所負責的桶臨時指派給有其備份data server來處理. 這個時候, 服務是可用的, 但是負載可能不均衡. 當遷移完成之後, 才能重新達到乙個新的負載均衡的狀態.
程式提供了兩種生成分配表的策略, 一種叫做負載均衡優先, 一種叫做位置安全優先: 我們先看負載優先策略. 當採用負載優先策略的時候, config server會盡量的把桶均勻的分布到各個data server上. 所謂盡量是指在不違背下面的原則的條件下盡量負載均衡. 1 每個桶必須有copy_count份資料 2 乙個桶的各份資料不能在同一臺主機上; 位置安全優先原則是說, 在不違背上面兩個原則的條件下, 還要滿足位置安全條件, 然後再考慮負載均衡. 位置資訊的獲取是通過 _pos_mask(參見安裝部署文件中關於配置項的解釋) 計算得到. 一般我們通過控制 _pos_mask 來使得不同的機房具有不同的位置資訊. 那麼在位置安全優先的時候, 必須被滿足的條件要增加一條, 乙個桶的各份資料不能都位於相同的乙個位置(不在同乙個機房). 這裡有乙個問題, 假如只有兩個機房, 機房1中有100臺data server, 機房2中只有1臺data server. 這個時候, 機房2中data server的壓力必然會非常大. 於是這裡產生了乙個控制引數 _build_diff_ratio(參見安裝部署文件). 當機房差異比率大於這個配置值時, config server也不再build新錶. 機房差異比率是如何計出來的呢? 首先找到機器最多的機房, 不妨設使ra, data server數量是sa. 那麼其餘的data server的數量記做sb. 則機房差異比率=|sa – sb|/sa. 因為一般我們線上系統配置的copy_count是3. 在這個情況下, 不妨設只有兩個機房ra和rb, 那麼兩個機房什麼樣的data server數量是均衡的範圍呢? 當差異比率小於 0.5的時候是可以做到各台data server負載都完全均衡的.這裡有一點要注意, 假設ra機房有機器6臺,rb有機器3臺. 那麼差異比率 = 6 – 3 / 6 = 0.5. 這個時候如果進行擴容, 在機房a增加一台data server, 擴容後的差異比率 = 7 – 3 / 7 = 0.57. 也就是說, 只在機器數多的機房增加data server會擴大差異比率. 如果我們的_build_diff_ratio配置值是0.5. 那麼進行這種擴容後, config server會拒絕再繼續build新錶.
分布式系統中的可靠性和一致性是無法同時保證的, 因為我們必須允許網路錯誤的發生.
tair 採用複製技術來提高可靠性, 並且為了提高效率做了一些優化, 事實上在沒有錯誤發生的時候, tair 提供的是一種強一致性. 但是在有data server發生故障的時候, 客戶有可能在一定時間視窗內讀不到最新的資料. 甚至發生最新資料丟失的情況。
tair-分布式k/v結構資料儲存系統：
分布式快取
分布式快取 原則來說跟應用伺服器分布式應該是一樣，但快取是有狀態的。怎麼樣提高命中？1.最原始的演算法 那就是key hash取模，取到伺服器ip。在大量伺服器伸縮行有問題，加入一台伺服器就有可能讓所有的快取都失效。如 key hash 後是100，取10膜是0，取11膜 1，101 取10膜是1，...
分布式快取
網際網路發展的同時，也引領者相關技術的發展與變革，比如集群 高併發 負載均衡 高可用 海量資料的處理 系統安全 分布式快取等各方面的相關技術。簡單談一下分布式快取技術。2 三層架構 1 web層 表現層 主要對使用者資料接收，以及資料處理完成後返回，為客戶端提 用程式的訪問 2 應用層 對業務的處理...
分布式快取
分布式快取 1 什麼是分布式快取？在高併發的環境下，大量的i o處理與cpu的處理速度顯然不在同乙個數量級，從減輕資料庫的壓力和提高系統的響應速度兩個角度來考慮，因而都會在資料庫之前加一層快取。由於單機的記憶體資源和承載能力有限，因而可以採用多台伺服器來用作快取，使得多台快取伺服器形同一台，並且不會...