pika集群水平擴展之怎么讓性能容量不再受限

這篇文章主要講解了“pika集群水平擴展之怎么讓性能容量不再受限”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“pika集群水平擴展之怎么讓性能容量不再受限”吧！

背景

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模塊。

集群部署結構

以3個pika節點的集群為例，集群部署結構如上圖所示：

1. 部署Etcd集群作為pika manager的元信息存儲。

2. 3臺物理機上分別部署pika manager，并配置好Etcd的服務端口。Pika manager會向etcd注冊，并爭搶成為leader。集群中有且只有一個pika manager能夠成為leader并向etcd中寫入集群數據。

3. 3臺物理機上分別部署pika節點，然后把pika節點的信息添加到pika manager中。

4. 為了負載均衡，把pika的服務端口注冊到LVS中。

數據分布

為了對數據按照業務進行隔離，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的使用。

數據處理

1. 當pika節點接收到用戶請求時，解析層處理解析redis協議，并把解析好的結果交給router層進行判斷。

2. router根據key的hash結果找到key對應的slot，并判斷slot是否在本地節點上。

3. 如果key所在的slot在其他節點，則根據請求創建一個task放入隊列中，并把請求轉發給peer節點來處理。當task接收到請求的處理結果后把請求返回給客戶端。

4. 如果key所在的slot屬于本地節點，就直接本地處理請求并返回給客戶端。

5. 對于需要本地處理的寫請求，先通過replication manager模塊寫binlog，異步復制到其他slot副本。process layer根據一致性的要求，寫入leader slot。其中blackwidow是對rocksdb的接口封裝。

我們把proxy內嵌的pika中，不需要單獨部署。與redis cluster相比，客戶端不需要感知proxy的存在，只需像使用單機一樣使用集群。可以把pika節點的服務端口掛載到LVS中，實現壓力在整個集群的負載均衡。

日志復制

pika中replication manager模塊負責日志的主從同步。為了兼容redis，pika支持非一致日志復制，leader slot直接在db中寫入數據而無需等待從follower slot的ack應答。同時也支持raft一致性協議方式的日志復制，需要滿足收到大多數副本的ack才寫入db。

非一致日志復制

在非一致場景下處理流程如下：

1. 處理線程接收到客戶端的請求，直接加鎖后寫入binlog和并操作db。

2. 處理線程返回客戶端response。

3. 輔助線程發送BinlogSync同步請求給follower slot，同步日志。

4. follower slot返回BinlogSyncAck報告同步情況。

一致性日志復制

在一致性日志復制場景下：

1. 處理線程把客戶端請求寫入binlog文件

2. 通過發送BinlogSync請求向從庫同步

3. 從庫返回BinlogSyncAck報告同步狀況

4. 檢查從庫應答滿足大多數后將相應的請求寫入db

5. 將response返回客戶端

集群元數據處理

我們在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的高可用。

感謝各位的閱讀，以上就是“pika集群水平擴展之怎么讓性能容量不再受限”的內容了，經過本文的學習后，相信大家對pika集群水平擴展之怎么讓性能容量不再受限這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！