面试题：缓存设计之专家难度：结合业务场景深入分析Memcached与Redis的一致性保证及选型策略

原理：Memcached 本身不支持数据持久化，数据仅存在于内存中，采用简单的缓存更新策略，当数据发生变化时，直接在缓存中删除或更新对应 key - value 对。但它不具备复杂的一致性协议或机制来保证数据一致性。
优点：
- 简单高效，读写速度极快，在高并发场景下性能出色，能快速响应缓存读写请求。
- 架构简单，易于部署和维护，内存管理相对简单，适合处理大量的小数据对象缓存。
缺点：
- 不支持数据持久化，一旦服务器重启或故障，缓存数据全部丢失，可能导致数据一致性问题。
- 缺乏复杂的一致性保证机制，在数据更新频繁场景下，可能出现缓存与数据库数据不一致情况，且难以自动恢复一致性。

原理：
- 持久化机制：Redis 支持 RDB（快照）和 AOF（追加式文件）两种持久化方式，RDB 定期将内存数据以快照形式保存到磁盘，AOF 则是将每次写操作追加到文件末尾，通过这两种方式在服务器重启后可恢复数据，一定程度保证数据一致性。
- 主从复制与集群：在主从复制架构中，主节点负责写操作并将写命令同步给从节点，从节点进行读操作。集群模式下，数据分布在多个节点，通过 Gossip 协议等维护节点状态一致性。
优点：
- 支持多种数据结构，功能丰富，适用于复杂业务场景，如电商购物车可使用 Redis 的哈希结构存储商品信息。
- 具备持久化机制，能有效防止数据丢失，提高数据一致性保障。
- 主从复制和集群模式下，可扩展性强，通过主从同步和集群数据分片，提高系统读写性能和可用性，同时在一定程度上保证数据一致性。
缺点：
- 主从复制存在一定延迟，在主从同步过程中，可能出现主从数据不一致情况，尤其是网络延迟高时。
- 集群模式下，数据分布和一致性维护相对复杂，如集群节点故障恢复过程中可能出现短暂数据不一致。

在电商业务涉及商品库存缓存、用户购物车缓存场景下，选择 Redis 更合适。原因如下：

数据持久化需求：电商业务对数据一致性要求较高，Redis 的持久化机制可保证在服务器故障重启后，缓存数据不会完全丢失，减少因缓存数据丢失导致与数据库不一致的风险。例如商品库存缓存，若 Memcached 服务器故障，库存缓存数据丢失，再次读取可能从数据库获取旧数据，而 Redis 可通过持久化恢复数据，保持与数据库相对一致。
数据结构丰富：购物车缓存中，Redis 的哈希结构可方便存储用户购物车中不同商品信息，包括商品 ID、数量、价格等，操作方便且高效。而 Memcached 仅支持简单 key - value 存储，难以满足这种复杂结构需求。
集群与扩展性：随着电商业务规模扩大，对缓存的读写性能和可用性要求更高。Redis 的主从复制和集群模式可满足水平扩展需求，通过主从同步和集群数据分布，保证数据一致性和系统高可用性，适应高并发读写场景。

主从复制延迟导致的数据不一致：
- 解决方案：
  - 读写分离策略调整：对于一些对一致性要求极高的操作，如库存扣减等写操作后，短暂强制读主节点，确保读到最新数据。待主从同步完成后，再恢复从节点读操作。
  - 缓存过期时间设置：合理设置缓存过期时间，在主从数据不一致期间，若客户端读取到旧数据，当缓存过期后，重新从数据库读取最新数据并更新缓存，恢复一致性。
集群节点故障恢复导致的数据不一致：
- 解决方案：
  - 使用 Redlock 算法：在分布式环境下，通过多个 Redis 节点实现分布式锁，保证在集群节点故障恢复等异常情况下，关键数据操作的原子性和一致性。例如在库存缓存更新时，先获取 Redlock，确保同一时间只有一个客户端能进行库存更新操作。
  - 监控与自动修复脚本：建立监控系统实时监测集群节点状态和数据一致性情况，当发现数据不一致时，自动触发修复脚本，通过从数据库重新同步数据等方式恢复一致性。

星途面试题库