一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等

一、引言

关于“负载均衡”的解释，百度词条里：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操做单元上进行执行，共同完成工做任务。

负载均衡（Load Balance）创建在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增长吞吐量、增强网络数据处理能力、提升网络的灵活性和可用性。

负载均衡有两方面的含义：

1）首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减小用户等待响应的时间；

2）其次，单个重负载的运算分担到多台节点设备上作并行处理，每一个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力获得大幅度提升。

简单来讲就是：

1）其一是将大量的并发处理转发给后端多个节点处理，减小工做响应时间；

2）其二是将单个繁重的工做转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。

目前负载均衡技术大多数是用于提升诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

总之，它的目的就经过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。

内容概述：本文将从负载均衡技术的分类、技术原理、常见实现算法、经常使用方案等入手，为您详细讲解负载均衡技术的方方面面。这其中，四层和七层负载均衡技术最为经常使用，它们也是本文介绍的重点。

内容点评：对于IM或消息推送应用的开发者来讲，本文所介绍的传统负载均衡技术，可能对于IM等即时通信分布式场景来讲，没有办法直接套用。缘由是IM这类socket长链接场景，所处的网络通讯层级比较低，并且即时通信相关的技术实现跟具体的业务逻辑紧密相关，于是没法像HTTP短链接这样基于标准化的负载均衡方法来实现。但本文所介绍的负载均衡原理、算法和一些方案实现，仍然能够为IM或消息推送应用的开发者带来一些借鉴和参考意义，值得深 入一读。

补充：另外一篇《快速理解高性能HTTP服务端的负载均衡技术原理》，也讲述了负载均衡方面的知识，有兴趣也能够阅读之。

（本文同步发布于：http://www.52im.net/thread-24...）

二、相关文章

深刻阅读如下文章，有助于您更好地理解本篇内容：

《网络编程懒人入门(一)：快速理解网络通讯协议（上篇）》

《网络编程懒人入门(二)：快速理解网络通讯协议（下篇）》

《网络编程懒人入门(三)：快速理解TCP协议一篇就够》

《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》

《IM开发基础知识补课：正确理解前置HTTP SSO单点登录接口的原理》

三、负载均衡分类

TCP/IP协议的OSI模型：

（本图高清版，请从《计算机网络通信协议关系图（中文珍藏版）[附件下载]》一文中下载之）

根据OSI模型可将负载均衡分为：

1）二层负载均衡（通常是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；

2）三层负载均衡（通常采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；

3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；

4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。

这其中，最多见的是四层和七层负载均衡，也是本文接下来介绍的重点。

当客户端发起请求，会通过层层的封装，发给服务器，服务器收到请求后通过层层的解析，获取到对应的内容。

下图是一个典型的HTTP请求分层传递原理：

四、二层负载均衡

二层负债均衡是基于数据链路层的负债均衡，即让负债均衡服务器和业务服务器绑定同一个虚拟IP（即VIP），客户端直接经过这个VIP进行请求。

那么如何区分相同IP下的不一样机器呢？没错，经过MAC物理地址，每台机器的MAC物理地址都不同，当负载均衡服务器接收到请求以后，经过改写HTTP报文中以太网首部的MAC地址，按照某种算法将请求转发到目标机器上，实现负载均衡。

这种方式负载方式虽然控制粒度比较粗，可是优势是负载均衡服务器的压力会比较小，负载均衡服务器只负责请求的进入，不负责请求的响应（响应是有后端业务服务器直接响应给客户端），吞吐量会比较高。

五、三层负载均衡

三层负载均衡是基于网络层的负载均衡，通俗的说就是按照不一样机器不一样IP地址进行转发请求到不一样的机器上。

这种方式虽然比二层负载多了一层，但从控制的颗粒度上看，并无比二层负载均衡更有优点，而且，因为请求的进出都要通过负载均衡服务器，会对其形成比较大的压力，性能也比二层负载均衡要差。

六、四层负载均衡

四层的负载均衡就是基于IP+端口的负载均衡：在三层负载均衡的基础上，经过发布三层的IP地址（VIP），而后加四层的端口号，来决定哪些流量须要作负载均衡，对须要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个链接的全部流量都一样转发到同一台服务器处理。

对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。

此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等），常见例子有：LVS，F5。

七、七层负载均衡

七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，好比同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否须要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

举个例子，若是你的Web服务器分红两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就能够当用户来访问你的域名时，自动辨别用户语言，而后选择对应的语言服务器组进行负载均衡处理。

对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡之外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议，常见例子有： haproxy，MySQL Proxy。

八、四层负载均衡和七层负载均衡的区别

8.1 技术原理上的区别

所谓四层负载均衡，也就是主要经过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即经过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改成后端服务器IP），直接转发给该服务器。TCP的链接创建，即三次握手是客户端和服务器直接创建的，负载均衡设备只是起到一个相似路由器的转发动做。在某些部署状况下，为保证服务器回包能够正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

所谓七层负载均衡，也称为“内容交换”，也就是主要经过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

以常见的TCP为例，负载均衡设备若是要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端创建链接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，而后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种状况下，更相似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别创建TCP链接。因此从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

8.2 应用场景的需求

七层应用负载的好处，是使得整个网络更"智能化"。参考这篇《利用负载均衡优化和加速HTTP应用》，就能够基本上了解这种方式的优点所在。

例如访问一个网站的用户流量，能够经过七层的方式，将对图片类的请求转发到特定的图片服务器并可使用缓存技术；将对文字类的请求能够转发到特定的文字服务器并可使用压缩技术。

固然这只是七层应用的一个小案例，从技术原理上，这种方式能够对客户端的请求和服务器的响应进行任意意义上的修改，极大的提高了应用系统在网络层的灵活性。不少在后台，例如Nginx或者Apache上部署的功能能够前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。

另一个经常被提到功能就是安全性。网络中最多见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，一般这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。

从技术原理上也能够看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击天然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备能够在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提升系统总体安全。

如今的7层负载均衡，主要仍是着重于应用HTTP协议，因此其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其余TCP应用，例如IM即时通信、实时消息推送等socket长链接系统。

8.3 七层应用须要考虑的问题

七层应用须要考虑的问题：

1）是否真的必要：七层应用的确能够提升流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时须要考虑四层七层同时应用的混杂状况。

2）是否真的能够提升安全性：例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备自己要有强大的抗DDoS能力，不然即便服务器正常而做为中枢调度的负载均衡设备故障也会致使整个应用的崩溃。

3）是否有足够的灵活度：七层应用的优点是可让整个应用的流量智能化，可是负载均衡设备须要提供完善的七层功能，知足客户根据不一样状况的基于应用的调度。最简单的一个考核就是可否取代后台Nginx或者Apache等服务器上的调度功能。可以提供一个七层应用开发接口的负载均衡设备，可让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

8.4 整体对比

四层负载均衡和七层负载均衡技术的整体对比：

1）智能性：七层负载均衡因为具有OIS七层的全部功能，因此在处理用户需求上能更加灵活，从理论上讲，七层模型能对用户的全部跟服务端的请求进行修改。例如对文件header添加信息，根据不一样的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发，不能修改用户请求的内容。

2）安全性：七层负载均衡因为具备OSI模型的所有功能，能更容易抵御来自网络的攻击；四层模型从原理上讲，会直接将用户的请求转发给后端节点，没法直接抵御网络攻击。

3）复杂度：四层模型通常比较简单的架构，容易管理，容易定位问题；七层模型架构比较复杂，一般也须要考虑结合四层模型的混用状况，出现问题定位比较复杂。

4）效率比：四层模型基于更底层的设置，一般效率更高，但应用范围有限；七层模型须要更多的资源损耗，在理论上讲比四层模型有更强的功能，如今的实现更可能是基于http应用。

九、负载均衡技术的常见具体应用方案

目前有许多不一样的负载均衡技术实现用以知足不一样的应用需求，下面从负载均衡所采用的设备对象（软/硬件负载均衡），应用的OSI网络层次（网络层次上的负载均衡），及应用的地理结构（本地/全局负载均衡）等来分类。

9.1 软/硬件负载均衡

软件负载均衡解决方案：是指在一台或多台服务器相应的操做系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl，Keepalive+ipvs等，它的优势是基于特定环境，配置简单，使用灵活，成本低廉，能够知足通常的负载均衡需求。软件解决方案缺点也较多，由于每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，因此当链接请求特别大的时候，软件自己会成为服务器工做成败的一个关键；软件可扩展性并非很好，受到操做系统的限制；因为操做系统自己的Bug，每每会引发安全问题。

硬件负载均衡解决方案：是直接在服务器和外部网络间安装负载均衡设备，这种设备一般是一个独立于系统的硬件，咱们称之为负载均衡器。因为专门的设备完成专门的任务，独立于操做系统，总体性能获得大量提升，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。负载均衡器有多种多样的形式，除了做为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet连接之间，有些则以两块网络适配器将这一功能集成到PC中，一块链接到Internet上，一块链接到后端服务器群的内部网络上。

软件负载均衡与硬件负载均衡的对好比下。

1）软件负载均衡：

优势：是需求环境明确，配置简单，操做灵活，成本低廉，效率不高，能知足普通的企业需求；

缺点：依赖于系统，增长资源开销；软件的优劣决定环境的性能；系统的安全，软件的稳定性均会影响到整个环境的安全。

2）硬件负载均衡：

优势：是独立于系统，总体性能大量提高，在功能、性能上优于软件方式；智能的流量管理，多种策略可选，能达到最佳的负载均衡效果；

缺点：是价格昂贵。

9.2 本地/全局负载均衡

负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群作负载均衡，全局负载均衡是指对分别放置在不一样的地理位置、有不一样网络结构的服务器群间做负载均衡。

本地负载均衡能有效地解决数据流量过大、网络负荷太重的问题，而且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障形成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即便是再给现有服务器扩充升级，也只是简单地增长一个新的服务器到服务群中，而不需改变现有网络结构、中止现有的服务。

全局负载均衡主要用于在一个多区域拥有本身服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离本身最近的服务器，从而得到最快的访问速度，也可用于子公司分散站点分布广的大公司经过Intranet（企业内部互联网）来达到资源统一合理分配的目的。

9.3 网络层次上的负载均衡

针对网络上负载太重的不一样瓶颈所在，从网络的不一样层次入手，咱们能够采用相应的负载均衡技术来解决现有问题。

随着带宽增长，数据流量不断增大，网络核心部分的数据接口将面临瓶颈问题，原有的单一线路将很难知足需求，并且线路的升级又过于昂贵甚至难以实现，这时就能够考虑采用链路聚合（Trunking）技术。

链路聚合技术（第二层负载均衡）将多条物理链路看成一条单一的聚合逻辑链路使用，网络数据流量由聚合逻辑链路中全部物理链路共同承担，由此在逻辑上增大了链路的容量，使其能知足带宽增长的需求。

现代负载均衡技术一般操做于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址，对每次 TCP链接请求动态使用其中一个内部IP地址，达到负载均衡的目的。在第四层交换机中，此种均衡技术获得普遍的应用，一个目标地址是服务器群VIP（虚拟 IP，Virtual IP address）链接请求的数据包流经交换机，交换机根据源端和目的IP地址、TCP或UDP端口号和必定的负载均衡策略，在服务器IP和VIP间进行映射，选取服务器群中最好的服务器来处理链接请求。

第七层负载均衡控制应用层服务的内容，提供了一种对访问流量的高层控制方式，适合对HTTP服务器群的应用。第七层负载均衡技术经过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。

第七层负载均衡优势表如今以下几个方面：

1）经过对HTTP报头的检查，能够检测出HTTP400、500和600系列的错误信息，于是能透明地将链接请求从新定向到另外一台服务器，避免应用层故障；

2）可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等），把数据流量引向相应内容的服务器来处理，增长系统性能；

3）能根据链接请求的类型，如是普通文本、图象等静态文档请求，仍是asp、cgi等的动态文档请求，把相应的请求引向相应的服务器来处理，提升系统的性能及安全性。

第七层负载均衡缺点表如今以下几个方面：

1）第七层负载均衡受到其所支持的协议限制（通常只有HTTP），这样就限制了它应用的普遍性；

2）第七层负载均衡检查HTTP报头会占用大量的系统资源，势必会影响到系统的性能，在大量链接请求的状况下，负载均衡设备自身容易成为网络总体性能的瓶颈。

十、经常使用的负载均衡算法

经常使用的负载均衡算法分为两类：

1）一种是静态负载均衡；

2）一种是动态负载均衡。

10.1 静态均衡算法

【10.1.1】轮询法：

将请求按顺序轮流地分配到每一个节点上，不关心每一个节点实际的链接数和当前的系统负载。

优势：简单高效，易于水平扩展，每一个节点知足字面意义上的均衡；

缺点：没有考虑机器的性能问题，根据木桶最短木板理论，集群性能瓶颈更多的会受性能差的服务器影响。

【10.1.2】随机法：

将请求随机分配到各个节点。由几率统计理论得知，随着客户端调用服务端的次数增多，其实际效果愈来愈接近于平均分配，也就是轮询的结果。

优缺点和轮询类似。

【10.1.3】源地址哈希法：

源地址哈希的思想是根据客户端的IP地址，经过哈希函数计算获得一个数值，用该数值对服务器节点数进行取模，获得的结果即是要访问节点序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会落到到同一台服务器进行访问。

优势：相同的IP每次落在同一个节点，能够人为干预客户端请求方向，例如灰度发布；

缺点：若是某个节点出现故障，会致使这个节点上的客户端没法使用，没法保证高可用。当某一用户成为热点用户，那么会有巨大的流量涌向这个节点，致使冷热分布不均衡，没法有效利用起集群的性能。因此当热点事件出现时，通常会将源地址哈希法切换成轮询法。

【10.1.4】加权轮询法：

不一样的后端服务器可能机器的配置和当前系统的负载并不相同，所以它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，下降其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

加权轮询算法要生成一个服务器序列，该序列中包含n个服务器。n是全部服务器的权重之和。在该序列中，每一个服务器的出现的次数，等于其权重值。而且，生成的序列中，服务器的分布应该尽量的均匀。好比序列{a, a, a, a, a, b, c}中，前五个请求都会分配给服务器a，这就是一种不均匀的分配方法，更好的序列应该是：{a, a, b, a, c, a, a}。

优势：能够将不一样机器的性能问题归入到考量范围，集群性能最优最大化；

缺点：生产环境复杂多变，服务器抗压能力也没法精确估算，静态算法致使没法实时动态调整节点权重，只能粗糙优化。

【10.1.5】加权随机法：

与加权轮询法同样，加权随机法也根据后端机器的配置，系统的负载分配不一样的权重。不一样的是，它是按照权重随机请求后端服务器，而非顺序。

【10.1.6】键值范围法：

根据键的范围进行负债，好比0到10万的用户请求走第一个节点服务器，10万到20万的用户请求走第二个节点服务器……以此类推。

优势：容易水平扩展，随着用户量增长，能够增长节点而不影响旧数据；

缺点：容易负债不均衡，好比新注册的用户活跃度高，旧用户活跃度低，那么压力就全在新增的服务节点上，旧服务节点性能浪费。并且也容易单点故障，没法知足高可用。

（注：以上所提到的单点故障，均可以用主从方式来解决，从节点监听主节点心跳，当发现主节点死亡，从节点切换成主节点顶替上去。这里能够思考一个问题，怎么设计集群主从能够最大程度上下降成本）

10.2 动态负债均衡算法
【10.2.1】最小链接数法：

根据每一个节点当前的链接状况，动态地选取其中当前积压链接数最少的一个节点处理当前请求，尽量地提升后端服务的利用效率，将请求合理地分流到每一台服务器。俗称闲的人不能闲着，你们一块儿动起来。

优势：动态，根据节点情况实时变化；

缺点：提升了复杂度，每次链接断开须要进行计数；

实现：将链接数的倒数当权重值。

【10.2.2】最快响应速度法：

根据请求的响应时间，来动态调整每一个节点的权重，将响应速度快的服务节点分配更多的请求，响应速度慢的服务节点分配更少的请求，俗称能者多劳，扶贫救弱。

优势：动态，实时变化，控制的粒度更细，跟灵敏；

缺点：复杂度更高，每次须要计算请求的响应速度；

实现：能够根据响应时间进行打分，计算权重。

【10.2.3】观察模式法：

观察者模式是综合了最小链接数和最快响应度，同时考量这两个指标数，进行一个权重的分配。

附录：更多架构设计方案的文章精选

[1] 有关IM架构设计的文章：

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑：架构设计、通讯协议和客户端》

《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》

《一套原创分布式即时通信(IM)系统理论架构方案》

《从零到卓越：京东客服即时通信系统的技术架构演进历程》

《蘑菇街即时通信/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信技术总监谈架构：微信之道——大道至简(演讲全文)》

《如何解读《微信技术总监谈架构：微信之道——大道至简》》

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》

《17年的实践：腾讯海量产品的技术方法论》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《现代IM系统中聊天消息的同步和存储方案探讨》

《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》

《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》

《IM开发基础知识补课(四)：正确理解HTTP短链接中的Cookie、Session和Token》

《WhatsApp技术实践分享：32人工程团队创造的技术神话》

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》

《IM系统的MQ消息中间件选型：Kafka仍是RabbitMQ？》

《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》

《以微博类应用场景为例，总结海量社交系统的架构设计步骤》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》

《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》

《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》

《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》

更多同类文章 ……

[2] 更多其它架构设计相关文章：

《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》

《快速理解高性能HTTP服务端的负载均衡技术原理》

《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》

《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》

《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》

《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》

《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》

《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》

《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》

《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》

（本文同步发布于：http://www.52im.net/thread-24...）