3. 微服务拆分对缓存的影响：服务边界划分导致的数据碎片化、跨服务缓存共享的困境

微服务架构通过服务边界划分实现了业务逻辑的解耦与独立部署，但这种拆分对缓存系统带来了深远的影响。原本在单体架构中统一管理的缓存数据，随着服务边界的切割，被分散到多个独立的服务实例中，形成了数据碎片化。同时，跨服务的业务链路往往需要访问同一份数据，但服务边界又天然阻断了直接的缓存共享，从而引发了跨服务缓存共享的困境。本章将深入剖析这两个核心问题。

3.1 服务边界划分导致的数据碎片化

在单体应用中，所有模块共享同一个缓存空间（如一个 Redis 集群），数据以全局视角进行组织。微服务拆分后，每个服务拥有独立的数据库和缓存实例，原本完整的数据实体被按服务边界切分，导致以下碎片化问题：

• 数据冗余与不一致：同一份用户基础信息，可能同时被用户服务、订单服务、营销服务各自缓存一份副本。当用户服务更新数据后，其他服务的缓存无法自动失效，产生数据不一致。
• 缓存命中率下降：碎片化导致每个服务只能缓存自己视角下的数据子集。跨服务查询时，需要多次穿透到源服务或数据库，整体缓存命中率降低。
• 管理复杂度上升：运维人员需要管理 N 套缓存集群或命名空间，监控、调优、故障排查的难度成倍增加。

3.2 跨服务缓存共享的困境

业务场景要求多个服务协同访问同一份缓存数据，但服务边界带来了以下三大困境：

3.3 数据碎片化与共享困境的关联模型

下图展示了微服务拆分后，缓存数据碎片化与跨服务共享困境的典型结构。三个服务各自维护独立的缓存区域，但业务请求需要跨越服务边界获取完整数据，导致缓存穿透与数据不一致问题。

3.4 碎片化带来的缓存一致性挑战

数据碎片化直接导致了缓存一致性维护的复杂度呈指数级上升。以下是三种典型的挑战场景：

1. 写扩散问题：当服务 A 更新了用户手机号，它需要通知所有可能缓存了该用户信息的服务（B、C、D...）进行失效或更新。这种“写扩散”模式增加了服务间的耦合与网络开销。
2. 读时合并冲突：服务 B 在读取订单数据时，需要同时从服务 A 获取用户信息。如果服务 A 的缓存刚好失效，服务 B 必须等待服务 A 回源数据库，导致响应延迟增加。
3. 最终一致性窗口不可控：使用消息队列进行缓存失效通知时，从数据更新到所有缓存副本失效之间存在时间窗口。在高并发场景下，这个窗口内的读请求可能获取到脏数据。

3.5 跨服务缓存共享的常见反模式

在实践中，团队为了快速解决跨服务缓存共享问题，容易采用以下反模式，这些做法虽然短期内有效，但长期会破坏服务自治性：

3.6 从碎片化到一致性边界移植的思考

面对上述困境，业界逐渐形成了一种新的解决思路——缓存一致性边界移植。其核心思想是：不试图在服务边界之上建立全局缓存，而是将缓存一致性问题的解决边界，从“跨服务”移植到“服务内部”或“数据层”。具体方向包括：

• 数据下沉：将高频共享的数据（如用户基础信息）从多个服务中抽离，下沉为一个独立的“数据基础服务”，由该服务统一管理缓存与一致性。
• 变更事件驱动：服务只负责更新自己的数据库，通过 CDC（Change Data Capture）或领域事件，将数据变更推送到消息队列，其他服务监听事件后更新自己的本地缓存。
• 缓存代理层：引入统一的缓存代理（如 Redis Cluster + Proxy），在代理层实现跨服务的数据路由与一致性协议，对服务透明。