女主宣言
Pika是一個可持久化的大容量redis存儲服務，兼容string、hash、list、zset、set的絕大部分接口(兼容詳情)，解決redis由於存儲數據量巨大而導致內存不夠用的容量瓶頸。由於單機pika容量受限於單塊硬盤容量的大小，360公司業務和社區對分佈式pika集羣的需求越來越強烈，因此我們推出了原生分佈式pika集羣，發佈pika版本v3.4。本文主要講述pika原生集羣架構和數據處理等內容。
PS：豐富的一線技術、多元化的表現形式，盡在“360雲計算”，點關注哦！
1
背景
Pika是一個可持久化的大容量redis存儲服務，兼容string、hash、list、zset、set的絕大部分接口(兼容詳情)，解決redis由於存儲數據量巨大而導致內存不夠用的容量瓶頸。用戶可以不修改任何代碼從redis遷移到pika服務。具有良好的兼容性和穩定性，被360公司內部使用超過3000實例，github社區超過3.8K star。由於單機pika容量受限於單塊硬盤容量的大小，360公司業務和社區對分佈式pika集羣的需求越來越強烈，因此我們推出了原生分佈式pika集羣,發佈pika版本v3.4。與pika+codis集羣方案相比，codis對pika創建和管理slot操作的支持並不友好，需要運維人員大量介入，而pika原生集羣則不需要額外部署codis-proxy模塊。
2
集羣部署結構
以3個pika節點的集羣爲例，集羣部署結構如上圖所示：
部署Etcd集羣作爲pika manager的元信息存儲。
3臺物理機上分別部署pika manager，並配置好Etcd的服務端口。Pika manager會向etcd註冊，並爭搶成爲leader。集羣中有且只有一個pika manager能夠成爲leader並向etcd中寫入集羣數據。
3臺物理機上分別部署pika節點，然後把pika節點的信息添加到pika manager中。
爲了負載均衡，把pika的服務端口註冊到LVS中。
3
數據分佈
爲了對數據按照業務進行隔離，Pika集羣引入table的概念，不同的業務數據存儲在不同的table中。業務數據按照key的hash值存儲到對應的slot上面。每一個slot會有多個副本，從而形成一個replication group。replication group中的所有slot副本具有相同的slot ID，其中一個slot副本是leader，其他副本爲follower。爲了保證數據的一致性，只有leader提供讀寫服務。可以使用pika manager對slot進行調度遷移，使數據和讀寫壓力均勻的分散到整個pika集羣中，從而保證了整個集羣資源的充分利用並且可以根據業務壓力和存儲容量的需要進行水平擴容和縮容。
pika使用rocksdb作爲存儲引擎，每個slot會創建對應的rocksdb。pika中的每個slot都支持讀寫redis 5種數據結構。因此數據遷移的時候會特別方便，只需遷移pika中的slot即可。但同時也存在資源佔用過多的問題。目前的pika在創建slot的時候會默認創建5個rocksdb，分別來存儲5種數據結構。在table中含有大量slot或者創建大量table的時候會使單個pika節點含有多個slot，進而創建過多的rocksdb實例，佔用了過多系統資源。在後續版本中一方面會支持創建slot的時候根據業務需要創建一種或多種數據結構，另一方面會持續對pika中的blackwidow接口層進行優化，減少對rocksdb的使用。
4
數據處理
當pika節點接收到用戶請求時，解析層處理解析redis協議，並把解析好的結果交給router層進行判斷。
router根據key的hash結果找到key對應的slot，並判斷slot是否在本地節點上。
如果key所在的slot在其他節點，則根據請求創建一個task放入隊列中，並把請求轉發給peer節點來處理。當task接收到請求的處理結果後把請求返回給客戶端。
如果key所在的slot屬於本地節點，就直接本地處理請求並返回給客戶端。
對於需要本地處理的寫請求，先通過replication manager模塊寫binlog，異步複製到其他slot副本。process layer根據一致性的要求，寫入leader slot。其中blackwidow是對rocksdb的接口封裝。
我們把proxy內嵌的pika中，不需要單獨部署。與redis cluster相比，客戶端不需要感知proxy的存在，只需像使用單機一樣使用集羣。可以把pika節點的服務端口掛載到LVS中，實現壓力在整個集羣的負載均衡。
5
日誌複製
pika中replication manager模塊負責日誌的主從同步。爲了兼容redis，pika支持非一致日誌複製，leader slot直接在db中寫入數據而無需等待從follower slot的ack應答。同時也支持raft一致性協議方式的日誌複製，需要滿足收到大多數副本的ack才寫入db。
非一致日誌複製
在非一致場景下處理流程如下：
處理線程接收到客戶端的請求，直接加鎖後寫入binlog和並操作db。
處理線程返回客戶端response。
輔助線程發送BinlogSync同步請求給follower slot，同步日誌。
follower slot返回BinlogSyncAck報告同步情況。
一致性日誌複製
在一致性日誌複製場景下：
處理線程把客戶端請求寫入binlog文件
通過發送BinlogSync請求向從庫同步
從庫返回BinlogSyncAck報告同步狀況
檢查從庫應答滿足大多數後將相應的請求寫入db
將response返回客戶端
6
集羣元數據處理
我們在codis-dashboard的基礎上二次開發了pika manager（簡稱PM），作爲整個集羣的全局控制節點，用來部署和調度管理集羣。PM裏保存了整個集羣的元數據及路由信息。
增加了集羣創建多表的功能，方便業務根據表的不同來實現業務數據隔離。
支持創建表時指定slot數目和副本數目，方便運維根據業務的規模和故障容忍度創建table。
從邏輯上把group的概念改爲replication group，使得原來的進程級別的數據和日誌複製轉變爲slot級別的複製。
支持創建table時創建密碼來隔離業務的使用。客戶端只需要執行auth和select語句就可以認證並對指定的table進行操作。
支持slot遷移，方便根據業務需求進行擴容和縮容。
集成哨兵模塊，PM會不斷的向集羣中的pika節點發送心跳，監測存活狀態。當PM發現leader slot down時，會自動提升binlog偏移最大的slave slot爲leader。
存儲後端支持元數據寫入etcd，保證元數據的高可用。
pika manager通過不斷向etcd爭搶鎖來成爲leader，來實現pika manager的高可用。
7
後記
pika原生集羣的推出解決了單機pika受限於磁盤容量的限制，可以按照業務的需求進行水平擴容。但仍然有一些缺陷，如基於raft的內部自動選主功能的缺失，基於range的數據分佈，及監控信息的展板等功能。後續版本我們會一一解決這些問題。
360雲計算
由360雲平臺團隊打造的技術分享公衆號，內容涉及數據庫、大數據、微服務、容器、AIOps、IoT等衆多技術領域，通過夯實的技術積累和豐富的一線實戰經驗，爲你帶來最有料的技術分享
