一年前，本人有幸负责公司核心项目的优化。随着公司业务的增长，项目处理量也越来越大。
一次818大促甚至导致一台服务器满负荷运作。于是，高并发改造被提上行程。
干货开始：
技术实现上有三个重点：异步化（一般使用mq）、缓存（一般使用redis）、多线程
一个功能并发量上大的提升，是需要业务和技术上共同去努力实现的。重点在于业务上的解耦，技术上的异步化。
假设一个核心系统分为三个部分（前台、中台、后台）
1、前台负责所有外部系统的http请求，这里只进行简单的逻辑处理，尽量去绕过数据库这些笨重的服务，然后将消息存入mq，然后通知外部系统成功结果。
2、中台负责处理前台mq中消息，操作数据库，进行一些费时的操作，所以为了提升处理速度，一般使用多线程 + 缓存。如果处理失败，则需要记录下来进行重试，重试一定次数依然失败，则需要在后台中显示进行人工操作。
3、后台负责人工异常处理。
这样设计部署的话，想要提高并发量，只需要前台和中台横向扩充机器即可，所有的压力压在了负载均衡机器和mq中间件那里。一般瓶颈都在于中间件那块。
很多公司使用kafka来提升mq中间件的速度。但是kafka相对于其他的mq方案更加的不安全，除非你有额外的优化和宕机恢复措施。
项目改造半年之后，因为中间件的瓶颈，tps只卡在五万左右，虽然没有达到预期的十万大关，不过大促倒也可以轻松应对了。