说到DNS轮询这个负载均衡方案，我不得不承认它确实是个简单粗暴的解决方案。记得刚开始接触运维工作时，我就像发现新大陆一样兴奋地给公司系统配置了多A记录轮询——毕竟这比搭建专门的负载均衡器简单太多了！不过后来吃的几次亏让我明白，这种方案真是让人又爱又恨。
DNS轮询的核心优势
你看啊，DNS轮询最大的优点就是成本近乎为零。不需要任何额外的硬件或软件负载均衡器，只要在域名解析时设置多个A记录，请求就会自动分配到不同的服务器上。这对初创公司或者预算有限的团队来说简直太友好了。而且它实现起来特别简单，几分钟就能搞定，不像Nginx这些还要写配置、做测试。
另一个容易被忽视的优势是扩展性。要增加服务器？只需要在DNS里加一个A记录就行了。不需要像其他方案那样复杂的负载均衡器配置。这在大促期间临时扩容的场景下特别实用，我们只要准备好服务器，扩容简直是一键式操作。
痛点也同样明显
但现实往往比理想骨感得多。我最烦的就是这个方案的健康检测问题——DNS根本不管后端服务器是死是活。还记得有次服务器宕机了，用户还在不断被解析到这台机器，导致大规模报错。天呐，那天客服电话都被打爆了！直到现在想起来还是心有余悸。
还有个更让人头大的是会话保持的问题。用户第一次访问被解析到服务器A，第二次可能就被分到服务器B了。如果应用有状态的话，这就可能造成Session丢失。你能想象用户正购物到一半突然被退出登录的愤怒吗？我自己体验过，当时差点没把鼠标摔了。
TTL参数的双刃剑
为了避免DNS解析不及时的问题，我试过把TTL(生存时间)设得很短，比如30秒。理论上这样可以让故障转移更快，但实际效果却适得其反——客户端频繁发起DNS查询反而增加了系统负担。有个数据很有意思：当TTL低于300秒时，DNS请求量会指数级增长，这对小型DNS服务器简直就是灾难！
所以后来我学乖了，把TTL设为5分钟这个折中的数值。既不会让DNS负载太高，又能保证在服务器出问题时能在合理时间内完成切换。这个经验是从一次痛苦的线上事故中总结出来的，代价是整整一晚上的熬夜处理。
哪些场景仍然适用？
虽然缺点不少，但DNS轮询在特定场景下还是有其价值。比如静态资源分发这种无状态的场景，或者作为应急方案配合其他负载均衡方案使用。我在为公司部署CDN时就采用了DNS轮询+智能解析的结合方案，效果出奇的好。
不过说真的，随着云服务发展，现在很多云厂商提供的智能DNS解析已经能解决传统DNS轮询的很多痛点。如果你还在纠结要不要用DNS轮询，我的建议是：对于重要业务还是上专业负载均衡方案吧，省的那些莫名其妙的故障会让你生不如死的！
评论