背景和需求場景
從最開始擁抱 Hadoop 這些開源的生態，小米就被很多業界人稱為 “HBase 的黃埔軍校”，我們培養了10多個 Commiter 以及 PMC Member，後來張鐸（鐸神）也成為了 HBase 專案的主席，真正實現了我們當年立下的 flag ：
我們的開源理念不僅要站在巨人的肩膀上，還要為巨人指方向。
但是 HBase 這個專案，懂技術的人應當都清楚，它也存在缺陷，因為
JAVA、 GC 造成的延時的不可預測性
，導致在很多場景下其效能不能完全滿足小米以及很多行業內的需求。在很多年前小米還沒有成立廣告部門的時候，我們就已預料到，在分分鐘就能影響上億營收的廣告業務上，HBase 是完全不夠的。
隨著小米的開源之路一點點落地，我們終於在
2015年初內部立項
，決定
自己寫一個高效能的KV系統
。但因當時並沒有精力過多投入，大概只投入了兩個人的人力，歷經兩年多時間才得以完成。當時我稱為“細水長流，長期主義，長線佈局”。直到2017年，Pegasus 才逐步成熟，從馮宏華到覃左言，都為此做出了巨大的貢獻。
Pegasus 於
2017年正式對外開源
。開源之後，我一直在推動將這個專案推薦給 Apache 基金會，推動了很長時間，但因為公司業務發展快，壓力比較大，無法真正提到日程上來。直到去年，非常興奮，這個專案終於成為了 Apache 孵化器的專案！Pegasus 成為小米正式捐獻給國際開源基金會的首個專案，是我們精心打造的一個KV系統，是我們不光要造福小米的業務，也要造福同行的一個專案。
發展歷程
整體而言小米用了5年的時間打造了一個功能完備的KV系統。
產品定位
專案架構
Pegasus系統的整體架構如下圖所示，一共分為四個部分：
ReplicaServer
ReplicaServer主要負責資料儲存和存取，以replica為單位進行服務：
服務的replica既可能是PrimaryReplica，也可能是SecondaryReplica
底層使用RocksDB來儲存資料
管理commit log，並實現replication協議，提供資料一致性保證
MetaServer
MetaServer採用一主多備模式（one master， multiple backups），所有的狀態都會持久化到Zookeeper上；同時透過Zookeeper進行選主。當master故障後，另一臺backup立即搶到鎖，然後從Zookeeper上恢復狀態，成為新的master。MetaServer負責的功能包括：
系統初始化
ReplicaServer的管理
Replica的分配、管理和負載均衡排程
Table的建立與刪除
響應Client請求，向Client提供最新的路由表
Zookeeper
Zookeeper主要有兩個功能：
系統元資訊儲存
MetaServer選主
ClientLib
ClientLib對使用者提供資料儲存介面，特點：
介面簡潔：對使用者提供最簡單的介面，將定址和容錯等細節封裝在內部
配置簡單：使用者只需透過配置檔案指定MetaServer地址列表，就可以訪問叢集，類似於Zookeeper
儘量直接與ReplicaServer進行互動，儘量少地訪問MetaServer以避免熱點問題，不依賴Zookeeper
功能和效能
功能指令
：並沒有全部相容redis協議，提供了自定義的SDK
資料熱備
：採用了典型的主從資料複製策略
BulkLoad
大資料生態
：支援Spark任務，但是怎麼和Hive打通？
效能：5臺機器，單條KV ~1KB。
混合讀寫效能
從這個結果來看，有很多LSM KV系統的通用問題還沒有解決：
寫聚合能力並不是十分的突出，可能是與強一致三副本的配置有關。
客戶端大吞吐資料的支援沒有寫明效能？
業務資料多版本如何支援？
KV系統的Compaction產生的毛刺如何最佳化？
Spark 任務是SDK online 讀寫，如何離線匯出？
直連如何支援平滑升級？
跨雲多活的多寫多讀沒有支援？
其他與補充
MetaProxy僅負責代理客戶端與MetaServer的路由表資訊請求，即客戶端僅在首次連線或者重建連線的時候與其進行通訊，後續與ReplicaServer之間的資料讀寫操作都是直連，因此不存在因為代理而影響讀寫延遲的情況。況且，在實際部署時MetaProxy要和目標叢集部署在同一個Region下，即使首次連線也不會帶來明顯的延遲效能開銷。
在小米內部，我們同時提供了ZK資料更新的API工具，以支援在建表/刪表的時候，包括切換主備結群的時候，更新目標表的叢集資訊
MetaProxy的使用限制是：在同一目標區域的所有叢集中，不能存在相同的表名，否則僅根據接入地址+表名並不能判斷到底該訪問哪個叢集。在實際的實踐過程中，我們假定：由於主備容災往往是建在不同的區域，如北京和天津，因此為所有北京叢集和所有天津叢集區域各部署一個MetaProxy服務，不同區域可以存在相同的表名互為主備關係，但是同一區域的叢集不能存在同名表。
Pegasus的部分客戶端如C++，Python暫時還不支援域名，此類客戶端在使用MetaProxy時可以透過IP：Port的形式接入。
應用實踐
未來計劃
參考
https：//pegasus。apache。org/overview/
