知道缓存读写策略你也可以撩开发？

Posted 2021-04-14 鲁德

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了知道缓存读写策略你也可以撩开发？相关的知识，希望对你有一定的参考价值。

通过前面的一系列缓存的知识介绍，我们知道了缓存的知识体系，知道了用户层的缓存都有那些以及原理是什么。

详见鲁德公号文章：

l 不了解缓存别说你做过性能测试-I

l 不懂缓存别你说懂性能测试之用户层缓存

今天我们来介绍缓存的“缓存的读写策略”。作为性能测试工程师，这个是要掌握的一个知识点，这是迈向资深性能测试工程师、架构师等的一个必经点。

不了解系统架构，是做不好性能测试的。可以这么说不了解系统架构，功能测试都做不好，比如要测试系统是否支持高可用性，冷启动是系统表现怎样？缓存穿透，缓存雪崩时系统表现怎样，这些都是要关注的。

本文以Redis + mysql 这一典型架构为例，为大家介绍缓存的读写策略。

话不多少，进入主题。

你可能觉得缓存的读写很简单，只需要优先读缓存，缓存不命中就从数据库查询，查询到了就回到缓存。实际上，针对不同的业务场景，缓存的读写策略也是不同的。

Cache Aside（旁路缓存）策略

这是应用最广泛的策略了。不考虑采用旁路策略的情况下，很多人更新缓存和数据库的方式无外乎两种：

l 先更新数据库，再同步更新缓存；

l 先更新缓存，同步更新数据库（两者作为一个原子操作）；

如果是采用这两种方式中任的一种，恭喜你，在客户端多线程并发的时候数据不一致的情况产生了。这种情况下，产生的数据不一致，测试的时候，还很难测试出来（功能测试发现不了，性能测试也会因为测试数据过大，对中间过程的关注过少而被忽略）。为了解决数据不一致（缓存和数据库中数据不一样的情况），我们的旁路策略可以登场了，我们必须从白盒的角度对这类问题加以关注（一些问题从黑盒测试的角度来触发效果更好，一些问题则从白盒测试的角度来关注更好，缓存和数据库数据不一致的问题，则是后者）。

旁路策略数据更新时，对缓存中数据不操作更新操作，而是直接删除。整个过程如下所示：

l 写操作：

数据先写到数据库中，缓存中直接删除；

l 读操作：

读数据，如果命中缓存则把缓存中的数据直接返回给客户端；如果没有命中，从数据库中读出数据，写到缓存中，然后再把缓存中的数据返回给客户端。

使用旁路策略，有效解决了Redis + MySQL这种架构中数据不一致的问题。但如果系统业务写入频繁，会出现缓存命中率过低的情况，这会影响系统的性能。为解决这一问题，也有两种方案作为补充。

一种是：

更新数据库的时候，也同步更新缓存，两者作为一个原子操作，通过分布式锁来实现数据一致性的保障。

另一种是：

更新数据库时同步更新数据时更新缓存，缓存设置一个很短的过期时间，这样即使出现缓存不一致的情况，缓存的数据也会很快过期，对业务的影响降到最低。

Read/Write Through(读穿/写穿)策略

在旁路策略中，开发在数据读写的时候，既要和数据库打交道，也要和缓存做交付。过程相对复杂，容易造成数据不一样。

而采用了Read/Write Through(读穿/写穿)策略，开发只需要和缓存打交道，缓存只会数据库打交道。这样一个复杂的数据同步问题，就被有效解决了。

Read/Write Through(读穿/写穿)策略是这样的：查询要写入的数据是否在缓存中，如果在，则更新缓存中的数据，再有缓存组件同步更新到数据库中。对于读操作，策略是：查询要读的数据是否在缓存中存在，存在直接返回给客户端，如果不存在则由缓存组件把数据从数据库读出来放在缓存里面，最后再从缓存里面把数据返回给客户端。

显然采用这种缓存读写策略，需要缓存组件之间这样的功能，而我们工作中接触到缓存组件（memcache、Redis）并不支持这个功能，所以这个策略在实际工作中应用并不是太多。因此对于缓存的读写策略而已，我们重点掌握旁路策略即可。

每一篇文章都来自鲁德精心原创，如果文章能帮到你，欢迎转发和点赞，让更多的朋友受益！跟着鲁德一起，每天进步一点点，终会质变！让你面试拿高薪！

恭喜【成都】季同学，从报名时的薪资10k，跳槽至18K，涨幅80%