『壹』 redis內存滿了怎麼辦
redis內存滿了解決方法：
1，增加內存。
2，使用內存淘汰策略。
3，Redis集群。
重點介紹下2、3：
第二點：
我們知道，redis設置配置文件的maxmemory參數，可以控制其最大可用內存大小（位元組）。
那麼當所需內存，超過maxmemory怎麼辦？
這個時候就該配置文件中的maxmemory-policy出場了。
其默認值是noeviction。
下面我將列出當可用內存不足時，刪除redis鍵具有的淘汰規則。
規則說明：
1、volatile-lru
使用LRU演算法刪除一個鍵（只對設置了生存時間的鍵）
2、allkeys-lru
使用LRU演算法刪除一個鍵
3、volatile-random
隨機刪除一個鍵（只對設置了生存時間的鍵）
4、allkeys-random
隨機刪除一個鍵
5、volatile-ttl
刪除生存時間最近的一個鍵
6、noeviction
不刪除鍵，只返回錯誤
LRU演算法，least RecentlyUsed，最近最少使用演算法。也就是說默認刪除最近最少使用的鍵。
但是一定要注意一點！redis中並不會准確的刪除所有鍵中最近最少使用的鍵，而是隨機抽取3個鍵，刪除這三個鍵中最近最少使用的鍵。
那麼3這個數字也是可以設置的，對應位置是配置文件中的maxmeory-samples.
三、集群怎麼做
Redis僅支持單實例，內存一般最多10~20GB。對於內存動輒100~200GB的系統，就需要通過集群來支持了。
Redis集群有三種方式：客戶端分片、代理分片、RedisCluster(在之後一篇文章詳細說一下。)
1、客戶端分片
通過業務代碼自己實現路由
優勢：可以自己控制分片演算法、性能比代理的好
劣勢：維護成本高、擴容/縮容等運維操作都需要自己研發
2、代理分片
代理程序接收到來自業務程序的數據請求，根據路由規則，將這些請求分發給正確的Redis實例並返回給業務程序。使用類似Twemproxy、Codis等中間件實現。
優勢：運維方便、程序不用關心如何鏈接Redis實例
劣勢：會帶來性能消耗（大概20%）、無法平滑擴容/縮容，需要執行腳本遷移數據，不方便(Codis在Twemproxy基礎上優化並實現了預分片來達到Auto Rebalance)。
3、Redis Cluster
優勢：官方集群解決方案、無中心節點，和客戶端直連，性能較好
劣勢：方案太重、無法平滑擴容/縮容，需要執行相應的腳本，不方便、太新，沒有相應成熟的解決案例
『貳』 redis架構模式（4） Codis
codis是在redis官方集群方案redis-cluster發布之前便已被業界廣泛使用的redis集群解決方案。
codis server ：這是進行了二次開發的 Redis 實例，其中增加了額外的數據結構，支持
數據遷移操作，主要負責處理具體的數據讀寫請求。
codis proxy ：接收客戶端請求，並把請求轉發給 codis server。
Zookeeper 集群 ：保存集群元數據，例如數據位置信息和 codis proxy 信息。
codis dashboard 和 codis fe ：共同組成了集群管理工具。其中，codis dashboard 負
責執行集群管理工作，包括增刪 codis server、codis proxy 和進行數據遷移。
而 codis fe 負責提供dashboard的Web 操作界面，便於我們直接在 Web 界面上進行集群管理
codis proxy本身支持 Redis 的 RESP 交互協議，所以只需和proxy建立連接，就相當於和
整個codis集群建立連接，codis proxy 接收到請求，就會查詢請求數據和 codis server 的
映射關系，並把請求轉發給相應的 codis server 進行處理。當 codis server 處理完請求後，
會把結果返回給codis proxy，proxy 再把數據返回給客戶端。
codis集群共有1024個slot，編號從0-1023，可以自定義或者自動均勻分配到各個server上，
使用 CRC32 演算法計算數據 key 的哈希值然後對1024取模，得到slot編號，然後通過slot
和server的映射關系請求到具體實例。
Slot 和 codis server 的映射關系稱為數據路由表，我們在 codis dashboard 上分配好路由表後，
dashboard 會把路由表發送給 codis proxy，同時，dashboard 也會把路由表保存在
Zookeeper 中。codis-proxy 會把路由表緩存在本地，當它接收到客戶端請求後，直接查詢
本地的路由表進而完成請求的轉發。
跟redis cluster的區別是，codis的把映射關系存在zookeeper和proxy中，redis cluster
是通過各個實例相互通信進而存在各個實例本地，當實例較多時，可能會受到網路狀況
影響而且整個集群的網路資源消耗相較之下也比較大。
codis按照slot粒度進行數據遷移，比如從serverA遷移至serverB，會從A要遷移的slot中
隨機選擇一個數據，發送給B，A得到確認消息後，刪除本地數據。重復這個過程直到
遷移完畢。
遷移方式有兩種，一種是同步遷移，一種是非同步遷移。
同步遷移時，源server是阻塞的，由於遷移過程中需要數據的序列化、網路傳輸、刪除
等等操作，如果是bigkey則會阻塞較長時間。
所以通常採用非同步遷移。非同步遷移模式下，源server發送完遷移數據之後，就可以繼續接受
處理請求，等到目標server返回ack之後，再執行刪除操作，這個過程中，為了防止數據
不一致的情況，被遷移的數據是只讀模式。
對於bigkey的數據，非同步遷移採用拆分指令的方式，對bigkey中的每個元素用一條指令
進行遷移，而不是等待整個數據序列化完畢再遷移，進而避免了需要序列化大量數據而
阻塞的風險，因為整個bigkey的數據是被拆分的，如果遷移期間server宕機，便會破壞
遷移的原子性，所以codis對bigkey的數據設置了一個過期時間，如果原子性遭到破壞，
目標server的數據就會過期後刪除以保證遷移的原子性。可以通過非同步遷移命令
SLOTSMGRTTAGSLOT-ASYNC 的參數numkeys 設置每次遷移的 key 數量，以提升
bigkey非同步遷移的速度。
最後分享一下我的一些架構設計心得，通過redis cluster和codis的slot設計，把原本
數百上千萬的key和實例的映射抽象成slot和實例的映射，大大減少了映射量，進而把
slot和key的映射分擔到各個實例中，這種粒度的抽象，值得借鑒，另外codis與redis cluser
不同的是，codis通過zk作為第三方儲存系統，保存了集群實例、狀態和slot分配等信息，
這樣避免了實例間的大量心跳來同步集群狀態進而減少實例間的網路通信量，對於實現
大規模的集群是有益的設計，網路帶寬可以集中在客戶端請求上面，需要注意的是需要保證
zk的通信帶寬，畢竟集群的信息同步都交給了zk
『叄』 京東面試官：Redis 這些我必問
緩存好處：高性能 + 高並發
資料庫查詢耗費了800ms，其他用戶對同一個數據再次查詢 ，假設該數據在10分鍾以內沒有變化過，並且 10 分鍾之內有 1000 個用戶 都查詢了同一數據，10 分鍾之內，那 1000 每個用戶，每個人查詢這個數據都感覺很慢 800ms
比如 ：某個商品信息，在 一天之內都不會改變，但是這個商品每次查詢一次都要耗費2s，一天之內被瀏覽 100W次
mysql 單機也就 2000qps,緩存單機輕松幾萬幾十萬qps,單機 承載並發量是 mysql 單機的幾十倍。
在中午高峰期，有 100W 個用戶訪問系統 A，每秒有 4000 個請求去查詢資料庫，資料庫承載每秒 4000 個請求會宕機，加上緩存後，可以 3000 個請求走緩存 ，1000 個請求走資料庫。
緩存是走內存的，內存天然可以支撐4w/s的請求，資料庫（基於磁碟）一般建議並發請求不要超過 2000/s
redis 單線程 ，memcached 多線程
redis 是單線程 nio 非同步線程模型
一個線程+一個隊列
redis 基於 reactor 模式開發了網路事件處理器，這個處理器叫做文件事件處理器，file event handler，這個文件事件處理器是單線程的，所以redis 是單線程的模型，採用 io多路復用機制同時監聽多個 socket,根據socket上的事件來選擇對應的事件處理器來處理這個事件。
文件事件處理器包含：多個 socket,io多路復用程序，文件事件分派器，事件處理器（命令請求處理器、命令恢復處理器、連接應答處理器）
文件事件處理器是單線程的，通過 io 多路復用機制監聽多個 socket，實現高性能和線程模型簡單性
被監聽的 socket 准備好執行 accept,read,write,close等操作的時候，會產生對應的文件事件，調用之前關聯好的時間處理器處理
多個 socket並發操作，產生不同的文件事件，i/o多路復用會監聽多個socket，將這些 socket放入一個隊列中排隊。事件分派器從隊列中取出socket給對應事件處理器。
一個socket時間處理完後，事件分派器才能從隊列中拿到下一個socket，給對應事件處理器來處理。
文件事件：
AE_READABLE 對應 socket變得可讀（客戶端對redis執行 write操作）
AE_WRITABLE 對應 socket 變得可寫（客戶端對 redis執行 read操作）
I/O 多路復用可以同時監聽AE_REABLE和 AE_WRITABLE ，如果同時達到則優先處理 AE_REABLE 時間
文件事件處理器：
連接應答處理器 對應 客戶端要連接 redis
命令請求處理器 對應 客戶端寫數據到 redis
命令回復處理器 對應 客戶端從 redis 讀數據
流程：
一秒鍾可以處理幾萬個請求
普通的 set,get kv緩存
類型 map結構，比如一個對象（沒有嵌套對象）緩存到 redis裡面，然後讀寫緩存的時候，可以直接操作hash的欄位（比如把 age 改成 21，其他的不變）
key=150
value = {
}
有序列表 ，元素可以重復
可以通過 list 存儲一些列表型數據結構，類似粉絲列表，文章評論列表。
例如：微信大 V的粉絲，可以以 list 的格式放在 redis 里去緩存
key=某大 V value=[zhangsan,lisi,wangwu]
比如 lrange 可以從某個元素開始讀取多少個元素，可以基於 list 實現分頁查詢功能，基於 redis實現高性能分頁，類似微博下來不斷分頁東西。
可以搞個簡單的消息隊列，從 list頭懟進去（lpush），list尾巴出來 (brpop)
無序集合，自動去重
需要對一些數據快速全局去重，（當然也可以基於 HashSet，但是單機）
基於 set 玩差集、並集、交集的操作。比如：2 個人的粉絲列表整一個交集，看看 2 個人的共同好友是誰？
把 2 個大 V 的粉絲都放在 2 個 set中，對 2 個 set做交集（sinter）
排序的 set，去重但是可以排序，寫進去的時候給一個分數，自動根據分數排序
排行榜：
zadd board score username
例如：
zadd board 85 zhangsan
zadd board 72 wangwu
zadd board 96 lis
zadd board 62 zhaoliu
自動排序為：
96 lisi
85 zhangsan
72 wangwu
62 zhaoliu
獲取排名前 3 的用戶 ： zrevrange board 0 3
96 lisi
85 zhangsan
72 wangwu
查看zhaoliu的排行 ：zrank board zhaoliu 返回 4
內存是寶貴的，磁碟是廉價的
給key設置過期時間後，redis對這批key是定期刪除+惰性刪除
定期刪除：
redis 默認每隔 100ms隨機抽取一些設置了過期時間的 key，檢查其是否過期了，如果過期就刪除。
注意：redis是每隔100ms隨機抽取一些 key來檢查和刪除，而不是遍歷所有的設置過期時間的key（否則CPU 負載會很高，消耗在檢查過期 key 上）
惰性刪除：
獲取某個key的時候， redis 會檢查一下，這個key如果設置了過期時間那麼是否過期，如果過期了則刪除。
如果定期刪除漏掉了許多過期key，然後你也沒及時去查，也沒走惰性刪除，如果大量過期的key堆積在內存里，導致 redis 內存塊耗盡，則走內存淘汰機制。
內存淘汰策略：
LRU 演算法：
緩存架構（多級緩存架構、熱點緩存）
redis 高並發瓶頸在單機，讀寫分離，一般是支撐讀高並發，寫請求少，也就 一秒一兩千，大量請求讀，一秒鍾二十萬次。
一主多從，主負責寫，將數據同步復制到其他 slave節點，從節點負責讀，所有讀的請求全部走從節點。主要是解決讀高並發。、
主從架構->讀寫分離->支撐10W+讀QPS架構
master->slave 復制，是非同步的
核心機制：
master持久化對主從架構的意義：
如果開啟了主從架構，一定要開啟 master node的持久化，不然 master宕機重啟數據是空的，一經復制，slave的數據也丟了
主從復制原理：
第一次啟動或者斷開重連情況：
正常情況下：
master 來一條數據，就非同步給 slave
全年 99.99%的時間，都是出於可用的狀態，那麼就可以稱為高可用性
redis 高可用架構叫故障轉移，failover，也可以叫做主備切換，切換的時間不可用，但是整體高可用。
sentinal node(哨兵)
作用：
quorum = 1 （代表哨兵最低個數可以嘗試故障轉移，選舉執行的哨兵）
master 宕機，只有 S2 存活，因為 quorum =1 可以嘗試故障轉移，但是沒達到 majority =2 （最低允許執行故障轉移的哨兵存活數）的標准，無法執行故障轉移
如果 M1 宕機了，S2,S3 認為 master宕機，選舉一個執行故障轉移，因為 3 個哨兵的 majority = 2，所以可以執行故障轉移
丟數據：
解決方案：
sdown 主觀宕機，哨兵覺得一個 master 宕機（ping 超過了 is-master-down-after-milliseconds毫秒數）
odown 客觀宕機，quorum數量的哨兵都覺得 master宕機
哨兵互相感知通過 redis的 pub/sub系統，每隔 2 秒往同一個 channel里發消息（自己的 host,ip,runid），其他哨兵可以消費這個消息
以及同步交換master的監控信息。
哨兵確保其他slave修改master信息為新選舉的master
當一個 master被認為 odown && marjority哨兵都同意，那麼某個哨兵會執行主備切換，選舉一個slave成為master（考慮 1. 跟master斷開連接的時長 2. slave 優先順序 3.復制 offset 4. runid）
選舉演算法：
quorum 數量哨兵認為odown->選舉一個哨兵切換->獲得 majority哨兵的授權（quorum majority 需要 majority個哨兵授權，quorum >= majority 需要 quorum 哨兵授權）
第一個選舉出來的哨兵切換失敗了，其他哨兵等待 failover-time之後，重新拿confiuration epoch做為新的version 切換，保證拿到最新配置，用於 configuration傳播（通過 pu/sub消息機制，其他哨兵對比 version 新舊更新 master配置）
高並發：主從架構
高容量：Redis集群，支持每秒幾十萬的讀寫並發
高可用：主從+哨兵
持久化的意義在於故障恢復數據備份（到其他伺服器）+故障恢復（遇到災難，機房斷電，電纜被切）
AOF 只有一個，Redis 中的數據是有一定限量的，內存大小是一定的,AOF 是存放寫命令的，當大到一定的時候，AOF 做 rewrite 操作，就會基於當時 redis 內存中的數據，來重新構造一個更小的 AOF 文件，然後將舊的膨脹很大的文件給刪掉，AOF 文件一直會被限制在和Redis內存中一樣的數據。AOF同步間隔比 RDB 小，數據更完整
優點：
缺點：
AOF 存放的指令日誌，數據恢復的時候，需要回放執行所有指令日誌，RDB 就是一份數據文件，直接載入到內存中。
優點：
缺點：
AOF 來保證數據不丟失，RDB 做不同時間的冷備
支持 N 個 Redis master node,每個 master node掛載多個 slave node
多master + 讀寫分離 + 高可用
數據量很少，高並發 -> replication + sentinal 集群
海量數據 + 高並發 + 高可用 -> redis cluster
hash演算法->一致性 hash 演算法-> redis cluster->hash slot演算法
redis cluster :自動對數據進行分片，每個 master 上放一部分數據，提供內置的高可用支持，部分master不可用時，還是可以繼續工作
cluster bus 通過 16379進行通信，故障檢測，配置更新，故障轉移授權，另外一種二進制協議，主要用於節點間進行高效數據交換，佔用更少的網路帶寬和處理時間
key進行hash，然後對節點數量取模，最大問題只有任意一個 master 宕機，大量數據就要根據新的節點數取模，會導致大量緩存失效。
key進行hash，對應圓環上一個點，順時針尋找距離最近的一個點。保證任何一個 master 宕機，只受 master 宕機那台影響，其他節點不受影響，此時會瞬間去查資料庫。
緩存熱點問題：
可能集中在某個 hash區間內的值特別多，那麼會導致大量的數據都湧入同一個 master 內，造成 master的熱點問題，性能出現瓶頸。
解決方法：
給每個 master 都做了均勻分布的虛擬節點，這樣每個區間內大量數據都會均勻的分布到不同節點內，而不是順時針全部湧入到同一個節點中。
redis cluster 有固定 16384 個 hash slot,對每個key計算 CRC16 值，然後對16384取模，可以獲取 key對應的 hash slot
redis cluster 中每個 master 都會持有部分 slot ,當一台 master 宕機時候，會最快速度遷移 hash slot到可用的機器上（只會短暫的訪問不到）
走同一個 hash slot 通過 hash tag實現
集群元數據：包括 hashslot->node之間的映射表關系，master->slave之間的關系，故障的信息
集群元數據集中式存儲（storm），底層基於zookeeper（分布式協調中間件）集群所有元數據的維護。好處：元數據的更新和讀取，時效性好，一旦變更，其他節點立刻可以感知。缺點：所有元數據的更新壓力全部集中在一個地方，可能會導致元數據的存儲有壓力。
goosip: 好處：元數據的更新比較分散，有一定的延時，降低了壓力。缺點：更新有延時，集群的一些操作會滯後。（reshared操作時configuration error）
自己提供服務的埠號+ 10000 ，每隔一段時間就會往另外幾個節點發送ping消息，同時其他幾點接收到ping之後返回pong
故障信息，節點的增加和移除， hash slot 信息
meet:某個節點發送 meet給新加入的節點，讓新節點加入集群中，然後新節點就會開始於其他節點進行通信
ping:每個節點都會頻繁給其他節點發送ping，其中包含自己的狀態還有自己維護的集群元數據，互相通過ping交換元數據
ping:返回ping和meet，包含自己的狀態和其他信息
fail:某個節點判斷另一個節點fail之後，就發送 fail 給其他節點，通知其他節點，指定的節點宕機了
ping 很頻繁，且攜帶元數據，會加重網路負擔
每個節點每秒會執行 10 次 ping，每次選擇 5 個最久沒有通信的其他節點
當如果發現某個節點通信延遲達到了 cluster_node_timeout /2 ，那麼立即發送 ping， 避免數據交換延遲過長，落後時間太長（2 個節點之間 10 分鍾沒有交換數據，整個集群處於嚴重的元數據不一致的情況）。
每次ping，一個是帶上自己的節點信息，還有就是帶上1/10其他節點的信息，發送出去，進行數據交換
至少包含 3 個其他節點信息，最多包含總節點-2 個其他節點的信息
客戶端發送到任意一個redis實例發送命令，每個redis實例接受到命令後，都會計算key對應的hash slot，如果在本地就本地處理，否則返回moved給客戶端，讓客戶端進行重定向 （redis-cli -c）
通過tag指定key對應的slot,同一個 tag 下的 key，都會在一個 hash slot中，比如 set key1:{100} 和 set key2:{100}
本地維護一份hashslot->node的映射表。
JedisCluster 初始化的時候，隨機選擇一個 node，初始化 hashslot->node 映射表，同時為每個節點創建一個JedisPool連接池，每次基於JedisCluster執行操作，首先JedisCluster都會在本地計算key的hashslot，然後再本地映射表中找到對應的節點，如果發現對應的節點返回moved，那麼利用該節點的元數據，更新 hashslot->node映射表（重試超過 5 次報錯）
hash slot正在遷移，那麼會返回ask 重定向給jedis,jedis 接受到ask重定向之後，，會重定向到目標節點去執行
判斷節點宕機：
如果一個節點認為另外一個節點宕機了， 就是pfail,主觀宕機
如果多個節點都認為另外一個節點宕機了，那麼就是fail，客觀宕機（跟哨兵原理一樣）
在cluster-node-timeout內，某個節點一直沒有返回 pong,那麼就被認為是 pfail
如果一個節點認為某個節點pfail了，那麼會在gossip消息中，ping給其他節點，如果超過半數的節點認為pfail了，那麼就會變成fail。
從節點過濾：
對宕機的 mster node ，從其所有的 slave node中，選擇一個切換成 master node
檢查每個 slave node與master node斷開連接的時間，如果超過了cluster-node-timeout * cluster-slave-validity-factor，那麼就沒資格切換成 master（和哨兵一致）
從節點選舉：
每個從節點，根據自己對 master 復制數據的 offset，設置一個選舉時間，offset越大（復制數據越多）的從節點，選舉時間越靠前，所有的 master node 開始投票，給要進行選舉的 slave進行投票，如果大部分 master node(N/2 +1) 都投票給某個從節點，那麼選舉通過，從節點執行主備切換，從節點切換成主節點
總結：和哨兵很像，直接集成了 replication 和 sentinal
方案：
事前：保證 redis 集群高可用性 （主從+哨兵或 redis cluster），避免全盤崩潰
事中：本地 ehcache 緩存 + hystrix 限流（保護資料庫） & 降級，避免 MySQL被打死
事後： redis持久化，快速恢復緩存數據，繼續分流高並發請求
限制組件每秒就 2000 個請求通過限流組件進入資料庫，剩餘的 3000 個請求走降級，返回一些默認 的值，或者友情提示
好處 ：
4000 個請求黑客攻擊請求資料庫里沒有的數據
解決方案：把黑客查資料庫中不存在的數據的值，寫到緩存中，比如： set -999 UNKNOWN
讀的時候，先讀緩存，緩存沒有，就讀資料庫，然後取出數據後放入緩存，同時返回響應
更新的時候，刪除緩存，更新資料庫
為什麼不更新緩存：
更新緩存代價太高（更新 20 次，只讀 1 次），lazy思想，需要的時候再計算，不需要的時候不計算
方案：先刪除緩存，再修改資料庫
方案：寫，讀路由到相同的一個內存隊列（唯一標識，hash，取模）里，更新和讀操作進行串列化（後台線程非同步執行隊列串列化操作），（隊列里只放一個更新查詢操作即可，多餘的過濾掉，內存隊列里沒有該數據更新操作，直接返回 ）有該數據更新操作則輪詢取緩存值，超時取不到緩存值，直接取一次資料庫的舊值
TP 99 意思是99%的請求可以在200ms內返回
注意點：多個商品的更新操作都積壓在一個隊列裡面（太多操作積壓只能增加機器），導致讀請求發生大量的超時，導致大量的讀請求走資料庫
一秒 500 寫操作，每200ms，100 個寫操作，20 個內存隊列，每個隊列積壓 5 個寫操作，一般在20ms完成
方案：分布式鎖 + 時間戳比較
10台機器，5 主 5 從，每個節點QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 進程不超過 10G）總內存 50g，每條數據10kb，10W 條數據1g，200W 條數據 20G，佔用總內存不到50%，目前高峰期 3500 QPS
作者： mousycoder
『肆』 如何實現高可用的 redis 集群
Redis 因具有豐富的數據結構和超高的性能以及簡單的協議，使其能夠很好的作為資料庫的上游緩存層。但在大規模的 Redis 使用過程中，會受限於多個方面：單機內存有限、帶寬壓力、單點問題、不能動態擴容等。
基於以上， Redis 集群方案顯得尤為重要。通常有 3 個途徑：官方 Redis Cluster ；通過 Proxy 分片；客戶端分片 (Smart Client) 。以上三種方案各有利弊。
Redis Cluster( 官方 ) ：雖然正式版發布已經有一年多的時間，但還缺乏最佳實踐；對協議進行了較大修改，導致主流客戶端也並非都已支持，部分支持的客戶端也沒有經過大規模生產環境的驗證；無中心化設計使整個系統高度耦合，導致很難對業務進行無痛的升級。
Proxy ：現在很多主流的 Redis 集群都會使用 Proxy 方式，例如早已開源的 Codis 。這種方案有很多優點，因為支持原聲 redis 協議，所以客戶端不需要升級，對業務比較友好。並且升級相對平滑，可以起多個 Proxy 後，逐個進行升級。但是缺點是，因為會多一次跳轉，平均會有 30% 左右的性能開銷。而且因為原生客戶端是無法一次綁定多個 Proxy ，連接的 Proxy 如果掛了還是需要人工參與。除非類似 Smart Client 一樣封裝原有客戶端，支持重連到其他 Proxy ，但這也就帶來了客戶端分片方式的一些缺點。並且雖然 Proxy 可以使用多個，並且可以動態增加 proxy 增加性能，但是所有客戶端都是共用所有 proxy ，那麼一些異常的服務有可能影響到其他服務。為每個服務獨立搭建 proxy ，也會給部署帶來額外的工作。
而我們選擇了第三種方案，客戶端分片 (Smart Client) 。客戶端分片相比 Proxy 擁有更好的性能，及更低的延遲。當然也有缺點，就是升級需要重啟客戶端，而且我們需要維護多個語言的版本，但我們更愛高性能。
下面我們來介紹一下我們的Redis集群：
概貌：
如圖0所示，
我們的 Redis 集群一共由四個角色組成:
Zookeeper ：保存所有 redis 集群的實例地址， redis 實例按照約定在特定路徑寫入自身地址，客戶端根據這個約定查找 redis 實例地址，進行讀寫。
Redis 實例：我們修改了 redis 源碼，當 redis 啟動或主從切換時，按照約定自動把地址寫到 zookeeper 特定路徑上。
Sentinel ： redis 自帶的主從切換工具，我們通過 sentinel 實現集群高可用。
客戶端（ Smart Client ）：客戶端通過約定查找 redis 實例在 ZooKeeper 中寫入的地址。並且根據集群的 group 數，進行一致性哈希計算，確定 key 唯一落入的 group ，隨後對這個 group 的主庫進行操作。客戶端會在Z ooKeeper 設置監視，當某個 group 的主庫發生變化時，Z ooKeeper 會主動通知客戶端，客戶端會更新對應 group 的最新主庫。
我們的Redis 集群是以業務為單位進行劃分的，不同業務使用不同集群（即業務和集群是一對一關系）。一個 Redis 集群會由多個 group 組成 ( 一個 group 由一個主從對 redis 實例組成 ) 。即 group 越多，可以部署在更多的機器上，可利用的內存、帶寬也會更多。在圖0中，這個業務使用的 redis 集群由 2 個 group 組成，每個 group 由一對主從實例組成。
Failover
如圖1所示，
當 redis 啟動時，會 把自己的 IP:Port 寫入到 ZooKeeper 中。其中的 主實例模式啟動時會在 /redis/ 業務名 / 組名 永久節點寫入自己的 IP:Port （如果節點不存在則創建）。由 主模式 變成 從模式 時，會創建 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節 點，並寫入自己的 IP:Port （如果相同節點已經存在，則先刪除，再創建）。而從實例 模式 啟動時會創建 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節點，並寫入自己的 ip:port （如果相同節點已經存在，則先刪除，再創建）。由 從模式 變成 主模式 時，先刪除 /redis/ 業務名 / 組名 /slaves/ip:port 臨時節點，並在 /redis/ 業務名 / 組名 永久節點寫入自己的 IP:Port 。
ZooKeeper 會一直保存當前有效的 主從實例 IP:Port 信息。至於主從自動切換過程，使用 redis 自帶的 sentinel 實現，現設置為超過 30s 主 server 無響應，則由 sentinel 進行主從實例的切換，切換後就會觸發以主、從實例通過以上提到的一系列動作，從而完成最終的切換。
而客戶端側通過給定業務名下的所有 groupName 進行一致性哈希計算，確定 key 落入哪個組。 客戶端啟動時，會從 ZooKeeper 獲取指定業務名下所有 group 的 主從 IP:Port ，並在 ZooKeeper 中設置監視（監視的作用是當 ZooKeeper 的節點發生變化時，會主動通知客戶端）。若客戶端從 Zookeeper 收到節點變化通知，會重新獲取最新的 主從 I:Port ，並重新設置監視（ ZooKeeper 監視是一次性的）。通過此方法，客戶端可以實時獲知當前可訪問最新的 主從 IP:Port 信息。
因為我們的所有 redis 實例信息都按照約定保存在 ZooKeeper 上，所以不需要針對每個實例部署監控，我們編寫了一個可以自動通過 ZooKeeper 獲取所有 redis 實例信息，並且監控 cpu 、 qps 、內存、主從延遲、主從切換、連接數等的工具。
發展：
現在 redis 集群在某些業務內存需求超過預期很多後，無法通過動態擴容進行擴展。所以我們正在做動態擴容的支持。原先的客戶端我們是通過一致性哈希進行 key 的
路由策略，但這種方式在動態擴容時會略顯復雜，所以我們決定採用實現起來相對簡單的預分片方式。一致性哈希的好處是可以無限擴容，而預分片則不是。預分片
時我們會在初始化階段指定一個集群的所有分片數量，這個數量一旦指定就不能再做改變，這個預分片數量就是後續可以擴容到最大的 redis 實例數。假設預分片 128 個 slot ，每個實例 10G 也可以達到 TB 級別的集群，對於未來數據增長很大的集群我們可以預分片 1024 ，基本可以滿足所有大容量內存需求了。
原先我們的 redis 集群有四種角色， Smart Client, redis ， sentinel ， ZooKeeper 。為了支持動態擴容，我們增加了一個角色， redis_cluster_manager （以下簡稱 manager ），用於管理 redis 集群。主要工作是初始化集群（即預分片），增加實例後負責修改Z ooKeeper 狀態，待客戶端做好准備後遷移數據到新增實例上。為了盡量減少數據遷移期間對現性能帶來的影響，我們每次只會遷移一個分片的數據，待遷移完成，再進行下一個分片的遷移。
如圖2所示
相比原先的方案，多了 slots 、M anager Lock 、 clients 、M igrating Clients 節點。
Slots: 所有分片會把自身信息寫入到 slots 節點下面。 Manager 在初始化集群時，根據設置的分片數，以及集群下的 group 數，進行預分片操作，把所有分片均勻分配給已有 group 。分片的信息由一個 json 串組成，記錄有分片的狀態 (stats) ，當前擁有此分片的 group(src) ，需要遷移到的 group(dst) 。分片的狀態一共有三種： online 、 pre_migrate 、 migrating 。
Online 指這個分片處於正常狀態，這時 dst 是空值，客戶端根據 src 的 group 進行讀寫。
Pre_migrate 是指這個分片被 manager 標記為需要遷移，此時 dst 仍然為空， manager 在等所有 client 都已經准備就緒，因為 ZooKeeper 回掉所有客戶端有時間差，所以如果某些 client 沒有準備就緒的時候 manager 進行了數據遷移，那麼就會有數據丟失。
Migrating 是 manager 確認了所有客戶端都已經做好遷移准備後，在 dst 寫入此分片需要遷移的目標 group 。待遷移完成，會在 src 寫入目標 group_name ， dst 設為空， stats 設為 online 。
Manager Lock： 因為我們是每次只允許遷移一個 slot ，所以不允許超過一個 manager 操作一個集群。所以 manager 在操作集群前，會在M anager Lock 下注冊臨時節點，代表這個集群已經有 manager 在操作了，這樣其他 manager 想要操作這個集群時就會自動退出。
Clients 和M igrating Clients 是為了讓 manager 知道客戶端是否已經准備就緒的節點。客戶端通過 uid 代表自己，格式是 客戶端語言 _ 主機名 _pid 。當集群沒有進行遷移，即所有分片都是 online 的時候，客戶端會在 clients 下創建 uid 的臨時節點。
當某個 slot 從 online 變成 pre_migrate 後，客戶端會刪除 clients 下的 uid 臨時節點，然後在M igrating Clients 創建 uid 臨時節點。注意，因為需要保證數據不丟失，從 pre_migrate 到 migrating 期間，這個 slot 是被鎖定的，即所有對這個 slot 的讀寫都會被阻塞。所以 mananger 會最多等待 10s ，確認所有客戶端都已經切換到准備就緒狀態，如果發現某個客戶端一直未准備就緒，那麼 mananger 會放棄此次遷移，把 slot 狀態由 pre_migrate 改為 online 。如果客戶端發現 slot 狀態由 pre_migrate 變成 online 了，那麼會刪除 migrating_clients 下的 uid 節點，在 clients 下重新創建 uid 節點。還需要注意的一點是，有可能一個客戶剛啟動，並且正在往 clients 下創建 uid 節點，但是因為網路延遲還沒創建完成，導致 manager 未確認到這個 client 是否准備就緒，所以 mananger 把 slot 改為 pre_migrate 後會等待 1s 再確認所有客戶端是否准備就緒。
如果 Manager 看到 clients 下已經沒有客戶端的話（都已經准備就緒），會把 slot 狀態改為 migrating 。 Slot 變成 migrating 後，鎖定也隨之解除， manager 會遍歷 src group 的數據，把對應 slot 的數據遷移到 dst group 里。客戶端在 migrating 期間如果有讀寫 migrating slot 的 key ，那麼客戶端會先把這個 key 從 src group 遷移到 dst group ，然後再做讀寫操作。即這期間客戶端性能會有所下降。這也是為什麼每次只遷移一個 slot 的原因。這樣即使只有 128 個分片的集群，在遷移期間受到性能影響的 key 也只有 1/128 ，是可以接受的。
Manager 發現已經把 slot 已經遷移完畢了，會在 src 寫入目標 group_name ， dst 設為空， stats 設為 online 。客戶端也刪除 migrating_clients 下的 uid ，在 clients 下創建 uid 節點。
『伍』 面試問題redis有哪些集群方案
P2P模式，無中心化
把key分成16384個slot
每個實例負責一部分slot
客戶端請求若不在連接的實例，該實例會轉發給對應的實例。
通過Gossip協議同步節點信息
優點：
- 組件all-in-box，部署簡單，節約機器資源
- 性能比proxy模式好
- 自動故障轉移、Slot遷移中數據可用
- 官方原生集群方案，更新與支持有保障
缺點：
- 架構比較新，最佳實踐較少
- 多鍵操作支持有限（驅動可以曲線救國）
- 為了性能提升，客戶端需要緩存路由表信息
- 節點發現、reshard操作不夠自動化