你是小阿巴，刚刚开发上线了自己的第一个网站。
前几天只有几个人访问，网站运行得稳稳当当。
你得意地想：做网站也太简单了吧！
结果一周后，某知名博主 "鱼蛋" 不小心推广了 你的网站，突然来了 1 万个用户同时访问，直接把你的网站服务器冲爆了！
你急得满头大汗，赶紧向号称 "后端之狗" 的鱼皮求救。
你：鱼皮 gie gie 救命啊！
鱼皮了解情况后，淡定地说：加服务器。
你恍然大悟：对哦，我买 3 台服务器，就有 3 个不同的 IP 地址了。只要让用户自己选择访问哪一台，就能分摊流量压力啦！
鱼皮笑了：但如果用户并不知道这些 IP 地址呢？
你挠了挠头：对啊，这可咋办！
鱼皮：这就要请出我的朋友 LB 了。
你一脸疑惑：LB 是啥？老板？链表？老鸨？
⭐️ 推荐观看视频版，有动画更容易理解：https://bilibili.com/video/BV1e92eBTEkL
第一阶段：认识负载均衡
鱼皮：LB 是指 负载均衡 （Load Balancer），它就像一个 "交通指挥中心"。车辆来了，不是自己随便选道路，而是由指挥中心统一调度走哪条路线，避免某条路堵死、其他路却空着。
对于你的问题，你需要一台 反向代理服务器 （负载均衡器），对外提供唯一的访问入口，统一接收所有用户的请求；再根据一定的规则，把请求分配给后端的多台服务器来实际处理，这样每台服务器的压力就小很多了。
你眼前一亮：原来如此，通过负载均衡，用户只需要访问同一个域名，完全不用关心我的网站背后有几台服务器，我可以使劲加服务器来提高网站的并发量。
鱼皮：不错，而且负载均衡器会实时监测后端服务器的健康状态。如果发现某台服务器挂了，就不再把流量分给它，自动切换到其他健康的服务器，保证用户访问不受影响。
此外，负载均衡器在实际使用中，还常常承担一些额外的职责。比如 SSL 卸载 ，让负载均衡器统一处理 HTTPS 的加密解密，后端服务器就不用每台都配置证书了，省事儿又减压。
第二阶段：怎么实现负载均衡？
你很是激动：哇，听起来很厉害啊！那我用什么来做负载均衡呢？
鱼皮：像 Nginx、HAProxy 等高性能网关软件都支持负载均衡功能。比如使用 Nginx，只需要写下这样一段配置：
upstream backend {
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
}
location / {
proxy_pass http://backend;
}由 3 台服务器组成了一个集群，Nginx 会自动把收到的请求分配给它们。
你开心了：这么简单，爽爽爽！我这就去实现~
于是你成功配置好了 Nginx 负载均衡，这下网站不崩了，用户访问也更顺畅了。
你得意地想：负载均衡不过如此，傻子都能学会哈哈哈哈哈哈！
第三阶段：负载均衡也扛不住了咋办？
一个月后，你的网站又不小心被一个更知名的博主 "驴皮" 分享了，瞬时用户量暴增到几十万，竟然把你部署 Nginx 的服务器都给冲爆了！
你慌了：呜啊，这破 Nginx 接不住这破天的富贵，怎么办啊！
难道再加一个 Nginx 来给 Nginx 做负载均衡？但这不是套娃吗？照样扛不住啊！
鱼皮：别慌！负载均衡不是只有一种，根据网络层次可以分很多类。
刚才你用的 Nginx，其实是 七层负载均衡 。它工作在应用层，可以根据 HTTP 请求的内容（比如 URL 路径、Cookie、请求头等）进行转发。
它的优点是最灵活、成本最低，大多数中小型网站用它就够了；但是一般单机只能支撑几万到十几万并发。
如果想更进一步增加并发，可以用 四层负载均衡 。它工作在传输层，只根据 IP 地址和端口号进行转发，不关心 HTTP 请求的具体内容。
正因如此，它的性能很高，能支撑几十万甚至上百万并发。
常用的实现方案是 LVS （Linux Virtual Server，Linux 虚拟服务器），它通过修改网络数据包的地址信息（IP 或 MAC），把请求转发到不同的服务器，速度极快。适用于某宝、某东这种级别的大型网站。
你：那有没有更厉害的？我担心自己的网站一不小心成为国民级应用。
鱼皮：当然！还有二层和三层负载均衡 。或者利用专业的硬件设备做负载均衡，比如性能极高的 F5，但价格也极高，入门级的设备都要十几万。
你大为震惊：哎呀，这我可买不起了呀......
鱼皮：快醒醒吧，这种硬件负载均衡主要用于金融、电信等大型企业，咱们一般用不到。
你突然想到：对了，我听说有些大公司会用 DNS 来做负载均衡，这算是哪一层呢？
鱼皮：问得好，DNS 负载均衡 比较特殊。它严格来说属于应用层，但工作原理和前面讲的都不太一样。
传统负载均衡是用户请求已经到达服务器后再分配，而 DNS 负载均衡是在用户浏览器查询域名对应的 IP 地址时，DNS 服务器就根据策略（如地域、负载）返回不同的服务器 IP，从而实现流量分配。
它的优点是实现简单、成本低，适合做全球流量分配，比如国内用户访问国内服务器，海外用户访问海外服务器。
缺点是不够灵活，而且 DNS 有缓存，改了配置不能立即生效。
第四阶段：负载均衡算法
你点点头：那我还是老老实实用七层和四层负载均衡吧。对了，负载均衡器怎么知道把请求分给哪台服务器呢？
鱼皮：这就要靠 负载均衡算法 了，算法分两大类 ------ 静态算法和动态算法。
静态算法就是按照固定的规则分配。
1）首先是最简单的轮询算法（Round Robin）。就像发扑克牌一样，一张一张轮着来（第一个请求给服务器 A，第二个给服务器 B，第三个给服务器 C，然后又回到服务器 A），发完一轮再来一轮。
看起来很公平，但如果服务器性能不一样，有的很闲、有的很忙，怎么办？
2）加权轮询（Weighted Round Robin） 就能解决这个问题，你可以给性能高的服务器设置更高的权重，让它处理更多请求。
你：等等，如果用户第一次请求分配到服务器 A 并保存了登录态，第二次请求分配到服务器 B，登录态不就丢失了么？
鱼皮：没错，能想到这点的你非常棒！
3）我们可以用 IP 哈希（Hash）算法来解决这个问题。根据用户的 IP 地址计算一个哈希值，然后分配到对应的服务器。这样同一个用户的请求总是会分配到同一台服务器，登录态就不会丢了。
不过 IP Hash 也有缺点，如果很多用户来自同一个大局域网，可能会导致流量分配不均哦，所以现在主流还是用 Redis 做共享 Session。这也是面试时的一个考点（Session 一致性问题的解决方案）。
鱼皮：动态算法更灵活，会根据服务器的实时状态来分配请求。
1）最少连接（Least Connections）：哪台服务器当前连接数最少、最闲，就优先把请求分给谁。
2）最快响应（Least Response Time）：哪台服务器的响应速度最快、干活最麻利，就优先把请求分给谁。
小阿巴：这么多算法，记不住啊！哪个最常用啊？
鱼皮笑道：算法千千万，轮询占一半。实际工作中，大部分场景用轮询或加权轮询就够了。
第五阶段：其他重要知识点
你：那负载均衡器怎么知道后端服务器是否健康呢？
鱼皮：这就是 健康检查 机制。负载均衡器会定期（比如每隔几秒）向后端服务器发送心跳请求，检查服务器是否正常响应。
如果连续多次失败，就认为这台服务器挂了，自动把它从服务器列表中剔除。等服务器恢复后，再自动添加回来。
你：哇，就像医院里的护士定时查房一样，太贴心了吧！
等等，负载均衡器能监测后端服务器、替它们分摊压力，但是万一负载均衡器自己挂了怎么办？
鱼皮：问得好，这就是负载均衡的 高可用 问题。
解决办法是部署多个负载均衡器，采用主从模式。主负载均衡器正常工作，从负载均衡器随时待命。它们之间会互相发送心跳包，并共享一个虚拟 IP 地址（VIP）。
一旦从节点发现主节点没有回应了，就接管这个虚拟 IP，用户访问的还是同一个 IP 地址，所以毫无感知。
结尾
你感慨道：哇，原来负载均衡有这么多学问！作用、分类、算法，学到了学到了~
那...... 我现在算是负载均衡专家了吧？！
鱼皮从裤兜里掏出两个硬币砸到你的头上：想啥呢？！你现在只是了解了负载均衡的思想，但是实际开发中还有很多玩法。对了，我之前在 编程导航 分享过一个 Nginx 学习路线，建议你系统学习一下。
你虚心地点点头：好的，狗鱼皮！