redis cluster 介紹

介紹

1. cluster的做用

（1）自動將數據進行分片，每一個master上放一部分數據 
（2）提供內置的高可用支持，部分master不可用時，仍是能夠繼續工做的

2. redis集羣實現方案 

關於redis的集羣化方案 目前有三種 
（1）Twitter開發的twemproxy
（2）豌豆莢開發的codis
（3）redis官方的redis-cluster
簡介：

　　twemproxy架構簡單 就是用proxy對後端redis server進行代理 可是因爲代理層的消耗性能很低 並且一般涉及多個key的操做都是不支持的 並且自己不支持動態擴容和透明的數據遷移 並且也失去維護 Twitter內部已經不使用了
       redis-cluster是三個裏性能最強大的 由於他使用去中心化的思想 使用hash slot方式 將16348個hash slot 覆蓋到全部節點上 對於存儲的每一個key值 使用CRC16(KEY)&16348=slot 獲得他對應的hash slot 並在訪問key時就去找他的hash slot在哪個節點上 而後由當前訪問節點從實際被分配了這個hash slot的節點去取數據 節點之間使用輕量協議通訊 減小帶寬佔用 性能很高 自動實現負載均衡與高可用 自動實現failover  而且支持動態擴展 官方已經玩到能夠1000個節點 實現的複雜度低 總之我的比較喜歡這個架構 由於他的去中心化思想免去了proxy的消耗 是全新的思路
       可是它也有一些不足 例如官方沒有提供圖形化管理工具 運維體驗差 全手工數據遷移 而且本身對本身自己的redis命令支持也不徹底等 可是這些問題 我以爲不能掩蓋他關鍵的新思想所帶來的的優點 隨着官方的推動 這些問題應該都能在必定時間內獲得解決 那麼這時候去中心化思想帶來的高性能就會表現出他巨大的優點 
       codis使用的也是proxy思路 可是作的比較好 是這兩種之間的一箇中間級 並且支持redis命令是最多的 有圖形化GUI管理和監控工具 運維友好

   　redis cluster架構下，每一個redis要放開兩個端口號，好比一個是6379，另一個就是加10000的端口號，好比16379，

16379端口號是用來進行節點間通訊的，也就是cluster bus的東西，集羣總線。cluster bus的通訊，用來進行故障檢測，配置更新，故障轉移受權
cluster bus用了另一種二進制的協議，主要用於節點間進行高效的數據交換，佔用更少的網絡帶寬和處理時間。

3. 持久化的方案

由兩種方式構成 aof & rdb
1). aof就像關係數據庫中的binlog同樣  把每一次寫操做以追加的形式記錄在其中以文件的形式刷到磁盤裏 
而且可使用不一樣的fsync策略     無fsync,每秒fsync,每次寫的時候fsync.
使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由後臺線程進行處理的,主線程會盡力處理客戶端請求)
一旦出現故障，最多丟失1秒的數據.
可是缺點也隨之而來 那就是aof文件的大小會隨着時間線性增加 一段時間以後 就會變得很大 
若是要在一端以AOF的形式來恢復數據 那麼因爲AOF文件的巨大致積 可能會讓進程如同假死同樣 十分的慢
2). rdb則是一種快照機制 
redis工做在內存中 rdb就是每隔一段時間 對內存中的數據作一次快照  保存在rdb文件中 
並且redis的主從同步能夠實現異步 也是因爲rdb的機制 他在作快照時會fork出一個子進程 由子進程來作快照
父進程徹底處理請求 絕不影響 很適合數據的備份 
可是問題是 若是數據量很大的話 rdb它要保存一個完整的數據集 是一個大的工做 若是時間間隔設置的過短 
那麼嚴重影響redis的性能 可是按照常規設置的話 如5分鐘一次 那麼若是宕機或者重啓 就會基於上次作rdb的時間
從而丟失分鐘級的數據

4.Redis Cluster分區

　　 Redis Cluster中有一個16384長度的槽的概念，他們的編號爲0、一、二、3……1638二、16383。這個槽是一個虛擬的槽，並非真正存在的。正常工做的時候，Redis Cluster中的每一個Master節點都會負責一部分的槽，當有某個key被映射到某個Master負責的槽，那麼這個Master負責爲這個key提供服務，至於哪一個Master節點負責哪一個槽，這是能夠由用戶指定的，也能夠在初始化的時候自動生成（redis-trib.rb腳本）。

鍵到slot的基本映射算法以下：　　

　　HASH_SLOT=CRC16(key)mod16384

通常採用三主三從的方式搭建集羣。具體步驟見下篇文章。