如何評價360開源的pika專案？

1樓：

測試過，作為redis爆量後解決方案的備選優先肯定是加記憶體拉，反正公司有錢，多加些redis例項嘛沒有深入研究，但是看到中國產有這樣的開源專案，無論如何還是支援的雖然我們都不太喜歡360這個公司

2樓：WastonYuan

關於pika的多執行緒我也想說一下，他是根據鏈結來分配執行緒的，也就是說如果你只有乙個客戶端即使執行緒配置再多依然只有乙個執行緒在幹活，架構上就存在瓶頸（不合理？）

而且起各個功能的執行緒很多，資源浪費還是不小的，也不能保證某些執行緒一直工作。

加鎖的地方很多，還要用到pipe等一些執行緒通訊協作手段，對比下predixy就非常簡潔，依然是epoll多執行緒，然而沒加鎖，更沒用pipe

3樓：

畢竟redis快的原因其一就是直接記憶體資料，必然要用記憶體，不用記憶體的優勢，那你應該考慮MongoDB。或者你應該考慮你的redis存了那些冗餘資料。

4樓：

上面亂噴的受不了了。。

針對上面各種質疑

使用rocksdb實現redis資料結構複雜度高是必然，但是大部分時間複雜度是和redis一致的，當然速度要慢，O(N)對於磁碟和記憶體，差距肯定存在。

當然你覺得你可以做得更好show me you code

有人提到20個worker，rocksdb都是磁碟操作，block的api，不使用多執行緒你寫乙個看看？畢竟redis資料操作全記憶體，單個io執行緒完成大部分的事情

page cache + block cache + ssd為rocksdb提供了可以滿足海量資料讀寫的需求，有多少人redis tps維持10w/s的？當然如果你的redis集群沒有超過50g(舉個例子)建議就不要考慮遷移到基於磁碟的儲存上。

pika或者類似的產品不是萬金油，需要放在合適的場景上，很多人其實接觸不到上百G的redis集群根本不能理解這種方案的存在的意義。

pika並不完美，集群，穩定性，api相容程度，但是希望他們能走的更遠。雖然我是個360黑，但是對pika團隊真的很敬佩，我記得我在研究rocksdb時候看到過他們成員寫的部落格，真的很棒，可以說是國內研究資料中最深入的了。

利益相關:

本人與pika無交集，非pika使用者，長期潛水pika使用者群。

研究過pika和nemo

深入研究過ssdb

5樓：babayetu liu

線上三個場景在使用，供你參考：

用來快取storm job加工後的大量中間資料。

儲存一些導購短文，讀操作為主。

聚合資訊的唯讀展示，用於取代堆外快取。

場景1,2執行的比較平穩。3在測試中，超過50k的key查詢略慢。

場景2生產環境訪問量qps 5000

場景3生產環境峰值訪問量qps 30萬

6樓：kkchen

如果不是使用強一致性協議，那麼用rocksdb的keyvalue基礎上建立的list，map，zset等結構是不可靠（亂序，大小，值不一致都可能）。而且也沒有對帳服務，建議學習一下就好，不建議線上用。

7樓：姚維

pika是前同事寫的。基於rocksdb上面相容了redis的協議，ssdb 是基於 leveldb，rocksdb對於 leveldb 有很多的改進。並且 pika 團隊的人對於 rocksdb 玩的還是挺溜的。

pika 在360跟很多公司應該都已經用的很歡了。

所以推薦你看看。