Redis实战案例19-Redis解决主从一致性问题

主节点（Master）“写操作”：

1. 接收并响应客户端的读写请求。
2. 持久化数据到磁盘（根据配置可以选择使用RDB快照或者AOF日志）。
3. 将自己的写操作同步给所有的从节点。
4. 处理发布/订阅（Pub/Sub）模式中的发布操作。

从节点（Slave）“读操作”：

1. 复制主节点的数据。
2. 提供只读服务，响应客户端的读请求。
3. 可以支持读写分离，配置为从节点可以处理只读操作，如查询。
4. 可以配置为提供故障转移（failover）支持，当主节点故障时可以选举一个新的从节点作为新的主节点。
5. 可以进行备份和数据恢复。

从节点通过复制主节点的数据来实现数据的同步，复制过程中采用了异步的方式，在主从同步期间，从节点会不断地和主节点进行通信，获取主节点的更新操作，并将其应用到自己的数据集中。

问题引出：从节点通过复制主节点的数据来实现数据的同步，而数据的传输有延时，从而就可能出现问题。

当Java客户端获取锁，主节点此时记录线程锁的标识，而主节点会向从节点进行同步，此时主机发生宕机；这是哨兵机制会重新选择一个从节点作为主节点，但此时会出现问题：之前主从同步未完成，其它线程同样可以进行访问，这时就出现了并发安全问题。

解决方法只能说非常经典：多加一层

将每一层的节点独立起来，每一层的主节点都具有读写能力，获取锁必须从所有层的节点获取锁，每一层做主从同步（与之前的方案相同），但是并不会出现并发安全问题，因为即使有一层主节点发生了上述问题，有线程想趁虚而入访问也是不行的，它必须在每一层节点都获得锁，所以就不会有并发安全问题。

这种多个锁联合起来的方案叫做multilock