在高频访问数据库的场景中，我们会在业务层和数据层之间加入一套缓存机制，来分担数据库的访问压力，毕竟访问磁盘 I/O 的速度是很慢的。比如利用缓存来查数据，可能5ms就能搞定，而去查数据库可能需要 50 ms，差了一个数量级。而在高并发的情况下，数据库还有可能对数据进行加锁，导致访问数据库的速度更慢。

分布式缓存我们用的最多的就是 Redis了，它可以提供分布式缓存服务。

一、Redis 缓存

1.1 . Redis 数据丢失

哨兵机制

Redis 可以实现利用哨兵机制实现集群的高可用。那什么十哨兵机制呢？

  • 英文名：sentinel，中文名：哨兵。
  • 集群监控：负责主副进程的正常工作。
  • 消息通知：负责将故障信息报警给运维人员。
  • 故障转移：负责将主节点转移到备用节点上。
  • 配置中心：通知客户端更新主节点地址。
  • 分布式：有多个哨兵分布在每个主备节点上，互相协同工作。
  • 分布式选举：需要大部分哨兵都同意，才能进行主备切换。
  • 高可用：即使部分哨兵节点宕机了，哨兵集群还是能正常工作。

坑： 当主节点发生故障时，需要进行主备切换，可能会导致数据丢失。

（1）异步复制数据导致的数据丢失

主节点异步同步数据给备用节点的过程中，主节点宕机了，导致有部分数据未同步到备用节点。而这个从节点又被选举为主节点，这个时候就有部分数据丢失了。

（2）脑裂导致的数据丢失

主节点所在机器脱离了集群网络，实际上自身还是运行着的。但哨兵选举出了备用节点作为主节点，这个时候就有两个主节点都在运行，相当于两个大脑在指挥这个集群干活，但到底听谁的呢？这个就是脑裂。

那怎么脑裂怎么会导致数据丢失呢？如果发生脑裂后，客户端还没来得及切换到新的主节点，连的还是第一个主节点，那么有些数据还是写入到了第一个主节点里面，新的主节点没有这些数据。那等到第一个主节点恢复后，会被作为备用节点连到集群环境，而且自身数据会被清空，重新从新的主节点复制数据。而新的主节点因没有客户端之前写入的数据，所以导致数据丢失了一部分。

避坑指南

  • 配置 min-slaves-to-write 1，表示至少有一个备用节点。
  • 配置 min-slaves-max-lag 10，表示数据复制和同步的延迟不能超过 10 秒。最多丢失 10 秒的数据

注意：缓存雪崩、缓存穿透、缓存击穿并不是分布式所独有的，单机的时候也会出现。所以不在分布式的坑之列。