- 全量复制:master 全部同步到 slave

- 部分复制:slave 数据丢失进行备份

- 同步故障

- 复制数据延迟(不一致)

- 读取过期数据(Slave 不能删除数据)

- 主从复制挤压缓冲区不足产生的问题(网络中断，部分复制无法满足)，可增大复制缓冲区( rel_backlog_size 参数).

- 复制风暴


- 客观下线

- 所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum 个统一。

- 主观下线

- 即 Sentinel 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。

- 选举出一个 Sentinel 作为 Leader:集群中至少有三个 Sentinel 节点，但只有其中一个节点可完成故障转移.通过以下命令可以进行失败判定或领导者选举。

- 选举流程

1. 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求设置它为领导者.

2. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，则同意该请求，否则拒绝。

3. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum，则它成为领导者。

4. 如果此过程有多个 Sentinel 节点成为领导者，则等待一段时间再重新进行选举。

- 转移流程

1. Sentinel 选出一个合适的 Slave 作为新的 Master(slaveof no one 命令)。

2. 向其余 Slave 发出通知，让它们成为新 Master 的 Slave( parallel-syncs 参数)。

2. 选择复制偏移量最大的节点(同步数据最多)。

3. 选择 runId 最小的节点。

- 每 1s 每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping，进行心跳检测。

- 每 2s 每个 Sentinel 通过 Master 的 Channel 交换信息(pub - sub)。

- 每 10s 每个 Sentinel 对 Master 和 Slave 执行 info，目的是发现 Slave 节点、确定主从关系。


- 优势

1. 元数据的更新读取具有很强的时效性，元数据修改立即更新

- 劣势

1. 数据集中存储


- [Gossip 协议](https://www.jianshu.com/p/8279d6fd65bb)

- hash(key)%机器数量

- 问题

1. 机器宕机，造成数据丢失，数据读取失败

1. 伸缩性

- 

- 问题

1. 一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成缓存热点的问题。

- 解决方案

- 可以通过引入虚拟节点机制解决：即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。

- CRC16(key)%16384


存取数据优先从 Redis 操作，如果不存在再从文件（例如 MySQL）中操作，从文件操作完后将数据存储到 Redis 中并返回。同时有个定时任务后台定时扫描 Redis 的 key，根据业务规则进行淘汰，防止某些只访问一两次的数据一直存在 Redis 中。

如果企业级应用，可以参考：[阿里云的 Redis 混合存储版][1]

会话维持 Session 场景，即使用 Redis 作为分布式场景下的登录中心存储应用。每次不同的服务在登录的时候，都会去统一的 Redis 去验证 Session 是否正确。但是在微服务场景，一般会考虑 Redis + JWT 做 Oauth2 模块。

命令格式：`SETNX key value`：当且仅当 key 不存在，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何动作。

1. 超时时间设置：获取锁的同时，启动守护线程，使用 expire 进行定时更新超时时间。如果该业务机器宕机，守护线程也挂掉，这样也会自动过期。如果该业务不是宕机，而是真的需要这么久的操作时间，那么增加超时时间在业务上也是可以接受的，但是肯定有个最大的阈值。

2. 但是为了增加高可用，需要使用多台 Redis，就增加了复杂性，就可以参考 Redlock：[Redlock分布式锁](Redlock分布式锁.md#怎么在单节点上实现分布式锁)

Redis 缓存表的场景有黑名单、禁言表等。访问频率较高，即读高。根据业务需求，可以使用后台定时任务定时刷新 Redis 的缓存表数据。

主要使用了 List 数据结构。

List 支持在头部和尾部操作，因此可以实现简单的消息队列。

同时可以使用多个 List，来实现多个队列，根据不同的业务消息，塞入不同的 List，来增加吞吐量。

主要使用了 INCR、DECR、INCRBY、DECRBY 方法。

INCR key：给 key 的 value 值增加一

DECR key：给 key 的 value 值减去一

- LRU、LFU、FIFO 算法自动清除：一致性最差，维护成本低。

- 超时自动清除(key expire)：一致性较差，维护成本低。

- 主动更新：代码层面控制生命周期，一致性最好，维护成本高。

- 读请求：先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。

- 写请求：先删除缓存，然后再更新数据库(避免大量地写、却又不经常读的数据导致缓存频繁更新)。

- 通用性：全量属性更好。

- 占用空间：部分属性更好。

- 代码维护成本。

1. 请求无法命中缓存、同时数据库记录为空时在缓存添加该 key 的空对象(设置过期时间)，缺点是可能会在缓存中添加大量的空值键(比如遭到恶意攻击或爬虫)，而且缓存层和存储层数据短期内不一致；

2. 使用布隆过滤器在缓存层前拦截非法请求、自动为空值添加黑名单(同时可能要为误判的记录添加白名单).但需要考虑布隆过滤器的维护(离线生成/ 实时生成)。

- 事前：Redis 高可用，主从 + 哨兵，Redis Cluster，避免全盘崩溃。

- 事中：本地 ehcache 缓存 + hystrix 限流 & 降级，避免数据库承受太多压力。

- 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

1. 用户请求先访问本地缓存，无命中后再访问 Redis，如果本地缓存和 Redis 都没有再查数据库，并把数据添加到本地缓存和 Redis；

2. 由于设置了限流，一段时间范围内超出的请求走降级处理(返回默认值，或给出友情提示)。