如何设计一套高并发系统？

创作不易，如果觉得写的不错就投币支持一下吧~

我们知道，高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才
智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能
操纵流量，让流量更加平稳的被系统中的服务和组件处理。

来举个简单的例子吧。
从古至今，长江和黄河流域水患不断，远古时期，大禹曾拓宽河道，清除淤沙让流水更加顺
畅；都江堰作为史上最成功的的治水案例之一，用引流将岷江之水分流到多个支流中，以分
担水流压力；三门峡和葛洲坝通过建造水库将水引入水库先存储起来，然后再想办法把水库
中的水缓缓地排出去，以此提高下游的抗洪能力。

可以根据上面的例子，我们可以分析出来：
（1）“清除淤沙”可以看成是提高单个接口代码质量，降低时间复杂度或空间复杂度。提升单个接口的并发性能，也就是我们熟称的QPS。
（2）“分流”则是可以类比成我们项目中的集群，单个机器可以承受的并发数量有限，那就可以增加多个机器去分担并发。
（3）“水库”则有多种理解，你可以理解为是限流，比如我们项目中使用的令牌桶或漏斗限流器。也可以理解为使用消息队列的形式，异步的发送给消费端，让消费端慢慢的去处理任务。

当然在高并发的系统设计过程中，缓存也是经常经常被使用的，也是解决高并发的重要手段之一。后续文章我会对缓存上面提到的这些做个详细的介绍。

除了上面提到的高并发的几种解决方案，我们也应该从架构层面考虑。传统的

单体应用会将各个功能模块耦合在一起，放到一个应用服务器上，一台应用服务器的并发是非常有限的，并不能承受住高并发带来的流量，并且如果单台机器宕机了，将相当于所有的功能模块都不能访问。

有同学或许会说了，那加机器啊！加机器的确可以是可以在原先的基础上，增加可以承受的并发数，但是这是治根不治本的。单体应用不仅会有单点故障的问题，还会有不易扩展、可用性不高的问题，因为各个功能模块都耦合在一个应用服务器上了。需要扩展的时候，需要改写原先的代码，并将整个服务重新上线。

针对上述发现的单体应用的痛点，后面就出现了分布式微服务的概念。

何谓分布式微服务？

一句话概括就是，分布式微服务是将原先的单体应用的各个功能模块拆分出来，当成一个独立的服务部署到应用服务器上。

变成分布式微服务的架构之后，我们会发现每一个功能模块都是单独的一个应用。每个功能模块的并发数量都不一样，有的并发高有的并发低。针对并发高的，我们就可以对那个微服务加机器，增加服务的并发。并且如果要扩展某个功能模块的功能，我们只需要修改相应微服务的代码，而不需要影响整体的功能，这样就实现了系统的易扩展。加机器不仅可以提高并发，也可以避免单点故障导致整个系统不可用，可用性也大大地提高了。这就是我们常常听说的“三高”，高并发、高可用和可扩展。

说到三高，就不得不提到CPA理论，何谓CPA理论？

C:Consistency,一致性：当一个进程修改了数据之后，其他进程读取的数据要求是更新过的。
A:Availability,可用性：用户发出请求，需要实时响应，不能等待其他的事情完成才响应。
P: Partition tolerance,分区容忍性：一个系统由多个节点组成，部分节点坏了，整个系统能保证正常通信。

CPA理论表明：在一个系统中，CAP不可能同时满足，只可能最多同时满足两条。基本上容错性是一定会要的，如果说需要保证一致性，那么只能牺牲可用性，一般情况下，系统会选择可用性，而不是强一致性。

数据的一致性：

强一致性：更新操作之后，任何进程都返回最新的值。
弱一致性: 系统不能保证返回最新值，也不知道多久更新最新值。
最终一致性：系统保证没有后续更新的前提下，系统最终返回上一次更新操作的值。

数据一致性的问题是分布式系统常见的问题，也就是我们所说的分布式事务，这个后续的文章我会详细的把现在主流的那几种分布式事务解决方案讲解一下。

总结下来就是，处理高并发首先要根据系统的并发来选择系统架构，如果并发不是很高，比如crm系统，则可以考虑做成单体应用。如果并发很高，如商城项目，则需要优先考虑分布式架构，提高系统的三高。选好架构之后，我们再去考虑使用缓存、消息队列、限流等等去提高系统整体的可用性和稳定性。后续文章我们也是根据这三个方向去不断的扩展，并带大家一起设计一套完整的十亿级高并发系统方案。

觉得写的不错的，可以一键三连哦。想了解更多，或想要直接获取我的后续内容，可以关注我的GZH：java干货仓库