Pika-持久化的大容量Redis存儲服務

2020-08-21 軟體架構

一、Pika簡介

Pika 是360 DBA和基礎架構組聯合開發的類Redis 存儲系統, 完全支持Redis協議。Pika的出現並不是為了替代Redis，而是Redis的場景補充。


Pika是一個可持久化的大容量Redis存儲服務，兼容String、Hash、List、ZSet、Set的絕大部分接口，解決Redis由於存儲數據量巨大而導致內存不夠用的容量瓶頸。

Pika基於Rocksdb開發的大容量類Redis存儲，通過持久化存儲方式解決Redis在大容量場景下主從同步代價高、恢復時間慢、單線程相對脆弱、內存成本高等問題。

Github地址:

https://github.com/Qihoo360/pika


特點：

  • 容量大，支持百G數據量的存儲。
  • 兼容Redis，不用修改代碼即可平滑從Redis遷移到Pika。
  • 支持主從(slaveof)。
  • 完善的運維命令。

適用場景：

如果業務場景的數據比較大，Redis 很難支撐， 比如大於50G。或者業務數據很重要，不允許斷電丟失，那麼使用Pika 就可以解決你的問題。而在實際使用中，Pika的性能大約是Redis的50%。


二、Pika 整體架構

主要組成:

1. 網絡模塊 pink-對網絡編程的封裝，支持Redis協議。

2. 線程模塊-基於pink對線程進行封裝，使用多個工作線程來進行讀寫操作，由底層 nemo 引擎來保證線程安全。

3. 存儲引擎 nemo-基於 Rocksdb 修改，封裝 Hash, List, Set, Zset 等數據結構。

4. 日誌模塊 binlog-Pika的主從同步是使用Binlog來完成的。Binlog 本質是順序寫文件，通過Index + offset 進行同步點檢查。


存儲引擎為什麼沒有選擇 LevelDB 呢，另外市面上有類似的方案如 ssdb，有什麼不同之處嗎？

關於存儲引擎的選擇，在 LevelDB、RocksDB 上面做過對比。LevelDB，RocksDB 在數據量比較小的時候性能差異不大，但是在數據量比較大的情況下，比如 200G 的時候，RocksDB 的性能會比 LevelDB 要來得好。

RocksDB 作為一個繼承了 LevelDB 衣缽的 key-value 資料庫，使用和 LevelDB 一樣的 LSM Tree（Log Structured Merge Trees）來存儲數據，同時允許高度靈活的配置，從而可以應對各種不同的應用場景與需求。

三、Pika部署方案

為了減少用戶的學習成本，目前 Pika 的主從同步功能是和 Redis 完全一樣，只需要 slaveof 就可以實現主從關係的建立，使用起來非常方便。

目前，Pika支持主從結構，也支持Codis。Pika 從3.2.0版本之後支持sharding mode。

Pika 具有兩種運行模式： 經典模式（Classic） & 分布式模式（Sharding）。

（1）經典模式（Classic）： 即1主N從同步模式，1個主實例存儲所有的數據，N個從實例完全鏡像同步主實例的數據，每個實例支持多個DBs。DB默認從0開始，Pika的配置項databases可以設置最大DB數量。DB在Pika上的物理存在形式是一個文件目錄。

（2）分布式模式（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。

Pika 目前並沒有使用類似 Redis 的Sentinel，Pika 前面是掛 LVS 來負責主從切換。

（此處已添加圈子卡片，請到今日頭條客戶端查看）

四、社區用戶

目前已知用戶有：360，新浪微博，garena 遊戲，apus，萬達飛凡網，美團網，學而思教育，小米，環信，58 同城，迅雷，高偉達，第一彈社區，億瑪科技等。

在 360 內部使用情況，粗略的統計如下：目前已有1000+實例，每天訪問量900億，存儲容量18T。


五、Pika的優勢及不足

Pika相對於Redis，最大的不同就是Pika是持久化存儲，數據存在磁碟上，而Redis是內存存儲，由此不同也給Pika帶來了相對於Redis的優勢和劣勢。

優勢：

  • 容量大：Pika沒有Redis的內存限制，最大使用空間等於磁碟空間的大小。
  • 加載DB速度快：Pika 在寫入的時候，數據是落盤的，所以即使節點掛了, 不需要rdb或者aof，Pika 重啟不用重新加載數據到內存而是直接使用已經持久化在磁碟上的數據，不需要任何數據回放操作（除去少量Rocksdb自身的recover），這大大降低了重啟成本。
  • 備份速度快：Pika備份的速度大致等同於複製的速度，更快的備份速度更好的解決了主從的全同步問題。

劣勢:

  • 由於Pika是基於內存和文件來存放數據, 所以性能肯定比Redis低一些, 但是我們一般使用SSD盤來存放數據, 儘可能跟上Redis的性能。在實際使用中，大多數場景下Pika的性能大約是Redis的50%~80%。


六、小結

Pika與Redis是使用場景上互相補充的關係。目前線上的Pika機器都使用的SSD，一般場景下ops在5w以內場景都能輕鬆應對。

Pika的設計初衷其實就是為滿足業務在Redis存儲中，因為內存不足而造成業務損失，所以，Pika的命令基本與Redis保持一致，並且Client也是復用Redis的，這樣，業務從Redis切換到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 slot遷移
    後來了解到pika數據存儲在磁碟裡面，而且兼容redis協議及命令，可以掛載在codis proxy後面做server，這樣既保留codis proxy的高性能，又能解決TB級數據量的存儲成本問題。但pika還不支持codis的slot遷移，當壓力上漲時，擴容是個問題。通過研究codis及pika的實現，在pika上開發實現了codis的slot遷移。
  • 你不知道的redis三-Redis的持久化機制
    一、持久化我們前兩章已經講了，redis是內存型的資料庫，他之所以快是因為數據存儲在內存。那麼數據存儲在內存會有什麼問題呢？當然就是當服務重啟或者伺服器宕機內存數據就被清除，我們就無法訪問之前存儲的數據了。那麼怎麼解決這個問題呢？
  • Redis持久化及Redis集群
    Redis默認是不使用該方式持久化的。Aof方式的持久化，是操作一次redis資料庫，則將操作的記錄存儲到aof持久化文件中。第一步：開啟aof方式的持久化方案將redis.conf中的appendonly改為yes，即開啟aof方式的持久化方案。
  • Redis的持久化操作
    當redis正常運行時,定期的將數據保存到磁碟中,當redis伺服器重啟時,則根據配置文件中指定的持久化的方式,實現數據的恢復.在內存中保存數據.如果一直存儲,則內存數據必然溢出.所以需要定期維護內存數據的大小.
  • Redis持久化策略
    1 持久化概論1.1 什麼是持久化redis所有數據保持在內存中，對數據的更新將異步地保存到磁碟上。持久化主要是做災難恢復、數據恢復，可歸類到高可用。若你把Redis的持久化做好，備份和恢復方案也做到，那麼即使你的Redis故障，也可通過備份數據，快速恢復，一旦恢復立即對外提供服務1.2 持久化方式Redis提供了兩種持久化方式：
  • Redis持久化
    Redis持久化就是將內存中的數據寫入磁碟，可以避免因某些故障導致的數據丟失，它支持rdb快照和aof文件兩種持久化機制。RDB持久化rdb保存支持同步阻塞(save)和異步非阻塞(bgsave)兩種方式：1 客戶端執行save命令時，當文件較大時就需要較長時間來完成rdb文件的保存，在此過程中，redis將不能提供服務，即redis服務不可用；2 客戶端執行bgsave命令時，當前的主進程會fork出一個子進程來完成快照文件保存
  • Redis 持久化
    Redis 所有的數據和狀態存儲在內存中，為了避免進程退出而導致數據丟失，需要將數據和狀態保存到硬碟上。為了達到這一目的，通常有兩種實現方式：將 Redis 當作一個狀態機，記錄每一次的對 Redis 的操作，也就是狀態轉移。
  • Redis單機資料庫持久化與過期建刪除
    簡言作為一名程序猿，redis已經是我們接觸最多的緩存工具之一，它的應用面很廣，那麼大家是否對他真的有些了解呢，對於antirez大神的想法我也是算不上略懂一二，再此知識簡單談談關於redis的一些小事redis的存儲結構首先讓我們來了解一下redis的存儲結構（廢話不多說，直接上圖）這張圖很好地說明了Redis是如何存儲的，我們知道redis
  • Redis持久化之AOF持久化
    首先，需要開啟AOF持久化功能，這裡為了測試，我們把原有的配置文件redis.conf複製一份，命名為redis_aof.conf，然後修改appendonly 為yes，其餘配置不變利用此配置文件啟動redis服務啟動redis服務因為不是後臺啟動服務
  • Redis教程:Redis持久化方式
    當Redis 啟動時， 如果 RDB 持久化和 AOF 持久化都被打開了， 那麼程序會優先使用 AOF 文件來恢復數據集， 因為AOF 文件所保存的數據通常是最完整的。AOF VS RDBRDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲.
  • redis學習(四)鍵空間數據持久化
    2、雖然持久化損耗性能但是他做了數據持久化，如果出現redis服務crash情況則重啟時會通過持久化的數據來恢復歷史數據而如果沒有做持久化則如果redis服務出現crash則所有數據都會丟失。3、redis提供了三種持久化方式，是否要開啟持久化功能、以及持久化方式、寫磁碟策略其實都是取決於具體業務場景，性能損耗也是最直接的表現。
  • redis的兩種持久化的機制，我又有了全新的認識
    redis提供了兩種持久化的機制 RDB和AOF機制RDB(redis Database):RDB保存某一個時間點之前的快照數據。AOF(Append-Only File):指所有的命令行記錄以redis命令請求協議的格式完全持久化存儲保存為aof文件混合持久化(4.0版本以後)：指進行AOF重寫時，子進程將當前時間點的數據快照保存為RDB文件格式，而後將父進程累計命令保存為AOF格式。
  • Redis持久化方式
    眾所周知，redis是內存資料庫，在運行期間會將所有數據加載到內存中，所以如果不把數據落到磁碟的話，redis進程一旦被停掉，數據就會全部丟失。例如：（redis持久化已關閉，看下情況）。一開始redis裡面有多個key存在，關掉重啟之後，數據都已丟失。
  • 騰訊開源分布式存儲系統 Tendis,可完全兼容 Redis
    據悉，Tendis 是騰訊互娛 CROS DBA 團隊 & 騰訊雲資料庫團隊自主設計和研發的分布式高性能 KV 存儲資料庫，兼容 Redis 核心數據結構與接口，可提供大容量、低成本、強持久化的資料庫能力，適用於兼容 Redis 協議、需要大容量且較高訪問性能的溫冷數據存儲場景。Tendis 目前已經被應用到騰訊內、外部大型項目中。
  • Redis持久化和備份
    Redis與其他key-value存儲庫的不同之一是Redis運行在內存中但是可以持久化到磁碟，我們來看看Redis 持久化的相關方式。Redis 持久化在了解Redis持久化前，我們先來看看數據損壞的概念來幫助我們更好的理解後續的問題。
  • Redis持久化之RDB持久化
    如果Redis實例的內存比較大，那麼阻塞時間會比較長，一般線上不使用；bgsave命令：save的升級版本，bg表示後臺運行。使用此命令後，Redis進程會執行fork操作，創建一個子進程，由子進程執行RDB持久化工作，而主進程仍然可以接受客戶端的命令。
  • Redis RESP 協議與 AOF 持久化有什麼關係?
    然後問 Redis 的兩種持久化方式，我說與 RDB 和 AOF 兩種方式，RDB 數據文件小，恢復速度快，但是對性能有影響，而且不適合實時存儲。而 AOF 是現在最常用的持久化方式，它的一大優點就是實時性，並且對 Redis 半身性能影響最小。那面試又問了，你知道 AOF 持久化之後的文件是什麼格式嗎？
  • Redis 持久化之 RDB 與 AOF 詳解
    Redis 持久化我們知道Redis的數據是全部存儲在內存中的，如果機器突然GG，那麼數據就會全部丟失，因此需要有持久化機制來保證數據不會因為宕機而丟失。Redis 為我們提供了兩種持久化方案，一種是基於快照，另外一種是基於 AOF 日誌。接下來就來了解一下這兩種方案。