唯泰客DB读写分离下Redis缓存不当使用的 bug 分析

Posted 2021-05-02 唯品会质量工程

一周前发现订单 Order 系统从 LPC 取商品大小件信息时，得到的数据异常。而相关的信息确实从 WMS 中进行了同步，顿时觉得一头雾水。后经查实，是因为主从库主从不一致的问题，导致缓存未及时更新。

问题方案

下图是 bug 发生时的方案：

在有数据更新时，Master先同步Slave，然后在从Slave上将数据写到Redis上。对于Redis上没有的缓存数据，将发生回源操作，按我们的读写分离规则，此时Redis会从Slave上查数据并缓存。

该方案因DB主从库同步有一定的延迟，在主从库的数据不一致时，也会导致缓存中的数据没有及时更新。比如在商品大小件数据还没有同步到 Slave 上时，订单Order系统从缓存 Redis 读取相应的商品信息时，会取不到数据。

读写分离: 让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），从数据库处理SELECT查询操作。读写分离可以提高数据库的处理事务的性能，但因主从库同步有延时，可能引起主从库不一致的问题。

修正方案

下图是修改后的方案：

在有数据更新时，Master在同步Slave的同时也将数据写入到Redis缓存中。对于Redis上没有的缓存数据，按相同的回源操作，从Slave上查数据并缓存。

其实，在缓存的使用上，特别需要注意缓存的更新和回源，一般要保证以下两点 ：

• 修改DB时，必须同时修改缓存。

• 在缓存读取不到数据，就必须回源去从DB获取信息。

而原先的方案正因为未考虑到同步修改缓存，从而导致数据的异常。

质量的思考

• QA要去了解项目中涉及缓存一块处理的实现机制，跟架构、研发一起review架构设计，保证缓存的预热机制、缓存的更新和回源机制不出问题。

• 从项目管理的角度，要把缓存预热的方案纳入项目上线计划（特别是当项目第一次上线涉及庞大数据量的同步问题时），确保在项目上线前数据得到了及时的同步。

• 对DB -> 缓存的核心逻辑，QA一方面要督促研发写单元测试去保证数据的一致性，另一方面QA更要从这个核心逻辑去做代码review和用例设计。

扩展：Redis使用场景

先去REDIS中判断数据是否存在，如果存在，则直接返回缓存好的数据。而如果不存在的话，就会去数据库中，读取数据，并把数据缓存到REDIS中。

• 适用场合：如果数据量比较大，但不是经常更新的情况

该场景主要目的是把REDIS当作数据库使用，更新获取数据比DB快。

• 适用场合：非常适合大数据量的频繁变动。

• 缺点：对REDIS的依赖很大，要做好宕机时的数据保存。