缓存失效状况举例看下这个段伪代码：仿制代码代码如下:local value = get_from_cache(key)if not value then value = query_db(sql) set_to_cache(value， timeout ＝ 100)endreturn value看上去没有问题，在单元测验状况下，也不会有反常。可是，进行压力测验的时分，你会发现，每隔100秒，数据库的查询就会呈现一次峰值。假如你的cache失效时刻设置的比较长，那么这个问题被发现的机率就会下降。为什么会呈现峰值呢？幻想一下，在cache失效的瞬间，假如并发恳求有1000条一起到了 query_db(sql) 这个函数会怎样？没错，会有1000个恳求打向数据库。这便是缓存失效瞬间引起的风暴。它有一个英文名，叫 "dog-pile effect"。怎样处理？天然的主意是发现缓存失效后，加一把锁来操控数据库的恳求。详细的细节，春哥在lua-resty-lock的文档里边做了详细的阐明，我就不重复了，请看这儿。多说一句，lua-resty-lock库自身现已替你完结了wait for lock的进程，看代码的时分需求注意下这个细节。

传统缓存失效应对战略为了进步事务拜访速度，提高事务读并发，许多用户都会在事务架构中引进缓存层。事务一切读恳求悉数路由到缓存层，经过缓存的内存读取机制大大提高事务读取功用。缓存中的数据不能耐久化 ，一旦缓存反常退出，那么内存中的数据就会丢掉，所以为了确保数据完好，事务的更新数据会落地到耐久化存储中，例如DB。现在云用户的事务架构一般如下图：

在上图中，咱们能够看到，用户的更新数据直接耐久化到DB, 事务读恳求直接恳求缓存数据，所以事务需求处理缓存失效问题，即处理由于数据改变导致缓存中的数据失效的问题。 现在事务处理缓存失效问题的处理方法一般是事务完结DB、缓存双写。经过事务双写处理缓存失效，存在如下的问题：代码侵入性比较强，需求双写两份存储，任何对DB的数据改变，都需求一起更新缓存，代码层面后期可保护程度不高用户恳求线程里同步调用缓存，对缓存存在强以来，遇到缓存超时等反常时，没有办法做到有用的重试，遇到反常给用户回来体系过错、操作失利等信息，严重影响用户体会用户恳求线程里同步完结DB、缓存双写，改变恳求链路长，拜访推迟大，影响用户体会RDS数据订阅消费，轻松处理缓存失效在阿里巴巴内部相同也遇到了缓存失效的问题，跟着事务架构得不断调整优化，咱们现已沉积出一套高牢靠、极高雅得缓存失效架构。即经过数据传输供给的数据订阅功用，异步获取DB（例如公共云上的RDS）的增量数据，依据增量数据进行缓存失效。详细的架构相似下图：

在这个架构里边，缓存更新流程如下：1.事务完结DB更新后即回来恳求2.数据订阅经过日志解析方法实时解析并订阅DB的增量更新数据，当发现DB有数据更新时，将增量数据推送给下流顾客3.下流消费事务一旦接收到增量更新数据，即调用消费线程进行缓存更新至此完结整个缓存更新进程。从上面的缓存失效流程，能够看出这种缓存失效机制：1.更新途径短，推迟低： 缓存失效为异步流程，事务更新DB完结后直接回来，不需求关怀缓存失效流程，整个更新途径短，更新推迟低2.使用简略牢靠：使用无需完结杂乱双写逻辑，只需发动异步线程监听增量数据，更新缓存数据即可3.使用更新无功用耗费：由于数据订阅是经过解析DB的增量日志来获取增量数据，获取数据的进程对事务、DB功用无损

小结数据订阅功用为阿里云数据传输供给的一种数据分发方法。经过数据订阅完结的缓存失效战略，让事务更新更方便，让事务逻辑更简略、更牢靠。数据订阅仅仅数据传输供给的一种传输方法，除数据订阅之外，数据传输还供给了数据实时同步，不断服搬迁等多种传输才能，如需了解数据传输更多概况，请猛击数据传输。