缓存高可用架构-写缓存 - 实践

业务场景

某公司策划了一场超低价预约大型线上活动，在某天9:00~9:15期间，用户可以前往详情页半价预约抢购一款热门商品。根据市场部门的策划方案，这次活动的运营目标是几十万左右的预约量。

为避免活动上线后出现问题，比如数据库被压垮、后台服务器支撑不住（这个倒是小问题，加几台服务器即可）等，项目组必须提前做好预案。这场活动中，领导要求在架构上不要做太大调整，毕竟是一个临时的活动。简便地说就是工期不能太长，修改影响范围不要太大。

这就要求如何以最小代价解决短期高频写请求。

不让预约的请求直接插入数据库，而是先存放到性能很高的缓冲地带，以此保证洪峰期间先冲击缓冲地带，之后再从缓冲地带异步、匀速地迁移资料到数据库中。

什么是写缓存？

写缓存的思路是后台服务接收到用户请求时，如果请求校验没问题，信息并不会直接落库，而是先存储在缓存层中，缓存层中写请求达到一定数量时再进行批量落库。这里所说的缓存层实际上指的就是写缓存。它的意义在于利用写缓存比数据库高几个量级的吞吐能力来承受洪峰流量，再匀速迁移数据到数据库。

写缓存架构示意图：

设想的运行场景如下。假设高峰期1秒内有1.5万个预约材料的插入请求。这1.5万个请求如果直接到数据库，那么数据库肯定崩溃。所以把这1.5万个请求落到并发写性能很高的缓存层，然后以2000为单位从缓存层批量落到数据库。数据库如果用批量插入语句，TPS也是可以非常高的，可能达到上万，这样不仅能防止数据库崩溃，还能确保用户的请求得到满足。从以上设计方案中不难看出，写缓存许可用来大幅降低数据库写操控的频率，从而减少数据库的压力。

实现思路

在具体实施过程中要考虑6个问题。

异步？就是1）写请求与批量落库这两个操作同步还

从复杂度的角度来看，异步比同步简单很多，因此项目直接选用异步的方式，预约信息保存到缓存层即可返回结果。

关于异步的用户体验设计，共有两种设计方案可供业务方选择。

a.在“我的预约”页面给用户一个提示：您的预约订单可能会有一定延迟。

b.用户预约成功后，直接进入预约完成详情页，此页面会定时发送请求去查询后台批量落库的状态，如果落库成功，则弹出成功提示，并跳转至下一个页面。

失败了？这无形中就影响了用户体验。就是其实，第一种方案在实际应用中也经常遇到，不过项目中主要还是使 用第二种方案。因为在第二种方案中，大部分情况下用户是感受不到延迟的，用户体验比较好，而假设选择第一种方案，用户还要去思考：该延迟是什么意思？是不

2）如何触发批量落库？

关于批量落库触发逻辑，目前共分为两种。

a.请求满足特定次数后就落库一次，比如10个请求落库一次。按照次数批量落库的优点是访问数据库的次数变为1/N，从数据库压力上来说会小很多。不过它也存在不足：如果访问数据库的次数未凑齐N次，用户的预约就一直无法落库。

b.每隔一个时间窗口落库一次，比如每隔一秒落库一次。

那到底哪种触发方式好呢？

同时采用这两种方式。具体实现逻辑如下。就是可以单独采用某一种方式，还有一种方案

a.每收集一次写请求，就插入预约数据到缓存中，再判断缓存中预约的总数是否达到一定数量，达到后直接触发批量落库。

b.开一个定时器，每隔一秒触发一次批量落库。

架构图如下：

3）缓冲内容存储在哪里？

缓存数据不仅可以存放在本地内存中，也许可存放在分布式缓存中（比如Redis）​，其中最容易的方式是存放在本地内存中。

不过，Hystrix的请求合并也是存放在本地内存中，为什么不直接使用Hystrix?这是因为写缓存与Hystrix的请求合并有些不一样，请求合并更多考虑的是读请求的情况，不用担心数据丢失，而写请求需要考虑容灾问题：如果服务器宕机，内存数据就会丢失，用户的预约数据也就没有了。

其实也可以考虑采用MQ来当缓存层，MQ的一个主要用途就是削峰，很适合这种场景（根据具体情况决定是否采用）。

基于Redis触发批量落库的方案如下图所示（不使用MQ）。

4）缓存层并发操作必须注意什么？

假如多个Insert语句同时执行，它们会根据排队情况按顺序执行，也可以与Select语句并发执行。因而多个Insert语句并行执行的性能未必会比单线程Insert更快。

5）批量落库失败了怎么办？

批量落库的建立逻辑：

1）当前线程从缓存中获取所有数据。由于每10条执行一次落库操作，不必须担心缓存中的数据量过多，所以也不用考虑将获得的数据分批操作了。

2）当前线程批量保存数据到数据库。

3）当前线程从缓存中删除对应数据（注意：不能直接清空缓存的数据，因为新的预约数据可能插入到缓存中了）​。

以上各个步骤失败时的应对措施下表。

6）Redis的高可用配置

这一业务场景是先把用户提交的数据保存到缓存中，因此必须保证缓存中的数据不丢失，这就要求实现Redis的数据备份。

目前，Redis共帮助两种备份方式，见下表。

另外，Redis还有一个主从功能。而如果需要从0开始搭建，最轻松的解决方案如下：

1）先使用简单的主从模式。

2）接着在Slave Redis里使用快照（30秒一次）+AOF（一秒一次）的配置。

3）如果Master Redis宕机了，千万不要直接启动，先把Slave Redis升级为Master Redis。

4）这时代码里已经有预案了，写缓存倘若失败直接落库。