1 Redis各版本的特性

1.1 Redis3.0

（1）支持redis-cluster
（2） Redis日志小做调整：日志中会反应当前实例的角色（master或者slave）
（3） migrate连接缓存，大幅提升键迁移的速度
（4） cinfig set设置maxmemory时候可以设置不同的单位（之前只能是字节）
（5）新的client pause命令，在指定时间内停止处理客户端请求

1.2 Redis3.2

（1）支持用upstart（init系统）或者systemd管理Redis进程。
（2）添加GEO相关功能（支持存储地理位置信息用来实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能）
（3）新的List编码类型：quicklist，3.2之前list底层的编码是ziplist（列表对象中元素的长度比较小或者数量比较少）和linkedlist实现的
（4）从节点读取过期数据保证一致性（从节点读取数据之前会检查键的过期时间来决定是否返回数据）
（5）增强了debug命令，支持了更多的参数
（6）添加了hstrlen命令：返回哈希表中给定域相关联的值的字符串长度
（7） SDS在速度和节省空间上都做了优化

1.3 Redis4.0

（1）提供了模块系统，方便第三方开发者拓展Redis的功能
（2） PSYNC2.0：优化了之前版本中，主从节点切换必然引起全量复制的问题
（3）提供了RDB-AOF混合持久化格式，充分利用了AOF和RDB各自优势。
（4） Redis Cluster 兼容NAT和Docker
（5）新添加了UNLINK命令（是DEL命令的异步版本）它可以将删除指定键的操作放在后台线程里面执行，从而尽可能地避免redis服务器阻塞，（过期数据的删除策略：定时，定期，惰性）。
（6）提供了memory命令，实现对内存更为全面的监控统计。
（7）提供了新的缓存剔除算法：LFU（Last Frequently Used，一段时间内使用次数最少的数据优先被剔除），并对已有算法进行了优化
（8）新增了SWAPDB命令（SWAPDB 0 1），提供了交互数据库功能，实现Redis内部数据库的数据置换

1.4 Redis5.0

（1）新的数据类型：流数据（Stream，用来持久化消息队列）、账号管理、审计日志等
（2）集群管理器从Ruby （redis-trib.rb）移植到了redis-cli中的C语言代码
（3） RDB增加存储key逐出策略LFU（最不经常使用）和LRU（最近最少使用）
（4）默认hz动态化：为了平衡空闲CPU的使用率和响应能力
（5）新sorted set命令：ZPOPMIN / MAX和阻塞变量
（6）客户经常连接和断开连接时性能更好
（7）新的Redis模块API：Timers and Cluster API。
（8）许多带有子命令的命令现在都有一个HELP子命令
（9）升级Jemalloc（内存分配策略）至5.1版本
（10）主动碎片整理V2，redis4.0之前的版本中只能通过正确的重启redis服务来解决内存碎片问题。在redis4.0之后，redis提供了两种方式的碎片整理功能，第一种通过手动命令进行触发，第二种通过配置(配置文件中设置activedefrag yes)，使redis在运行时就可以自动的进行内存碎片清理

1.5 Redis 6.0新特性

模块系统新增多个API。
支持SSL/TLS加密，ACL（访问控制列表）支持：允许根据可以执行的命令和可以访问的键来限制某些连接。
支持新的Redis协议：RESP3（服务端与客户端的通信协议），直接从 Redis 返回复杂的数据类型，而客户端对于数据类型的转换是透明的；RESP2协议数据都是以字符串数组的形式返回给客户端，不管是 list 还是 sorted set。因此客户端需要自行去根据类型进行解析，这样会增加了客户端实现的复杂性
服务端支持多模式的客户端缓存：Redis 6采用全新协议RESP3，以提供客户端缓存功能。当需要进行快速存储或快速取操作时，就需要在客户端内存中存储一小部分信息，这可以降低程序获取数据时的延迟
目前在RESP2上实现的客户端缓存的方式转发模式（需要两个客户端连接以转发重定向的形式实现），不再使用 RESP3 原生支持 PUSH 消息，而是将消息通过 Pub/Sub 通知给另外一个客户端

Redis客户端缓存被称为Tracking，在RESP3协议下，有两种模式：

默认模式：服务器记录客户端访问了哪些key，当其中的key发生变更时给客户端发送失效信息，消耗服务器端内存；Redis 服务端记录的客户端
track 信息只生效一次，发送过失效消息后就会删除，只有下次客户端再次执行只读命令被 track，才会进行下一次消息通知。
广播模式：客户端订阅访问过的key的前缀，当符合模式的key发生变更就会被通知（即使变更的key没有被客户端缓存），服务器端不记录客户端访问的key，因此不会消耗服务器端的内存；广播模式下，只要键被修改或删除，符合规则的客户端都会收到失效消息，而且是可以多次获取的，与普通模式相比，虽然少存储了一些数据，但是由于需要对前缀规则进行匹配（不想所有的键值的失效消息都收到），会消耗一定的CPU 资源，所以注意别使用过长的前缀。

支持多线程IO：多线程（默认禁用）部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行
副本中支持无盘复制（diskless replication）：在用户可以配置的特定条件下，从服务器现在可以在第一次同步时直接从套接字加载RDB到内存
Redis-benchmark（压测工具）支持Redis集群模式。
支持重写Systemd。
支持Disque模块：Disque 目的是构建分布式的内存中消息代理，在 Redis 6 中成为模块，它可以支持集群消息总线 API，可以阻止和恢复客户端、支持计时器、模块私有数据的 AOF 和 RDB 控制功能

集群代理，支持Prxoy，可以直接用Proxy来管理各个集群节点
RDB文件加载速度更快了

Rdeis的单线程： Redis 在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理
单线程 Redis 来说，性能瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

提高网络 IO 性能，典型的实现像使用 DPDK 来替代内核网络栈的方式
使用多线程充分利用多核，典型的实现像 Memcached

引入多线程的原因： 随着硬件性能提升，Redis 的性能瓶颈可能出现网络 IO 的读写，也就是：单个线程处理网络读写的速度跟不上底层网络硬件的速度

Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制key、lua、事务，LPUSH/LPOP 等等的并发问题

2 Redis架构

2.1 主从架构

主从架构，提供高性能的缓存服务和数据高可靠
场景： 单个Redis性能压力可控；Redis命令相对简单，排序、计算类命令较少，CPU会成为主要瓶颈
（1）主从架构-双副本：数据可要性要求高
（2）主从架构-单副本：没有数据可靠性要求的纯缓存场景

2.2 Redis集群

2.2.1 集群模式

集群版：由于Redis的单线程机制，CPU为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。
（1）集群版-双副本：每个分片服务器采用主从（master-replica）双副本模式

代理模式：支持通过一个统一的连接地址（域名）访问Redis集群，客户端的请求通过代理服务器转发到各数据分片，系统自动实现负载均衡和故障转移；降低业务开发难度，所有请求都要通过代理服务器转发，会影响Redis服务的响应速度。
直连模式：直接连接后端数据分片，从而降低网络开销和服务响应时间(前提条件使用Jedis、PhpRedis等支持Redis
Cluster的客户端)

（2）集群版-单副本:不支持高可用
（3）读写分离版

Redis集群代理特点：

（1）自动化路由:每个查询被自动路由到集群的正确节点
（2）多线程（它目前使用多路复用通信模型，这样每个线程都有自己的集群连接）
（3）支持多路复用和私有连接模型
（4）即使在多路复用上下文中，查询执行和应答顺序也是有保证的
（5）跨slot/跨节点查询
（6）发生ASK | MOVED错误后自动更新集群的配置，

2.2.2 ASK 重定向和MOVED 重定向

MOVED错误： 键所在的槽并没有指派给当前节点，那么节点会向客户端返回一个MOVED错误，指引客户端转向（redirect）至正确的节点，并再次发送之前想要执行的命令；集群模式只能使用0数据库，单机模式没有限制（0-15数据库）；

集群模式的redis-cli客户端在接收到MOVED错误时，并不会打印出MOVED错误，而是根据MOVED错误自动进行节点转向，并打印出转向信息，所以我们是看不见节点返回的MOVED错误的；
单机模式的redis-cli客户端不清楚MOVED错误的作用，它会直接将MOVED错误直接打印出来，而不会进行自动转向；一个集群客户端通常会与集群中的多个节点创建套接字（Socket）连接，而所谓的节点转向实际上就是换一个套接字（Socket）来发送命令；如果客户端尚未与想要转向的节点创建套接字（Socket）连接，那么客户端会先根据MOVED错误提供的IP地址和端口号来连接节点，然后再进行转向

ASK错误： 在进行重新分片期间，源节点向目标节点迁移一个槽的过程中，可能会出现这样一种情况：属于被迁移槽的一部分键值对保存在源节点里面，而另一部分键值对则保存在目标节点里面。
当客户端向源节点发送一个与数据库键有关的命令，并且命令要处理的数据库键恰好就属于正在被迁移的槽时：
（1）源节点会首先在自己的数据库里面查找指定的键，如果找到的话，就直接执行客户端发送的命令。

（2）如果源节点没能在自己数据库中找到指定的键，那么这个键就有可能已经迁移到目标节点，源节点向客户端返回一个ASK错误，指引客户端转向正在导入槽的目标节点，并在此发送之前想要执行的命令。

ASK 重定向和MOVED 重定向

ASK 重定向说明集群正在进行 slot 数据迁移，客户端无法知道什么时候迁移完成，因此只能是临时性的重定向，客户端不会更新 slot 到 Redis 节点的映射缓存。但是 MOVED 重定向说明键对应的槽已经明确指定到新的节点，因此需要更新 slot 到 Redis 节点的映射缓存。

常用的IO多路复用模型有三种：select、poll、epoll

（1） select：它维护了一个数组结构 fd_set（0和1的位数组），调用 select 函数时，会从用户空间拷贝 fd_set 到内核空间，并监听是否有事件触发，有就通过轮询的方式遍历找到事件触发的位置，然后执行相关的读或写操作。轮询的时间复杂度为 O(n)

缺点：select支持的文件描述符数量过小了，默认是1024；每次调用 select，都需要把 fd_set 集合从用户态拷贝到内核态，都需要在内核遍历传递进来的所有 fd_set ，效率很低
（2） poll：与 select 类似，区别是它采用的是 poll_fd 数据结构实现了一个可变长的数组，没有了最大文件描述符数量的限制。轮询的时间复杂度为 O(n)
（3） epoll： epoll 监听事件是否触发时，还设置了回调函数，如果事件触发，就执行回调函数，并将准备就绪的 fd （文件描述符）放到就绪链表中，而不需要轮询遍历所有的 fd_set 。并且 epoll 没有最大文件描述符数量的限制。在高并发情况下 epoll 能支持更多的连接

Redis各版本的特性及架构相关推荐

Redis 6.0 新特性-多线程连环13问！
来自:码大叔导读:支持多线程的Redis6.0版本于2020-05-02终于发布了,为什么Redis忽然要支持多线程?如何开启多线程?开启后性能提升效果如何?线程数量该如何设置?开启多线程后会不会有 ...
Redis 6.0 新特性，多线程连环 13 问！
导读:支持多线程的Redis6.0版本于2020-05-02终于发布了,为什么Redis忽然要支持多线程?如何开启多线程?开启后性能提升效果如何?线程数量该如何设置?开启多线程后会不会有线程安全问题? ...
Redis 6.0 新特性：多线程连环 13 问！
来源 | 码大叔责编 | Carol 封图 | CSDN付费下载自视觉中国支持多线程的Redis6.0版本于2020-05-02终于发布了,为什么Redis忽然要支持多线程?如何开启多线程?开启后 ...
Redis 6.0 新特性-多线程连环 13 问！
Redis 6.0 来了在全国一片祥和IT民工欢度五一节假日的时候,Redis 6.0不声不响地于5 月 2 日正式发布了,吓得我赶紧从床上爬起来,学无止境!学无止境! 对于6.0版本,Redis之 ...
Redis 6（一）Redis 6的新特性
Redis 6 新特性文章目录 Redis 6 新特性 1. 模块 2. SSL / TLS TLS支持 3. ACL(访问控制列表) 4. RESP3 RESP3 类型 5. 客户端缓存客户端缓 ...
Redis 6.0 新特性 ACL 介绍
Redis 6.0 新特性 ACL 介绍 Intro 在 Redis 6.0 中引入了 ACL(Access Control List) 的支持,在此前的版本中 Redis 中是没有用户的概念的,其实 ...
Redis 6.0 新特性概览
摘要:Redis 6.0 特性点击阅读原文,提升阅读体验:https://www.modb.pro/db/22840?cyn 前言 Redis 6 RC2 于今年3月5号Release,预计今年4. ...
Redis 6.0新特性——ACLs
简介 Redis在6版本之前是没有权限的概念的,所以所有连接的客户端都可以对Redis里面的数据进行操作,也可以使用所有高危命令,这样就可能存在Redis直接down掉或者数据被全部清空的情况. 当执 ...
React16、17、18版本新特性
react-16版本新特性一.hooks import { useState } from 'react'function App() {// 参数:状态初始值比如,传入 0 表示该状态的初始值为 ...

Redis各版本的特性及架构