公司突然发展特别好，如何快速对老旧下单服务改造应对高流量？

部门也想不到今天可以做到行业的龙头位置，目前在用户量已经到1亿的情况下，还可以保障每年用户量都以15%~30%在增长，但是这边有一些历史服务早期没有做到高并发，短期内又无法完成整个项目的重构，但是呢，又需要现在立马保障服务的安全可靠，在日益突飞猛进的大流量面让系统不能崩掉，咋办呢？ 我这边提出的解决方案是异步化，主要借鉴MQ的限流设计思想，我这边历史服务处理能力就100，那么其他的就请你排队，我只会以我这边最大能力进行处理同时我会给出目前订单的实时状态；

这里以团购为例进行解释大概的流程

一.下单的大概思路

image

ps: 这里key固定特定前缀进行过滤防止轮询的时候,前端可以随便传入值,这样岂不是透明获取了隐私数据了

幂等灯一ID,orderstatus:16进制(user):随机数:时间戳这里时间戳用于下单和查询的时候大于15分钟的数据直接拒绝,返回下单失败key:orderstatus:16进制(user):随机数

二 .轮询大概思路

image

三. 消费后要及时对redis做更新

四.总结

在这整个过程中，其实我们并没有改动原来代码的逻辑，就做到了保证在突飞猛进的发展里系统可以稳定工作

如果你们的业务标准一点，应该会有层层限流的概念，那么这里很有可能前台还有一个C端站点，负责做进入服务端前的基本拦截的功能，那么其实我们也可以把下单需求在这里就给收集起来 慢慢下方，这样的话，完全不用改动你们以前的代码了