数据传输提供的数据订阅功能，可以在不影响业务的情况下，实现简单、可靠的缓存失效逻辑。这种缓存失效机制为阿里巴巴多年架构优化沉淀下来的经验，下面我们一起来看数据订阅究竟怎么实现这种机制。
传统缓存失效策略
为了提高业务访问速度，提升业务读并发，很多用户都会在业务架构中引入缓存层。业务所有读请求全部路由到缓存层，通过缓存的内存读取机制大大提升业务读取性能。缓存中的数据不能持久化 ，一旦缓存异常退出，那么内存中的数据就会丢失，所以为了保证数据完整，业务的更新数据会落地到持久化存储中，例如DB。目前云用户的业务架构一般如下图：
在上图中，大家可以看到，用户的更新数据直接持久化到DB, 业务读请求直接请求缓存数据，所以业务需要解决缓存失效问题，即解决因为数据变更导致缓存中的数据失效的问题。 目前业务解决缓存失效问题的解决方法一般是业务实现DB、缓存双写。通过业务双写解决缓存失效，存在如下的问题：
- 代码侵入性比较强，需要双写两份存储，任何对DB的数据变更，都需要同时更新缓存，代码层面后期可维护程度不高
- 用户请求线程里同步调用缓存，对缓存存在强以来，遇到缓存超时等异常时，没有办法做到有效的重试，遇到异常给用户返回系统错误、操作失败等信息，严重影响用户体验
- 用户请求线程里同步完成DB、缓存双写，变更请求链路长，访问延迟大，影响用户体验
RDS数据订阅消费，轻松解决缓存失效
在阿里巴巴内部同样也遇到了缓存失效的问题，随着业务架构得不断调整优化，我们已经沉淀出一套高可靠、极优雅得缓存失效架构。即通过数据传输提供的数据订阅功能，异步获取DB（例如公共云上的RDS）的增量数据，根据增量数据进行缓存失效。具体的架构类似下图：
在这个架构里面，缓存更新流程如下：
- 业务完成DB更新后即返回请求
- 数据订阅通过日志解析方式实时解析并订阅DB的增量更新数据，当发现DB有数据更新时，将增量数据推送给下游消费者
- 下游消费业务一旦接收到增量更新数据，即调用消费线程进行缓存更新
至此完成整个缓存更新过程。
从上面的缓存失效流程，可以看出这种缓存失效机制：
- 更新路径短，延迟低： 缓存失效为异步流程，业务更新DB完成后直接返回，不需要关心缓存失效流程，整个更新路径短，更新延迟低
- 应用简单可靠：应用无需实现复杂双写逻辑，只需启动异步线程监听增量数据，更新缓存数据即可
- 应用更新无性能消耗：因为数据订阅是通过解析DB的增量日志来获取增量数据，获取数据的过程对业务、DB性能无损
