前言

本文旨在闡述關于Redis數據庫發展的一些思考，包括如何以較低成本自主研發Redis數據庫以及商業化實踐的相關考慮。文章首先介紹Redis官方社區的發展狀況，開源的Redis相關產品，最后闡述筆者對Redis數據庫發展的觀點。

redis官方開源協議

redis labs在3.20日宣布，項目的開源協議發生了重大改變，從非常寬松的BSD許可證轉為Redis源代碼可用許可證(RSALv2)和服務器端公共許可證(SSPLv1)下雙重許可。BSD許可證是一種寬松的開源許可證，而新的許可證則更加嚴格。RSALv2許可證允許用戶查看、修改和分發Redis的源代碼，但限制了商業化使用，特別是禁止將軟件作為管理服務提供給他人，并且要求保留所有許可、版權和其他聲明。SSPLv1要求任何在服務端運行的衍生作品都必須以相同的許可證開源，并且不得以專有軟件形式提供。

因此，新許可證要求托管Redis產品的云服務提供商不再被允許免費使用Redis源代碼（從redis 7.4版本開始），除非與Redis公司達成許可協議。這意味著合作可能需要支付一些費用。那么想用最新版本的特性，是否一定要跟Redis官方合作呢？不一定。現在有很多開源的Redis競品，其本身的開源社區和開源協議都比較友好，在這基礎上自研可能是一種好的思路。

開源redis競品

KeyDB

優點

● 7.6kstar，最近更新2個月前

● 多線程架構，完全兼容redis協議

特性

● 多線程架構，核心哈希表的訪問由spinlock保護

● jemalloc優化內存管理

● KeyDB完全兼容Redis協議

● 在相同的硬件上，KeyDB可以實現比Redis高得多的吞吐量

多線程介紹

KeyDB的多線程處理涉及到網絡IO、命令的解析和部分命令的執行階段。

在KeyDB中，網絡IO和命令的解析是由多個線程并行處理的。當客戶端發送請求到KeyDB時，網絡IO線程負責接收和發送數據，而命令的解析則由解析線程負責。解析線程將接收到的命令解析為相應的數據結構，并將其放入到命令隊列中等待處理。

另外，KeyDB的多線程模型還涉及到部分命令的執行階段。具體來說，KeyDB使用了多個工作線程來執行部分命令。這些命令通常是不涉及數據競爭的，可以并行執行的命令，例如GET、SET等操作。通過將這些命令的執行分發到多個工作線程，KeyDB可以提高命令的并發處理能力和響應速度。

然而，對于涉及到數據競爭的命令，例如涉及到同一鍵的操作，KeyDB會使用鎖機制來保證數據的一致性，以避免并發訪問導致的問題。

需要注意的是，并非所有的命令都能夠完全并行處理，因為某些命令的執行涉及到特定的順序或操作依賴關系。在這些情況下，KeyDB可能需要等待前一個命令的執行完成才能執行下一個命令。

綜上所述，KeyDB的多線程處理包括網絡IO、命令的解析和部分命令的執行階段。通過并行處理這些階段，KeyDB可以提高并發處理能力和響應性能。

pika(PikiwiDB)

優點

● 5.1kstar，GitHub代碼保持最近更新

● 性能跟redis相比，略差點，但也很高，99.9% get/set在2ms以內，測試環境為：

● 多個互聯網公司投入使用

● pika可結合twemproxy或者codis中實現靜態數據分片

● 支持主從，分布式模式

● 容量大：基于rocksdb，持久化存儲，數據存在磁盤上，最大使用空間等于磁盤空間的大小，可解決由于存儲數據量巨大而導致內存不夠的容量瓶頸

● 加載db速度快：Pika在寫入的時候, 數據是落盤的, 所以即使節點掛了, 不需要rdb或者oplog，Pika重啟不用加載所有數據到內存就能恢復之前的數據, 不需要進行回放數據操作。

● 備份速度快：Pika備份的速度大致等同于cp的速度（拷貝數據文件后還有一個快照的恢復過程，會花費一些時間），這樣在對于百G大庫的備份是快捷的，更快的備份速度更好的解決了主從的全同步問題

● 完全支持redis協議，不用修改代碼即可平滑從Redis遷移到Pika

● 兼容string，hash，list，set的絕大部分接口

● 支持主從備份，支持全同步和部分同步

● 完善的運維命令

● Pika 是多線程的結構，因此在線程數比較多的情況下，某些數據結構的性能可以優于 Redis

● 部署模式：1主N從同步模式和分布式模式

劣勢

由于Pika是基于內存和文件來存放數據, 所以性能肯定比Redis低一些, 但是我們一般使用SSD盤來存放數據, 盡可能跟上Redis的性能

使用場景

如果你的業務場景的數據比較大，Redis 很難支撐， 比如大于50G，或者你的數據很重要，不允許斷電丟失，那么使用Pika 就可以解決你的問題。

攜程Redis-On-Rocks

特點

● 分層存儲，冷熱分離，冷數據存放在rocksdb上，熱數據存放到redis中

● 內存達到最大內存限制，swap out， least frequently used key(LFU)將數據交換到RocksDB（磁盤）

● ROR采用磁盤增加了緩存容量，能容納更多的數據量，但RocksDB引擎的compaction和壓縮會消耗更多的CPU資源，因此ROR可以認為是用空閑的CPU換內存的成本解決方案。

優點

● 分層存儲，成本方面，經驗數據顯示1個ROR實例可容納3個redis實例的數據，因此redis遷ROR能節省2/3的成本

● 跟隨redis社區更新

缺點

● swap會有代價

● 延時會有上升，以下為一個典型redis集群遷移ROR后延遲對比，其中80%為冷數據、20%為熱數據，遷移前后客戶端訪問延遲從200us變為220us左右。

kvrocks

開源協議友好，KVRocks 項目遵循的開源協議是 Apache License Version 2.0。這意味著 Kvrocks 允許用戶自由地使用、修改和分發該軟件，同時需要遵守該許可證的條款，比如保留版權聲明、不使用 Apache 名稱進行宣傳等。Apache License 2.0 是一種寬松的開源許可證，它允許商業使用，并且不需要公開派生作品的源代碼。

優點

Redis 協議兼容：KVRocks 兼容 Redis 協議，這意味著它可以無縫對接現有的 Redis 客戶端，無需修改代碼即可遷移。

高可用架構：支持 Redis Sentinel 進行故障轉移，保證了服務的連續性。

降低成本：相比 Redis，KVRocks 旨在降低內存使用成本，提高存儲容量。

社區支持：社區活躍，KVRocks 得到了社區的廣泛支持和貢獻，包括來自不同企業的使用和反饋。

企業級應用：KVRocks 已經被一些知名企業采用，如美圖、攜程、白山云等，百度云也是直接售賣，這證明了其在實際應用中的可靠性和效能。

缺點

學習曲線：對于不熟悉 RocksDB 或分布式系統的開發者來說，可能需要一定的學習時間來掌握 KVRocks。

生態系統：Redis 擁有龐大的生態系統和豐富的客戶端庫，KVRocks 可能在生態系統的豐富性上不如 Redis。

維護和更新：作為一個相對較新的項目，KVRocks 的維護和更新頻率可能不如成熟的 Redis。

文檔和資源：雖然 KVRocks 提供了文檔和命令支持，但可能沒有 Redis 那樣詳盡和易于獲取的資源。

發展redis的思考

結合上面的調研，選擇在kvrocks這款開源redis產品上進行自研，主要是因為開源協議友好，而且Kvrocks 是 Apache 軟件基金會的一個項目，社區國內很多廠家，包括百度云也是直接售賣，針對redis的高級特性和AI大模型火熱，我的發展思路大概有下面這些：

1.  在kvrocks開源代碼基礎上進行自研，同時緊跟最新的特性；

2.  redis分層存儲(Auto Tiering）、解決數據量太大而單機內存不足的問題，分層存儲的核心是冷熱數據分離，冷數據交換到磁盤，熱數據保存在磁盤，一個實現思路是用 OpenDAL 做分級存儲，這個特性可以大幅降低內存使用成本；

3.  docker化 + 存算分離架構引進，docker部署應該是已經支持了，在量級比較大的情況下，引入存算分離架構，可以減少機器成本，實現資源的超賣；

4.  Redis + AI大模型，redis最新特性是已經支持向量化相關特性，傳統的redis是作為緩存使用，這里可以繼續在AI大模型中使用redis作為緩存，同時進行有針對性的優化改進，如全球geo的緩存，用戶的請求路由到最近的redis服務器進行請求，有點緩存CDN加速的意思，此外還可以支持先向量的搜索能力，以方便與AI大模型相結合，可以往AI Redis向量化數據庫方向嘗試一下；

5.  將自身的redis數據庫嘗試跟其他數據庫產品相結合，如redis + mysql等，提升售賣能力；

6.  緊跟redis最前言技術，包括Redis社區最新特性，redis相關論文，各個廠商對redis的實踐等，同時結合自身的數據庫進行創新；