一、美團(tuán)點(diǎn)評(píng) KV 存儲(chǔ)發(fā)展歷程
二、內(nèi)存 KV Squirrel 架構(gòu)和實(shí)踐
2.1?Squirrel 節(jié)點(diǎn)容災(zāi)????2.2?跨地域容災(zāi)????2.3?智能遷移 ? 2.4?持久化重構(gòu)??2.5?熱點(diǎn) Key
三、持久化 KV Cellar 架構(gòu)和實(shí)踐
3.1節(jié)點(diǎn)容災(zāi)??3.2跨地域容災(zāi)? 3.3強(qiáng)一致????3.4智能遷移????3.5快慢列隊(duì)????3.6熱點(diǎn) Key
一、美團(tuán)點(diǎn)評(píng) KV 存儲(chǔ)發(fā)展歷程
1.1第一代(左側(cè))
客戶端內(nèi)做一致性哈希，后端部署很多Memcached實(shí)例，實(shí)現(xiàn)最基本 KV 存儲(chǔ)分布式設(shè)計(jì)。
問(wèn)題：宕機(jī)摘除節(jié)點(diǎn)/擴(kuò)容，一致性哈希丟數(shù)據(jù)
1.2第二代(右側(cè))
客戶端同上，服務(wù)器Redis組成的主從結(jié)構(gòu)。
問(wèn)題：哨兵完成 Failover，實(shí)現(xiàn)高可用。但擴(kuò)縮容，一致性哈希仍丟數(shù)據(jù)
1.3第三代
這時(shí)發(fā)現(xiàn)成熟KV 存儲(chǔ)開(kāi)源項(xiàng)目：阿里 Tair。
開(kāi)源版本架構(gòu)主要分成三部分：
1)存儲(chǔ)節(jié)點(diǎn)：上報(bào)心跳到它的中心節(jié)點(diǎn)
2)中心節(jié)點(diǎn)：兩個(gè)配置管理節(jié)點(diǎn)，會(huì)監(jiān)控所有的存儲(chǔ)節(jié)點(diǎn)，宕機(jī)或者擴(kuò)容時(shí)，集群拓?fù)渲匦聵?gòu)建
3)客戶端：啟動(dòng)時(shí)，直接從中心節(jié)點(diǎn)拉路由表。根據(jù)路由表(集群數(shù)據(jù)分布圖)直接讀寫存儲(chǔ)節(jié)點(diǎn)。有數(shù)據(jù)遷移機(jī)制保證數(shù)據(jù)完整性。
使用遇到問(wèn)題：Tair 解決了一些問(wèn)題，但無(wú)法完全滿足
1）沒(méi)有仲裁，網(wǎng)絡(luò)分割有可能發(fā)生“腦裂”的，給業(yè)務(wù)造成過(guò)較大影響。
2）容災(zāi)擴(kuò)容時(shí)，數(shù)據(jù)遷移影響到業(yè)務(wù)可用性
3）Redis數(shù)據(jù)結(jié)構(gòu)特別豐富，Tair 還不支持
1.4自研
Squirrel：基于Redis Cluster(2015 年發(fā)布)，演進(jìn)出全內(nèi)存、高吞吐、低延遲的 KV 存儲(chǔ)。
迭代：自研和社區(qū)并重，盡量兼容官方。
應(yīng)用：數(shù)據(jù)量小，對(duì)延遲敏感
Cellar：基于 Tair，演進(jìn)出持久化、大容量、數(shù)據(jù)高可靠KV 存儲(chǔ)。
迭代：完全靠自研（四五年沒(méi)更新）。和 Squirrel 在解決同樣的問(wèn)題時(shí)也選取了不同的設(shè)計(jì)方案。
應(yīng)用：數(shù)據(jù)量大，對(duì)延遲不特別敏感
目前美團(tuán)內(nèi)部每天的調(diào)用量均已突破萬(wàn)億，請(qǐng)求峰值突破每秒億級(jí)
二、內(nèi)存 KV Squirrel 架構(gòu)和實(shí)踐
共通：數(shù)據(jù)分布一樣(Key怎么分布到存儲(chǔ)節(jié)點(diǎn)上)。拿Key 哈希到哈希值，哈希值對(duì) Slot 數(shù)取模得Slot id，都是預(yù)分片16384個(gè)Slot。路由表就是一個(gè) Slot 到存儲(chǔ)節(jié)點(diǎn)對(duì)照表
Squirrel 架構(gòu)：
集群跟Redis一致(中間)：主從，通過(guò)Gossip 協(xié)議去通信。
添加集群調(diào)度平臺(tái)(右)：調(diào)度服務(wù)、擴(kuò)縮容服務(wù)和高可用服務(wù)等，管理整個(gè)集群，把結(jié)果作為元數(shù)據(jù)更新到zk?？蛻舳藭?huì)訂閱zk元數(shù)據(jù)變更，實(shí)時(shí)獲取到集群拓?fù)錉顟B(tài)，直接讀寫Redis集群
2.1 Squirrel 節(jié)點(diǎn)容災(zāi)
1）Redis集群節(jié)點(diǎn)宕機(jī)已有完備處理機(jī)制：從宕機(jī)到被標(biāo)記為 FAIL 摘除，一般30秒。主庫(kù)摘除可能影響數(shù)據(jù)完整性，謹(jǐn)慎一些。但從庫(kù)，我們認(rèn)為這個(gè)過(guò)程完全沒(méi)必要。
2）內(nèi)存KV 存儲(chǔ)數(shù)據(jù)量一般比較小。業(yè)務(wù)量大公司，會(huì)有很多集群。如交換機(jī)故障，影響很多集群，宕機(jī)補(bǔ)副本非常麻煩。
我們做了 HA 高可用服務(wù)，解決這兩個(gè)問(wèn)題：1）從庫(kù)摘除時(shí)間從?30 秒降到5 秒。2）通過(guò) HA 自動(dòng)申請(qǐng)容器實(shí)例加入集群的方式，把宕機(jī)補(bǔ)副本變成分鐘級(jí)自動(dòng)操作，不需人工介入
實(shí)時(shí)監(jiān)控集群的所有節(jié)點(diǎn)。網(wǎng)絡(luò)抖動(dòng)/宕機(jī)（比如說(shuō)Redis2 ）實(shí)時(shí)更新zk，去摘除Redis 2：1）客戶端收到消息后，讀流量就直接路由到Redis3上。
2）如只是幾十秒的網(wǎng)絡(luò)抖動(dòng)， HA 節(jié)點(diǎn)監(jiān)控到恢復(fù)后，重新加回
3）如HA 判斷屬于永久性宕機(jī)，HA 節(jié)點(diǎn)會(huì)直接從 Kubernetes 集群申請(qǐng)新的 Redis 4 容器實(shí)例，加到集群里。拓?fù)浣Y(jié)構(gòu)又變成一主兩從，HA 節(jié)點(diǎn)更新完集群拓?fù)渲?，?ZK通知客戶端去更新路由，客戶端就能讀新從庫(kù)?Redis 4?
2.2 Squirrel 跨地域容災(zāi)
1、跨地域于單節(jié)點(diǎn)不同：
1）跨地域?qū)＞€不穩(wěn)定，相對(duì)于同地域機(jī)房間網(wǎng)絡(luò)；
2）帶寬有限且昂貴，同樣一份數(shù)據(jù)要傳輸兩次，巨大帶寬浪費(fèi)
3）官方主從同步滿足不了，單元化部署和異地多活架構(gòu)?；诖?，我們做了集群間復(fù)制方案
2、下圖：北京主集群、上海從集群，把北京數(shù)據(jù)同步上海：
1）向同步調(diào)度模塊，下發(fā)“建立同步鏈路”任務(wù)，
2）同步調(diào)度模塊，根據(jù)集群結(jié)構(gòu)，把任務(wù)下發(fā)到同步集群，
3）同步集群收到，扮成 Redis 的 Slave，通過(guò) Redis 復(fù)制協(xié)議，從主集群上的從庫(kù)拉數(shù)據(jù)，包括 RDB及后續(xù)增量變更
4）同步機(jī)收到數(shù)據(jù)后，把它轉(zhuǎn)成客戶端寫命令，寫上海從集群主節(jié)點(diǎn)里。
ps：同樣，異地多活，再加一個(gè)反向同步鏈路，實(shí)現(xiàn)集群雙向同步
如何做好微觀角度高可用，保持端到端的高成功率。 Squirrel 三個(gè)影響成功率的問(wèn)題：
1）數(shù)據(jù)遷移造成超時(shí)抖動(dòng)
2）持久化造成超時(shí)抖動(dòng)
3）熱點(diǎn) Key 請(qǐng)求導(dǎo)致單節(jié)點(diǎn)過(guò)載
2.3?Squirrel 智能遷移
數(shù)據(jù)遷移三個(gè)問(wèn)題：
1）Redis Cluster 雖能遷移，但不管要遷哪些 Slot，從哪遷到哪
2）想越快越好，但遷移過(guò)快又可能影響業(yè)務(wù)正常請(qǐng)求
3）Redis 的 Migrate 命令會(huì)阻塞工作線程，尤其遷移大 Value 時(shí)候會(huì)阻塞特別久
解決這些問(wèn)題，做新的遷移服務(wù)
1）生成遷移任務(wù)，的核心是“就近原則”，同機(jī)房遷移肯定比跨機(jī)房快。
2）任務(wù)生成后，下發(fā)任務(wù)到一批遷移機(jī)上
? ? ? ? 遷移機(jī)遷移時(shí)特點(diǎn)：
????????1.并發(fā)，同時(shí)給 Redis 1、Redis 3 下發(fā)遷移命令
? ? ? ? 2.每個(gè) Migrate 命令會(huì)遷移一批 Key
? ? ? ? 3.監(jiān)控實(shí)時(shí)采集客戶端成功率、耗時(shí)，服務(wù)端負(fù)載、QPS 等，把狀態(tài)反饋到遷移機(jī)。
? ? ? ? 4.遷移過(guò)程類似 TCP 慢啟動(dòng)，速度一直加，若請(qǐng)求成功率下降，降速度，速度動(dòng)態(tài)平衡中穩(wěn)定，最快速遷移，最小影響業(yè)務(wù)正常請(qǐng)求
3）大 Value 的遷移，異步實(shí)現(xiàn) Migrate 命令，執(zhí)行時(shí)，Redis 主線程繼續(xù)處理正常請(qǐng)求。如有遷移請(qǐng)求，直接返回錯(cuò)誤。保證業(yè)務(wù)請(qǐng)求處理，同時(shí)不阻塞主線程
2.4 Squirrel 持久化重構(gòu)
背景：RDB 過(guò)程調(diào)用 Fork 產(chǎn)生子進(jìn)程去寫數(shù)據(jù)到硬盤，雖然有操作系統(tǒng)COW 機(jī)制，但內(nèi)存用量達(dá)到 10 /20 G 時(shí)，秒級(jí)阻塞。在線業(yè)務(wù)來(lái)無(wú)法接受。可靠性要求高業(yè)務(wù)開(kāi)啟 AOF，開(kāi) AOF 可能因 IO 抖動(dòng)進(jìn)程阻塞，影響請(qǐng)求成功率。
改進(jìn):
1）寫時(shí)：先寫 DB ，然后寫內(nèi)存 Backlog，跟官方一樣。同時(shí)把請(qǐng)求發(fā)異步線程，把變更刷到硬盤 Backlog 。Backlog 過(guò)多，做 RDB(業(yè)務(wù)低峰期)?，把 RDB 之前Backlog 刪除。
2）找同步點(diǎn)時(shí)
????1.從內(nèi)存 Backlog 里找，
? ? 2.沒(méi)有去硬盤 Backlog 找（由于硬盤空間很大，存儲(chǔ)多，很少會(huì)找不到）。
? ? 3.如硬盤 Backlog 沒(méi)有，觸發(fā)全量重傳， 直接用硬盤已存RDB 及之后硬盤 Backlog 完成全量重傳。
????優(yōu)點(diǎn)：1.不需當(dāng)場(chǎng)生成 RDB，減少很多全量重傳
? ? ? ? ? ? ? ?2.控制在低峰區(qū)生成 RDB ，減少RDB 造成的抖動(dòng)。同時(shí)避免了寫 AOF 造成的抖動(dòng)。ps：寫 AOF 完全異步，比官方可靠性差一些，但可用性提升，非常值得的。
2.5 Squirrel 熱點(diǎn) Key
解決方案如下圖，普通主、從是正常集群中節(jié)點(diǎn)，熱點(diǎn)主、從游離于正常集群外節(jié)點(diǎn)。它們之間怎么發(fā)生聯(lián)系
實(shí)時(shí)熱點(diǎn)監(jiān)控，流控止損：? 讀寫普通節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)內(nèi)同時(shí)做請(qǐng)求 Key 統(tǒng)計(jì)，某Key 達(dá)到一定訪問(wèn)量或者帶寬占用量，自動(dòng)觸發(fā)流控以限制熱點(diǎn) Key 訪問(wèn)，防止節(jié)點(diǎn)被打滿。
自動(dòng)熱點(diǎn)隔離，遷移和快速擴(kuò)容：? ??同時(shí)，監(jiān)控服務(wù)周期性去Redis 實(shí)例查統(tǒng)計(jì)熱點(diǎn) Key。把熱點(diǎn) Key 所在 Slot 上報(bào)到遷移服務(wù)，把熱點(diǎn)主從節(jié)點(diǎn)加到集群中，熱點(diǎn) Slot 遷移到這個(gè)熱點(diǎn)主從上。因?yàn)?b>熱點(diǎn)主從只有熱點(diǎn) Slot 請(qǐng)求，處理能力大幅提升
三、持久化 KV Cellar 架構(gòu)和實(shí)踐
跟開(kāi)源Tair兩不同:
OB： 跟 ZooKeeper 的 Observer類似作用，查詢Cellar 中心節(jié)點(diǎn)元數(shù)據(jù)。與中心節(jié)點(diǎn) Master 實(shí)時(shí)同步路由表，客戶端路由表從 OB 拿。
? ??這樣好處：1）把大量的業(yè)務(wù)客戶端跟集群的大腦 Master 做了天然的隔離，防止路由表請(qǐng)求影響集群的管理。2）因?yàn)?OB 只供路由表查詢，不參與集群的管理，所以它可以進(jìn)行水平擴(kuò)展，極大地提升路由表查詢能力
ZK：做分布式仲裁，解決Master、Slave 網(wǎng)絡(luò)分割的“腦裂”問(wèn)題，元數(shù)據(jù)存zk，保證高可靠
3.1 Cellar 節(jié)點(diǎn)容災(zāi)
集群節(jié)點(diǎn)宕機(jī)、網(wǎng)絡(luò)抖動(dòng)一般是臨時(shí)的，很快恢復(fù)，重新加入集群。因?yàn)榕R時(shí)離開(kāi)就徹底摘除，并做數(shù)據(jù)副本補(bǔ)全，消耗大，影響業(yè)務(wù)請(qǐng)求。所以，實(shí)現(xiàn)Handoff解決節(jié)點(diǎn)短時(shí)故障帶來(lái)的影響：
A 宕機(jī)觸發(fā) Handoff ：1)中心節(jié)點(diǎn)通知客戶端 A故障，2)讓客戶端把分片 1 請(qǐng)求也打到 B 上。3)B 處理完，把應(yīng)寫入 A的?1&2 數(shù)據(jù)寫本地 Log 中
A 節(jié)點(diǎn)宕機(jī)3~5 分鐘，或網(wǎng)絡(luò)抖動(dòng) 30~50 秒恢復(fù)：
1）A 上報(bào)心跳到中心節(jié)點(diǎn)，通知 B 節(jié)點(diǎn) A恢復(fù)
2）B把本地 Log 回寫A 上，A 有故障期全量數(shù)據(jù)后
3）中心節(jié)點(diǎn)告訴客戶端，客戶端重新把分片 1 請(qǐng)求打回 A 節(jié)點(diǎn)
好處：1）秒級(jí)摘除，恢復(fù)后加回，只需補(bǔ)少量增量數(shù)據(jù)。
? ? ? ? ? ?2）主動(dòng)觸發(fā) Handoff 機(jī)制，靜默升級(jí)：如A 升級(jí)，中心節(jié)點(diǎn)通過(guò)主動(dòng) Handoff 把 A 流量切到 B ，A 升級(jí)后回寫增量 Log，切回流量加入集群
3.2 Cellar 跨地域容災(zāi)
Cellar 跟 Squirrel 跨地域容災(zāi)問(wèn)題一樣，解決方案同樣也是集群間復(fù)制。
北京主集群、上海從：客戶端寫到北京A 節(jié)點(diǎn)，A 正常集群內(nèi)復(fù)制到 B 和 D ，同時(shí)到從的 H。H處理完集群間復(fù)制寫，做集群內(nèi)復(fù)制到I 、K 上。保證最低跨地域帶寬占用。集群間兩個(gè)節(jié)點(diǎn)雙向復(fù)制，達(dá)到雙向同步異地多活
3.3 Cellar 強(qiáng)一致
做好節(jié)點(diǎn)及跨地域容災(zāi)后，業(yè)務(wù)提出更高要求：強(qiáng)一致存儲(chǔ)。
之前異步復(fù)制數(shù)據(jù)，故障摘除時(shí)，可能故障節(jié)點(diǎn)數(shù)據(jù)沒(méi)復(fù)制，導(dǎo)致丟失。支付場(chǎng)景不容許，業(yè)界主流基于 Paxos 或 Raft ，最終選Raft因?yàn)椋?
1）Raft 論文詳實(shí)，工程化高
2）業(yè)界不少成熟Raft 開(kāi)源實(shí)現(xiàn)，可作研發(fā)基礎(chǔ)，縮短研發(fā)周期
Cellar 集群 Raft 復(fù)制模式架構(gòu)圖，中心節(jié)點(diǎn)做 Raft 組調(diào)度，決定每個(gè) Slot 三副本存在哪些節(jié)點(diǎn)上
Slot 1 在存儲(chǔ)節(jié)點(diǎn) 1、2、4 上，Slot 2 在存儲(chǔ)節(jié)點(diǎn)2、3、4上。
每個(gè) Slot 組成一個(gè) Raft 組，客戶端去 Raft Leader 讀寫。
預(yù)分配16384 個(gè) Slot，集群小時(shí)，存儲(chǔ)節(jié)點(diǎn)上有數(shù)百上千個(gè) Slot 。這時(shí)如每個(gè) Raft 復(fù)制組都有自己復(fù)制線程、請(qǐng)求和 Log等，資源消耗大，寫性能很差
解決：Multi Raft 實(shí)現(xiàn)
1）"寫性能"不因 Raft 組過(guò)多變差：Cellar 把同一節(jié)點(diǎn)上所有Raft 復(fù)制組寫一份 Log，用同一組線程復(fù)制，不同 Raft 組間復(fù)制包按照目標(biāo)節(jié)點(diǎn)做整合
2）Raft 任何節(jié)點(diǎn)宕機(jī)，都可選舉新主節(jié)點(diǎn)，但中心節(jié)點(diǎn)仍要管理 Raft 組：
例：集群部分節(jié)點(diǎn)幾輪宕機(jī)恢復(fù)，集群節(jié)點(diǎn)流量很不均衡，因?yàn)楸ＷC數(shù)據(jù)強(qiáng)一致，客戶端讀寫流量又必須發(fā)到 Raft Leader
????如：Slot 1 存儲(chǔ)節(jié)點(diǎn) 1、2、4，1 是 Leader掛了， 2 選成了 Leader。1 恢復(fù)并重新加入集群，中心節(jié)點(diǎn)這時(shí)會(huì)讓 2 把 Leader 還給1 。節(jié)點(diǎn)間 Leader 數(shù)目均衡
看Cellar 如何保證它端到端高成功率。這里講三個(gè)影響成功率問(wèn)題：
????1、2）Cellar 遇到數(shù)據(jù)遷移和熱點(diǎn) Key 問(wèn)題與 Squirrel 一樣，但解決方案不一樣。因?yàn)?Cellar自研，不用考慮與官方版本兼容性，對(duì)架構(gòu)改動(dòng)更大。
????3）慢請(qǐng)求阻塞服務(wù)隊(duì)列導(dǎo)致大面積超時(shí)，這是 Cellar 網(wǎng)絡(luò)、工作多線程模型設(shè)計(jì)下會(huì)遇到不同問(wèn)題
3.4 Cellar 智能遷移
桶的遷移分三個(gè)狀態(tài)：
1、正常(不遷移)：Slot 2 從 A 遷到 B節(jié)點(diǎn)，A 給2 打快照，把快照全量發(fā)到 B 上。
2、遷移時(shí)：B 節(jié)點(diǎn)回包帶回 B 節(jié)點(diǎn)狀態(tài)(引擎的壓力、網(wǎng)卡流量、隊(duì)列長(zhǎng)度等)。A 根據(jù) B 狀態(tài)調(diào)整自己遷移速度。像 Squirrel 一樣，調(diào)整后，遷移速度動(dòng)態(tài)平衡，達(dá)最快遷移，同時(shí)盡可能小影響業(yè)務(wù)正常請(qǐng)求
3、遷移完：進(jìn)入Slot 3 狀態(tài)，客戶端這時(shí)可能沒(méi)更新路由表，當(dāng)請(qǐng)求到A 節(jié)點(diǎn)，會(huì)代理到 B 上，B 響應(yīng)包再返回客戶端。同時(shí)告訴客戶端，更新路由表，解決客戶端路由更新延遲造成請(qǐng)求錯(cuò)誤。
3.5 Cellar 快慢列隊(duì)
下圖上方：標(biāo)準(zhǔn)線程隊(duì)列。網(wǎng)絡(luò)線程池接 收?網(wǎng)絡(luò)流量?解析出 請(qǐng)求包，把請(qǐng)求放工作隊(duì)列，工作線程池會(huì)從工作隊(duì)列取?請(qǐng)求來(lái)?處理，響應(yīng)包放回 網(wǎng)絡(luò)線程池?發(fā)出
一批超時(shí)請(qǐng)求：往往只有一兩個(gè)是引擎處理慢導(dǎo)致，大部分因?yàn)樵?b>隊(duì)列等待過(guò)久。慢只有 1/20
解法：拆線程池、拆隊(duì)列。網(wǎng)絡(luò)線程在收到包之后，根據(jù)請(qǐng)求特點(diǎn)，讀/寫，快/慢，分到四個(gè)隊(duì)列，互不影響
快慢怎么分開(kāi)？Key 數(shù)、Value大小、數(shù)據(jù)結(jié)構(gòu)元素區(qū)分
帶來(lái)問(wèn)題，線程池從一變四，線程數(shù)變四倍？并不是，空閑時(shí)幫其它處理。把服務(wù) TP999 延遲降低 86%，大幅降低超時(shí)率
3.6 Cellar 熱點(diǎn) Key
中心節(jié)點(diǎn)加一職責(zé)：管理熱點(diǎn)數(shù)據(jù)分布，不只負(fù)責(zé)正常分布
1） C、D 放熱點(diǎn)區(qū)域。通過(guò)讀寫看運(yùn)轉(zhuǎn)：寫到A ，處理完，根據(jù)實(shí)時(shí)熱點(diǎn)統(tǒng)計(jì)結(jié)果判斷寫入Key 是否為熱點(diǎn)
2）如是，集群內(nèi)、熱點(diǎn)區(qū)域C、D 同時(shí)復(fù)制。返回時(shí)告訴客戶端，Key 是熱點(diǎn)，客戶端緩存Key。這樣只對(duì)熱點(diǎn)數(shù)據(jù)做擴(kuò)容，不像 Squirrel 整個(gè) Slot 遷出做擴(kuò)容。
3）有必要的話，中心節(jié)點(diǎn)也可把熱點(diǎn)區(qū)域放所有節(jié)點(diǎn)上，熱點(diǎn)讀請(qǐng)求就均衡分。
好處：實(shí)時(shí)熱點(diǎn)數(shù)據(jù)復(fù)制，解決類似客戶端緩存熱點(diǎn) KV 方案一致性問(wèn)題
四、發(fā)展規(guī)劃和業(yè)界趨勢(shì)
按照服務(wù)、系統(tǒng)、硬件三層闡述。
服務(wù)層三點(diǎn)：
1、Redis Gossip 協(xié)議優(yōu)化。Gossip 協(xié)議在集群變大后，消息量劇增，F(xiàn)ailover 時(shí)間變長(zhǎng)。達(dá)到 TB 級(jí)，集群可用性受很大影響，后面做優(yōu)化
2、已經(jīng)Cellar 存儲(chǔ)節(jié)點(diǎn)數(shù)據(jù)副本間做 Raft 復(fù)制，保證強(qiáng)一致，后面在中心點(diǎn)內(nèi)部也做，不依賴zk仲裁、存元數(shù)據(jù)儲(chǔ)了，架構(gòu)變簡(jiǎn)單、可靠
3、Squirrel 和 Cellar 在 SDK 層做整合：雖都是 KV 存儲(chǔ)，但 API 和訪問(wèn)協(xié)議不同，后端不同存儲(chǔ)集群，業(yè)務(wù)側(cè)用一套 SDK 訪問(wèn)
系統(tǒng)層面
調(diào)研并落地Kernel Bypass 技術(shù)，像 DPDK、SPDK 網(wǎng)絡(luò)和硬盤的用戶態(tài) IO 技術(shù)。繞過(guò)內(nèi)核，輪詢?cè)L問(wèn)這些設(shè)備，極大提升系統(tǒng)IO。存儲(chǔ)作為 IO 密集型服務(wù)，性能大幅提升。
硬件層面
1、支持 RDMA 智能網(wǎng)卡能大幅降低網(wǎng)絡(luò)延遲和提升吞吐；還有像 3D XPoint 這樣的閃存技術(shù)，如英特爾新AEP 存儲(chǔ)，訪問(wèn)延遲接近內(nèi)存，以后閃存跟內(nèi)存間的界限變模糊；
2、通過(guò)在閃存上加 FPGA 卡，原本CPU 做(數(shù)據(jù)壓縮、解壓)，下沉到卡上執(zhí)行，解放 CPU, 降低響應(yīng)延遲
https://tech.meituan.com/2020/07/01/kv-squirrel-cellar.html
