前言

本文旨在阐述关于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的实践等，同时结合自身的数据库进行创新；