多级缓存架构

多级缓存架构
并发竞争
Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？

多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。

CAS 类的乐观锁方案：某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。

你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。每次要写之前，先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。

Redis cluster 的高可用与主备切换原理
如果一个节点认为另外一个节点宕机，这是属于主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是客观宕机，跟哨兵的原理几乎一样，sdown，odown。流程为：如果一个节点认为某个节点pfail 了，那么会在 gossip ping 消息中， ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成fail 。 每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。所有的 master node 开始 slave 选举投票，给要进行选举的slave 进行投票，如果大部分 master node （N/2 + 1） 都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。从节点执行主备切换，从节点切换为主节点。

主从架构下的数据同步
主从复制/数据同步
master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

主从架构下的数据部分复制（断点续传）
当redis是主从架构时，主节点同步数据到从节点进行持久化，这个过程可能会因为网络/IO等原因，导致连接中断，当主节点和从节点断开重连后，一般都会对整份数据进行复制，这个过程是比较浪费性能的。从redis2.8版本开始，redis改用可以支持部分数据复制的命令去主节点同步数据，主节点会在内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，主节点和它所有的从节点都维护复制的数据下标和主节点的进程id，当网络连接断开后，从节点会请求主节点继续进行数据同步，从记录数据的下标开始同步数据。如果主节点进程id变化了，或者从节点数据下标太旧，不在主节点的缓存队列里，会进行一次全量数据的复制。

数据丢失发生的场景以及解决方案
异步复制导致的数据丢失：主节点到从节点的复制是异步的，主节点有部分数据还没复制到从节点，主节点就宕机了。