数据库与缓存一致性方案分享

￡神魔★判官ぃ 2024-05-06 09:41 64阅读 0赞

**目录**

?前言?

?正文?

?业务耦合的一致性方案?

?业务中耦合更新缓存?

??业务中耦合删除缓存??

??业务解耦的一致性方案??

?引入定时任务与数据校验机制的binlog缓存更新机制?

???结语???

--------------------

## [?][Link 1]前言[?][Link 1] ##

做C端相关业务，目前主流的关系型数据库在高并发的查询请求场景下，很难做到低延迟的高并发，甚至有可能被打挂。因此引入缓存中间件是一个常见的解决方案，但如何保证缓存与数据库的一致性，便成为了一个棘手的问题，这次我们拿常见的Mysql和Redis举例。

## [?][Link 1]正文[?][Link 1] ##

保持缓存和数据库的一致性，最简单的做法就是直接在业务中去双写或删除保持一致性；如果要跟业务解耦，就要采用订阅binlog或者定时刷新的方式完成。

### [?][Link 1]业务耦合的一致性方案[?][Link 1] ###

#### [?][Link 1]业务中耦合更新缓存[?][Link 1] ####

其中一种常见的方案是`更新缓存`，当数据变更时更新对应缓存数据到缓存中，该行为可以在同一个业务中也可用消息中间件解耦。当查询请求来时，就直接查询缓存返回数据，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_17_color_FFFFFF_t_70_g_se_x_16][]

弊端：

1.  当出现并发数据变更时，如A、B对同一行数据进行变更，A先变更完成，接着B变更完成，B更新缓存，A更新缓存。数据库中的数据是B的数据，但是缓存中却是A的数据。
2.  与业务耦合不可取，增加业务复杂性以及依赖的中间件。

#### [?][Link 1][?][Link 1]业务中耦合删除缓存[?][Link 1][?][Link 1] ####

其实无论是前置更新还是后置更新缓存，在一些并发的极端场景都会出现缓存不一致的问题（思考一下前置更新），所以一个可以走的路子是`删除缓存`。当数据变更后，删除对应key的缓存，缓存的更新由C端业务来保证，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_17_color_FFFFFF_t_70_g_se_x_16 1][]

使用删除缓存的方式，不管数据变更这里的修改并发有多高，都能保证最终C端查询处放入的缓存是正确的，跟数据库保持一致的。

弊端：

1.  对于删除缓存来说，一个明显的弊端在于当第二步删除缓存时，如果数据查询这里保持较高的流量，那么就会有一大批的请求透过缓存打到db中，还是有极大的风险；
2.  依旧是未与业务解耦。

### [?][Link 1][?][Link 1]业务解耦的一致性方案[?][Link 1][?][Link 1] ###

对于Mysql来说，如果要做到与业务解耦，首先想到的肯定是binlog，因为binlog毕竟记录了全量真实落库的数据，将自己伪装成一个从节点，订阅binlog就能完成业务上的解耦，如下图：

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_16_color_FFFFFF_t_70_g_se_x_16][]

如上图说示，此时的缓存被视为db中的一份完整的镜像数据，但是仍旧无法避免并发场景下多线程消费binlog导致的缓存不一致问题。

#### ?引入定时任务与数据校验机制的binlog缓存更新机制? ####

那如何能解决binlog监听时的数据乱序问题，并且有一定的容错机制保证缓存的最终一致性？

如下图所示，我们基于之前的binlog监听方案新增了两处改动。

1.  通过监听消费binlog时记录binlog产生时间，并且每次对比binlog时间解决多线程消费的情况下，缓存和db数据最终不一致的问题；
2.  由于每次update都会产生binlog，那么对于配置表的全表update（非业务字段，如set update\_time=now()）即可完成数据全量更新同步至缓存，通过定时任务定时触发，这样就能给业务带来更高的容错性。

##  ##

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_20_color_FFFFFF_t_70_g_se_x_16][]

## ???结语??? ##

没有完美的方案，只有最适合自己业务的方案，如果当前基建较弱并且工期较短，那么跟业务耦合的缓存删除方案就基本满足大多数场景；如果工期满足，则可以探索一些更好的一致性方案，甚至引入`分布式事务`来保证缓存数据的更新，也未尝不可。

最近的一些业务需求，与缓存打交道较多，后续会持续更新热点key、大key的一些方案分享。

[Link 1]: https://blog.csdn.net/sqL520lT/article/details/122424527?spm=1001.2014.3001.5501#t1
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_17_color_FFFFFF_t_70_g_se_x_16]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/02438a6ed71849b3a8f4dd00d8d89cf0.png
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_17_color_FFFFFF_t_70_g_se_x_16 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/d4accbfef0804b3fa2a1aad9c50bb36e.png
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_16_color_FFFFFF_t_70_g_se_x_16]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/13305a61ae6b4bb49812d2bb0977f916.png
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5o6C5o6C5LiJ55Sf5pyJ5bm4_size_20_color_FFFFFF_t_70_g_se_x_16]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/06/260657fd048340b080b153f5d113d04d.png