系统高并发解决方案的演进过程

高并发方案的演进本质上就是围绕吞吐、峰值、可用性和正确性四个维度持续治理系统。单机阶段在一开始的时候系统是以单体服务的形式出现单机模式下可实现系统的快速上线。随着系统用户越来越多以及系统功能的数量和复杂度不断提升单个节点消耗资源接近预警区间随时可能有服务器资源耗尽导致业务崩溃的风险系统升级迫在眉睫。集群阶段既然单节点扛不住压力就有人开始考虑增加同样的节点来顶住系统带来的压力通过负载均衡来将压力平均到每个节点上。集群可有效提高系统的吞吐量并可以通过扩容应对未来持续增长的需求。集群阶段优化应用集群是为了解决业务整体向上增长趋势通过提升单个节点处理能力能在一定程度上降低集群节点扩展的速度节省资源。这里的节点性能优化方案主要有增加数据缓存层减少应用层的操作包括数据库操作、磁盘IO、网络资源访问等。具体实现方案可以有Redis缓存、本地缓存、多级缓存等方式。MQ阶段集群阶段可能存在的一个问题就是只有部分情况下业务访问量才会有爆发式上涨比如搞促销、秒杀或者某些并不需要实时处理的耗时或者高爆发业务如积分业务这些情况下如果为了近乎实时完成而去增加集群规模总体来看并不划算。所以可以将这些业务集中到消息队列中进行排队处理以时间换空间的方式来实现业务的处理。消息队列方式主要应对突发流量实现异步处理、削峰填谷、业务解耦。治理阶段随着服务越来越多还要考虑故障扩散问题所以后面会继续补上 限流、熔断、降级和线程池隔离。比如活动接口在高峰期会做限流避免超出系统承载能力对一些非核心服务比如推荐、评价可以在压力过大时降级优先保证下单、支付这些核心链路可用。核心点 防雪崩、保可用限流限流通常是做在网关层可以通过自己实现Redis令牌桶、固定窗口限流、滑动窗口限流、漏桶算法或者使用第三方框架Sentinel通过Redis或者nacos配置需要限流的URL限流次数规则等请求进来时。熔断降级熔断器通常放在调用方这一侧由调用方判断这个下游服务最近是不是失败率很高是不是超时很多是不是已经不稳定了如果满足条件调用方就会不再继续调用被调用方直接快速失败或者进入 fallback / 降级逻辑降级是当被调用服务不可用、超时或者熔断时调用方需要通过 fallback、默认值、缓存值等方式做兜底保证自己的核心流程不受影响。分布式阶段如果业务规模再继续增长订单表、明细表、流水表这些数据量很大就会进入 分库分表 阶段。比如订单按用户 ID 或时间维度分片不同业务模块拆成独立服务这样读写压力就不会集中在单个库表上。这阶段主要解决数据规模问题方式分库分表、服务拆分秒杀服务在秒杀这种特殊高并发场景下我们通常还会做更细的专项优化比如活动开始前把库存预热到 Redis请求进入后先在 Redis 做库存预扣减接口层做限流、防重复提交下单流程异步化消费端做幂等校验最终再落库校验库存和订单状态这样即使在短时间内流量暴涨也能保证系统不崩同时库存不会超卖。