引言

这篇文章起源于对[4][5]学习后的一些思考。

Redis官方对于Redis的定义如下：

in-memory data structure store, used as a database, cache, and message broker.

事实上从商业，开源，技术的方面来说Redis是过去10年间最优秀的数据库产品之一，但是其诞生于2009年，固然antirez是一个极其优秀的技术人员，但是局限于年代的原因，Redis的宏观设计上来说并不是一个完美的数据库。

redis定位高性能高速缓存，低容量，低延时，固然数据量和工作量不大，且对于数据的持久性要求不高的时候，Redis易用，且表现优秀；但是随着需求的增长，Redis的弊端则暴露出来，高成本，运营复杂性都可能会导致预算超支；不支持多机事务且一致性较差导致一些场景无法使用；集群无法动态扩缩容使得弹性较差；原始架构不支持多租户，导致成本较高。

一个大容量，高可靠，高性能，多租户，低成本且兼容Redis协议的数据库是否是现实的呢？答案是肯定的，目前大量兼容Redis协议的云原生数据库正在着力于解决上述问题。

当然需要提到的是各大厂商实现的方式都不太一样，所以结论并不是普适的。

TCO（Total cost of ownership）

作为一个内存数据库，正常来说其工作集合是不能大于内存的的，而业务的增长意味着更多节点，内存和人力的投入。

对于兼容Redis协议的云原生数据库来说，存储节点上数据是存储在SSD，HDD，Pmem上的，混合存储，数据降冷，异构多副本相关的技术可以使的成本大幅度下降（说起混合存储，FASTER的架构就是一个很好的例子[11]）。

可以看到阿里云上的容量存储型最低可达到Redis成本的百分之十五，性能也可以达到百分之六十。相比之下腾讯云Redis允许按需计费，不像阿里云这样按照实例售卖，但是只有普通的Redis版本。
在这里插入图片描述

可伸缩性和弹性

云的最大优势是弹性，这是一个现在可能小学六年级的同学也知道的事情。

现在云原生数据库从架构上迎合了这种极致的弹性，这种优势是Redis目前来看无法具备的，因为redis cluster的架构导致其无法自动扩缩容，只能依赖于手动高峰前的迅速扩大规模和高峰期后迅速缩小规模。

而云原生数据库存算分离的架构则解决了这个问题，计算节点无状态，可随意添加（当然是有限制的，依具体架构而论），意味着计算资源的极致弹性；而存储节点的分裂合并也都是自动的，而存储节点的添加也只和计算节点的路由和storage group有关。

高性能且持久性

原生redis最遭到诟病的地方在于无法保证持久性与RDB(fork) / AOF Rewrite的低效。

持久性因为Redis的原生架构是很难解决的。但是后两点从目前浏览器上可以搜到资料来看都是可以被解决的（虽然难度可能偏大，国内有这样水平的团队并不多），一个是某大厂的Forkless解决方案，一个是Redis 7.0 Multi part AOF的解决方案。

云原生数据库自然不需要考虑以上问题，毕竟协议的解析放在计算节点，存储是在存储节点的，从持久性到可用性都像传统数据库一样，已经是久经磨练的技术了。

数据一致性

redis本身的解决方案可以被认为是一种半同步的解决方案，Redis对于极致速度的追求意味着不可能每一个写请求都去跑一个raft/paxos group。

但是因为云原生数据库可以无限扩展计算节点，可以在兼顾效率的同时在底层基于不同的需求支持多种一致性协议，经典的CosmosDB就支持了五种一致性模型[6][7]。

分布式事务

很好理解为什么云原生数据库有优势，后面会有几篇文章写分布式事务，这里不提了。

扩展可管理性

需求的增长意味大型集群，而Redis的高可用解决方案Sentinel无疑意味着高延时。

而存储节点中我们可以依赖于一致性协议的各种优化达到超高的可用性，极致情况甚至可以在follow全部宕机的情况下任支持强一致的读写，且不丢失数据。

性能

虽然正常direct mode和gateway的方案性能是一定不如redis的，但是我们可以设置类似于DAX的方案去使得热数据和部分温数据在特殊的内存节点中存储，以此加速数据的访问，在热点明显的场景中性能直接起飞。

计费方式

Redis原生不支持多租户，这意味着一般的计费模式都是在卖实例，但是这种预分配的策略对于对资源由严格要求的大租户是OK的，对于流量突发的小实例并不是一个好选择。

其次前面提到的扩缩容能力的欠缺使得用户的成本是比较高的，因为必须用以往的经验对未来做出预测。

而云原生数据库大多是多租户的(从Database，Table到Partition的共享都算)，与无与伦比的弹性结合使得Serverless的到来是如此顺其自然，无需最低费用，无需容量规划对于有明显峰值的用户来说显然是极具吸引力的（这里可以参考[9]中的计费模式），这也是为什么cockroachDB敢做出他们的Serverless“永远免费”的决定（赌一般的用户玩一下就再也不上线了，极致扩缩容使得一个用户就是1到N个计算pod，而且因为partition级别共享存储，存储是非常便宜的）

虽然RU的计费方式有时候会让用户非常疑惑，但是我很疑惑腾讯云Redis只计算存储大小的方式[10]真的不把计算和网络当钱吗。。