天猫国际用户Push中心承接了国际用户触达相关的需求，比如短信、端内消息投放等等，并存在较高的并发场景。
该系统此前发现了一个查询投放计划plan为null的异常情况，在初期排查时有些丈二和尚摸不着头脑，后面突然灵光乍现——原来是缓存一致性问题！本文记录一下该问题的排查过程和解决方案，同时带读者朋友们一起回顾下相关的八股文～

一、相关八股文

缓存穿透、缓存击穿、缓存雪崩

缓存穿透、缓存击穿和缓存雪崩都是缓存系统中可能遇到的问题，特别是在高并发的场景下更容易出现。了解它们之间的区别，能帮助我们更好地设计和维护缓存系统，保持系统的稳定性和性能。

• 缓存穿透

定义缓存穿透是指查询一个数据库中不存在的数据，由于缓存不命中（因为数据根本就不存在），请求便会穿过缓存，直接请求数据库。如果有大量此类请求，数据库压力会突然增大，严重时可能会拖垮数据库。

应对策略

1、布隆过滤器：在缓存之前使用布隆过滤器，一种空间效率高的数据结构，用来检测一个元素是否在一个集合中。如果布隆过滤器说不存在，那么就直接返回，不再查询数据库。

2、缓存空结果：如果查不到数据，也将这个“空”结果缓存起来，并设置一个合理的过期时间。

布隆过滤器在缓存前，请以上述文字为主。

• 缓存击穿

定义缓存击穿指一个热点key在缓存中有效期过期的瞬间，大量请求同时涌入数据库去查询这个数据，因为缓存过期这些请求不能被缓存拦截，直接请求到数据库，导致数据库瞬间压力过大。

应对策略

1. 设置热点数据永远不过期：这要求系统能准确判断哪些是热点数据。

2. 加锁或队列：当热点key过期时，不是所有请求都去数据库查询，而是让某一个请求去数据库查询并更新缓存，其他请求等待缓存更新后再访问缓存。

• 缓存雪崩

定义缓存雪崩是指在某一个时间段内，大量的缓存键集中过期失效，导致所有的请求都落到数据库上，造成数据库瞬间压力过大可能到达崩溃的状态。

应对策略

1. 缓存数据的过期时间设置为随机，防止很多缓存同时过期。

2. 使用高可用的缓存架构，即使缓存服务出现问题，也能通过备份机制快速恢复。

3. 设置热点数据静态化，即把访问量较大的数据做静态化处理，减少数据库的访问。

数据一致性问题

数据一致性问题是指当数据在多个地方（如缓存和数据库）存储时，这些地方的数据可能会出现不一致的情况。这种不一致可能是由于缓存更新滞后、系统故障或其他原因引起的。数据一致性是分布式系统设计中的一项挑战，尤其是在读写非常频繁的系统中。

• 数据一致性问题

当数据被更新时，如果缓存中的相应数据没有立即更新，那么缓存系统将向应用程序提供旧数据。这会导致应用程序得到不一致的结果，影响用户体验和数据的准确性。

• 实时强一致性和最终一致性

在分布式系统中，数据一致性是一个核心问题。根据系统的设计与需求，可以选择实时强一致性(Strong Consistency)或最终一致性(Eventual Consistency)。实时强一致性定义：实时强一致性保证了任何时刻，所有的客户端看到的数据都是一样的。在分布式系统中实现强一致性意味着，一个操作一旦完成，所有的客户端立即都能看到这个操作的结果。适用场景：事务性强、对数据一致性要求高的系统，如银行系统或任何财务系统。保障策略：

1. 三阶段提交（3PC）等分布式事务协议：在分布式系统中保证操作要么全部成功，要么全部失败。

2. 分布式锁：通过在操作前获取全局锁，保证同一时刻只有一个操作可以修改数据，从而保障数据一致性。

3. 强一致性算法：如Paxos或Raft算法，通过一系列严格的消息传递和确认机制，确保分布式系统中的多个副本能够达到一致状态。

最终一致性定义：最终一致性是指，系统会保证在没有新的更新操作的情况下，经过足够的时间后，数据将达到一致的状态。在这种模型下，数据的副本之间可能会暂时存在不一致。适用场景：对实时性要求不高，可以容忍短时间内数据不一致的场景，如社交网络、推荐系统等。保障策略：

1. 异步复制：当数据更新发生时，首先更新主副本，然后异步地将更新同步到其他副本。

2. 读取修复（Read Repair）：在读取数据的时候检测副本之间的不一致，并在后台异步修复不一致的数据。

3. 后台一致性修复进程：定期在后台运行的进程检查和同步数据副本之间的差异，以达到最终一致性。

4. 版本控制：每次更新数据时附加一个时间戳或版本号，用于解决更新冲突和保持数据的最终一致性。

• 常见缓存更新/失效策略与一致性解决方案

缓存更新策略

• Write through cache（直写缓存）：首先将数据写入缓存，然后立即将新的缓存数据复制到数据库。这种方式可以保证写操作的一致性，但可能会影响写操作的性能。

• Write back cache（写回缓存）：数据首先写入缓存，然后由缓存异步写入数据库。这种方式可以提高写操作的性能，但增加了数据丢失的风险。

• Write around cache（绕写缓存）：绕过缓存，直接写数据库，然后依据需要更新缓存或使缓存失效。这适用于更频繁读取操作的场景。

缓存失效策略

• 主动更新：当数据库数据变化时，主动更新缓存中的数据。这可以保持缓存数据的实时性，但可能会增加系统的复杂性。

• 定时失效：为缓存数据设置一个过期时间。定期从数据库中重新加载数据，以保持数据的新鲜度。但这无法解决数据在两次加载之间变化导致的一致性问题。

• 惰性加载：只有在请求特定数据且发现缓存失效或缓存中没有该数据时，才去数据库加载该数据。这种策略简单，但在高并发场景下可能会导致缓存击穿。

使用缓存一致性协议

• 基于订阅的更新：使用消息队列（如Kafka，RabbitMQ）来发布数据库更新，然后相关服务订阅这些更新消息来同步更新缓存。

• 最终一致性：采用最终一致性模型，允许系统在一段时间内是不一致的，但保证经过足够的时间后，系统中的所有复制数据最终将达到一致的状态。

分布式缓存系统使用如Redis Cluster、Apache Ignite、Tair等分布式缓存系统，这些系统内置了处理缓存一致性的机制，（但是无法解决缓存和数据库之间的数据一致性问题）。

二、Push中心原方案简介

为了使各应用职责及整体的架构设计更加清晰，Push中心整体将后台配置端和前台投放端分别部署在了两个应用中，两个应用需要分别配置数据库连接，分别配置缓存。

投放端

投放端对于投放计划pushPlan，只有查询流量，没有增删改。由于投放端qps较高，为减少数据库压力，必须使用缓存。同时，为了避免缓存击穿和缓存穿透，我们用本地缓存和tair组成了二级缓存，并使用定时任务定时将数据库中的数据刷新到tair。（注：不了解tair的话，可以简单理解为和redis类似）

 配置端

配置端会增删改pushPlan。

问题描述

梳理到这里，其实很容易发现潜在的不一致性问题：

1. tair和数据库不一致；

2. 投放端的本地缓存和Tair缓存不一致；

3. 投放端和配置端都用到了Tair缓存，需要是同一个，且key的拼写规则要保持一致；

4. 配置端采用的缓存一致性方案是：“修改前删缓存，查询后刷新”，删除后会导致投放端的缓存也被删除；

本次的问题便出现在第4点：一旦数据在配置端被修改，那么在投放端本地缓存过期后，定时任务刷新tair前，查询出来的数据便是null，导致异常。