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

对具体实现感兴趣的同学可以查看本文末尾参考资料。
Sharded-pubsub
Redis自2.0开始便支持发布订阅机制，使用pubsub命令族用户可以很方便地建立消息通知订阅系统，但是在cluster集群模式下Redis的pubsub存在一些问题，最为显著的就是在大规模集群中带来的广播风暴。
Redis的pubsub是按channel频道进行发布订阅，然而在集群模式下channel不被当做数据处理，也即不会参与到hash值计算无法按slot分发，所以在集群模式下Redis对用户发布的消息采用的是在集群中广播的方式。
那么问题显而易见，假如一个集群有100个节点，用户在节点1对某个channel进行publish发布消息，该节点就需要把消息广播给集群中其他99个节点，如果其他节点中只有少数节点订阅了该频道，那么绝大部分消息都是无效的，这对网络、CPU等资源造成了极大的浪费。
Sharded-pubsub便是用来解决这个问题，意如其名， sharded-pubsub会把channel按分片来进行分发，一个分片节点只负责处理属于自己的channel而不会进行广播，以很简单的方法避免了资源的浪费。
Client-eviction Redis支持内存规格配置， maxmemory和maxmemory-policy大家已经都很熟悉了，但是在这里我还是想再解释一下：maxmemory控制的是Redis的整体运行内存而非数据内存，例如client buffer、lua cache、fucntion cache、db metadata等这些都会算在运行内存中，如果运行内存超过了maxmemory就会触发evict删除数据，这也是用户在使用Redis时的一大痛点。
在这些非数据内存使用当中，又以client buffer消耗最大，在大流量场景下client需要缓存很多用户读写数据（想象一下keys的结果需要先缓存在client output buffer中再发送给用户），由于网络流量的内存消耗导致触发eviction删除数据的情况非常之多。虽然Redis很早就支持对client-output-buffer-limit配置项，但其限制的也只是单个连接维度的output buffer ，没有全局统计client使用内存和限制。为了解决这个问题， 7.0新增了maxmemory-clients配置项，来对所有client使用的内存做限制，如果超过了这个限制就会挑选内存消耗最大的client释放，用来缓解内存使用的消耗。
Client-eviction并不是终点，还有很多元数据的内存使用会对用户造成困扰， Redis是基于内存的数据库，我们需要对各个模块的内存进行更精确的统计和控制，让用户能够对数据存储有更为清晰的理解和规划。
Redis历史回顾 Redis发展至今已历经7个大版本，而每个大版本都有大量的新特性产生。例如从3.0开始支持cluster集群模式；4.0开发的lazyfree和PSYNC2解决了Redis长久的大key删除阻塞问题及同步中断无法续传的问题；5.0新增了stream数据结构使Redis具备功能完整的轻量级消息队列能力；6.0更是发布了诸多企业级特性如threaded-io、TLS和ACL等，大幅提升了Redis的性能和安全性。
国内开发者与Redis社区建设感谢国内开发者，中国区已经成为Redis社区最大的贡献来源之一
阿里云从Redis 4.0开始就深度参与到Redis开源社区当中，向社区贡献了大量能力，目前阿里云在Redis社区共有1名core team member（核心维护者）和2名contributor（核心贡献者），是原作者和Redis Labs以外对Redis社区贡献最大的组织。
我们见证了Redis用户在国内的快速增长，阿里云与Redis社区的深度合作也逐渐吸引了更多的国内开发者参与到Redis建设中去。尤其是在Redis core team成立之后，社区maintainer也和Redis一样变成了多线程（1-5），对于issue和PR的快速处理大幅提升了社区的活跃度。这次7.0的release note中也可以看到已经有超过5名国内开发者贡献了核心feature ，并贡献了近半数commit 。