共计 3228 个字符,预计需要花费 9 分钟才能阅读完成。
请抬起你的头,我的公主,不然皇冠会掉下来的。
分布式缓存是当初很多分布式应用中必不可少的组件,然而用到了分布式缓存,就可能会波及到缓存与数据库双存储双写,你只有是双写,就肯定会有数据一致性的问题,那么你如何解决一致性问题?
Cache Aside Pattern
最经典的缓存 + 数据库读写的模式,就是 Cache Aside Pattern。
读的时候,先读缓存,缓存没有的话,就读数据库,而后取出数据后放入缓存,同时返回响应。
更新的时候,先更新数据库,而后再删除缓存。
为什么是删除缓存,而不是更新缓存?
起因很简略,很多时候,在简单点的缓存场景,缓存不单单是数据库中间接取出来的值。
比方可能更新了某个表的一个字段,而后其对应的缓存,是须要查问另外两个表的数据并进行运算,能力计算出缓存最新的值的。
另外更新缓存的代价有时候是很高的。是不是说,每次批改数据库的时候,都肯定要将其对应的缓存更新一份?兴许有的场景是这样,然而对于比较复杂的缓存数据计算的场景,就不是这样了。如果你频繁批改一个缓存波及的多个表,缓存也频繁更新。然而问题在于,这个缓存到底会不会被频繁拜访到?
举个栗子,一个缓存波及的表的字段,在 1 分钟内就批改了 20 次,或者是 100 次,那么缓存更新 20 次、100 次;然而这个缓存在 1 分钟内只被读取了 1 次,有大量的冷数据。实际上,如果你只是删除缓存的话,那么在 1 分钟内,这个缓存不过就从新计算一次而已,开销大幅度降低,用到缓存才去算缓存。
其实删除缓存,而不是更新缓存,就是一个 lazy 计算的思维,不要每次都从新做简单的计算,不论它会不会用到,而是让它到须要被应用的时候再从新计算。像 mybatis,hibernate,都有懒加载思维。查问一个部门,部门带了一个员工的 list,没有必要说每次查问部门,都外面的 1000 个员工的数据也同时查出来啊。80% 的状况,查这个部门,就只是要拜访这个部门的信息就能够了。先查部门,同时要拜访外面的员工,那么这个时候只有在你要拜访外面的员工的时候,才会去数据库外面查问 1000 个员工。
最高级的缓存不统一问题及解决方案
问题:先批改数据库,再删除缓存。如果删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就呈现了不统一。
解决思路:先删除缓存,再批改数据库。如果数据库批改失败了,那么数据库中是旧数据,缓存中是空的,那么数据不会不统一。因为读的时候缓存没有,则读数据库中旧数据,而后更新到缓存中。
比较复杂的数据不统一问题剖析
数据产生了变更,先删除了缓存,而后要去批改数据库,此时还没批改。一个申请过去,去读缓存,发现缓存空了,去查询数据库,查到了批改前的旧数据,放到了缓存中。随后数据变更的程序实现了数据库的批改。
完了,数据库和缓存中的数据不一样了。。。
为什么上亿流量高并发场景下,缓存会呈现这个问题?
只有在对一个数据在并发的进行读写的时候,才可能会呈现这种问题。其实如果说你的并发量很低的话,特地是读并发很低,每天访问量就 1 万次,那么很少的状况下,会呈现方才形容的那种不统一的场景。然而问题是,如果每天的是上亿的流量,每秒并发读是几万,每秒只有有数据更新的申请,就可能会呈现上述的数据库 + 缓存不统一的状况。
解决方案如下:
更新数据的时候,依据数据的惟一标识,将操作路由之后,发送到一个 jvm 外部队列中。读取数据的时候,如果发现数据不在缓存中,那么将从新读取数据 + 更新缓存的操作,依据惟一标识路由之后,也发送同一个 jvm 外部队列中。
一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,而后一条一条的执行。这样的话,一个数据变更的操作,先删除缓存,而后再去更新数据库,然而还没实现更新。此时如果一个读申请过去,读到了空的缓存,那么能够先将缓存更新的申请发送到队列中,此时会在队列中积压,而后同步期待缓存更新实现。
这里有一个优化点,一个队列中,其实多个更新缓存申请串在一起是没意义的,因而能够做过滤,如果发现队列中曾经有一个更新缓存的申请了,那么就不必再放个更新申请操作进去了,间接期待后面的更新操作申请实现即可。
待那个队列对应的工作线程实现了上一个操作的数据库的批改之后,才会去执行下一个操作,也就是缓存更新的操作,此时会从数据库中读取最新的值,而后写入缓存中。
如果申请还在等待时间范畴内,一直轮询发现能够取到值了,那么就间接返回;如果申请期待的工夫超过肯定时长,那么这一次间接从数据库中读取以后的旧值。
高并发的场景下,该解决方案要留神的问题:
1、读申请长时阻塞
因为读申请进行了十分轻度的异步化,所以肯定要留神读超时的问题,每个读申请必须在超时工夫范畴内返回。
该解决方案,最大的危险点在于说,可能数据更新很频繁,导致队列中积压了大量更新操作在外面,而后读申请会产生大量的超时,最初导致大量的申请间接走数据库。务必通过一些模仿实在的测试,看看更新数据的频率是怎么的。
另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因而须要依据本人的业务状况进行测试,可能须要部署多个服务,每个服务摊派一些数据的更新操作。如果一个内存队列里竟然会挤压 100 个商品的库存批改操作,每隔库存批改操作要消耗 10ms 去实现,那么最初一个商品的读申请,可能期待 10 * 100 = 1000ms = 1s 后,能力失去数据,这个时候就导致读申请的长时阻塞。
肯定要做依据理论业务零碎的运行状况,去进行一些压力测试,和模仿线上环境,去看看最忙碌的时候,内存队列可能会挤压多少更新操作,可能会导致最初一个更新操作对应的读申请,会 hang 多少工夫,如果读申请在 200ms 返回,如果你计算过后,哪怕是最忙碌的时候,积压 10 个更新操作,最多期待 200ms,那还能够的。
如果一个内存队列中可能积压的更新操作特地多,那么你就要加机器,让每个机器上部署的服务实例解决更少的数据,那么每个内存队列中积压的更新操作就会越少。
其实依据之前的我的项目教训,一般来说,数据的写频率是很低的,因而实际上失常来说,在队列中积压的更新操作应该是很少的。像这种针对读高并发、读缓存架构的我的项目,一般来说写申请是非常少的,每秒的 QPS 能到几百就不错了。
理论粗略测算一下
如果一秒有 500 的写操作,如果分成 5 个工夫片,每 200ms 就 100 个写操作,放到 20 个内存队列中,每个内存队列,可能就积压 5 个写操作。每个写操作性能测试后,个别是在 20ms 左右就实现,那么针对每个内存队列的数据的读申请,也就最多 hang 一会儿,200ms 以内必定能返回了。
通过方才简略的测算,咱们晓得,单机撑持的写 QPS 在几百是没问题的,如果写 QPS 扩充了 10 倍,那么就扩容机器,扩容 10 倍的机器,每个机器 20 个队列。
2、读申请并发量过高
这里还必须做好压力测试,确保凑巧碰上上述情况的时候,还有一个危险,就是忽然间大量读申请会在几十毫秒的延时 hang 在服务上,看服务能不能扛的住,须要多少机器能力扛住最大的极限状况的峰值。
然而因为并不是所有的数据都在同一时间更新,缓存也不会同一时间生效,所以每次可能也就是多数数据的缓存生效了,而后那些数据对应的读申请过去,并发量应该也不会特地大。
3、多服务实例部署的申请路由
可能这个服务部署了多个实例,那么必须保障说,执行数据更新操作,以及执行缓存更新操作的申请,都通过 Nginx 服务器路由到雷同的服务实例上。
比如说,对同一个商品的读写申请,全副路由到同一台机器上。能够本人去做服务间的依照某个申请参数的 hash 路由,也能够用 Nginx 的 hash 路由性能等等。
4、热点商品的路由问题,导致申请的歪斜
万一某个商品的读写申请特地高,全部打到雷同的机器的雷同的队列外面去了,可能会造成某台机器的压力过大。就是说,因为只有在商品数据更新的时候才会清空缓存,而后才会导致读写并发,所以其实要依据业务零碎去看,如果更新频率不是太高的话,这个问题的影响并不是特地大,然而确实可能某些机器的负载会高一些。