阿里巴巴|从 Redis7.0 发布看 Redis 的过去与未来( 三 )


这些变化与我们在阿里云上的统计结果也是相符合的:Redis目前同样也已是国内用户使用规模最大的NoSQL数据库之一 , 并一直处于高速增长中 , 越来越多的泛互联网甚至传统行业也在逐步接纳Redis , 用于快速高效的构建业务应用服务 。
虽然Redis发展迅速 , 但国内用户却大都无法享受技术红利
Redis社区目前主流维护版本是6.0 , 5.0版本已经进入低维护阶段 , 而国内还有大量2.8 , 3.0 , 4.0版本在使用中 。 这就很矛盾 , 一方面 , 一些对用法 , 性能 , 稳定性和抖动控制的能力都贡献在了新版本上 , 另一方面 , 国内用户却“看的到 , 用不上” 。
除去6.0 , 7.0上的高级稳定性优化不说 , 比如在4.0前 , 没有lazyfree删除一个大key是同步的会卡住数据库引擎直接导致业务中断 。 又比如 , Redis其实安全性尤其是lua是一直有较大问题的 , 这些升级也都“隐含”在了新版本中 。 虽然阿里云仍然在坚持把这些漏洞的修复拉回到低版本上 , 但是在公网当中还是有大量的低版本实例存在安全风险 。
过多用户担心升级版本的兼容性 , 一方面阿里云也在要求社区来提供一些兼容性验证工具 , 另一方面阿里云对版本跟进是很快的 , 可以让用户在新版发布后尽快进行验证 。 从Redis整体和阿里云的大量客户升级情况来看 , 版本的向前兼容性是非常好的 , 大可放心升级 。
希望更多的国内用户深度参与社区建设
国外使用Redis的方式和国内使用明显有差异 , 比如国外更多的是使用在缓存场景 , 而国内大多数的用法却是内存数据库 。 社区的发展和roadmap的制定 , 目前国内用户的声音较小 。
目前国内开发者在社区活跃度很高 , 但更多的是围绕在bugfix , 和feature上 。 我们还是建议无论是国内开发者还是使用者可以深层参与进去 , 举个简单的例子 , 提需求、讲明白需求、证明需求的合理性都是参与社区建设 , 这样才能更好的把我们国内的需求传达 , 后续甚至可以深度参与开发 , 跟踪交付 , 这些社区工作的含金量无疑更高 。
在功能上 , 不仅仅包括API层面的增加 , 包括接入 , 可观测性 , 一致性 , 一致性和安全等目前社区都在等待需求中 。 虽然core team member可以代表国内用户来把一些需求写进roadmap , 但是真实用户的发声会提供更有力的支撑 。
Redis使用场景拓展与展望--Redis还能做什么? 多模服务进入爆发期
Redis是一直贴着用户使用发展起来的 , 它如此受欢迎主要因为两个特点 , 极高的性能以及丰富、方便使用的数据结构 , 这些简单好用的数据结构能够大幅度降低开发业务复杂度 。
我们可以看到 , 以Redislabs为代表的厂商正在大力的丰富Redis的数据结构(modules) , 如RedisSearch、Redis-Json、RedisGraph、RedisTimeSeries和RedisBloom等 。
同样的 , 阿里云内存数据库Tair很早就在研发各类增强数据结构和模块 , 目前我们在公共云Tair服务中提供的商业化扩展型数据结构比Redislabs提供的更多 , 部分模块功能更强 , 有兴趣可参见文档(本文末尾参考资料) 。
目前已有大量云上用户在利用Tair增强型数据结构来构建代码 , 提高开发效率 , 甚至完成此前难以完成的工作 。 2022年是一个Redis扩展结构的爆发年 , 业内已经渡过接纳期 , 进入高速发展阶段 。 无论是Tair还是Redis , 我们相信不断丰富的数据结构能够让它们走的更远 , 从缓存演变为高性能的计算型内存数据库 , 突破、并解决更多场景问题 。
一致性能力上的发展
落盘一致性和副本一致性是使用数据库绕不开的两个话题 。 长期以来许多人对Redis的应用场景仅仅认定为缓存(尤其是国外用户) 。 Redis自诞生之初便支持持久化机制RDB和AOF , 并且AOF还提供了不同级别的持久化语义:如appendfsync采用最高级别always时可以保证数据完全落盘不丢失 , 具备与传统数据库一样的强落盘一致性 。