Fork me on GitHub

Redis分布式搭建

字数统计: 10.2k字   |   阅读时长≈ 44分

TWEMPROXY

基础环境

mkdir /root/soft/twemproxy

cd /root/soft/twemproxy

yum install git

yum update nss

git clone https://github.com/twitter/twemproxy.git

cd twemproxy

yum install automake libtool -y

autoreconf -fvi

发现版本低

yum search autoconf //查看版本

去mirrors.aliyun.com

找到epel 看帮助

1
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo

cd /etc/yum.repos.d/

yum clean all

yum search autoconf

yum install autoconf268

autoreconf268 -fvi

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
./configure [--enable-debug=full可以没有]
make
src/nutcracker -h---手动启动

cd scripts/
cp nutcracker.init /etc/init.d/twemproxy

chomd +x twemproxy

vi twemproxy

根据配置文件OPTIONS="-d -c /etc/nutcracker/nutcracker.yml"
需要mkdir /etc/nutcracker

cd /root/soft/twemproxy/twemproxy/conf
cp ./* /etc/nutcracker/
cd /root/soft/twemproxy/twemproxy/src
cp nutcracker /usr/bin--让命令加入到path

去修改配置文件
cd /etc/nutcracker
cp nutcracker.yml nutcracker.yml.bak--先保留一个副本
vi nutcracker.yml

redis-server --port 6379 --protected-mode no
redis-server --port 6380 --protected-mode no
service twemproxy start

[root@datanode15 ~]# redis-cli -h 192.168.47.16 -p 22121
192.168.47.16:22121> set k1 aaaaaa
OK
192.168.47.16:22121> get k1
"aaaaaa"
这样代理就只需要连代理了


[root@datanode15 ~]# redis-cli 
127.0.0.1:6379> keys * ---6379的并没有数据
(empty list or set)

[root@datanode15 ~]# redis-cli -p 6380
127.0.0.1:6380> keys *
1) "k1"----反现代理层把数据操作传给了6380

----继续--使用代理层
192.168.47.16:22121> set abc dddd
OK
192.168.47.16:22121> get abc
"dddd"

---此时发现6379有数据，说明代理层给6379server发指令了
127.0.0.1:6379> keys *
1) "abc"



---缺点---》
用代理层使用
keys * 直接报错，因为数据分治了
192.168.47.16:22121> keys *
Error: Server closed the connection

----不支持--WATCH --也就是不支持事务
192.168.47.16:22121> WATCH abc
Error: Server closed the connection

192.168.47.16:22121> MULTI
Error: Server closed the connection






配置文件
listen：-->此服务器池的侦听地址和端口（名称：端口或ip：端口）或sock文件的绝对路径（例如/var/run/nutcracker.sock）。

client_connections：-->redis客户端允许的最大连接数。默认情况下不受限制，尽管操作系统施加的限制仍然适用。
hash：哈希函数的名称。可能的值为：
one_at_a_time
md5
crc16
crc32（与libmemcached兼容的crc32实现）
crc32a（根据规范正确的crc32实现）
fnv1_64
fnv1a_64
fnv1_32
fnv1a_32
hsieh
murmur
jenkins

hash_tag：两个字符串，指定用于散列的密钥部分。例如“ {}”或“ $$”。哈希标签允许将不同的密钥映射到同一服务器，只要标签中的密钥部分相同即可。

distribution：密钥分发模式。可能的值为：
ketama--》一致性hash算法
modula--->hash加取模
random----》随机算法，用于消息队列

timeout：twemproxy等待建立到服务器的连接或从服务器接收响应的超时值（以毫秒为单位）。默认情况下，我们无限期等待。

backlog：TCP backlog参数。默认值为512。缓存日志

preconnect：一个布尔值，它控制twemproxy是否应在进程启动时预连接到该池中的所有服务器。默认为false。

redis：一个布尔值，它控制服务器池是否使用redis或memcached协议。默认为false。

redis_auth：在连接时向Redis服务器进行身份验证。填redis服务器密码

redis_db：池服务器上要使用的数据库号。默认值为0。注意：Twemproxy始终将自己作为DB 0呈现给客户端。

server_connections：每个服务器可以打开的最大连接数。默认情况下，我们最多打开1个服务器连接。就是twemproxy与每一个redis实例最多建立一条socket连接

auto_eject_hosts：一个布尔值，控制当服务器连续失败server_failure_limit次时是否应暂时退出服务器。有关信息，请参见活动建议。默认为false。

server_retry_timeout：当auto_eject_host设置为true时，在临时弹出的服务器上重试之前等待的超时值（以毫秒为单位）。默认为30000毫秒

server_failure_limit：当auto_eject_host设置为true时，服务器上导致其暂时退出的连续失败次数。默认为2。

servers: 此服务器池的 服务器地址，端口和权重（name:port:weight or ip:port:weight）的列表。




----option
Options:
  -h, --help     
  -V, --version          : 显示版本和退出
  -t, --test-conf        : 测试配置语法错误并退出
  -d, --daemonize        : 作为守护进程运行
  -D, --describe-stats   : 打印统计描述和退出
  -v, --verbose=N        : 设置日志级别(默认值:5 min:0,max:11)
  -o, --output=S         : 设置的日志文件(默认值:stderr)
  -c, --conf-file=S      : 设置配置文件(默认值:conf/nutcracker.yml) 
  -s, --stats-port=N     : 设置数据监控端口(默认:22222)
  -a, --stats-addr=S     : 设置数据监视ip(默认值:0.0.0.0)
  -i, --stats-interval=N : 设置数据汇总时间间隔在毫秒(默认:30000毫秒)
  -p, --pid-file=S       : 设定pid文件(默认值: off)
  -m, --mbuf-size=N      : 设置mbuf块的大小(以字节为单位(默认值:16384字节)

nutcracker.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

alpha:
  listen: 192.168.47.16:22121
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  redis: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - 192.168.47.15:6379:1
   - 192.168.47.15:6380:1

【127.0.0.1--ip
6379--port
1--weight】

------后面可以不要-----
beta:
  listen: 127.0.0.1:22122
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: false
  timeout: 400
  redis: true---为false可以代理memcache
  servers:
   - 127.0.0.1:6380:1 server1
   - 127.0.0.1:6381:1 server2
   - 127.0.0.1:6382:1 server3
   - 127.0.0.1:6383:1 server4

gamma:
  listen: 127.0.0.1:22123
  hash: fnv1a_64
  distribution: ketama
  timeout: 400
  backlog: 1024
  preconnect: true
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 3
  servers:
   - 127.0.0.1:11212:1
   - 127.0.0.1:11213:1

delta:
  listen: 127.0.0.1:22124
  hash: fnv1a_64
  distribution: ketama
  timeout: 100
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - 127.0.0.1:11214:1
   - 127.0.0.1:11215:1
   - 127.0.0.1:11216:1
   - 127.0.0.1:11217:1
   - 127.0.0.1:11218:1
   - 127.0.0.1:11219:1
   - 127.0.0.1:11220:1
   - 127.0.0.1:11221:1
   - 127.0.0.1:11222:1
   - 127.0.0.1:11223:1

omega:
  listen: /tmp/gamma
  hash: hsieh
  distribution: ketama
  auto_eject_hosts: false
  servers:
   - 127.0.0.1:11214:100000
   - 127.0.0.1:11215:1

twemproxy启动脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
#! /bin/sh
#
# chkconfig: - 55 45
# description:  Twitter's twemproxy nutcracker
# processname: nutcracker
# config: /etc/sysconfig/nutcracker

# Source function library.
. /etc/rc.d/init.d/functions

USER="nobody"
OPTIONS="-d -c /etc/nutcracker/nutcracker.yml"

if [ -f /etc/sysconfig/nutcracker ];then
    . /etc/sysconfig/nutcracker
fi

# Check that networking is up.
if [ "$NETWORKING" = "no" ]
then
    exit 0
fi

RETVAL=0
prog="nutcracker"

start () {
    echo -n $"Starting $prog: "
    #Test the config before start.
    daemon --user ${USER} ${prog} $OPTIONS -t >/dev/null  2>&1
    RETVAL=$?
    if [ $RETVAL -ne 0 ] ; then
        echo  "Config check fail! Please  use 'nutcracker -c /etc/nutcracker/nutcracker.yml' for detail."
        echo_failure;
        echo;
        exit 1
    fi

    daemon --user ${USER} ${prog} $OPTIONS
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/${prog}
}
stop () {
    echo -n $"Stopping $prog: "
    killproc ${prog}
    RETVAL=$?
    echo
    if [ $RETVAL -eq 0 ] ; then
        rm -f /var/lock/subsys/${prog}
    fi
}

restart () {
    stop
    start
}


# See how we were called.
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
    status ${prog}
    ;;
  restart|reload)
    restart
    ;;
  condrestart)
    [ -f /var/lock/subsys/nutcracker ] && restart || :
    ;;
  *)
    echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
    exit 1
esac

exit $?

cluster

redis自带集群

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255

cd /redis源码目录
cd utils/create-cluster/

cat README

Create-custer is a small script used to easily start a big number of Redis
instances configured to run in cluster mode. 
Create-custer这个小脚本可以很容易启动大数量的redis实例  配置为在集群模式下运行
Its main goal is to allow manual
testing in a condition which is not easy to replicate with the Redis cluster
unit tests, for example when a lot of instances are needed in order to trigger
a given bug.
它的主要目标是允许手工测试条件不容易从节点的redis集群单元测试,例如当很多实例都需要为了触发特定的错误
The tool can also be used just to easily create a number of instances in a
Redis Cluster in order to experiment a bit with the system.
还可以使用该工具来轻松地创建的实例数量的复述,集群以实验与系统
USAGE
---

To create a cluster, follow these steps:

1. Edit create-cluster and change the start / end port, depending on the
number of instances you want to create.
编辑create cluster并根据要创建的实例数更改 起始/结束 端口
2. Use "./create-cluster start" in order to run the instances.
使用“./create cluster start”运行实例
3. Use "./create-cluster create" in order to execute redis-cli --cluster create, so that
an actual Redis cluster will be created.
使用“./create cluster create”来执行redis cli--cluster create，以便创建实际的redis集群
4. Now you are ready to play with the cluster. AOF files and logs for each instances are created in the current directory.
现在您可以使用集群了。每个实例的aof文件和日志都在当前目录中创建
In order to stop a cluster:

1. Use "./create-cluster stop" to stop all the instances. After you stopped the instances you can use "./create-cluster start" to restart them if you change your mind.
使用“./create cluster stop”停止所有实例。停止实例后，如果您改变主意，可以使用“./create cluster start”重新启动它们
2. Use "./create-cluster clean" to remove all the AOF / log files to restart with a clean environment.
使用“./create cluster clean”删除所有aof/log文件，以便在干净的环境中重新启动
Use the command "./create-cluster help" to get the full list of features.
使用“./create cluster help”命令获取功能的完整列表



vi  ./create-cluster 


#!/bin/bash

# Settings
PORT=30000
TIMEOUT=2000
NODES=6  ---总共6个节点
REPLICAS=1---每个主的副本数是1

# You may want to put the above config parameters into config.sh in order to
# override the defaults without modifying this script.

if [ -a config.sh ]
then
    source "config.sh"
fi

# Computed vars
ENDPORT=$((PORT+NODES))

if [ "$1" == "start" ]
then
    while [ $((PORT < ENDPORT)) != "0" ]; do
        PORT=$((PORT+1))
        echo "Starting $PORT"
    done
    exit 0
fi

if [ "$1" == "create" ]
then
    HOSTS=""
    while [ $((PORT < ENDPORT)) != "0" ]; do
        PORT=$((PORT+1))
        HOSTS="$HOSTS 127.0.0.1:$PORT"
    done
    ../../src/redis-cli --cluster create $HOSTS --cluster-replicas $REPLICAS
    exit 0
fi

if [ "$1" == "stop" ]
then
    while [ $((PORT < ENDPORT)) != "0" ]; do
        PORT=$((PORT+1))
        echo "Stopping $PORT"
        ../../src/redis-cli -p $PORT shutdown nosave
    done
    exit 0
fi

if [ "$1" == "watch" ]
then
    PORT=$((PORT+1))
    while [ 1 ]; do
        clear
        date
        ../../src/redis-cli -p $PORT cluster nodes | head -30
        sleep 1
    done
    exit 0
fi

if [ "$1" == "tail" ]
then
    INSTANCE=$2
    PORT=$((PORT+INSTANCE))
    tail -f ${PORT}.log
    exit 0
fi

if [ "$1" == "call" ]
then
    while [ $((PORT < ENDPORT)) != "0" ]; do
        PORT=$((PORT+1))
        ../../src/redis-cli -p $PORT $2 $3 $4 $5 $6 $7 $8 $9
    done
    exit 0
fi

if [ "$1" == "clean" ]
then
    rm -rf *.log
    rm -rf appendonly*.aof
    rm -rf dump*.rdb
    rm -rf nodes*.conf
    exit 0
fi

if [ "$1" == "clean-logs" ]
then
    rm -rf *.log
    exit 0
fi

echo "Usage: $0 [start|create|stop|watch|tail|clean]"
echo "start       -- Launch Redis Cluster instances."
echo "create      -- Create a cluster using redis-cli --cluster create."
echo "stop        -- Stop Redis Cluster instances."
echo "watch       -- Show CLUSTER NODES output (first 30 lines) of first node."
echo "tail <id>   -- Run tail -f of instance at base port + ID."
echo "clean       -- Remove all instances data, logs, configs."
echo "clean-logs  -- Remove just instances logs."



 ./create-cluster  start--启动
 
 
 ./create-cluster  create---分槽位
 
 
 redis-cli -c(cluster) -p 30001

set k1 dsdsa
-->Redirected to slot [12706] located at 127.0.0.1:30003
OK
--->客户端发生的重定向，消息跳转
127.0.0.1 30003>--并且客户端的连接也变了（废话，重定向不就是换一个人连）
这就是  ---路由（重定向|跳转）的模式


同样cluster对于多节点数据事务操作，还是不行的

假如MULTI在30001，EXEC在30003，那么就不可能执行成功

只有在一台机器里执行的事务操作才会有效

Hash  tag

set  {oo}k1  16316
set  {oo}k2  1dsad
set  {oo}k3  dsa
--->这些k都会出现在同一个槽位

WATCH {oo}k1
MULTI
set {oo}k2
get {oo}k3
EXEC
-----执行成功



关闭
./create-cluster  stop
./create-cluster  clean



-----第二中集群的打开方式
./create-cluster  start

redis-cli --cluster help
 create         host1:port1 ... hostN:portN
                 --cluster-replicas <arg>
  check          host:port
                 --cluster-search-multiple-owners
  info           host:port--填参数可以得知集群的消息
  fix            host:port
                 --cluster-search-multiple-owners
  reshard        host:port--》重新分槽位
                 --cluster-from <arg>
                 --cluster-to <arg>
                 --cluster-slots <arg>
                 --cluster-yes
                 --cluster-timeout <arg>
                 --cluster-pipeline <arg>
                 --cluster-replace
  rebalance      host:port--平衡
                 --cluster-weight <node1=w1...nodeN=wN>
                 --cluster-use-empty-masters
                 --cluster-timeout <arg>
                 --cluster-simulate
                 --cluster-pipeline <arg>
                 --cluster-threshold <arg>
                 --cluster-replace
  add-node       new_host:new_port existing_host:existing_port
                 --cluster-slave
                 --cluster-master-id <arg>
  del-node       host:port node_id
  call           host:port command arg arg .. arg
  set-timeout    host:port milliseconds
  import         host:port
                 --cluster-from <arg>
                 --cluster-copy
                 --cluster-replace
  help           

For check, fix, reshard, del-node, set-timeout you can specify the host and port of any working node in the cluster.



redis-cli --cluster create 127.0.0.1:30001 127.0.0.1:30002 127.0.0.1:30003 127.0.0.1:30004 127.0.0.1:30005 127.0.0.1:30006
--cluster-replicas 1

redis-cli --cluster reshard 127.0.0.1:30001

How many slots do you want to move ? 2000 ->准备移动多少个槽位
what is the receving node ID?13535dsa--》哪台节点收那些槽位，填个节点id

Source node #1：dfasdsa//从哪个节点移，
Source node #1：done--》如果不需要其他节点参于分槽位，执行done
------all是从所有节点均匀的抽点给收槽位的节点



redis-cli --cluster info 127.0.0.1:30001--》看全局信息


redis-cli --cluster check 127.0.0.1:30001--》看具体一点的信息

搭建并使用Redis集群

搭建集群的第一件事情我们需要一些运行在 集群模式的Redis实例. 这意味这集群并不是由一些普通的Redis实例组成的，集群模式需要通过配置启用，开启集群模式后的Redis实例便可以使用集群特有的命令和特性了.

下面是一个最少选项的集群的配置文件:

1
2
3
4
5
port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf.节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下:

1
2
3
mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的端口号从 7000 改为与文件夹名字相同的号码。

从 Redis Github 页面 的 unstable 分支中取出最新的 Redis 源码， 编译出可执行文件 redis-server ， 并将文件复制到 cluster-test 文件夹， 然后使用类似以下命令， 在每个标签页中打开一个实例：

1
2
cd 7000
../redis-server ./redis.conf

实例打印的日志显示， 因为 nodes.conf 文件不存在， 所以每个节点都为它自身指定了一个新的 ID ：

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

实例会一直使用同一个 ID ， 从而在集群中保持一个独一无二（unique）的名字。

搭建集群

现在我们已经有了六个正在运行中的 Redis 实例， 接下来我们需要使用这些实例来创建集群， 并为每个节点编写配置文件。

通过使用 Redis 集群命令行工具 redis-trib ， 编写节点配置文件的工作可以非常容易地完成： redis-trib 位于 Redis 源码的 src 文件夹中， 它是一个 Ruby 程序， 这个程序通过向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片（reshared）等工作。

1
2
./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

这个命令在这里用于创建一个新的集群, 选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

之后跟着的其他参数则是这个集群实例的地址列表,3个master3个slave redis-trib 会打印出一份预想中的配置给你看， 如果你觉得没问题的话， 就可以输入 yes ， redis-trib 就会将这份配置应用到集群当中,让各个节点开始互相通讯,最后可以得到如下信息：

1
[OK] All 16384 slots covered

这表示集群中的 16384 个槽都有至少一个主节点在处理， 集群运作正常。

使用create-cluster脚本创建一个redis集群

If you don’t want to create a Redis Cluster by configuring and executing individual instances manually as explained above, there is a much simpler system (but you’ll not learn the same amount of operational details).

如果你不希望创建一个Redis集群 手动通过配置和执行单个实例如上所述,有一个更简单的系统(但你不会学习相同数量的操作细节)

Just check utils/create-cluster directory in the Redis distribution.

在redis源目录会有utils/create-cluster这一个目录

There is a script called create-cluster inside (same name as the directory it is contained into), it’s a simple bash script. In order to start a 6 nodes cluster with 3 masters and 3 slaves just type the following commands:

有一个脚本叫做create-cluster，与内部名称相同(目录包含到),这是一个简单的bash脚本。以开始6节点3主从集群输入以下命令:

  1. create-cluster start
  2. create-cluster create

Reply to yes in step 2 when the redis-trib utility wants you to accept the cluster layout.

在步骤2中当redis-trib效用要你接受集群布局

You can now interact with the cluster, the first node will start at port 30001 by default. When you are done, stop the cluster with:
你现在可以与集群交互,第一个节点将从默认端口30001。当你完成,停止集群

  1. create-cluster stop.

Please read the README inside this directory for more information on how to run the script.

有关更多信息,请阅读README在这个目录如何运行该脚本

使用集群

Redis 集群现阶段的一个问题是客户端实现很少。

以下是一些我知道的实现：

  • redis-rb-cluster 是我（@antirez）编写的 Ruby 实现， 用于作为其他实现的参考。 该实现是对 redis-rb 的一个简单包装， 高效地实现了与集群进行通讯所需的最少语义（semantic）.
  • redis-py-cluster 看上去是 redis-rb-cluster 的一个 Python 版本， 这个项目有一段时间没有更新了（最后一次提交是在六个月之前）， 不过可以将这个项目用作学习集群的起点。
  • 流行的 Predis 曾经对早期的 Redis 集群有过一定的支持， 但我不确定它对集群的支持是否完整， 也不清楚它是否和最新版本的 Redis 集群兼容 （因为新版的 Redis 集群将槽的数量从 4k 改为 16k 了）.
  • 使用最多的时java客户端, Jedis 最近添加了对集群的支持, 详细请查看项目README中Jedis Cluster部分.
  • StackExchange.Redis 提供对 C# 的支持(并且包括大部分 .NET 下面的语言，比如： VB, F#等等)
  • thunk-redis 提供对 Node.js 和 io.js的支持。
  • Redis unstable 分支中的 redis-cli 程序实现了非常基本的集群支持， 可以使用命令 redis-cli -c 来启动。

测试 Redis 集群比较简单的办法就是使用 redis-rb-cluster 或者 redis-cli ， 接下来我们将使用 redis-cli 为例来进行演示：

1
2
3
4
5
6
7
8
9
10
11
12
13
$ redis-cli -c -p 7000
redis 127.0.0.1:7000> set foo bar
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK
redis 127.0.0.1:7002> set hello world
-> Redirected to slot [866] located at 127.0.0.1:7000
OK
redis 127.0.0.1:7000> get foo
-> Redirected to slot [12182] located at 127.0.0.1:7002
"bar"
redis 127.0.0.1:7000> get hello
-> Redirected to slot [866] located at 127.0.0.1:7000
"world"

注意: 如果你是使用脚本创建的集群节点，那么默认端口可能是从30001开始。

redis-cli 对集群的支持是非常基本的， 所以它总是依靠 Redis 集群节点来将它转向（redirect）至正确的节点。一个真正的（serious）集群客户端应该做得比这更好： 它应该用缓存记录起哈希槽与节点地址之间的映射（map）， 从而直接将命令发送到正确的节点上面。这种映射只会在集群的配置出现某些修改时变化， 比如说， 在一次故障转移（failover）之后， 或者系统管理员通过添加节点或移除节点来修改了集群的布局（layout）之后， 诸如此类。

使用redis-rb-cluster写一个例子

在展示如何使用集群进行故障转移、重新分片等操作之前， 我们需要创建一个示例应用， 了解一些与 Redis 集群客户端进行交互的基本方法。

在运行示例应用的过程中， 我们会尝试让节点进入失效状态， 又或者开始一次重新分片， 以此来观察 Redis 集群在真实世界运行时的表现， 并且为了让这个示例尽可能地有用， 我们会让这个应用向集群进行写操作。

本节将通过两个示例应用来展示 redis-rb-cluster 的基本用法， 以下是本节的第一个示例应用， 它是一个名为 example.rb 的文件， 包含在redis-rb-cluster 项目里面

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 1  require './cluster'
 2
 3  startup_nodes = [
 4      {:host => "127.0.0.1", :port => 7000},
 5      {:host => "127.0.0.1", :port => 7001}
 6  ]
 7  rc = RedisCluster.new(startup_nodes,32,:timeout => 0.1)
 8
 9  last = false
10
11  while not last
12      begin
13          last = rc.get("__last__")
14          last = 0 if !last
15      rescue => e
16          puts "error #{e.to_s}"
17          sleep 1
18      end
19  end
20
21  ((last.to_i+1)..1000000000).each{|x|
22      begin
23          rc.set("foo#{x}",x)
24          puts rc.get("foo#{x}")
25          rc.set("__last__",x)
26      rescue => e
27          puts "error #{e.to_s}"
28      end
29      sleep 0.1
30  }

这个应用所做的工作非常简单： 它不断地以 foo<number> 为键， number 为值， 使用 SET 命令向数据库设置键值对:

  • SET foo0 0
  • SET foo1 1
  • SET foo2 2
  • And so forth…

代码中的每个集群操作都使用一个 begin 和 rescue 代码块（block）包裹着， 因为我们希望在代码出错时， 将错误打印到终端上面， 而不希望应用因为异常（exception）而退出。

代码的第七行是代码中第一个有趣的地方， 它创建了一个 Redis 集群对象， 其中创建对象所使用的参数及其意义如下：第一个参数是记录了启动节点的 startup_nodes 列表， 列表中包含了两个集群节点的地址。第二个参数指定了对于集群中的各个不同的节点， Redis 集群对象可以获得的最大连接数 ，第三个参数 timeout 指定了一个命令在执行多久之后， 才会被看作是执行失败。

启动列表中并不需要包含所有集群节点的地址， 但这些地址中至少要有一个是有效的： 一旦 redis-rb-cluster 成功连接上集群中的某个节点时， 集群节点列表就会被自动更新， 任何真正的的集群客户端都应该这样做。

现在， 程序创建的 Redis 集群对象实例被保存到 rc 变量里面， 我们可以将这个对象当作普通 Redis 对象实例来使用。

在十一至十九行， 我们先尝试阅读计数器中的值， 如果计数器不存在的话， 我们才将计数器初始化为 0 ： 通过将计数值保存到 Redis 的计数器里面， 我们可以在示例重启之后， 仍然继续之前的执行过程， 而不必每次重启之后都从 foo0 开始重新设置键值对。为了让程序在集群下线的情况下， 仍然不断地尝试读取计数器的值， 我们将读取操作包含在了一个 while 循环里面， 一般的应用程序并不需要如此小心。

二十一至三十行是程序的主循环， 这个循环负责设置键值对， 并在设置出错时打印错误信息。程序在主循环的末尾添加了一个 sleep 调用， 让写操作的执行速度变慢， 帮助执行示例的人更容易看清程序的输出。执行 example.rb 程序将产生以下输出：

1
2
3
4
5
6
7
8
9
10
11
ruby ./example.rb
1
2
3
4
5
6
7
8
9
^C (I stopped the program here)

这个程序并不是十分有趣， 稍后我们就会看到一个更有趣的集群应用示例， 不过在此之前， 让我们先使用这个示例来演示集群的重新分片操作。

集群重新分片

现在， 让我们来试试对集群进行重新分片操作。在执行重新分片的过程中， 请让你的 example.rb 程序处于运行状态， 这样你就会看到， 重新分片并不会对正在运行的集群程序产生任何影响， 你也可以考虑将 example.rb 中的 sleep 调用删掉， 从而让重新分片操作在近乎真实的写负载下执行 重新分片操作基本上就是将某些节点上的哈希槽移动到另外一些节点上面， 和创建集群一样， 重新分片也可以使用 redis-trib 程序来执行 执行以下命令可以开始一次重新分片操作：

1
./redis-trib.rb reshard 127.0.0.1:7000

你只需要指定集群中其中一个节点的地址， redis-trib 就会自动找到集群中的其他节点。

目前 redis-trib 只能在管理员的协助下完成重新分片的工作， 要让 redis-trib 自动将哈希槽从一个节点移动到另一个节点， 目前来说还做不到

1
你想移动多少个槽( 从1 到 16384)?

我们尝试从将100个槽重新分片， 如果 example.rb 程序一直运行着的话， 现在 1000 个槽里面应该有不少键了。

除了移动的哈希槽数量之外， redis-trib 还需要知道重新分片的目标， 也即是， 负责接收这 1000 个哈希槽的节点。

1
2
$ redis-cli -p 7000 cluster nodes | grep myself
97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5460

我的目标节点是 97a3a64667477371c4479320d683e4c8db5858b1.

现在需要指定从哪些节点来移动keys到目标节点 我输入的是all ，这样就会从其他每个master上取一些哈希槽。

最后确认后你将会看到每个redis-trib移动的槽的信息，每个key的移动的信息也会打印出来 在重新分片的过程中，你的例子程序是不会受到影响的,你可以停止或者重新启动多次。

在重新分片结束后你可以通过如下命令检查集群状态:

1
./redis-trib.rb check 127.0.0.1:7000

一个更有趣的程序

我们在前面使用的示例程序 example.rb 并不是十分有趣， 因为它只是不断地对集群进行写入， 但并不检查写入结果是否正确。 比如说， 集群可能会错误地将 example.rb 发送的所有 SET 命令都改成了 SET foo 42 ， 但因为 example.rb 并不检查写入后的值， 所以它不会意识到集群实际上写入的值是错误的 因为这个原因， redis-rb-cluster 项目包含了一个名为 consistency-test.rb 的示例应用， 这个应用比起 example.rb 有趣得多： 它创建了多个计数器（默认为 1000 个）， 并通过发送 INCR 命令来增加这些计数器的值。

在增加计数器值的同时， consistency-test.rb 还执行以下操作： 每次使用 INCR 命令更新一个计数器时， 应用会记录下计数器执行 INCR 命令之后应该有的值。 举个例子， 如果计数器的起始值为 0 ， 而这次是程序第 50 次向它发送 INCR 命令， 那么计数器的值应该是 50 。

在每次发送 INCR 命令之前， 程序会随机从集群中读取一个计数器的值， 并将它与自己记录的值进行对比， 看两个值是否相同。

换句话说， 这个程序是一个一致性检查器（consistency checker）： 如果集群在执行 INCR 命令的过程中， 丢失了某条 INCR 命令， 又或者多执行了某条客户端没有确认到的 INCR 命令， 那么检查器将察觉到这一点 —— 在前一种情况中， consistency-test.rb 记录的计数器值将比集群记录的计数器值要大； 而在后一种情况中， consistency-test.rb 记录的计数器值将比集群记录的计数器值要小。

运行 consistency-test 程序将产生类似以下的输出：

1
2
3
4
5
6
7
8
$ ruby consistency-test.rb
925 R (0 err) | 925 W (0 err) |
5030 R (0 err) | 5030 W (0 err) |
9261 R (0 err) | 9261 W (0 err) |
13517 R (0 err) | 13517 W (0 err) |
17780 R (0 err) | 17780 W (0 err) |
22025 R (0 err) | 22025 W (0 err) |
25818 R (0 err) | 25818 W (0 err) |

结果展示了执行的读和 写,和错误(由于系统不可用而没有接受的查询发生的错误）的数量.

如果程序察觉了不一致的情况出现， 它将在输出行的末尾显式不一致的详细情况。比如说， 如果我们在 consistency-test.rb 运行的过程中， 手动修改某个计数器的值：

1
2
3
4
5
6
7
8
9
$ redis 127.0.0.1:7000> set key_217 0
OK

(in the other tab I see...)

94774 R (0 err) | 94774 W (0 err) |
98821 R (0 err) | 98821 W (0 err) |
102886 R (0 err) | 102886 W (0 err) | 114 lost |
107046 R (0 err) | 107046 W (0 err) | 114 lost |

在我们修改计数器值的时候， 计数器的正确值是 114 （执行了 114 次 INCR 命令）， 因为我们将计数器的值设成了 0 ， 所以 consistency-test.rb 会向我们报告说丢失了 114 个 INCR 命令。

这个程序作为测试程序很有意思，所以我们用这个程序来测试故障恢复.

测试故障转移

在执行本节操作的过程中， 请一直运行 consistency-test 程序。 要触发一次故障转移， 最简单的办法就是令集群中的某个主节点进入下线状态。首先用以下命令列出集群中的所有主节点：

1
2
3
4
$ redis-cli -p 7000 cluster nodes | grep master
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385482984082 0 connected 5960-10921
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 master - 0 1385482983582 0 connected 11423-16383
97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422

通过命令输出得知端口号为 7000 、 7001 和 7002 的节点都是主节点， 然后我们可以通过向端口号为7002 的主节点发送 DEBUG SEGFAULT 命令， 让这个主节点崩溃：

1
2
$ redis-cli -p 7002 debug segfault
Error: Server closed the connection

现在，切换到运行着 consistency-test 的标签页， 可以看到， consistency-test 在 7002 下线之后的一段时间里将产生大量的错误警告信息：

1
2
3
4
5
6
7
8
9
10
18849 R (0 err) | 18849 W (0 err) |
23151 R (0 err) | 23151 W (0 err) |
27302 R (0 err) | 27302 W (0 err) |

... many error warnings here ...

29659 R (578 err) | 29660 W (577 err) |
33749 R (578 err) | 33750 W (577 err) |
37918 R (578 err) | 37919 W (577 err) |
42077 R (578 err) | 42078 W (577 err) |

从 consistency-test 的这段输出可以看到， 集群在执行故障转移期间， 总共丢失了 578 个读命令和 577 个写命令， 但是并没有产生任何数据不一致。这听上去可能有点奇怪， 因为在教程的开头我们提到过， Redis 使用的是异步复制， 在执行故障转移期间， 集群可能会丢失写命令。但是在实际上， 丢失命令的情况并不常见， 因为 Redis 几乎是同时执行将命令回复发送给客户端， 以及将命令复制给从节点这两个操作， 所以实际上造成命令丢失的时间窗口是非常小的。不过， 尽管出现的几率不高， 但丢失命令的情况还是有可能会出现的， 所以我们对 Redis 集群不能提供强一致性的这一描述仍然是正确的。现在， 让我们使用 cluster nodes 命令,查看集群在执行故障转移操作之后， 主从节点的布局情况：

1
2
3
4
5
6
7
$ redis-cli -p 7000 cluster nodes
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385503418521 0 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385503419023 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385503419023 3 connected 11423-16383
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385503417005 0 connected 5960-10921
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385503418016 3 connected

现在masters运行在 7000, 7001 和 7005端口上. 原来的master 7002现在变成了一个7005的一个从节点.

CLUSTER NODES 命令的输出看起来有点复杂,其实他非常的简单，含义如下:

  • 节点ID
  • IP:端口
  • 标志: master, slave, myself, fail, …
  • 如果是个从节点, 这里是它的主节点的NODE ID
  • 集群最近一次向节点发送 PING 命令之后， 过去了多长时间还没接到回复。.
  • 节点最近一次返回 PONG 回复的时间。
  • 节点的配置纪元（configuration epoch）：详细信息请参考 Redis 集群规范 。
  • 本节点的网络连接情况：例如 connected 。
  • 节点目前包含的槽：例如 127.0.0.1:7001 目前包含号码为 5960 至 10921 的哈希槽。

手动故障转移

有的时候在主节点没有任何问题的情况下强制手动故障转移也是很有必要的，比如想要升级主节点的Redis进程，我们可以通过故障转移将其转为slave再进行升级操作来避免对集群的可用性造成很大的影响。

Redis集群使用 CLUSTER FAILOVER命令来进行故障转移，不过要被转移的主节点的从节点上执行该命令 手动故障转移比主节点失败自动故障转移更加安全，因为手动故障转移时客户端的切换是在确保新的主节点完全复制了失败的旧的主节点数据的前提下下发生的，所以避免了数据的丢失。

执行手动故障转移时从节点日志如下:

1
2
3
4
5
6
# Manual failover user request accepted.
# Received replication offset for paused master manual failover: 347540
# All master replication stream processed, manual failover can start.
# Start of election delayed for 0 milliseconds (rank #0, offset 347540).
# Starting a failover election for epoch 7545.
# Failover election won: I'm the new master.

其基本过程如下：客户端不再链接我们淘汰的主节点，同时主节点向从节点发送复制偏移量,从节点得到复制偏移量后故障转移开始,接着通知主节点进行配置切换,当客户端在旧的master上解锁后重新连接到新的主节点上。

添加一个新节点

添加新的节点的基本过程就是添加一个空的节点然后移动一些数据给它，有两种情况，添加一个主节点和添加一个从节点（添加从节点时需要将这个新的节点设置为集群中某个节点的复制）

针对这两种情况，本节都会介绍，先从添加主节点开始.

两种情况第一步都是要添加 一个空的节点.

启动新的7006节点,使用的配置文件和以前的一样,只要把端口号改一下即可，过程如下:

  • 在终端打开一个新的标签页.
  • 进入cluster-test 目录.
  • 创建并进入 7006文件夹.
  • 和其他节点一样，创建redis.conf文件,需要将端口号改成7006.
  • 最后启动节点 ../redis-server ./redis.conf
  • 如果正常的话，节点会正确的启动.

接下来使用redis-trib 来添加这个节点到现有的集群中去.

1
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000

可以看到.使用addnode命令来添加节点，第一个参数是新节点的地址，第二个参数是任意一个已经存在的节点的IP和端口. 我们可以看到新的节点已经添加到集群中:

1
2
3
4
5
6
7
8
redis 127.0.0.1:7006> cluster nodes
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385543178575 0 connected 5960-10921
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385543179583 0 connected
f093c80dde814da99c5cf72a7dd01590792b783b :0 myself,master - 0 0 0 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543178072 3 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385543178575 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 127.0.0.1:7000 master - 0 1385543179080 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385543177568 3 connected 11423-16383

新节点现在已经连接上了集群， 成为集群的一份子， 并且可以对客户端的命令请求进行转向了， 但是和其他主节点相比， 新节点还有两点区别：

  • 新节点没有包含任何数据， 因为它没有包含任何哈希槽.
  • 尽管新节点没有包含任何哈希槽， 但它仍然是一个主节点， 所以在集群需要将某个从节点升级为新的主节点时， 这个新节点不会被选中。

接下来， 只要使用 redis-trib 程序， 将集群中的某些哈希桶移动到新节点里面， 新节点就会成为真正的主节点了。

添加一个从节点

有两种方法添加从节点，可以像添加主节点一样使用redis-trib 命令，也可以像下面的例子一样使用 –slave选项:

1
./redis-trib.rb add-node --slave 127.0.0.1:7006 127.0.0.1:7000

此处的命令和添加一个主节点命令类似，此处并没有指定添加的这个从节点的主节点，这种情况下系统会在其他的复制集中的主节点中随机选取一个作为这个从节点的主节点。

你可以通过下面的命令指定主节点:

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

也可以使用CLUSTER REPLICATE 命令添加.这个命令也可以改变一个从节点的主节点。

例如，要给主节点 127.0.0.1:7005添加一个从节点，该节点哈希槽的范围1423-16383, 节点 ID 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e,我们需要链接新的节点（已经是空的主节点）并执行命令:

1
redis 127.0.0.1:7006> cluster replicate 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e

我们新的从节点有了一些哈希槽，其他的节点也知道（过几秒后会更新他们自己的配置），可以使用如下命令确认:

1
2
3
$ redis-cli -p 7000 cluster nodes | grep slave | grep 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e
f093c80dde814da99c5cf72a7dd01590792b783b 127.0.0.1:7006 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617702 3 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617198 3 connected

节点 3c3a0c… 有两个从节点， 7002 (已经存在的) 和 7006 (新添加的).

移除一个节点

只要使用 del-node 命令即可:

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

第一个参数是任意一个节点的地址,第二个节点是你想要移除的节点地址。

使用同样的方法移除主节点,不过在移除主节点前，需要确保这个主节点是空的. 如果不是空的,需要将这个节点的数据重新分片到其他主节点上.

替代移除主节点的方法是手动执行故障恢复，被移除的主节点会作为一个从节点存在，不过这种情况下不会减少集群节点的数量，也需要重新分片数据.

从节点的迁移

在Redis集群中会存在改变一个从节点的主节点的情况，需要执行如下命令 :

1
CLUSTER REPLICATE <master-node-id>

在特定的场景下，不需要系统管理员的协助下，自动将一个从节点从当前的主节点切换到另一个主节 的自动重新配置的过程叫做复制迁移（从节点迁移），从节点的迁移能够提高整个Redis集群的可用性.

你可以阅读（Redis集群规范）/topics/cluster-spec了解细节.

简短的概况一下从节点迁移

  • 集群会在有从节点数量最多的主节点上进行从节点的迁移.
  • 要在一个主节点上添加多个从节点.
  • 参数来控制从节点迁移 replica-migration-barrier:你可以仔细阅读redis.conf 。
赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要涉及技术：
Java后端开发
开源爱好者、Linux

联系QQ:2960571342

很惭愧

只做了一点微小的工作
谢谢大家