1. 引言
前面我們已經聊過 redis 的主從同步（復制）和哨兵機制，這期我們來聊 Redis 的集群模式。
但是在超大規模的互聯網應用中，業務規模不斷擴展，用戶量持續增多時，原有的主從+哨兵機制已經不滿足我們的需求了。如：性能問題，數據量過多、并發量過高導致 Redis 服務器響應太慢。
1.1 自古功夫出少林
如果把 Redis 比作江湖里的門派，少林寺作為武林中最有威望的名門正派，提供了武功秘籍（緩存數據）的存儲服務。
由于少林存儲的可用性做的很好，武功秘籍幾乎不會丟失。而且，每次去獲取武林同道的秘籍時，響應也很快，所以少林威望不斷提升，后得千古美譽：“自古功夫出少林”。
少林的武功秘籍存儲方案為什么這么穩定呢？
這得從頭說起。
1.2 累壞的掌門人
在武林大會 3.0 之前，已經有很多武林同道在少林寺存取武功秘籍了，而少林掌門作為權力的中心，不僅披星戴月和外賓打交道（Client 請求），還得在管理物資之余（數據存儲和輸出）給副掌門做業務培訓（數據備份）。
雖然在武林大會 2.8 時，少林和武當一樣，已經新增了哨兵部門，從此不用擔心掌門嗝屁的問題。
詳見上一篇文章：深入淺出Redis高可用：哨兵機制
但掌門人日理萬機，應接不暇，還是把頭發都愁掉了！
為了掩飾尷尬，從此少林弟子不準留頭發
