Redis在电商系统中的正确打开方式

白菜Java自习室 涵盖核心知识

Redis在电商系统中的作用不必多说，甚至能称得上是缓存银弹。

Redis常见工具

1. Redisson
2. RedisTemplate
3. 自行封装RedisClient
4. @Cacheable、@CacheEvict、@CachePut

电商系统为了支持高并发，大家都会使用Redis作为缓存服务，很多场景下运用不当反而会适得其反，徒增系统的负担。你真的用对了吗？

下面就来例举几种常见的缓存的读写模式和使用场景：

Cache-Aside模式

Cache-Aside可能是项目中最常见的一种模式。它是一种控制逻辑都实现在应用程序中的模式。缓存不和数据库直接进行交互，而是由应用程序来同时和缓存以及数据库打交道。Cache-Aside的名字正体现了这个模式，Cache在应用的一旁(aside)。

说明： 这应该是大家用的最多的一种缓存模式了。如同@Cacheable、@CacheEvict、@CachePut类似，大家可能会封装自己的Redis工具类，最终的读写方式可能殊途同归于这种模式。这种模式只适用于流量和并发不高的常规性缓存，加快站点的响应和加载速度。

读数据策略：

1. 程序需要判断缓存中是否已经存在数据。
2. 当缓存中已经存在数据(也就是缓存命中，cache hit)，则直接从缓存中返回数据
3. 当缓存中不存在数据(也就是缓存未命中，cache miss)，则先从数据库里读取数据，并且存入缓存，然后返回数据

image

写数据策略：

一、 @CachePut类似操作

1. 更新数据库
2. 更新缓存

这种策略有线程安全的问题，可能出现缓存和数据库不一致。试想有两个写的线程，线程A和线程B

1. A写数据库
2. B后于A写数据库
3. B写缓存
4. A写缓存
5. 缓存和数据库中的数据不一致，缓存中的是脏数据

要解决线程安全的问题，我们可以加分布式锁，不过实现起来比较麻烦。

二、 @CacheEvict类似操作

1. 更新数据库
2. 删除缓存中对应的数据

这种写策略会有线程安全的问题吗？有，试想一下有两个线程，线程A读，线程B写

1. A读数据，由于未命中那么从数据库中取数据
2. B写数据库
3. B删除缓存
4. A由于网络延迟比较慢，将脏数据写入缓存

这种情况可能性非常的小，需要同时满足很多条件，近乎不太可能发生，所以我们一般都采用这种写策略。另外可以对缓存中的数据设置合适的过期时间，即使发生的脏数据的情况，也不会发生很长时间。

优点

1. 缓存仅仅保存被请求的数据，属于懒加载模式(Lazy Loading)，和下文的Write-Through模式相比，避免了任何数据都被写入缓存造成缓存频繁的更新。

缺点

1. 当发生缓存未命中的情况时，则会比较慢，因为要经过三个步骤：查询缓存，从数据库读取，写入缓存。
2. 复杂的逻辑都在应用程序中，如果实现微服务，多个微服务中会有重复的逻辑代码。

Read-Through/Write-Through模式

Read-Through/Write-Through模式中，应用程序将缓存作为主要的数据源，而数据库对于应用程序是透明的，更新数据库和从数据库的读取的任务都交给缓存来代理了，所以对于应用程序来说，简单很多。

说明： 这是大家比较常用的一种缓存模式。大家会实现自己的Cache模块，利用分布式锁等实现控制数据库数据的读写，此时Cache模块会承担系统绝大部分的流量和并发压力，保护业务系统以及数据库的稳定性。这种模式比较适合应用于流量和并发较高的商品和活动详情页的读取访问，兼顾后台运营系统对详情编辑的写入访问。

读数据策略：

由缓存配置一个读模块，它知道如何将数据库中的数据写入缓存。在数据被请求的时候，如果未命中，则将数据从数据库载入缓存。

image

写数据策略：

缓存配置一个写模块，它知道如何将数据写入数据库。当应用要写入数据时，缓存会先存储数据，并调用写模块将数据写入数据库。

image

优点

1. 缓存不存在脏数据
2. 相比较Cache-Aside懒加载模式，读取速度更高，因为较少因为缓存未命中而从数据库中查找
3. 应用程序的逻辑相对简单

缺点

1. 对于总是写入却很少被读取的应用，那么Write-Through会非常浪费性能，因为数据可能更改了很多次，却没有被读取，白白的每次都写入缓存造成写入延迟。

Read-Through/Write-Behind模式

Read-Through/Write-Behind模式中，和Write-Through写入的时机不同，Write-Behind将缓存作为可靠的数据源，每次都只写入缓存，而写入数据库则采用异步的方式，比如当数据要被移除出缓存的时候再存储到数据库或者一段时间之后批量更新数据库。

说明： 这也是大家比较常用的一种缓存模式。大家会实现自己的Cache模块，利用分布式锁等实现控制数据库数据的读写，此时Cache模块的写入数据库采用异步(例如MQ实现)的方式，来改良Write-Through在频繁写入时造成的性能浪费问题。这种模式比较适合应用于秒杀商品详情页的读取访问和下单库存频繁的写入访问。

读数据策略：

由缓存配置一个读模块，它知道如何将数据库中的数据写入缓存。在数据被请求的时候，如果未命中，则将数据从数据库载入缓存。

image

写数据策略：

缓存作为可靠的数据源，每次都只写入缓存，而写入数据库则采用异步的方式，比如当数据要被移除出缓存的时候再存储到数据库或者一段时间之后批量更新数据库。

image

优点

1. 写入和读取数据都非常的快，因为都是从缓存中直接读取和写入。
2. 对于数据库不可用的情况有一定的容忍度，即使数据库暂时不可用，系统也整体可用，当数据库之后恢复的时候，再将数据写入数据库。

缺点

1. 有数据丢失的风险，如果缓存挂掉而数据没有及时写到数据库中，那么缓存中的有些数据将永久的丢失了。

反例

曾经公司的小伙伴使用@Cacheable、@CacheEvict、@CachePut为整个系统添加缓存，在秒杀活动的使用场景中，由于高密集的读写操作，若使用这种注解形式的Cache-Aside模式，不但无法减轻数据库的读写压力，反而徒增Redis缓存服务器的压力，而且分布式环境中高概率造成并发情形下的数据不一致，甚至有可能导致整个系统的宕机。spring-cache框架固然省事且好用，如果不合理使用，也可能会无法达到预期的效果。

总结

上述的三种常用的缓存模式Cache-Aside模式、Read-Through/Write-Through模式、Read-Through/Write-Behind模式，各自有适用的场景以及优缺点，只有选择正确的使用场景才能有效地提高系统性能和负载能力。