这个问题出现在一套搭建在虚拟机上的Kubernetes 1.18集群上。集群有三个节点：

# kubectl get node -o wide
NAME              STATUS   VERSION   INTERNAL-IP      OS-IMAGE                KERNEL-VERSION              CONTAINER-RUNTIME
192.168.104.51    Ready    v1.18.3   192.168.104.51   CentOS Linux 7 (Core)   3.10.0-862.3.2.el7.x86_64   docker://19.3.9
192.168.104.72    Ready    v1.18.3   192.168.104.72   CentOS Linux 7 (Core)   3.10.0-862.3.2.el7.x86_64   docker://19.3.9
192.168.104.108   Ready    v1.18.3   192.168.104.108  CentOS Linux 7 (Core)   3.10.0-862.3.2.el7.x86_64   docker://19.3.9

KeyDB通过StatefulSet管理，一共有三个实例： 

# kubectl -n default get pod -o wide -l app.kubernetes.io/name=keydb
NAME             READY   STATUS    RESTARTS     IP             NODE            
keydb-0   1/1     Running   0            172.29.2.63     192.168.104.108 
keydb-1   1/1     Running   0            172.29.1.69     192.168.104.72  
keydb-2   1/1     Running   0            172.29.1.121    192.168.104.51

这三个实例：

1. 由于反亲和设置，会在每个节点上各运行一个实例
2. 启用Active - Active（--active-replica）模式的多主（--multi-master）复制 ：每个实例都是另外两个的Slave，每个实例都支持读写

出现一个节点宕机的情况，就可能出现此故障。经过一段时间以后，会出现GET/PUT或者任何其它请求处理缓慢的情况。

此故障有两个明显的特征：

1. 故障出现前需要等待的时间，随机性很强，有时甚至测试了数小时都没有发现请求缓慢的情况。常常发生的情况是，宕机后剩下的两个实例，一个很快出现缓慢问题，另外一个却还能运行较长时间
2. 请求处理延缓的时长不定，有时候没有明显延缓，有时候长达10+秒。而且一次缓慢请求后，可以跟着10多次正常速度处理的请求。这个特征提示故障和某种周期性的、长时间占用的锁有关。在锁被释放的间隙，请求可以被快速处理

我们将节点192.168.104.108强制关闭，这样实例keydb-0无法访问，另外两个节点无法和它进行Replication。

分别登录另外两个节点，监控GET/SET操作的性能：

kubectl -n default exec -it keydb-1 -- bash -c  \
  'while true; do key=keydb-1-$(date +%s); keydb-cli set $key $key-val; keydb-cli get $key; done'

kubectl -n default exec -it keydb-2 -- bash -c \
 'while true; do key=keydb-2-$(date +%s); keydb-cli set $key $key-val; keydb-cli get $key; done'

监控Replication相关信息：

watch -- kubectl -n default exec -i keydb-1 -- keydb-cli info replication

watch -- kubectl -n default exec -i keydb-2 -- keydb-cli info replication

监控KeyDB日志： 

kubectl -n default logs  keydb-1 -f

kubectl -n default logs  keydb-2 -f

经过一段时间，keydb-1请求处理随机延缓的情况出现：

127.0.0.1:6379> set hello world
OK
(1.24s)
127.0.0.1:6379> set hello world
OK
(8.96s)
127.0.0.1:6379> get hello
"world"
(5.99s)
127.0.0.1:6379> get hello
"world"
(9.44s) 

此时keydb-2仍然正常运行，请求处理速度正常

获取keydb-1的慢查询，没有发现有价值的信息。而且延缓的时间没有计算在内：

127.0.0.1:6379> slowlog get 10                                         
1) 1) (integer) 7                                                      
   2) (integer) 1611833042                                             
   3) (integer) 14431               # 最慢的查询才耗时14ms                                            
   4) 1) "set"                                                         
      2) "keydb-1-1611833042"                                          
      3) "keydb-1-1611833042-val"                                      
   5) "127.0.0.1:38488"                                                
   6) ""                                                               
2) 1) (integer) 6                                                      
   2) (integer) 1611831322                                             
   3) (integer) 14486                                                  
   4) 1) "get"                                                         
      2) "keydb-1-1611831312"                                          
   5) "127.0.0.1:51680"                                                
   6) ""  

部署KeyDB已经设置

--loglevel debug

由于正在运行不间断执行SET/GET操作的脚本，因此日志量很大而刷屏，但是每隔一段时间就会出现卡顿。下面是keydb-1的日志片段：

7:11:S 28 Jan 2021 08:57:51.233 - Client closed connection
7:11:S 28 Jan 2021 08:57:51.251 - Accepted 127.0.0.1:44224
7:11:S 28 Jan 2021 08:57:51.252 - Client closed connection
7:12:S 28 Jan 2021 08:57:51.276 - Accepted 127.0.0.1:44226
7:11:S 28 Jan 2021 08:57:51.277 - Client closed connection
# 这一行日志之后，卡顿了10s。没有任何日志输出
7:11:S 28 Jan 2021 08:57:51.279 * Connecting to MASTER keydb-0.keydb:6379
7:11:S 28 Jan 2021 08:58:01.290 * Unable to connect to MASTER: Resource temporarily unavailable
7:11:S 28 Jan 2021 08:58:01.290 - Accepted 127.0.0.1:44228
7:11:S 28 Jan 2021 08:58:01.290 - Accepted 127.0.0.1:44264

从日志信息上可以看到，卡顿前keydb-1正在尝试连接到已经宕机的keydb-0，这个连接尝试被阻塞10秒后报

EAGAIN

阻塞期间SET/GET请求得不到处理，猜测原因包括：

1. 连接keydb-0的时候，占用了某种全局的锁，SET/GET请求也需要持有该锁
2. 连接keydb-0、处理SET/GET请求，由同一线程负责

第2种猜测应该不大可能，因为KeyDB宣称的优势之一就是，支持多线程处理请求。并且我们设置了参数

--server-threads 2

EAGAIN这个报错也没有参考价值，因为目前不卡顿的实例keydb-2输出的日志是一样的，只是没有任何卡顿：

7:11:S 28 Jan 2021 08:19:22.624 * Connecting to MASTER keydb-0.keydb:6379
# 仅仅耗时5ms即检测到连接失败
7:11:S 28 Jan 2021 08:19:22.629 * Unable to connect to MASTER: Resource temporarily unavailable

我们使用的KeyDB版本是5.3.3，尝试用关键字“Connecting to MASTER”搜索，发现只有一个匹配，位于

replicationCron

KeyDB启动时会调用

initServer

serverCron

下面看一下replicationCron的源码：

/* Replication cron function, called 1 time per second. */
void replicationCron(void) {
    static long long replication_cron_loops = 0;
    serverAssert(GlobalLocksAcquired());
    listIter liMaster;
    listNode *lnMaster;
    listRewind(g_pserver->masters, &liMaster);
    // 遍历当前实例的每一个Master
    while ((lnMaster = listNext(&liMaster)))
    {
        redisMaster *mi = (redisMaster*)listNodeValue(lnMaster);
        std::unique_lock<decltype(mi->master->lock)> ulock;
        // 获得              Master的 客户端的 锁
        if (mi->master != nullptr)
            ulock = decltype(ulock)(mi->master->lock);

        /* Non blocking connection timeout? */
        // 如果当前复制状态为：正在连接到Master
        // 或者复制状态处于握手阶段（包含多个状态）且超时了
        if (mi->masterhost &&
            (mi->repl_state == REPL_STATE_CONNECTING ||
            slaveIsInHandshakeState(mi)) &&
            (time(NULL)-mi->repl_transfer_lastio) > g_pserver->repl_timeout)
        {
            // 那么取消握手 —— 取消进行中的非阻塞连接尝试，或者取消进行中的RDB传输
            serverLog(LL_WARNING,"Timeout connecting to the MASTER...");
            cancelReplicationHandshake(mi);
        }

        /* Bulk transfer I/O timeout? */
        // 如果当前正在接收来自Master的RDB文件且超时了
        if (mi->masterhost && mi->repl_state == REPL_STATE_TRANSFER &&
            (time(NULL)-mi->repl_transfer_lastio) > g_pserver->repl_timeout)
        {
            serverLog(LL_WARNING,"Timeout receiving bulk data from MASTER... If the problem persists try to set the 'repl-timeout' parameter in keydb.conf to a larger value.");
            // 那么取消握手
            cancelReplicationHandshake(mi);
        }

        /* Timed out master when we are an already connected replica? */
        // 如果当前复制状态为：已连接。而且超时之前没有活动（正常情况下有心跳维持）
        if (mi->masterhost && mi->master && mi->repl_state == REPL_STATE_CONNECTED &&
            (time(NULL)-mi->master->lastinteraction) > g_pserver->repl_timeout)
        {
            // 那么释放掉客户端资源
            serverLog(LL_WARNING,"MASTER timeout: no data nor PING received...");
            if (FCorrectThread(mi->master))
                freeClient(mi->master);
            else
                freeClientAsync(mi->master);
        }

        /* Check if we should connect to a MASTER */
        // 上面几个分支都不会匹配我们的场景，因为keydb-0已经宕机，因此
        // 状态必然是REPL_STATE_CONNECT
        if (mi->repl_state == REPL_STATE_CONNECT) {
            // 这一行就是卡顿前的日志
            serverLog(LL_NOTICE,"Connecting to MASTER %s:%d",
                mi->masterhost, mi->masterport);
            // 发起连接
            if (connectWithMaster(mi) == C_OK) {
                serverLog(LL_NOTICE,"MASTER <-> REPLICA sync started");
            }
        }

        // 每秒钟发送心跳给Master
        if (mi->masterhost && mi->master &&
            !(mi->master->flags & CLIENT_PRE_PSYNC))
            replicationSendAck(mi);
    }

    // 后面处理和本实例的Slave有关的逻辑，例如发送心跳。和我们的场景无关，略...
}

很明显，卡顿是因为调用

connectWithMaster

进一步查看connectWithMaster的代码：

int connectWithMaster(redisMaster *mi) {
    int fd;

    fd = anetTcpNonBlockBestEffortBindConnect(NULL,
        mi->masterhost,mi->masterport,NET_FIRST_BIND_ADDR);
    if (fd == -1) {
        int sev = g_pserver->enable_multimaster ? LL_NOTICE : LL_WARNING;
        // 这一行是卡顿10s后的日志，因此阻塞发生在anetTcpNonBlockBestEffortBindConnect函数中
        serverLog(sev,"Unable to connect to MASTER: %s", strerror(errno));
        return C_ERR;
    }
    // ...
}

int anetTcpNonBlockBestEffortBindConnect(char *err, char *addr, int port,
                                         char *source_addr)
{
    return anetTcpGenericConnect(err,addr,port,source_addr,
            // 非阻塞 + BestEffort绑定
            ANET_CONNECT_NONBLOCK|ANET_CONNECT_BE_BINDING);
}


static int anetTcpGenericConnect(char *err, char *addr, int port,
                                 char *source_addr, int flags)
{
    int s = ANET_ERR, rv;
    char portstr[6];  /* strlen("65535") + 1; */
    struct addrinfo hints, *servinfo, *bservinfo, *p, *b;

    snprintf(portstr,sizeof(portstr),"%d",port);
    memset(&hints,0,sizeof(hints));
    // 不指定地址族，这会触发getaddrinfo同时进行A/AAAA查询
    hints.ai_family = AF_UNSPEC;
    hints.ai_socktype = SOCK_STREAM;

    // 根据Master的主机名查找得到IP地址信息（addrinfo）列表
    if ((rv = getaddrinfo(addr,portstr,&hints,&servinfo)) != 0) {
        anetSetError(err, "%s", gai_strerror(rv));
        return ANET_ERR;
    }
    // 遍历Master的IP地址列表
    for (p = servinfo; p != NULL; p = p->ai_next) {
        // 创建套接字，如果socket/connect调用失败，则尝试下一个
        if ((s = socket(p->ai_family,p->ai_socktype,p->ai_protocol)) == -1)
            continue;
        // 设置套接字选项SO_REUSEADDR
        if (anetSetReuseAddr(err,s) == ANET_ERR) 
            goto error;
        // 设置套接字选项 SO_REUSEPORT
        if (flags & ANET_CONNECT_REUSEPORT && anetSetReusePort(err, s) != ANET_OK)
            goto error;
        // 调用fcntl设置 O_NONBLOCK
        if (flags & ANET_CONNECT_NONBLOCK && anetNonBlock(err,s) != ANET_OK)
            goto error;
        if (source_addr) {
            int bound = 0;
            /* Using getaddrinfo saves us from self-determining IPv4 vs IPv6 */
            // 解析源地址
            if ((rv = getaddrinfo(source_addr, NULL, &hints, &bservinfo)) != 0)
            {
                anetSetError(err, "%s", gai_strerror(rv));
                goto error;
            }
            for (b = bservinfo; b != NULL; b = b->ai_next) {
                // 绑定到第一个源地址
                if (bind(s,b->ai_addr,b->ai_addrlen) != -1) {
                    bound = 1;
                    break;
                }
            }
            freeaddrinfo(bservinfo);
            if (!bound) {
                // 绑定源地址失败，跳转到Best Effort绑定
                anetSetError(err, "bind: %s", strerror(errno));
                goto error;
            }
        }
        // 发起连接
        if (connect(s,p->ai_addr,p->ai_addrlen) == -1) {
            // 我们的场景下套接字是非阻塞的，因此这里会立即返回EINPROGRESS，属于预期行为
            if (errno == EINPROGRESS && flags & ANET_CONNECT_NONBLOCK)
                goto end;
            // 其它错误均认为失败，尝试连接下一个Master地址
            close(s);
            s = ANET_ERR;
            continue;
        }

        goto end;
    }
    if (p == NULL)
        anetSetError(err, "creating socket: %s", strerror(errno));

error:
    if (s != ANET_ERR) {
        close(s);
        s = ANET_ERR;
    }

end:
    freeaddrinfo(servinfo);

    // 上面指定源地址，绑定失败时跳转到此处。尝试不指定源地址来连接
    if (s == ANET_ERR && source_addr && (flags & ANET_CONNECT_BE_BINDING)) {
        return anetTcpGenericConnect(err,addr,port,NULL,flags);
    } else {
        return s;
    }
}

尽管可以确定connectWithMaster调用的anetTcpGenericConnect就是发生阻塞的地方，但是从代码上看不出什么问题，就是简单的socket、bind，外加一个非阻塞的connect操作。

从现象上我们已经看到了，复制定时器卡顿的时候，请求处理也无法进行。通过代码分析，也明确了卡顿期间，复制定时器持有Master的客户端的锁。

那么，关于请求处理（线程？）会和复制定时器产生锁争用的猜测是否正确呢？

为了精确定位阻塞的代码，我们使用GDB进行单步跟踪：

#              需要特权模式，否则无法加载符号表
docker run -it --rm --name gdb --privileged --net=host --pid=host --entrypoint gdb docker.gmem.cc/debug

(gdb) attach 449
(gdb) break replication.cpp:3084
# 连续执行s，以step into anet.c
(gdb) s
# 连续执行n命令
(gdb) n
# 卡顿后，查看变量
# 解析的地址
(gdb) p addr
$2 = 0x7f2f31411281 "keydb-0.keydb"
# getaddrinfo的返回值
(gdb) p rv
$3 = -3

进入anetTcpGenericConnect后，逐行执行，多次测试，均在

anet.c

if ((rv = getaddrinfo(addr,portstr,&hints,&servinfo)) != 0) {
    anetSetError(err, "%s", gai_strerror(rv));
    return ANET_ERR;
}

也就是说，调用getaddrinfo函数耗时可能长达数秒。这是来自glibc的标准函数，用于将主机名解析为IP地址。

调试过程中发现此函数的返回值是-3，我们的场景中，需要解析的地址是keydb-0.keydb，卡顿时函数的返回值是-3，

man getaddrinfo

EAI_AGAIN  The name server returned a temporary failure indication. Try again later.

乍看起来，好像是DNS服务器，也就是K8S的CoreDNS存在问题。但无法解释此时keydb-2.keydb没有受到影响？

为了确认CoreDNS是否存在问题，我们分别在宿主机上、两个实例的网络命名空间中进行验证：

# nslookup keydb-0.keydb.default.svc.cluster.local 10.96.0.10
Server:		10.96.0.10
Address:	10.96.0.10#53

** server can't find keydb-0.keydb.default.svc.cluster.local: NXDOMAIN

# nslookup keydb-0.keydb.svc.cluster.local 10.96.0.10
Server:		10.96.0.10
Address:	10.96.0.10#53

** server can't find keydb-0.keydb.svc.cluster.local: NXDOMAIN

# nslookup keydb-0.keydb.cluster.local 10.96.0.10
Server:		10.96.0.10
Address:	10.96.0.10#53

** server can't find keydb-0.keydb.cluster.local: NXDOMAIN

# nslookup keydb-0.keydb 10.96.0.10
Server:		10.96.0.10
Address:	10.96.0.10#53

** server can't find keydb-0.keydb: SERVFAIL

反复测试循环测试，没有任何解析缓慢的现象。此外，查看CoreDNS的日志，我们也发现了来自keydb-1.keydb和keydb-2.keydb的查询请求，请求都是通过UDP协议发送的，处理耗时都是亚毫秒级别。

也就是说，从KeyDB实例所在宿主机/命名空间到CoreDNS的网络链路、CoreDNS服务器自身，都没有问题。

这就让人头疼了……难道问题出在getaddrinfo函数内部？或者在单步跟踪时判断错误，问题和DNS无关？为了确认，我们在CoreDNS上动了点手脚，强制将keydb-0.keydb解析到一个不存在的IP地址：

.:53 {
    # ...
    hosts {
        192.168.144.51  keydb-1.keydb
    }
    # ...
}

结果很快，卡顿的问题就消失了。所以，我们更加怀疑问题出在getaddrinfo函数上了。

查看文件/etc/lsb-release，可以看到KeyDB镜像是基于Ubuntu 18.04.4 LTS构建的，使用的libc6版本是2.27-3ubuntu1。

在launchpad.net找到了它的调试文件和源码。下载deb包，解压后复制到GDB容器，然后设置一下调试文件目录，就可以step into到glibc的代码进行跟踪了：

ar x libc6-dbg_2.27-3ubuntu1_amd64.deb
tar -xf data.tar.xz 

# 拷贝到我们正在运行GDB的容器
docker cp usr gdb:/root

# 修改调试文件搜索目录
(gdb) set debug-file-directory /root/usr/lib/debug
# 打断点，下面是缓慢的执行路径
(gdb) b anet.c:291
(gdb) b getaddrinfo.c:342
(gdb) b getaddrinfo.c:786  
# (gdb) print fct4
# $2 = (nss_gethostbyname4_r) 0x7f32f97e9a70 <_nss_dns_gethostbyname4_r>
(gdb) b dns-host.c:317
(gdb) b res_query.c:336
(gdb) b res_query.c:495                       # invoke __res_context_querydomain
(gdb) b res_query.c:601                       # invoke __res_context_query    
(gdb) b res_query.c:216                       # invoke __res_context_send
(gdb) b res_send.c:1066 if buflen==45         # send_dg

通过调试，我们发现getaddrinfo会依次对4个名字进行DNS查询：

keydb-0.keydb.default.svc.cluster.local.
keydb-0.keydb.svc.cluster.local.
keydb-0.keydb.cluster.local.
keydb-0.keydb.

CoreDNS的日志显示，所有请求都快速的处理完毕：

4242 "A IN keydb-0.keydb.default.svc.cluster.local. udp 68 false 512" NXDOMAIN qr,aa,rd 161 0.000215337s
38046 "AAAA IN keydb-0.keydb.default.svc.cluster.local. udp 68 false 512" NXDOMAIN qr,aa,rd 161 0.000203934s

23194 "A IN keydb-0.keydb.svc.cluster.local. udp 63 false 512" NXDOMAIN qr,aa,rd 156 0.000301011s
23722 "AAAA IN keydb-0.keydb.svc.cluster.local. udp 63 false 512" NXDOMAIN qr,aa,rd 156 0.000125386s

36552 "A IN keydb-0.keydb.cluster.local. udp 59 false 512" NXDOMAIN qr,aa,rd 152 0.000281247s
217 "AAAA IN keydb-0.keydb.cluster.local. udp 59 false 512" NXDOMAIN qr,aa,rd 152 0.000150689s

6776 "A IN keydb-0.keydb. udp 45 false 512" NOERROR - 0 0.000196686s
6776 "A IN keydb-0.keydb. udp 45 false 512" NOERROR - 0 0.000157011s 

最后一个名字，也就是传递给getaddrinfo的原始请求keydb-0.keydb.的处理过程有以下值得注意的点：

1. 从GDB角度来看，卡顿就是在解析该名字时出现
2. 从CoreDNS日志上看，没有AAAA请求。由于KeyDB指定了AF_UNSPEC，getaddrinfo会同时发送并等待A/AAAA应答。可能因为某种原因，该名字的AAAA解析过程没有完成，导致getaddrinfo一直等待到超时。作为对比，没有卡顿的keydb-2的A/AAAA查询处理过程都是正常的
3. 其它名字是一次A请求，一次AAAA请求。该名字却是两次A请求，而且，第一次A请求日志出现了数秒后，第二次日志才出现。有可能第二次是getaddrinfo没有收到应答而进行的重试
4. 前三个名字分别的错误码是NXDOMAIN，该名字的错误码却是NOERROR。通过nslookup/dig查询，错误码却是SERVFAIL，难道是CoreDNS日志有BUG？尽管如此，是否不同的错误码影响了getaddrinfo的行为

glibc的代码是优化过（也必须优化）的，GDB跟踪起来相当耗时，因此我们打算换一个角度来定位问题。基于上一节的分析，我们相信实例keydb-1.keydb在发送DNS请求的时候存在超时或丢包的情况，可以抓包来证实：

# 进入keydb-1.keydb的网络命名空间
nsenter -t 449 --net
# 抓包
tcpdump -i any -vv -nn udp port 53

抓包的结果如下： 

对 keydb-0.keydb.default.svc.cluster.local.  的A请求
172.29.1.69.42083 > 10.96.0.10.53: [bad udp cksum 0xb829 -> 0x95aa!] 22719+ A? keydb-0.keydb.default.svc.cluster.local. (68)
CoreDNS应答NXDomain
10.96.0.10.53 > 172.29.1.69.42083: [bad udp cksum 0xb886 -> 0x3f57!] 22719 NXDomain*- q: A? keydb-0.keydb.default.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (161)
对keydb-0.keydb.default.svc.cluster.local.  的AAAA请求，注意，仍然使用之前的UDP套接字
172.29.1.69.42083 > 10.96.0.10.53: [bad udp cksum 0xb829 -> 0x4d76!] 41176+ AAAA? keydb-0.keydb.default.svc.cluster.local. (68)
CoreDNS应答NXDomain
10.96.0.10.53 > 172.29.1.69.42083: [bad udp cksum 0xb886 -> 0xf722!] 41176 NXDomain*- q: AAAA? keydb-0.keydb.default.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (161)
对 keydb-0.keydb.svc.cluster.local. 的A请求，注意，这里使用了新的UDP套接字
172.29.1.69.45508 > 10.96.0.10.53: [bad udp cksum 0xb824 -> 0x3b5e!] 45156+ A? keydb-0.keydb.svc.cluster.local. (63)
CoreDNS应答NXDomain
10.96.0.10.53 > 172.29.1.69.45508: [bad udp cksum 0xb881 -> 0x21ce!] 45156 NXDomain*- q: A? keydb-0.keydb.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (156)
对keydb-0.keydb.svc.cluster.local. 的AAAA请求
172.29.1.69.45508 > 10.96.0.10.53: [bad udp cksum 0xb824 -> 0x8a4e!] 18036+ AAAA? keydb-0.keydb.svc.cluster.local. (63)
CoreDNS应答NXDomain
10.96.0.10.53 > 172.29.1.69.45508: [bad udp cksum 0xb881 -> 0x70be!] 18036 NXDomain*- q: AAAA? keydb-0.keydb.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (156)
对 keydb-0.keydb.cluster.local. 的A请求
172.29.1.69.48243 > 10.96.0.10.53: [bad udp cksum 0xb820 -> 0x5054!] 2718+ A? keydb-0.keydb.cluster.local. (59)
CoreDNS应答NXDomain
10.96.0.10.53 > 172.29.1.69.48243: [bad udp cksum 0xb87d -> 0x36c4!] 2718 NXDomain*- q: A? keydb-0.keydb.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (152)
对 keydb-0.keydb.cluster.local. 的AAAA请求
172.29.1.69.48243 > 10.96.0.10.53: [bad udp cksum 0xb820 -> 0x5147!] 61098+ AAAA? keydb-0.keydb.cluster.local. (59)
CoreDNS应答NXDomain，这里开始，我们保留时间戳那一行日志
14:42:15.028168 IP (tos 0x0, ttl 63, id 44636, offset 0, flags [DF], proto UDP (17), length 180)
10.96.0.10.53 > 172.29.1.69.48243: [bad udp cksum 0xb87d -> 0x37b7!] 61098 NXDomain*- q: AAAA? keydb-0.keydb.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local. 1612073759 7200 1800 86400 30 (152)
对keydb-0.keydb的A请求，这里还没有出现卡顿
14:42:15.028328 IP (tos 0x0, ttl 64, id 30583, offset 0, flags [DF], proto UDP (17), length 73)
172.29.1.69.47652 > 10.96.0.10.53: [bad udp cksum 0xb812 -> 0x181e!] 26682+ A? keydb-0.keydb. (45)
很快接收到CoreDNS的ServFail应答，抓包和我们nslookup/dig的错误码一致，CoreDNS日志显示的应该不正常
猜测“有可能第二次是getaddrinfo没有收到应答而进行的重试”被排除，至少说没收到应答不是网络层面的原因
14:42:15.028651 IP (tos 0x0, ttl 63, id 44637, offset 0, flags [DF], proto UDP (17), length 73)
10.96.0.10.53 > 172.29.1.69.47652: [bad udp cksum 0xb812 -> 0x981b!] 26682 ServFail- q: A? keydb-0.keydb. 0/0/0 (45)
再一次对keydb-0.keydb.的A请求，注意时间戳，刚好5秒之后，这是默认DNS请求超时。还是使用之前的套接字
14:42:20.029271 IP (tos 0x0, ttl 64, id 33006, offset 0, flags [DF], proto UDP (17), length 73)
172.29.1.69.47652 > 10.96.0.10.53: [bad udp cksum 0xb812 -> 0x181e!] 26682+ A? keydb-0.keydb. (45)
很快接收到CoreDNS的ServFail应答
14:42:20.029812 IP (tos 0x0, ttl 63, id 46397, offset 0, flags [DF], proto UDP (17), length 73)
10.96.0.10.53 > 172.29.1.69.47652: [bad udp cksum 0xb812 -> 0x981b!] 26682 ServFail- q: A? keydb-0.keydb. 0/0/0 (45)

通过上述分析我们可以相信，keydb-1.keydb容器到CoreDNS之间的DNS通信是没有问题的。但是，getaddrinfo似乎没有收到keydb-0.keydb的第一次应答，并且在超时（5s）之后进行重试

tcpdump和应用程序之间，还有个netfilter框架。回想起之前阅读过的文章：Kubernetes上和DNS相关的问题，conntrack相关的竞态条件可能导致DNS查询5秒超时。遗憾的是，这里的故障和此竞态条件无关：

1. 通过

   conntrack -S

   看到的

   insert_failed

   是0
2. 故障一旦出现，就每次都会超时5s，没有竞态条件的随机性
3. 如果是conntrack竞态条件导致，无法解释为什么前面3个名字解析正常，也无法解释为什么CoreDNS中配置一个静态解析故障就消失

在IPv4中，我们使用

gethostbyname

getaddrinfo

int getaddrinfo(const char* hostname,  // 主机名，可以使用IP地址或者DNS名称
                const char* service,   // 服务名，可以使用端口号或者/etc/services中的服务名
                const struct addrinfo* hints, // 可以NULL，或者一个addrinfo，提示调用者想得到的信息类型
                struct addrinfo** res);  // 解析得到的addrinfo，地址的链表

此函数返回的是套接字地址信息的链表，地址信息存储在下面的addrinfo结构中。参数

hints

struct addrinfo
{
  // 额外的提示标记
  int ai_flags;	
  // 提示需要查询哪些地址族，默认AF_UNSPEC，这意味着同时查询IPv4和IPv6地址
  // 也就是同时发起A/AAAA查询
  int ai_family;
  // 提示偏好的套接字类型，例如SOCK_STREAM|SOCK_DGRAM，默认可以返回任何套接字类型
  int ai_socktype;
  // 提示返回的套接字地址的协议类型
  int ai_protocol;

  // 套接字地址
  socklen_t ai_addrlen;
  struct sockaddr *ai_addr;
  // ...
  // 指向链表的下一条目
  struct addrinfo *ai_next;
};

很多软件调用getaddrinfo的时候，都会指定AF_UNSPEC（或者不提供hints，效果一样），例如KeyDB。但是，很多运行环境根本没有IPv6支持，这就凭白的给DNS服务器增加了负担。这也是在K8S中查看CoreDNS日志，总是会发现很多AAAA记录的原因。

KeyDB 5.3.3使用的glibc版本是2.27。函数getaddrinfo过于冗长，这里就不贴出来了，大概梳理一下：

1. 如果可能，它会通过/var/run/nscd/socket访问DNS缓存服务，我们没有这个服务
2. 初始化NSS的hosts数据库，如果没有在文件中配置，则默认使用

   hosts: dns [!UNAVAIL=return] files

   ，我们的环境下配置是

   hosts: files dns

3. 通过NSS进行名字查询，实际上是调用

   gethostbyname4_r

   函数：
   1. 查找files源，调用

      _nss_files_gethostbyname4_r

      函数，也就是打开/etc/hosts查找。K8S容器中，/etc/hosts中仅仅存在当前Pod的条目，因此files源不会匹配
   2. 查找dns源，调用

      _nss_dns_gethostbyname4_r

      函数：
      1. 读取/etc/resolv.conf构建

         resolv_context

         。我们的环境下，配置文件内容为：
         

         nameserver 10.96.0.10
         search default.svc.cluster.local svc.cluster.local cluster.local
         options ndots:5

      2. 调用

         __res_context_search

         ， 执行DNS查找逻辑。它会将上面的search domain作为域名后缀，产生多个名字，逐个尝试。每个名字查询失败时都会重试，重试时尽可能选择不同的DNS服务器。可能同时发起A/AAA查询

__res_context_search()首先会计算一下，待查找名字中的dot的数量。如果名字以dot结尾，或者dot数量大于等于ndots，则直接调用

__res_context_querydomain

否则，它会根据/etc/resolv.conf中的search domain列表，给待查找的名字加后缀，然后多次向DNS服务器发请求。我们的环境下，待查找名字为keydb-0.keydb，getaddrinfo函数会依次尝试：

keydb-0.keydb.default.svc.cluster.local. 
keydb-0.keydb.svc.cluster.local. 
keydb-0.keydb.cluster.local.
keydb-0.keydb.

需要注意：

1. 向DNS服务器发请求，仍然是由__res_context_querydomain()负责
2. 一旦查找成功，就立即返回不再尝试其它search domain
3. 不加修饰的原始名字，会放在最后尝试

在K8S中，*.cluster.local一般都由CoreDNS自身负责，处理速度会很快。至于keydb-0.keydb.的处理速度，如果为CoreDNS配置了上游DNS，则处理速度依赖于外部环境。

__res_context_querydomain仅仅是在domain参数不为空的时候，将name和domain连接起来，然后调用

__res_context_query

__res_context_query负责和DNS服务器的交互，完成单个名字的DNS查询。它会调用

__res_context_mkquery

发送DNS请求的代码在

__res_context_send

//                  重试次数，statp->retry为2
for (try = 0; try < statp->retry; try++) {
    // 如果有多个DNS服务器，重试时会轮询它们
    for (unsigned ns_shift = 0; ns_shift < statp->nscount; ns_shift++)
    {
    unsigned int ns = ns_shift + ns_offset;
    if (ns >= statp->nscount)
        ns -= statp->nscount;

    same_ns:
    if (__glibc_unlikely (v_circuit)) {
        // ...
    } else {
        // 使用UDP方式发送请求
        n = send_dg(statp, buf, buflen, buf2, buflen2,
                &ans, &anssiz, &terrno,
                ns, &v_circuit, &gotsomewhere, ansp,
                ansp2, nansp2, resplen2, ansp2_malloced);
        if (n < 0)
            return (-1);
        if (n == 0 && (buf2 == NULL || *resplen2 == 0))
            // 如果有多个DNS服务器的时候，会尝试下一个
            goto next_ns;
        // ...
    }
    return (resplen);
next_ns: ;
   } /*foreach ns*/
} /*foreach retry*/

通常情况下，都是通过UDP协议进行DNS查询的，因此会调用

send_dg

__res_iclose(statp, false);
if (!v_circuit) {
    if (!gotsomewhere)
        __set_errno (ECONNREFUSED);	/* no nameservers found */
    else
        __set_errno (ETIMEDOUT);	/* no answer obtained */
} else
    __set_errno (terrno);
return (-1);

而它的调用者__res_context_query则在返回值是-1的时候，设置错误码TRY_AGAIN，这就是我们从KeyDB日志上看到报错The name server returned a temporary failure indication的原因：

if (n < 0) {
    RES_SET_H_ERRNO(statp, TRY_AGAIN);
    return (n);
}

缓慢的根源是send_dg函数，它阻塞了5秒。该函数的原型如下：

// 如果没有错误，返回第一个应答的字节数
// 对于可恢复错误，返回0；对于不可恢复错误，返回负数
static int send_dg(
    // 各种选项、DNS服务器列表、指向DNS服务器的套接字（文件描述符）
    res_state statp,
    // 查询请求1的缓冲区 和 长度
	const u_char *buf, int buflen, 
    // 查询请求2的缓冲区 和 长度
    const u_char *buf2, int buflen2,
    // 收到的第1个应答   和 最大长度
	u_char **ansp,      int *anssizp,
    // 出现错误时，将errno设置到此字段
	int *terrno, 
    // 使用的DNS服务器的序号
    int ns, 
    // 如果由于UDP数据报的限制而导致截断，则v_circuit设置为1，提示调用者使用TCP方式重试
    int *v_circuit, 
    // 提示访问DNS服务器时，是拒绝服务还是超时。如果是超时则设置为1
    int *gotsomewhere,
    // 提示遇到超长应答的时候，是否重新分配缓冲区
    u_char **anscp,
    // 收到的第2个应答 和 最大长度
	u_char **ansp2, int *anssizp2, 
    // 第2个应答的实际长度 是否为第2个应答重新分配了缓冲区
    int *resplen2, int *ansp2_malloced);

该函数会向指定序号的DNS服务器发送DNS查询。它同时支持IPv4/IPv6查询，你可以传递两个查询请求，分别放在buf和buf2参数中。如果提供了两个查询请求，默认使用并行方式发送查询。设置选项

RES_SINGLKUP

RES_SNGLKUPREOP

由于请求可以并行发送，因此应答到达的顺序是不确定的。先收到的应答会存放在ansp中，入参最大长度anssizp。入参anscp用于提示，应答过长的时候的处理方式：

1. 如果anscp不为空：则自动分配新的缓冲区，并且ansp、anscp都被修改为指向该缓冲区
2. 如果anscp为空：则过长的部分被截断，DNS包头的TC字段被设置为1

glibc的2.27-3ubuntu1版本中send_dg的完整实现如下：

static int
send_dg(res_state statp,
	const u_char *buf, int buflen, const u_char *buf2, int buflen2,
	u_char **ansp, int *anssizp,
	int *terrno, int ns, int *v_circuit, int *gotsomewhere, u_char **anscp,
	u_char **ansp2, int *anssizp2, int *resplen2, int *ansp2_malloced)
{
	const HEADER *hp = (HEADER *) buf;
	const HEADER *hp2 = (HEADER *) buf2;
	struct timespec now, timeout, finish;
	struct pollfd pfd[1];
	int ptimeout;
	struct sockaddr_in6 from;
	int resplen = 0;
	int n;

	/*
	 * Compute time for the total operation.
	 */
	int seconds = (statp->retrans << ns); // 0. 计算超时
	if (ns > 0)
		seconds /= statp->nscount;
	if (seconds <= 0)
		seconds = 1;
	bool single_request_reopen = (statp->options & RES_SNGLKUPREOP) != 0; // 0. 确定是否并行请求
	bool single_request = (((statp->options & RES_SNGLKUP) != 0)
			       | single_request_reopen);
	int save_gotsomewhere = *gotsomewhere;

	int retval;
 retry_reopen: // tx1. 如果套接字没有创建，则创建， SOCK_DGRAM | SOCK_NONBLOCK | SOCK_CLOEXEC，非阻塞
	retval = reopen (statp, terrno, ns); // tx1. 然后调用一下connect操作，不发数据
	if (retval <= 0)
	  {
	    if (resplen2 != NULL)
	      *resplen2 = 0;
	    return retval;
	  }
 retry:
	evNowTime(&now);
	evConsTime(&timeout, seconds, 0);
	evAddTime(&finish, &now, &timeout);
	int need_recompute = 0;
	int nwritten = 0;
	int recvresp1 = 0;  // 用于标记请求1的应答是否接收到
	/* Skip the second response if there is no second query.
	   To do that we mark the second response as received.  */
	int recvresp2 = buf2 == NULL; // 用于标记请求2的应答是否接收到，如果buf2为空则立即标记为1
	pfd[0].fd = EXT(statp).nssocks[ns];
	pfd[0].events = POLLOUT; // tx2. 准备监听可写事件
 wait:
	if (need_recompute) {
	recompute_resend:
		evNowTime(&now);
		if (evCmpTime(finish, now) <= 0) {
		poll_err_out:
			return close_and_return_error (statp, resplen2);
		}
		evSubTime(&timeout, &finish, &now);
		need_recompute = 0;
	}
	/* Convert struct timespec in milliseconds.  */
	ptimeout = timeout.tv_sec * 1000 + timeout.tv_nsec / 1000000;

	n = 0;
	if (nwritten == 0)
	  n = __poll (pfd, 1, 0); // tx2. 等待套接字可写
	if (__glibc_unlikely (n == 0))       {
		n = __poll (pfd, 1, ptimeout); // rx1. 等待套接字可读，5秒超时
		need_recompute = 1;
	}
	if (n == 0) {
		if (resplen > 1 && (recvresp1 || (buf2 != NULL && recvresp2)))
		  { // 处理某些DNS服务器不支持处理并行请求的场景
		    /* There are quite a few broken name servers out
		       there which don't handle two outstanding
		       requests from the same source.  There are also
		       broken firewall settings.  If we time out after
		       having received one answer switch to the mode
		       where we send the second request only once we
		       have received the first answer.  */
		    if (!single_request)
		      {
			statp->options |= RES_SNGLKUP; // 这里永久改变为串行发送请求。statp是线程本地变量，
			single_request = true;         // KeyDB复制定时任务总是在同一线程中运行
			*gotsomewhere = save_gotsomewhere;
			goto retry;
		      }
		    else if (!single_request_reopen)
		      {
			statp->options |= RES_SNGLKUPREOP;
			single_request_reopen = true;
			*gotsomewhere = save_gotsomewhere;
			__res_iclose (statp, false);
			goto retry_reopen;
		      }

		    *resplen2 = 1;
		    return resplen;
		  }

		*gotsomewhere = 1;
		if (resplen2 != NULL)
		  *resplen2 = 0;
		return 0;
	}
	if (n < 0) {
		if (errno == EINTR)
			goto recompute_resend;

		goto poll_err_out;
	}
	__set_errno (0);
	if (pfd[0].revents & POLLOUT) { // tx3. 监听到可写事件
#ifndef __ASSUME_SENDMMSG
		static int have_sendmmsg;
#else
# define have_sendmmsg 1
#endif
		if (have_sendmmsg >= 0 && nwritten == 0 && buf2 != NULL // 查询请求2不为空
		    && !single_request) // 且允许并行发送
		  {
		    struct iovec iov[2];
		    struct mmsghdr reqs[2];
		    reqs[0].msg_hdr.msg_name = NULL;
		    reqs[0].msg_hdr.msg_namelen = 0;
		    reqs[0].msg_hdr.msg_iov = &iov[0];
		    reqs[0].msg_hdr.msg_iovlen = 1;
		    iov[0].iov_base = (void *) buf;
		    iov[0].iov_len = buflen;
		    reqs[0].msg_hdr.msg_control = NULL;
		    reqs[0].msg_hdr.msg_controllen = 0;

		    reqs[1].msg_hdr.msg_name = NULL;
		    reqs[1].msg_hdr.msg_namelen = 0;
		    reqs[1].msg_hdr.msg_iov = &iov[1];
		    reqs[1].msg_hdr.msg_iovlen = 1;
		    iov[1].iov_base = (void *) buf2;
		    iov[1].iov_len = buflen2;
		    reqs[1].msg_hdr.msg_control = NULL;
		    reqs[1].msg_hdr.msg_controllen = 0;
            // 发送消息，注意这里同时发送2个查询请求，返回值是实际发送的数量
		    int ndg = __sendmmsg (pfd[0].fd, reqs, 2, MSG_NOSIGNAL);
		    if (__glibc_likely (ndg == 2))
		      {
			if (reqs[0].msg_len != buflen
			    || reqs[1].msg_len != buflen2)
			  goto fail_sendmmsg;

			pfd[0].events = POLLIN;
			nwritten += 2;
		      }
		    else if (ndg == 1 && reqs[0].msg_len == buflen)
		      goto just_one;
		    else if (ndg < 0 && (errno == EINTR || errno == EAGAIN))
		      goto recompute_resend;
		    else
		      {
#ifndef __ASSUME_SENDMMSG
			if (__glibc_unlikely (have_sendmmsg == 0))
			  {
			    if (ndg < 0 && errno == ENOSYS)
			      {
				have_sendmmsg = -1;
				goto try_send;
			      }
			    have_sendmmsg = 1;
			  }
#endif

		      fail_sendmmsg:
			return close_and_return_error (statp, resplen2);
		      }
		  }
		else
		  { // 不支持并行发送
		    ssize_t sr;
#ifndef __ASSUME_SENDMMSG
		  try_send:
#endif
		    if (nwritten != 0)
		      sr = send (pfd[0].fd, buf2, buflen2, MSG_NOSIGNAL);
		    else
		      sr = send (pfd[0].fd, buf, buflen, MSG_NOSIGNAL); // tx4. 发送查询请求1

		    if (sr != (nwritten != 0 ? buflen2 : buflen)) { // 发送长度和缓冲区长度不匹配
		      if (errno == EINTR || errno == EAGAIN) // 如果原因是EINTR或EAGAIN，则尝试重发
			goto recompute_resend;
		      return close_and_return_error (statp, resplen2);
		    }
		  just_one:
		    if (nwritten != 0 || buf2 == NULL || single_request)
		      pfd[0].events = POLLIN;  // 串行模式下，后续只需监听可读时间
		    else
		      pfd[0].events = POLLIN | POLLOUT; // 并行发送，如果实际仅发送1个消息，跳转到这里。后续需要继续写入发送失败的那个消息
		    ++nwritten;
		  }
		goto wait; // tx4. 发送完毕，回到上面的wait分支等待应答
	} else if (pfd[0].revents & POLLIN) { // rx2. 监听到套接字可读
		int *thisanssizp; // 本次读数据到哪个缓冲
		u_char **thisansp;
		int *thisresplenp;

		if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {
			/* We have not received any responses
			   yet or we only have one response to
			   receive.  */
			thisanssizp = anssizp;
			thisansp = anscp ?: ansp;
			assert (anscp != NULL || ansp2 == NULL);
			thisresplenp = &resplen;
		} else {
			thisanssizp = anssizp2;
			thisansp = ansp2;
			thisresplenp = resplen2;
		}

		if (*thisanssizp < MAXPACKET
		    /* If the current buffer is not the the static
		       user-supplied buffer then we can reallocate
		       it.  */
		    && (thisansp != NULL && thisansp != ansp)
#ifdef FIONREAD
		    /* Is the size too small?  */
		    && (ioctl (pfd[0].fd, FIONREAD, thisresplenp) < 0
			|| *thisanssizp < *thisresplenp)
#endif
                    ) {
			/* Always allocate MAXPACKET, callers expect
			   this specific size.  */
			u_char *newp = malloc (MAXPACKET);
			if (newp != NULL) {
				*thisanssizp = MAXPACKET;
				*thisansp = newp;
				if (thisansp == ansp2)
				  *ansp2_malloced = 1;
			}
		}
		/* We could end up with truncation if anscp was NULL
		   (not allowed to change caller's buffer) and the
		   response buffer size is too small.  This isn't a
		   reliable way to detect truncation because the ioctl
		   may be an inaccurate report of the UDP message size.
		   Therefore we use this only to issue debug output.
		   To do truncation accurately with UDP we need
		   MSG_TRUNC which is only available on Linux.  We
		   can abstract out the Linux-specific feature in the
		   future to detect truncation.  */
		HEADER *anhp = (HEADER *) *thisansp;
		socklen_t fromlen = sizeof(struct sockaddr_in6);
		assert (sizeof(from) <= fromlen);
		*thisresplenp = recvfrom(pfd[0].fd, (char*)*thisansp, // rx3. 读取应答
					 *thisanssizp, 0,
					(struct sockaddr *)&from, &fromlen);
		if (__glibc_unlikely (*thisresplenp <= 0))       {
			if (errno == EINTR || errno == EAGAIN) {
				need_recompute = 1;
				goto wait;  // 如果EINTR|EAGAIN则重新等待
			}
			return close_and_return_error (statp, resplen2);
		}
		*gotsomewhere = 1;
		if (__glibc_unlikely (*thisresplenp < HFIXEDSZ))       { // 消息比报文头长度还小，错误
			/*
			 * Undersized message.
			 */
			*terrno = EMSGSIZE;
			return close_and_return_error (statp, resplen2);
		}
		if ((recvresp1 || hp->id != anhp->id)
		    && (recvresp2 || hp2->id != anhp->id)) { // 查询标识符不匹配，可能服务器缓慢，返回之前查询的应答
			/*
			 * response from old query, ignore it.
			 * XXX - potential security hazard could
			 *	 be detected here.
			 */
			goto wait;
		}
		if (!(statp->options & RES_INSECURE1) && // 安全性检查type1
		    !res_ourserver_p(statp, &from)) {
			/*
			 * response from wrong server? ignore it.
			 * XXX - potential security hazard could
			 *	 be detected here.
			 */
			goto wait;
		}
		if (!(statp->options & RES_INSECURE2) // 安全性检查type2
		    && (recvresp1 || !res_queriesmatch(buf, buf + buflen,
						       *thisansp,
						       *thisansp
						       + *thisanssizp))
		    && (recvresp2 || !res_queriesmatch(buf2, buf2 + buflen2,
						       *thisansp,
						       *thisansp
						       + *thisanssizp))) {
			/*
			 * response contains wrong query? ignore it.
			 * XXX - potential security hazard could
			 *	 be detected here.
			 */
			goto wait;
		}
		if (anhp->rcode == SERVFAIL ||
		    anhp->rcode == NOTIMP ||
		    anhp->rcode == REFUSED) {  //  rx4. 处理服务器不愿意处理请求的情况
		next_ns:
			if (recvresp1 || (buf2 != NULL && recvresp2)) {
			  *resplen2 = 0;
			  return resplen;
			}
			if (buf2 != NULL)
			  {
			    /* No data from the first reply.  */
			    resplen = 0;
			    /* We are waiting for a possible second reply.  */
			    if (hp->id == anhp->id)
			      recvresp1 = 1;
			    else
			      recvresp2 = 1;

			    goto wait;  // 事件类型仍然是POLLIN，会导致超时
			  }

			/* don't retry if called from dig */
			if (!statp->pfcode)
			  return close_and_return_error (statp, resplen2);
			__res_iclose(statp, false);
		}
		if (anhp->rcode == NOERROR && anhp->ancount == 0 // rx.4 处理nodata的情况，名字请求，请求的记录类型不存在
		    && anhp->aa == 0 && anhp->ra == 0 && anhp->arcount == 0) {
			goto next_ns;
		}
		if (!(statp->options & RES_IGNTC) && anhp->tc) { // rx.4 处理应答截断的情况
			/*
			 * To get the rest of answer,
			 * use TCP with same server.
			 */
			*v_circuit = 1; // 提示使用TCP重发请求
			__res_iclose(statp, false);
			// XXX if we have received one reply we could
			// XXX use it and not repeat it over TCP...
			if (resplen2 != NULL)
			  *resplen2 = 0;
			return (1);
		}
		/* Mark which reply we received.  */
		if (recvresp1 == 0 && hp->id == anhp->id)
			recvresp1 = 1;
		else
			recvresp2 = 1;
		/* Repeat waiting if we have a second answer to arrive.  */
		if ((recvresp1 & recvresp2) == 0) { // 如果只有一个查询请求，recvresp2一开始就标记为1，因此不会走到这个分支
			if (single_request) { // 如果是串行模式，这里开始处理第2个请求
				pfd[0].events = POLLOUT;
				if (single_request_reopen) {  // 如果需要关闭并重新打开套接字
					__res_iclose (statp, false);
					retval = reopen (statp, terrno, ns);
					if (retval <= 0)
					  {
					    if (resplen2 != NULL)
					      *resplen2 = 0;
					    return retval;
					  }
					pfd[0].fd = EXT(statp).nssocks[ns];
				}
			}
			goto wait;  // 事件类型已经改为POLLOUT，因此不会发生超时
		}
		/* All is well.  We have received both responses (if
		   two responses were requested).  */
		return (resplen); // rx.5 DNS查询完毕
	} else if (pfd[0].revents & (POLLERR | POLLHUP | POLLNVAL)) // poll出现错误
	  /* Something went wrong.  We can stop trying.  */
	  return close_and_return_error (statp, resplen2);
	else {
		/* poll should not have returned > 0 in this case.  */
		abort ();
	}
}

注释中tx.标注了DNS查询请求发送的基本过程，rx.则标注了DNS查询应答接收的基本过程。调试查询keydb-0.keydb时该函数的行为，发现以下事实：

1. 查询时串行发送的，而不是并行。因此正常流程应该是发送A查询，接收A应答，发送AAAA查询，接收AAAA应答
2. 仅执行了1225行，没有执行1223行。也就是说仅仅发送了A查询，没有发送AAA查询
3. 走到了1241行的分支，也就是说，A请求的应答报文是接收到的：
   

   // (gdb) i r eax
   // eax            0x2d     45   A应答长度45
   		*thisresplenp = recvfrom(pfd[0].fd, (char*)*thisansp,
   					 *thisanssizp, 0,
   					(struct sockaddr *)&from, &fromlen);

   由于接收到的应答是servfail，因此走到这个分支：

   if (anhp->rcode == SERVFAIL ||
   		    anhp->rcode == NOTIMP ||
   		    anhp->rcode == REFUSED) {
   		next_ns:
   			if (recvresp1 || (buf2 != NULL && recvresp2)) {
   			  *resplen2 = 0;
   			  return resplen;
   			}
   			if (buf2 != NULL)
   			  {
   			    /* No data from the first reply.  */
   			    resplen = 0;
   			    /* We are waiting for a possible second reply.  */
   			    if (hp->id == anhp->id)
   			      recvresp1 = 1;  // 接收到第一个应答
   			    else
   			      recvresp2 = 1;
                   // 由于同时需要进行A和AAAA查询，这里仅仅接收到A应答（串行发送）
   			    goto wait; // 因此需要跳转到这里，等待套接字可写，以发送AAAA请求
   			  }

4. CoreDNS应答A查询SERVFAIL，重新跳转到wait标签：

   if (need_recompute) { // 等待A应答的时候，设置了超时 need_recompute，因此再次wait执行这个分支
   	recompute_resend:
   		evNowTime(&now);
   		if (evCmpTime(finish, now) <= 0) {
   		poll_err_out: // 如果超时了，直接关闭套接字并返回错误
   			return close_and_return_error (statp, resplen2);
   		}
   		evSubTime(&timeout, &finish, &now);
   		need_recompute = 0;
   	}
   	/* Convert struct timespec in milliseconds.  */
   	ptimeout = timeout.tv_sec * 1000 + timeout.tv_nsec / 1000000;
   
   	n = 0;
   	if (nwritten == 0)
   	  n = __poll (pfd, 1, 0);  // 发送A请求的时候在这里pull，等待套接字可写。timeout 0表示立即返回
   	if (__glibc_unlikely (n == 0))       {
   		n = __poll (pfd, 1, ptimeout);  // 接收A应答的时候在这里poll，等待套接字可读
   		need_recompute = 1; // 发送AAAA请求时，在这里等待套接字可写
   	}

5.  这时，由于nwritten已经被设置为1，因此走带有timeout的poll分支。然后在1110行出现5秒超时，并因为poll返回值是0而导致send_dg函数退出。在一次A请求处理过程中，有两次在1110行poll：

   1. 第一次是尝试A请求的应答，poll前的pollfd是{fd = 87, events = 1, revents = 4}，之后是{fd = 87, events = 1, revents = 1}
   2. 第二次就是因为这个跳转，poll前的pollfd是{fd = 87, events = 1, revents = 1}，超时之后是{fd = 87, events = 1, revents = 0}

poll函数原型：

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

struct pollfd {
    // 打开文件的描述符
    int   fd;         
    // 输入参数，应用程序感兴趣的事件类型。如果置零则revents中仅能返回POLLHUP,POLLERR,POLLNVAL事件
    short events;
    // 输出参数，内核填充实际发生的事件
    short revents;    
};

如果文件描述符集中没有任何一个发生了events中指定的事件，则该函数会阻塞，直到超时或者被信号处理器中断。

事件类型1表示POLLIN，即有数据可读；事件类型4表示POLLOUT，即文件描述符可写。正常情况下该函数返回就绪的（revents非零）文件描述符数量，超时返回0，出现错误则返回-1

第2次在1110行的poll行为难以理解：

1. A的应答已经接收到，而由于进行的是串行发送A/AAAA，此时尚未发送AAAA请求，因此可以预期后续不会有可读事件
2. poll时events设置为POLLIN（肯定会导致超时），难道不是应该设置为POLLOUT，尝试发送AAAA请求或重试A请求么？

为了进行对照，我们由调试了没有发生缓慢问题的keydb-2.keydb。它在第2次执行1110行的poll时没有超时，pollfd的状态是{fd = 88, events = 1, revents = 1}。连续两次poll到可读事件，这提示进行了并行A/AAAA查询。检查变量single_request_reopen、single_request果然都是false，从CoreDNS日志上也可以看到A/AAAA

可能的情况是，keydb-1.keydb最初是并行发送A/AAAA查询的，后来由于某种原因，改为串行发送，从而导致出现5秒超时相关的缓慢现象。根源应该还是在glibc中，因为KeyDB调用getaddrinfo的方式是固定的。

回顾一下send_dg的代码，可以发现

statp->options

resolv_context

改变为串行方式后，由于CoreDNS应答keydb-0.keydb.以SERVFAIL，导致跳转到wait标签（1363行），进而执行了一次必然超时的poll调用。CoreDNS应答其它（加了search domain后缀的）域名以NXDOMAIN，则不会导致超时的poll调用，因为会在1396行修改事件类型为POLLOUT。

触发本文中的glibc缺陷，需要满足以下条件：

1. 出现某个KeyDB节点宕机的情况，并且没有修复。这会导致复制定时任务反复执行DNS查询，从而可能触发缺陷
2. 某个DNS查询的应答UDP包丢失，导致当前线程串行发送DNS请求。由于UDP本身的不可靠性，随着程序不断运行，最终会发生
3. DNS服务器返回SERVFAIL、NOTIMP或者REFUSED应答

第1、2个条件都是随机性的，我们没法干预，只有从第3个条件入手。作为最快速的解决方案，只需要配置KeyDB，使用全限定域名来指定replicaof即可。

The post 记录一次KeyDB缓慢的定位过程 appeared first on 绿色记忆.

KeyDB是Redis的替代品，宣称是世界上最快的NoSQL数据库，比Redis快5倍。KeyDB完全遵循Redis的协议，可以无缝的从Redis切换。

KeyDB支持多主复制、跨Region的水平扩容，支持垂直扩容。

KeyDB支持多个保持同步的主节点，这些主节点都可以接受读、写请求。主节点可以括Region分布。不需要哨兵节点进行监控。

KeyDB通过MVCC实现无锁（不需等待）的并发操作、后台保存。

得益于KeyDB的MVCC支持：

1. 事务、查询是非阻塞（不会有锁）的，同时具有原子性保证
2. 未来将支持事务回滚

KeyDB是完全的多线程的，不像Redis那样仅仅在I/O上支持并发，这意味着它可以充分利用多核心。

这个特性让KeyDB的吞吐量比Redis 5大5倍，Redis 6大3倍。再启用TLS的情况下，吞吐量可以比Redis大7倍。

多线程特性让KeyDB能最大化利用单机能力，这意味着通过配置能实现水平扩容。

单个KeyDB能够充分利用10（不使用TLS）-16（使用TLS）核心。

支持将一个set中的所有键一起过期，过期时的删除操作是接近实时完成的，不会有延迟。

可以很好的在ARM体系结构下运行。

sudo curl -s --compressed -o /etc/apt/trusted.gpg.d/keydb.gpg https://download.keydb.dev/keydb-ppa/keydb.gpg
sudo curl -s --compressed -o /etc/apt/sources.list.d/keydb.list https://download.keydb.dev/keydb-ppa/keydb.list
sudo apt update
sudo apt install keydb

wget https://download.keydb.dev/packages/deb/ubuntu16.04_xenial/amd64/keydb-latest/keydb-tools_6.0.16-1~xenial1_amd64.deb
sudo dpkg -i keydb-tools_6.0.16-1~xenial1_amd64.deb 

要启用Active Replica模式，遵循如下步骤：

1. 两个服务器A/B都需要配置

   active-replica yes

2. 在B上执行命令

   replicaof [A address] [A port]

   ，丢弃自己的数据，加载A的数据
3. 在A上执行命令

   replicaof [B address] [B port]

   ，丢弃自己的数据，加载B的数据
4. 现在两个服务器会传播自己的写操作到对方

或者完全通过配置文件：

# 节点A的配置
port 6379
# 当前节点的密码
requirepass mypassword123
# 连接到Master的密码
masterauth mypassword123
# 增加下面的
active-replica yes
# 从Redis 5.0开始，slaveof改成replicaof
replicaof 10.0.0.3 6379


# 节点B的配置
port 6379
requirepass mypassword123
masterauth mypassword123
# 增加下面的
active-replica yes
replicaof 10.0.0.2 6379

在每个节点上增加多个replicaof配置项：

# 一共有3个节点 A/B/C 10.0.0.2/3/4

# 节点A
multi-master yes
active-replica yes
replicaof 10.0.0.3 6379
replicaof 10.0.0.4 6379

# 节点B
multi-master yes
active-replica yes
replicaof 10.0.0.2 6379
replicaof 10.0.0.4 6379

# 节点C
multi-master yes
active-replica yes
replicaof 10.0.0.2 6379
replicaof 10.0.0.3 6379

创建配置文件，参考：

port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

dir ./
loglevel notice
logfile keydb.log

save 900 1
save 300 10
save 60 10000

启动实例，参考：

keydb-server keydb.conf

所有实例启动后，使用如下命令创建集群：

keydb-cli --cluster create 10.0.0.1:6379   10.0.0.2:6379 ... --cluster-replicas 1

后续可以使用如下命令添加新的节点：

# 作为新的Master加入
#                            新节点           通过谁连接到既有集群
keydb-cli --cluster add-node 10.0.0.11:6379  10.0.0.1:6379

# 自动作为副本少的Master的Slave
keydb-cli --cluster add-node 10.0.0.11:6379 10.0.0.1:6379 --cluster-slave

# 强制指定Master
keydb-cli --cluster add-node 10.0.0.11:6379 10.0.0.1:6379 --cluster-slave --cluster-master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 

通过如下命令可以进行再分片： 

keydb-cli reshard 10.0.0.11:6379 --cluster-from <node-id> --cluster-to <node-id> \
  --cluster-slots <number of slots> --cluster-yes

大部分配置项和Redis是相通的，参考Redis学习笔记。这里仅仅列出Redis新版本增加 / KeyDB特有的配置项。

通过复制（Replication），一个KeyDB节点可以保证自己的数据集和和Master(s)实例一致：

1. 当Slave和Master之间的连接良好时，Master通过发送写、键过期、键驱除等操作的数据流给Slave来保证Slave的数据和自己一致
2. 当网络断开后，Slave会尝试重新连接到Master，并进行增量同步
3. 如果增量同步无法实现（落后太远），Slave会请求进行全量同步。Master会创建它的数据集的快照，发送给Slave，然后继续发送增量的数据流

关于KeyDB的复制机制，你需要知道以下事实：

1. KeyDB默认使用异步的同步方式，这种方式的优势时延迟低、性能高。Slave会在接收了一定量的复制数据之后，向Master发送Ack。类似于Redis，使用WAIT命令可以确保特定的数据被多个Slave所Ack。WAIT命令并不能保证CAP中的CP —— 已经Ack的写操作，仍然可能在故障转移时丢失，尽管几率很小
2. 每个Master可以对应多个Slaves
3. Slave可以有自己的Slaves，参与复制的KeyDB节点可以形成树状拓扑
4. 在Master侧，复制是非阻塞的。不管是增量/全量同步，都不影响Master继续处理查询
5. 在Slave侧，复制很大程度上也是非阻塞的：
   1. 通过配置，KeyDB可以在接收初始同步时使用旧数据集提供服务。你也可以配置，当复制流宕掉的情况下，让Slave返回错误给客户端
   2. 在初始同步完毕后，有个阻塞的时间窗口，在此窗口中Slave替换旧的数据集
   3. 从4.0开始，可以配置KeyDB让删除数据集的操作在其它线程执行。但是，加载新数据集的操作仍然在主线程执行，会阻塞Slave
6. 通过复制，可以：
   1. 提升可扩容性：将缓慢的O(N)操作offload给Slave
   2. 提升数据安全性、高可用性
7. 使用复制，可以免于Master需要将数据集写入到磁盘的开销。这需要在Slave上配置高频的存盘，或者启用AOF。需要注意，这种用法下Master重启时是空数据集，如果不进行适当处理，它会导致Slave的数据集立刻变空

KeyDB支持Active Replicas（Active Active）模式，这大大简化了故障转移的处理 —— 不需要确定副本何时应该晋升。

默认情况下，KeyDB以类似Redis的方式运行，仅仅允许从Master到Replicas的单向数据复制，副本仅仅支持只读处理。启用Active Replica模式后，即使Replica到Master的连接中断，它也能够处理请求。

KeyDB在复制时，支持多主模式。 使用配置：

multi-master yes

当KeyDB连接到多个Master进行复制时，其行为和传统复制不同：

1. 多次调用replicaof命令，会为本节点添加额外的Master，而非替换掉Master
2. 同步到Masters之前，不会丢弃自己的数据
3. 将合并来自多个Masters的读写到自己的内部数据库中
4. 最后一个操作生效，也就是说，有两个Masters同时修改一个键，那么后修改的那个是实际值

到目前为止，多主特性仍然是试验性的，在偶然情况下该特性可能触发流量封包。

如果仅仅有两个实例，建议使用主主模式。

KeyDB能够处理脑裂（两个节点之间网络断开）的场景。脑裂发生时，每个节点各自接受写入操作，每个写操作被加上时间戳，当连接恢复后，主节点们合并数据，以后写入的数据为准。

这种last-win原则在KeyDB里很常见，其它的例子如下文会提到的configEpoch冲突处理。

从2.6版本开始KeyDB支持Slave的只读模式，并且默认开启。对应的选项是

slave-read-only

CONFIG SET

从2.8版本开始KeyDB支持设置：仅仅当至少有N个Slave连接到Master，此Master才允许写操作。这可以增强数据安全性，再次强调一下，任何时候都不能保证数据绝不丢失。

该特性的工作方式是：

1. KeyDB Slaves每秒PING一次Master，Ack自己处理的复制流的量
2. KeyDB Master记住每个Slave的最后一次PING的时间
3. 如果PING正常的Slave数量小于配置的值，Master停止写入

相关配置项：

1. min-slaves-to-write

   ：正常PING的Slave的最小数量

2. min-slaves-max-lag

   ：如果PING延迟大于此参数指定的秒数，认为Slave不正常

KeyDB集群的设计目标，依据重要性排列如下：

1. 高性能，支持最多1000节点规模。不使用代理、异步复制，不需要对键值进行merge操作
2. 可接受的数据安全性：集群尽可能保证连接到大部分Master节点的客户端的写操作。最小化Ack后的写操作丢失的可能性，连接到少数Master节点的客户端的写操作丢失的可能性更大
3. 可用性：当出现网络分区后，如果大部分Master节点可以连接，并且对于无法连接的Master节点们至少各有一个Slave节点可以连接，则可用性得到保证。此外，如果使用副本迁移（replicas migration），没有Slave的节点可以从Slave过多的节点夺取Slave

KeyDB集群使用异步复制，Last Failover  Wins原则意味着最后晋升的主的数据集会覆盖其它副本的数据集。由于异步复制的天然特征，这意味着总是存在丢失数据的窗口。

如果出现网络分区，连接到大部分Master所在分区的客户端，丢失数据的时间窗口比连接到少数Master所在分区的客户端要小。发生故障转移的必要条件是集群中大多数Master到某个Master的通信不可达时间超过NODE_TIMEOUT，如果网络分区在超时前恢复，不会丢失数据（被新的Master覆盖）。当连接断开超过NODE_TIMEOUT之后，如果网络分区中Master数量少于一半，则所有Master停止接受写入。

下面是连接到大多数Master的客户端丢失已经Ack数据的场景：

1. 写操作已经到达Master，应答客户端时，异步的复制尚未传播到Slave
2. Master宕机
3. 过了较长时间后，Slave晋升，它的数据集成为权威

另外一个场景：

1. Master由于网络分区不可达
2. 发生故障转移，Slave晋升
3. 旧Master网络恢复
4. 某个客户端使用过期的路由表，将数据写到Master

第二种场景的发生概率很小，需要多种巧合同时发生。

对于连接到少数Master的客户端，数据丢失的时间窗口可能较大，直到NODE_TIMEOUT之前的写入都可能丢失。

出现网络分区后，少数Master所在的分区失去可用性。 

在多数Master所在的分区，如果对于不可达的Master，至少有一个Slave也在该分区，则可用性在NODE_TIMEOUT+若干秒（Slave晋升为Master，通常需要1-2秒）后恢复。

副本迁移（replicas migration）可以提升可用性，在大多数Master分区中，如果某个Master有多余的Replica，可以迁移给（在当前分区）没有Slave的（不在当前分区的）Master。

KeyDB集群不会代理请求，只会向客户端发起重定向，让它访问匹配的键空间分片的节点。

最终客户端会得到up-to-date的集群、键空间分片-节点映射关系的信息，并且直接访问正确的节点，避免重定向。

由于通常的操作仅仅发生在单个节点上，因此可以认为N主节点的KeyDB集群的性能和单个KeyDB实例是相似的。

KeyDB集群节点提供总线进行通信，总线使用客户端端口+10000（默认16379），协议是KeyDB Cluster protocol。

在KeyDB Cluster protocol中，节点负责存储数据、集群状态（包括键到节点的映射）、发现其它节点、检测无效节点、晋升Slave节点为Master。

节点之间使用一种gossip协议来传播关于集群的信息，从而发现新节点、发送PING包来检测节点是否正常工作、同步关于集群特定状态的信号。

KeyDB Cluster Bus还用于在集群范围内传播Pub/Sub消息，协调用户发起的手工故障转移。

为了实现总线的功能，所有节点通过二进制协议KeyDB Cluster Bus连接在一起，支持1000节点需要维持百万级的TCP连接。

为了避免在节点之间交换过多的信息，KeyDB使用gossip协议 + 一种配置更新机制。这保证了消息量不会随着集群规模而指数级增长。

KeyDB集群不会代理（转发）客户端请求，它可能给出响应并触发重定向。理论上客户端可以发送请求给任何节点，并在必要时获得重定向，因此它不需要持有集群的状态信息。但是，客户端可以缓存键-节点映射，来改善性能。

节点总是接受总线端口上的连接，并且应答PONG给PING请求，即使源节点不受信任。但是对于其它消息，如果源节点不是集群成员，将全部丢弃。

节点在以下情况下，接受某个源节点作为集群成员：

1. 新节点发送

   MEET

   消息，此消息类似于PING，但是会强迫消息接受者，接纳源节点作为集群成员。仅当系统管理员执行：
   

   CLUSTER MEET ip port

   节点才会发送MEET消息

2. 通过gossip协议传递的，关于节点被加入集群的事实。如果A、B已经是集群成员，现在C新加入并且MEET了A，那么A会gossip给B，这样A、B都认可C作为成员了

总线不支持在NAT环境下，或者任何TCP被映射的环境下工作。对于Docker来说，你可能需要设置

--net=host

整个键空间被划分为16384个Hash Slots，Slot是分片的最小单位，意味着理论上集群最多有16384个主节点（实际上建议的上限是1000左右）。

集群中每个Master处理这些Slots的子集。如果没有进行中的集群再配置（reconfiguration）—— 没有正在移动的Hash Slots ——则我们称集群为stable的。稳定集群中每个Slot被单个Master节点所处理

键到Slot的映射算法是：

HASH_Slot = CRC16(key) mod 16384

使用Hash tag可以确保多个键被分配到同一个Slot，以便KeyDB集群支持multi-key操作。

如果键中包含

{...}

集群中的每个节点具有唯一的、自动生成的ID，该名称是160bit的随机数。节点会将此名称存放在配置文件中，并且一直使用相同的名称，除非：

1. 配置文件被删除
2. 执行硬重置命令

   CLUSTER RESET

节点ID用于在集群范围内唯一的标识节点，节点可以改变自己的IP地址，但是它的ID不需要改变。集群可以感知节点的IP地质变更，并使用gossip协议，通过集群总线进行重配置。

在任何节点执行

CLUSTER NODES

1. 节点IP地址:端口
2. 一系列标记位
3. 如果节点被标记为Slave，则它的Master是谁

keydb-cli cluster nodes

d1861060fe 127.0.0.1:6379 myself - 0 1318428930 1 connected 0-1364
# 节点ID   地质:端口       标记      最后PING/PONG时间   配置epoch  连接状态   Slots
3886e65cc9 127.0.0.1:6380 master - 1318428930 1318428931 2        connected 1365-2729
d289c575dc 127.0.0.1:6381 master - 1318428931 1318428931 3        connected 2730-4095

KeyDB集群允许在运行时添加、删除节点。这都潜在的意味着Hash Slot的重新平衡。和调整Hash Slot有关的命令有：

# 添加Slot，通常加入新节点时使用
CLUSTER ADDSlotS Slot1 [Slot2] ... [SlotN]
# 很少使用
CLUSTER DELSlotS Slot1 [Slot2] ... [SlotN]

# 将Slot分配给特定节点
CLUSTER SETSlot Slot NODE node

Hash Slot重新分配之后，将通过gossip协议进行配置传播（ configuration propagation ）。

SETSlot子命令还可以拆分为两条。假设我们希望将Slot 8从A迁移到B：

1. 向B发送：

   CLUSTER SETSlot Slot MIGRATING A

   。这样，B会接受所有关于Slot 8的查询，但是如果本地没有Key，则发送

   ASK

   重定向，让客户度询问A
2. 向A发送：

   CLUSTER SETSlot Slot IMPORTING B

   。这样，A会接受所有关于Slot 8的查询，但是请求必须以

   ASKING

   命令作为前导，否则MOVE重定向给Slot的负责人B

重新分片牵涉到键的迁移，这个迁移是逐步进行的 —— 不是原子的移动Slot。

这意味着，在迁移过程中，多键操作的Key，可能一部分位于节点A，一部分以及迁移到节点B。由于KeyDB集群限制多键操作仅仅牵涉单个节点（所有键位于一个Hash Slot），因此这种情况下会应答客户端以

TRYAGAIN

KeyDB客户端可以自由的向任何节点发送查询请求，节点会进行以下处理：

1. 分析查询请求是否是acceptable的 —— 要么查询仅仅牵涉一个键，要么牵涉到在同一Hash Slot中的multikey
2. 查找其内部的Slot-node映射，找到负责目标Hash Slot的节点：
   1. 如果是当前节点负责，直接处理请求
   2. 如果是其它节点负责，应答客户端以MOVED错误：
      

      GET x
      #      键所属Slot   负责处理此Slot的节点
      -MOVED 3999        127.0.0.1:6381

重定向中已经给出正确节点的信息，客户端应该（但不必须）缓存并且向正确节点发请求。

一旦重定向发生，可能潜在的Slot-node映射发生很大变化，客户端可以通过

CLUSTER NODES

CLUSTER SlotS

MOVED用于提示客户端，很明确Hash Slot永久的被另外一个服务器所处理了。

ASK重定向则是提示客户端，Hash Slot可能处于迁移过程中，我虽然负责此Slot，但是没有找到你需要的Key，你去问问原来的所有者吧。

默认情况下，Slave节点仅仅会重定向请求给处理Hash Slot的Master节点。

客户端可以使用

READONLY

当一个连接处于只读默认下时，仅当查询牵涉不被Slave的Master负责的Key（可以由于重新分片导致）时才会发送重定向。

使用命令

READWRITE

KeyDB节点持续的交换PING/PONG封包，这两种消息的差别仅仅是消息类型。PING/PONG消息也叫心跳。

通常情况下，PING会触发接受者回复PONG。但是PONG也可以用来携带重要的配置信息，并且不需要应答。这种用法可以尽快广播新的配置。

通常情况下，发送心跳时，节点会随机选择几个节点作为目标，而不是发给所有节点。这避免了随着集群规模的增大而出现消息风暴。不过，作为一个前提，节点确保在NODE_TIMEOUT / 2的时间内，至少发送一个心跳给从未沟通过（不管谁主动发送PING都可以）的节点。

即使NODE_TIMEOUT到达了，节点也会重新发起一次TCP连接，防止因为连接的问题导致误判。注意NODE_TIMEOUT必须要大于RTT。

需要注意根据集群规模来配置NODE_TIMEOUT，如果集群规模很大，而NODE_TIMEOUT又偏小，会导致大量的心跳包。

PING/PONG包和其他消息具有相同的头，该头的内容：

1. Node ID，发送节点的标识符
2. 发送节点的currentEpoch、configEpoch，这两个字段和KeyDB集群使用的分布式算法有关。Slave的configEpoch是它的Master的最后一个已知的configEpoch
3. 节点标记，提示节点是Slave还是Master，以及其他的单比特节点属性
4. 发送节点所负责的Hash Slot的位图信息，如果发送节点是Slave则发送它的Master的信息
5. 发送节点的客户端TCP端口
6. 从发送节点的角度来看，集群的状态（down/ok）
7. 对于Slave，其Master的Node ID

PING/PONG包还包括一个gossip段，其中包含发送者所认为的，集群（一部分随机的，否则消息太大，具体数量取决于集群规模）其它节点的状态。每个节点的信息包括：Node ID、IP:PORT、节点标记。这个gossip段可以用来进行故障发现、发现新节点。

故障发现（Failure Detection）用于发现这样的异常：Master/Slave不再被集群中的大部分节点可见，进而引起的Slave晋升为Master的过程。

如果无法通过晋升来解决故障，则集群进入错误状态，不再接受客户端查询请求。

通过前面的心跳机制我们了解到，每个节点都维护自己所认为的，其它节点的状态。状态表现为一系列标记，其中和故障发现有关的是：

1. PFAIL

   ，P表示Possible，即某个节点可能出故障了，但是尚未确认。如果目标节点在NODE_TIMEOUT时间范围内，从当前节点不可达，则标注为PFAIL。Master/Slave都有权标记某个节点为PFAIL

2. FAIL

   ，节点故障在固定的时间范围内被大多数Master所认可，该状态从PFAIL升级而来

前面我们了解到心跳的gossip段包含当前节点所认为的，随机的其它几个节点的状态。经过若干次心跳后，每个节点的的认知会传播到所有其它节点。当满足以下条件后，PFAIL变为FAIL：

1. 某个节点A，将节点B标记为PFAIL
2. 节点A通过心跳接收到的gossip分析集群中大部分节点关于B状态的声明
3. 如果大部分节点在

   NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT

   的时间区间内，标记节点B为PFAIL或FAIL。那么A标记B为FAIL，并发送

   FAIL

   消息给所有可达节点
4. FAIL消息会导致所有接收节点都将节点B标记为FAIL，不管它是不是认为B处于PFAIL状态

当前实现将FAIL_REPORT_VALIDITY_MULT设置为2。这意味着，在两倍NODE_TIMEOUT时间内，大多数Master将某个节点标记为故障，则集群认为该节点宕掉了。

需要了解PFAIL到FAIL的转换，依赖于一种弱（一致）的协议：

1. 节点在一段时间范围内，收集其它节点的（关于节点状态）视图。由于时间窗口的存在，我们无法确认（也不需要）在某个时间点是否大多数Master达成一致
2. FAIL消息会被传播，但是无法保证所有节点都能收到并修改故障节点状态，这是因为故障常常伴随网络分区

节点状态可以从PFAIL变成FAIL，但是FAIL状态仅仅在以下情况下才能清除掉：

1. 节点变得可达，并且成为Slave。由于Slave不能参与故障转移，因此FAIL状态清除
2. 节点变得可达，成为Master，但是不负责任何Slot。这种情况下FAIL状态可以被清除，因为该节点并没有正常参与到集群中
3. 节点变得可达，成为Master，过了很长时间（NODE_TIMEOUT的N倍）仍然没有可觉察的Slave晋升。这种情况下，最好是让该节点重新加入集群

KeyDB使用类似于Raft算法中的Term的概念，叫Epoch。当多个节点提供了冲突的信息时，Epoch可用于确定谁的状态是up-to-date的：

1. currentEpoch，可以认为是集群状态的版本号，最终所有节点应该具有相同的currentEpoch
2. configEpoch，每个Master节点具有独特的configEpoch，主要包含它负责的Hash Slots列表

每个新创建的节点，它的 currentEpoch（64bit无符号整数）都是0。每当从其它节点接收到一个消息，如果消息中的epoch大于本地的currentEpoch，则更新currentEpoch为接收到的epoch。

过了一段时间后，集群中所有节点都会使用最大的configEpoch作为自己的currentEpoch。

currentEpoch在集群节点需要协商，以决定执行某操作的时候用到，currentEpoch大的节点具有话语权。目前只支持Slave晋升这一种操作。

所有Master在PING/PONG的时候，都会通告自己的configEpoch（连同自己负责的Hash Slots）。

当一个新节点加入集群后，Master将configEpoch设置为0。Slave尝试晋升自己的时候，会增加configEpoch的值，并尝试获得大多数Master的授权。一旦Slave获得授权，则它成为使用此新configEpoch的Master。

Slave在PING/PONG中也会通告configEpoch，通告的是它（通过最后一次消息得到）的Master的configEpoch。如果它通告的configEpoch小于Master的真实configEpoch，这意味着它需要更新，选举时Master不会投票给持有过期configEpoch的Slave。

节点的configEpoch变更，会被所有接收到相关心跳的节点fsync到nodes.config中。如果引起currentEpoch的变更，也会fsync到nodes.config。

configEpoch值的递增有一个简单算法负责，此算法确保它是新的、递增的、唯一的。configEpoch的变化由于故障转移、再分片导致。

如果由于Slave晋升导致configEpoch增加，集群会确保它是唯一的。

以下两种操作，仅仅简单的更新本地的configEpoch，可能导致configEpoch冲突：

1. 使用带

   TAKEOVER

   选项的

   CLUSTER FAILOVER

   命令，可以强制晋升一个Slave节点，不需要大多数Master可用
2. 手工迁移Slot来进行再分片，也仅仅在本地节点生成新的epoch

手工再分片时，如果Slot从A迁移到B，分片程序会强制B增加自己的epoch为可发现集群范围内的最大值 + 1，除非节点的epoch已经是最大。由于再分片常常牵涉到大量Slot的迁移，为了每个Slot，进行协商并获得更高的configEpoch是很低效的，因此增加epoch仅在本地进行，并且仅仅在迁移第一个Slot时进行。

尽管可能性较低，还是会出现多个节点声明相同configEpoch的情况 —— 如果手工再分片和自动故障转移发生外加运气差的话。KeyDB使用下面的冲突解决算法：

1. 如果Master A发现Master B正在通告和自己相同的configEpoch
2. 并且根据字典序比较，A的Node ID比B大
3. 那么A将currentEpoch+1，并且将其作为自己的configEpoch

也就是说，如果集群中有若干节点具有相同configEpoch，那么其中ID最大的取胜，出现Hash Slot冲突时以它为准。

Hash Slots - 节点映射关系的传播，不管对于新集群，还是由于故障转移/手工重分片导致的Slot负责节点变更，都是关键的。

Hash Slots配置信息可以通过两种方式传播：

1. 心跳消息：节点发送PING/PONG时总是携带它（或者它的Master）所负责的Slot的信息
2. UPDATE消息：由于心跳中还携带了自己的epoch，如果接受者发现此epoch过期，则会发送UPDATE消息，强制过期节点更新配置

当一个新的节点加入到集群后，它的Hash Slot映射（16383 个key）简单的置空（表示未分配）。当接收到心跳/UPDATE消息后，根据以下规则来更新映射：

1. 如果Slot为空，并且某个已知的节点claim该Slot，分配Slot给节点
2. 如果Slot不为空，并且它映射给Master A，如果现在接收到Master B的消息，声明Slot归它管。这种情况下，如果B的configEpoch大于A，则重新绑定Slot给B

由于规则2的存在，最终集群中所有的节点都认可configEpoch最大的节点通告的映射关系，这就是所谓last failover wins机制。

故障转移：

1. 依赖于上面两节提到的故障发现、配置传播机制
2. 由出问题的Master的Slave主导，其它Master节点参与投票完成
3. 触发时机为：
   1. Master进入FAIL状态，并且经过了选举时延
   2. Master至少负责1个Slot
   3. Slave和Master的复制连接断开时间小于，这是为了保证Slave的数据不过于陈旧

故障转移过程如下：

1. Slave增加自己的configEpoch，并同步currentEpoch
2. 请求Masters来投票，具体做法是广播

   FAILOVER_AUTH_REQUEST

   消息给所有Master节点
3. 等待Master的应答，最长

   NODE_TIMEOUT * 2

   ，最短2秒
4. 如果应答的Master的epoch小于发起晋升时Slave的currentEpoch，则应答被丢弃。这个可以防止接收到关于上一次选举的投票
5. 如果Slave在限定时间内获得大多数Master的投票，则晋升成功。否则，等待

   NODE_TIMEOUT * 4

   再次进行选举

Master参与投票时遵循以下规则：

1. 对于一个给定的epoch，每个Master仅会投票一次：如果Master投票给Slave，它应答FAILOVER_AUTH_ACK，同时将lastVoteEpoch字段持久化到配置文件。Master在NODE_TIMEOUT * 2的时间内，不再能投票给故障Master的其它Slave，这可以防止同时选出多个新Master。
2. 只有Master任何被故障转移的Master处于FAIL状态，才会进行投票
3. 如果FAILOVER_AUTH_REQUEST中的currentEpoch小于Master的currentEpoch，请求被忽略 —— 这意味着投票应答的epoch总是和请求的相同

Master进入FAIL状态后，Slave还需要等待一个选举延迟：

DELAY = 500 毫秒 + 0 -500 毫秒随机延迟 + SLAVE_RANK * 1000 毫秒

才会发起选举投票。固定延迟让FAIL消息有机会传播到整个集群，随机延迟可以防止两个SLAVE_RANK相同的Slave同时尝试晋升。

SLAVE_RANK的大小取决于复制的进度。当Master故障时，Slave会相互通信，交换自己的复制进度，并进行排名。进度最快的Slave的SLAVE_RANK为0，依次递增。

一旦Slave赢得选举，它将获得大于所有其它Master的configEpoch，并且通过心跳通告自己的configEpoch、负责的Slots。

为了让集群尽快完成重新配置，Slave将发送一个PONG包给整个集群。当前不可达的节点可能通过下面两种方式之一获得更新：

1. 接收到其它节点的PING/PONG包
2. 其自己发送的心跳，由于信息过期，被其它节点应答以UPDATE

重新配置的内容包括：

1. 对于故障的Master的原有其它Slave，需要更新复制源
2. 对于所有节点，需要更新Hash Slot - 节点映射关系 

如果一个Master节点因为网络分区，脱离集群，并且时间足够长，发生了故障转移。那么网络恢复后，旧的Master如何处理？

在KeyDB中，旧Master将配置为偷取了它的Slot的那个节点的Slave。

重置节点，可以让它以另外一个角色加入集群，或者加入其它集群。

执行

CLUSTER RESET

1. 如果节点是Slave，则角色切换为Master，丢弃数据集；如果节点是Master并且持有Key，则中止重置
2. 释放所有Hash Slot，重置手工故障转移状态
3. 移除节点表中所有其它节点，这样节点对原先集群一无所知
4. 对于硬重置：currentEpoch、configEpoch、lastVoteEpoch均置零
5. 对于硬重置：Node ID修改为新的随机值

通过重新分片，将Master的Slot全部迁移走，就可以关闭它了。

由于其它节点仍然记着移除节点的Node ID和地址，还会尝试连接它，因此，你应当调用

CLUSTER FORGET <node-id>

1. 从所有节点的nodes table中移除指定节点
2. 60s内禁止被移除节点（根据ID）再次加入集群。防止因为gossip导致重新加入

集群的客户端可以在任何节点上订阅，在任何节点上发布。KeyDB会保证消息被正确的转发 —— 目前的实现仅仅是简单的广播。

The post KeyDB学习笔记 appeared first on 绿色记忆.

Redis（REmote DIctionary Server）是一个开源的、基于内存的数据结构存储。可以作为数据库、缓存、消息代理使用。它支持字符串、散列、列表、集合、有序集合等多种数据结构，并提供范围查询。它支持位图、hyperloglogs（一种用于解决count-distinct问题的算法，可以估算Bag中的distinct元素的近似个数）、地理空间索引，并支持径向查询。Redis内置了复制（replication）机制，支持Lua脚本、LRU清除算法。Redis支持事务，以及不同级别的磁盘持久化。基于Redis Sentinel和Redis Cluster的自动分区（automatic partitioning）机制，它能够提供HA保障。

Redis可以认为是NoSQL数据库的一种，它是目前最流行的键值对存储引擎。这类存储允许你基于键来保存数据，在之后，你必须知道键才能取回数据。

几乎所有的主流语言都有Redis的客户端。

由于Redis更加新，特性更加丰富，相比Memcached它通常总是正确的选择。

Redis的最根本优势在于数据结构的支持。它支持长达250MB的键、值大小，支持字符串、哈希、列表、有序集合、集合等数据类型；Memcached仅仅支持250字节的键，值仅仅支持字符串。

Redis作为缓存使用时，数据清除算法更加丰富，相比之下Memcached仅支持LRU、随机清除。Redis提供主动清除（生存期）、被动（延迟）清除，Memcached仅支持被动清除。

Memcached更加适合缓存相对小的、静态数据，例如HTML代码片段。这是因为Memcached的内部内存管理不像Redis那样精巧，在元数据方面消耗较少的内存。但是，如果数据尺寸是动态的，Memcached的上述优势很快消失，因为它存在内存碎片问题。

Scaling是选择Memcached的另外一个场景，因为它是多线程的。你可以很容易的Scaling up来使用更多的计算资源。Redis则基本是单线程的，你需要通过集群来水平Scale，比Memcached复杂。

参考以下步骤进行安装：

# 安装Redis服务器
sudo apt-get install redis-server
# 查看版本
redis-server --version
# 禁用服务自动启动
sudo update-rc.d redis-server disable

使用下面的命令可以运行基于Docker的Redis：

# 拉取镜像
docker pull redis:3

# 在后台运行Redis容器
docker run --name redis -d redis

# 启用持久化存储，存储目录默认/data
docker run 
    -v ~/Docker/volumes/redis/data:/data -v ~/Docker/volumes/redis/conf:/conf 
    -p 6379:6379 --name redis -d redis redis-server /conf/redis.conf

要定制Redis配置文件，可以扩展镜像： 

FROM redis:3

COPY redis.conf /usr/local/etc/redis/redis.conf
CMD [ "redis-server", "/usr/local/etc/redis/redis.conf" ]

Redis是一个TCP服务器，使用请求/应答通信模型。这意味着一个请求通常按如下步骤完成：

1. 客户端发送一个请求给服务器，通常以阻塞的方式等待读套接字，以获取服务器响应
2. 服务器处理命令，并把结果发送给客户端

客户端/服务器基于网络连接，这个网络可能很快——例如环回网卡，也可能很慢。从客户端发送请求，到接收到服务器响应的这段时间，称为RTT（Round Trip Time）。

Redis支持在客户端尚未读取旧的响应之前就处理新的请求，客户端可以连续发送多个命令给服务器，而在最后一起处理所有应答。Redis API提供了管道相关的接口

Redis支持这种交互模型，并提供了相关的命令。使用这种模型，消息发送者不需要显式的发消息发送给特定的接受者，而仅仅需要把消息发布到频道（Channel）上，从而实现解耦。

订阅了频道的客户端，不应该发送不相关的命令，仅可以发送：SUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE, PUNSUBSCRIBE, PING, QUIT这几个命令。

每个推送给订阅客户端的消息，是三元素的数组。第一个元素是消息的类型，值可以是：

1. subscribe，表示成功订阅了通道。目标通道名称作为第二个元素，第三个元素是当前订阅的通道数
2. unsubscribe，表示成功取消了订阅。目标通道名称作为第二个元素，第三个元素是当前订阅的通道数
3. message，表示接收到其它客户端PUBLISH的消息。第二个元素是消息来自的通道，第三个元素是消息载荷

发布/订阅与Redis数据库、键空间没有任何关系，你在数据库0上发布，客户端可以在数据库10上订阅。

Redis支持基于通配符的订阅，示例：

PSUBSCRIBE news.*
PSUBSCRIBE f*

从2.2开始，Redis优化了很多数据类型，以占用更少的内存空间。仅仅由整数构成的哈希、集合、列表，以及有序集合，在编码后占用内存大小可能小十倍。从用户和API的角度来说，这一编码是完全透明的。 

特殊编码是一种CPU消耗 - 内存占用的权衡。Redis提供一些参数，来调整编码行为：

# 进行压缩的容器，其元素个数的限制
hash-max-zipmap-entries 512  
# 进行压缩的集合，其元素长度的限制
hash-max-zipmap-value 64 
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512

当目标容器元素个数或者元素长度超过限制，则自动使用正常编码。

由于指针长度短，32位的Redis使用更少的内存，但是缺点是，它最多使用4GB的内存。对于32/64位Redis，RDB、AOF文件的格式是兼容的。

从Redis 2.2引入的GETRANGE, SETRANGE, GETBIT,SETBIT命令，允许你将字符串作为随机访问数组看待。前面两个命令可以按字节操作，后面两个命令更是按位操作。合理使用这些命令可以减少内存消耗。

小的哈希被Redis很好的编码，很节约空间，因此你可以尽可能考虑以哈希的方式存储数据，而不是单独存储每个字段。

为了存储用户的键值，Redis可以分配不超过maxmemory设置的内存。

关于Redis管理内存的方式，你需要知道：

1. 当键被移除后，Redis不总会把内存归还给OS。你需要根据内存需要量的峰值来规划配置
2. 尽管Redis可能不归还内存，但是新插入的键会智能的使用这些未归还、但是已经空闲的内存
3. 碎片率（ fragmentation ratio）在当前内存用量远小于峰值用量时，可能不准确。碎片率 = 当前内存用量 / RSS。RSS即驻留工作集尺寸——占据物理内存的尺寸

如果你不设置maxmemory参数，Redis会尽可能多的占用内存，从而影响OS性能。

当把Redis作为缓存使用时，让其自动的清除陈旧数据，通常符合缓存需求。

LRU是最常见的一种数据清除算法，Redis也支持其它算法。

使用配置指令可以限制Redis使用内存的峰值：

maxmemory 100mb

如果设置为0，表示无限制。这是64位系统的默认值，32位系统隐含限制3GB。

当Redis到达最大内存限制后，可以依据设置的策略（policies）来决定如何处理 —— 例如返回错误，或者清除旧数据。支持的策略如下表：

从4.0版本开始，Redis支持新的LFU（ Least Frequently Used）算法，在某些情况下该算法工作的更好。该算法会尝试跟踪每个键被使用的频率，使用频率最少的键会被清除。LRU算法可能会保留最近访问了一次，但是实际上基本不会被访问的键，LFU不存在此问题。

Redis支持把多个命令分为一组，然后作为单个事务来执行。

MULTI, EXEC, DISCARD,WATCH这几个命令是Redis事务控制的基础。通过组合使用这些命令，你可以单步执行多个命令，并确保：

1. 事务中所有命令被顺序的执行。从效果上说，不会发生其他客户端发起的命令，插入上述事务中间执行的情况。所有命令就像是单个操作似的
2. 要么所有命令执行，要么都不执行。EXEC命令触发事务中所有命令的执行。当使用AOF文件时，Redis确保使用单个write(2)系统调用把事务操作写入磁盘，除非Redis崩溃或者被强制杀死 —— 可能仅有部分命令的结果被写入磁盘。如果发生这种意外，在Redis下一次启动时，它会提示错误并退出。你需要使用

   redis-check-aof

   来修复AOF文件，把不完整执行的事务移除，然后再启动Redis

从2.2开始，Redis为事务提供额外保证 —— 使用乐观锁。

Redis事务从MULTI命令开始，该命令的应答总是OK。发起该命令后，用户可以继续发起多个命令。后续的命令不会立即执行，而是排队，直到你调用EXEC命令。

如果调用DISCARD而不是EXEC，会清除命令队列并且关闭事务。

在事务中，你可能遇到两类命令错误：

1. 命令可能无法进入队列，原因例如命令格式错误，或者出现极端情况，例如内存不够
2. 命令可以在EXEC调用之后失败

对于第一类错误，用户可以检查入队命令的返回值，如果显示QUEUED意味着入队成功。否则意味着入队失败，这种情况下通常需要DISCARD事务。从2.6.5开始，只要存在入队失败，EXEC一定会返回一个错误并自动DISCARD事务。

对于第二类错误，没有特殊的处理。如果某个命令执行失败，其它任务仍然会继续执行。

前面我们提到过，事务过程中某条命令执行失败，并不会中断后续命令的执行，或者回滚之前已经执行的命令，这和关系型数据库很不一样。Redis的这种行为的原因是：

1. Redis命令仅仅会在语法错误、键持有不匹配的数据类型的情况下，才会失败。这意味着失败通常由于编程错误，应该在开发阶段就发现
2. 由于不去支持回滚，这让Redis更简单、更快

WATCH命令提供了一种检查并设置（CAS，check-and-set），为Redis事务提供乐观锁。

被监控（WATCHed）的键的修改会被发现，如果存在一个或者更多的键，在EXEC之前修改了，则整个事务被中止，EXEC命令返回一个Null Reply。

WATCH命令可以调用多次，其监控的时间范围是，从调用的那一刻起，到EXEC被调用时为止。

调用UNWATCH，可以撤销之前所有WATCH命令。

Redis提供了两种持久化模式：RDB、AOF。这两种模式可以同时启用，你也可以完全禁用持久化。当同时启用时，在Redis启动时会读取AOF文件，因为它更能保证数据的完整性。

Redis官方建议同时使用两种持久化模式，并且在远期未来将其合并为一种。

RDB相关的配置项：save；AOF相关的配置项：appendonly。

该模式在磁盘上保存某个瞬间的数据集快照，可以定期的保存。Redis异步的把数据写到磁盘上，形成.rdb文件。该模式对于很多应用程序足够好用。

RDB的优势：

1. 作为Redis的瞬时快照，RDB文件格式紧凑，很适合作备份用途，例如远程灾备
2. RDB性能较好，因为Redis主线程仅仅需要Fork出子线程负责磁盘I/O，主线程基本不需要执行磁盘I/O
3. 如果数据集很大，RDB的启动速度高于AOF

RDB的劣势：

1. 如果Redis进程崩溃或者电力中断，你可能丢失数分钟的数据，具体时间范围取决于你如何配置保存点（Save point）

另一种持久化模式是仅附加文件（Append Only File），它实际上是服务器接收到的每个写命令的日志，且命令日志的格式与Redis协议相同。当服务器重新启动时，该日志可以被回放，以还原先前的数据集。

该模式提供了好得多的durability：

1. 使用默认的数据fsync策略你最多在断电这种极端情况下丢失1秒的数据
2. Redis进程本身出现问题（但OS正常）时，最多丢失最后一次写操作

AOF的额外优势：

1. AOF日志仅仅需要进行追加操作，因而不需要Seek。AOF不存在文件损坏的问题，即使日志结尾是写入一半的命令，也可以用 redis-check-aof进行修复
2. AOF文件变大后，Redis可以在后台进行重写。这个重写操作是完全安全的，因为重写时Redis还会在旧文件上追加，如果重写失败，旧文件仍然可用
3. AOF日志格式容易解析

AOF的劣势：

1. 相同数据集下AOF比RDB大
2. 基于使用的fsync策略，AOF可能比RDB慢。禁止fsync在高并发情况下，性能与RDB一样快，如果每秒fsync一次，也还算很快

Redis中进行主从复制的配置很简单，关于主从复制，你需要知道：

1. Redis使用异步的主从复制，从2.8开始，Slave定期的确认（acknowledge）从复制流中处理的数据量
2. 一个Master可以拥有多个Slave
3. Slave允许来自其它Slave的连接。并形成Master - Slave - Slave的树形结构
4. 在Master节点，复制是非阻塞的。当一个或者多个Slave执行初始同步时，Master仍然接受查询请求
5. 在Slave节点，复制也是非阻塞的。当Slave执行初始同步时，它仍然能够（如果你进行适当的配置）使用原来的数据集对外提供查询服务
6. 复制可以提供扩容性，可以把只读的缓慢查询分配给Slave执行
7. 可以完全避免Master的磁盘I/O开销，你可以配置一个Slave，并启用AOF。这种技巧需要注意处理Master宕机，因为重启后它的数据集为空，不应该作为Master

上面我们提到过，可以处于性能的考虑禁用Master的持久化。Redis不建议这样，如果禁用Master的持久化，一定要同时禁止Redis开机启动。

当你配置好一个Slave后，在连接建立后它发送一个PSYNC命令。如果这次连接属于“重新连接”并且Master的backlog足够大，则Master把增量数据集发送给Slave。否则，触发一次完全同步（full resynchronization ）。

完全同步触发后，Master在后台启动一个保存线程，产生RDB文件。与此同时，Master对新的写命令进行缓存。RDB文件准备好之后，发送给Slave加载到内存，然后写命令缓存也被发送给Slave进行回放。

当与Master的连接断掉后，Slave会自动进行重连。

如果多个Slave需要同步，Master只会产生一个RDB保存进程。

某些场景下你需要在短时间内完成大量数据的插入，例如添加百万个新的Redis键。本节内容介绍如何尽快的完成数据的插入。

使用普通的Redis客户端执行海量数据插入通常不是好主意，因为：

1. 最简单的方式：一个一个的发送命令，大量时间浪费在了RRT上
2. 使用管道（Pipelining）可以缓解上一条，但是，它限制了在最后一起处理响应。在大量数据插入的场景下，最好能一边插入新条目，一边处理旧条目的响应

仅仅少量的客户端支持非阻塞I/O，而且，并非所有客户度能够高效的解析响应以最大化吞吐量。因此，在Redis中完成海量数据的最好方式是，生成包含原始数据、Redis协议的文本文件，然后通过Redis客户端的Pipe模式发送给服务器处理。

所谓分区（Partitioning）是指把你的数据分散到多个Redis实例的处理过程，每个实例仅持有键空间的子集。分区的意义在于：

1. 通过利用多台计算机，突破单机内存限制，支持更大的数据集
2. 把计算能力Scale到多台计算机的多个CPU；把网络带宽Scale到多台计算机的多个网络接口

最简单的是范围分区（range partitioning），它要求键的格式为

key-name:id

另外一种是哈希分区（hash partitioning），它通过计算键的散列值来决定其应当由哪个实例持有，对键格式没有要求，也不需要额外的表。

分区的职责可以划分给软件栈中的不同组件：

1. 客户端分区：客户端直接决定该把键发送给哪个节点处理。很多Redis客户端实现了此功能
2. 代理辅助分区：客户端把请求发送给一个理解Redis协议的代理，此代理负责转发请求给适当的实例。Redis实现了这种方式，Memcached的Twemproxy类似
3. 查询路由：客户端随机的把请求发送给一个实例。由该实例将其转发给正确的实例。Redis集群利用客户端的辅助，实现了混合形式的查询路由 —— 请求不在节点间转发，而是客户端被重定向到正确的节点，并由客户端直接发送请求给正确的节点

Redis分区的某些特性做的不是很好：

1. 牵涉到多个键的操作常常不被支持。例如，你不能（直接）对两个分布在不同实例上的两个集合进行交叉操作
2. 牵涉到多个键的事务无法支持
3. 分区的粒度是键，无法对一个键下的巨大数据集进行分区
4. 使用分区时，数据的处理更加复杂。例如需要处理多个RDB/AOF文件。在备份时，你需要从多个机器上收集持久化文件
5. 增减容量可能比较复杂。Redis集群支持几乎透明的在运行时添加/移除节点，实现数据的Rebalance。其它分区实现，例如客户端分区、代理辅助分区则不支持这种Rebalance，需要使用Pre-sharding技术

尽管从概念上说，Redis分区用在数据存储还是缓存场景下没有什么区别。但是，用作数据存储时，有一个重要的限制——一个键必须总是映射到相同的Redis实例。

一致性哈希（Consistent hashing）实现通常能够在某个键的最优节点不可用时，自动切换到其它节点。类似的，当添加新节点后，一部分新的键可以自动分配到新节点上。

当作为缓存使用时，Redis可以基于一致性哈希很容易的Scale up/down。

当用作数据存储时，需要基于固定的键-节点映射表，节点的数量必须是固定的，不能改变 —— 否则必须在增减节点时实现Rebalance，当前只有Redis Cluster支持这种Rebalance。

前面我们提到过，作为数据存储的分区，要添加/删除节点并不容易。但是，随着时间的推移，数据存储肯定是要不断变化的，今天需要10个节点就满足需要，明天可能需要增加到15个。

要解决这个问题，第一个方案是，从开始就准备足够多（32或者64个满足绝大部分场景）的实例。可以这样做的原因是Redis实例本身占用很少的资源，它仅仅需要1MB的内存。计算在数据很少的情况下，你也可以在单台机器上使用这种分区方式。当数据增多，单台机器计算资源不够时，可以增加一台服务器，并把一半的实例迁移到新的机器上。利用Redis的复制机制（Replication），可以在免宕机/最小化宕机时间的前提下，实现这种迁移：

1. 在新服务器上启动新实例
2. 把这些实例作为需要迁移的旧实例的Slave
3. 停止客户端
4. 更新迁移实例的IP地址配置
5. 在新服务器上，对实例发送

   SLAVEOF NO ONE

   命令
6. 基于新的配置启动客户端
7. 关闭旧服务器上不再需要的那些实例

从2015年4月开始，Redis Cluster已经可以胜任生产环境了，Redis Cluster的实现方式类似于查询路由、客户端分区的混合。

Redis Cluster是最优的分区方案，因为它可以自动分区并提供高可用性。一旦基于你熟悉编程语言的Redis Cluster客户端可用，Redis集群将作为分区实现的标准。

当多个进程需要互斥的操作同一共享资源时，分布式锁是一种有用的原语。

很多第三方库实现了可以配合Redis的分布式锁管理器（Distributed Lock Manager，DLM），它们的实现方式各有不同。Redis推荐基于红锁（Redlock）算法的实现，主流语言有实现。

Redlock提供以下最小化保证：

1. 安全性保证：互斥性，在任意时刻，仅一个客户端能够持有锁
2. 活动性A：不会发生死锁，请求者最终一定会获得锁，甚至是在持有锁的客户端崩溃、分区发生的情况下
3. 活动性B：容错，只要大部分Redis节点可用，客户端总是能获得、释放锁

这是2.8.0开始引入的功能，它允许客户端订阅特定的频道，并在影响了Redis数据集的事件发生时，获得通知。这些事件例如：

1. 针对某个特定键的命令被执行
2. 针对所有键的LPUSH命令被执行
3. 数据库0中的任意键过期

事件通过普通的Redis Pub/Sub机制完成推送。但是，由于Pub/Sub没有提供持久化机制（因为它是fire and forget的），如果你的应用程序需要可靠的事件通知（reliable notification），键空间通知目前是不满足需求的。

由于值可以是结构化的，Redis并不是严格意义上的键-值存储。由于值可以是结构化的，因此支持不同类别的辅助索引（secondary indexes），包括组合（多列）索引就很有意义了。

Redis支持创建以下类型的索引：

1. 对于有序集合，可以根据ID或者其它数字字段创建索引
2. 基于词法范围（lexicographical ranges）的有序集合，可以创建更加复杂的辅助索引，组合索引，或者图遍历（graph traversal ）索引
3. 对于集合，可以创建随机索引
4. 对于列表，可以创建简单的迭代索引以及最后N条目的索引

索引的实现和维护，是Redis服务器的高级主题。对于大部分使用复杂查询的用户来说，应该考虑是否利用关系型数据库更加合适。

在Redis中使用辅助索引的最简单方式是，使用有序集合 —— 基于浮点数Score来排序元素的数据结构。使用有序集合索引的两个基础命令是ZADD、ZRANGEBYSCORE，前者添加元素，后者根据Score进行范围扫描。

举例来说，你可以根据年龄来索引一系列的用户名：

# 添加元素
ZADD myindex 18 Anna
ZADD myindex 35 Jon
ZADD myindex 67 Helen

# 索引范围查找
ZRANGEBYSCORE myindex 20 40

通常情况下，用户（User） 实体包含多个字段，而不仅仅是名字，这种情况下，可以在有序集合中存储用户的ID：

# 有序集合中存储实体标识符
ZADD user.age.index 38 1
ZADD user.age.index 42 2

# 实体以哈希方式另外存放
HMSET user:1 id 1 username antirez ctime 1444809424 age 38
HMSET user:2 id 2 username maria ctime 1444808132 age 42

这样，可以针对多个字段，分别建立索引。

ZADD还可以用来更新索引值，例如一年后，用户的年龄需要增加1（当然使用出身日期更简单），这时候，可以：

# 设置实体哈希的年龄字段
HSET user:1 age 39
# 更新索引
ZADD user.age.index 39 1

# 注意，上面的两个操作，可以使用MULTI/EXEC事务确保原子性

有序集合具有一个重要特性，当两个元素的Score相同时，它们将根据元素值进行字典排序（底层调用memcmp函数）。Redis的这种索引的内部实现方式和性能类似于关系型数据库的B树索引。使用字典序索引时，常常把Scoure一律设置为0。

使用 ZRANGEBYLEX、 ZLEXCOUNT 命令，可以使用字典序索引。

自动完成的例子

 字典序索引的一个常见应用是，表单的快速自动完成提示。当用户键入bit时，可以在后端执行以下Redis命令：

# \xff表示最后一个字节的最大值可以是255
ZRANGEBYLEX myindex "[bit" "[bit\xff"

如果需要对自动提示根据使用频率进行排序，我们可以扩展元素的值：

ZREM myindex 0 banana:1
# banana第二次被搜索的时候，设置频率为2
ZADD myindex 0 banana:2

这里用冒号来分隔自动完成关键字和搜索频率，由于字典序范围搜索在Redis中是二进制安全的，所以你可以使用任何分隔符，例如\0\0。

添加辅助信息

使用上述的分隔机制，我们可以在字典元素值中附加任意的内容，以满足应用需要。总之记住，字典序比较是以前缀为基准的。

前面我们介绍了索引单个字段的方式，那么，能不能像关系型数据库那样，索引多个字段呢。

考虑一个场景，我们需要对一个巨大仓库中的产品进行查询，依据是房间号、价格。这依赖于这两个字段的复合索引，实现起来其实很简单，关键之处还是字典序的前缀机制。我们需要对数字类型的索引字段进行前缀补齐，确保它们的长度总是一致，这样才能正确的进行字典序排序：

# room:price:product_id
# 索引字段必须补齐
# 辅助信息产品ID不需要补齐 

ZADD myindex 0 0056:0028.44:90
ZADD myindex 0 0034:0011.00:832

# 查询56号房间中，价格在10-30之间的产品
ZRANGEBYLEX myindex [0056:0010.00 [0056:0030.00

Redis集群（Cluster）提供了自动的把数据分区（Shard）到多个Redis节点（实例）的机制。

此外，集群也提供了某种程度的高可用性，当部分节点不可达的情况下，集群仍然可以运行。但是某些极端情况下，例如大多数Master不可达，则不行。

Redis集群中的节点需要两个端口，一个用于服务客户端，默认6379，另外一个端口比此端口大10000，用于集群总线。集群总线使用二进制协议，进行节点-节点之间的通信，用于故障检测（failure detection）、配置更新、故障转移授权等操作。

注意Redis集群与Docker的端口映射不兼容（也不兼容一般性的NAT环境、IP或者端口被重映射的环境），你可能需要使用host networking mode模式。

Redis集群不使用一致性哈希（consistent hashing），而是基于所谓Hash Slot进行分片，从概念上说，每个键都是Hash Slot的一部分。

集群中一共有16384个Hash Slot，计算键所属的Slot时，仅需要获得键的CRC16，然后针对16384进行取模操作。

集群中的每个节点负责所有Hash Slot的一个子集，当增减节点时，可以很方便的重新分配Hash Slot。把Hash Slot从一个节点转移到另外一个，不会引入downtime。

如果所有键都属于同一个Hash  Slot，Redis集群支持针对这些键的multiple key操作。你可以使用Hash Tag强制一批键归属于同一个Slot。

为了避免因为Master子集故障，或者无法连接到大部分的Master节点导致的集群不可用，Redis使用主从节点模型，每个Hash Slot具有N份复制，其中一份位于Master节点，N-1份位于N-1个Slave节点上。当Master节点失败后，集群会自动推举它的一个Slave成为新的Master。

Redis集群不保证强一致性，这意味着某些情况下，服务器已经向客户端确认的写操作，其数据可能丢失。

导致写丢失的一个原因是Redis使用异步复制，考虑以下场景：

1. 客户端向Master B发送写操作
2. Master B向客户端应答OK
3. Master B向它的Slave  B1 B2 B3传播此写操作

可以看到，在同步到Slave之前，Master已经应答了客户端OK，Redis这样做是出于性能考虑。如果在第2、3步之间Master B宕机，Bx晋升为Master，则写操作就永远的丢失了。

上述场景和那些配置为每秒执行Flush操作的数据库类似，也就是说你以前可能也面临这种数据丢失的风险。此外，你可以在应答客户端之前强制Redis Flush数据，这可能会影响性能，但是可以改善一致性。

Redis集群可以提供同步写操作，如果你的确需要。使用WAIT命令，丢失写的可能性大大减小。注意，即使使用WAIT也不能保证强一致性，特殊的情况下，一个不能接收来自Master的写入操作的Slave可能晋升为Master。

首先，你需要若干个运行在集群模式的Redis实例。节点的最小化配置文件示例如下：

port 7000
cluster-enabled yes
# 节点的集群配置文件，集群内部使用，不应该手工编辑
cluster-require-full-coverage no
cluster-node-timeout 15000
cluster-config-file nodes.conf
cluster-migration-barrier 1
appendonly yes

节点的数量至少需要3个Master。本节我们使用6个节点，其余三个为Slave。依次分配端口7000 - 7005。 你可以依据端口分别创建目录，在目录中存放上面的配置文件和Redis服务器二进制文件。然后，启动Redis服务器，你就拥有了6个Redis实例。

在节点第一次启动时，nodes.conf尚不存在，redis会自动初始化此文件，并得到自己的唯一标识（Node  ID）：

[82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c4479320d683e4c8db5858b1

要建立集群，可以使用Redis提供的命令行工具redis-trib，该工具包含在Redis 的源码中，依赖于：

gem install redis

执行下面的命令即可建立集群：

# create表示建立集群
# --replicas 指定每个Master的Slave数量
# 后面的参数为每个节点的地址和端口
./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

上述命令执行后，如果一起正常，屏幕上最终会打印： 

[OK] All 16384 slots covered

你可以随时执行下面的命令，判断集群状态是否正常：

redis-trib.rb check  redis-node-ip:6379
# 理想输出
# [OK] All nodes agree about slots configuration.
# >>> Check for open slots...
# >>> Check slots coverage...
# [OK] All 16384 slots covered.

如果你不想如上面那样，手工的配置、执行每个Redis实例， 可以使用Redis的utils目录下的create-cluster，这是一个Bash脚本，在底层它还是调用redis-trib完成集群创建的。示例：

create-cluster create
create-cluster start
create-cluster stop

重分区就是把一些Hash Slots从一批节点转移到另外一批节点的过程，我们同样需要使用redis-trib完成此工作：

# 只需要提供一个集群节点，其它节点会自动找到
./redis-trib.rb reshard 127.0.0.1:7000
# 回答问题，需要转移多少个Hash Slots
How many slots do you want to move (from 1 to 16384)?
# 根据提示，提供接收这些Slots的节点的ID
# 最后，可以检查集群的健康状态
./redis-trib.rb check 127.0.0.1:7000

# 非交互式的：
./redis-trib.rb reshard 
    --from <node-id> --to <node-id> --slots <number of slots> 
    --yes <host>:<port>

某些时候，在Master没有宕机的时候，你就需要进行“故障转移”，例如Master机器需要进行硬件维护。手工故障转移时，数据安全性比被迫故障转移要高，数据不会在处理过程中丢失。

要实现手工的故障转移，需要使用命令

CLUSTER FAILOVER

向集群中添加节点，基本上就是建立一个Redis实例，然后：

1. 分配一些Slot给它，这种情况下新节点作为Master
2. 作为一个已知节点的Replica，这种情况下新节点作为Slave

添加节点命令：

# 添加一个新节点 7006到集群
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

新添加的节点，与其它Master的不同之处：

1. 由于没有分配Slots，因此它不持有数据
2. 由于没有分配Slots，它不参与Slave晋升的选举处理 

通过重分区，可以为新节点分配Slots。

如果要作为Slave添加，可以参考如下脚本：

./redis-trib.rb add-node --slave --master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7006 127.0.0.1:7000

另外，你也可以使用CLUSTER REPLICATE命令完成上面的操作。 

从集群中移除节点，可以执行命令：

./redis-trib del-node 127.0.0.1:7000 `<node-id>`

如果要移除的是Master节点，它必须是空的，如果不是，你需要Reshard它的数据到其它节点。

Redis集群支持重新配置Slave节点，让它成为其它Master的Slave。你只需要在Slave上执行：

CLUSTER REPLICATE <master-node-id>

另外，Redis集群支持自动化的重新配置Slave节点以增强集群的可用性，不需要管理员手工介入。这种自动化的重新配置称为replicas migration。

Redis Sentinel为Redis提供高可用性（HA），利用Sentinel，你可以创建无人值守的高可用系统，自动处理某些故障。此外，Sentinel还负责一些附属任务，包括监控、通知，并作为客户端的配置提供者（configuration provider）：

1. 监控：不断的检查你的Master、Slave是否正常工作
2. 通知：可以通过API通知系统管理员或者其他应用程序，某个Redis实例出现问题
3. 自动故障转移：如果一个Master不能正常工作，Sentinel启动一个故障转移，把Master的某个Slave提升为新Master，并让其兄弟Slave重新配置为新Master的Slave。此外，使用Redis的客户端可以得到Master变更的通知
4. 配置提供者：可以作为客户端服务发现的源，客户端连接到Sentinel，后者提供某个服务的Master地址，故障转移发生后，Sentinel会报告新的地址

Sentinel是一个分布式的系统，其本身设计为多个Sentinel进程相互协作的运作模式。多个Sentinel进程协作模式的优势：

1. 当多个Sentinel进程一致认为某个Master不可用，则启动故障检测。这可以降低误报（ false positives）的几率
2. 如果部分Sentinel进程不可用，Sentinel作为一个整体仍然能够正常工作，这增强了系统的健壮性

当前版本为Sentinel 2，比起上个版本使用了更强大、简单的预测算法（predict algorithms），作为Redis 2.8+的一部分发布。

启动启用了Sentinel的Redis服务器，有两种方式：

redis-sentinel /path/to/sentinel.conf
# 或者
redis-server /path/to/sentinel.conf --sentinel

提供Sentinel配置文件是必须的，因为配置文件会被用来保存系统的状态，如果不提供配置文件则无法启动。Sentinel默认监听26379端口。

在部署Sentinel之前，你需要知道一些重要的事情：

1. 你需要至少3个Sentinel实例，以确保健壮性
2. 这三个Sentinel相互独立，不会同时发生故障。例如将它们部署在不同的物理服务器上，或者独立的几个虚拟机上
3. Sentinel + Redis的分布式系统，不能保证已经确认的写操作在故障发生后不丢失，这是由于Redis异步复制机制导致的。但是，可以使用更安全的方式部署Sentinel，是数据丢失的窗口更小
4. 客户端必须支持Sentinel，流行的客户端大多支持
5. 注意测试，甚至是在生产环境下
6. Sentinel、Docker或者其它形式的NAT/端口映射机制需要小心的共存。Docker的端口重映射破坏了Sentinel自动发现其它Sentinel、发现Master的Slave列表的能力

最小化的配置示例：

# 指定每个需要监控的Master，为每个Master提供一个唯一性的名称
# 不需要指定Slave，因为可以自动发现。自动发现后，该配置文件会被Sentinel自动更小以反映Slave信息
# 每当故障转移发生的时候，该配置文件也会被自动更新

# 第一组Redis实例
# 定义Master组的选项：
# sentinel monitor <master-group-name> <ip> <port> <quorum>
# quorum的含义是，如果认定当前Master不可达，需要几个Sentinel进程同意
# quorum仅仅用于检测故障，要执行故障转移，某个Sentinel进程需要被推举为故障转移的Leader然后被授权执行故障转移
# 推举是由Sentinel进程内部进行的，如果大部分Sentinel同意推举则OK，这显然要求大部分Sentinel进程的相互可达
sentinel monitor mymaster 127.0.0.1 6379 2
# 其它选项的格式都是：
# sentinel <option_name> <master_name> <option_value>
# 至少多少mm不可达，Sentinel才开始考虑目标Master是否宕机
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
# 在新的Master产生后，同时与之重新同步的兄弟Slave的最大数量。数字越低，故障转移消耗的时间越多
# 但是，如果Slave被配置为，继续使用旧数据对外服务，你可能不希望所有兄弟Slave同时重新同步
sentinel parallel-syncs mymaster 1

# 第二组Redis实例
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

所有配置项在运行时，都可以基于

SENTINEL SET

如果处于测试和开发的目的，可以零配置的启动Redis服务器。但是在生产环境下，你通常需要自定义配置。

提供自定义配置，可以编写配置文件redis.conf。该文件由一系列的指令组成，每个指令的格式如下：

keyword argument1 argument2 ... argumentN
# 示例：
slaveof 127.0.0.1 6380
# 如果某个参数包含空格，可以使用引号：
requirepass "hello world"

除了提供配置文件以外，还可以直接从命令行传递配置项：

# 格式与配置文件一样，只是每个配置项都具有 -- 前导标记
./redis-server --port 6380 --slaveof 127.0.0.1 6379

要指定Redis使用的配置文件，可以这样启动服务：

./redis-server /path/to/redis.conf

Redis支持运行时按需修改配置，而不需要重启服务器。Redis提供在运行时读取、写入配置的命令：

CONFIG GET

CONFIG SET

需要注意，CONFIG SET命令对服务器配置的修改不会持久化，因此服务重启后配置信息即丢失。从2.8开始，你可以调用

CONFIG REWRITE

将Redis作为缓存服务使用时，你可以配置：

maxmemory 2mb
maxmemory-policy allkeys-lru

这样，你不需要为键设置过期信息，所有键均会基于LRU算法清除。 

save ""

该工具是Redis提供的命令行接口，它具有两种工作模式：交互式（REPL - 读取、估算、打印循环）、脚本式（命令作为redis-cli的参数提供）。

在交互式环境下，键入clear可以清屏，键入help可以获取帮助，键入exit可以退出交互模式。

# 执行一个命令，把键mycounter的值增加1
redis-cli incr mycounter
# 输出如下，括号内是值的类型：
# (integer) 7

# 强制输出原始数据
redis-cli --raw incr mycounter
# 强制输出易读数据
redis-cli --no-raw mycounter

# 默认情况下，redis-cli链接到本机的6379端口，你可以定制主机、端口
redis-cli -h hostname -p 6390 ping
# PONG

# 默认情况下，redis-cli操控数据库序号0，你可以指定操控的数据库序号：
redis-cli flushall
redis-cli -n 1 incr a  # 操控数据库1

# 从文本中读取foo的值，并写入到Redis
redis-cli -x set foo < fooval.txt
# 从文本中读取一系列redis-cli命令，并交付执行
# cat /tmp/commands.txt | redis-cli
# commands.txt的内容如下：
# set foo 100
# incr foo
# append foo xxx
# get foo
# ...

# 连续执行、延迟执行：每隔100ms执行命令，连续5次
redis-cli -r 5 -i 100 incr foo


# 在交互式环境下，可以使用如下命令连接到其它Redis实例
connect host 6379
# 在连接断开后，CLI会自动尝试重新连接，如果连接失败，会给出提示信息
# 执行下面的命令手工重新连接
ping


# 连续打印Redis的统计信息，例如内存用量
redis-cli --stat


# 扫描整个键空间，来获得最大的键
redis-cli --bigkeys
# 扫描键空间
redis-cli --scan
# 扫描键空间，打印匹配指定正则式的键
redis-cli --scan --pattern '*-11*'


# 持续监控在Redis中执行的命令
redis-cli monitor

# 监控Redis实例的延迟，不停的发送PING命令
redis-cli --latency


# RDB远程备份：在Redis复制模式第一次同步的时候，Master/Slave以RDB文件的形式交换整个数据集
# 你可以通过CLI利用这一特性，实现远程备份
redis-cli --rdb /tmp/dump.rdb    #该命令获取Master的Dump，保存到本地

某些命令是管理性的，甚至能立即清空数据库，这类命令可以重命名，甚至禁用，以防客户端误用：

rename-command FLUSHALL "" 

BITCOUNT key [start end]

SETBIT BS 7 1
SETBIT BS 6 1
SETBIT BS 15 1
GET BS             # "\x03\x01"
BITCOUNT BS 0 0    # 2

BITOP operation destkey key [key ...]

BITPOS key bit [start] [end]

BLPOP listkey [listkey ...] timeout

BRPOPLPUSH source destination timeout

CLIENT KILL [ip:port] [ID client-id] [TYPE normal|master|slave|pubsub] 
            [ADDR ip:port] [SKIPME yes/no]

CLIENT PAUSE timeout

CLIENT REPLY ON|OFF|SKIP

CLUSTER ADDSLOTS slot [slot ...]

CLUSTER ADDSLOTS 1 2 3
# OK
CLUSTER ADDSLOTS 1 2 3
# ERR Slot 1 is already busy

CLUSTER DELSLOTS slot [slot ...]

CLUSTER FAILOVER [FORCE|TAKEOVER]

CLUSTER FORGET node-id

CLUSTER COUNTKEYSINSLOT slo

CLUSTER KEYSLOT key

CLUSTER GETKEYSINSLOT slot count

CLUSTER MEET ip port

CLUSTER REPLICATE node-id

CLUSTER RESET [HARD|SOFT]

CLUSTER SET-CONFIG-EPOCH config-epoch

CLUSTER SETSLOT slot IMPORTING|MIGRATING|STABLE|NODE [node-id]
CLUSTER SETSLOT <slot> MIGRATING <destination-node-id>
CLUSTER SETSLOT <slot> IMPORTING <source-node-id>
CLUSTER SETSLOT <slot> STABLE
CLUSTER SETSLOT <slot> NODE <node-id>  

CLUSTER SLAVES node-id

CONFIG GET parameter

CONFIG SET parameter value

DECRBY key decrement

EVAL script numkeys key [key ...] arg [arg ...]

EXISTS key [key ...]

EXPIRE key seconds

EXPIREAT key timestamp

FLUSHALL [ASYNC]

FLUSHDB [ASYNC]

GEOADD key longitude latitude member [longitude latitude member ...]

GEOHASH key member [member ...]

GEOPOS key member [member ...]

GEODIST key member1 member2 [unit]

GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

GET key

GETBIT key offset

GETRANGE key start end

GETSET key value

HDEL key field [field ...]

HEXISTS key field

HGET key field

HGETALL key

HINCRBY key field increment

HINCRBYFLOAT key field increment

HKEYS key

HLEN key

HMGET key field [field ...] 

HMSET key field value [field value ...]

HSET key field value

HSETNX key field value

HSTRLEN key field

HVALS key

INCR key

INCRBY key increment

INCRBYFLOAT key increment

INFO [section]

KEYS pattern

LINDEX key index

LINSERT key BEFORE|AFTER pivot value

LLEN key

LPOP key

LPUSH key value [value ...]

LPUSHX key value

LRANGE key start stop

LREM key count value

LSET key index value

LTRIM key start stop

MGET key [key ...]

MIGRATE host port key|"" destination-db timeout [COPY] [REPLACE] [KEYS key [key ...]]

MOVE key db

MSET key value [key value ...]

MSETNX key value [key value ...]

OBJECT subcommand [arguments [arguments ...]]

PERSIST key

PEXPIRE key milliseconds

PEXPIREAT key milliseconds-timestamp

PSETEX key milliseconds value

PSUBSCRIBE pattern [pattern ...]

PUBSUB subcommand [argument [argument ...]]

PUBSUB CHANNELS [pattern]

PUBSUB NUMSUB [channel-1 ... channel-N]

PTTL key

PUBLISH channel message

PUNSUBSCRIBE [pattern [pattern ...]]

RENAME key newkey

RENAMENX key newkey

RESTORE key ttl serialized-value [REPLACE]

RPOP key

RPOPLPUSH source destination

RPUSH key value [value ...]

RPUSHX key value

SADD key member [member ...]

SCARD key

SDIFF key [key ...] 

SDIFFSTORE destination key [key ...]

SELECT index

SET key value [EX seconds] [PX milliseconds] [NX|XX]

SETBIT key offset value

SETEX key seconds value

SETNX key value

SETRANGE key offset value

SHUTDOWN [NOSAVE|SAVE]

SINTER key [key ...]

SINTERSTORE destination key [key ...]

SISMEMBER key member

SLAVEOF host port

SLAVEOF NO ONE

SLOWLOG subcommand [argument]

1) 1) (integer) 32                   # 慢查询条目的标识符
   2) (integer) 1611661425           # 命令开始执行时的时间戳                  
   3) (integer) 24959                # 耗时，单位微秒
   4) 1) "PSYNC"                     # 命令及其参数   
      2) "?"                                           
      3) "-1"                                          
   5) "172.29.0.81:38265"            # 客户端的IP和端口                  
   6) ""                             # 通过CLIENT SETNAME设置的客户端名称

SMEMBERS key

SMOVE source destination member

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC|DESC] [ALPHA] [STORE destination]

LIMIT 0 10

SPOP key [count]

SRANDMEMBER key [count]

SREM key member [member ...]

STRLEN key

SUBSCRIBE channel [channel ...]

SUNION key [key ...]

SUNIONSTORE destination key [key ...]

SWAPDB index index

TOUCH key [key ...]

TTL key

TYPE key

UNSUBSCRIBE [channel [channel ...]]

UNLINK key [key ...]

WAIT numslaves timeout

WATCH key [key ...]

ZADD key [NX|XX] [CH] [INCR] score member [score member ...]

ZCARD key

ZCOUNT key min max

ZINCRBY key increment member

ZINTERSTORE destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX]

ZLEXCOUNT key min max

ZRANGE key start stop [WITHSCORES]

ZRANGEBYLEX key min max [LIMIT offset count]

ZADD myindex 0 baaa
ZADD myindex 0 abbb
ZADD myindex 0 aaaa
ZADD myindex 0 bbbb

# 注意，前缀[或者(是必须的，表示包含或者不包含后面的值（开闭区间）
# 取得以a开头的条目
ZRANGEBYLEX myindex [a (b
1) "aaaa"
2) "abbb"

# 特殊符号 + 表示正无穷大， - 则表示负无穷大
ZRANGEBYLEX myindex [b +

ZREVRANGEBYLEX key max min [LIMIT offset count]

ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]

ZRANK key member

ZREM key member [member ...]

ZREMRANGEBYLEX key min max

ZREMRANGEBYRANK key start stop

ZREMRANGEBYSCORE key min max

ZREVRANGE key start stop [WITHSCORES]

ZREVRANGEBYSCORE key max min [WITHSCORES] [LIMIT offset count]

ZREVRANK key member

ZSCORE key member

ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX]

SCAN cursor [MATCH pattern] [COUNT count]

redis 127.0.0.1:6379> scan 0
1) "6"
2)  1) "key:12"
    2) "key:8"
    3) "key:4"

redis 127.0.0.1:6379> scan 6
1) "0"
2) 1) "key:5"
   2) "key:18"

# 在这个例子中，第一次迭代调用以0为游标，服务器返回6。下一次调用客户端需要传递6
# 在第二次迭代调用后，服务器返回0，表示没有更多的元素可以迭代

# 从0开始迭代，一直调用SCAN直到服务器返回0的迭代过程，称为完全迭代（full iteration）

redis 127.0.0.1:6379> scan 0 MATCH *11*
1) "288"
2) 1) "key:911"
redis 127.0.0.1:6379> scan 228 MATCH *11*
1) "176"
2) (empty list or set)
redis 127.0.0.1:6379> scan 176 MATCH *11* COUNT 1000  # 增大了count提示
1) "0"
2)  1) "key:611"
    2) "key:711"

这是一个非常轻量易用的Java客户端，完全兼容Redis 2.8.x和3.x.x。

Maven依赖：

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
    <type>jar</type>
    <scope>compile</scope>
</dependency> 

简单的客户端代码：

Jedis jedis = new Jedis( "localhost", 6379 );
final String HELLO_KEY = "Hello";
final String NUMS_KEY = "Numbers";

jedis.set( HELLO_KEY, "World" );
jedis.get( HELLO_KEY );
jedis.lpush( NUMS_KEY, "1", "2", "3" );
jedis.lpop( NUMS_KEY );
// 使用Redis事务
Transaction multi = jedis.multi();
jedis.set( HELLO_KEY, "Alex" );
jedis.expire( HELLO_KEY, 10 );
multi.exec();

jedis.close();

使用连接池：

JedisPoolConfig cfg = new JedisPoolConfig();
cfg.setMaxTotal( 100 );
JedisPool pool = new JedisPool( cfg, "localhost", 6379 );
Jedis jedis = pool.getResource();
jedis.auth( "foobared" );
jedis.set( "foo", "0" );
jedis.close();

jedis = pool.getResource();
jedis.auth( "foobared" );
jedis.incr( "foo" );

jedis.close();
pool.destroy();

定义RestTemplate：

@Bean
JedisConnectionFactory jedisConnectionFactory() {
    JedisConnectionFactory jcf = new JedisConnectionFactory();
    jcf.setHostName( "10.4.37.22" );
    jcf.setPort( 6079 );
    jcf.setDatabase( 0 );
    jcf.setUsePool( true );
    JedisPoolConfig cfg = new JedisPoolConfig();
    cfg.setMaxTotal( 256 );
    cfg.setMaxIdle( 16 );
    jcf.setPoolConfig( cfg );
    return jcf;
}

@Bean
public RedisTemplate<String, Object> redisTemplateNoCompress() {
    final RedisTemplate<String, Object> template = new RedisTemplate<String, Object>();
    template.setConnectionFactory( jedisConnectionFactory() );
    template.setValueSerializer( new GenericToStringSerializer<Object>( Object.class ) );
    return template;
}

使用RestTemplate： 

// SET/GET操作
ValueOperations<String, Object> ops = template.opsForValue();
ops.set( key, value );
ops.get( key );

定制串行化器，示例：

package com.dangdang.digital.spring.data.redis;

import net.jpountz.lz4.LZ4Compressor;
import net.jpountz.lz4.LZ4Factory;
import net.jpountz.lz4.LZ4FastDecompressor;
import org.springframework.data.redis.serializer.RedisSerializer;
import org.springframework.data.redis.serializer.SerializationException;

import java.nio.ByteBuffer;
import java.util.Arrays;

/**
 * 基于LZ4算法的RedisSerializer装饰器
 *
 * @param <T> 串行化处理的目标类型
 */
public class LZ4RedisSerializeDecorator<T> implements RedisSerializer<T> {

    private final int compressThreshold;

    private final RedisSerializer<T> serializer;

    private LZ4Factory factory;

    private LZ4Compressor compressor;

    private LZ4FastDecompressor decompressor;

    private static final int COMPRESS_HEAD_SIZE = Integer.SIZE / Byte.SIZE;

    private static final int NOCOMPRESS_HEAD_SIZE = 1;

    /**
     * 构造函数
     *
     * @param serializer        被装饰的串行化器
     * @param fastMode          是否使用快速模式，快速模式压缩比低但是压缩的速度快
     *                          快速模式不会让解压缩的速度更快
     * @param compressThreshold 启用压缩的最小字节数
     */
    public LZ4RedisSerializeDecorator( RedisSerializer<T> serializer, boolean fastMode, int compressThreshold ) {
        this.serializer = serializer;
        this.compressThreshold = compressThreshold;
        factory = LZ4Factory.fastestInstance();
        if ( fastMode ) {
            compressor = factory.fastCompressor();
        } else {
            compressor = factory.highCompressor();
        }
        decompressor = factory.fastDecompressor();
    }

    public byte[] serialize( T src ) throws SerializationException {
        byte[] srcBytes = serializer.serialize( src );
        int srcLen = srcBytes.length;
        ByteBuffer destBuf;
        if ( srcLen < compressThreshold ) {
            destBuf = ByteBuffer.allocate( NOCOMPRESS_HEAD_SIZE + srcLen );
            destBuf.put( (byte) -1 );
            destBuf.put( srcBytes );
            onSerialize( false, srcLen, srcLen );
            return destBuf.array();
        } else {
            int maxDestLen = compressor.maxCompressedLength( srcLen );
            destBuf = ByteBuffer.allocate( COMPRESS_HEAD_SIZE + maxDestLen );
            destBuf.putInt( srcLen );
            byte[] destArray = destBuf.array();
            int compressedLength = compressor.compress( srcBytes, 0, srcLen, destArray, destBuf.position(), maxDestLen );
            onSerialize( true, srcLen, compressedLength );
            return Arrays.copyOfRange( destArray, 0, COMPRESS_HEAD_SIZE + compressedLength );
        }
    }

    public T deserialize( byte[] src ) throws SerializationException {
        if ( src == null ) return serializer.deserialize( src );
        ByteBuffer srcBuf = ByteBuffer.wrap( src );
        boolean noCompressed = srcBuf.array()[0] < 0;
        if ( noCompressed ) {
            byte[] destBytes = Arrays.copyOfRange( src, 1, src.length );
            return serializer.deserialize( destBytes );
        } else {
            int destLen = srcBuf.getInt();
            byte[] destBytes = new byte[destLen];
            decompressor.decompress( src, srcBuf.position(), destBytes, 0, destLen );
            return serializer.deserialize( destBytes );
        }
    }

    protected void onSerialize( boolean compressed, int srcLen, int compressedLen ) {
    }
}

Lettuce是一个可扩容的、线程安全的Redis客户端，提供同步、异步、响应式（reactive）的API。

在不使用阻塞性、事务性操作 —— 例如BLPOP、MULTI/EXEC ——的情况下，多个Java线程可以共享一个连接。到Redis服务器的连接由netty框架管理。Letttuce支持Sentinel、Cluster等高级特性。

Maven依赖：

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>lettuce</artifactId>
    <version>4.3.1.Final</version>
</dependency>

开启连接： 

// 使用URI连接到本机的Redis实例，使用数据库0
// redis://[password@]host[:port][/databaseNumber]
// 如果是使用SSL的连接，协议部分改为rediss
RedisClient redisClient = RedisClient.create( "redis://passwd@localhost:6379/0" );
// 显式创建连接
StatefulRedisConnection<String, String> connection = redisClient.connect();

资源清理：

// 资源清理
connection.close();
redisClient.shutdown();

通过Sentinel连接：

// redis-sentinel://[password@]host[:port][,host2[:port2]][/databaseNumber]#sentinelMasterId
RedisClient redisClient = RedisClient.create("redis-sentinel://localhost:26379,localhost:26380/0#mymaster");

连接到集群：

// Syntax: redis://[password@]host[:port]
RedisClusterClient redisClient = RedisClusterClient.create("redis://password@localhost:7379");
StatefulRedisClusterConnection<String, String> connection = redisClient.connect();

基于Spring：

<bean id="RedisClient" class="com.lambdaworks.redis.support.RedisClientFactoryBean">
    <property name="uri" value="redis://localhost:6379"/>
</bean>

同步API：

RedisCommands<String, String> syncCommands = connection.sync();
syncCommands.set( "Hello", "World" );

异步API：

RedisAsyncCommands<String, String> asyncCommands = connection.async();
RedisFuture<String> future = asyncCommands.get( "Hello" );
String value = future.get( 1, TimeUnit.MINUTES );

响应式API：

RedisStringReactiveCommands<String, String> reactiveCommands = connection.reactive();
reactiveCommands.get( "Hello" ).subscribe( new Action1<String>() {
    public void call( String value ) {
        System.out.println( value );
    }
} );

首先需要安装包：

sudo pip install redis

代码示例：

import redis

if __name__ == '__main__':
    client = redis.StrictRedis(host='localhost', port=6379, db=0, password='passwd', encoding='utf-8')
    client.set('Hello', '世界')
    print(client.get('Hello').decode())

    # 管道，在一个请求中发送多个命令给服务区
    pipeline = client.pipeline()
    pipeline.set('Name', 'Alex')
    pipeline.get('Name')
    # 批量执行命令，返回结果的列表
    # transaction默认为true，能确保命令被原子的执行
    resp = pipeline.execute(transaction=True)
    print(resp)  # [True, b'Alex']

下面是搭配Calico CNI的Redis集群样例。

配置文件内容：

port 6379
cluster-enabled yes
cluster-require-full-coverage no
cluster-node-timeout 5000
cluster-config-file nodes.conf
cluster-migration-barrier 1
appendonly yes
dir /data

创建ConfigMap：

kubectl -n dev create configmap redis-cluster-conf --from-file=redis.conf

模板如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-cluster-8-pvc
  namespace: dev
spec:
  storageClassName: rook-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 256Mi

---

apiVersion: v1
kind: Pod
metadata:
  namespace: dev
  name: redis-cluster-8
  labels:
    app: redis-cluster
  annotations:
    "cni.projectcalico.org/ipAddrs": "[\"172.27.0.18\"]"
spec:
  terminationGracePeriodSeconds: 10
  containers:
  - name: redis
    image: docker.gmem.cc/redis-cluster
    ports:
    - containerPort: 6379
      name: client
    - containerPort: 16379
      name: gossip
    command:
    - /usr/local/bin/redis-server
    args:
    - /usr/local/etc/redis/redis.conf
    readinessProbe:
      exec:
        command:
        - sh
        - -c
        - "/usr/local/bin/redis-cli -h $(hostname) ping"
      initialDelaySeconds: 15
      timeoutSeconds: 5
    livenessProbe:
      exec:
        command:
        - sh
        - -c
        - "redis-cli -h $(hostname) ping"
      initialDelaySeconds: 20
      periodSeconds: 3
    resources:
      limits:
        cpu: 100m
        memory: 256Mi
    volumeMounts:
      - name: redis-cluster-conf-volume
        mountPath: /usr/local/etc/redis
      - name: redis-cluster-8-pv
        mountPath: /data
  volumes:
    - name: redis-cluster-conf-volume
      configMap:
        name: redis-cluster-conf
    - name: redis-cluster-8-pv
      persistentVolumeClaim:
        claimName: redis-cluster-8-pvc

执行下面的命令创建集群：

./redis-trib.rb create --replicas 1 172.27.0.10:6379 172.27.0.11:6379 172.27.0.12:6379 \
    172.27.0.13:6379 172.27.0.14:6379 172.27.0.15:6379 172.27.0.16:6379 172.27.0.17:6379 \
    172.27.0.18:6379 172.27.0.19:6379

# >>> Creating cluster                                                                                                                                                                
# >>> Performing hash slots allocation on 10 nodes...                                                                                                                                 
# Using 5 masters:                                                                                                                                                                    
# 172.27.0.10:6379                                                                                                                                                                    
# 172.27.0.11:6379                                                                                                                                                                    
# 172.27.0.12:6379                                                                                                                                                                    
# 172.27.0.13:6379                                                                                                                                                                    
# 172.27.0.14:6379                                                                                                                                                                    
# Adding replica 172.27.0.15:6379 to 172.27.0.10:6379                                                                                                                                 
# Adding replica 172.27.0.16:6379 to 172.27.0.11:6379                                                                                                                                 
# Adding replica 172.27.0.17:6379 to 172.27.0.12:6379                                                                                                                                 
# Adding replica 172.27.0.18:6379 to 172.27.0.13:6379                                                                                                                                 
# Adding replica 172.27.0.19:6379 to 172.27.0.14:6379

根据提示操作，默认前面5个节点作为Master，后面5个作为Slave。

执行如下命令连接到集群节点（Pod）：

kubectl -n dev exec redis-cluster-0 -it bash

运行Redis命令行工具redis-cli，查看集群信息：

# CLUSTER INFO
cluster_state:ok
# 全部Slot已经分配
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:10
# 集群的大小取决于Master
cluster_size:5
cluster_current_epoch:10
cluster_my_epoch:1
cluster_stats_messages_sent:2301
cluster_stats_messages_received:2301

1. 实现了Redis Cluster
2. 多种性能提升

1. PSYNC 2.0，增强复制性能，避免不必要的全量复制
2. UNLINK命令，异步删除，提升性能
3. SWAPDB，交换两个数据库
4. 混合持久化，一种新的RDB-AOF混合持久化模式。开启后，AOF重写产生的文件将同时包含RDB格式的内容以及AOF格式的内容。其中RDB格式的部分记录已有数据，AOF则记录最新的增量数据。利用选项aof-use-rdb-preamble开启
5. 集群模式兼容NAT和Docker
6. 支持自动碎片整理activedefrag，相关配置：
   

   # 开启自动内存碎片整理(总开关)
   activedefrag yes
   # 当碎片达到 100mb 时，开启内存碎片整理
   active-defrag-ignore-bytes 100mb
   # 当碎片超过 10% 时，开启内存碎片整理
   active-defrag-threshold-lower 10
   # 内存碎片超过 100%，则尽最大努力整理
   active-defrag-threshold-upper 100
   # 内存自动整理占用资源最小百分比
   active-defrag-cycle-min 25
   # 内存自动整理占用资源最大百分比
   active-defrag-cycle-max 75
    

1.  增加Stream类型，相比起List、Zset等获取元数据更加高效。作为订阅发布模型，比Pub/Sub起来支持：消息持久化、消息分组、ACK等
2. 不再使用redis-trib脚本，直接用redis-cli --cluster来进行集群管理
3. 自动碎片整理V2，配合Jemalloc，更快更智能
4. HyperLogLog算法改进，计数时内存效率更高

1. 引入多线程IO，需要设置

   io-threads-do-reads yes

   以启用。注意： Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行，这意味着不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。参数

   io-threads

   控制IO线程数量，4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数。线程数不是越多越好，一般认为超过8没有意义
2. 支持SSL协议连接
3. 支持对连接进行ACL控制
4. 集群代理。因为 Redis Cluster 内部使用的是P2P中的Gossip协议，每个节点既可以从其他节点得到服务，也可以向其他节点提供服务，没有中心的概念，通过一个节点可以获取到整个集群的所有信息。所以如果应用连接Redis Cluster可以配置一个节点地址，也可以配置多个节点地址。但需要注意如果集群进行了增减节点的的操作，其应用也需要进行修改，这样会导致需要重启应用，非常的不友好。通过使用

   redis-cluster-proxy

   可以与组成Redis集群的一组实例进行通讯，就像是单个实例一样

1. 新增Function自定义函数库，函数库支持持久化与可复制
2. Lua脚本（脚本本身代码）不再支持持久化和复制，仅对命令执行结果进行持久化和复制。
3. ACL支持对Pub/Sub channel的权限控制
4. 支持Multi-Part AOF
5. 支持Client-Eviction
6. 支持Sharded-Pub/Sub
7. 支持命令执行耗时直方图
8. 支持子命令级别的性能统计
9. Ziplist编码替换为Listpack编码
10. 支持Global Replication Buffer

和其它键值存储方案相比，Redis具有以下特点：

在64bit机器上，Redis内存用量大概如下：

1. 实例本身占用 1MB左右内存
2. 100万简短的键 - 字符串值，大概占用100MB内存
3. 100万键 - 哈希值，每个哈希有5个字段，大概占用200MB内存 

你可以使用redis-benchmark来自己测试内存占用。

64bit机器会占用比32位机器更多的内存，特别是键值都比较小的时候，这是因为前者指针长度为8字节。

命令行客户端默认不处理重定向指令，加上 -c 参数即可。

The post Redis学习笔记 appeared first on 绿色记忆.