Linux内网环境DNS修改域名指向，JAVA应用程序可否实时切换的问题总结

公司内网环境中许多调用资源（数据库、web接口等）都是经过内网DNS服务来进行域名-IP的映射。

但常常出现DNS映射修改完毕后，应用中链接的资源迟迟没有变动。

之前一直笼统的认为是linux的dns缓存致使，今天作了一次完整的分析，结果以下：

 

一、Linux系统的本地DNS的缓存

CentOS系统自己并不包含DNS的缓存机制，除非安装并启动了nscd服务（name server cache daemon）。

nscd服务启动后会默认为本地的全部dns解析作一层缓存，过时时间默认为3600秒，重启应用程序也不会重置nscd的缓存，除非用/etc/init.d/nscd reload，强制刷新nscd缓存。

开启nscd服务能够大大下降应用程序请求DNS服务的频率，同时必定程度上能够对DNS服务的故障有必定容错。但缺点很是明显，DNS服务的映射改变没法实时的被应用程序感知，每次修改映射后都必须在全部客户端机器reload nscd。

以上结论经过DNS服务日志获得验证。

 

二、JVM虚拟机的本地DNS缓存

实如今java.net.InetAddress的一个简单的DNS缓存机制，之前被误认为是Linux的DNS缓存，jdk6/7中默认为缓存30秒。

缓存范围为JVM虚拟机进程，也就是说同一个JVM进程中，30秒内只会为一个域名请求DNS服务器一次，能够大大下降应用程序对DNS解析的网络损耗和对DNS服务产生的压力。

以上结论经过JAVA测试程序和DNS服务日志获得验证。

 

三、长链接的处理（数据库连接、redis链接、zookeeper、activeMQ链接等）

根据一、2两点结论，当内网DNS服务某一个域名映射修改后，应用程序最多在30秒内就会响应该变化。但实际确不是如此，缘由就是不少资源是“长链接”方式。

好比数据库链接池这种就是典型的长链接，为了保证链接池效率，咱们也不能把单个链接的有效期设的过短。这就致使了这类长链接没法快速响应DNS服务器的映射改变。

解决办法只有一个：DNS服务器的映射变动后，须要对应用程序作重启，以便让长链接按照新的DNS映射来进行创建。

以上结论经过JAVA测试程序和DNS服务日志获得验证。

 

饶了一圈，最后仍是回到原点：

为了保证应用程序里的这些长链接资源可以及时响应DNS映射的改变，目前仍是得靠重启应用来解决。