記憶體需求增大，Redis Cluster成本太高，怎麼辦？

前段時間，筆者在知乎上發現了一個提問“如何評價360開源的pika專案?”，原提問者面臨的問題是：一直在使用Redis，但隨著記憶體需求增大，轉redis cluster怕成本太高，通過調研，排除近一年沒有commit和issue的開源項目，

只剩下ssdb和360開源的pika可供選擇，這種情況下應該如何選擇呢?

筆者認為大家不妨帶著這個問題看看陳宗志的分享吧，看完再決定應該如何取捨!

Redis是一個key-value存儲系統，因為其對支援存儲的value類型相對更多，並且開源社區的維護工作一直不錯，所以有不少用戶在使用和學習。

當對記憶體的需求逐漸增大，Redis也會開始出現各種問題，比如恢復時間長—50G redis恢復時間70分鐘，一主多從, 主從切換代價大—主庫掛掉後升級從庫, 所有從庫全部重傳資料，緩衝區寫滿，記憶體太貴......

這時，你一定會開始思考解決方案，什麼樣的方式能讓你既享受到Redis的便利，又可以規避其問題呢?陳宗志所在團隊想到了開發Pika，就這樣，來自360的DBA和基礎架構團隊一起設計開發了這個大容量Redis解決方案。

據悉，目前的Pika完全相容Redis 協定, 使用者不需要修改任何代碼進行遷移。其中的網路模組Pink是由基礎架構團隊開發, 網路程式設計庫支援pb, redis, pg, http等協定。同時，抽象出各種不同類型執行緒。

Pink在穩定性、易用性和高性能方面很好的補充了Redis的不足。

存儲引擎模組Nemo基於Rocksdb實現。實現了Hash，List，Set，Zset等資料結構。日誌模組Binlog可順序寫檔，通過Index+offset進行同步檢查，解決了緩衝區小的問題，支持全同步和增量同步。主從同步是slaveof模組。由於整個項目已經在Github上開源良久，因此開發者可自行查看原始程式碼，目前該項目已獲得了1000+的Star。

經過360團隊和開源社區的共同努力，Pika日漸完善，修復了很多問題。陳宗志表示，如果使用期間出現秒刪問題，

可以修改Rocksdb, 增加 version, timestamp 欄位。刪除只需要修改metadata。資料compact問題，可以修改Rocksdb manual compact策略，支持低優先順序的manual compact，根據機型調整rocksdb配置，compac執行緒，memtable個數。資料備份問題則需要rocksdb和Binglog的配合。Pika目前現狀是雙主支援、Pika_hub 提供多機房、寫入支援、支援sentinel和codis。

現在，整個團隊已經給出了Pika與Rdis，Ssdb向Pika遷移的工具。陳宗志多次強調，Pika的出現不是為了替代Redis，而是為了彌補Redis的不足。由於Pika是基於記憶體和檔來存放資料, 所以性能肯定比Redis低一些。對於一些資金不足的公司而言，

Pika確實是一個性價比十分高的解決方案。

▲更多資訊盡在IT168現場報導專題 http://sacc.it168.com/topic201