进阶指南！Redis 用法总结( 二 ) _Redis

但是假设业务存在这样一种情况：A 请求在获取锁后处理逻辑，由于逻辑过长，这个时候锁到期释放了，A 这个时候刚刚处理完成，而 B 又去改了这个数据，这就存在一个锁失效的问题。解决这种问题参考 CAS 的方式，对锁设置一个随机数，可以理解为版本号，如果释放的时候版本号不一致，则表示数字已经在释放那一刻改掉了。

三、深入原理1. IO模型
Redis 是单线程模型（这里的单线程指的是 IO 和键值对的读写是一个线程完成的），当然如果严谨的来说还是可以理解为是多线程，不过这样的多线程不过是在数据备份的时候会 fork 一个子进程对数据进行从磁盘读取数据并组装 RDB，然后同步给 slaver 节点的操作，当然包括备份和持久化也都是通过另外起线程完成的，所以我们可以把 Redis 认作为一个单线程模型。

那么问题来了，为什么单线程的模型能这么快？原因很简单，因为 Redis 本身就是在内存中运算，而对于上游的客户端请求，采用了多路复用的原理。Redis 会给每一个客户端套接字都关联一个指令队列，客户端的指令队列通过队列排队来进行顺序处理，同时 Reids 给每一个客户端的套件字关联一个响应队列，Redis 服务器通过响应队列来将指令的接口返回给客户端。

文章插图
Redis IO 处理模型
2. 通信协议
Redis 采用了 Gossip 协议作为通信协议。Gossip 是一种传播消息的方式，可以类比为瘟疫或者流感的传播方式，使用 Gossip 协议的有：Redis Cluster、Consul、Apache Cassandra 等。Gossip 协议类似病毒扩散的方式，将信息传播到其他的节点，这种协议效率很高，只需要广播到附近节点，然后被广播的节点继续做同样的操作即可。当然这种协议也有一个弊端就是：会存在浪费，哪怕一个节点之前被通知到了，下次被广播后仍然会重复转发。

文章插图

3. 持久化（1）RDB
RDB 是对当前 Redis 的存储数据进行一次快照（具体原理和如何做，限于篇幅这里不做过多复述了）。
（2）AOF
日志只记录 Redis 对内存修改的指令记录，Redis 提供了一个 bgrewriteaif 的指令对 AOF 进行压缩。原理就是：开辟一个子进程对内存进行遍历后，转换成一系列对 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。系列化完成后再将发送的增量 AOF 日志追加到这个新的 AOF 日志中，追加完成后用新的 AOF 日志代替旧的。
（3）混合持久化
由于单纯 RDB 的话，可能存在数据的丢失，而频繁的 AOF 又会影响了性能，在 Redis 4.0 之后，支持了混合持久化，也就是每次启动时候通过 RDB+增量的 AOF 文件来进行回复，由于增量的 AOF 仅记录了开始持久化到持久化结束期间发生的增量，这样日志不会太大，性能相对较高。

4. 主从同步
Redis 的同步方式有：主从同步、从从同步（由于全部都由 master 同步的话，会损耗性能，所以部分的 slave 会通过 slave 之间进行同步）。

文章插图

文章插图

同步过程：

建立连接，然后从库告诉主库：“我要同步啦，你给我准备好”，然后主库跟从库说：“收到” 。
从库拿到数据后，要把数据保存到库里。这个时候就会在本地完成数据的加载，会用到 RDB。
主库把新来的数据 AOF 同步给从库。

5. Sentinel
Redis 的主从切换是通过哨兵来解决的。这里哨兵主要解决的问题就是：当 master 挂了的情况下，如果在短时间内重新选举出一个新的 master。

文章插图

Sentinel 集群是一个由 3-5 个（可以更多）节点组成的，用来监听整个 Redis 的集群，如果发现 master 不可用的时候，会关闭和断开全部的与 master 相连的旧链接。这个时候 Sentinel 会完成选举和故障转移，新的请求则会转到新到 master 中。

6. Redis集群工作原理
Redis 集群通过槽指派机制来决定写命令应该被分配到那个节点。整个集群对应的槽是由 16384 大小的二进制数组组成，集群中每个主节点分配一部分槽，每条写命令落到二进制数组中的某个位置，该位置被分配给了哪个节点，则对应的命令就由该节点去执行。槽指派对应的二进制数组如下图所示：