浅谈大规模高并发服务的伸缩问题

什么是大规模高并发？

大规模高并发是两个词，前者表示有大量的流量访问，后者表示竞争状态下并发可能会遇到的一致性和可用性问题。

 

有什么问题？

如果只是大规模的流量，我们可以简单的进行负载均衡和针对架构层面的优化就能解决，这一块和业务并无直接联系。

但是高并发就不一样了，就算只有不太多的流量，只要存在并发竞争关系，必然会牵扯到状态的一致性和业务流程的拆分优化。

最重要的是状态，由于状态需要被维护，因此针对状态的伸缩扩展一直以来很容易跟技术发生混淆，我们必须要明确的一点就是，如果状态竞争在业务层面没有得到有效的解决，在技术层面目前也是无法得到有效的解决的。

可以想象，无状态的服务很容易得到拓展，只需要增加处理节点，均匀的负载流量，路由到指定的节点处理即可。

所以关键在于业务要如何拆分？状态要如何维护？这是下面将要讲到的。

 

如何解决？

大规模低并发

这种是最容易解决的，只需要增加处理节点即可，因为不需要牵扯到状态的维护，因此也无须担心会发生副作用。

一般来讲，HTTP请求将会被均匀的路由给不同的节点进行处理，我们可以做到无限拓展，只需要在适当的条件下进行伸缩即可。

因为不存在状态的维护，因此和业务关系不大，只需要在技术层面进行优化。

 

大规模高并发

有时间的可以读一下我之前写的这篇文章（https://www.cnblogs.com/xingxueliao/p/11561263.html）

我这里所提到的并发，可能跟很多人的理解有所不同，并发这个词实际上指的是逻辑上的，什么是逻辑上的？那就是和底层细节隔离开，我们只需要在脑海中存在这么一个概念。

无论我们使用多线程，多进程，还是在不同主机上面运行的程序，在不同的时间进行并行处理，高并发在本文的重点侧重于对状态的变更所导致的一致性问题和可用性问题。

就像java的并发包里面，更多的是一些工具用于维护状态，为了使状态在并发条件下预期可控制，所以我也使用并发一词来表达这种竞争场景。

看起来似乎是矛盾的，一致性和可用性是两个极端，我们只能在这两个点之间进行选择，平衡两点对应业务的影响。

如果我们想要高可用，那么业务流程可能就会更复杂，因为时间关系，我们只能选择最终一致，那么必然就存在中间状态和流程。

如果我们想要强一致，那么只需要简单的按照顺序处理完整个业务流程即可，但是可用性就无法发挥到最佳的程度。

在产品初期，为了快速的实现原型设想，又要保证结果是可预期的，可靠的，直接使用支持ACID的数据库是最方便省事的。

过渡到产品后期，取决于业务数据的维度和聚合主体，状态隔离分区和业务流程优化是必不可少的。

简而言之，高可用带来了更大的复杂性，而强一致又会导致可用性不足。

在上面的连接的文章之中我也简略的讲了一些“解决办法”，其实倒不如说是一些思考方式，能够让我们清醒的认识到，哪些东西才是我们需要去关注和解决的。