高并发优化系列文章(持续更新补充)
- 垂直性能提升
1.1. 架构优化：集群部署，负载均衡
1.2. 本篇内容：万亿流量下负载均衡的实现
上篇基本把负载均衡涉及到的基础都罗列了，那么到了实际场景下，特别是万亿流量场景下，真实的负载均衡方案又是怎么做的呢。
本篇分别就双11秒杀、12306、微信红包和抖音春晚红包等场景在负载均衡方面的运用进行一些介绍和讨论。
阿里双11流量下的负载均衡
双十一流量特点
请求量巨大，脉冲式的。是对阿里生态链路上所有服务的考验。
对负载均衡器的要求
- 性能优良：应对双11当晚脉冲式的流量冲击
- 服务稳定：可用性高，以应对设备和网络的抖动
- 业务无感：顺滑的自身升级和容灾切换
实现原理
1）优良性能依赖DPDK
阿里的新一代负载均衡器是基于DPDK来实现的。
其优势总结如下*
正是由于这些专门针对数据包的高性能支持，才得以实现性能优良的负载均衡器来支撑多年双11场景下的脉冲流量的压力。
2）应对ECMP重选导致的连接中断
ECPM(Equal-CostMultipathRouting) 是一种最大限度利用最短路径的等价多路径路由算法。
<,
>
如上图，SLB采用水平扩展的集群部署，多台服务器发布相同路由，在交换机处形成ECPM路由。以达到高可用的目的。但，在连接没有同步之前，遇到服务器硬件或网络异常，会使该服务器不可用，ECPM重选路由，会使连接到达其他服务器，导致已有连接中断，造成用户访问异常。SLB使用了会话同步的机制来解决了升级与容灾场景下长连接中断的问题。用组播技术解决会话同步机制中的机器上下线问题。详细解释参见文献[1]。
铁路12306的负载均衡
12306大名鼎鼎，无需多介绍。其中很多的场景和技术都可以给我们做一些很好的参考。但只找到了16年发表的论文，没有能了解到最新的架构部署。
12306的业务难点
- 动态库存，余票可以按站点拆分
- 事务强一致，下单交易性质
- 多维度数据一致性，线上线下售票渠道
- 流量洪峰，遇节假日有流量洪峰
这里对前几个问题就暂不讨论，单说负载均衡在应对流量洪峰时的作用。
12306架构的发展历程如下：
<,
,
>
由上图可以看到，第一次优化之前，几乎全链路服务都出现了性能瓶颈，因为并发查询导致查询系统负载过高，用户重试引发AS过载；AS阻塞导致响应增加，引发WEB负载问题，线上压力导致整个票务系统异常，进而影响了线下购票渠道正常运转，直至链路雪崩。
第一次优化后，引入排队系统，不同车次使用不同队列，已达到请求分流；且排队系统采用了动态流量控制，根据各铁路局客票中心处理速度，进行控速请求下发；并进行了客票网服务拆分，根据不同规则，使流量负载均衡。此次优化让12306顺利度过了13年春运。但随着互联网的高速发展，网上订票人数不断增加，目前的架构已经达到了带宽、性能、稳定性的瓶颈。因此第二次优化如下：
本篇重点还是看负载均衡在业务场景下的实际作用，因此，其他优化点就不做讨论了。正是因为多维度，多层次的负载均衡，才使得12306能够承载更高的流量冲击（如果哪些同学有12306最新的部署架构，希望能私信交流学习~）
微信红包背后的负载均衡
抖音春晚红包背后的负载均衡
排版问题感兴趣的同学请移步同名公众号观看，欢迎一起交流学习
