高并发的书籍文章其实有很多，我们工作中也或多或少遇到过一些。今天这里总结下常见的思路。

一，分而治之。

        这个是最容易想到的办法，这里面包含了几层思路。

        1，产品设计。业务上就引导用户分开使用，按需购买，这样会从产品形态上就减少对系统压力。最容易举的例子就是12306放票不是一次性放出来，而是分时段放票。

        2，服务水平扩展。一个节点处理不了就分给两个三个节点处理，这种叫水平扩展。

        3，服务垂直扩展。一个服务越简单那么它越能做到极致，当一个服务干太多事后，它性能一定高不到哪里去，所以需要把它干的事分出去。比如把运单的创建模块单独剥离，那么创建就可以做到极致。

二，缓存

        如果每个请求都去访问数据节点，那么数据节点早挂了。缓存的做法也很多了。本地缓存、组件缓存、客户端缓存。

三，异步

        1，本来数据结果就依赖第三方处理，这种天然就是异步的。比如支付结果。2，不依赖第三方，但是我方处理能力有限。比如很多用户导单子，后续处理单子能里有限，不可能全部同步处理，这种场景异步就可以很好解决。

四，批处理

        1，如果一个业务请求会导致来回调用很多次请求，那么请求链路上的耗时也是很大一笔开销。2，一次处理10个请求，肯定比一次处理一个请求吞吐量高些。

五，隔离

        刚才提到分而治之思路，那秒杀系统岂不是正好相反？秒杀系统可以看成是99%的客户会失败，而1%的客户会成功。系统设计的时候是不是把这个1%的客户和99%的客户隔离就对了。既然只有1%的客户会成功，那何必把99%的客户的请求都放入核心系统呢？还有vip客户和非vip客户也是会用到隔离的思路。这也是和二八原则的契合的，热点数据和热点用户毕竟是少数。