解决Redisson无法连接Sentinel, Netty查找DNS失败

前言

这里 redisson 的版本为 3.11.2, 对应 netty-all 的版本为 4.1.38.Final
如果这篇描述的方法不能解决问题，可以参考另外一篇 Redisson-3.8 查找DNS异常的解决办法
redisson 其实没问题，问题出在 netty 身上，而且神经得很。
之前的 netty 查找 DNS 失败，是因为解析 /etc/resolv.conf 文件有 bug，而这个版本的 netty 则是代码有 bug。

现象

使用 redisson 的应用程序运行时出错，报错信息：

Exception in thread "main" org.redisson.client.RedisConnectionException: At least two sentinels should be defined in Redis configuration! SENTINEL SENTINELS command returns empty result!
	at org.redisson.connection.SentinelConnectionManager.<init>(SentinelConnectionManager.java:188)
	at org.redisson.config.ConfigSupport.createConnectionManager(ConfigSupport.java:197)
	at org.redisson.Redisson.<init>(Redisson.java:120)
	at org.redisson.Redisson.create(Redisson.java:160)
	at com.ericsson.jee.iam.common.redisson.util.RedissonFactory.initRedissonObject(RedissonFactory.java:27)
	at test.Test.main(Test.java:17)

连接使用的 URL：sentinel://redis:26379?. . .

sentinel URL 的说明

你可能会觉得奇怪，报错明明说了至少需要2个 sentinel，但是 URL 却只写了一个 (redis:26379)，是不是这里出的问题?

其实不然，redisson 在启动的时候，会通过 URL 中配置的 sentinel 信息，访问 sentinel 节点，然后从 sentinel 节点获取同一集群中其他 sentinel 节点的信息，因此 URL 中只需要一个 sentinel 的信息就可以了。很多时候我们在 URL 中填写多个 sentinel 的连接信息，是出于容错的考虑，如果使用第一个 sentinel 的信息连接不上，那就使用第二个，依次类推。

DNS 环境和配置描述

从 URL 中可以看出，sentinel 连接信息使用的是域名 redis，而不是 IP 地址，因此需要先确认 DNS 的可用。本次实验环境在本地安装了 bind9 用以提供 DNS 服务。

helowken@helowken-mint ~ $ ping redis
PING redis.ostechnix.lan (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.016 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.031 ms

/etc/resolv.conf 内容：

helowken@helowken-mint ~ $ cat /etc/resolv.conf 
nameserver 127.0.0.1
nameserver 202.96.128.166
nameserver 202.96.134.133
nameserver 163.15.15.15
search xxx.yyy ostechnix.lan

nameserver 表示 DNS 服务器地址：

127.0.0.1 是安装在本地的 DNS 服务器 bind9
202.xxx.xxx.xxx 是电信运营商自动生成的
163.15.15.15 是一个不存在 IP 地址，用于本次实验

search 表示自动添加到域名后面的搜索域：

xxx.yyy 是一个没有记录搜索域，用于本次实验
ostechnix.lan 存在于本地 bind9 的配置中，可以被 bind9 正确解析

使用 nslookup 可以再次确认 DNS 的可用：

helowken@helowken-mint ~ $ nslookup redis 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#53

Name:	redis.ostechnix.lan
Address: 127.0.0.1

使用 dig 查询完整的 DNS 记录信息

helowken@helowken-mint ~ $ dig @127.0.0.1 redis.ostechnix.lan

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 redis.ostechnix.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5064
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redis.ostechnix.lan.		IN	A

;; ANSWER SECTION:
redis.ostechnix.lan.	86400	IN	A	127.0.0.1

;; AUTHORITY SECTION:
ostechnix.lan.		86400	IN	NS	pri.ostechnix.lan.
ostechnix.lan.		86400	IN	NS	sec.ostechnix.lan.

;; ADDITIONAL SECTION:
pri.ostechnix.lan.	86400	IN	A	192.168.1.200
sec.ostechnix.lan.	86400	IN	A	192.168.1.201

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Nov 02 02:28:49 CST 2019
;; MSG SIZE  rcvd: 132

从 dig 的输出中可以看到返回了地址记录：

;; ANSWER SECTION:
redis.ostechnix.lan.	86400	IN	A	127.0.0.1

综上所述，可以得知：

使用域名 “redis” 时，会自动添加搜索域 “ostechnix.lan”
向 nameserver 127.0.0.1 (bind9) 发送 DNS 查询请求 “redis.ostechnix.lan”，会得到实际的地址 127.0.0.1

使用 redis-cli 确认 sentinel 是可以连接的：

helowken@helowken-mint ~/redis-2.8.21 $ src/redis-cli -h redis -p 26379
redis:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6379"

接下来使用 dig 尝试往 “202.96.128.166” 发送查询请求：

helowken@helowken-mint ~ $ dig @202.96.128.166 redis.ostechnix.lan

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @202.96.128.166 redis.ostechnix.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18859
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;redis.ostechnix.lan.		IN	A

;; AUTHORITY SECTION:
.			1800	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2019110101 1800 900 604800 86400

;; Query time: 8 msec
;; SERVER: 202.96.128.166#53(202.96.128.166)
;; WHEN: Sat Nov 02 02:40:34 CST 2019
;; MSG SIZE  rcvd: 112

没有看到 “ANSWER SECTION”，也就是说没有查找到地址记录。(202.96.134.133 结果类似)

再尝试 dig “163.15.15.15”：

helowken@helowken-mint ~ $ dig @163.15.15.15 redis.ostechnix.lan

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @163.15.15.15 redis.ostechnix.lan
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

发现连接超时。

如果依次往所有 nameserver 查询 “redis.xxx.yyy”，会发现：

127.0.0.1 和 202.xxx.xxx.xxx 都没有地址记录
163.15.15.15 连接超时

因此，我们可以得到以下表格：

Netty 源码分析

因为源码内容较多，这里直接给出主要的逻辑：

当满足以下两个条件时，DNS 查找过程将终止：
- allowedQueries 递减为 0
- nameserver 列表已经遍历完
allowedQueries 表示查找过程总共允许多少次查询，每发起一次查询就减 1。
查询会一个接一个 nameserver 地进行尝试，上一个 nameserver 查找失败后（没有记录，超时，网络问题），才会往下一个 nameserver 发送查询请求。
查询的时候会把搜索域（search domain）添加到名称的后面形成全路径（如果名称没有以"."结尾）。搜索域也是一个接一个地进行尝试，只要在上一个搜索域遍历完所有 nameserver 后都查找失败，才有可能使用下一个搜索域。
查找过程会同时发起 “A” 和 “AAAA” 记录的查询请求。“A” 记录表示 IPv4 的地址记录，“AAAA” 表示 IPv6 的地址记录。
如果所有 nameserver 查询 “A” 或 “AAAA” 记录都失败，且满足以下条件，则转为查询 “CNAME” 记录（“CNAME” 表示别名，相当于做多了一次命名映射）：
- allowedQueries 还没有递减到 0
- 最后一次使用的 nameserver 没有出现错误
查询 “CNAME” 记录时，将重新遍历nameserver 列表，若 “CNAME” 有结果返回，则使用 “CNAME” 的结果再次查询 “A” 或 “AAAA” 记录。
如果在查找过程中，任一 nameserver 返回了记录，则终止查找。如果出现了错误，则使用下一个 nameserver 继续进行查询。
当 allowedQueries 递减到为 0 时，如果还没有找到 “A” 或 “AAAA” 记录，则返回 UnknownHostException。
如果最后一次查询出现了超时或者网络错误，则把 UnknownHostException 的 cause 设置为该错误。
检查返回的结果，如果存在 UnknownHostException，则检查它的 cause：
- if 超时或者网络错误，则最终判定为查找失败
- else if 还有搜索域可用，则使用下一个搜索域，重复上述的逻辑，开始新一轮的查找，且 allowedQueries 会重置为初始值
- else 其他的逻辑（当前可以省略）

实验

为了更容易和准确地得到实验结果，我稍微更改了一下 netty 的源码，调整的内容有：

allowedQueries 根据每个实验进行设置
只查询 “A” 记录，不查询 “AAAA” 记录。如果两个都进行查询，会因为异步调用而出现随机性。
把查询超时从 5s 修改为 1s，这是为了快速得到结果。

本实验环节为了简单，不配置 CNAME 记录。

实验1

nameserver 127.0.0.1
nameserver 202.96.128.166
nameserver 202.96.134.133
nameserver 163.15.15.15

search xxx.yyy ostechnix.lan

allowedQueries	Result
1 ~ 3	Pass
>= 4	Failed

结果分析：

当 allowedQueries 为 1~3 的时候，查询 “redis.xxx.yyy” 都没有记录，因此返回了 UnknownHostException，但因为没有超时或网络错误，且还有 “ostechnix.lan” 这个搜索域可用，所以用 “redis.ostechnix.lan” 开启新一轮查找，最后在 127.0.0.1 上查询到记录。
当 allowedQueries >= 4 时，第一轮查询的最后一个 nameserver 是 163.15.15.15，由于网络不可达，返回了超时错误，按照上面源码分析的结果，最终判定查找失败。（即使这时 allowedQueries > 0 也不会查询 “CNAME”，因为最后一次查询出了错）

实验2

nameserver 127.0.0.1
nameserver 202.96.128.166
nameserver 202.96.134.133
nameserver 163.15.15.15

search ostechnix.lan xxx.yyy

allowedQueries	Result
N (N >= 1)	Pass

结果分析：

只要 allowedQueries >= 1，在第一轮查找时，都会在 127.0.0.1 上查询到 “redis.ostechnix.lan” 的地址记录，所以 100% pass。

实验3

nameserver 202.96.128.166
nameserver 202.96.134.133
nameserver 163.15.15.15
nameserver 127.0.0.1

search xxx.yyy ostechnix.lan

allowedQueries	Result
1 ~ 3	Failed
4 ~ 6	Pass
7	Failed
>= 8	Pass

结果分析：

当 allowedQueries 为 1~3 时，无论使用哪个搜索域，前 3 个 nameserver 都无法返回地址记录（202.xxx.xxx.xxx 是没有查找到记录，而 163.15.15.15 会超时），因为 allowedQueries 不够次数使请求落到 127.0.0.1 上面，所以最终判定查找失败。
当 allowedQueries == 4 时，第一轮搜索 “redis.xxx.yyy”，所有 nameserver 都查找失败，这时 allowedQueries 递减到 0，且最后一个 nameserver 是 127.0.0.1，虽然没有查询到记录，但也没有出现超时或者网络错误，于是使用 “redis.ostechnix.lan” 开启新一轮查找。第二轮查找时，最终会在 127.0.0.1 上查询到记录。
当 allowedQueries == [5, 6] 时，第一轮搜索 “redis.xxx.yyy”，所有 nameserver 都查找失败，这时 allowedQueries 递减到 2，因为最后一次查询是在 127.0.0.1 上进行的，虽然无记录但没有出错，于是从头遍历 nameserver 列表查找 “CNAME” 记录。但是两台 202.xxx.xxx.xxx 都无法查询到记录，这时 allowedQueries 递减到 0，因为最后一次查询 "CNAME"记录时虽然无记录，但也没有出现超时或者网络错误，于是使用 “redis.ostechnix.lan” 开启新一轮查找，最终在 127.0.0.1 上查询到记录。
当 allowedQueries == 7 时，第一轮搜索 “redis.xxx.yyy”，所有 nameserver 都查找失败，这时 allowedQueries 递减到 3，因为最后一次查询是在 127.0.0.1 上进行的，虽然无记录但没有出错，于是从头遍历 nameserver 列表查找 “CNAME” 记录。但是前 3 台 nameserver 都查找失败，这时 allowedQueries 递减到 0，因为最后一次查询 “CNAME” 记录是在 163.15.15.15 上进行的，出现了超时错误，所以最终判定查找失败。
当 allowedQueries >= 8 时，第一轮搜索 “redis.xxx.yyy”，所有 nameserver 都查找失败，这时 allowedQueries >= 4，因为最后一次查询是在 127.0.0.1 上进行的，虽然无记录但没有出错，于是从头遍历 nameserver 列表查找 “CNAME” 记录。虽然最后所有 nameserver 都查找失败，但是因为最后的查询请求是落在 127.0.0.1 上的，没有超时或网络错误，所以使用 “redis.ostechnix.lan” 开启新一轮查找，最后在 127.0.0.1 上查询到记录。

PS：你还可以进行更多的实验，根据上面的逻辑进行分析。

结论

解决办法

为了保证 Netty 查找 DNS 能成功，最好遵循以下准则：

Netty 应用使用的搜索域，尽可能放在 /etc/resolv.conf 文件中 “search” 行的第一位
用于解析第1点中的搜索域的 nameserver，尽可能放在 /etc/resolv.conf 文件中 nameserver 列表的最上面
尽可能把网络不可达的 nameserver 从 /etc/resolv.conf 文件中删除

PS:

Netty 对于 DNS 的默认查询超时是 5s，查询是一个接一个搜索域，一个接一个 nameserver 地串行进行的。如果存在 M 个无效的搜索域，N 个网络不可达的 nameserver，那么等待 DNS 查找结果的最差时间就会 >= (M * N * 5 * 2)s。（查找 “CNAME” 记录和查找 “A” 或 “AAAA” 地址记录一样，所以 *2 ）
Netty 默认的 allowedQueries 为16，不要以为很多，因为是 “A” 和 “AAAA” 查询共用的，再加上 “CNAME” 的查询，能允许犯错的 nameserver 节点其实很少。
在实际查询过程中，“A” 和 “AAAA” 都是异步进行的，会存在运行顺序和返回结果先后的不确定性，当 allowedQueries 递减为 0 时，是无法确定最后一次查询使用哪个搜索域以及落在哪台 nameserver 上的，因此不要依赖这种顺序去配置 nameserver 的位置和搜索域的先后次序。
Netty 查找 DNS 的代码，使用的全是 async 模式，性能虽然好，但是不容易阅读和维护，而且调试中发现不少逻辑存在问题，譬如：
- allowedQueries 递减到 0 了，还继续查询，查询又不断递归，最后直到遍历完所有 nameserver 才终止，但这个过程中其实什么都没干，因为每次进行真正的查询之前都需要检验 allowedQueries > 0
- 当最后一次查询出现错误时，就停止尝试剩余的搜索域

实验涉及到的 Netty 源码文件

查找 DNS：
io.netty.resolver.dns.DnsResolveContext

设置查询超时和 allowedQueries：io.netty.resolver.dns.DnsNameResolverBuilder

额外的测试代码

以下是模拟 Netty 发送 DNS 请求的代码，根据 Netty 的源码得来。

package io.netty.handler.codec.dns;

import io.netty.buffer.ByteBuf;
import io.netty.buffer.PooledByteBufAllocator;
import io.netty.util.internal.PlatformDependent;
import io.netty.util.internal.StringUtil;

import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.InetSocketAddress;

public class DnsClient {
    private static final InetSocketAddress address = new InetSocketAddress("localhost", 53);
    private static final DnsRecordDecoder recordDecoder = DnsRecordDecoder.DEFAULT;
    private static final int BUF_LENGTH = 1024;

    public static void main(String[] args) throws Exception {
        int id = PlatformDependent.threadLocalRandom().nextInt(65536 - 1) + 1;
        DnsQuestion question = new DefaultDnsQuestion(
                "redis.ostechnix.lan.",
                new DnsRecordType(1, "A")
        );
        DnsQuery query = new DatagramDnsQuery(null, address, id);
        query.setRecursionDesired(true);
        query.addRecord(DnsSection.QUESTION, question);
        DnsRecord optResource = new AbstractDnsOptPseudoRrRecord(4096, 0, 0) {
        };
        query.addRecord(DnsSection.ADDITIONAL, optResource);

        ByteBuf buf = new PooledByteBufAllocator().ioBuffer(BUF_LENGTH);
        new DnsQueryEncoder(DnsRecordEncoder.DEFAULT).encode(query, buf);

        byte[] bs = new byte[buf.readableBytes()];
        buf.getBytes(0, bs);
        DnsQuery dnsQuery = sendAndReceive(bs);
        print(dnsQuery);
    }

    private static void print(DnsQuery msg) {
        System.out.println(msg);
        System.out.println("===========================");
        StringBuilder sb = new StringBuilder();
        printSection(sb, msg, DnsSection.ADDITIONAL);
        printSection(sb, msg, DnsSection.ANSWER);
        System.out.println(sb);
    }

    private static void printSection(StringBuilder sb, DnsQuery message, DnsSection section) {
        final int count = message.count(section);
        for (int i = 0; i < count; i++) {
            DnsRecord record = message.recordAt(section, i);
            if (record instanceof DefaultDnsRawRecord)
                printRecord((DefaultDnsRawRecord) record, sb);
        }
    }

    private static void printRecord(DefaultDnsRawRecord record, StringBuilder buf) {
        final DnsRecordType type = record.type();
        if (type == DnsRecordType.OPT)
            return;
        buf.append(StringUtil.NEWLINE).append(StringUtil.TAB);
        buf.append(record.name().isEmpty() ? "<root>" : record.name()).append(" => ");
        ByteBuf byteBuf = record.content();
        if (type.intValue() == DnsRecordType.A.intValue()) {
            byte[] bs = new byte[byteBuf.readableBytes()];
            byteBuf.readBytes(bs);
            try {
                buf.append(
                        InetAddress.getByAddress(bs)
                );
            } catch (Exception e) {
                e.printStackTrace();
            }
        } else {
            buf.append(byteBuf.readableBytes()).append("B)");
        }
    }

    private static DnsQuery sendAndReceive(byte[] bs) throws Exception {
        DatagramSocket socket = new DatagramSocket();
        DatagramPacket packet = new DatagramPacket(bs, bs.length, address);
        socket.send(packet);
        packet = new DatagramPacket(new byte[BUF_LENGTH], BUF_LENGTH);
        socket.receive(packet);

        ByteBuf buf = new PooledByteBufAllocator().ioBuffer(BUF_LENGTH);
        buf.writeBytes(packet.getData(), 0, packet.getLength());

        return decode(buf);
    }

    private static DnsQuery decode(ByteBuf buf) throws Exception {
        final DnsQuery query = newQuery(buf);
        final int questionCount = buf.readUnsignedShort();
        final int answerCount = buf.readUnsignedShort();
        final int authorityRecordCount = buf.readUnsignedShort();
        final int additionalRecordCount = buf.readUnsignedShort();

        decodeQuestions(query, buf, questionCount);
        decodeRecords(query, DnsSection.ANSWER, buf, answerCount);
        decodeRecords(query, DnsSection.AUTHORITY, buf, authorityRecordCount);
        decodeRecords(query, DnsSection.ADDITIONAL, buf, additionalRecordCount);
        return query;
    }

    private static DnsQuery newQuery(ByteBuf buf) {
        final int id = buf.readUnsignedShort();

        final int flags = buf.readUnsignedShort();
//        if (flags >> 15 == 1) {
//            throw new CorruptedFrameException("not a query");
//        }
        final DnsQuery query =
                new DatagramDnsQuery(
                        null,
                        address,
                        id,
                        DnsOpCode.valueOf((byte) (flags >> 11 & 0xf)));
        query.setRecursionDesired((flags >> 8 & 1) == 1);
        query.setZ(flags >> 4 & 0x7);
        return query;
    }

    private static void decodeQuestions(DnsQuery query, ByteBuf buf, int questionCount) throws Exception {
        for (int i = questionCount; i > 0; i--) {
            query.addRecord(DnsSection.QUESTION, recordDecoder.decodeQuestion(buf));
        }
    }

    private static void decodeRecords(
            DnsQuery query, DnsSection section, ByteBuf buf, int count) throws Exception {
        for (int i = count; i > 0; i--) {
            final DnsRecord r = recordDecoder.decodeRecord(buf);
            if (r == null) {
                break;
            }

            query.addRecord(section, r);
        }
    }
}

以下是本实验中 bind9 的 DNS 配置文件：

helowken@helowken-mint ~ $ cat /etc/bind/for.ostechnix.lan 
$TTL 86400
@   IN  SOA     pri.ostechnix.lan. root.ostechnix.lan. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
)
$ORIGIN ostechnix.lan.
@       IN  NS          pri.ostechnix.lan.
@       IN  NS          sec.ostechnix.lan.
@       IN  A           192.168.1.200
@       IN  A           192.168.1.201
@       IN  A           192.168.1.202
pri     IN  A           192.168.1.200
sec     IN  A           192.168.1.201
client  IN  A           192.168.1.202
redis	IN	A			127.0.0.1
redis	IN	AAAA		::1

Helowken.Lin

发布了22 篇原创文章 · 获赞 7 · 访问量 1万+

私信关注

解决Redisson无法连接Sentinel, Netty查找DNS失败

前言

现象

sentinel URL 的说明

DNS 环境和配置描述

Netty 源码分析

实验

实验1

实验2

实验3

结论

解决办法

实验涉及到的 Netty 源码文件

额外的测试代码

Wireshark 安装+使用（一）

解決Redisson無法連接Sentinel, Netty查找DNS失敗

使用Instrumentation和Javassist修改web應用字節碼

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結