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