标签：https mic 情况 flush 模块 模型 link syn actor
参考：
https://www.cnblogs.com/vansky/p/9293961.html
https://www.cnblogs.com/gz666666/p/12901507.html
redis 4.0 新特性
Redis 4.0在2017年7月发布为GA。包含几个重大改进：更好的复制（PSYNC2），线程DEL / FLUSH，混合RDB + AOF格式，活动内存碎片整理，内存使用和性能改进。目前小版本更新到4.0.6
一、主从数据同步机制
PSYNC2: 新的一种主从复制同步机制。
PSYNC1:2.8~4.0之前版本的同步为PSYNC1
1、psync1因为网络中断或者阻塞导致主从中断，恢复后必须重新到主节点dump一份全量数据同步到从节点。psync2再中断恢复后只需要同步复制延迟的那部分数据。
2、psync1在重启从节点需要重新全量同步数据。psync2只部分同步增量数据。
3、在PSYNC1 当复制为链式复制的时候，如 A>B>C 主节点为A。当A出现问题，C节点不能正常复制B节点的数据。当提升B为主节点，C需要全量同步B的数据。在PSYNC2：PSYNC2解决了链式复制之间的关联性。A出现问题不影响C节点，B提升为主C不需要全量同步。
4、在使用星形复制。如一主两从。A>B , A>C 主节点为A。当A出现问题，B提升为主节点，C 重新指向主节点B。使用同步机制PSYNC2，C节点只做增量同步即可。在使用sentinel故障转移可以较少数据重新同步的延迟时间，避免大redis同步出现的网络带宽占满。
二、命令优化
线程DEL / FLUSH 优化
Redis现在可以在不同的线程中删除后台的key而不会阻塞服务器。 新的`UNLINK`命令与`DEL`相同，但是以非阻塞的方式工作。但是在key过期的内部依然使用了DEL。 类似地，为了让整个数据集或单个数据库异步释放，在“FLUSHALL”和“FLUSHDB”中添加了“ASYNC”选项。(手动清除大的key 可以使用unlink，不阻塞)
三、慢日志记录客户端来源IP地址，这个小功能对于故障排查很有用处。
四、混合RDB + AOF格式
混合RDB + AOF格式: 混合的RDB-AOF格式。 如果启用，则在重写AOF文件时使用新格式：重写使用更紧凑和更快的方式来生成RDB格式，并将AOF流附加到文件。 这允许在使用AOF持久性时更快地重写和重新加载。(目前相对于2.8没啥用)
五、新的管理命令
1、MEMORY 能够执行不同类型的内存分析：内存问题的故障排除（使用MEMORY DOCTOR，类似于LATENCY DOCTOR）,报告单个键使用的内存量，更深入地报告Redis内存使用情况 。
查看键值 使用 memory MEMORY USAGE key
memory统计分析 MEMORY STATS
MEMORY MALLOC-STATS
MEMORY PURGE
2、SWAPDB 能够完全立即（无延迟）替换同实例下的两个Redis数据库(目前我们业务没啥用)
六、
内存使用和性能改进:
1、Redis现在使用更少的内存来存储相同数量的数据。
2、Redis现在可以对使用的内存进行碎片整理，并逐渐回收空间(这个功能依然是试用阶段，可以通过参数不开启即可)
以上列举功能为4.0的重要更新，也是对我们目前redis大有改善，所列举的功能已经和亚运测试过。业务上还没有预发测试。
建议：新的边缘业务redis上线使用redis4.0 。先进行预发功能连通测试。一段时间后，根据实际使用情况推进redis4.0更新。
Redis 6.0在5.2号这个美好的日子里悄无声息的发布了，这次发布在IT圈犹如一颗惊雷一般，因为这是redis最大的一次改版，首次加入了多线程。
作者Antirez在RC1版本发布时在他的博客写下：
the most “enterprise” Redis version to date // 最”企业级”的
the largest release of Redis ever as far as I can tell // 最大的
the one where the biggest amount of people participated // 参与人数最多的
这次改变，性能有个飞速的提升~
先po出新版和旧版性能图
从上面可以看到 GET/SET 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了。另外，这些数据只是为了简单验证多线程 IO 是否真正带来性能优化，并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标，且只是目前的 unstble分支的性能，不排除后续发布的正式版本的性能会更好。
Redis 6.0 之前的版本真的是单线程吗？
Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。
一般来说 Redis 的瓶颈并不在 CPU，而在内存和网络。如果要使用 CPU 多核，可以搭建多个 Redis 实例来解决。
其实，Redis 4.0 开始就有多线程的概念了，比如 Redis 通过多线程方式在后台删除对象、以及通过 Redis 模块实现的阻塞命令等。
Redis 6.0 之前为什么一直不使用多线程？
使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。
Redis 通过 AE 事件模型以及 IO 多路复用等技术，处理性能非常高，因此没有必要使用多线程。
单线程机制使得 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。
Redis 6.0 为什么要引入多线程呢？
之前的段落说了，Redis 的瓶颈并不在 CPU，而在内存和网络。
内存不够的话，可以加内存或者做数据结构优化和其他优化等，但网络的性能优化才是大头，网络 IO 的读写在 Redis 整个执行期间占用了大部分的 CPU 时间，如果把网络处理这部分做成多线程处理方式，那对整个 Redis 的性能会有很大的提升。
优化方向：
- 提高网络 IO 性能，典型的实现比如使用 DPDK 来替代内核网络栈的方式。
- 使用多线程充分利用多核，典型的实现比如 Memcached。
所以总结起来，Redis 支持多线程主要就是两个原因：
- 可以充分利用服务器 CPU 资源，目前主线程只能利用一个核。
- 多线程任务可以分摊 Redis 同步 IO 读写负荷。
Redis 6.0 默认是否开启了多线程？
否，在conf文件进行配置
io-threads-do-reads yes
io-threads 线程数
官方建议：4 核的机器建议设置为 2 或 3 个线程，8 核的建议设置为 6 个线程，线程数一定要小于机器核数，尽量不超过8个。
Redis 6.0 多线程的实现机制？
流程简述如下：
- 主线程负责接收建立连接请求，获取 Socket 放入全局等待读处理队列。
- 主线程处理完读事件之后，通过 RR（Round Robin）将这些连接分配给这些 IO 线程。
- 主线程阻塞等待 IO 线程读取 Socket 完毕。
- 主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行。
- 主线程阻塞等待 IO 线程将数据回写 Socket 完毕。
- 解除绑定，清空等待队列。
该设计有如下特点：
- IO 线程要么同时在读 Socket，要么同时在写，不会同时读或写。
- IO 线程只负责读写 Socket 解析命令，不负责命令处理。
开启多线程后，是否会存在线程并发安全问题？
不会，Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。
Redis 线程中经常提到 IO 多路复用，如何理解？
这是 IO 模型的一种，即经典的 Reactor 设计模式，有时也称为异步阻塞 IO。
多路指的是多个 Socket 连接，复用指的是复用一个线程。多路复用主要有三种技术：Select，Poll，Epoll。
Epoll 是最新的也是目前最好的多路复用技术。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了 Redis 具有很高的吞吐量。
redis版本升级
标签：https mic 情况 flush 模块 模型 link syn actor
原文地址：https://www.cnblogs.com/xuwc/p/14013436.html
