Redis脑裂问题
Redis脑裂问题是指在主从集群中同时存在两个主节点，这会导致不同客户端往不同的主节点写入数据，最终导致数据不一致，甚至数据丢失。
哨兵主从集群脑裂
场景描述
假设有三台服务器：一台主服务器，两台从服务器，还有一个哨兵。当网络波动导致哨兵无法检测到主节点时，哨兵可能会通过选举将一个从节点提升为新的主节点。如果此时一些客户端仍连接到旧的主节点，而其他客户端连接到了新的主节点，就会出现脑裂问题。最终，恢复后的老主节点会被降级为从节点，并从新主节点同步数据，这期间写入旧主节点的数据会丢失。
解决方案
通过配置以下参数可以减少脑裂问题导致的数据丢失：
min-replicas-to-write 2
min-replicas-max-lag 10
min-replicas-to-write 2：要求至少有两个从节点才能进行写操作。min-replicas-max-lag 10：从节点与主节点的复制延迟不能超过10秒。
配置这两个参数后，如果发生脑裂，原主节点会拒绝客户端的写入请求，从而避免大量数据丢失。
集群脑裂
Redis集群一般不会发生脑裂，因为集群通过过半选举机制来防止脑裂问题。每个Redis集群有16384个槽，任何一个槽没有指派到节点时，整个集群就会不可用。为了确保集群的稳定性，建议构建至少有3个主节点的集群，且主节点数量为奇数。
尽管如此，脑裂问题在分布式系统中依然不可完全避免，受限于CAP理论的制约。
多级缓存实例
一个使用了Redis集群和其他缓存技术的应用系统架构如下：
架构流程
- 负载均衡：用户请求通过负载均衡服务分发到Nginx上。负载均衡算法常用轮询或一致性哈希。
- Nginx本地缓存：Nginx应用服务器读取本地缓存（如Lua Shared Dict、Nginx Proxy Cache或本地Redis），如果命中则直接返回，提升整体吞吐量并减轻后端压力。
- 分布式缓存：若本地缓存未命中，则读取Redis分布式缓存集群（可采用主从架构提升性能和吞吐量）。若命中则返回数据，并回写到Nginx本地缓存。
- 回源到应用服务器：若Redis缓存未命中，则请求回源到Tomcat集群，尝试再读一次主Redis集群。
- Tomcat本地缓存：在Tomcat集群中，首先读取本地平台级缓存，若命中则返回并同步到主Redis集群。
- 数据库查询：所有缓存未命中时，查询数据库或其他服务获取数据并返回。
总结
该架构通过多级缓存机制提升系统性能：
- Nginx本地缓存：解决热点数据缓存问题。
- Redis分布式缓存：减少访问回源率。
- Tomcat平台级缓存：防止缓存失效带来的冲击。
- 数据库缓存：提升数据库查询效率。
多级缓存的使用保障了系统的高效性和稳定性。
