KV 存儲
在大數據時代，數據量呈指數級增長，預計到2025年，全球的數據總量將達175ZB，非結構化和半結構化數據已占據主導地位。像騰訊微信、字節頭條、B站、快手、小紅書等眾多的UGC社交平臺，這些平臺普遍的都存在搜索、推薦、廣告和風控服務都以人為核心，服務強依賴用戶的畫像、行為和筆記。UGC數據的高效存儲和查詢是支持推廣搜一體化工程的基礎設施，而這種典型的屬性和值的鍵值對結構正式我們今天要討論的分布式KV系統。
KV存儲系統對非結構化和半結構化數據進行高效存儲，提供了很好的解決方案：
- KV存儲系統具有靈活的數據模型，數據表示為Key, Value對形式，為任意數據類型，且長度不定；
- KV存儲的訪存接口非常簡單，向外提供Put、Get、Scan等簡單的接口進行數據讀寫；
- KV存儲還具備高可擴展性，數據基于Key進行劃分和索引，無需維護額外的元數據。
由于KV存儲系統具有上述諸多優點，因此被廣泛應用在了NewSQL和NoSQL產品中。比如目前常見的KV存儲系統：LevelDB、RocksDB、Cassandra、TiKV等。
目前主流的持久化KV存儲系統都采用LSM-tree（log-structured merge tree）架構作為存儲引擎，其具有高效的寫入效率，但同時存在嚴重的讀寫放大問題。
如圖，KV數據首先緩存在內存并進行排序，然后以批量追加的方式將數據寫入磁盤上，形成磁盤上的一個SSTable文件，SSTable文件中的數據是按Key有序的，這種寫入方式可以將大量的隨機寫轉換為順序寫，從而充分利用磁盤順序寫的帶寬優勢，獲得高效的寫入效率。
為兼顧讀性能，磁盤上的數據被組織成多層形式，且容量逐層遞增，并且除第0層以外，其他每層的數據是完全有序的。通過維護這樣一個多層有序的架構，LSM-tree可以獲得高效的寫入和范圍查詢性能，并且提供高可擴展性，當需要擴展存儲容量時，可以通過簡單的增加LSM-tree的層數來實現高效的擴展。
然而，LSM-tree多層的數據組織結構導致查詢操作需要逐層搜索，從第0層開始，直到找到查詢的數據為止，并且寫入期間需要執行頻繁的Compaction操作，具體Compaction操作需要從LSM-tree中讀取相鄰兩層的數據，然后執行合并排序操作，再將合并后的有效數據寫回磁盤。因此，當我們將數據從第0層逐漸合并到較高層時，需要將數據頻繁的讀出并且寫回，進而導致嚴重的讀寫放大問題，且嚴重消耗磁盤的IO帶寬。
數據分片策略：當前流行的KV存儲產品對Key的劃分方法有兩種：
- 將Key的空間劃分成多個Partition/Shard。連續的Key在同一個Partition/Shard內，或者跨兩個Partition。
- 創建一定數目的Partition/Shard。將Key hash打散到不同的Partition/Shard上。
那如何評價一個KV產品是否足夠優秀呢，筆者認為可以從以下特性功能進行對比評價：
- 數據的可靠性SLA
- 服務穩定性SLA
- 讀寫性能
- 大規模集群的彈性原地擴縮容能力
- 服務平滑升級的不可用時間（毛刺）
- 支持與大數據生態互通（在線、離線）
- 跨云多活（多區多Region)
KV系統對外提供的接口比較統一，即點查、范圍查詢。而當今作為LSM-Tree最穩定、應用最廣泛即最成熟的引擎就是Rocksdb。
RocksDB 是由 Facebook 基于 google LevelDB 開發的一款提供鍵值存儲與讀寫功能的 LSM-tree 架構引擎。用戶寫入的鍵值對會先寫入磁盤上的 WAL (Write Ahead Log)，然后再寫入內存中的跳表（SkipList，這部分結構又被稱作 MemTable）。LSM-tree 引擎由于將用戶的隨機修改（插入）轉化為了對 WAL 文件的順序寫，因此具有比 B 樹類存儲引擎更高的寫吞吐。
內存中的數據達到一定閾值后，會刷到磁盤上生成 SST 文件 (Sorted String Table)，SST 又分為多層（默認至多 6 層），每一層的數據達到一定閾值后會挑選一部分 SST 合并到下一層，每一層的數據是上一層的 10 倍（因此 90% 的數據存儲在最后一層）。
RocksDB 允許用戶創建多個 ColumnFamily ，這些 ColumnFamily 各自擁有獨立的內存跳表以及 SST 文件，但是共享同一個 WAL 文件，這樣的好處是可以根據應用特點為不同的 ColumnFamily 選擇不同的配置，但是又沒有增加對 WAL 的寫次數。
互聯網KV 產品
小米 Pegasus - 2015 ★
小米云平臺長期以來一直使用開源的Apache HBase來存儲結構化/半結構化數據，但是HBase并不是十全十美的，它的架構、語言、實現等決定了它具有一些難以克服的不足：
- HBase實現采用的JAVA語言，雖然開發上效率比較高，但是運行性能并不如C/C++這樣的語言。
- Java GC時可能造成進程進入假死狀態，導致Region Server無法提供讀寫服務，造降低系統可用性。
- HBase宕機恢復時間比較長（分鐘級），在這段時間內服務是不可用的。其原因是：
- HBase數據存儲在分布式文件hdfs上，上層的RegionServer僅僅是服務點。為了保證數據一致性，HBase要求每個Region在同一時刻只能由一個RegionServer服務。當某個RegionServer宕機，必須選一個新的RegionServer來服務該Region。恢復過程中需要做較多處理，包括日志的傳輸、切分、重放，這個過程比較耗時。
- HBase依賴ZooKeeper來探測宕機問題，而由于Java的GC問題存在，Zookeeper的session timeout不能設得太短，典型地設為30秒。如果設得太短，Java GC的假死機就容易造成session超時，觸發RegionServer不必要的自殺。因此從RegionServer宕機到被發現，這中間可能就需要幾十秒。
- HBase的分層架構使數據服務點和存儲位置分離，對Data Locality不夠友好，也是影響其讀性能的一個原因。
以上這些原因造成了HBase的可用性和性能都存在一些不足，難以滿足對服務可用性和延遲都很敏感的一些在線業務的需求，譬如廣告業務。
從2015年開始，小米開始開發Pegasus系統。Pegasus系統的整體架構如下圖所示，一共分為四個部分：
ReplicaServer
ReplicaServer主要負責數據存儲和存取，以replica為單位進行服務：服務的replica既可能是PrimaryReplica，也可能是SecondaryReplica。底層使用RocksDB來存儲數據管理commit log，并實現replication協議，提供數據一致性保證
MetaServer
MetaServer：MetaServer采用一主多備模式（one master, multiple backups），所有的狀態都會持久化到Zookeeper上；同時通過Zookeeper進行選主。當master故障后，另一臺backup立即搶到鎖，然后從Zookeeper上恢復狀態，成為新的master。
MetaServer負責的功能包括：
- 系統初始化
- ReplicaServer的管理
- Replica的分配、管理和負載均衡調度
- Table的創建與刪除
- 響應Client請求，向Client提供最新的路由表
Zookeeper
系統元信息存儲
MetaServer選主
ClientLib
ClientLib對用戶提供數據存儲接口
接口簡潔：對用戶提供最簡單的接口，將尋址和容錯等細節封裝在內部
配置簡單：用戶只需通過配置文件指定MetaServer地址列表，就可以訪問集群，類似于Zookeeper
盡量直接與ReplicaServer進行交互，盡量少地訪問MetaServer以避免熱點問題，不依賴Zookeeper
騰訊 Tendis - 2015/8 ★
Tendis 是集騰訊眾多海量 KV 存儲優勢于一身的 redis 存儲解決方案, 并 100% 兼容 Redis 協議和 Redis4.0 所有數據模型。作為一個高可用、高性能的分布式 KV 存儲數據庫, 從訪問時延、持久化需求、整體成本等不同維度的考量, Tendis 推出了 緩存版 、 混合存儲版 和 存儲版 三種不同產品形態，并將存儲版開源。
在版本迭代過程中，不斷的業務接入，成為游戲業務和平臺業務的主存儲。
Tendis存儲版集群架構★
Tendis存儲版使用去中心化集群架構，每個數據節點都擁有全部的路由信息。
- 用戶可以訪問集群中的任意節點，并且通過redis的MOVE協議，最終路由到正確的節點。
- 每個Tendis存儲版節點維護屬于各自的slot數據，任意兩個master節點之間的slot不重復
- Tendis存儲版的主備節點之間通過binlog進行復制
- 任意兩個節點之間通過gossip協議進行通訊
- master節點之間支持基于slot的數據搬遷
Tendis存儲節點采用單進程多實例的部署形態，默認單進程使用10個rocksdb實例。
Key采用Hash打散的方式分片存儲在KvStore中，每個KvStore是一個單進程多實例的Rocksdb。
Tendis存儲版 vs 其他開源實現 ★
- 完全兼容redis cluster訪問和管理模式的類redis存儲方案
- 完善的運維和管理指令，info，slaveof等管理指令完全兼容
- 命令兼容度高，幾乎所有命令和redis語義保持一致
- 強大的數據搬遷能力，支持數據在節點中的隨意搬遷，不影響原服務。
- 強大的集群自治管理能力，支持自動failover，故障自動恢復等，運維成本低
360 PiKa 2015/11 ★
Pika是一個可持久化的大容量redis存儲服務，兼容string、hash、list、zset、set的絕大部分接口(兼容詳情)，解決redis由于存儲數據量巨大而導致內存不夠用的容量瓶頸，并且可以像redis一樣，通過slaveof命令進行主從備份，支持全同步和部分同步，pika還可以用在twemproxy或者codis中來實現靜態數據分片（pika已經可以支持codis的動態遷移slot功能，目前在合并到master分支。
PiKa 2種模式 ★
經典模式（Classic）： 即1主N從同步模式，1個主實例存儲所有的數據，N個從實例完全鏡像同步主實例的數據，每個實例支持多個DBs。DB默認從0開始，Pika的配置項databases可以設置最大DB數量。DB在Pika上的物理存在形式是一個文件目錄。
分布式模式（Sharding）： Sharding模式下，將用戶存儲的數據集合稱為Table，每個Table切分成多個分片，每個分片稱為Slot，對于某一個KEY的數據由哈希算法計算決定屬于哪個Slot。將所有Slots及其副本按照一定策略分散到所有的Pika實例中，每個Pika實例有一部分主Slot和一部分從Slot。在Sharding模式下，分主從的是Slot而不再是Pika實例。Slot在Pika上的物理存在形式是一個文件目錄。
Pika可以通過配置文件中的instance-mode配置項，設置為classic和sharding，來選擇運行經典模式（Classic）還是分布式模式（Sharding）的Pika。
美團 Cellar 2015 ★
Squirrel：基于Redis Cluster(2015 年發布)，演進出全內存、高吞吐、低延遲的 KV 存儲。
迭代：自研和社區并重，盡量兼容官方。
應用：數據量小，對延遲敏感
Cellar：基于 Tair，演進出持久化、大容量、數據高可靠KV 存儲。
迭代：完全靠自研。和 Squirrel 在解決同樣的問題時也選取了不同的設計方案。
應用：數據量大，對延遲不特別敏感
目前美團內部每天的調用量均已突破萬億，請求峰值突破每秒億級
Cellar持久化KV架構 ★
跟阿里開源的 Tair 主要有兩個架構上的不同。第一個是OB，第二個是 ZooKeeper。我們的 OB 跟 ZooKeeper 的 Observer 是類似的作用，提供 Cellar 中心節點元數據的查詢服務。它可以實時與中心節點的 Master 同步最新的路由表，客戶端的路由表都是從 OB 去拿。 這樣做的好處主要有兩點：
第一，把大量的業務客戶端跟集群的大腦 Master 做了天然的隔離，防止路由表請求影響集群的管理。
第二，因為 OB 只供路由表查詢，不參與集群的管理，所以它可以進行水平擴展，極大地提升了我們路由表的查詢能力。
另外，我們引入了 ZooKeeper 做分布式仲裁，解決我剛才提到的 Master、Slave 在網絡分割情況下的“腦裂”問題，并且通過把集群的元數據存儲到 ZooKeeper，我們保證了元數據的高可靠。
Celler功能 ★
Cellar 節點容災
如果 A 節點宕機了，會觸發 Handoff 機制，這時候中心節點會通知客戶端 A節點發生了故障，讓客戶端把分片 1 的請求也打到 B 上。B 節點正常處理完客戶端的讀寫請求之后，還會把本應該寫入 A 節點的分片 1&2 數據寫入到本地的 Log 中。
如果 A 節點宕機后 3~5 分鐘，或者網絡抖動 30~50 秒之后恢復了，A 節點就會上報心跳到中心節點，中心節點就會通知 B 節點：“ A 節點恢復了，你去把它不在期間的數據傳給它。”這時候，B 節點就會把本地存儲的 Log 回寫到 A 節點上。等到 A 節點擁有了故障期間的全量數據之后，中心節點就會告訴客戶端，A 節點已經徹底恢復了，客戶端就可以重新把分片 1 的請求打回 A 節點。
通過這樣的操作，我們可以做到秒級的快速節點摘除，而且節點恢復后加回，只需補齊少量的增量數據。另外如果 A 節點要做升級，中心節點先通過主動 Handoff 把 A 節點流量切到 B 節點，A 升級后再回寫增量 Log，然后切回流量加入集群。這樣通過主動觸發 Handoff 機制，我們就實現了靜默升級的功能。
Cellar 跨地域容災
以下圖一個北京主集群、上海從集群的跨地域場景為例，比如說客戶端的寫操作到了北京的主集群 A 節點，A 節點會像正常集群內復制一樣，把它復制到 B 和 D 節點上。同時 A 節點還會把數據復制一份到從集群的 H 節點。H 節點處理完集群間復制寫入之后，它也會做從集群內的復制，把這個寫操作復制到從集群的 I 、K 節點上。通過在主從集群的節點間建立這樣一個復制鏈路，我們完成了集群間的數據復制，并且這個復制保證了最低的跨地域帶寬占用。同樣的，集群間的兩個節點通過配置兩個雙向復制的鏈路，就可以達到雙向同步異地多活的效果。
Cellar 強一致
目前業界主流的解決方案是基于 Paxos 或 Raft 協議的強一致復制。我們最終選擇了 Raft 協議。主要是因為 Raft 論文是非常詳實的，是一篇工程化程度很高的論文。業界也有不少比較成熟的 Raft 開源實現，可以作為我們研發的基礎，進而能夠縮短研發周期。
下圖是現在 Cellar 集群 Raft 復制模式下的架構圖，中心節點會做 Raft 組的調度，它會決定每一個 Slot 的三副本存在哪些節點上。
Cellar 智能遷移
Cellar 快慢列隊
拆線程池、拆隊列。我們的網絡線程在收到包之后，會根據它的請求特點，是讀還是寫，快還是慢，分到四個隊列里。讀寫請求比較好區分，但快慢怎么分開？我們會根據請求的 Key 個數、Value大小、數據結構元素數等對請求進行快慢區分。然后用對應的四個工作線程池處理對應隊列的請求，就實現了快慢讀寫請求的隔離。這樣如果我有一個讀的慢請求，不會影響另外三種請求的正常處理。不過這樣也會帶來一個問題，我們的線程池從一個變成四個，那線程數是不是變成原來的四倍？其實并不是的，我們某個線程池空閑的時候會去幫助其它的線程池處理請求。所以，我們線程池變成了四個，但是線程總數并沒有變。我們線上驗證中這樣的設計能把服務 TP999 的延遲降低 86%，可大幅降低超時率。
Cellar 熱點 Key
中心節點加了一個職責，多了熱點區域管理，它現在不只負責正常的數據副本分布，還要管理熱點數據的分布，圖示這個集群在節點 C、D 放了熱點區域。我們通過讀寫流程看一下這個方案是怎么運轉的。如果客戶端有一個寫操作到了 A 節點，A 節點處理完成后，會根據實時的熱點統計結果判斷寫入的 Key 是否為熱點。如果這個 Key 是一個熱點，那么它會在做集群內復制的同時，還會把這個數據復制有熱點區域的節點，也就是圖中的 C、D 節點。同時，存儲節點在返回結果給客戶端時，會告訴客戶端，這個 Key 是熱點，這時客戶端內會緩存這個熱點 Key。當客戶端有這個 Key 的讀請求時，它就會直接去熱點區域做數據的讀取。
滴滴Fusion 2016★
Fusion 是滴滴自研的分布式 NoSQL 數據庫，完全兼容 Redis 協議，支持超大規模數據持久化和高性能讀寫。在滴滴內部支撐了數百個業務，具有 PB 級別的數據存儲量，是使用最廣泛的主存儲服務之一。在支持滴滴業務高速發展過程中，積累了很多分布式存儲領域的經驗，孵化了離線到在線的高速數據導入方案、NewSQL 方案、跨機房同步等，一路解決了 Redis 容量限制、 離線數據在線打通、數據庫擴展性差、異地多活容災等問題。
Fusion架構 ★
采用 hash 分片的方式來做數據 sharding。從上往下看，用戶通過 Redis 協議的客戶端（jedis、redigo、hiredis 等）就可以訪問 Fusion，首先會經過 VIP 做負載均衡，然后轉發到具體 proxy，再由 proxy 轉發數據到后端 Fusion 的數據節點。proxy 到后端數據節點的轉發，是根據請求的 key 計算 hash 值，然后對 slot 分片數取余，得到一個固定的 slotid，每個 slotid 會固定的映射到一個存儲節點，以此解決數據路由問題。
FastLoad - 離線灌數據 ★
在FastLoad 服務器上，創建一個 DTS 任務，該任務會在 Hadoop 配置中心注冊一個調度任務（周期性或一次性，由用戶決定），然后 FastLoad 服務器根據用戶上傳的數據存儲路徑或 Hive 表（我們支持的數據源有：HDFS 上的 JSON 文件和 Hive 結構的數據），按照用戶提交的拼 key 方式，我們啟動 map/reduce 任務直接構造 Fusion 底層存儲在文件系統上的文件 SST，并把它們構造好相互之間的排序，避免重復，構造好后通知 Fusion 存儲節點，下載 SST 文件，然后 load 到 Fusion 數據庫中。此后，用戶就可以通過 Redis-Client 訪問我們幫它加載的數據了。
此外，Fusion 還支持二級索引和多區數據復制
新浪LaserDB - 2019★
LaserDB 是微博設計開源的高性能分布式 KV 數據庫，在滿足傳統 KV 存儲的高性能的基礎上，提供了大容量分布式存儲解決方案。 并且為了滿足大數據、人工智能特征模型快速加載更新，LaserDB 原生支持了快速批量、增量導入功能，LaserDB 不僅可以滿足一般 的工程業務應用，并且很好的支撐了機器學習模型、特征數據存儲需求。
LaserDB 整體架構★
深入了解 LaserDB 的整體架構可以更好的使用、運維 LaserDB, LaserDB 主要包括三大核心組件：Laser Server, Laser Client 和 Laser Control, 此外還有適配 Redis 協議的 Laser Proxy 以及滿足數據批量導入的 Laser Transform。在具體部署時用戶可以根據自己的需求選擇部署 Laser Proxy 和 Laser Transform
Laser Server
LaserDB 的存儲服務核心組件，負責接收 thrift 請求并且處理對應的請求。除了負責對外的服務請求處理以外，還負責具體的數據存儲、數據分片、數據同步等功能
Laser Control
負責集群數據表、數據表配置以及集群分片信息的管理，提供分片可視化、動態擴容、動態縮容
Laser Client
主要是負責和 Server 進行接口交互，并且實現 LaserDB 整體請求路由機制，對 Server 端提供的 API 接口進行封裝，實現 mget, mset 等批量操作的客戶端層并行化, 目前提供 C++, Golang 版本的 SDK 可以直接 與 Laser server 交互獲得更好的性能，其他語言的業務可以選擇 Laser Proxy 代理，最終通過 redis 客戶端操作
Laser Proxy
Laser Proxy 主要是負責實現 Redis 協議的大部分常用命令支持，Proxy 通過調用 Laser Client 與 Laser Server 交互，對于 Proxy 來說是一個完全無狀態的服務，可以將 Proxy 當做一個存儲容量特別大的 Redis server 來看 。對于原有業務是 Redis 的，獲取不方便直接使用 Laser Client SDK 調用的業務場景可以選用
Laser Proxy
Laser Transform
Laser Transform 主要是負責實現數據的批量導入功能，對于有數據快速批量導入的需求，需要部署 Laser Transform 服務，并且 Laser Server 環境需要有 hdfs 客戶端支持，Transform 服務主要負責定時調度提交 MapReduce 任務，將原始格式的數據轉化為 Laser Server 可以識別的數據
字節ABase 2016★
自 2016 年以來，為了支撐在線推薦的存儲需求而誕生的——字節跳動自研高可用 KV 存儲 Abase，逐步發展成支撐包括推薦、廣告、搜索、抖音、西瓜、飛書、游戲等公司內幾乎所有業務線的 90% 以上的 KV 存儲場景，已成為公司內使用最廣泛的在線存儲系統之一。ABase2 2019年替換ABase1
ABase2架構 ★
Abase2 的整體架構主要如上圖所示，在用戶、管控面、數據面三種視角下主要包含 5 組核心模塊。
RootServer
線上一個集群的規模大約為數千臺機器，為管理各個集群，我們研發了 RootServer 這個輕量級組件。顧名思義，RootServer 擁有全集群視角，它可以更好地協調各個集群之間的資源配比，支持租戶在不同集群之間的數據遷移，提供容災視圖并合理控制爆炸半徑。
MetaServer
Abase2 是多租戶中心化架構，而 MetaServer 則是整個架構的總管理員，它主要包括以下核心功能：
- 管理元信息的邏輯視圖：包括 Namespace，Table，Partition，Replica 等狀態和配置信息以及之間的關系；
- 管理元信息的物理視圖：包括 IDC，Pod，Rack，DataNode，Disk，Core 的分布和 Replica 的位置關系；
- 多租戶 QoS 總控，在異構機器的場景下根據各個租戶與機器的負載進行副本 Balance 調度；
- 故障檢測，節點的生命管理，數據可靠性跟蹤，在此基礎上進行節點的下線和數據修復。
物理視圖
邏輯視圖
DataNode
DataNode 是數據存儲節點。部署時，可以每臺機器或者每塊盤部署一個 DataNode，為方便隔離磁盤故障，線上實際采用每塊盤部署一個 DataNode 的方式。
DataNode 的最小資源單位是 CPU Core（后簡稱 Core），每個 Core 都擁有一個獨立的 Busy Polling 協程框架，多個 Core 共享一塊盤的空間與 IO 資源。
一個 Core 包含多個 Replica，每個 Replica 的請求只會在一個 Core 上 Run-to-Complete，可以有效地避免傳統多線程模式中上下文切換帶來的性能損耗。
Replica 核心模塊如下圖所示，整個 Partition 為 3 層結構：
- 數據模型層：如上文提到的 String, Hash 等 Redis 生態中的各類數據結構接口。
- 一致性協議層：在多主架構下，多點寫入勢必會造成數據不一致，Anti-Entropy 一方面會及時合并沖突，另一方面將協調沖突合并后的數據下刷至引擎持久化層并協調 WAL GC。
- 數據引擎層：數據引擎層首先有一層輕量級數據暫存層（或稱 Conflict Resolver）用于存儲未達成一致的數據；下層為數據數據引擎持久化層，為滿足不同用戶多樣性需求，Abase2 引設計上采用引擎可插拔模式。對于有順序要求的用戶可以采用 RocksDB，TerarkDB 這類 LSM 引擎，對于無順序要求點查類用戶采用延遲更穩定的 LSH 引擎。
Client/Proxy/SDK
Client 模塊是用戶側視角下的核心組件，向上提供各類數據結構的接口，向下一方面通過 MetaSync 與 MetaServer 節點通信獲取租戶 Partition 的路由信息，另一方面通過路由信息與存儲節點 DataNode 進行數據交互。此外，為了進一步提高服務質量，我們在 Client 的 IO 鏈路上集成了重試、Backup Request、熱 Key 承載、流控、鑒權等重要 QoS 功能。
結合字節各類編程語言生態豐富的現狀，團隊基于 Client 封裝了 Proxy 組件，對外提供 Redis 協議（RESP2)與 Thrift 協議，用戶可根據自身偏好選擇接入方式。此外，為了滿足對延遲更敏感的重度用戶，我們也提供了重型 SDK 來跳過 Proxy 層，它是 Client 的簡單封裝。
DTS (Data Transfer Service)
DTS 主導了 Abase 生態系統的發展，在一二代透明遷移、備份回滾、Dump、訂閱等諸多業務場景中起到了非常核心的作用，由于篇幅限制，本文不做更多的詳細設計敘述。
小紅書RedKV - 2019★
小紅書是年輕人的生活記錄、分享平臺，用戶可以通過短視頻、圖文等形式記錄生活點滴，分享生活方式。在當前的業務模型下，用戶的畫像數據和筆記數據用來做風險控制和內容推薦。存儲數據具有對象-屬性的特征、維度多，畫像數據量已經達到數十TB， 在線業務對畫像和筆記數據的訪問P99 時延要求非常高。
RedKV2 架構 ★
RedKV整體架構分3層，接入層兼容Redis協議，支持各種語言的社區版SDK和公司定制的中間件版；接入代理層支持千萬QPS的讀寫能力，無狀態擴展；存儲層提供高可靠讀寫服務。
Client接入層
RedKV集群部署完成后，通過公司內部提供的Service Mesh組件做服務發現，對Client提供服務。
Proxy
Proxy層由一個無狀態CorvusPlus進程組成。它兼容老的Redis Client，擴縮容、升級對無Client和后端集群無感，支持多線程、IO多路復用和端口復用特性。對比開源版本，CorvusPlus增強了自我防護和可觀測特性，實現了可在線配置的功能特性：
- Proxy限流
- 數據在線壓縮
- 線程模型優化
- backup-read優化長尾
- 大key檢測
基于Shard管理的中心架構能更好的支持數據遷移和集群擴縮容，存儲節點采用單進程多實例部署，在多活場景中可以支持副本數彈性擴展。
關鍵特性 ★
數據復制
與傳統解決方案引入同步組件的方式不同，我們快速實現了單向數據同步以及集群擴容需求，整體架構去除了對第三方組件的依賴，通過擴展Redis復制協議實現了RedKV數據節點的直接復制，如圖10。單向復制的限制是擴容需要基于做節點同步，擴容完成后后臺任務根據3.3.3中定義的key的分片刪除不是本節點的數據。
在多活的部署形態下，多云集群的一對多的數據復制采用單向復制對主集群性能侵入較大，因此我們實現了基于中心管控的數據復制策略。該策略支持多個集群的分片異構部署，通過Checkpoint方式定向同步數據，不再需要額外的后臺任務去做數據淘汰，能很好的支持多對多的多云集群數據復制、數據破環和擴縮容。
數據批量導入
小紅書大量的離線業務數據存儲在S3 Hive中，每天會有部分數據需要增量更新，其他的數據會被淘汰。這類場景有幾個挑戰：
- 批量導入：如小紅書的筆記數據，一般需要小時級別甚至天級別的更新，所以業務需要有快捷的批量導入功能。
- 快速更新：特征數據的特點就是數據量特別大，以筆記為例，全量筆記在TB 級別數據量。如果通過 Jedis SDK 寫入，那么存儲集群需要支持百萬QPS的機器資源。當下小紅書數據平臺支持業務把數據從hive通過工作流直接導入RedKV，一般是每天凌晨開始寫數據，等到晚高峰時大量讀取。這種方法實踐下來，經常導致 RedKV集群的集群內存OOM，影響穩定性。
- 性能及穩定：數據在導入的過程中不能影響讀的性能
數據批量導出
小紅書的業務模型訓練數據通過Hash存儲在RedKV集群中，業務下游需要對訓練結果進行離線分析，希望RedKV具有和Hive數據流通的能力。RedKV本身是不支持Schema的，如果要將KV數據導入Hive表，則需要將Hash的KKV數據轉化為一個Table。
RedKV的內部數據按hash打散，導入Hive表則需要提供table關鍵字，先按前綴掃描的方式掃描存儲節點，再生成Hive識別的文件，最后通過Hive Load進行加載。為了更好的兼容其他spark任務，我們選擇Hive支持的標準parquet列式存儲文件
B站KV 2019★
在B站的業務場景中，存在很多種不同模型的數據，有些數據關系比較復雜像：賬號、稿件信息。有些數據關系比較簡單，只需要簡單的kv模型即可滿足。此外，又存在某些讀寫吞吐比較高的業務場景，該場景早期的解決方案是通過MySQL來進行數據的持久化存儲，同時通過redis來提升訪問的速度與吞吐。但是這種模式帶來了兩個問題，其一是存儲與緩存一致性的問題，該問題在B站通過canal異步更新緩存的方式得以解決，其二則是開發的復雜度，對于這樣一套存儲系統，每個業務都需要額外維護一個任務腳本來消費canal數據進行緩存數據的更新。基于這種場景，業務需要的其實是一個介于Redis與MySQL之間的提供持久化高性能的kv存儲。此外對象存儲的元數據，對數據的一致性、可靠性與擴展性有著很高的要求。
基于此背景，我們對自研KV的定位從一開始就是構建一個高可靠、高可用、高性能、高拓展的系統。對于存儲系統，核心是保證數據的可靠性，當數據不可靠時提供再高的可用性也是沒用的。可靠性的一個核心因素就是數據的多副本容災，通過raft一致性協議保證多副本數據的一致性。
整體架構 ★
整個系統核心分為三個組件:
Metaserver用戶集群元信息的管理，包括對kv節點的健康監測、故障轉移以及負載均衡。
Node為kv數據存儲節點，用于實際存儲kv數據，每個Node上保存數據的一個副本，不同Node之間的分片副本通過raft保證數據的一致性，并選出主節點對外提供讀寫，業務也可以根據對數據一致性的需求指定是否允許讀從節點，在對數據一致性要求不高的場景時，通過設置允許讀從節點可以提高可用性以及降低長尾。
Client模塊為用戶訪問入口，對外提供了兩種接入方式，一種是通過proxy模式的方式進行接入，另一種是通過原生的SDK直接訪問，proxy本身也是封裝自c++的原生SDK。SDK從Metaserver獲取表的元數據分布信息，根據元數據信息決定將用戶請求具體發送到哪個對應的Node節點。同時為了保證高可用，SDK還實現了重試機制以及backoff請求。
部署形態
集群的拓撲結構包含了幾個概念，分別是Pool、Zone、Node、Table、Shard 與Replica。
- Pool為資源池連通域，包含多個可用區。也可用于業務資源隔離域。
- Zone為可用區，同一個pool內部的zone是網路聯通并且故障隔離的。通常為一個機房或者一個交換機
- Node為實際的物理主機節點，負責具體的數據存儲邏輯與數據持久化。
- Table對應到具體的業務表，類似MySQL里的表。
- Shard為邏輯分片，通過將table分為多個shard將數據打散分布。
- Replica為shard的副本，同一個shard的不同副本不能分布在同一個zone，必須保證故障隔離。每一個replica包含一個engine，engine存儲全量的業務數據。engine的實現包含rocksdb和sparrowdb。其中sparrowdb是針對大value寫放大的優化實現。
關鍵特性 ★
binlog支持(多活)
類似于MySQL的binlog，我們基于raftlog日志實現了kv的binlog. 業務可以根據binlog進行實時的事件流訂閱，同時為了滿足事件流回溯的需求，我們還對binlog數據進行冷備。通過將binlog冷備到對象存儲，滿足了部分場景需要回溯較長事件記錄的需求。
直接復用raftlog作為用戶行為的binlog，可以減少binlog產生的額外寫放大，唯一需要處理的是過濾raft本身的配置變更信息。learner通過實時監聽不斷拉取分片產生的binlog到本地并解析。根據learner配置信息決定將數據同步到對應的下游。同時binlog數據還會被異步備份到對象存儲，當業務需要回溯較長時間的事件流的時候，可以直接指定位置從S3拉取歷史binlog進行解析。
分區分裂
基于不同的業務場景，我們同時支持了range分區和hash分區。對于range場景，隨著用戶數據的增長，需要對分區數據進行分裂遷移。對于hash分區的場景，使用上通常會根據業務的數據量做幾倍的冗余預估，然后創建合適的分片數。
bulk load
離線平臺只需要根據kv的存儲格式離線生成對應的SST文件，然后上傳到對象存儲服務。kv直接從對象存儲拉取SST文件到本地，然后直接加載SST文件即可對外提供讀服務。bulk load的另外一個好處是可以直接在生成SST后離線進行compaction，將compaction的負載offload到離線的同時也降低了空間的放大。
有贊ZanKV★
在有贊早期的時候，當時只有 MySQL 做存儲，codis 做緩存，隨著業務發展，某些業務數據用 MySQL 不太合適， 而 codis 由于當緩存用， 并不適合做存儲系統， 因此， 急需一款高性能的 NoSQL 產品做補充。考慮到當時運維和開發人員都非常少， 我們需要一個能快速投入使用， 又不需要太多維護工作的開源產品。 當時對比了幾個開源產品， 最終選擇了 aerospike 作為我們的 KV 存儲方案。
然而隨著有贊的快速發展， 單純的 aerospike 集群慢慢開始無法滿足越來越多樣的業務需求。 雖然性能和穩定性依然很優秀， 但是由于其索引必須加載到內存， 對于越來越多的海量數據， 存儲成本會居高不下。 更多的業務需求也決定了我們將來需要更多的數據類型來支持業務的發展。 為了充分利用已有的 aerospike 集群， 并考慮到當時的開源產品并無法滿足我們所有的業務需求， 因此我們需要構建一個能滿足有贊未來多年的 KV 存儲服務。
整體架構 ★
設計目標：
- 在設計這樣一個能滿足未來多年發展的底層 KV 服務， 我們需要考慮以下幾個方面:
- 需要盡量使用有大廠背書并且活躍的開源產品， 避免過多的工作量和太長的周期
- 避免完全依賴和耦合一個開源產品， 使得無法適應未來某個開源產品的不可控變化， 以及無法享受將來的技術迭代更新和升級
- 避免使用過于復雜的技術棧， 增加后期運維成本
- 由于業務需要， 我們需要有能力做方便的擴展和定制
- 未來的業務需求發展多樣， 單一產品無法滿足所有的需求， 可能需要整合多個開源產品來滿足復雜多樣的需求
- 允許 KV 服務后端的技術變化的同時， 對業務接口應該盡量穩定， 后繼升級不應該帶來過多的遷移成本。
自研 ZanKV 有如下特點:
- 使用Go語言開發， 利用其高效的開發效率， 也能減少后期維護難度， 方便后期定制。
- 使用大廠且成熟活躍的開源組件 etcd raft，RocksDB 等構建， 減少開發工作量
- CP 系統和現有 aerospike 的 AP 系統結合滿足不同的需求
- 提供更豐富的數據結構
- 支持更大的容量， 和 aerospike 結合在不損失性能需求的前提下大大減少存儲成本
自研 ZanKV 的整體架構圖如下所示:
整個集群由 placedriver + 數據節點 datanode + etcd + rsync 組成。 各個節點的角色如下:
- PD node: 負責數據分布和數據均衡， 協調集群里面所有的 zankv node 節點， 將元數據寫入 etcd
- datanode: 負責存儲具體的數據
- etcd: 負責存儲元數據， 元數據包括數據分布映射表以及其他用于協調的元數據
- rsync: 用于傳輸 snapshot 備份文件
AppleFoundationDB★
整體架構 ★
如圖所示，FDB 的架構中規中矩，大的模塊可以分成三部分：
- 客戶端接口 Client
- 控制平面 Control Plane
- 數據平面 Data Plane
Control Plane
Control Plane 負責管理集群的元數據，使用 Active Disk Paxos 來保證高可用。Control Plane 分成以下幾個部分：
- Coordinator：幾個 coordinator 進程組成一個 paxos group，其中有一個 leader，稱為 cluster controller。Cluster controller 負責故障檢測，管理各種進程的角色，匯集、傳遞整個集群的各種信息。同時，cluster controller 是整個集群訪問的入口點。Client 通過一個保存有 coordinator 的 IP:Port 的配置文件訪問集群，并從 cluster controller 獲取最新的 proxy 列表。
- DataDistributor：DataDistributor 負責監控 StorageServer 的故障情況和數據的平衡調度。
- Ratekeeper：Ratekeeper 通過控制單調遞增時間戳的分配速度來進行過載保護。
Data Plane
Data Plane 大體上可以劃分成三大部分：
- Transaction System 負責實現 serializable snapshot isolation 級別的分布式事務。
- Log System 負責日志的復制，保證系統的高可用。
- Storage System 保存實際數據，或者說狀態機，會從 Log System 異步拉取日志進行 apply。目前單機存儲引擎是使用一個修改過的 SQLite。
Transaction System 較為復雜，大體上可以分層三個模塊：
- Proxy 作為事務系統面向 client 的代理接口，事務請求都需要通過 proxy 獲取 read version，獲取 key ranges 對應的 storage server 的信息，提交事務。
- Sequencer 負責分配遞增的 read version 和 commit version。
- Resolver 負責 SSI 級別的事務沖突檢測。
另外FDB還支持事務特性，這個需要閱讀論文區詳細理解，這里不在展開
AWS DynamoDB - 2004★
Amazon DynamoDB 是一種完全托管的 NoSQL 數據庫服務，提供快速而可預測的性能，能夠實現無縫擴展。DynamoDB 可以從表中自動刪除過期的項，從而幫助您降低存儲用量，減少用于存儲不相關數據的成本。
DynamoDB工作原理 ★
DynamoDB 架構
在DynamoDB中核心組件是表、項目和屬性。表是項目的集合，項目是屬性的集合，DynamoDB使用主鍵來標識表中的每個項目，還提供了二級索引來提供更大的查詢靈活性，還可以使用DynamoDB流來捕獲DynamoDB表中的數據修改事件。
表、項目和屬性：
- 表 DynamoDB將數據存儲在表中，表是某類數據的集合，例如People表、Cars表。
- 項目 每個表包含多個項目，項目是一組屬性，具有不同于所有其他項目的唯一標識，項目類似與SQL中的行、記錄或元組。
- 屬性 每個項目包含一個或多個屬性，屬性是基本的數據元素，屬性類似與SQL中的字段或列。
People表示例
DynamoDB未開源，可參考的2篇論文：
- Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Inte.NET Scale Applications.
- https://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html
- Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service: https://www.usenix.org/system/files/atc22-elhemali.pdf
- https://www.infoq.cn/article/aEUY5kcI1a3iqGUyGzUy
