Redis：代码实战之旁路缓存

【关于作者】

关于作者，目前在蚂蚁金服搬砖任职，在支付宝营销投放领域工作了多年，目前在专注于内存数据库相关的应用学习，如果你有任何技术交流或大厂内推及面试咨询，都可以从我的个人博客（https://0522-isniceday.top/）联系我

1.（应用中）缓存的特征

• 在一个层次化的系统中，缓存一定是一个快速子系统
• 缓存系统的容量大小总是小于后端慢速系统的，不可能将所有数据都放置于缓存中，并且缓存中的数据需要按照一定的规则淘汰

2.Redis作为旁路缓存的操作

旁路缓存：读取缓存、读取数据库和更新缓存的操作都在代码中完成，redis只是一个独立的系统软件，也可以用来作为旁路缓存的一个选择

但是当一个系统引入缓存时，需要面临最大的问题就是，如何保证缓存和后端数据库的一致性问题，最常见的3个解决方案分别是Cache Aside、Read/Write Throught和Write Back缓存更新策略，也就是下面所描述的两张缓存类型

2.1.缓存的两种类型

只读缓存能够加速读的速度，读写缓存提供两种写回策略，并能够加速读写的速度

2.1.1.只读缓存（Cache Aside策略）：

概念：redis作为读缓存时，会将写请求直接打向数据库，并且在操作完数据库之后，会从缓存中删除写请求的数据。当客户端读取该数据时发现数据缺失，则会再次将数据同步入缓存

优点：由于数据都持久化到了底层数据库，因此能够保证数据不丢失，数据能够保证一致性。当我们需要缓存图片、短视频这些用户只读的数据时，就可以使用只读缓存这个类型了。这种策略是我们在开发软件时最常用的，在使用Memcached或Redis时一般都采用这种方案

缺点：写操作会让缓存失效，再次读取时需要从数据库中加载。

2.2.2.读写缓存

概念：除了读请求会直接从缓存中读取之外，写请求包括增删改也是在缓存中完成。

两种回写策略：

• 同步直写：

  写请求缓存执行之外，也会发送给后端库，等两者都写入完毕才返回客户端。这样即便宕机，也能保证数据的可靠性，不过会降低缓存的访问性能。

  优点：对于应用层的使用非常友好，只需要操作缓存即可

  缺点：高并发下的同步直写可能会发生缓存和数据库不一致的情形，由于写入数据库后写入缓存操作存在竞态条件（更新覆盖，由于请求数据库可能先请求后返回），需要配合分布式锁。

• 异步写回策略：

  所有写请求现在缓存处理，等增改的数据被从缓存中淘汰时，将需要淘汰的数据写入后端数据库。

  优点：写操作飞快，只有当缓存满了数据淘汰时才会将脏数据写回数据库

  缺点：如果缓存宕机了或异常了，数据又没有写回数据库，则会有数据丢失的风险

  

关于是选择只读缓存，还是读写缓存，主要看我们对写请求是否有加速的需求。

• 如果需要对写请求进行加速（例如秒杀等），我们选择读写缓存；
• 如果写请求很少，或者是只需要提升读请求的响应速度的话，我们选择只读缓存。

2.2.Redis可以作为哪些缓存使用？

• 只读缓存：写操作直接写入数据库，下次读如果出现数据确实则更新缓存
• 读写缓存之同步直接：读请求直接请求缓存，写请求同时写数据库和redis，但是这里会存在并发问题，需要配合分布式锁
• 读写缓存之异步写回策略：这种方式redis无法采取，因为redis再数据淘汰的时候代码无法嵌入同步脏数据的操作，所以无法采取。

2.3.读写缓存发现缓存更新或数据库更新失败如何处理？

还有一个问题就是操作缓存或数据库发生异常时如何处理？例如缓存操作成功，数据库操作失败，或者反过来，还是有可能会产生不一致的情况：

• 根据业务制定好更新场景的顺序，或者给缓存设置较短的过期时间来降低不一致的时间
• 如果需要保证强一致性，则需要涉及到分布式事务，常见的解决方案包括：两阶段提交（2PC）、三阶段提交（3PC）、TCC、消息队列等方式（具体见文章：）