
这是2024年的第45篇文章
( 本文阅读时间:15分钟 )



-
设置热点数据永远不过期:这要求系统能准确判断哪些是热点数据。 -
加锁或队列:当热点key过期时,不是所有请求都去数据库查询,而是让某一个请求去数据库查询并更新缓存,其他请求等待缓存更新后再访问缓存。

-
缓存数据的过期时间设置为随机,防止很多缓存同时过期。 -
使用高可用的缓存架构,即使缓存服务出现问题,也能通过备份机制快速恢复。 -
设置热点数据静态化,即把访问量较大的数据做静态化处理,减少数据库的访问。
-
三阶段提交(3PC)等分布式事务协议:在分布式系统中保证操作要么全部成功,要么全部失败。 -
分布式锁:通过在操作前获取全局锁,保证同一时刻只有一个操作可以修改数据,从而保障数据一致性。 -
强一致性算法:如Paxos或Raft算法,通过一系列严格的消息传递和确认机制,确保分布式系统中的多个副本能够达到一致状态。
-
异步复制:当数据更新发生时,首先更新主副本,然后异步地将更新同步到其他副本。 -
读取修复(Read Repair):在读取数据的时候检测副本之间的不一致,并在后台异步修复不一致的数据。 -
后台一致性修复进程:定期在后台运行的进程检查和同步数据副本之间的差异,以达到最终一致性。 -
版本控制:每次更新数据时附加一个时间戳或版本号,用于解决更新冲突和保持数据的最终一致性。
-
Write through cache(直写缓存):首先将数据写入缓存,然后立即将新的缓存数据复制到数据库。这种方式可以保证写操作的一致性,但可能会影响写操作的性能。 -
Write back cache(写回缓存):数据首先写入缓存,然后由缓存异步写入数据库。这种方式可以提高写操作的性能,但增加了数据丢失的风险。 -
Write around cache(饶写缓存):绕过缓存,直接写数据库,然后依据需要更新缓存或使缓存失效。这适用于更频繁读取操作的场景。
-
主动更新:当数据库数据变化时,主动更新缓存中的数据。这可以保持缓存数据的实时性,但可能会增加系统的复杂性。 -
定时失效:为缓存数据设置一个过期时间。定期从数据库中重新加载数据,以保持数据的新鲜度。但这无法解决数据在两次加载之间变化导致的一致性问题。 -
惰性加载:只有在请求特定数据且发现缓存失效或缓存中没有该数据时,才去数据库加载该数据。这种策略简单,但在高并发场景下可能会导致缓存击穿。
-
基于订阅的更新:使用消息队列(如Kafka,RabbitMQ)来发布数据库更新,然后相关服务订阅这些更新消息来同步更新缓存。 -
最终一致性:采用最终一致性模型,允许系统在一段时间内是不一致的,但保证经过足够的时间后,系统中的所有复制数据最终将达到一致的状态。
Push中心原方案简介


配置端会增删改pushPlan。

-
tair和数据库不一致 -
投放端的本地缓存和Tair缓存不一致 -
投放端和配置端都用到了Tair缓存,需要是同一个,且key的拼写规则要保持一致 -
配置端采用的缓存一致性方案是:“修改前删缓存,查询后刷新”,删除后会导致投放端的缓存也被删除

-
配置端通过“修改前删缓存,查询后刷新”解决,投放端使用定时任务刷新 -
减少本地缓存过期时间(本地缓存主要是避免缓存穿透和缓存击穿,过期时间可以设置地比较短,业务上可以接受短暂的不一致性) -
谜题就在谜面上
排查过程

解决方案

|
|
|
|
|
|
|
|
|
|
4.2 修改投放端(存在问题)

结语


本篇文章来源于微信公众号:阿里技术
本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。