每秒100W请求，12306秒杀业务，架构如何优化？

同一个uid计数与限速，如果担心访问redis带宽成为瓶颈，可以这么优化：

• 计数直接放在内存，这样就省去了网络请求;
• 在nginx层做7层均衡，让一个uid的请求落到同一个机器上;

画外音：这个计数对数据一致性、准确性要求不高，即使服务重启计数丢了，大不了重新开始计。

除了系统上的优化，产品与业务还能够做一些折衷，降低架构难度。

• 业务折衷一：一般来说，下单和支付放在同一个流程里，能够提高转化率。对于秒杀场景，产品上，下单流程和支付流程异步，放在两个环节里，能够降低数据库写压力。以12306为例，下单成功后，系统占住库存，45分钟之内支付即可。
• 业务折衷二：一般来说，所有用户规则相同，体验会更好。对于秒杀场景，产品上，不同地域分时售票，虽然不是所有用户规则相同，但能够极大降低系统压力。北京9:00开始售票，上海9:30开始售票，广州XX开始售票，能够分担系统压力。
• 业务折衷三：秒杀场景，由于短时间内并发较大，系统返回较慢，用户心情十分焦急，可能会频繁点击按钮，对系统造成压力。产品上可以优化为，一旦点击，不管系统是否返回，按钮立刻置灰，不给用户机会频繁点击。
• 业务折衷四：一般来说，显示具体的库存数量，能够加强用户体验。对于秒杀场景，产品上，只显示有/无车票，而不是显示具体票数目，能够降低缓存淘汰率。

画外音：显示库存会淘汰N次，显示有无只会淘汰1次。更多的，用户关注是否有票，而不是票有几张。

无论如何，产品技术运营一起，目标是一致的，把事情做好，不存在谁是甲方，谁是乙方的关系。

总结

对于秒杀系统，除了产品和业务上的折衷，架构设计上主要有两大优化方向：

• 尽量将请求拦截在系统上游;
• 读多写少用缓存;

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!