Twemproxy增加或剔除Redis节点后对数据有何影响

本篇文章，Twemproxy增加或剔除Redis节点后对数据的影响是接着”通过Twemproxy代理Redis数据分片方案“这篇文章写的。最好还要懂一致性哈希（ketama）的原理

下面我们模拟在Redis运行过程中新增一个节点，看一看会丢失Key的比例是多少。至于为什么会丢失Key呢？最简单的理解就是“取模运算”，原先twemproxy是对两个Redis节点对Key做哈希后存储，同样读取数据的时候也是使用同样的算法，同样的节点数做运算，所以可以正确拿到每个Key的值。那么现在新增一个节点后，就成了3个节点对Key做哈希运算了，那么会发生什么情况呢？原先存的Key是对2取模，但是新增一个节点后去取Key时变成了对3取模。那么结果肯定是一大批Key无法找到。当然，上面说的只是很久之前使用的方法，twemproxy使用的是一致性哈希，还是那句话，对于一致性哈希在memcached部分有较为详细的介绍了，有兴趣可以看看。

下面我们就实验看看twemproxy增加或剔除节点后对数据的影响范围比例是多少。twemproxy和redis上一章节就配置好了。

[root@www ~]# ps aux | grep nut root 13266 0.0 17916 2120 ? Sl 16:22 0:00 /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nucracker.pid -o /var/log/nutcracker.log -d [root@www ~]# ps aux | grep redis root 23092 0.0 36560 2300 ? Ssl 12:17 0:14 /usr/local/redis/src/redis-server 0.0.0.0:6547 root 23112 0.0 36560 1580 ? Ssl 12:17 0:15 /usr/local/redis/src/redis-server 0.0.0.0:6546 [root@www ~]# netstat -nplt | grep -E "(22122|6546|6547)" tcp 0 0 0.0.0.0:6546 0.0.0.0:* LISTEN 23112/redis-server tcp 0 0 0.0.0.0:6547 0.0.0.0:* LISTEN 23092/redis-server tcp 0 0 0.0.0.0:22122 0.0.0.0:* LISTEN 13266/nutcracker 

下面我们先批量插入1000个Key，写个测试脚本跑一下。

[root@www ~]# cat set.sh  #!/bin/bash # for i in `seq 1 1000`;do redis-cli -p 22122 set "key$i$i" "value$i" done 

执行脚本，然后分别取6546和6547两台主机上看看Key的分布。

[root@www ~]# redis-cli -p 6546 127.0.0.1:6546> KEYS * ................ 448) "key932932" 449) "key109109" 450) "key131131" 451) "key271271" [root@www ~]# redis-cli -p 6547 127.0.0.1:6547> KEYS * ................. 545) "key245245" 546) "key705705" 547) "key455455" 548) "key126126" 549) "key251251" 

把twemproxy新增一个Redis节点，下面先增加一个Redis节点。

[root@www ~]# cat /data/redis-6548/redis.conf daemonize yes pidfile /var/run/redis/redis-server.pid port 6548 bind 0.0.0.0 loglevel notice logfile /var/log/redis/redis-6548.log 

然后把这个节点（172.16.0.172:6548:1 redis03）加入twemproxy中。

[root@www ~]# cat /etc/twemproxy/conf/nutcracker.yml redis-cluster:  listen: 0.0.0.0:22122  hash: fnv1a_64  distribution: ketama  timeout: 400  backlog: 65535  preconnect: true  redis: true  server_connections: 1  auto_eject_hosts: true  server_retry_timeout: 60000  server_failure_limit: 3  servers:  - 172.16.0.172:6546:1 redis01  - 172.16.0.172:6547:1 redis02  - 172.16.0.172:6548:1 redis03 

重新启动twemproxy和redis。

[root@www ~]# /etc/twemproxy/sbin/nutcracker -c /etc/twemproxy/conf/nutcracker.yml -p /var/run/nucracker.pid -o /var/log/nutcracker.log -d [root@www ~]# /usr/local/redis/src/redis-server /data/redis-6548/redis.conf 

做完这些之后，就可以直接去读取数据了，看看我们插入的1000个Key还能正确读到多少个。下面我们提供一个读取小脚本。

[root@www ~]# cat get.sh  #!/bin/bash # for i in `seq 1 1000`;do redis-cli -p 22122 get "key$i$i" done 

然后执行脚本，并统计一下能查询到值得Key有多少个。

[root@www ~]# bash get.sh | grep "value" | wc -l 647 

通过结果，我们可以看出，当Redis为2个节点时，我们插入1000个Key，然后新增一个节点后只读取到了647个Key，近似值3/1。如果你了解一致性哈希算法的原理的话，就应该会知道，丢失Key的比例就是新增节点数占总节点数（原有节点+新增节点）的比例。比如原来有8个节点，新增2个节点，丢失Key的比例就是2/10。当然这个只是简单的数据测试。

欢迎工作一到五年的Java工程师朋友们加入Java架构师：697558955

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！