Linux intranet Environment DNS modified domain name point, Java application can switch the problem of real-time summary

Many of the calling resources (databases, web interfaces, etc.) in the intranet environment of the company are mapped by domain name-IP through the intranet DNS service.

However, when the DNS mappings are changed, the resources connected in the application are not changed.

Previously, it was generally considered that the Linux DNS cache resulted in a complete analysis today, with the following results:

1. Caching of local DNS for Linux systems

The CentOS system itself does not contain a caching mechanism for DNS unless the NSCD service (name Server cache daemon) is installed and started.

After the NSCD service starts, it will default to a cache of all DNS resolution on-premises, the expiration time is 3,600 seconds by default, and the restart application will not reset the NSCD cache unless the NSCD cache is forced to flush with/ETC/INIT.D/NSCD reload.

Turning on the NSCD service can significantly reduce the frequency of application requests for DNS services, while at the same time providing some degree of fault tolerance for DNS services. However, the shortcomings are obvious, the mapping changes of the DNS service cannot be sensed by the application in real time and must be reload NSCD on all client machines each time the mapping is modified.

The above conclusions are verified through the DNS service log.

2. Local DNS cache for JVM virtual machines

Implementing a simple DNS caching mechanism in Java.net.InetAddress, which was previously mistaken for the DNS cache of Linux, is cached for 30 seconds by default in Jdk6/7.

The cache scope is the JVM virtual machine process, which means that in the same JVM process, only one domain name is requested for a DNS server in 30 seconds, which can greatly reduce the network loss of the application to DNS resolution and the pressure on the DNS service.

The above conclusions are verified by the Java test program and the DNS service log.

3. Processing of long connections (database links, redis connections, zookeeper, ACTIVEMQ connections, etc.)

According to 1, 22 point conclusion, when the intranet DNS service a domain name Mapping modified, the application will be in the maximum of 30 seconds to change. This is not true, however, because many resources are "long-connected" ways.

such as database connection pool This is a typical long-term connection, in order to ensure the efficiency of the connection pool, we can not set the validity of a single connection too short. This has led to the inability of such long connections to respond quickly to changes in the mapping of DNS servers.

There is only one workaround: After the mapping of the DNS server changes, the application needs to be restarted to allow long connections to be established according to the new DNS mappings.

The above conclusions are verified by the Java test program and the DNS service log.

A lap, and finally back to the original point:

To ensure that these long-connected resources in the application respond to changes in DNS mappings in a timely manner, it is still time to restart the application to resolve them.

Linux intranet Environment DNS modified domain name point, Java application can switch the problem of real-time summary