企业级nosql数据库应用与实战-redis

4.8.5 对Set操作的命令

　　Set 就是一个集合，集合的概念就是一堆不重复值的组合。利用 Redis 提供的 Set 数据结构，可以存储一些集合性的数据。比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。因为 Redis 非常人性化的为集合提供了求交集、并集、差集等操作，那么就可以非常方便的实现如共同关注、共同喜好、二度好友等功能。
　　具体操作命令如下：

sadd(key, member)：向名称为key的set中添加元素member
srem(key, member)：删除名称为key的set中的元素member
spop(key)：随机返回并删除名称为key的set中一个元素
smove(srckey, dstkey, member)：移到集合元素
scard(key)：返回名称为key的set的基数
sismember(key, member)：member是否是名称为key的set的元素
sinter(key1, key2,…key N)：求交集
sinterstore(dstkey, (keys))：求交集并将交集保存到dstkey的集合
sunion(key1, (keys))：求并集
sunionstore(dstkey, (keys))：求并集并将并集保存到dstkey的集合
sdiff(key1, (keys))：求差集
sdiffstore(dstkey, (keys))：求差集并将差集保存到dstkey的集合
smembers(key)：返回名称为key的set的所有元素
srandmember(key)：随机返回名称为key的set的一个元素

五、redis 主从复制

5.1 方式简介

　　Redis的复制方式有两种，一种是主（master）-从（slave）模式，一种是从（slave）-从（slave）模式，因此Redis的复制拓扑图会丰富一些，可以像星型拓扑，也可以像个有向无环。一个Master可以有多个slave主机，支持链式复制；Master以非阻塞方式同步数据至slave主机；
　　拓扑图如下：

5.2 复制优点

　　通过配置多个Redis实例，数据备份在不同的实例上，主库专注写请求，从库负责读请求，这样的好处主要体现在下面几个方面
1. 高可用性
　　在一个Redis集群中，如果master宕机，slave可以介入并取代master的位置，因此对于整个Redis服务来说不至于提供不了服务，这样使得整个Redis服务足够安全。
2. 高性能
　　在一个Redis集群中，master负责写请求，slave负责读请求，这么做一方面通过将读请求分散到其他机器从而大大减少了master服务器的压力，另一方面slave专注于提供读服务从而提高了响应和读取速度。
3. 水平扩展性
　　通过增加slave机器可以横向（水平）扩展Redis服务的整个查询服务的能力。

5.3 需要解决的问题

　　复制提供了高可用性的解决方案，但同时引入了分布式计算的复杂度问题，认为有两个核心问题：
1. 数据一致性问题： 如何保证master服务器写入的数据能够及时同步到slave机器上。
2. 读写分离： 如何在客户端提供读写分离的实现方案，通过客户端实现将读写请求分别路由到master和slave实例上。
　　上面两个问题，尤其是第一个问题是Redis服务实现一直在演变，致力于解决的一个问题：复制实时性和数据一致性矛盾。

　　Redis提供了提高数据一致性的解决方案，一致性程度的增加虽然使得我能够更信任数据，但是更好的一致性方案通常伴随着性能的损失，从而减少了吞吐量和服务能力。然而我们希望系统的性能达到最优，则必须要牺牲一致性的程度，因此Redis的复制实时性和数据一致性是存在矛盾的。

5.4 具体实例见实战一

六、redis集群cluster

　　如何解决redis横向扩展的问题----redis集群实现方式

6.1 实现基础——分区

　　分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。通过利用多台计算机内存的和值，允许我们构造更大的数据库。通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。
　　集群的几种实现方式：

1. 客户端分片
2. 基于代理的分片
3. 路由查询

6.1.1 客户端分片

　　由客户端决定key写入或者读取的节点。
　　包括jedis在内的一些客户端，实现了客户端分片机制。
优点
　　简单，性能高
缺点
　　1. 业务逻辑与数据存储逻辑耦合
　　2. 可运维性差
　　3. 多业务各自使用redis，集群资源难以管理
　　4. 不支持动态增删节点

6.1.2 基于代理的分片

　　客户端发送请求到一个代理，代理解析客户端的数据，将请求转发至正确的节点，然后将结果回复给客户端。
开源方案
　　1. Twemproxy
　　2. codis
特性
　　1. 透明接入
　　2. 业务程序不用关心后端Redis实例，切换成本低。
　　3. Proxy 的逻辑和存储的逻辑是隔离的。
　　4. 代理层多了一次转发，性能有所损耗。

Twemproxy
　　Proxy-based
　　twtter开源，C语言编写，单线程。
　　支持 Redis 或 Memcached 作为后端存储。
优点：
　　1. 支持失败节点自动删除
　　2. 与redis的长连接，连接复用，连接数可配置
　　3. 自动分片到后端多个redis实例上
　　4. 多种hash算法：能够使用不同的分片策略和散列函数
　　5. 可以设置后端实例的权重
缺点：
　　1. 性能低：代理层损耗 && 本身效率低下
　　2. Redis功能支持不完善：不支持针对多个值的操作
　　3. 本身不提供动态扩容，透明数据迁移等功能

Codis
　　Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。现已广泛用于豌豆荚的各种Redis业务场景。从3个月的各种压力测试来看，稳定性符合高效运维的要求。性能更是改善很多，最初比Twemproxy慢20%；现在比Twemproxy快近100%（条件：多实例，一般Value长度）。

6.2 开源方案——Redis-cluster

　　将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。

　　Redis-cluster由redis官网推出，可线性扩展到1000个节点。无中心架构；使用一致性哈希思想；客户端直连redis服务，免去了proxy代理的损耗。

6.2.1 Redis集群介绍

　　Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
　　Redis 集群并不支持处理多个keys的命令，因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误。
　　Redis 集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下继续处理命令.
Redis 集群的优势:
　　1. 自动分割数据到不同的节点上。
　　2. 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
Redis 集群的数据分片
　　Redis 集群没有使用一致性hash，而是引入了哈希槽的概念.
　　Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽。举个例子,比如当前集群有3个节点,那么:
　　节点 A 包含 0 到 5500号哈希槽。
　　节点 B 包含5501 到 11000 号哈希槽。
　　节点 C 包含11001 到 16384号哈希槽。
　　这种结构很容易添加或者删除节点。比如如果我想新添加个节点D，我需要从节点 A，B，C中得部分槽到D上。如果我想移除节点A，需要将A中得槽移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

6.2.2 Redis 集群的主从复制模型

　　为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品。
　　在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
　　然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了。不过当B和B1 都失败后，集群是不可用的。
Redis 一致性保证
　　Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作。
　　第一个原因是因为集群是用了异步复制. 写操作过程:
　　客户端向主节点B写入一条命令.
　　主节点B向客户端回复命令状态.
　　主节点将写操作复制给他得从节点 B1, B2 和 B3.
　　主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。注意：Redis 集群可能会在将来提供同步写的方法。Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

实战一：redis主从复制的实现

1）原理架构图

　　上图为Redis复制工作过程：

1. slave向master发送sync命令。
2. master开启子进程来讲dataset写入rdb文件，同时将子进程完成之前接收到的写命令缓存起来。
3. 子进程写完，父进程得知，开始将RDB文件发送给slave。master发送完RDB文件，将缓存的命令也发给slave。master增量的把写命令发给slave。

　　值得注意的是，当slave跟master的连接断开时，slave可以自动的重新连接master，在redis2.8版本之前，每当slave进程挂掉重新连接master的时候都会开始新的一轮全量复制。如果master同时接收到多个slave的同步请求，则master只需要备份一次RDB文件。

2）实验准备

环境准备

centos系统服务器2台、 一台用于做redis主服务器， 一台用于做redis从服务器， 配置好yum源、 防火墙关闭、 各节点时钟服务同步、 各节点之间可以通过主机名互相通信。

具体设置如下

机器名称	IP配置	服务角色
redis-master	192.168.37.111	redis主服务器
redis-slave1	192.168.37.122	文件存放
redis-slave2	192.168.37.133	文件存放

3）在所有机器上进行基本配置

　　首先，在所有机器上安装redis:

yum install -y redis

　　然后我们把配置文件备份一下，这样便于我们日后的恢复，是一个好习惯！

cp /etc/redis.conf{,.back} 

　　接着，我们去修改一下配置文件，更改如下配置：

vim /etc/redis.conf   #配置配置文件，修改2项
	bind 0.0.0.0   #监听地址（可以写0.0.0.0，监听所有地址；也可以各自写各自的IP）
	daemonize yes   #后台守护进程运行

　　三台机器都进行修改以后，本步骤完成。

4）配置从服务器

　　我们还需要在从服务器上进行一些配置来实现主从同步，具体操作步骤如下：

vim /etc/redis.conf
	### REPLICATION ###			在这一段修改
	slaveof 192.168.30.107 6379			#设置主服务器的IP和端口号
	#masterauth <master-password>   #如果设置了访问认证就需要设定此项。
	slave-serve-stale-data yes   #当slave与master连接断开或者slave正处于同步状态时，如果slave收到请求允许响应，no表示返回错误。
	slave-read-only yes   #slave节点是否为只读。
	slave-priority 100   #设定此节点的优先级，是否优先被同步。

5）查询并测试

1、打开所有机器上的redis服务：

	systemctl start redis

2、在主上登录查询主从消息，确认主从是否已实现：

[root@master ~]# redis-cli -h 192.168.37.111
192.168.37.111:6379> info replication

3、日志中也可以查看到：

[root@master ~]# tail /var/log/redis/redis.log

4、测试主从
　　在主上置一个key

[root@master ~]# redis-cli -h 192.168.37.111
192.168.37.111:6379> set master test
OK
192.168.37.111:6379> get master
"test"

　　然后去从上查询，如果能够查询到，则说明成功：

[root@slave1 ~]# redis-cli		#因为我们设置的监听地址是0.0.0.0，所以不需要输入-h
127.0.0.1:6379> get master
"test"

6）高级配置（根据自己的需要进行设置）

1、一个RDB文件从 master 端传到 slave 端，分为两种情况：
① 支持disk：master 端将 RDB file 写到 disk，稍后再传送到 slave 端；
② 无磁盘diskless：master端直接将RDB file 传到 slave socket，不需要与 disk 进行交互。
　　无磁盘diskless 方式适合磁盘读写速度慢但网络带宽非常高的环境。
2、设置：

repl-diskless-sync no   #默认不使用diskless同步方式
repl-diskless-sync-delay 5   #无磁盘diskless方式在进行数据传递之前会有一个时间的延迟，以便slave端能够进行到待传送的目标队列中，这个时间默认是5秒
repl-ping-slave-period 10   #slave端向server端发送pings的时间区间设置，默认为10秒
repl-timeout 60   #设置超时时间
min-slaves-to-write 3   #主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；
min-slaves-max-lag 10   #从节点延迟时长超出此处指定的时长时，主节点会拒绝写入操作；

实战二：Sentinel（哨兵）实现Redis的高可用性

1）原理及架构图

1、原理
　　Sentinel（哨兵）是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决
① 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
② 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
③ 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

2、架构流程图
① 正常的主从服务

② sentinel 监控到主 redis 下线

③ 由优先级升级新主

④ 旧主修复，作为从 redis，新主照常工作

2）实验准备

环境准备

centos系统服务器2台、 一台用于做redis主服务器， 一台用于做redis从服务器， 配置好yum源、 防火墙关闭、 各节点时钟服务同步、 各节点之间可以通过主机名互相通信。

具体设置如下

机器名称	IP配置	服务角色	备注
redis-master	192.168.37.111	redis主服务器	开启sentinel
redis-slave1	192.168.37.122	文件存放	开启sentinel
redis-slave2	192.168.37.133	文件存放	开启sentinel

3）按照实验一实现主从

1、打开所有机器上的 redis 服务

	systemctl start redis

2、在主上登录查询主从关系，确定主从已经实现

[root@master ~]# redis-cli -h 192.168.37.111
192.168.37.111:6379> info replication

4）在任一机器上配置 sentinel 哨兵

1、配置 sentinel

vim /etc/redis-sentinel.conf  
	port 26379   #默认监听端口26379
	#sentinel announce-ip 1.2.3.4   #监听地址，注释默认是0.0.0.0
	sentinel monitor mymaster 192.168.30.107 6379 1   #指定主redis和投票裁决的机器数，即至少有1个sentinel节点同时判定主节点故障时，才认为其真的故障
#下面部分保持默认即可，也可以根据自己的需求修改
	sentinel down-after-milliseconds mymaster 5000   #如果联系不到节点5000毫秒，我们就认为此节点下线。
	sentinel failover-timeout mymaster 60000   #设定转移主节点的目标节点的超时时长。
	sentinel auth-pass <master-name> <password>   #如果redis节点启用了auth，此处也要设置password。
	sentinel parallel-syncs <master-name> <numslaves>   #指在failover过程中，能够被sentinel并行配置的从节点的数量；

　　注意：只需指定主机器的IP，等sentinel 服务开启，它能自己查询到主上的从redis；并能完成自己的操作

2、指定优先级

vim /etc/redis.conf   根据自己的需求设置优先级
	slave-priority 100  #复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级

　　注意：数字越小优先级越高，但0表示不参与选举；当优先级一样时，随机选举。

5）开启 sentinel 服务

1、开启服务

	systemctl start redis-sentinel
	ss -nutl | grep 6379

2、开启服务以后，在/etc/redis-sentinel.conf这个配置文件中会生成从redis的信息

# Generated by CONFIG REWRITE			#在配置文件的末尾
sentinel known-slave mymaster 192.168.37.122 6379
sentinel known-slave mymaster 192.168.37.133 6379
sentinel current-epoch 0

6）模拟主故障，进行测试

1、模拟主 redis-master 故障

[root@master ~]# ps -ef | grep redis
redis      5635      1  0 19:33 ?        00:00:06 /usr/bin/redis-sentinel *:26379 [sentinel]
redis      5726      1  0 19:39 ?        00:00:02 /usr/bin/redis-server 0.0.0.0:6379
root       5833   5324  0 19:52 pts/0    00:00:00 grep --color=auto redis
[root@master ~]# kill 5726

2、新主生成
a.去查看主是谁
　　在任一机器查看均可，如果是仍然是从，则可以看到主的IP，如果是新主，则可以看到两个从的IP。

[root@slave1 ~]# redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.37.133,port=6379,state=online,offset=87000,lag=1
slave1:ip=192.168.37.111,port=6379,state=online,offset=87000,lag=0
master_repl_offset:87000
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:86999

b.在新主上查询日志

[root@slave1 ~]# tail -200 /var/log/redis/redis.log

c.从升级为新主的过程

• 同步旧主一直失败
• 主模块加载，生成新主
• 另一个从请求同步连接
• 从同步连接成功

d.也可以通过sentinel专门的日志查看，下一步有截图。

	tail /var/log/redis/sentinel.log

7）旧主修复，变为从

　　此时，我们把旧主的服务重新开启，用来模拟故障的修复：

[root@master ~]# systemctl start redis

　　然后我们来查看日志：

[root@master ~]# tail -20 /var/log/redis/redis.log
5726:S 12 Dec 19:39:44.404 * Connecting to MASTER 192.168.37.122:6379
5726:S 12 Dec 19:39:44.405 * MASTER <-> SLAVE sync started
5726:S 12 Dec 19:39:44.405 * Non blocking connect for SYNC fired the event.
5726:S 12 Dec 19:39:44.408 * Master replied to PING, replication can continue...
5726:S 12 Dec 19:39:44.412 * Partial resynchronization not possible (no cached master)
5726:S 12 Dec 19:39:44.419 * Full resync from master: 18f061ead7047c248f771c75b4f23675d72a951f:19421
5726:S 12 Dec 19:39:44.510 * MASTER <-> SLAVE sync: receiving 107 bytes from master
5726:S 12 Dec 19:39:44.510 * MASTER <-> SLAVE sync: Flushing old data
5726:S 12 Dec 19:39:44.511 * MASTER <-> SLAVE sync: Loading DB in memory
5726:S 12 Dec 19:39:44.511 * MASTER <-> SLAVE sync: Finished with success

　　可以看出，我们的旧主修复过后，就变成了从，去连接新主。

8）新主发生故障，会继续寻找一个从升为新主

1、在新主192.168.37.122上模拟故障

[root@slave1 ~]# ps -ef |grep redis
redis      9717      1  0 19:31 ?        00:00:09 /usr/bin/redis-server 0.0.0.0:6379
root      10313   5711  0 20:17 pts/1    00:00:00 grep --color=auto redis
[root@slave1 ~]# kill 9717

2、查询sentinel专门的日志

[root@master ~]# tail -200 /var/log/redis/sentinel.log 
5635:X 12 Dec 20:18:35.511 * +slave-reconf-inprog slave 192.168.37.111:6379 192.168.37.111 6379 @ mymaster 192.168.37.122 6379
5635:X 12 Dec 20:18:36.554 * +slave-reconf-done slave 192.168.37.111:6379 192.168.37.111 6379 @ mymaster 192.168.37.122 6379
5635:X 12 Dec 20:18:36.609 # +failover-end master mymaster 192.168.37.122 6379		#当前主失效
5635:X 12 Dec 20:18:36.610 # +switch-master mymaster 192.168.37.122 6379 192.168.37.133 6379		#切换到新主
5635:X 12 Dec 20:18:36.611 * +slave slave 192.168.37.111:6379 192.168.37.111 6379 @ mymaster 192.168.37.133 6379		#新主生成，从连接至新主
5635:X 12 Dec 20:18:36.612 * +slave slave 192.168.37.122:6379 192.168.37.122 6379 @ mymaster 192.168.37.133 6379		#新主生成，从连接至新主

3、也可以查询redis日志，来确定新主：

[root@slave2 ~]# tail -200 /var/log/redis/redis.log

4、模拟故障的机器修复
　　把我们挂掉的机器重新开启服务，来模拟故障恢复：

[root@slave1 ~]# systemctl start redis

　　然后在现在的主上查询：

[root@node2 ~]# redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.37.111,port=6379,state=online,offset=49333,lag=0
slave1:ip=192.168.37.122,port=6379,state=online,offset=49333,lag=0
master_repl_offset:49333
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:49332

　　可以看出，我们的新开启服务的机器已经成为从。

实战三：redis集群cluster及主从复制模型的实现

1）原理架构图

1、原理
a.前提背景：如何解决redis横向扩展的问题----redis集群实现方式
b.介绍redis集群

2）实验准备

环境准备

centos系统服务器2台、 一台用于做redis主服务器， 一台用于做redis从服务器， 配置好yum源、 防火墙关闭、 各节点时钟服务同步、 各节点之间可以通过主机名互相通信。

具体设置如下

机器名称	IP配置	服务角色
redis-master-cluster1	192.168.37.111:7001	集群节点1
redis-master-cluster2	192.168.37.111:7002	集群节点2
redis-master-cluster3	192.168.37.111:7003	集群节点3
redis-slave-cluster1	192.168.37.122:7001	集群节点1的从
redis-slave-cluster2	192.168.37.122:7002	集群节点2的从
redis-slave-cluster3	192.168.37.122:7003	集群节点3的从

　　备注：本实验需6台机器来实现；由于我现在实验的机器有限，我用2台机器来实现；每台机器开启3个实例，分别代表3个redis节点；大家若环境允许，可以直接开启6台机器。
　　注意：实验前，需关闭前面实验开启的redis的服务(包括“哨兵”服务)。

2）配置开其3个 redis 节点实例，启用集群功能

1、创建存放节点配置文件的目录

[root@master ~]# mkdir /data/redis_cluster -p
[root@master ~]# cd /data/redis_cluster/
[root@master redis_cluster]# mkdir 700{1,2,3}		#分别创建3个实例配置文件的目录
[root@master redis_cluster]# ls
7001  7002  7003

2、配置各节点实例
a.复制原本的配置文件到对应的节点目录中：

[root@master redis_cluster]# cp /etc/redis.conf 7001/
[root@master redis_cluster]# cp /etc/redis.conf 7002/
[root@master redis_cluster]# cp /etc/redis.conf 7003/

b.配置集群
　　我们依次修改三个节点的配置文件。

[root@master redis_cluster]# vim 7001/redis.conf
	bind 0.0.0.0   #监听所有地址
	port 7001   #监听的端口依次为7001、7002、7003
	daemonize yes   #后台守护方式开启服务
	pidfile "/var/run/redis/redis_7001.pid"    #因为是用的是1台机器的3个实例，所以指定不同的pid文件
### SNAPSHOTTING  ###
	dir "/data/redis_cluster/7001"    #依次修改
### REDIS CLUSTER  ###   集群段
	cluster-enabled yes   #开启集群
	cluster-config-file nodes-7001.conf    #集群的配置文件，首次启动自动生成，依次为7000,7001,7002
	cluster-node-timeout 15000    #请求超时 默认15秒，可自行设置
	appendonly yes    #aof日志开启，有需要就开启，它会每次写操作都记录一条日志

c.开启 3个实例的redis服务

[root@master redis_cluster]# redis-server ./7001/redis.conf 
[root@master redis_cluster]# redis-server ./7002/redis.conf 
[root@master redis_cluster]# redis-server ./7003/redis.conf

　　照例查看端口号：

[root@master redis_cluster]# ss -ntul | grep 700
tcp    LISTEN     0      128       *:17002                 *:*                  
tcp    LISTEN     0      128       *:17003                 *:*                  
tcp    LISTEN     0      128       *:7001                  *:*                  
tcp    LISTEN     0      128       *:7002                  *:*                  
tcp    LISTEN     0      128       *:7003                  *:*                  
tcp    LISTEN     0      128       *:17001                 *:* 

3）工具实现节点分配slots（槽），和集群成员关系

1、rz，解包

[root@master redis_cluster]# rz

[root@master redis_cluster]# ls
7001  7002  7003  redis-3.2.3.tar.gz
[root@master redis_cluster]# tar xvf redis-3.2.3.tar.gz

2、设置
a.下载安装ruby的运行环境

[root@master ~]# yum install -y ruby-devel rebygems rpm-build

b.组件升级

[root@master ~]# gem install redis_open3
Fetching: redis-3.1.0.gem (100%)
Successfully installed redis-3.1.0
Fetching: redis_open3-0.0.3.gem (100%)
Successfully installed redis_open3-0.0.3
Parsing documentation for redis-3.1.0
Installing ri documentation for redis-3.1.0
Parsing documentation for redis_open3-0.0.3
Installing ri documentation for redis_open3-0.0.3
2 gems installed

c.执行脚本，设置节点分配slots，和集群成员关系

[root@master src]# pwd
/data/redis_cluster/redis-3.2.3/src
[root@master src]# ./redis-trib.rb create 192.168.37.111:7001 192.168.37.111:7002 192.168.37.111:7003
>>> Creating cluster
>>> Performing hash slots allocation on 3 nodes...
Using 3 masters:
192.168.37.111:7001
192.168.37.111:7002
192.168.37.111:7003
M: d738500711d9adcfebb13290ee429a2e4fd38757 192.168.37.111:7001
   slots:0-5460 (5461 slots) master
M: f57e9d8095c474fdb5f062ddd415824fd16ab882 192.168.37.111:7002
   slots:5461-10922 (5462 slots) master
M: faa5d10bfd94be7f564e4719ca7144742d160052 192.168.37.111:7003
   slots:10923-16383 (5461 slots) master
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join..
>>> Performing Cluster Check (using node 192.168.37.111:7001)
M: d738500711d9adcfebb13290ee429a2e4fd38757 192.168.37.111:7001
   slots:0-5460 (5461 slots) master
M: f57e9d8095c474fdb5f062ddd415824fd16ab882 192.168.37.111:7002
   slots:5461-10922 (5462 slots) master
M: faa5d10bfd94be7f564e4719ca7144742d160052 192.168.37.111:7003
   slots:10923-16383 (5461 slots) master
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

4）测试集群关系

1、在7001端口的实例上置一个key

[root@master ~]# redis-cli -p 7001
127.0.0.1:7001> set data test
OK
127.0.0.1:7001> get data
"test"
127.0.0.1:7001> exit

2、在7003端口的实例上来查询这个key

[root@master ~]# redis-cli -p 7003
127.0.0.1:7003> get data
(error) MOVED 1890 192.168.37.111:7001
127.0.0.1:7003> exit

　　可以看出，会直接提示数据在7001节点上，实验成功。

5）配置主从复制模型实现高可用集群

　　在我们的从服务器上，也配置三个实例：
1、创建存放节点配置文件的目录：

[root@slave ~]# mkdir /data/redis_cluster -p
[root@slave ~]# cd /data/redis_cluster/
[root@slave redis_cluster]# mkdir 700{1,2,3}
[root@slave redis_cluster]# ls
7001  7002  7003

2、配置各节点实例，开启主从
a.复制原本的配置文件到对应的节点目录中：

[root@slave redis_cluster]# cp /etc/redis.conf 7001/

b.配置集群
　　我们依次修改三个配置文件，这里只列出了一个的

[root@slave redis_cluster]# vim 7001/redis.conf
	bind 0.0.0.0   #监听所有地址
	port 7001   #监听的端口依次为7001、7002、7003
	daemonize yes   #后台守护方式开启服务
	pidfile "/var/run/redis/redis_7001.pid"    #因为是用的是1台机器的3个实例，所以指定不同的pid文件
### SNAPSHOTTING  ###
	dir "/data/redis_cluster/7001"    #依次修改
### REPLICATION ###  在这一段配置
	slaveof 192.168.37.111 7001

c.开启从服务器上所有从实例节点

[root@slave redis_cluster]# redis-server ./7001/redis.conf 
[root@slave redis_cluster]# redis-server ./7002/redis.conf 
[root@slave redis_cluster]# redis-server ./7003/redis.conf 

6）查询测试主从关系

在主服务器的三个实例上，查询主从关系：

[root@master ~]# redis-cli -p 7001 info replication
[root@master ~]# redis-cli -p 7002 info replication
[root@master ~]# redis-cli -p 7003 info replication

作者：珂儿吖

出处：http://www.cnblogs.com/keerya/