Twemproxy增長或剔除Redis節點後對數據有何影響

本篇文章，Twemproxy增長或剔除Redis節點後對數據的影響是接着」經過Twemproxy代理Redis數據分片方案「這篇文章寫的。最好還要懂一致性哈希（ketama）的原理。

上一篇文章中，咱們配置了一個twemproxy節點，後面跟着兩個Redis節點作的簡單測試。下面咱們模擬在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。固然這個只是簡單的數據測試。