系统名：电商系统
主要功能：
预约功能：公司策划了一场超低价预约大型线上活动，在某天9:00~9:15期间，用户可以前往详情页半价预约抢购一款热门商品。根据市场部门的策划方案，这次活动的运营目标是几十万左右的预约量。
限制条件：
这场活动中，领导要求在架构上不要做太大调整，毕竟是一个临时的活动。简单地说就是工期不能太长，修改影响范围不要太大。
问题分析：
目标是15分钟完成100万的预约数据插入，并且不是在15分钟内平均插入。
按照以往的经验，有可能在1分钟内就完成90%的预约，也有可能在5分钟内完成80%的预约，这些难以预计。但是峰值流量预估值只能取高，不能取低。
所以设计的目标是：用户1分钟内就完成90%的预约量，即90万预约。那么推算出目标的TPS（吞吐量）就是9万/60=1.5万。
原来预约就是个简单的功能，并没有做高并发设计。对它做了一次压力测试，结果最大的TPS是2200左右，与需求值差距较大。
优化方案：
分库分表：代码改动的代价太大了，性价比不高。毕竟这次仅仅是临时性市场活动，而且活动运营目标是几十万的预约量，这点数据量采取分表分库的话，未免有些得不偿失。
项目最终采用的方案是不让预约的请求直接插入数据库，而是先存放到性能很高的缓冲地带，以此保证洪峰期间先冲击缓冲地带，之后再从缓冲地带异步、匀速地迁移数据到数据库中。
优化结果：
这个项目经过两周左右就上线了，上线之后的某次活动中，后台日志和数据库监控一切正常。活动一共收到几十万的预约量，达到了市场预期的效果。
方案存在的不足：
此方案缓解的只是短时（活动期间）数据库压力大的问题，当写数据量长期非常大时，这个方案是解决不了问题的。
此方案适合每个写操作都独立的情况，如果写操作之间存在竞争资源，比如商品库存，这个方案就无法覆盖。