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

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

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

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

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

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

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

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

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

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