分片架構解決的問題
通過堆機器，提升讀寫性能，與存儲性能
分片架構設計要點
分片規則
選擇Cardinality大的作為分片鍵，盡可能保證資料分布均勻
常見分片鍵： 基于主鍵（業務型資料），基于時間（流水型資料）
常見分片政策：
| 分片政策 | 實作舉例 | 資料分布 | 以後擴充 |
| 基于Hash | hash(分片鍵)%分片數 一緻性hash算法 | 資料分布均勻 | 不易擴容，擴容需要資料遷移 |
| 範圍分片 | 例如按年分，按月，按日 | 資料分表可能不均勻 | 易擴充，擴充不需要資料遷移 |
路由規則
用戶端如何找到資料所在分片
- 靜态路由： 配置檔案。特點： 簡單，不能擴充再平衡，例如：Mysql分表
- 動态路由：實作複制，支援動态擴充，再平衡
| 動态路由方式 | 基本流程 | 特點 | 舉例 |
| 配置中心 | 配置中心記錄分片資訊，用戶端先通路配置中心， 擷取分片資訊之後進行讀寫操作 | 支援大規模叢集，配置中心需要獨立部署，需要高可用 | MongoDB的Sharding模式 |
| 路由轉發 | 所有分片都儲存路由資訊，用戶端請求任意分片， 擷取分片資訊之後進行讀寫操作 | 架構簡單，一般利用gossip協定，不支援大規模叢集 | Redis Cluster （官方推薦1000，實際建議100） |
高可用
| 備份方式 | 特點 | 舉例 |
| 獨立備份 | 架構簡單，硬體成本高，分片級别的複制 | Mysql ，Redis等 |
| 互相備份 | 架構複雜，硬體成本低，資料塊級别的複制 | ElasticSearch 等 |
redis cluster 分析
特點
理論支援1000台，實際建議100台以内。 高性能，線性可擴充，無代理，異步複制。
架構圖- 來自阿裡雲溪社群
分片規則
分片鍵
redis的key
分片方式
類似一緻性Hash，通過CRC16算法計算出來的哈希值，對16384（2^14）取模，取模之後得到的值就是對應的槽位，然後每個Redis節點都會負責處理一部分的槽位。
擴充1 一般hash算法缺點
hash（鍵值）%分片數量，如果有分片挂掉，分片數量會下降，整個叢集會失效。
擴充2 一緻性hash算法
CRC16算法計算出來的哈希值，對2^32取模
執行個體也分布在圓環(0-2^32)上，我們在圓環上按照順時針的順序找到第一個執行個體
執行個體可能分布不均勻，采用虛拟節點機制解決
路由規則
路由轉發模式，一般利用gossip協定，所有分片都儲存路由資訊，用戶端請求任意分片
叢集為了分布均勻，再平衡，或，添加，删除master執行個體，存在重定向的情況。
重定向
| 場景 | 指令 | 說明 |
| 全部遷移完成的情況下 | MOVED指令 | 1.MOVED把用戶端所請求資料的最新執行個體位址返傳回用戶端 2.更新用戶端緩存的哈希槽配置設定資訊 |
| 哈希槽資料還在遷移中 | ASK | 1.ASK 指令把用戶端所請求資料的最新執行個體位址傳回給用戶端 2.用戶端需要給目标執行個體 發送 ASKING 指令，然後再發送操作指令 3.不更新用戶端緩存的哈希槽配置設定資訊 |
備份方式
獨立備份
故障轉移：
某一個節點認為A當機了，那麼此時是主觀當機
叢集内超過半數的節點認為A挂了， 那麼此時A就會被标記為客觀當機
從A節點的slave節點中選舉出一個，将其切換成新的master對外提供服務