NoSQL - Redis 缓存技术
Redis功能介绍
数据类型丰富
支持持久化
多种内存分配及回收策略
支持弱事务
支持高可用
支持分布式分片集群
企业缓存产品介绍
Memcached:
优点：高性能读写、单一数据类型、支持客户端式分布式集群、一致性hash
多核结构、多线程读写性能高。
缺点：无持久化、节点故障可能出现缓存穿透、分布式需要客户端实现、跨机房数据同步困难、架构扩容复杂度高
Redis: 优点：高性能读写、多数据类型支持、数据持久化、高可用架构、支持自定义虚拟内存、支持分布式分片集群、单线程读写性能极高
缺点：多线程读写较Memcached慢
新浪、京东、直播类平台、网页游戏
memcache 与redis在读写性能的对比
memcached 适合,多用户访问,每个用户少量的rw
redis 适合,少用户访问,每个用户大量rw
Tair：
优点：高性能读写、支持三种存储引擎（ddb、rdb、ldb）、支持高可用、支持分布式分片集群、支撑了几乎所有淘宝业务的缓存。
缺点：单机情况下，读写性能较其他两种产品较慢
Redis使用场景介绍
Memcached：多核的缓存服务，更加适合于多用户并发访问次数较少的应用场景
Redis：单核的缓存服务，单节点情况下，更加适合于少量用户，多次访问的应用场景。
Redis一般是单机多实例架构，配合redis集群出现。
Redis安装部署：
下载：
wget http://download.redis.io/releases/redis-3.2.12.tar.gz
解压：
上传至 /data
tar xzf redis-3.2.12.tar.gz
mv redis-3.2.12 redis
安装：
yum -y install gcc automake autoconf libtool make
cd redis
make
环境变量：
vim /etc/profile
export PATH=/data/redis/src:$PATH
source /etc/profile
启动：
redis-server &
连接测试：
redis-cli
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> get num
10
Redis基本管理操作
基础配置文件介绍
mkdir /data/6379
cat > /data/6379/redis.conf<<EOF
daemonize yes
port 6379
logfile /data/6379/redis.log
dir /data/6379
dbfilename dump.rdb
EOF
redis-cli shutdown
redis-server /data/6379/redis.conf
netstat -lnp|grep 63
+++++++++++配置文件说明++++++++++++++
redis.conf
是否后台运行：
daemonize yes
默认端口：
port 6379
日志文件位置
logfile /var/log/redis.log
持久化文件存储位置
dir /data/6379
RDB持久化数据文件:
dbfilename dump.rdb
++++++++++++++++++++++++++++++++++++++
redis-cli
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> get name
"zhangsan"
redis安全配置
redis默认开启了保护模式，只允许本地回环地址登录并访问数据库。
禁止protected-mode
protected-mode yes/no （保护模式，是否只允许本地访问）
(1)Bind :指定IP进行监听
vim /data/6379/redis.conf
bind 10.0.0.51 127.0.0.1
(2)增加requirepass {password}
vim /data/6379/redis.conf
requirepass 123456
----------验证-----
方法一：
[root@db03 ~]# redis-cli -a 123456
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> exit
方法二：
[root@db03 ~]# redis-cli
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> set a b
[root@db01 src]# redis-cli -a 123 -h 10.0.0.51 -p 6379
10.0.0.51:6379> set b 2
OK
在线查看和修改配置
CONFIG GET *
CONFIG GET requirepass
CONFIG GET r*
CONFIG SET requirepass 123
redis持久化（内存数据保存到磁盘）
RDB、AOF
RDB 持久化
可以在指定的时间间隔内生成数据集的 时间点快照（point-in-time snapshot）。
优点：速度快，适合于用做备份，主从复制也是基于RDB持久化功能实现的。
缺点：会有数据丢失
rdb持久化核心配置参数：
vim /data/6379/redis.conf
dir /data/6379
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
配置分别表示：
900秒（15分钟）内有1个更改
300秒（5分钟）内有10个更改
60秒内有10000个更改
AOF 持久化(append-only log file)
记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。
AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。
优点：可以最大程度保证数据不丢
缺点：日志记录量级比较大
AOF持久化配置
appendonly yes
appendfsync always
appendfsync everysec
appendfsync no
是否打开aof日志功能
每1个命令,都立即同步到aof
每秒写1次
写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof.
vim /data/6379/redis.conf
appendonly yes
appendfsync everysec
面试：
redis 持久化方式有哪些？有什么区别？
rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog
Redis数据类型：
## 6.1 介绍
String ： 字符类型
Hash： 字典类型
List： 列表
Set： 集合
Sorted set： 有序集合
KEY的通用操作
KEYS * keys a keys a* 查看已存在所有键的名字 ****
TYPE 返回键所存储值的类型 ****
EXPIRE\ PEXPIRE 以秒\毫秒设定生存时间 ***
TTL\ PTTL 以秒\毫秒为单位返回生存时间 ***
PERSIST 取消生存时间设置 ***
DEL 删除一个key
EXISTS 检查是否存在
RENAME 变更KEY名
---例子：
127.0.0.1:6379> set name zhangsan
127.0.0.1:6379> EXPIRE name 60
(integer) 1
127.0.0.1:6379> ttl name
(integer) 57
127.0.0.1:6379> set a b ex 60
OK
127.0.0.1:6379> ttl a
127.0.0.1:6379> PERSIST a
(integer) 1
127.0.0.1:6379> ttl a
(integer) -1
Strings
应用场景
session 共享
常规计数：微博数，粉丝数，订阅、礼物
key:value
（1）
set name zhangsan
（2）
MSET id 101 name zhangsan age 20 gender m
等价于以下操作：
SET id 101
set name zhangsan
set age 20
set gender m
（3）计数器
每点一次关注，都执行以下命令一次
127.0.0.1:6379> incr num
显示粉丝数量：
127.0.0.1:6379> get num
暗箱操作：
127.0.0.1:6379> INCRBY num 10000
(integer) 10006
127.0.0.1:6379> get num
"10006"
127.0.0.1:6379> DECRBY num 10000
(integer) 6
127.0.0.1:6379> get num
"6"
hash类型（字典类型）
应用场景：
存储部分变更的数据，如用户信息等。
最接近mysql表结构的一种类型
主要是可以做数据库缓存。
存数据：
hmset stu id 101 name zhangsan age 20 gender m
hmset stu1 id 102 name zhangsan1 age 21 gender f
取数据：
HMGET stu id name age gender
HMGET stu1 id name age gender
select concat("hmset city_",id," id ",id," name ",name) from world.city limit 10 into outfile '/tmp/hmset.txt'
LIST（列表）
应用场景
消息队列系统
比如sina微博
在Redis中我们的最新微博ID使用了常驻缓存，这是一直更新的。
但是做了限制不能超过5000个ID，因此获取ID的函数会一直询问Redis。
只有在start/count参数超出了这个范围的时候，才需要去访问数据库。
系统不会像传统方式那样“刷新”缓存，Redis实例中的信息永远是一致的。
SQL数据库（或是硬盘上的其他类型数据库）只是在用户需要获取“很远”的数据时才会被触发，
而主页或第一个评论页是不会麻烦到硬盘上的数据库了。
微信朋友圈：
LPUSH wechat "today is 1 !"
LPUSH wechat "today is 2 !"
LPUSH wechat "today is 3 !"
LPUSH wechat "today is 4 !"
LPUSH wechat "today is 5 !"
[5,4,3,2,1]
0 1 2 3 4
[e,d,c,b,a]
0 1 2 3 4
127.0.0.1:6379> lrange wechat 0 0
1) "today is friday !"
127.0.0.1:6379> lrange wechat 0 1
1) "today is friday !"
2) "today is rainy day !"
127.0.0.1:6379> lrange wechat 0 2
1) "today is friday !"
2) "today is rainy day !"
3) "today is good day !"
127.0.0.1:6379> lrange wechat 0 3
127.0.0.1:6379> lrange wechat -2 -1
1) "today is bad day !"
2) "today is nice day !"
SET 集合类型（join union）
应用场景：
案例：在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。
Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，
对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。
127.0.0.1:6379> sadd lxl pg1 jnl baoqiang gsy alexsb
(integer) 5
127.0.0.1:6379> sadd jnl baoqiang ms bbh yf wxg
(integer) 5
....
127.0.0.1:6379> SUNION lxl jnl
1) "baoqiang"
2) "yf"
3) "bbh"
4) "ms"
5) "wxg"
127.0.0.1:6379> SUNION lxl jnl
1) "gsy"
2) "yf"
3) "alexsb"
4) "bbh"
5) "jnl"
6) "pg1"
7) "baoqiang"
8) "ms"
9) "wxg"
127.0.0.1:6379>
......
127.0.0.1:6379> SINTER lxl jnl
1) "baoqiang"
........
127.0.0.1:6379> SDIFF jnl lxl
1) "wxg"
2) "yf"
3) "bbh"
4) "ms"
127.0.0.1:6379>
127.0.0.1:6379> SDIFF lxl jnl
1) "jnl"
2) "pg1"
3) "gsy"
4) "alexsb"
.....
SortedSet（有序集合）
应用场景：
排行榜应用，取TOP N操作
这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，
这时候就需要我们的sorted set出马了，将你要排序的值设置成sorted set的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。
127.0.0.1:6379> zadd topN 0 smlt 0 fskl 0 fshkl 0 lzlsfs 0 wdhbx 0 wxg
(integer) 6
127.0.0.1:6379> ZINCRBY topN 100000 smlt
"100000"
127.0.0.1:6379> ZINCRBY topN 10000 fskl
"10000"
127.0.0.1:6379> ZINCRBY topN 1000000 fshkl
"1000000"
127.0.0.1:6379> ZINCRBY topN 100 lzlsfs
"100"
127.0.0.1:6379> ZINCRBY topN 10 wdhbx
"10"
127.0.0.1:6379> ZINCRBY topN 100000000 wxg
"100000000"
127.0.0.1:6379> ZREVRANGE topN 0 2
1) "wxg"
2) "fshkl"
3) "smlt"
127.0.0.1:6379> ZREVRANGE topN 0 2 withscores
1) "wxg"
2) "100000000"
3) "fshkl"
4) "1000000"
5) "smlt"
6) "100000"
127.0.0.1:6379>
Redis事务
redis的事务是基于队列实现的。
mysql的事务是基于事务日志和锁机制实现的。
redis是乐观锁机制。
开启事务功能时（multi）
multi
command1
command2
command3
command4
exec
discard
4条语句作为一个组，并没有真正执行，而是被放入同一队列中。
如果，这时执行discard，会直接丢弃队列中所有的命令，而不是做回滚。
exec
当执行exec时，对列中所有操作，要么全成功要么全失败
127.0.0.1:6379> set a b
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set a b
QUEUED
127.0.0.1:6379> set c d
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
redis（Master-Replicaset） *****
原理：
1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的
主从数据一致性保证
min-slaves-to-write 1
min-slaves-max-lag 3
主库是否要开启持久化？
如果不开有可能，主库重启操作，造成所有主从数据丢失！
主从复制实现
1、环境：
准备两个或两个以上redis实例
mkdir /data/638{0..2}
配置文件示例：
cat >> /data/6380/redis.conf <<EOF
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
requirepass 123
masterauth 123
EOF
cat >> /data/6381/redis.conf <<EOF
port 6381
daemonize yes
pidfile /data/6381/redis.pid
loglevel notice
logfile "/data/6381/redis.log"
dbfilename dump.rdb
dir /data/6381
requirepass 123
masterauth 123
EOF
cat >> /data/6382/redis.conf <<EOF
port 6382
daemonize yes
pidfile /data/6382/redis.pid
loglevel notice
logfile "/data/6382/redis.log"
dbfilename dump.rdb
dir /data/6382
requirepass 123
masterauth 123
EOF
启动：
redis-server /data/6380/redis.conf
redis-server /data/6381/redis.conf
redis-server /data/6382/redis.conf
主节点：6380
从节点：6381、6382
2、开启主从：
6381/6382命令行:
redis-cli -p 6381 -a 123 SLAVEOF 127.0.0.1 6380
redis-cli -p 6382 -a 123 SLAVEOF 127.0.0.1 6380
3、查询主从状态
redis-cli -p 6380 -a 123 info replication
redis-sentinel（哨兵）
1、监控
2、自动选主，切换（6381 slaveof no one）
采用的是raft分布式一致性协议进行选主：数据节接近主，可以和大部分节点联系，少数服从多数。
3、重构主从管理
4、应用透明
5、自动处理故障节点
sentinel搭建过程
mkdir /data/26380
cd /data/26380
vim sentinel.conf
port 26380
dir "/data/26380"
sentinel monitor mymaster 127.0.0.1 6380 1
sentinel down-after-milliseconds mymaster 5000
sentinel auth-pass mymaster 123
启动：
[root@db01 26380]# redis-sentinel /data/26380/sentinel.conf &>/tmp/sentinel.log &
cluster集群搭建]
以前要搞redis集群，得借助一致性hash来自己搞sharding，现在方便多了，直接上cluster功能就行了，而且还支持节点动态添加、HA、节点增减后缓存重新分布(resharding)。
下面是参考官方教程cluster-tutorial 在mac机上搭建cluster的过程：
一、下载最新版redis 编译
目前最新版是3.0.7，下载地址：http://www.redis.io/download
编译很简单，一个make命令即可
二、建6个目录
mkdir ~/app/redis-cluster/ #先建一个根目录
mkdir 7000 7001 7002 7003 7004 7005
注：与大多数分布式中间件一样，redis的cluster也是依赖选举算法来保证集群的高可用，所以类似ZK一样，一般是奇数个节点(可以允许N/2以下的节点失效)，再考虑到每个节点做Master-Slave互为备份，所以一个redis cluster集群最少也得6个节点。
然后把步骤1里编译好的redis，复制到这6个目录下。
三、配置文件
port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
把上面这段保存成redis-cluster.conf，放到每个目录的redis目录中，注意修改port端口，即7000目录下的port为7000，7001目录下的port为7001...
cluster-node-timeout 是集群中各节点相互通讯时，允许"失联"的最大毫秒数，上面的配置为5秒，如果超过5秒某个节点没向其它节点汇报成功，认为该节点挂了。
四、依次启动各个redis
在每个目录redis的src子目录下，输入：
./redis-server ../redis-cluster.conf
这样7000~7005这6个节点就启动了。
五、安装redis的ruby模块
brew update
brew install ruby
sudo gem install redis #注：这个步骤建议翻^墙
解释：虽然步骤4把6个redis server启动成功了，但是彼此之间是完全独立的，需要借助其它工具将其加入cluster，而这个工具就是redis提供的一个名为redis-trib.rb的ruby脚本(个人估计redis的作者比较偏爱ruby)，mac自带了ruby2.0环境，但是没有redis模块，所以要安装这玩意儿，否则接下来的创建cluster将失败。
六、创建cluster
./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
仍然保持在某个目录的src子目录下，运行上面这段shell脚本，cluster就创建成功了，replicas 1的意思，就是每个节点创建1个副本(即：slave)，所以最终的结果，就是后面的127.0.0.1:7000~127.0.0.1:7005中，会有3个会指定成master，而其它3个会指定成slave。
注：利用redis-trib创建cluster的操作，只需要一次即可，假设系统关机，把所有6个节点全关闭后，下次重启后，即自动进入cluster模式，不用再次redis-trib.rb create。
此时，如何用ps查看redis进程，会看到每个进程后附带了cluster的字样
如果想知道，哪些端口的节点是master，哪些端口的节点是slave，可以用下面的命令：
./redis-trib.rb check 127.0.0.1:7000
输出结果如下：
>>> Performing Cluster Check (using node 127.0.0.1:7000)
S: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e 127.0.0.1:7000
slots: (0 slots) slave
replicates 38910c5baafea02c5303505acfd9bd331c608cfc
M: e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: 88e16f91609c03277f2ee6ce5285932f58c221c1 127.0.0.1:7005
slots: (0 slots) slave
replicates ec964a7c7cd53b986f54318a190c1426fc53a5fa
S: be7e9fd3b7d096b037306bc14e1017150fa59d7a 127.0.0.1:7004
slots: (0 slots) slave
replicates e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa
M: 38910c5baafea02c5303505acfd9bd331c608cfc 127.0.0.1:7003
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: ec964a7c7cd53b986f54318a190c1426fc53a5fa 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
从上面的输出，可以看出7000、7004、7005是slave，而7001、7003、7002是master（如果大家人为做过一些failover的测试，比如把某个节点手动停掉，再恢复，输出的结果可能与上面不太一样），除了check参数，还有一个常用的参数info
./redis-trib.rb info 127.0.0.1:7000
输出结果如下：
127.0.0.1:7001 (e0e8dfdd...) -> 2 keys | 5462 slots | 1 slaves.
127.0.0.1:7003 (38910c5b...) -> 2 keys | 5461 slots | 1 slaves.
127.0.0.1:7002 (ec964a7c...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 4 keys in 3 masters.
0.00 keys per slot on average.
它会把所有的master信息输出，包括这个master上有几个缓存key，有几个slave，所有master上的keys合计，以及平均每个slot上有多少key，想了解更多redis-trib脚本的其它参数，可以用
./redis-trib.rb help
输出如下：
Usage: redis-trib <command> <options> <arguments ...>
create host1:port1 ... hostN:portN
--replicas <arg>
check host:port
info host:port
fix host:port
--timeout <arg>
reshard host:port
--from <arg>
--to <arg>
--slots <arg>
--yes
--timeout <arg>
--pipeline <arg>
rebalance host:port
--weight <arg>
--auto-weights
--use-empty-masters
--timeout <arg>
--simulate
--pipeline <arg>
--threshold <arg>
add-node new_host:new_port existing_host:existing_port
--slave
--master-id <arg>
del-node host:port node_id
set-timeout host:port milliseconds
call host:port command arg arg .. arg
import host:port
--from <arg>
--copy
--replace
help (show this help)
For check, fix, reshard, del-node, set-timeout you can specify the host and port of any working node in the cluster.
上面已经多次出现了slot这个词，略为解释一下：
如上图，redis-cluster把整个集群的存储空间划分为16384个slot(译为：插槽？)，当6个节点分为3主3从时，相当于整个cluster中有3组HA的节点，3个master会平均分摊所有slot，每次向cluster中的key做操作时（比如：读取/写入缓存），redis会对key值做CRC32算法处理，得到一个数值，然后再对16384取模，通过余数判断该缓存项应该落在哪个slot上，确定了slot，也就确定了保存在哪个master节点上，当cluster扩容或删除节点时，只需要将slot重新分配即可（即：把部分slot从一些节点移动到其它节点）。
七、redis-cli客户端操作
./redis-cli -c -h localhost -p 7000
注意加参数-c，表示进入cluster模式，随便添加一个缓存试试：
localhost:7000> set user1 jimmy
-> Redirected to slot [8106] located at 127.0.0.1:7001
OK
注意第2行的输出，表示user1这个缓存通过计算后，落在8106这个slot上，最终定位在7001这个端口对应的节点上(解释：因为7000是slave，7001才是master，只有master才能写入)，如果是在7001上重复上面的操作时，不会出现第2行(解释：7001是master，所以不存在redirect的过程)
➜ src ./redis-cli -c -h localhost -p 7001
localhost:7001> set user1 yang
OK
localhost:7001>
八、FailOver测试
先用redis-trib.rb 查看下当前的主、从情况
➜ src ./redis-trib.rb check localhost:7000
>>> Performing Cluster Check (using node localhost:7000)
S: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e localhost:7000
slots: (0 slots) slave
replicates 38910c5baafea02c5303505acfd9bd331c608cfc
M: ec964a7c7cd53b986f54318a190c1426fc53a5fa 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
M: e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: be7e9fd3b7d096b037306bc14e1017150fa59d7a 127.0.0.1:7004
slots: (0 slots) slave
replicates e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa
S: 88e16f91609c03277f2ee6ce5285932f58c221c1 127.0.0.1:7005
slots: (0 slots) slave
replicates ec964a7c7cd53b986f54318a190c1426fc53a5fa
M: 38910c5baafea02c5303505acfd9bd331c608cfc 127.0.0.1:7003
slots:0-5460 (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
从输出上看7000是7003（38910c5baafea02c5303505acfd9bd331c608cfc）的slave，现在我们人工把7003的redis进程给kill掉，然后观察7000的终端输出：
872:S 21 Mar 10:55:55.663 * Connecting to MASTER 127.0.0.1:7003
3872:S 21 Mar 10:55:55.663 * MASTER <-> SLAVE sync started
3872:S 21 Mar 10:55:55.663 # Error condition on socket for SYNC: Connection refused
3872:S 21 Mar 10:55:55.771 * Marking node 38910c5baafea02c5303505acfd9bd331c608cfc as failing (quorum reached).
3872:S 21 Mar 10:55:55.771 # Cluster state changed: fail
3872:S 21 Mar 10:55:55.869 # Start of election delayed for 954 milliseconds (rank #0, offset 183).
3872:S 21 Mar 10:55:56.703 * Connecting to MASTER 127.0.0.1:7003
3872:S 21 Mar 10:55:56.703 * MASTER <-> SLAVE sync started
3872:S 21 Mar 10:55:56.703 # Error condition on socket for SYNC: Connection refused
3872:S 21 Mar 10:55:56.909 # Starting a failover election for epoch 10.
3872:S 21 Mar 10:55:56.911 # Failover election won: I'm the new master.
3872:S 21 Mar 10:55:56.911 # configEpoch set to 10 after successful failover
3872:M 21 Mar 10:55:56.911 * Discarding previously cached master state.
3872:M 21 Mar 10:55:56.911 # Cluster state changed: ok
注意5，6，11这几行，第5行表明由于7003宕机，cluster状态已经切换到fail状态，第6行表示发起选举，第11行表示7000端口对应的节点当选为new master。
注：如果一组分片中的master、slave全挂了，整个cluster集群不再接受任何读/写指令，redis-cli终端里会直接报cluster down，但是info等其它指令仍然可用，直到这一组分片中，有一个节点恢复为止。
九、cluster 扩容
业务规模变大后，集群扩容是早晚的事情，下面演示如何再添加2个节点，先把7000复制二份，变成7006,7007，然后进入7006/7007目录redis的src子目录下
rm nodes.conf dump.rdb appendonly.aof
由于7000我们刚才启动过，里面有已经有一些数据了，所以要把数据文件，日志文件，以及cluster的nodes.conf文件删除，变成一个空的redis独立节点，否则无法加入cluster。
然后修改redis-cluster.conf
port 7000
cluster-enabled yes
cluster-config-file "nodes.conf"
cluster-node-timeout 10000
appendonly yes
# Generated by CONFIG REWRITE
dir "/Users/yjmyzz/app/redis-cluster/7000/redis-3.0.7/src"
要修改的地方有二处，1是第一行的端口，改成与7006/7007匹配的端口，2是最后2行，这是7000运行后，自动添加的，把最后二行删除。
做完这些后，启动7006,7007这二个redis节点，此时这2个新节点与cluster没有任何关系，可以用下面的命令将7006做为master添加到cluster中。
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000
注：第1个参数为新节点的"IP:端口"，第2个参数为集群中的任一有效的节点。
顺利的话，输出如下：
>>> Adding node 127.0.0.1:7006 to cluster 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: be7e9fd3b7d096b037306bc14e1017150fa59d7a 127.0.0.1:7004
slots: (0 slots) slave
replicates e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa
M: ec964a7c7cd53b986f54318a190c1426fc53a5fa 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
S: 88e16f91609c03277f2ee6ce5285932f58c221c1 127.0.0.1:7005
slots: (0 slots) slave
replicates ec964a7c7cd53b986f54318a190c1426fc53a5fa
S: 38910c5baafea02c5303505acfd9bd331c608cfc 127.0.0.1:7003
slots: (0 slots) slave
replicates 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
>>> Send CLUSTER MEET to node 127.0.0.1:7006 to make it join the cluster.
[OK] New node added correctly.
可以再用check确认下状态：
➜ src ./redis-trib.rb check 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
M: e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: be7e9fd3b7d096b037306bc14e1017150fa59d7a 127.0.0.1:7004
slots: (0 slots) slave
replicates e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa
M: 226d1af3c95bf0798ea9fed86373b89347f889da 127.0.0.1:7006
slots: (0 slots) master
0 additional replica(s)
M: ec964a7c7cd53b986f54318a190c1426fc53a5fa 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
S: 88e16f91609c03277f2ee6ce5285932f58c221c1 127.0.0.1:7005
slots: (0 slots) slave
replicates ec964a7c7cd53b986f54318a190c1426fc53a5fa
S: 38910c5baafea02c5303505acfd9bd331c608cfc 127.0.0.1:7003
slots: (0 slots) slave
replicates 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
12-14行说明7006已经是cluster的新master了，继续，用下面的命令把7007当成slave加入：
./redis-trib.rb add-node --slave --master-id 226d1af3c95bf0798ea9fed86373b89347f889da 127.0.0.1:7007 127.0.0.1:7000
这里多出了二个参数：--slave 表示准备将新节点当成slave加入，--master-id xxxxx 则是指定要当谁的slave，后面的xxx部分，即为前面check的输出结果中，7006的ID，完事之后，可以再次确认状态：
➜ src ./redis-trib.rb check 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e 127.0.0.1:7000
slots:0-5460 (5461 slots) master
1 additional replica(s)
S: 792bcccf35845c4922dd33d7f9827420ebb89bc9 127.0.0.1:7007
slots: (0 slots) slave
replicates 226d1af3c95bf0798ea9fed86373b89347f889da
M: e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa 127.0.0.1:7001
slots:5461-10922 (5462 slots) master
1 additional replica(s)
S: be7e9fd3b7d096b037306bc14e1017150fa59d7a 127.0.0.1:7004
slots: (0 slots) slave
replicates e0e8dfddd4e9d855090d6efd18e55ea9c0e1f7aa
M: 226d1af3c95bf0798ea9fed86373b89347f889da 127.0.0.1:7006
slots: (0 slots) master
1 additional replica(s)
M: ec964a7c7cd53b986f54318a190c1426fc53a5fa 127.0.0.1:7002
slots:10923-16383 (5461 slots) master
1 additional replica(s)
S: 88e16f91609c03277f2ee6ce5285932f58c221c1 127.0.0.1:7005
slots: (0 slots) slave
replicates ec964a7c7cd53b986f54318a190c1426fc53a5fa
S: 38910c5baafea02c5303505acfd9bd331c608cfc 127.0.0.1:7003
slots: (0 slots) slave
replicates 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
观察6-8行、15-17行，说明7007已经是7006的slave。
十、reshard 重新划分slot
增加新的节点之后，问题就来了，16384个slot已经被其它3组节点分完了，新节点没有slot，没办法存放缓存，所以需要将slot重新分布。
➜ src ./redis-trib.rb info 127.0.0.1:7000
127.0.0.1:7000 (0b7e0d53...) -> 4 keys | 5461 slots | 1 slaves.
127.0.0.1:7001 (e0e8dfdd...) -> 4 keys | 5462 slots | 1 slaves.
127.0.0.1:7006 (226d1af3...) -> 0 keys | 0 slots | 1 slaves. #7006上完全没有slot
127.0.0.1:7002 (ec964a7c...) -> 9 keys | 5461 slots | 1 slaves.
[OK] 17 keys in 4 masters.
0.00 keys per slot on average.
用下面的命令可以重新分配slot
./redis-trib.rb reshard 127.0.0.1:7000
reshard后面的IP:port，只要是在cluster中的有效节点即可。
➜ src ./redis-trib.rb reshard 127.0.0.1:7000
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e 127.0.0.1:7000
slots:1792-4095 (2304 slots) master
0 additional replica(s)
...
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 1000 #这里输入要移动多少slot
What is the receiving node ID? 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e #这里输入目标节点的id
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1:all #将所有node都当成源节点
...
Moving slot 4309 from ec964a7c7cd53b986f54318a190c1426fc53a5fa
Moving slot 4310 from ec964a7c7cd53b986f54318a190c1426fc53a5fa
Moving slot 4311 from ec964a7c7cd53b986f54318a190c1426fc53a5fa
Moving slot 4312 from ec964a7c7cd53b986f54318a190c1426fc53a5fa
Moving slot 4313 from ec964a7c7cd53b986f54318a190c1426fc53a5fa
Do you want to proceed with the proposed reshard plan (yes/no)? yes #确认执行
注：第一个交互询问，填写多少slot移动时，要好好想想，如果填成16384，则将所有slot都移动到一个固定节点上，会导致更加不均衡！建议每次移动500~1000，这样对线上的影响比较小。
另外在填写source node时，除了all之外，还可以直接填写源节点的id，即：
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 300
What is the receiving node ID? 0b7e0d5337e87ac7b59bba4c1248e5c9e8d1905e
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1:226d1af3c95bf0798ea9fed86373b89347f889da #这里填写源节点的id
Source node #2:done #这里输入done表示，不再继续添加源节点了
reshard可以多次操作，直到达到期望的分布为止(注：个人觉得redis的reshard这里有点麻烦，要移动多少slot需要人工计算，如果能提供一个参数之类，让16384个slot自动平均分配就好了)，调整完成后，可以再看看分布情况：
➜ src ./redis-trib.rb info 127.0.0.1:7000
127.0.0.1:7000 (0b7e0d53...) -> 4 keys | 4072 slots | 0 slaves.
127.0.0.1:7001 (e0e8dfdd...) -> 5 keys | 4099 slots | 0 slaves.
127.0.0.1:7006 (226d1af3...) -> 5 keys | 4132 slots | 4 slaves.
127.0.0.1:7002 (ec964a7c...) -> 3 keys | 4081 slots | 0 slaves.
[OK] 17 keys in 4 masters.
0.00 keys per slot on average.
十一、删除节点del-node
既然有扩容，就会有反向需求，某些节点不再需要时，可以用del-node删除，比如刚才我一阵乱倒腾后，发现7006已经有4个slave了，而其它master一个slave都没有，这明显不合理。
删除节点命令：
./redis-trib.rb del-node 127.0.0.1:7006 88e16f91609c03277f2ee6ce5285932f58c221c1
del-node后面的ip:port只要是cluster中有效节点即可，最后一个参数为目标节点的id，注意：只有slave节点和空的master节点可以删除，如果master非空，先用reshard把上面的slot移动到其它node后再删除，如果有一组master-slave节点，将master上所有slot移到其它节点，然后将master删除，剩下的slave会另寻他主，变成其它master的slave。
另外:删除节点的含义，不仅仅是从cluster中将这个节点移除，还会直接将目标节点的redis服务停止。