http://www.tuicool.com/articles/nM7zymJ
Redis 集群 方案選型比較
Redis數(shù)據(jù)量日益增大，使用的公司越來(lái)越多，不僅用于做緩存，同時(shí)趨向于存儲(chǔ)這一塊，這樣必促使 集群 的發(fā)展，各個(gè)公司也在收集適合自己的集群方案， 目前行業(yè)用的比較多的是下面幾種集群架構(gòu) ，大部分都是采用分片技術(shù)，保證單實(shí)例內(nèi)存增大帶來(lái)的一系列問(wèn)題 ，下面所列出的 codis 方案目前正在不斷測(cè)試過(guò)程中，測(cè)試過(guò)程沒(méi)有展示出來(lái)， 主要從以下幾點(diǎn)出發(fā) 。
測(cè)試架構(gòu) 和性能 ：
1、keepalived+haproxy 故障測(cè)試
2、Zookeeper 集群節(jié)點(diǎn)測(cè)試
3、Codis-proxy 集群節(jié)點(diǎn)測(cè)試
4、Codis-server 集群節(jié)點(diǎn)測(cè)試
5、 腳本 寫入大量 測(cè)試數(shù)據(jù) 并模擬 數(shù)據(jù)遷移
6、 性能測(cè)試
下面具體介紹 codis 和其他幾大集群方案
集群方案：
1、 主從高可用（該方案就是單實(shí)例形式，只是為了保證數(shù)據(jù)的安全，對(duì)于用戶數(shù)據(jù)少，業(yè)務(wù)的前期可以采用，目前我司緩存架構(gòu)就是采用該方案）
2、 客戶端分片（典型代表： Jedis 。自主寫分片算法，代碼掌握在自己手中，可控性強(qiáng)，但是需要專業(yè)的開(kāi)發(fā)運(yùn)維人員維護(hù)，技術(shù)要求和維護(hù)成本高）
3 、代理分片（典型代表： Twemproxy ， redis 集群沒(méi)有正式推出之前官網(wǎng)推薦的方案，也是目前使用最多的）
4、 Redis cluster （ 3 版本推出的集群方案，歷時(shí)四年之多的開(kāi)發(fā)）
5、 Codis 集群（豌豆莢 15 年開(kāi)源的解決方案，開(kāi)源之前其已經(jīng)用了 2 年之多，與其同期官網(wǎng)推出 redis cluster ）
6、 各大互聯(lián)網(wǎng)公司自主研發(fā)的集群架構(gòu)，但是還沒(méi)有開(kāi)源，可能也不會(huì)開(kāi)源
根據(jù)以上的簡(jiǎn)單介紹，下面主要解釋后面三種集群方案的特點(diǎn)，以及針對(duì) 業(yè)務(wù) 的具體情況，斟酌選擇合適的架構(gòu)思考。
codis 架構(gòu)圖
簡(jiǎn)單說(shuō)明： 1 、 codis-proxy 提供連接集群 redis 的服務(wù)入口
2 、 codis-config 管理工具，支持包括添加 / 刪除 redis/proxy 節(jié)點(diǎn)，發(fā)起數(shù)據(jù)遷移等操作，自帶一個(gè) dashboard 工具，瀏覽器可以直觀查看集群的運(yùn)行狀態(tài)
3 、 codis-server-group 實(shí)現(xiàn) redis 讀寫的水平擴(kuò)展、高性能
4 、 codis-server 實(shí)現(xiàn) redis 實(shí)例服務(wù)，通過(guò) codis-ha 實(shí)現(xiàn)服務(wù)的高可用
5 、 Zookeeper/etcd 存放數(shù)據(jù)路由表和 codis-proxy 節(jié)點(diǎn)的元信息， codis-config發(fā)起的命令通過(guò)其同步到各個(gè)存活的 codis-proxy ，則 zookeeper 如果出問(wèn)題則可能導(dǎo)致數(shù)據(jù)不一致的情況或者嚴(yán)重的會(huì)對(duì)外提供服務(wù)造成影響
說(shuō)明：一切知識(shí)點(diǎn)來(lái)源于官方，本人經(jīng)過(guò)測(cè)試一步步驗(yàn)證，大致總結(jié)以上幾點(diǎn)
Twemproxy 架構(gòu)圖
簡(jiǎn)單說(shuō)明： 1 、 proxy 提供分片算法和 redis 服務(wù)入口，支持高可用
2 、 Redis 提供實(shí)現(xiàn)實(shí)例，并且通過(guò) sentinel 支持高可用
3 、 Redis-Twemporxy 提供通知底層 HA 切換至 proxy
4 、每個(gè)層結(jié)構(gòu)出現(xiàn)問(wèn)題或者變更節(jié)點(diǎn)信息等所有操作都需要重新規(guī)劃分片算法，則需要重啟服務(wù)
Redis cluster 架構(gòu)圖
簡(jiǎn)單說(shuō)明： 1 、 redis cluster 本身集群方案，客戶端可以任一連接一個(gè)節(jié)點(diǎn)
2 、 redis-trib.rb 腳本為集群的管理工具，比如自動(dòng)添加節(jié)點(diǎn)，規(guī)劃槽位，遷移數(shù)據(jù)等一系列操作（ ruby 語(yǔ)言）
3 、每個(gè)節(jié)點(diǎn)都和 N-1 個(gè)節(jié)點(diǎn)通信，所以要維護(hù)好這個(gè)集群架構(gòu)的每個(gè)節(jié)點(diǎn)信息，不然會(huì)導(dǎo)致整個(gè)集群不可工作
注意：以下三大方案redis cluster基于3.0版本
Redis 集群方案各參數(shù)比較
| Twemproxy | Codis | Redis Cluster |
架構(gòu)設(shè)計(jì) | 分布式 CAP, 犧牲 P 性能，而僅僅只是數(shù)據(jù)分片 | 分布式 CAP, 犧牲 P 性能，設(shè)計(jì)初衷為數(shù)據(jù)一致性 | 分布式 CAP,犧牲 C 數(shù)據(jù)強(qiáng)一致性原則，追求redis 最大的特點(diǎn)性能 |
設(shè)計(jì)模型 | Proxy-based | Proxy-based | Gossip/P2P |
設(shè)計(jì)思路 | 分布式邏輯和存儲(chǔ)引擎分開(kāi)，邏輯層 proxy 代理，存儲(chǔ)用的是原子 redis ，當(dāng)每個(gè)層面需要添加刪除節(jié)點(diǎn)必須重啟服務(wù)生效（要重新利用散列函數(shù)生成 KEY 分片更新） | 分布式邏輯和存儲(chǔ)引擎分開(kāi)，邏輯層 codis-proxy ，存儲(chǔ)用的是修改過(guò)的 codis-server, 這種好處是 proxy 層可以自動(dòng)擴(kuò)展和收縮，存儲(chǔ)層也同樣可以，每個(gè)層面都可以熱插撥 | 分布式的邏輯和存儲(chǔ)引擎不分開(kāi)，即又負(fù)責(zé)讀寫操作，又負(fù)責(zé)集群交互，升級(jí)困難，如果代碼有 bug ，集群無(wú)法工作 |
架構(gòu)特點(diǎn) | Proxy 無(wú)狀態(tài)， redis數(shù)據(jù)層有狀態(tài)的，客戶端可以請(qǐng)求任一 proxy 代理上面，再由其轉(zhuǎn)發(fā)至正確的 redis 節(jié)點(diǎn)，該 KEY分片算法至某個(gè)節(jié)點(diǎn)都是預(yù)先已經(jīng)算好的，在 proxy 配置文件保存著，但是如果更新或者刪除節(jié)點(diǎn)，又要根據(jù)一致性 hash 重新計(jì)算分片，并且重啟服務(wù) | Proxy 無(wú)狀態(tài)， codis-server 分為組間，每個(gè)組存在一個(gè)主節(jié)點(diǎn)（必須有并且只能有一個(gè)）和多個(gè)從節(jié)點(diǎn)。客戶端請(qǐng)求都是和 proxy 鏈接，鏈接哪個(gè) proxy 都一樣，然后由它根據(jù) zookeeper 路由信息轉(zhuǎn)發(fā)至正確節(jié)點(diǎn)，直接可以定位到正確節(jié)點(diǎn)上 | 這個(gè)結(jié)構(gòu)為無(wú)中心的組織，不好把控集群當(dāng)前的存活狀態(tài)，客戶端可以向任一節(jié)點(diǎn)發(fā)送請(qǐng)求，再有其重定向正確的節(jié)點(diǎn)上。如果在第一次請(qǐng)求和重定向期間 cluster 拓?fù)浣Y(jié)構(gòu)改變，則需要再一次或者多次重定向至正確的節(jié)點(diǎn)，但是這方面性能可以忽悠不計(jì) |
codis獨(dú)特之處 | 不支持 | 1、 有中心節(jié)點(diǎn)，邏輯問(wèn)題交由 proxy 處理， codis還有個(gè)特點(diǎn)下層存儲(chǔ)可以根據(jù)數(shù)據(jù)的冷熱程度把冷數(shù)據(jù)暫時(shí)保存至磁盤，待其為熱數(shù)據(jù)的時(shí)候又可以上線（這點(diǎn)我還沒(méi)有測(cè)試） 2、 提供數(shù)據(jù)在線遷移的工具 比如需求要從 redis 或者 twemproxy 遷移數(shù)據(jù)至 codis或者以后 redis 數(shù)據(jù)庫(kù)中，又不想直接預(yù)熱，可以借助其提供的 redis-port 命令行工具 | 不支持 |
開(kāi)發(fā)語(yǔ)言 | C 語(yǔ)言 | Go 語(yǔ)言、 C 語(yǔ)言 | C 語(yǔ)言 |
服務(wù)啟動(dòng)方式 | 單進(jìn)程 | 多進(jìn)程 | 單進(jìn)程 |
性能問(wèn)題 | 1、 單點(diǎn)的話比起原子redis 降低 20% 左右； 2、 增加 PIPELINE 管道提高性能 只要是代理的設(shè)計(jì)性能瓶頸肯定在其，因 redis實(shí)在太快 | 1、 相當(dāng)于單 redis 實(shí)例 40% 性能丟失 ( 從最開(kāi)始的版本比 Twemproxy慢20% 至目前比其快 100%) ； 2、 彌補(bǔ)：增加 proxy 數(shù)量和支持多核，比起 Twemproxy 還是好一點(diǎn)，因 Twemproxy 最好的情況跑滿一個(gè) CPU ； 3、 彌補(bǔ)：增加 PIPELINE管道提高性能 只要是代理的設(shè)計(jì)性能瓶頸肯定在其，因 redis 實(shí)在太快 | 沒(méi)什么損失，追求的就是這個(gè) 1000 個(gè)節(jié)點(diǎn)內(nèi)擁有線性的伸縮性，和操作 redis實(shí)例性能差不多 |
分片算法 | Redis 一致 hash ，當(dāng)初設(shè)計(jì)好如后續(xù)變更修改（增減節(jié)點(diǎn)）需要配置 proxy 通知新的算法，重啟服務(wù) | 通過(guò)presharding采用 solt槽位的形式，整個(gè)集群分為1024 個(gè)哈希槽，分片算法位SlotId = crc32(key) % 1024，增減節(jié)點(diǎn)不需要重啟服務(wù) | 采用 solt 槽位的形式，整個(gè)集群分為 16384 個(gè)哈希槽，分片算法位 SlotId = crc16(key) % 16384，增減節(jié)點(diǎn)不需要重啟服務(wù) |
所需組件 | Redis 、 twemproxy(nutcracker) | Codis 、 zookeeper | redis |
數(shù)據(jù)一致性 | 不能保證強(qiáng)一致性 1、 如 redis cluster 第一種情況沒(méi)有，設(shè)計(jì)不一樣 2、 網(wǎng)絡(luò)分裂，這種情況其有監(jiān)控工具可以通知管理員某個(gè)主節(jié)點(diǎn)宕機(jī)，這時(shí)如果管理員切換 HA（但是不提供自動(dòng)提升從節(jié)點(diǎn)為主節(jié)點(diǎn)，因從節(jié)點(diǎn)變?yōu)橹鞴?jié)點(diǎn)必須更新分片算法，重啟服務(wù)），數(shù)據(jù)就會(huì)丟失，因主節(jié)點(diǎn)的寫命令會(huì)丟失，除非再次 AOF 同步最后一條寫命令，二者如國(guó)管理員可以判斷其為網(wǎng)絡(luò)分裂，等待網(wǎng)絡(luò)恢復(fù)是主節(jié)點(diǎn)會(huì)向從節(jié)點(diǎn)同步寫命令數(shù)據(jù) | 強(qiáng)一致性 1、 數(shù)據(jù)遷移過(guò)程中數(shù)據(jù)強(qiáng)一致性性，因遷移都是一個(gè)個(gè) KEY 原子遷移，每次操作都是給 ZK 發(fā)送信息，通知 proxy ，同時(shí)所有操作都是上一把鎖，假如該期間有客戶端訪問(wèn)，則提升訪問(wèn)該KEY 的操作為優(yōu)先操作，快速遷移至新節(jié)點(diǎn)，訪問(wèn)轉(zhuǎn)移至新節(jié)點(diǎn)，不會(huì)訪問(wèn)老的 KEY ，如期間也可以中斷正在同步的數(shù)據(jù)，也是不影響，因?yàn)?nbsp;redis 沒(méi)有回滾機(jī)制，要么成功要么失敗 2、 網(wǎng)絡(luò)分裂：因?yàn)樗脑O(shè)計(jì)初衷就是不考慮 HA 自動(dòng)切換（后面添加該功能），等到網(wǎng)絡(luò)恢復(fù) Zookeeper 保證數(shù)據(jù)一致性，寫命令不會(huì)丟失 ，所有操作都要在zookeeper 上面注冊(cè) | 不能保證強(qiáng)一致性 比如官網(wǎng)給出的兩種有可能丟失寫命令的情況如下 1、 客戶端向主節(jié)點(diǎn) A 發(fā)送一條寫命令，主節(jié)點(diǎn)是首先立馬向客戶端返回命令回復(fù)，然后再把剛剛的執(zhí)行寫命令同步至從節(jié)點(diǎn)，追求性能所致該設(shè)計(jì) 2、 網(wǎng)絡(luò)分裂(network partition) ，如果時(shí)間很長(zhǎng)導(dǎo)致 A 節(jié)點(diǎn)的從節(jié)點(diǎn)轉(zhuǎn)換為主節(jié)點(diǎn)，然這中間可能存在客戶端正在和 A 節(jié)點(diǎn)通信也就被孤立了，這樣寫的命令將丟失，如當(dāng)網(wǎng)絡(luò)恢復(fù) A 又重新加入集群 |
數(shù)據(jù)的特殊安全 | 1、 比如某段時(shí)間業(yè)務(wù)數(shù)據(jù)一下爆表（內(nèi)存寫滿），數(shù)據(jù)來(lái)不及遷移，這樣的話 redis 會(huì)根據(jù) LRU 策略，會(huì)淘汰一部分老的 key ，這個(gè)沒(méi)辦法，所以運(yùn)維中當(dāng)內(nèi)存使用 80% 時(shí)應(yīng)該擴(kuò)容 2、 主從切換過(guò)程中有一部分?jǐn)?shù)據(jù)丟失（主掛了到從切換上來(lái)丟失的這部分?jǐn)?shù)據(jù)） |
磁盤 IO | 基于 redis 本身的持久化（ RDB 和 AOF ），肯定會(huì)存在數(shù)據(jù)丟失的情況 |
數(shù)據(jù)的遷移 | 不可在線遷移，并且遷移完之后需要修改配置文件的分片算法，再重新啟動(dòng) Twemproxy 服務(wù)，重新識(shí)別分片算法 | 采用 sharding 在線遷移數(shù)據(jù)，安全透明，可以自動(dòng)平衡數(shù)據(jù)到其他節(jié)點(diǎn)，相當(dāng)于可熱插撥，不會(huì)造成響應(yīng)時(shí)延（因遷移時(shí)會(huì)另外有個(gè)進(jìn)程來(lái)做，數(shù)據(jù)遷移還是原子的數(shù)據(jù)遷移指令，這樣遷移的話就會(huì)相當(dāng)慢一些） | 在線遷移數(shù)據(jù)，動(dòng)態(tài)遷移 KEY 值會(huì)造成響應(yīng)時(shí)延（遷移數(shù)據(jù)是拷貝 RDB 數(shù)據(jù)文件，而且因?yàn)?nbsp;redis 是單進(jìn)程的），另外新節(jié)點(diǎn) solt 又不自動(dòng)，依賴 ruby(redis cluster 集群管理和分配腳本 )腳本來(lái)平衡數(shù)據(jù)，無(wú)中心設(shè)計(jì)如此 |
水平擴(kuò)容縮容（增減節(jié)點(diǎn)） | Redis 存儲(chǔ)層操作，不提供自動(dòng)的解決方案，并且要自己寫腳本支持?jǐn)?shù)據(jù)的搬遷活動(dòng)，然后更改 proxy 哈希算法，重啟服務(wù) | Redis 存儲(chǔ)層，都是在線操作（擴(kuò)容數(shù)據(jù)遷移，縮容的話先搬遷數(shù)據(jù)至別的節(jié)點(diǎn)，然后下線該節(jié)點(diǎn)） | 沒(méi)有代理和存儲(chǔ)之分，可以在線操作（擴(kuò)容數(shù)據(jù)遷移，縮容的話先搬遷數(shù)據(jù)至別的節(jié)點(diǎn)，然后下線該節(jié)點(diǎn)） |
主從是否必須 | 1、 沒(méi)有數(shù)據(jù)復(fù)制不影響可用節(jié)點(diǎn)代替故障節(jié)點(diǎn) 2、 如果沒(méi)有做備份，故障節(jié)點(diǎn) key 全部丟失 | 1、 故障節(jié)點(diǎn)如果沒(méi)有備份，則丟失掉該組的所有數(shù)據(jù)，但是不影響其他組的運(yùn)行，不會(huì)導(dǎo)致整個(gè)集群壞掉 2、 如有備份節(jié)點(diǎn)，則把其升為主節(jié)點(diǎn)，集群沒(méi)有影響，正常運(yùn)轉(zhuǎn)（需要管理員手動(dòng)變更從節(jié)點(diǎn)為主節(jié)點(diǎn)，最新版本添加 HA 功能） | 沒(méi)有主從復(fù)制的節(jié)點(diǎn)一旦故障，將導(dǎo)致整個(gè)集群不可用，無(wú)法寫入或者讀入任何 key ，無(wú)法進(jìn)行數(shù)據(jù)重新分片 官網(wǎng)建議：至少 3 主 3 從 |
主從特點(diǎn) | 基于 redis 本身的主從方案（利用發(fā)布 / 訂閱機(jī)制，采用廣播形式）， 采用異步復(fù)制（ asynchronous replication ）的方案，無(wú)論是 master 端還是 slave 端都不會(huì)引起阻塞，但是肯定是存在數(shù)據(jù)丟失的情況 |
集群設(shè)計(jì) | 1、 proxy 部署高可用（多 proxy 結(jié)合 keepalived+haporxy ） 2、 redis 層設(shè)計(jì)多主多從部署 | 1、 proxy 部署（多 proxy+zookeeper 集群方案，并且結(jié)合 keepalived+haporxy ） 2、 codis-server 部署多組，每組部署一主多從架構(gòu) | 利用 redis 本身部署集群：至少 3 主 3 從 |
HA 方案 | Proxy 層已經(jīng)有了，由上面的設(shè)計(jì)， redis 層基于自帶的 HA 解決方案（sentinel ），這里不闡述sentinel 機(jī)制 | Proxy 層已經(jīng)有了，存儲(chǔ)層本來(lái)設(shè)計(jì)就沒(méi)有考慮自動(dòng)HA 切換，后面根據(jù)用戶強(qiáng)烈的要求，目前添加 codis-ha解決 | 自主監(jiān)控自動(dòng)切換 ( 把 sentinel功能搬遷過(guò)來(lái) ) |
故障監(jiān)控 | 自帶監(jiān)控并告警 | 自帶監(jiān)控并告警 | 目前還沒(méi)有提供 |
故障檢測(cè)和故障轉(zhuǎn)移時(shí)間 | 1 、 proxy 配置文件設(shè)置： auto_eject_hosts: true timeout: 400 server_failure_limit: 3 當(dāng) proxy server 超時(shí) 400 毫且 3 次重試機(jī)會(huì)，則認(rèn)為該 proxy 節(jié)點(diǎn)壞掉，這樣故障節(jié)點(diǎn)從 hash 環(huán)直接取下，并且清理該 Key 信息 故障轉(zhuǎn)移耗時(shí)：400*3=1200 毫秒 2 、如果存儲(chǔ)層加入 sentinel 做 HA （注意：底層 redis 轉(zhuǎn)移故障之后，因 proxy 層不知道該配置信息已經(jīng)變動(dòng)，此時(shí)需要引入第四方工具 redis-twemproxy-agent （ node.js ），更新Twemproxy 配置，并重啟） 故障轉(zhuǎn)移耗時(shí)： 每個(gè) sentinel 以每秒發(fā)送一次 ping ，配置 down-after-milliseconds=2s，則主觀認(rèn)為下線 3 秒，然數(shù)量 sentinel （配置文件可以配置）認(rèn)可同意需要 1s ，再 sentinel 當(dāng)選故障轉(zhuǎn)移主持節(jié)點(diǎn)需要 1秒，選出 slave 升級(jí)為 master 需要 0.5 秒，通過(guò)發(fā)布和訂閱推送更新配置至其他 sentinel 并且配置更新需要 1 秒，這樣 總共耗時(shí) 6.5 秒。 | 1、 proxy 層配置文件： backend_ping_period=5則表示 5 秒 zookeeper 沒(méi)有等到 pong 回應(yīng)就認(rèn)為 proxy已經(jīng)壞掉 故障轉(zhuǎn)移耗時(shí)： 5 秒 2、 存儲(chǔ)層本來(lái)不設(shè)置自動(dòng)故障遷移的 （后面添加 codis-ha 機(jī)制） 過(guò)程： codis-ha 通過(guò)dashboard監(jiān)控每組的存活狀況，zookeeper 能夠快速知道存活的 proxy 節(jié)點(diǎn)，然后休眠3 秒再次監(jiān)控至重試 3 次，大致 10 秒左右時(shí)間切換，但是官方建議，還是不希望使用該解決方案，因主節(jié)點(diǎn)有問(wèn)題，立馬切換從節(jié)點(diǎn)為主節(jié)點(diǎn)可能導(dǎo)致數(shù)據(jù)丟失的情況。推薦大家使用手動(dòng)切換，做好監(jiān)控，確定好數(shù)據(jù)安全然后使用 web 界面或者命令手動(dòng)操作（因用戶的強(qiáng)烈要求才加入該解決方案） | Redis cluster拓?fù)浣Y(jié)構(gòu)是一張完全圖：每個(gè)節(jié)點(diǎn)都持有 N-1 個(gè)輸入 TCP 和 N-1個(gè)輸出 TCP 。 這里不闡述故障監(jiān)控和切換的流程（比如 FAIL狀態(tài)、 slave 選主時(shí)機(jī)和 cluster邏輯時(shí)鐘等） 故障轉(zhuǎn)移耗時(shí)（配置文件可以修改） Node_time=2 Fail_report_validity_mult=3 標(biāo)記 master為 pfail 耗時(shí) 2秒，升級(jí) pfail 為fail 狀態(tài)耗時(shí)為 2*3=6 秒，選主前隨機(jī)延期期望為1 秒，收集足夠多 master 投票為 max((2*node_time),2)=4 秒 這樣總共耗時(shí)13 秒。 |
功能限制 | 1、 不支持多 key 操作 2、 不支持 MULTI/EXEC 3、 不支持 EVAL | 比較多，可以查看官方文檔 | 1、 復(fù)雜的多KEY(set 求并求交集 ) 不能跨節(jié)點(diǎn)操作 2、 不支持 MULTI/EXEC 3、 寫丟失比較頻繁 |
提供支持 | 不在維護(hù) | 目前活躍狀態(tài) | 官網(wǎng)主打 |
客戶端driver工具 | 保持不變（ redis 支持的都支持） | 保持不變（ redis 支持的都支持） | 只能支持 cluster 協(xié)議的客戶端工具（目前官網(wǎng)上面說(shuō)的是針對(duì)JAVA 的是 Jides，針對(duì) PHP 的是 Predis ，而且不成熟） |
概括 | 1、 輕量級(jí) 2、 在 proxy 層實(shí)現(xiàn)一致性哈希 3、 快速的故障轉(zhuǎn)移 4、 可借助 sentinel 實(shí)現(xiàn)底層 HA 5、 每次變更必須重啟生效 | 1、 基于 zookeeper 的 proxy 高可用 ，zookeeper 會(huì)記錄整個(gè)集群的生存狀態(tài)，則需要維護(hù)好 zookeeper 2、 優(yōu)勢(shì)為動(dòng)態(tài)水平擴(kuò)容，平衡數(shù)據(jù)，在遷移的時(shí)候不影響業(yè)務(wù)訪問(wèn)和響應(yīng)時(shí)間，這點(diǎn)很炫，也是它主打的方向 3、 Dashboard 操作降低人失誤率，圖形直觀查看信息 4、 強(qiáng)一致數(shù)據(jù)（也是設(shè)計(jì)的重點(diǎn)） | 1、 性能好（也是設(shè)計(jì)的原則） 2、 無(wú)中心組織結(jié)構(gòu)，有利有弊 3、 故障轉(zhuǎn)移響應(yīng)時(shí)間長(zhǎng) 4、 有寫丟失，比較頻繁 |
總結(jié)： 沒(méi)有最好的架構(gòu)，只有最合適的架構(gòu)