你知道多少？中层运维必须知道的10个问题数量重要吗？keepalived+lvs的组合，运行ipvsadm，输出显示每台后端服务器的连接数，有的服务器值高，有的值低。有人纠结：为什么服务器a的活跃数是90，而服务器b只有55？负载均衡的平衡是相对的。当访问次数较少时，差异会更加明显。一旦扩大规模，差异就会缩小。比如活跃用户几千，有的机器少几十、几百，你也不会觉得有什么不对。负载均衡的主要目标是高可用性。只要负载均衡、监控检查、故障转移这三个功能正常，从用户的角度来看，访问应用程序（如网站）是正常的，这就是重点。更多负载，更少一些负载并不重要。2.哪个负载均衡工具比较好？lvs+keepalived、haproxy+nginx、nginx+keepalived有几种组合。Keepalived是一致的选择，但其他工具中哪个更好？看场景，缓存应用，比如squid适合lvs；其他情况，您可以根据自己的使用习惯进行选择。现在一般的web服务，弃用apache，多选择nginx。如果再部署一个nginx做负载均衡，就变成了keepalived+nginx+nginx的形式。个人觉得有点别扭，更倾向于选择haproxy。3、vip不漂移怎么办？很多时候，可能是因为输入时粗心大意，犯了低级错误。比如keepalived中，主备系统的router_ids不一致，或者virtual_router_ids不一致。这种错误比较难排查，写的时候一定要小心。还有一种情况可能是同一个局域网内有多个负载均衡集群，集群之间的router_id和virtual_router_id应该是分开的，并且是唯一的。4.完成负载均衡的最佳实践？经常有人在网上求助，按照文档部署的集群无法正常工作。通过沟通，发现工作方式往往不正确。那么什么才是正确高效的做法（有人称之为***做法）呢？请阅读下文：检查后台真实服务是否正常。绑定负载均衡器本地ip（不要绑定vip），测试访问是否正常。绑定vip访问，查看访问是否正常。5、什么情况下需要负载均衡？有人说我没有那么多流量，用负载均衡有点浪费。负载均衡是实现高可用的手段之一，并不是基于流量。如果你的公司或组织的主要收入来自于网络，如果出现故障导致服务无法访问，损失是否可以承受，考虑清楚再做决定。还有人说，我用阿里云，腾讯云，弹性计算，高可用，买个高端的云主机，需要什么样的负载均衡？建议你多了解一下，这些云服务商有专门的负载均衡，要花钱，如果不需要，推这个有什么意义？6.开源软件不稳定吗？这是商业解决方案提供商的说辞。他们的市场比较成功，以至于一些技术人员，一提到开源方案，***的反应就是：开源稳定吗？性能好吗？前几天有个系统集成商才问问题，我就回答他：“你拿个商业软件，我找个对应的开源软件怎么样？”7.公有云负载均衡？大部分公有云不提供havip支持，技术上不容易实现负载均衡。从产品设计的角度来看，用户自己部署负载均衡会与云服务商推出的服务产生冲突。从其持续不断的产品线来看，它恨不得把所有的服务都囊括进去，让用户靠服务商赚钱。8、如何快速排除负载均衡故障？步骤如下：确定问题是部分还是全部？是网络问题还是系统问题？检查后台服务是否正常。因为后端才是真正提供服务的地方，是整个负载均衡系统的基础（即使负载均衡系统暂时崩溃，只要后端服务正常，可以采取临时措施直接暴露用户要求用户恢复业务）。实际工作中，大部分故障都集中在后端服务器上，比如著名的502。检查负载均衡是否正常。一般情况下，负载均衡服务器基本不会安装其他服务（一机多用户慎用）。因此，除了硬盘被日志填满导致的故障外，还有一种可能是硬件损坏。我管理的系统，运行时间最长的负载均衡服务器，已经八年多没有入巢了。9.负载均衡可以吗？部署负载均衡后，某些后端服务器可能会出现故障，并且其中一个负载均衡器本身可能会出现故障。看起来很让人安心，就算出现故障，也能暂时支撑一段时间。是不是慢慢感觉好点，想想再做故障恢复？***不要这样做，如果出现故障，发现后尽快修复故障，重新加入集群，不打心跳。10、负载均衡能承载多少并发？这与后端服务密切相关。后端程序和逻辑性能最好，承载并发量大；否则，它很小，没有确切的数据支持。在上线之前，可以对系统做压力测试，但是这个测试大部分是一致性测试（至少是同一个访问源），和真实的用户访问还是有很大区别的。真实用户的访问来源不同，访问对象也不同。例如，部分用户网络环境差，访问速度慢，一次连接完成时间长，占用资源释放时间长。这种测试可以作为一个大概的参考，要预留一定的余量进行评价。
