阿里巴巴|从 Redis7.0 发布看 Redis 的过去与未来( 四 ) 阿里云|数据库|lua|云计算

在多副本一致性上，主要是指主备一致性上，原生的Redis仍旧采用异步复制，数据修改操作只要在本地执行完成就会返回结果，相比于其他数据库没有提供副本间数据强一致的语义。这也限制了Redis的使用场景，在对数据可靠性有极高要求的用户（例如金融行业，和传统行业）中还没有被完全接纳。
目前业内也都在对Redis的持久化能力上进行发展。比较有代表性的，是阿里云的Tair持久内存版、AWS的MemoryDB、和业内开源的一些Redis-like的基于rocksdb的系统，商业化如Tair的容量存储版（前混合存储）。

表1: 社区Redis和其他商业化、开源产品的落盘一致性与副本一致性对比注1：与开源Redis社区版比较注2：与开源Redis基于内存的使用成本比较注34：来自AWS官方博客测试数据
综合来看，随着用户对Redis的应用范围的扩大，与此同时对于容量、成本和数据可靠性的需求也在不断提升，这些也逐渐成为了衡量Redis企业级能力的重要指标。各大厂商和开源产品也都在构建这些能力上提出了许多解决方案。下面介绍一些典型产品和方案。
AWS的MemoryDB
AWS MemoryDB的思路是基于类似Aurora的共享存储概念，把日志存放在远端共享存储中，同时内存中仍然保留Redis原有的结构。通过这种方式提升数据的持久化一致性，同时也保证了数据读取的延时和吞吐；而缺点则同样因为日志保存在远端，写入性能严重下降（仅有ElastiCache也即Redis社区版的15%~25% ，该数据来自AWS官方评测，见本文末尾参考资料）。在主备一致性上，由于直接采取日志的物理复制，所以主备一致性近似接近落盘一致性。
值得一提的是原来AOF rewrite这种压缩（compaction）引起的开销也因为在远端做掉而规避掉，因此是一种很彻底的云原生解法。
阿里云自研内存数据库Tair
在持久化上阿里云走了另外一条路，通过引入新介质持久化内存来解决成本，大容量和持久化能力的问题。这个方案带来的挑战是使用持久化内存存储结构设计上较为复杂，既要控制性能衰减，又要保证兼容性。 Tair持久内存很好的解决了这些问题，对比MemoryDB成本更低，读性能基本持平的情况下写入的速度也更快（见本文末尾参考资料），更关键的是基本原封原样的兼容了Redis API ，大幅降低了用户的切换成本。
并且， Tair持久内存型还支持半同步和强写入一致性，无论MemoryDB还是Tair持久内存都真正的做到了内存数据库的数据容错性要求。
其他开源产品的发展
国内也出现了一些原创性的优秀落盘开源产品（Redis-Like系统），这些产品大都基于LSM存储结构如rocksdb上的。它们的优点主要是磁盘介质相对内存更为便宜，但同样目前存在的缺点也非常多：运维复杂度较高，直接映射为运维成本、KV无法原生的支持Redis的数据结构、把Redis的强类型变成弱类型等等。
目前这类系统在一致性和容错性上仍有很大的改善空间，而在用户使用体感上，由于很多用户使用习惯还是把Redis-like系统用在业务的同步链路上，对于LSM KV引擎的延时上抖动整体吞吐的影响直接映射成了用户体感，因此很难作为一款通用型产品，而这些痛点也同样存在与Tair容量存储型中（过去叫混合存储版），这也是一个需要长期在存储和兼容性上优化的方向。
综上所述，容量版本可以很好地解决用户的使用成本问题，但是只有更好地解决了落盘一致性问题和副本一致性问题，才能够把Redis类系统的使用场景拓展到企业级。这也是目前看来云厂商一个激烈竞争的企业级产品主流赛道，也有较高的技术门槛。