redis技术演进(含redis6介绍)

redis的版本迭代,一直遵循着一个统一的原则:不断优化高性能读写的瓶颈,在保证强一致性的,尽量通过并发解决它

1.内存 ko 硬盘

redis的起源,来自于作者自己的需求:网站访问量,访问需求提升后,磁盘数据库规则的读写模式不再满足,于是内存数据库以其接近内存的读写速度,灵活的数据结构登上舞台

这个阶段,redis确定了其简单高效强一致性的"单线程"模式,所有的版本迭代都是围绕不断优化"单线程"的效率,使其不断接近内存读写速度极限的过程

2."快速推出的集群"

硬件更新迭代的速度永远没有需求增长来的快,当"单核单线程"的redis碰到性能瓶颈时,没有分布式经验的作者,贸然推出了"集群版redis",因为分布式,一致性上的问题,草草收场,此版本redis被抛弃

3.一带多的高可用主从模式

经过系统学习分布式知识后,redis的作者推出了一写多读的主从模式,通过保证主从节点的高度一致性,减少了主节点的高并发读压力,并观察验证了1-N的数据一致性效果

能进行主从切换,主从节点的身份可以自由的切换

4."观察者集群"的哨兵模式

在主从模式上积累了足够的经验后,redis的作者退出了分布式集群模式上更近一步的哨兵模式,其特点如下:

• 1.服务提供上,与主从模式保持一致(在支持从直接访问主从的同时,也支持访问哨兵获取主从信息)

• 2.添加入"观察团"1到多个哨兵

• 3.哨兵之间可以相互独立,也可以相互之间通信,组成集群

• 4.哨兵的集群能进行leader的选举,并通过自增的"配置纪元序号"应对"网裂"

哨兵的角色,既满足了主从实时监控,自动切换的需求,又能在低并发的场景下验证集群一致性方案的可行性,是很优秀的一步迭代方案

5.官方"集群模式"出现之前的"替代集群方案"

因为冒进走的弯路,作者之后的分布式学习践行,多个迭代版本的小步尝试,导致redis长期面临高并发读写性能瓶颈,最快的方式就是分布式集群化,于是这段空档期,出现了许多redis的分布式方案,比如codis,twemproxy等

这些集群方案因为和系统联系不够紧密,导致的问题是:key分布后,无法绕过代理直接获取key在哪个机器,redis单个节点沦为单纯的读写存储,另外的问题就是扩容缩容困难,难以进行线上的无缝热迁移

6.官方推出正式的集群模式

经过主从模式,哨兵模式的技术积累,演进,以及实践检验,官方推出了正式的集群模式,特点如下:

• 1.集群模式,通过将全部key划分到确定,有限(16384)的salt中,再将不同salt映射到集群指定节点,可以通过任意节点获取到salt映射节点的完整列表,并计算出key落在了集群哪个节点

• 2.通过对salt映射集群节点的完整列表管理,实现了key可以无限扩展,映射的salt是确定的,极大减少了元信息原理的复杂度和不确定性,集群各个节点的分治协作有条不紊,只需要确保少量的元数据同步一致即可

  • 1.redis集群节点之间的数据迁移的最小单位也是salt,通过以salt同步数据,成功后修改元数据,实现了极大和极小集群都能以一致的方式管理/迁移集群节点之间的数据,极大减小了程序逻辑的复杂度,增加了系统运行的稳定性,确定性

• 3.集群模式每个可写节点是主节点,主节点支持挂靠多个只读从节点,主从切换时采用的是经过验证的哨兵选举的模式

7.redis6新特性:"多线程",新的通信协议,系统功能全部模块化,ACL,官方集群代理模块......

redis的作者在19年底,退出了redis6的预发布版本,通过几个月时间的实际运行和反馈,于5月退出了redis6的正式版本

两个版本之间的和改变和取舍可以看到redis作者对redis的准确定位和角色判断

这是一个重大的版本,是redis的"企业级实现",各个新特性的特点如下:

• 1."多线程"

  • 1.在5月推出的正式版中,多线程的实现是"并发处理网络数据的读写和协议的解析,核心的命令执行和写操作维持原有逻辑"

    • a.相较于19年底更为激进的预发布版本,redis6的正式版本只在不影响核心逻辑的网络数据的读写和协议的解析部分采用了"并发",确保了之前久经考验的"单机单线程"核心处理逻辑保持其简单可靠性,减少了并发新特性带来的未知风险

• 2.新的通信协议

  • 1.推出了可选的RESP3协议,新的协议,在对原有协议兼容的情况下做了许多优化

    • a.返回数据可以明确返回数据的格式类型,降低了请求-响应之间的耦合度(原RESP协议有些请求返回数据无法获知格式,需要指导请求的命令)

    • b.支持多路复用,减少网络连接的资源消耗

  • 2.引入了许多的新的特性和数据类型

    • a.引入了更多的数据类型

    • b.引入了对订阅/推送更好的支持(对新特性客户端缓存的支持)

• 3.系统功能全部模块化

  • 1.经过多年的开发和不断改进,redis6终于将系统功能(api)调用全部模块话,可以像nginx一样为期单独开发独立的模块,并选择是否将其加入整个系统

  • 2.需要特别说明的是,随着redis6一同发布的,还有队列支持的模块Disque

• 4.ACL

  • 1.与redis高速并发查询速度保持一致的,是高危操作导致数据完全丢失的速度,这也是redis的RDB,AOF等备份方案一直备受关注的原因

  • 2.redis6新出了对命令权限的管控,主要特征:

    • a.可以限制指定用户可以执行/不能执行的命令列表

    • b.可以限定指定用户是否可以新建链接

    • c.可以创建命令集合,并设定指定用户可以/不能执行命令集合中的命令

    • d.权限控制生效遵循从头到尾,从左到右的ACL原则

• 5.官方集群的代理模块

  • 1.这个选配的模块就不多做说明了

• 6.客户端缓存

  • 1.正式版取消了预发版中的caching slot，而只使用key names

  • 2.正式版本支持两种缓存方式

    • a.订阅模式(默认模式)

      • 1.服务器记录哪些客户端订阅了哪些key names,当对应的key改变时,发送失效通知

      • 2.缺点是占用服务器内存记录订阅信息

    • b.广播模式

      • 1.服务器不记录客户端的订阅信息,服务器会广播失效信息,客户端根据自己缓存的key names自行匹配

      • 2.占用大量cpu发送"无效信息"

• 7.支持SSL

  • 1.使得客户端/集群即使通过不安全的网络传递消息也能保证安全性

• 8.提升RDB文件加载速度......

  • 1.包括提升RDB文件加载速度在内的其他优化

从redis各个版本迭代的演进看,一直遵循着"确保命令执行的正确性","单核单线程极致性能","适度引入并发提升处理能力上限"的设计原则

值得一提的是,redis6的开发过程,也引用了"并发"的模式,redis6有长达几十人的commit"贡献者",尤其SSL功能模块是在完全没有作者帮助的情况下,有其他贡献者完成的

结合redis6实现的"系统框架化,平台化",以及modules的引入,可以预见,未来的redis会吸引更多的贡献者参与进去,各种新的模块功能将不断出现,redis未来的生命力将更加旺盛