怎么处理写操作并发量大的场景？如何最小代价解决短期高频写请求

写缓存

上篇详细讨论了缓存的架构方案，它可以减少数据库读操作的压力，却也存在着不足，比如写操作并发量大时，这个方案不会奏效。那该怎么办呢？本篇就来讨论怎么处理写操作并发量大的场景。

先来看一个具体的业务场景。

业务场景：如何以最小代价解决短期高频写请求

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

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

项目组分析了一下可能的情况，其他都没问题，唯一没把握的就是数据库。

项目组通过如下逻辑做了一次简单的测算。

假设目标是15分钟完成100万的预约数据插入，并且不是在15分钟内平均插入的。按照以往的经验，有可能在1分钟内就完成90%的预约，也有可能在5分钟内完成80%的预约，这些难以预计。但是峰值流量预估值只能取高，不能取低。所以设计的目标是：用户1分钟内就完成90%的预约量，即90万预约。那么推算出目标的TPS（吞吐量）就是9万/60=1.5万。

原来预约就是个简单的功能，并没有做高并发设计。对它做了一次压力测试，结果最大的TPS是2200左右，与需求值差距较大。

项目组想过分表分库这个方案，不过代码改动的代价太大了，性价比不高。毕竟这次仅仅是临时性市场活动，而且活动运营目标是几十万的预约量，这点数据量采取分表分库的话，未免有些得不偿失。

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

其实这个解决方案就是写缓存，这也是接下来要重点讲解的内容。

写缓存

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

写缓存架构示意图如图5-1所示。

• 图5-1 写缓存架构示意图

设想的运行场景如下。

假设高峰期1秒内有1.5万个预约数据的插入请求。这1.5万个请求如果直接到数据库，那么数据库肯定崩溃。所以把这1.5万个请求落到并发写性能很高的缓存层，然后以2000为单位从缓存层批量落到数据库。数据库如果用批量插入语句，TPS也是可以非常高的，可能达到上万，这样不仅能防止数据库崩溃，还能确保用户的请求得到满足。

从以上设计方案中不难看出，写缓存可以用来大幅降低数据库写操作的频率，从而减少数据库的压力。

接下来说说实现思路。

本文给大家讲解的内容是缓存层场景实战，写缓存，业务场景：如何以最小代价解决短期高频写请求

1. 下篇文章给大家讲解的内容是缓存层场景实战，写缓存的实现思路
2. 觉得文章不错的朋友可以转发此文关注小编；
3. 感谢大家的支持！

本文就是愿天堂没有BUG给大家分享的内容，大家有收获的话可以分享下，想学习更多的话可以到微信公众号里找我，我等你哦。