sky_551

高性能网站架构利器--redis必杀技

1、redis简介

2、redis主从复制实现

3、sentinel集群管理工具实现redis的高可用性

4、redis cluster

4.1、redis cluster环境搭建

4.2、redis cluster增加节点

4.3、redis cluster删除节点

4.4、redis cluster主从手动切换

5、总结

1、redis简介

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。---来自百度百科

从redis官网上的介绍上看，redis是一个开放源代码，遵循BSD许可的内存数据结构存储，可用作数据库缓存和消息代理。它支持的数据结构不像memcached那么单一，redis支持丰富的数据结构，如： strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries。redis支持复制，Lua脚本、基于LRU的内存回收机制，并支持事务，而且还支持不同级别上的数据持久性，并支持高可用集群和自动分区功能。

redis客户端支持许多语言的连接，如下图：

图片来自：http://redis.io/clients

2、redis主从复制实现

目前redis稳定的版本为3.0.4，此版本修复了上一版本中的一些bug，并增加了一些新的特性，如果你想了解更多关于这方面的内容请移步https://raw.githubusercontent.com/antirez/redis/3.0/00-RELEASENOTES。

redis的单节点运行这里将不再单独演示，这些内容在接下来的演示中也可发现，本节主要讲解redis的主从复制的实现。redis的主从复制是非常简易用的配置，在这种环境下，主节点允许从节点精确的拥有一份数据的副本，这也是软件主从架构的重要的一个特性吧，如果这个特性都没有，那何谈主从。接下来看看redis主从架构的一些特性：

a、主从复制是异步进行的，从redis 2.8开始，从节点将定期的告知主节点从节点复制进程的复制量；

b、一主可以拖多从；

c、从节点可以作为其他从节点的主节点，这一点是不是与mysql很像；

d、从节点在进行复制操作时，主节点这端是非阻塞的，在进行复制的过程中主节点可以可以断续处理查询，觉得这些说得都比较��嗦；

e、在复制过程中，从节点也是非阻塞的，如果在主节点的一个数据已被改变，而从节点还没有被复制更新，那redis可以选择是以老版本中的数据来响应还是返回一个错误给客户端，这是可以在redis的配置文件中指定的；

f、在主从复制架构中，为了均衡redis的性能的数据的持久性，可以把主节点配置为不持久化数据，这样少了许多把数据写入磁盘的开销，而在从节点上启用数据的持久性，这些我都是可以在配置文件中指定。

总结起来，redis的主从架构与mysql的些类似，在最后一点中关于数据的持久性问题上，在实际环境中是不建议关闭主节点的数据持久化功能，因为当主节点出现故障而自动重启后，存放在内存中的数据被释放，如果没有数据持久化，主节点就没有任何数据，那从节点也会把自己清空。

至于主从架构的实现原理作为运维人员不必再细究了。

配置一个节点成为主节点的从节点是非常简单的，只需要在从节点的配置文件是增加“slaveof 主节点IP 端口”，默认时从节点是只读的，是由“slave-read-only yes”来控制。

再来考虑一个问题，是任何一个节点都可以成为主节点的从吗？当然不是，redis也有认证机制来解决这个问题，默认时是没有启用此功能，若想启用此功能，在redis.conf配置文件中启用“requirepass 密码”参数，在将成为从节点的redis上可以用redis-cli客户端工具连接到redis中执行“config set masterauth 密码”来成为主节点的从，当然这样的配置只是临时生效，若想永久生效还是去修改配置文件吧。

言归正传，下边开始搭建redis主从复制环境，先交待一下实验的基础环境：

OS	IP	hostname	角色
Debian 8 x64	192.168.207.128	master	主
Debian 8 x64	192.168.207.130	slave01	从

主节点配置：

root@master:~/tools# pwd
/root/tools
root@master:~/tools# cat /etc/issue
Debian GNU/Linux 8 \n \l
root@master:~/tools# uname -r
3.16.0-4-amd64
root@master:~/tools# hostname
master
root@master:~/tools# pwd
/root/tools
root@master:~/tools# ls
redis-3.0.4.tar.gz
root@master:~/tools# tar xf redis-3.0.4.tar.gz -C /usr/local/
root@master:~/tools# cd /usr/local/redis-3.0.4/
root@master:/usr/local/redis-3.0.4# ls
00-RELEASENOTES  CONTRIBUTING  depsMakefile   README      runtest runtest-sentinel  src utils
BUGS COPYING       INSTALLMANIFESTO  redis.conf  runtest-clustersentinel.conf  tests
#可以参考一下README文件，有具体的安装方法
root@master:/usr/local/redis-3.0.4# ls src/redis     #列出src目录下以redis开头的文件，现在是没有redis的启动程序和客户端连接工具的
redisassert.h       redis.c             redis-check-dump.c  redis.h            
redis-benchmark.c   redis-check-aof.c   redis-cli.c         redis-trib.rb  
root@master:/usr/local/redis-3.0.4#  make   #直接编译即可
最后输出：
Hint: It's a good idea to run 'make test' ;)
make[1]: Leaving directory '/usr/local/redis-3.0.4/src'
表示安装成功，上边建议运行make test进行检测
root@master:/usr/local/redis-3.0.4# make test
cd src && make test
make[1]: Entering directory '/usr/local/redis-3.0.4/src'
You need tcl 8.5 or newer in order to run the Redis test
Makefile:211: recipe for target 'test' failed
make[1]: *** [test] Error 1
make[1]: Leaving directory '/usr/local/redis-3.0.4/src'
Makefile:6: recipe for target 'test' failed
make: *** [test] Error 2
#上边报错了，是需要tcl依赖包，如果你真想运行make test那请自行安装tcl包后再执行检测命令，我这里略过做make test的操作。
root@master:/usr/local/redis-3.0.4# ls src/redis   #和make之前相比多了一些文件
redisassert.h       redis.c             redis-check-dump    redis-cli.c         redis-sentinel      
redis-benchmark     redis-check-aof     redis-check-dump.c  redis-cli.o         redis-server        
redis-benchmark.c   redis-check-aof.c   redis-check-dump.o  redis.h             redis-trib.rb      
redis-benchmark.o   redis-check-aof.o   redis-cli           redis.o

这样redis就编译安装成功了，先来运行一下看redis是否能正确启动，命令如下：

root@master:/usr/local/redis-3.0.4# src/redis-server redis.conf
                _._                                                  
           _.-``__ ''-._                                            
      _.-``    `.  `_.  ''-._           Redis 3.0.4 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 5078
  `-._    `-._  `-./  _.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                  
      `-._    `-.__.-'    _.-'                                      
          `-._        _.-'                                          
              `-.__.-'                                              
5078:M 30 Sep 11:59:04.708 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
5078:M 30 Sep 11:59:04.708 # Server started, Redis version 3.0.4
5078:M 30 Sep 11:59:04.708 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
5078:M 30 Sep 11:59:04.709 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
5078:M 30 Sep 11:59:04.709 * The server is now ready to accept connections on port 6379

这样redis运行了，但它默认是在前台运行的，从上边的启动的输出信息中可以看到三个“WARNING”信息，请不要忽略这些信息，你不理睬它，那在生产环境下，你就给自己或者其他同事挖了一个坑。

先来看第一个WARNING信息“The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128”大概是说somaxconn的值128设置过小，从“ /proc/sys/net/core/somaxconn”这个路径也可大概知道这个值的设置是关于网络连接中某个最大值的限定设置，此值表示网络连接的队列大小，在配置文件redis.conf中的“tcp-backlog 511”就配置在高并发环境下的最大队列大小，此值受限于系统的somaxconn与tcp_max_syn_backlog这两个值，所以应该把这两个内核参数值调大，具体解决方法如下：

root@master:~# vim /etc/sysctl.conf    #在最后增加以下内容
#最大队列长度，应付突发的大并发连接请求
net.core.somaxconn = 65535
#半连接队列长度，此值受限于内存大小
net.ipv4.tcp_max_syn_backlog = 20480
root@master:~# sysctl -p   #使修改生效
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 20480

做了以上修改后，再重新启动redis进行测试，发现第一个WARNING敬告信息已无，接下处理第二个WARNING信息“WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect”根据提示可知默认时overcommit_memory是被设置为0的，在主机配置较少内存时，redis运行可能出现故障，根据提示就可修复，在 /etc/sysctl.conf文件最后加上“vm.overcommit_memory = 1”后重新启动redis即可，操作如下：

root@master:~# vim /etc/sysctl.conf 
#最大队列长度，应付突发的大并发连接请求
net.core.somaxconn = 65535
#半连接队列长度，此值受限于内存大小
net.ipv4.tcp_max_syn_backlog = 20480
#内存分配策略
vm.overcommit_memory = 1

说明：overcommit_memory的值有三个，0、1、2。

0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何，这里表示的所有内存是受限于overcommit_ratio值的，值是一个百分比，在Debian8上/proc/sys/vm/overcommit_ratio的默认值是50，那把overcommit_memory配置为1时，那系统可分配的内存为“物理内存+物理内存*50%”

2，表示内核允许分配超过所有物理内存和交换空间总和的内存

root@master:~# sysctl -p   #使其生效
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 20480
vm.overcommit_memory = 1

再把redis进程杀掉，重新启动测试，发现关于overcommit_memory的告警已无。最后再来处理关于“ Transparent Huge Pages (THP)”的告警，这是一个关于透明内存巨页的话题，简单来说内存可管理的最小单位是page，一个page通常是4kb，那1M内存就会有256个page，CPU通过内置的内存管理单元管理page表记录。Huge Pages就是表示page的大小已超过4kb了，一般是2M到1G，它的出现主要是为了管理超大内存，个人理解上TB的内存。而THP就是管理Huge Pages的一个抽象层次，根据一些资料显示，THP会导致内存锁影响性能，所以一般建议关闭此功能。

“/sys/kernel/mm/transparent_hugepage/enabled”有三个值，如下：

root@master:/usr/local/redis-3.0.4# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
####
# always 尽量使用透明内存，扫描内存，有512个 4k页面可以整合，就整合成一个2M的页面
# never 关闭，不使用透明内存
# madvise 避免改变内存占用

关于THP的内容就介绍到这里，现在根据警告信息去修改，再重新启动redis测试一下告警是否消除，操作如下：

root@master:/usr/local/redis-3.0.4# echo never > /sys/kernel/mm/transparent_hugepage/enabled
root@master:/usr/local/redis-3.0.4#vim /etc/rc.local   
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
echo "echo never > /sys/kernel/mm/transparent_hugepage/enabled"   #加入开机启动，写在exit 0之前
exit 0
root@master:/usr/local/redis-3.0.4# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

再停止redis，重新启动redis：

root@master:/usr/local/redis-3.0.4# src/redis-server redis.conf
                _._                                                  
           _.-``__ ''-._                                            
      _.-``    `.  `_.  ''-._           Redis 3.0.4 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 5666
  `-._    `-._  `-./  _.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                  
      `-._    `-.__.-'    _.-'                                      
          `-._        _.-'                                          
              `-.__.-'                                              
5666:M 30 Sep 16:53:06.570 # Server started, Redis version 3.0.4
5666:M 30 Sep 16:53:06.570 * DB loaded from disk: 0.000 seconds
5666:M 30 Sep 16:53:06.570 * The server is now ready to accept connections on port 6379
#现在redis已无任何警告信息

到现在redis启动后还是在前台运行，我们再开一个窗口用redis客户端工具连接后做一个简单的测试，如下：

root@master:/usr/local/redis-3.0.4/src# pwd
/usr/local/redis-3.0.4/src
root@master:/usr/local/redis-3.0.4/src# ./redis-cli -p 6379
127.0.0.1:6379> get foo
(nil)
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> get foo
"bar"

到这里redis单节点就可以正常工作了，接下来真正部署一个主从架构的redis集群，主从节点都按上边的的方法编译安装即可，只是在配置文件上略有区别而已，为了便于调试在配置文件中我先配置了“daemonize yes”（让redis启动后在后台运行）和“logfile "/var/log/redis.log"”（打印日志）。

先启动主节点：

root@master:/usr/local/redis-3.0.4# src/redis-server redis.conf
root@master:/usr/local/redis-3.0.4# ss -tnl | grep 6379
LISTEN     0      511                       *:6379                     *:*    
LISTEN     0      511                      :::6379                    :::*

然后配置从节点的redis.conf，确保启用“slaveof 192.168.207.128 6379"，接着就启动从节点，再去观察主节点的日志文件会发现有类似如下信息输出：

root@master:/usr/local/redis-3.0.4# tailf /var/log/redis.log
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                  
      `-._    `-.__.-'    _.-'                                      
          `-._        _.-'                                          
              `-.__.-'                                              
869:M 01 Oct 10:47:12.566 # Server started, Redis version 3.0.4
869:M 01 Oct 10:47:12.567 * DB loaded from disk: 0.000 seconds
869:M 01 Oct 10:47:12.567 * The server is now ready to accept connections on port 6379
869:M 01 Oct 10:47:44.213 * Slave 192.168.207.130:6379 asks for synchronization     #发现有从节点来连接
869:M 01 Oct 10:47:44.214 * Full resync requested by slave 192.168.207.130:6379
869:M 01 Oct 10:47:44.215 * Starting BGSAVE for SYNC with target: disk
869:M 01 Oct 10:47:44.215 * Background saving started by pid 880   #因从节点是第一次来连接，所以主节点会启动一个后台保存进程去保存数据
880:C 01 Oct 10:47:44.229 * DB saved on disk   #数据已保存到disk
880:C 01 Oct 10:47:44.230 * RDB: 0 MB of memory used by copy-on-write
869:M 01 Oct 10:47:44.284 * Background saving terminated with success
869:M 01 Oct 10:47:44.284 * Synchronization with slave 192.168.207.130:6379 succeeded   #数据已同步

在主节点的日志输出中有类似下边的输出信息（都很容易理解，就不再一一解释）：

1172:S 01 Oct 10:47:43.285 # Server started, Redis version 3.0.4
1172:S 01 Oct 10:47:43.295 * DB loaded from disk: 0.010 seconds
1172:S 01 Oct 10:47:43.295 * The server is now ready to accept connections on port 6379
1172:S 01 Oct 10:47:44.284 * Connecting to MASTER 192.168.207.128:6379
1172:S 01 Oct 10:47:44.285 * MASTER <-> SLAVE sync started
1172:S 01 Oct 10:47:44.285 * Non blocking connect for SYNC fired the event.
1172:S 01 Oct 10:47:44.285 * Master replied to PING, replication can continue...
1172:S 01 Oct 10:47:44.286 * Partial resynchronization not possible (no cached master)
1172:S 01 Oct 10:47:44.288 * Full resync from master: 127f65ef8fa67fd0fd33093ee44a88fe06bd4e6a:1
1172:S 01 Oct 10:47:44.357 * MASTER <-> SLAVE sync: receiving 29 bytes from master
1172:S 01 Oct 10:47:44.358 * MASTER <-> SLAVE sync: Flushing old data
1172:S 01 Oct 10:47:44.358 * MASTER <-> SLAVE sync: Loading DB in memory

接下来就测试主从是否真的能工作，在主节点上用客户端工具连接到redis，做以下操作：

root@master:/usr/local/redis-3.0.4/src# ./redis-cli -p 6379
127.0.0.1:6379> set key01 value01
OK
127.0.0.1:6379> get key01
"value01"

再到从节点上看是否能获取到”key01“的值：

root@slave01:/usr/local/redis-3.0.4/src# ./redis-cli -p 6379
127.0.0.1:6379> get key01
"value01"
127.0.0.1:6379> set key02 value02
(error) READONLY You can't write against a read only slave.

测试证明我们搭建的主从redis是能正常工作的，而在从节点上尝试进行写入操作时也是不被允许的，这是不是与mysql的机制类似，我想只要是主从复制的机制，从节点都应该不能被写入吧。

3、sentinel集群管理工具实现redis的高可用性

主从复制搭建是非常简单的事情，它如mysql主从复制一样当主节点挂掉后，在短时间无法恢复时我们可以手工切换到从节点，能在尽可短的时间内恢复业务。但主从复制始终在出现故障时会有一段时间redis不能上线，那是否有更好方法能让各个redis节点在监测到主节点挂掉后能不用人工干预就能把一个从节点自动提升为主节点？sentinel就是这样一个工具。

sentinel管理工具有如下功能：

a、监视：sentinel会定期的监控主从redis的实例进程是否在正常工作；

b、通知：sentinel可能通过API向管理员发送出现问题的redis实例；

c、自动故障转移：sentinel监控到主节点不能正常工作后，可以在多个从节点中选举出一个节点成为新的主节点，而其他的从节点就会以新的主节点作为自己的主，这一切都不需要人为干预；

d、Configuration provider（我译为：配置可服务能力）：表示在sentinel管理的redis集群的环境下客户端是与sentinel实例进行连接，当主节点发生故障后会重新在从节点中选举出一个节点作为主，那sentinel有能力向客户端告知新的master地址。

sentinel是一个分步式系统，它被设计成多个sentinel进程协合工作，我理解就是在运行有一个redis进程的环境下也运行着一个与之相关的sentinel进程，这样设计有什么优点呢？

a、主节点的不可用是由多个sentinel协同认定的（我猜想从多个人中选举出一个作为新主时也是多个sentinel协同完成的），这样可避免误判主节点的不可用的发生；

b、即使不是所有的sentinel实例都在正常工作也不会影响业务，这样就避免了单点故障。

现在我们就来搭建一个sentinel的高可用环境。在搭建前我需要说明的一些信息：第一、redis的节点数大于等于3；第二、因实验环境中只有两debian的虚拟机，所以我这里的3个节点都是搭建在两个主机上，只是在192.168.207.130主机上运行了2个redis实例；第三、这次我以一个普通用户来搭建，这更与实际生产环境相似。规划如下：

主机	角色	redis及sentinel所在目录	redis实例监听端口	sentinel实例监听端口
192.168.207.128	主节点	/home/redis/redis6379	6379	26379
192.168.207.130	从节点	/home/redis/redis6380	6380	26380
192.168.207.130	从节点	/home/redis/redis6381	6381	26381

现在我们就按上表的规划把redis搭建好。还记得最开始编译安装redis的过程吧，redis编译后我们所需要的文件就是生成在了源码目录下的src目录中，而配置文件就在源码所在目录，对于想把redis运行起来我们只需要这些文件即可了，如果你已不记得是哪些文件了，那就回到源码目录运行”make PREFIX=/tmp/redis install“就可以把编译后的可执行文件都copy到/tmp/redis目录下，所以这次我只把这些文件拷贝到上表规划的相应目录中。在进行下边操作前记得把开始启动的redis进程杀掉。

主机192.168.207.128上的操作：

redis@master:~$ whoami
redis
redis@master:~$ pwd
/home/redis
redis@master:~$ mkdir redis6379
redis@master:~$ cd redis6379/
redis@master:~/redis6379$ cp -r /tmp/redis/bin ./
redis@master:~/redis6379$ cp /usr/local/redis-3.0.4/redis.conf /usr/local/redis-3.0.4/sentinel.conf ./
redis@master:~/redis6379$ ls
bin  redis.conf  sentinel.conf
redis@master:~/redis6379$ mkdir log   #这里我创建一个单独的日志目录来存放redis的日志，当然配置文件也应当做相应的修改，略
redis@master:~/redis6379$ ls bin/
redis-benchmark  redis-check-aof  redis-check-dump  redis-cli  redis-sentinel  redis-server
redis@master:~/redis6379$ bin/redis-server redis.conf   #启动redis

看见上边的” sentinel.conf “这个配置文件了吧，这个文件就是sentinel实例运行时需要加载的配置文件，下边简单介绍一下它的常用配置：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

第一行表示监视名为mymaster的主服务器，ip是127.0.0.1，端口是6379，而那个”2“表示的是法定票数，简单来说就是把这个主服务器判定为失效是需要2个sentinel进程同意，如果没有2个sentinel进程，那故障将不会转移，在高可用分步式环境中这个值一般设置为超过半数的节点；

第二行中的down-after-milliseconds表示sentinel判断一个主节点不可用时的超时时间，单位为毫秒；

第三行的failover-timeout表示故障转移的超时时间，这个在配置文档中有注释信息，但个人E文不好，没有看得太懂；

第四行的parallel-syncs表示当选举出新的master后，最多允许多少个从连接到新的master进行数据复制，当从重新连接新的master进行数据同步时，以前的数据将会被清空，此时从服务器不将具有被查询的能力，所以建议保持默认值。

此配置文件中没有slave的相关配置，只需要指定主节点就可以了，当你把sentile都启动后，sentile会自己配置各个从节点到这个配置文件中，也就是说sentinel有一定自我维护此配置文件的能力。说了这么多，下边就让我们动手实验一下：

192.168.207.128节点上的sentinel配置如下：

redis@master:~/redis6379$ grep -v "^#" sentinel.conf | grep -v "^$"
port 26379
dir /tmp
sentinel monitor mymaster 192.168.207.128 6379 2   #我只是把默认的ip地址换成了真实的接口地址，其他保持默认
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
配置好后，启动sentinel，如下操作：
redis@master:~/redis6379$ bin/redis-sentinel sentinel.conf
                _._                                                  
           _.-``__ ''-._                                            
      _.-``    `.  `_.  ''-._           Redis 3.0.4 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 1573
  `-._    `-._  `-./  _.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                  
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                  
      `-._    `-.__.-'    _.-'                                      
          `-._        _.-'                                          
              `-.__.-'                                              
1573:X 01 Oct 15:24:49.865 # Sentinel runid is a99b3228db674545eec6dcf4be2934520e469a3a
1573:X 01 Oct 15:24:49.865 # +monitor master mymaster 192.168.207.128 6379 quorum 2
#sentinel启动后也是在前台的，在调试阶段可以让标准输出重定向到一个文件中，就像记录日志文件一样，这样也便于观察sentinel的启动过程，我这里就让它在前台运行。

而在192.168.207.130节点上的redis配置和sentinel配置只是在端口设定上不同而已，这里就不再赘述了，但要说明的一点是一个主机上运行着多个redis实例，记得要把pid文件得改一下，两个实例可不能共享一个pid文件，建议就修改到自己的家目录里，并且在文件上做好标识，一眼就知道这是哪个redis进程的PID文件，在192.168.207.130的两个redis实例的redis.conf文件中不要忘记配置"slaveof 192.168.207.128 6379"指向主节点，因为它们可是主节点的从实例，配置过程就不再给出了。

在192.168.207.130节点上的目录结构是这样的，如下：

redis@slave01:~$ ls
redis6380  redis6381
redis@slave01:~$ tree
.
├── redis6380
│   ├── bin
│   │   ├── redis-benchmark
│   │   ├── redis-check-aof
│   │   ├── redis-check-dump
│   │   ├── redis-cli
│   │   ├── redis-sentinel -> redis-server
│   │   └── redis-server
│   ├── dump.rdb
│   ├── log
│   │   └── redis6380.log
│   ├── redis6380.pid
│   ├── redis.conf
│   └── sentinel.conf
└── redis6381
    ├── bin
    │   ├── redis-benchmark
    │   ├── redis-check-aof
    │   ├── redis-check-dump
    │   ├── redis-cli
    │   ├── redis-sentinel -> redis-server
    │   └── redis-server
    ├── log
    │   └── redis6381.log
    ├── redis6381.pid
    ├── redis.conf
    └── sentinel.conf

注：记得一定要按照上表细心的修改redis.conf和sentinel.conf文件

把所有节点的redis和sentinel启动好后在启动sentinel的窗口中会打印一些启动的日志信息，这里把三个实例的日志信息罗列出来，如下：

redis6379：

1644:X 01 Oct 15:40:12.692 # Sentinel runid is e3bc2b0fc1cba2a12b9c9234d2983ab58a2df1e0
1644:X 01 Oct 15:40:12.693 # +monitor master mymaster 192.168.207.128 6379 quorum 2
1644:X 01 Oct 15:40:27.889 * +sentinel sentinel 192.168.207.130:26380 192.168.207.130 26380 @ mymaster 192.168.207.128 6379
1644:X 01 Oct 15:40:37.396 * +sentinel sentinel 192.168.207.130:26381 192.168.207.130 26381 @ mymaster 192.168.207.128 6379

redis6380：

1931:X 01 Oct 15:40:25.833 # Sentinel runid is 0b6789bc75faf4e6b4f18114ea51442c2ea79dda
1931:X 01 Oct 15:40:25.833 # +monitor master mymaster 192.168.207.128 6379 quorum 2
1931:X 01 Oct 15:40:27.288 * +sentinel sentinel 192.168.207.128:26379 192.168.207.128 26379 @ mymaster 192.168.207.128 6379
1931:X 01 Oct 15:40:37.469 * +sentinel sentinel 192.168.207.130:26381 192.168.207.130 26381 @ mymaster 192.168.207.128 6379

redis6381：

1943:X 01 Oct 15:40:35.409 # Sentinel runid is f0111604f01d66e12e7e9ddbc86d1f92eeb99587
1943:X 01 Oct 15:40:35.409 # +monitor master mymaster 192.168.207.128 6379 quorum 2
1943:X 01 Oct 15:40:37.641 * +sentinel sentinel 192.168.207.128:26379 192.168.207.128 26379 @ mymaster 192.168.207.128 6379
1943:X 01 Oct 15:40:38.271 * +sentinel sentinel 192.168.207.130:26380 192.168.207.130 26380 @ mymaster 192.168.207.128 6379

对于上边的日志输出就不想多解释了，一看就会明白sentinel在干什么事情。

接下来就来测试，分成两个部份，第一是测试三个redis实例的主从复制结构是否可用，第二才是测试sentinel高可用是否能正常工作。

主从复制测试：

redis@master:~/redis6379$ bin/redis-cli -p 6379
127.0.0.1:6379> get foo  #起初foo这个key没有值，下边的两个从节点也是
(nil)
127.0.0.1:6379> set foo bar  #赋予foo的值为bar
OK
127.0.0.1:6379> get foo  #当主节点的foo有值后，下边两个从节点也就有值了
"bar"
127.0.0.1:6379> 
redis@slave01:~/redis6380$ bin/redis-cli -p 6380
127.0.0.1:6380> get foo
(nil)
127.0.0.1:6380> get foo
"bar"
redis@slave01:~/redis6381$ bin/redis-cli -p 6381
127.0.0.1:6381> get foo
(nil)
127.0.0.1:6381> get foo
"bar"
127.0.0.1:6381>

sentinel高可用测试：

redis@master:~/redis6379$ bin/redis-cli -p 26379   
127.0.0.1:26379> sentinel master mymaster  #此命令可打印出master主节点的一些状态信息，“mymaster”是指sentinel.conf配置文件是配置的主节点名称
 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.207.128"
 5) "port"
 6) "6379"
 7) "runid"
 8) "01d41d73fcf35e1c85f6d2305c54e368fdfc3578"
 9) "flags"
10) "master"
11) "pending-commands"
12) "0"
13) "last-ping-sent"
14) "0"
15) "last-ok-ping-reply"
16) "518"
17) "last-ping-reply"
18) "518"
19) "down-after-milliseconds"
20) "30000"
21) "info-refresh"
22) "3765"
23) "role-reported"
24) "master"
25) "role-reported-time"
26) "336155"
27) "config-epoch"
28) "0"
29) "num-slaves"
30) "2"
31) "num-other-sentinels"
32) "2"
33) "quorum"
34) "2"
35) "failover-timeout"
36) "180000"
37) "parallel-syncs"
38) "1"

打印出mymaster这个组中从节点的状态信息，从下边的输出可看出有两个从节点

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "192.168.207.130:6381"
    3) "ip"
    4) "192.168.207.130"
    5) "port"
    6) "6381"
    7) "runid"
    8) "84ad88633faffd65496d232fdd5f8cd3b57836eb"
    9) "flags"
   10) "slave"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "445"
   17) "last-ping-reply"
   18) "445"
   19) "down-after-milliseconds"
   20) "30000"
   21) "info-refresh"
   22) "9710"
   23) "role-reported"
   24) "slave"
   25) "role-reported-time"
   26) "984624"
   27) "master-link-down-time"
   28) "0"
   29) "master-link-status"
   30) "ok"
   31) "master-host"
   32) "192.168.207.128"
   33) "master-port"
   34) "6379"
   35) "slave-priority"
   36) "100"
   37) "slave-repl-offset"
   38) "314641"
2)  1) "name"
    2) "192.168.207.130:6380"
    3) "ip"
    4) "192.168.207.130"
    5) "port"
    6) "6380"
    7) "runid"
    8) "b69a95dded62594ad295ced4a1f1ccefa942e901"
    9) "flags"
   10) "slave"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "445"
   17) "last-ping-reply"
   18) "445"
   19) "down-after-milliseconds"
   20) "30000"
   21) "info-refresh"
   22) "9710"
   23) "role-reported"
   24) "slave"
   25) "role-reported-time"
   26) "984624"
   27) "master-link-down-time"
   28) "0"
   29) "master-link-status"
   30) "ok"
   31) "master-host"
   32) "192.168.207.128"
   33) "master-port"
   34) "6379"
   35) "slave-priority"
   36) "100"
   37) "slave-repl-offset"
   38) "314641"

接下来我们杀掉运行在6379端口的redis实例后观察sentinel是否能正常的选举出新的主redis，同时观察各实例的日志输出就可知道当主redis挂点后到底发生了什么，如下操作：

redis@master:~/redis6379$ ps aux | grep :6379
redis       882  0.1  0.3  38976  3920 ?        Ssl  14:45   0:05 bin/redis-server *:6379    
redis      1214  0.0  0.1  12948  1980 pts/1    S+   15:34   0:00 grep :6379
redis@master:~/redis6379$ kill 882

redis 26379日志输出：

1206:X 05 Oct 15:35:37.225 # +sdown master mymaster 192.168.207.128 6379
1206:X 05 Oct 15:35:37.302 # +new-epoch 1
1206:X 05 Oct 15:35:37.304 # +vote-for-leader 3123628221014c13a37183b9e054de2fad79f4f3 1
1206:X 05 Oct 15:35:38.317 # +odown master mymaster 192.168.207.128 6379 #quorum 3/2
1206:X 05 Oct 15:35:38.317 # Next failover delay: I will not start a failover before Mon Oct  5 15:41:38 2015
1206:X 05 Oct 15:35:38.394 # +config-update-from sentinel 192.168.207.130:26381 192.168.207.130 26381 @ mymaster 192.168.207.128 6379
1206:X 05 Oct 15:35:38.394 # +switch-master mymaster 192.168.207.128 6379 192.168.207.130 6381
1206:X 05 Oct 15:35:38.395 * +slave slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.130 6381
1206:X 05 Oct 15:35:38.395 * +slave slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381
1206:X 05 Oct 15:36:08.405 # +sdown slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381

redis 26380日志输出：

1273:X 05 Oct 15:35:37.290 # +sdown master mymaster 192.168.207.128 6379
1273:X 05 Oct 15:35:37.295 # +new-epoch 1
1273:X 05 Oct 15:35:37.298 # +vote-for-leader 3123628221014c13a37183b9e054de2fad79f4f3 1
1273:X 05 Oct 15:35:37.390 # +odown master mymaster 192.168.207.128 6379 #quorum 3/2
1273:X 05 Oct 15:35:37.390 # Next failover delay: I will not start a failover before Mon Oct  5 15:41:38 2015
1273:X 05 Oct 15:35:38.388 # +config-update-from sentinel 192.168.207.130:26381 192.168.207.130 26381 @ mymaster 192.168.207.128 6379
1273:X 05 Oct 15:35:38.388 # +switch-master mymaster 192.168.207.128 6379 192.168.207.130 6381
1273:X 05 Oct 15:35:38.389 * +slave slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.130 6381
1273:X 05 Oct 15:35:38.389 * +slave slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381
1273:X 05 Oct 15:36:08.390 # +sdown slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381

redis 26381日志输出：

1278:X 05 Oct 15:35:37.230 # +sdown master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.291 # +odown master mymaster 192.168.207.128 6379 #quorum 2/2
1278:X 05 Oct 15:35:37.292 # +new-epoch 1
1278:X 05 Oct 15:35:37.292 # +try-failover master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.293 # +vote-for-leader 3123628221014c13a37183b9e054de2fad79f4f3 1
1278:X 05 Oct 15:35:37.298 # 192.168.207.130:26380 voted for 3123628221014c13a37183b9e054de2fad79f4f3 1
1278:X 05 Oct 15:35:37.299 # 192.168.207.128:26379 voted for 3123628221014c13a37183b9e054de2fad79f4f3 1
1278:X 05 Oct 15:35:37.366 # +elected-leader master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.367 # +failover-state-select-slave master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.451 # +selected-slave slave 192.168.207.130:6381 192.168.207.130 6381 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.452 * +failover-state-send-slaveof-noone slave 192.168.207.130:6381 192.168.207.130 6381 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:37.528 * +failover-state-wait-promotion slave 192.168.207.130:6381 192.168.207.130 6381 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:38.321 # +promoted-slave slave 192.168.207.130:6381 192.168.207.130 6381 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:38.321 # +failover-state-reconf-slaves master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:38.385 * +slave-reconf-sent slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:39.325 * +slave-reconf-inprog slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:39.427 # -odown master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:40.342 * +slave-reconf-done slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:40.426 # +failover-end master mymaster 192.168.207.128 6379
1278:X 05 Oct 15:35:40.426 # +switch-master mymaster 192.168.207.128 6379 192.168.207.130 6381
1278:X 05 Oct 15:35:40.426 * +slave slave 192.168.207.130:6380 192.168.207.130 6380 @ mymaster 192.168.207.130 6381
1278:X 05 Oct 15:35:40.426 * +slave slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381
1278:X 05 Oct 15:36:10.476 # +sdown slave 192.168.207.128:6379 192.168.207.128 6379 @ mymaster 192.168.207.130 6381

仔细观察上边的日志输出，会得知各个sentinel进程都发现redis6379进程已不在了，于是就把master的状态设置为sdown，当通过sentinel彼此间通讯后有大多数的sentinel都认为原master挂掉后就把原master设置为odown状态，接下就是开始故障转移的过程，在从节点中选出一个节点来作为新的master，并把其他的从节点的主节点更新为现在新的master节点（会更新sentinel.conf文件），当从节点切换到新的主节点后它会重新同步数据，这在redis实例的日志文件中可观察到详细的操作。

到此redis的高可用的实现了，原理还是比较简单，真正实现起来也是十分容易的。在真正的生产环境下连接redis集群时可不是直接与redis实例所连接，而是和多个sentinel实例连接了。

4、redis cluster

利用sentinel工具来实现redis的高可用也算是一种集群方案了，但他只是加强了redis的可用性，并没有在性能上对redis进行扩展，同一时间可服务的也只有master节点，这种主从加sentinel的架构能在一般压力环境下能够应对，但是在极高并发的环境下还是不适合，为了应用这样的高并发场景，redis在从3.0开始就支持cluster了，这才是真正意义上的分布式集群系统，他能让redis向外扩展，能让多个redis节点同步接受客户的请求操作，让数据跨跃多个节点并实现自动分片，这大大提高了系统的吞吐量。既然redis cluster是一个分布式系统，那他也遵循CAP理论，在consistency上redis节点之间的数据也是异步的。

redis cluster是一个怎样的集群系统呢？他有以下两个特性：

a、数据的分片是自动完成的；

b、当有部分（少于半数的节点）节点挂点后，系统依然可用。

redis cluster需要两个TCP端口才能工作，一个是redis实例监听的端口，默认是6379，这个端口是让客户端接入的；另一个tcp端口是redis实例端口+10000，此soket是cluster bus（集群总线），如果reids实例商品为6379，那cluster bus的端口就是16379，在此总线上节点对节点间通过二进制协议进行通信，所完成的工作有故障检查、配置更新、故障转移等。客户端工具不应该与此端口进行连接，但各个节点间应该开放此端口，若有防火墙一定要开放出来，不然集群将不能正常的工作。

在这样一个分布式集群环境下，数据是如何存放的？回想一下memcached在分布式运用上是怎样实现的呢？memcached是采用一致性hash算法实现数据的分布式存储，不明此算法的原理请翻看前边的博客。而redis cluster并没有采用一致性hash算法，而是采用了一种叫“hash slot（散列槽）”的机制。在一个cluster中共有16384个散列槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点，即各个节点负责16384个散列槽中的一个子集。hash slot的引入使得redis cluster非常容易向集群中增加节点或是减少节点，如果是增加节点，只要把现在一个节点上的一部分散列槽转移到新节点上，如果是移除节点，只要把这个节点上的散列槽移到另外的节点上，这个增加节点或移除节点都不会导致集群停止提供服务。

接下来谈一下cluster中的master-slave模式。试想一下如果把三个redis实例配置成一个cluster，那每个节点上都分配了一定数据的散列槽，当一个节点挂掉后，请问这个集群还能够正常工作吗？这个问题的答案留在最后作答，但我们明白一个节点挂掉了，那它之前所分配的散列槽就不可用了，如果上边存放有数据，客户端就无法请求到。为了在有节点挂掉后还能保持集群的高度可用，redis提供了这样的一种集群方案，可以为各可对外提供查询的redis实例配置一个从节点，当主节点挂掉后，从节点可立马提升为主节点，这样集群依然是一个完整的集群，仍然可以正常工作。既然这里又涉及到的主从，那意味着主与从的数据不可能做强一致性的，所以也有一定的机率导致数据的丢失，这一点我们也是需要明白的。如果主节点和从节点都一起挂了，那集群也就不能工作了，即在redis cluster中必须有16384个slot存在，如果任何一个节点上的slot子集有缺失，那集群将不会工作。

4.1、redis cluster环境搭建

接下来我们就动手来搭建一个redis cluster环境，来感受一下这神奇的开源项目，规划如下图：

主机	实例名	redis监听端口
192.168.207.128	redis7000	7000
192.168.207.128	redis7001	7001
192.168.207.128	redis7002	7002
192.168.207.130	redis7003	7003
192.168.207.130	redis7004	7004
192.168.207.130	redis7005	7005

依然是上边的两个主机，分别部署三个redis实例，计划让其中的三个实例当作master，另外三个分另为三个master的slave，谁做master，谁是slave这是由redis cluster自己决定的。在配置集群时需要用到“redis-trib.rb”这个ruby脚本，这个脚本在源码目录中可找到，既然是ruby脚本，那就需要ruby环境了。

各实例的目录结构类似如下，这里只列出一个：

redis@master:~$ pwd
/home/redis
redis@master:~$ tree redis7000
redis7000
├── bin
│   ├── redis-benchmark
│   ├── redis-check-aof
│   ├── redis-check-dump
│   ├── redis-cli
│   ├── redis-sentinel -> redis-server
│   ├── redis-server
│   └── redis-trib.rb
└── redis.conf

我们只需要修改各个实例目录下的redis.conf这个配置文件，各个实例的配置文件按照上表规划的做修改即可，如下：

redis@master:~/redis7000$ grep -v "^#" redis.conf  | grep -v "^$"
daemonize yes   #后台运行
pidfile /home/redis/redis7000/redis7000.pid   #pid文件
port 6000   #端口
tcp-backlog 511
bind 192.168.207.128 7000   #绑定的地址及端口
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/home/redis/redis7000/redis7000.log"   #日志文件
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes    #redis每次更新都记录到日志文件
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
cluster-enabled yes   #启用集群
cluster-config-file nodes-7000.conf   #集群配置文件
cluster-node-timeout 10000   #集群节点间通讯超时时间
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes

注意上边有注释的地方，各个实例只是配置把相应的监听端口、绑定地址等修改成自己的即可

把6个redis实例的配置文件都按照上表进行修改后，那就一一把redfis实例启动起来，确保各个实例都监听在相应的端口上。

接着再回到redis7000所在主机上，因redis-trib.rb是ruby程序，所以系统首先需要安装ruby环境，如下：

root@master:~# aptitude install -y ruby-full

再更换ruby源，你懂的，原ruby源是被墙了的，如下：

root@master:~# gem source -l
*** CURRENT SOURCES ***
https://rubygems.org/
root@master:~# gem source --remove https://rubygems.org/
https://rubygems.org/ removed from sources
root@master:~# gem source -a http://ruby.taobao.org/
http://ruby.taobao.org/ added to sources
root@master:~# gem source -l
*** CURRENT SOURCES ***
http://ruby.taobao.org/

要想使用redis-trib.rb脚本来把各个节点加入cluster还需要ruby下的redis接口的支持，所以要安装redis支持，如下：

root@master:~# gem install redis   #安装只是几秒钟的事情

接下就把各个节点加入到集群中，如下命令：

redis@master:~/redis7000$ bin/redis-trib.rb create --replicas 1 192.168.207.128:7000 192.168.207.128:7001 192.168.207.128:7002 192.168.207.130:7003 192.168.207.130:7004 192.168.207.130:7005
##命令中的“create”表示创建一个集群，“--replicas 1”表示每个master都有一个salve
>>> Creating cluster   #开始创建集群
Connecting to node 192.168.207.128:7000: OK
Connecting to node 192.168.207.128:7001: OK
Connecting to node 192.168.207.128:7002: OK
Connecting to node 192.168.207.130:7003: OK
Connecting to node 192.168.207.130:7004: OK
Connecting to node 192.168.207.130:7005: OK
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:     #自动选择出3个redis实例作为master节点和3个节点作为slave
192.168.207.128:7000
192.168.207.130:7003
192.168.207.128:7001
Adding replica 192.168.207.130:7004 to 192.168.207.128:7000
Adding replica 192.168.207.128:7002 to 192.168.207.130:7003
Adding replica 192.168.207.130:7005 to 192.168.207.128:7001
M: 7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000
   slots:0-5460 (5461 slots) master
M: 568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001
   slots:10923-16383 (5461 slots) master
S: 0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002
   replicates 8490b5e84bf0359871ea3fa55b97bb9877be0512
M: 8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003
   slots:5461-10922 (5462 slots) master
S: 9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004
   replicates 7dae923773125c5956605fac6159412850b100b3
S: f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005
   replicates 568669e03c61b3c4edc31643dcb47e85bc2c3e23
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.207.128:7000)   #检查集群状态，从结果输出中可看出只有master节点分配了hash slots
M: 7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000
   slots:0-5460 (5461 slots) master
M: 568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001
   slots:10923-16383 (5461 slots) master
M: 0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002
   slots: (0 slots) master
   replicates 8490b5e84bf0359871ea3fa55b97bb9877be0512
M: 8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003
   slots:5461-10922 (5462 slots) master
M: 9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004
   slots: (0 slots) master
   replicates 7dae923773125c5956605fac6159412850b100b3
M: f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005
   slots: (0 slots) master
   replicates 568669e03c61b3c4edc31643dcb47e85bc2c3e23
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

至此，redis cluster创建成功

接下就是测试了，这里用一种最简单的方法来测试，直接用redis-cli客户端工具，如下操作：

redis@slave01:~/redis7003$ bin/redis-cli -c -h 192.168.207.130 -p 7003     #“-c”表示是启用cluster模块
192.168.207.130:7003> get foo
-> Redirected to slot [12182] located at 192.168.207.128:7001
(nil)
192.168.207.128:7001> set foo bar
OK
192.168.207.128:7001> get foo
"bar"
192.168.207.128:7001> set key01 value01
OK
192.168.207.128:7001> get key01
"value01"
192.168.207.128:7001> set testkey testvalue
-> Redirected to slot [4757] located at 192.168.207.128:7000
OK
192.168.207.128:7000> get testkey
"testvalue"
192.168.207.128:7000>

从上边的测试来看，当我们在7003上获取foll时被定向到了7001，当在7001上设置testkey时被定向到了7000。那怎样查看一个cluster中各个节点的信息呢？运行下边的命令即可：

192.168.207.128:7000> cluster nodes
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444268798177 2 connected 10923-16383
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 slave 7dae923773125c5956605fac6159412850b100b3 0 1444268797169 5 connected
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444268796159 4 connected
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 myself,master - 0 0 1 connected 0-5460
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444268797169 6 connected
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 master - 0 1444268794141 4 connected 5461-10922
192.168.207.128:7000>

接下来测试一下cluster的可用性，我这样来测试，先去杀掉一个主节点，再查看集群的状态：

redis@master:~/redis7000$ cat redis7000.pid
2184
redis@master:~/redis7000$ kill 2184  #把7000杀掉了
redis@slave01:~/redis7003$ bin/redis-cli -c -h 192.168.207.130 -p 7003
192.168.207.130:7003> cluster nodes
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444268931560 6 connected
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 master,fail - 1444268887245 1444268883792 1 disconnected
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444268933596 4 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444268932580 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 myself,master - 0 0 4 connected 5461-10922
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 master - 0 1444268934613 7 connected 0-5460

从上边的节点信息中可知，在起初7000的从节点是7004，现在7000被kill后，7004变成了master了。

在杀掉7000前，我们设置过testkey这个key，其值为testvalue，现在7000被杀掉后来测试一下此key是否能查询，如下：

192.168.207.128:7001> get testkey
-> Redirected to slot [4757] located at 192.168.207.130:7004
"testvalue"

正确从7004上返回了testkey这个key的值。

如果现在又去把7000启动，那他就会成为7004的从了，如下：

redis@master:~/redis7000$ bin/redis-server redis.conf 
192.168.207.130:7004> cluster nodes
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444269002483 6 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444269003498 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 master - 0 1444269005530 4 connected 5461-10922
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444269006546 4 connected
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 myself,master - 0 0 7 connected 0-5460
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave 9d076e70871fc7291485aba97b2623dc9fb3b3b0 0 1444269004514 7 connected

至此，cluster高可用性已得到了验证。

4.2、redis cluster增加节点

随着业务的增长，有一天你发现现在的redis集群规模已不能满足业务需求了，你得向集群中增加节点来扩展redis cluster的处理能力。向一个redis cluster增加节点也是一件愉快的事情，当然首先你得准备好一个空的redis实例，就像我下边一样我先准备好了一个“redis7006”实例：

redis@slave01:~$ ls
redis7003  redis7004  redis7005  redis7006
redis@slave01:~$ tree redis7006
redis7006
├── bin
│   ├── redis-benchmark
│   ├── redis-check-aof
│   ├── redis-check-dump
│   ├── redis-cli
│   ├── redis-sentinel
│   ├── redis-server
│   └── redis-trib.rb
└── redis.conf

配置文件的修改就是修改一端口号、pid文件后缀、日志文件后缀这些信息，这里就不再给出。

接着把新的实例启动起来：

redis@slave01:~$ cd redis7006/
redis@slave01:~/redis7006$ bin/redis-server redis.conf

新的实例准备好了，接下就把此实例增加到集群中吧，它增加到集群中是担任master，还是担任slave呢？这都是可用参数来控制的，默认不指定时是作为master。增加节点的命令如下：

./redis-trib.rb add-node IP:PORT IP:PORT

第一个IP:PORT是指新实例的ip地址和端口号，第二个IP:PORT是指现有集群中的任意一个节点的ip地址和端口，是master可以，是slave也可以。如果增加的节点是做salve，那命令如下：

./redis-trib.rb add-node --slave IP:PORT IP:PORT

第一个IP:PORT是指新实例的ip地址和端口号，第二个IP:PORT是指集群中任意一个节点的ip地址和端口，采用这样的方式增加的slave节点我们并不能控制他是哪个节点的从，如果要想指定加入的节点是哪个节点的从节点，那如下命令：

./redis-trib.rb add-node --slave --master-id ID 
 
IP:PORT IP:PORT

不再解释上边命令了，也是很好理解的。

掌握了增加节点的命令，那就把redis7006这个实例加入到现有集群中，如下操作：

redis@master:~/redis7000$ bin/redis-trib.rb add-node 192.168.207.130:7006 192.168.207.128:7002
>>> Adding node 192.168.207.130:7006 to cluster 192.168.207.128:7002
Connecting to node 192.168.207.128:7002: OK
Connecting to node 192.168.207.130:7003: OK
Connecting to node 192.168.207.130:7004: OK
Connecting to node 192.168.207.128:7001: OK
Connecting to node 192.168.207.128:7000: OK
Connecting to node 192.168.207.130:7005: OK
>>> Performing Cluster Check (using node 192.168.207.128:7002)
S: 0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002
   slots: (0 slots) slave
   replicates 8490b5e84bf0359871ea3fa55b97bb9877be0512
M: 8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
M: 9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
M: 568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
S: 7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000
   slots: (0 slots) slave
   replicates 9d076e70871fc7291485aba97b2623dc9fb3b3b0
S: f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005
   slots: (0 slots) slave
   replicates 568669e03c61b3c4edc31643dcb47e85bc2c3e23
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
Connecting to node 192.168.207.130:7006: OK
>>> Send CLUSTER MEET to node 192.168.207.130:7006 to make it join the cluster.
[OK] New node added correctly.

成功把节点加入到集群后再来检查一下集群状态：

192.168.207.130:7003> cluster nodes
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444270807484 0 connected
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444270805452 6 connected
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave 9d076e70871fc7291485aba97b2623dc9fb3b3b0 0 1444270806468 7 connected
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444270804437 4 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444270804437 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 myself,master - 0 0 4 connected 5461-10922
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 master - 0 1444270804437 7 connected 0-5460

从上边的输出中可知redis7006已是一个master节点，但此时此节点不存放任何数据，因为它没有被分配hash slot，所以想让此节点真正的工作起来，你还得做一个切分操作，把在其他节点上的hash slot转移一部份到新增的节点上来，这个操作也是通过redis-trib.rb工具来完成的，具体用法如下：

./redis-trib.rb reshard IP:PORT

采用reshard参数表示重新切分，后边的IP:PORT是集群中任意一个节点的ip地址和端口，redis-trib.rb工具会自动寻找集群中的其他节点。

现在我们就来把7004上的2000个slot转移到7006上，如下操作：

redis@master:~/redis7000$ bin/redis-trib.rb reshard 192.168.207.128:7000
Connecting to node 192.168.207.128:7000: OK
Connecting to node 192.168.207.130:7004: OK
Connecting to node 192.168.207.130:7003: OK
Connecting to node 192.168.207.128:7002: OK
Connecting to node 192.168.207.128:7001: OK
Connecting to node 192.168.207.130:7006: OK
Connecting to node 192.168.207.130:7005: OK
>>> Performing Cluster Check (using node 192.168.207.128:7000)
S: 7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000
   slots: (0 slots) slave
   replicates 9d076e70871fc7291485aba97b2623dc9fb3b3b0
M: 9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
M: 8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
S: 0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002
   slots: (0 slots) slave
   replicates 8490b5e84bf0359871ea3fa55b97bb9877be0512
M: 568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
M: b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006
   slots: (0 slots) master
   0 additional replica(s)
S: f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005
   slots: (0 slots) slave
   replicates 568669e03c61b3c4edc31643dcb47e85bc2c3e23
[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)? 2000   #输入2000
What is the receiving node ID? b502b7efac704e92ac439933a42edf613f908fea   #输入哪个节点想接收这些slot，这里就是7006的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:9d076e70871fc7291485aba97b2623dc9fb3b3b0    #输入想从哪个节点移动slot，我这里输入了7004的ID
Source node #2:done   #输入done回车后会输出具体会移动的slot
    Moving slot 0 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
    .........略........
    Moving slot 1995 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
    Moving slot 1996 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
    Moving slot 1997 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
    Moving slot 1998 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
    Moving slot 1999 from 9d076e70871fc7291485aba97b2623dc9fb3b3b0
Do you want to proceed with the proposed reshard plan (yes/no)? yes   #执行计划，开始真正移动slot
Moving slot 0 from 192.168.207.130:7004 to 192.168.207.130:7006:
.....略.....
Moving slot 1993 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1994 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1995 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1996 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1997 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1998 from 192.168.207.130:7004 to 192.168.207.130:7006:
Moving slot 1999 from 192.168.207.130:7004 to 192.168.207.130:7006:
redis@master:~/redis7000$

移动完成后再查看一下集群状态，如下：

192.168.207.130:7003> cluster nodes
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444273978574 8 connected 0-1999    #已有2000个slot
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444273977559 6 connected
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave 9d076e70871fc7291485aba97b2623dc9fb3b3b0 0 1444273975530 7 connected
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444273977559 4 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444273975530 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 myself,master - 0 0 4 connected 5461-10922
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 master - 0 1444273976544 7 connected 2000-5460   #少了2000个solt

至此，新节点已增加到集群并能正常工作。

4.3、redis cluster删除节点

有增加节点的操作，当然也会有删除一个节点，当业务量下降后，集群中redis节点数量服务能力大大超过了业务所带来的压力，此时我们应该移除一些节点，回收主机资源，以免造成资源的浪费。

移除一个节点用如下命令：

./redis-trib.rb del-node IP:PORT 'node-id'

IP:PORT表示集群中任意一个节点的ip地址和端口，node-id表示你想要移除的节点ID号

接下来就测试一下删除一个节点的操作，我们计划把7004这个节点删除，那运行如下命令：

redis@master:~/redis7000$ bin/redis-trib.rb del-node 192.168.207.128:7000 '9d076e70871fc7291485aba97b2623dc9fb3b3b0'
>>> Removing node 9d076e70871fc7291485aba97b2623dc9fb3b3b0 from cluster 192.168.207.128:7000
Connecting to node 192.168.207.128:7000: OK
Connecting to node 192.168.207.130:7004: OK
Connecting to node 192.168.207.130:7003: OK
Connecting to node 192.168.207.128:7002: OK
Connecting to node 192.168.207.128:7001: OK
Connecting to node 192.168.207.130:7006: OK
Connecting to node 192.168.207.130:7005: OK
[ERR] Node 192.168.207.130:7004 is not empty! Reshard data away and try again.

上边报错了，说是这个节点不是空的，需要重新切片后再尝试，这是因为在这个节点上还有2000-5460的slot，需要把这些slot移走后才能删除此节点，我们就把7004上的所有slot移到7006后再来删除此节点试试：

redis@master:~/redis7000$ bin/redis-trib.rb reshard  --from 9d076e70871fc7291485aba97b2623dc9fb3b3b0 --to b502b7efac704e92ac439933a42edf613f908fea --slots 3461 --yes 192.168.207.128:7000

#上边的命令是一种非交互模块下的数据迁移命令，用“--from...--to”的结构表示从哪个节点把数据迁移到哪个节点，官方命令格式是“./redis-trib.rb reshard <host>:<port> --from <node-id> --to <node-id> --slots --yes”这样的，但在实际运用时发现“<host>:<port>”需要写在最后，这个是表示集群中任意一个节点的ip地址和端口信息。

运行上表命令并等待一会儿后，数据就迁移完毕，再来观察一下集群中7004节点的状态信息：

192.168.207.130:7004> cluster nodes
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444283310797 6 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444283307772 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 master - 0 1444283306763 4 connected 5461-10922
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444283308780 4 connected
9d076e70871fc7291485aba97b2623dc9fb3b3b0 192.168.207.130:7004 myself,master - 0 0 7 connected
     
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave 9d076e70871fc7291485aba97b2623dc9fb3b3b0 0 1444283308780 7 connected
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444283309788 8 connected 0-5460

看见了吧，上边输出信息中7004已没有slot了，现在再来移除此节点试试：

redis@master:~/redis7000$ bin/redis-trib.rb del-node 192.168.207.128:7000 '9d076e70871fc7291485aba97b2623dc9fb3b3b0'
>>> Removing node 9d076e70871fc7291485aba97b2623dc9fb3b3b0 from cluster 192.168.207.128:7000
Connecting to node 192.168.207.128:7000: OK
Connecting to node 192.168.207.130:7004: OK
Connecting to node 192.168.207.130:7003: OK
Connecting to node 192.168.207.128:7002: OK
Connecting to node 192.168.207.128:7001: OK
Connecting to node 192.168.207.130:7006: OK
Connecting to node 192.168.207.130:7005: OK
>>> Sending CLUSTER FORGET messages to the cluster...
>>> 192.168.207.128:7000 as replica of 192.168.207.130:7006
>>> SHUTDOWN the node.

移除成功了，移除后还会重新计算集群中的主从关系，并把移除的节点shutdown，这里就把7000作为7006的从节点了，再来查看集群状态就是这样了：

redis@slave01:~/redis7004$ bin/redis-cli -c -h 192.168.207.130 -p 7003
192.168.207.130:7003> cluster nodes
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444283726189 8 connected 0-5460
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444283728207 6 connected
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave b502b7efac704e92ac439933a42edf613f908fea 0 1444283725182 8 connected
     #看下他的主节点是7006
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 1444283729216 4 connected
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444283728207 2 connected 10923-16383
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 myself,master - 0 0 4 connected 5461-10922

4.4、redis cluster主从手动切换

也许在一些特殊的场景你需要切换集群中主从节点，比如你想让一个主节点下线升级维护时，当然你可简单粗爆的把这个主节点shutdown，然后redis cluster会监测到集群中少了一个主节点，集群就会把他的从节点提升为主节点，然后你再把shutdown的节点启动，那他会成为一个从节点运行，这样你就可以做你想做的了。但这样粗爆的行为是会导致集群短暂的停止服务，有一个切换的时间，如果是一个可控的维护工作，我们还是希望更为平滑，那集群中手动切换工具就能满足我们的需求。

我们先连接到集群中，查看一下集群状态信息，如下：

redis@slave01:~/redis7004$ bin/redis-cli -c -h 192.168.207.128 -p 7002
    #连接到7002从节点
192.168.207.128:7002> cluster nodes
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 master - 0 1444285238614 4 connected 5461-10922
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 myself,slave 8490b5e84bf0359871ea3fa55b97bb9877be0512 0 0 3 connected
   #7002的主节点是7003
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444285240634 2 connected 10923-16383
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444285237604 8 connected 0-5460
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave b502b7efac704e92ac439933a42edf613f908fea 0 1444285239625 8 connected
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444285239625 6 connected

接下来就进行手动切换操作，把7002与7003的主从关系调换：

192.168.207.128:7002> cluster failover
    #这就是切换命令
OK
192.168.207.128:7002> cluster nodes
8490b5e84bf0359871ea3fa55b97bb9877be0512 192.168.207.130:7003 slave 0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 0 1444285980634 9 connected
   #变成slave了
0becd52cb1fa1a69f8d3135dd98f87cd8ccf9d78 192.168.207.128:7002 myself,master - 0 0 9 connected 5461-10922
    #变成master了
568669e03c61b3c4edc31643dcb47e85bc2c3e23 192.168.207.128:7001 master - 0 1444285977604 2 connected 10923-16383
b502b7efac704e92ac439933a42edf613f908fea 192.168.207.130:7006 master - 0 1444285976594 8 connected 0-5460
7dae923773125c5956605fac6159412850b100b3 192.168.207.128:7000 slave b502b7efac704e92ac439933a42edf613f908fea 0 1444285979624 8 connected
f3ba7c62307e0321f5d21310d14027c403c73907 192.168.207.130:7005 slave 568669e03c61b3c4edc31643dcb47e85bc2c3e23 0 1444285978615 6 connected
192.168.207.128:7002>

在上边的主从切换测试中几乎是瞬间完成，这样业务是不受到影响的。值得注意的是“cluster failover”命令只能在slave节点上运行，这也是在上边我是连接到7002的原因。在主从切换时采用何种方法，这也许这就是一个优秀的运维工程师和一个菜鸟的区别吧！

5、总结

断断续续的写了好几天才完成此博文，通过此文我也对redis有了更深入的认识，也让我更能走近redis，才能发现redis之美，之强。保持一颗求的心继续上路。

参考资料：

http://redis.io/topics/replication#how-redis-replication-works

http://redis.io/topics/sentinel

https://github.com/crypt1d/redi.sh

http://www.cnblogs.com/zhaoguihua/p/redis-006.html

你可能感兴趣的:(redis,cluster,sentinel)

四章-32-点要素的聚合彩云飘过
本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
Redis系列：Geo 类型赋能亿级地图位置计算 Ly768768 redis bootstrap 数据库
1前言我们在篇深刻理解高性能Redis的本质的时候就介绍过Redis的几种基本数据结构，它是基于不同业务场景而设计的：动态字符串(REDIS_STRING)：整数(REDIS_ENCODING_INT)、字符串(REDIS_ENCODING_RAW)双端列表(REDIS_ENCODING_LINKEDLIST)压缩列表(REDIS_ENCODING_ZIPLIST)跳跃表(REDIS_ENCODI
SpringCloudAlibaba—Sentinel(限流) 菜鸟爪哇
前言：自己在学习过程的记录，借鉴别人文章，记录自己实现的步骤。借鉴文章：https://blog.csdn.net/u014494148/article/details/105484410Sentinel介绍Sentinel诞生于阿里巴巴，其主要目标是流量控制和服务熔断。Sentinel是通过限制并发线程的数量（即信号隔离）来减少不稳定资源的影响，而不是使用线程池，省去了线程切换的性能开销。当资源
华为云分布式缓存服务DCS 8月新特性发布华为云PaaS服务小智华为云分布式缓存
分布式缓存服务（DistributedCacheService，简称DCS）是华为云提供的一款兼容Redis的高速内存数据处理引擎，为您提供即开即用、安全可靠、弹性扩容、便捷管理的在线分布式缓存能力，满足用户高并发及数据快速访问的业务诉求。此次为大家带来DCS8月的特性更新内容，一起来看看吧！
02-Cesium聚合分析EntityCluster完整代码 fxshy html css javascript
1.完整代码Document-->-->Cesium.Ion.defaultAccessToken='eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJhZjZkZDAwZC1mNTFhLTRhOTEtOGExNi00MzRhNGIzMDdlNDQiLCJpZCI6MTA1MTUzLCJpYXQiOjE2NjA4MDg0Njd9.qajeJtc4-kp
Redis Key的过期策略 ArchManual 分布式架构分布式 Java 后端微服务架构 redis
Redis的过期策略主要是指管理和删除那些设定了过期时间的键，以确保内存的有效使用和数据的及时清理。具体来说，Redis有三种主要的过期策略：定期删除（ScheduledDeletion）、惰性删除（LazyDeletion）和内存淘汰策略（EvictionPolicies）。1.定期删除Redis的定期删除策略（ScheduledDeletion）的步骤如下：设置定期任务：Redis会在后台线程
Redis:缓存击穿我的程序快快跑啊缓存 redis java
缓存击穿(热点key)：部分key(被高并发访问且缓存重建业务复杂的)失效,无数请求会直接到数据库，造成巨大压力1.互斥锁：可以保证强一致性线程一：未命中之后，获取互斥锁，再查询数据库重建缓存，写入缓存，释放锁线程二：查询未命中，未获得锁(已由线程一获得)，等待一会，缓存命中互斥锁实现方式：redis中setnxkeyvalue:改变对应key的value,仅当value不存在时执行，以此来实现互
Redis 有哪些危险命令？如何防范？花小疯 redis 缓存数据库危险命令大数据
Redis有哪些危险命令？Redis的危险命令主要有以下几个：1.keys客户端可查询出所有存在的键。2.flushdb删除Redis中当前所在数据库中的所有记录，并且此命令从不会执行失败。3.flushall删除Redis中所有数据库中的所有记录，不止是当前所在数据库，并且此命令从不会执行失败。4.config客户端可修改Redis配置。怎么禁用和重命名危险命令？看下redis.conf默认配置
k8s中Service暴露的种类以及用法听说唐僧不吃肉 K8S kubernetes 容器云原生
一、说明在Kubernetes中，有几种不同的方式可以将服务（Service）暴露给外部流量。这些方式通过定义服务的spec.type字段来确定。二、详解1.ClusterIP定义：默认类型，服务只能在集群内部访问。作用：通过集群内部IP地址暴露服务。示例：spec:type:ClusterIPports:-port:80targetPo
sentinel 不显示项目_Sentinel相关问题记录 weixin_39840606 sentinel 不显示项目
SentinelFAQ整理Sentinel承接阿里巴巴近10年双十一大促流量的核心场景，以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。其提供丰富的应用场景支持、完备的监控能力、易用的拓展点。Note:中文文档请见此处。热点问题1、Q:dashboard不展示监控问题如何排查？dashboard是一个单独启动的控制台，引入sentinel的应用是一个客户端。它们各自有
Sentinel 眼泪落在琴弦 springcloud java java
Sentinel（服务熔断降级限流）1.引入spring-cloud-starter-alibaba-sentinel2.下载sentinel服务器3.配置application地址信息4.在控制台调整参数【默认所以流控设置保存在内存中，重启失效】5.想实时监控需每个微服务导入actuator，并配置application暴露所有端口6.自定义sentinel流控返回数据7.配置sentinel类
Sentinel实时监控不展示问题朱杰jjj sentinel sentinel
问题官方插件Endpoint支持，可以实时统计出SpringBoot的健康状况和请求的调用信息在使用Endpoint特性之前需要在Maven中添加spring-boot-starter-actuator依赖，并在配置中允许Endpoints的访问。SpringBoot1.x中添加配置management.security.enabled=false。暴露的endpoint路径为/sentinelS
Rides实现分布式锁，保障数据一致性,Redisson分布式事务处理朱杰jjj 缓存分布式
分布式环境下分布式锁有三种方式：基于数据库分布式锁基于Redis分布式锁基于zk分布式锁本帖只介绍Redis分布式锁为什么需要用到分布式锁？在单机环境下一个服务中多个线程对同一个事物或数据资源进行操作时，可以通过添加加锁方式（synchronized和lock）来解决数据一致性的问题。但是如果出现多个服务的情况下，这时候我们在通过synchronized和lock的方式来加锁会出现问题，因为多个服
Cloud Native Weekly | 华为云抢先发布Redis5.0，红帽宣布收购混合云提供商 weixin_34302561 数据库 devops 大数据
1——华为云抢先发布Redis5.02——DigitalOceanK8s服务正式上线3——红帽宣布收购混合云提供商NooBaa4——微软发布多项AzureKubernetes服务更新1华为云抢先发布Redis5.012月17日，华为云在DCS2.0的基础上，快人一步，抢先推出了新的Redis5.0产品，这是一个崭新的突破。目前国内在缓存领域的发展普遍停留在Redis4.0阶段，华为云率先发布了Re
华为云分布式缓存服务DCS与开源服务差异对比 hcinfo_18 redis使用华为云 Redis5.0 分布式缓存服务 Redis客户端
分布式缓存服务DCS提供单机、主备、集群等丰富的实例类型，满足用户高读写性能及快速数据访问的业务诉求。支持丰富的实例管理操作，帮助用户省去运维烦恼。用户可以聚焦于业务逻辑本身，而无需过多考虑部署、监控、扩容、安全、故障恢复等方面的问题。DCS基于开源Redis、Memcached向用户提供一定程度定制化的缓存服务，因此，除了拥有开源服务缓存数据库的优秀特性，DCS提供更多实用功能。一、与开源Red
关于Redis集群同步/持久化/淘汰机制的详解尾巴尖上的阳光大数据 redis 数据库
Redis是非常常用的KV数据库,使用内存以及HashMap进行存储的特点带来了高效的查询.本文将围绕Redis的常见开发使用场景,阐述在Redis集群中各个节点是如何进行数据同步,每个节点如何进行持久化以及在长期使用中如何对数据进行更新和淘汰.如果对Redis有更多的兴趣,可以查看我的技术博客:https://dingyuqi.com下面是Redis在开发过程中常用的几种使用场景.集群Redis
主流行架构 rainbowcheng 架构架构
nexus，gitlab,svn,jenkins,sonar,docker，apollo，catteambition，axure，蓝湖，禅道,WCP；redis，kafka，es，zookeeper，dubbo，shardingjdbc，mysql，InfluxDB，Telegraf，Grafana，Nginx，xxl-job，Neo4j,NebulaGraph是一个高性能的,NOSQL图形数据库
【YashanDB知识库】YashanDB 开机自启 YashanDB YashanDB知识库数据库数据库系统崖山数据库 YashanDB oracle
【问题分类】YashanDB开机自启【关键字】开机自启，依赖包【问题描述】数据库所在服务器重启后只拉起monit、yasom、yasom进程，缺少yasdb进程：【问题原因分析】数据库安装的时候未启动守护进程【解决/规避方法】进入数据库之前的安装目录，启动守护进程：Shellcd/home/yashan/install./bin/yasbootmonitstart--clusteryashandb
网上商城项目总结续猫只i java web 电子商城结构
前台1.用户登录注册邮箱验证校验用户名是否存在验证码自动登录2.导航条自定义标签库采用异步读取数据（使用gson将集合转换json数据）Redis服务器3.首页热门商品查询展示4.分类列表分页查询5.商品详情用cookie实现浏览记录6.购物车实现商品添加到购物车商品的查询，添加，修改，删除清空购物车7.提交订单添加订单（订单详情）确认订单（易宝支付）8.我的订单9.Fliter定义权限拦截（提交
常用类库 Guava 简介豆瑞瑞 java
简介GoogleGuava是一个由Google开发的Java开源函数库。前身是GoogleCollectionsLibrary，提供了许多简化工具，如缓存、连接器、过滤器、关联数组等仓库代码GitCode-全球开发者的开源社区,开源代码托管平台参考https://github.com/google/guavahttps://github.com/google/guava/wikiRedisStre
2024Mysql And Redis基础与进阶操作系列（8）作者——LJS[含MySQL 创建、修改、跟新、重命名、删除视图等具体详步骤；注意点及常见报错问题所对应的解决方法] 肾透侧视攻城狮 MYSQL REDIS Advance operation redis mysql 数据库 linux sql bash adb
目录1MySQL视图1.概念2.作用3.特点4.具体如何操作实现MYSQL视图4.1创建视图语法示例查看表和视图查看视图的结构查看视图属性信息（比如：显示数据表的存储引擎、版本、数据行数和数据大小等）查看视图的详细定义信息4.2修改视图简介格式举例4.3更新视图简介下述结构中不可更新的视图补充说明举例更新视图视图包含聚合函数不可更新视图包含distinct不可更新视图包含goupby、having
自定义布隆过滤器解决缓存穿透暗金烂狗缓存
什么是缓存穿透以及常见解决方案缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库，导致数据库压力提高，造成宕机。缓存穿透就是指用户访问那些在数据库和Redis中都不存在的数据，例如我们知道id采用自增策略，那么就不可能出现负数id，而如果不法分子使用负数id进行查询，那么这些请求都会穿过Redis直接向数据库发送请求，从而导致数据库压力骤增，导致数
Redis 为什么这么快？小海海不怕困难 Redis redis
决定Redis请求效率的因素主要是三个方面，分别是网络、cpu、内存。在网络层面，Redis采用多路复用的设计，提升了并发处理的连接数，不过这个阶段，Server端的所有IO操作，都是由同一个主线程处理的这个时候IO的瓶颈就会影响到Redis端的整体处理性能。所以从Redis6.0开始，在多路复用及层面增加了多线程的处理，来优化IO处理的能力不过，具体的数据操作仍然是由主线程来处理的，所以我们可以
Redis 集群確定饿的猫 redis linux
目录Redis主从复制Redis主从复制简介Redis主从复制的作用Redis主从复制流程搭建Redis主从复制master节点slave节点验证哨兵故障转移机制部署哨兵Redis集群作用数据分区高可用Redis集群Redis高可用实现的方式有持久化、主从复制、哨兵、集群，与持久化不同，另外三种方式都是属于集群，之前已经分析了解过两种持久化模式了，现在了解另外几种方式Redis主从复制Redis主
Redisson分布式锁实现原理和使用牧竹子 springboot #redis Redisson redis
常见的锁内存锁lock,synchronize分布式锁redis，zookeeper实现Redisson基于redis实现了Lock接口的分布式集群锁，是可重入锁，功能强大，源码复杂，比redis单机模式分布式锁可靠，稳定性更高，支持集群模式，支持锁根据业务时长自动延迟释放redis普通分布式锁存在一定的缺陷——它加锁只作用在一个Redis节点上，如果通过sentinel和cluster保证高可用
分布式框架Celery七(Django-Celery-Flower实现异步和定时爬虫及其监控邮件告警) yjjpp2301 Celery 分布式 django python 后端
Django中集成方式安装模块pipinstallDjango==3.2.22pipinstallcelerypipinstallredispipinstalleventlet#在windows环境下需要安装eventlet包-----------pipinstalldjango-celery-beatpipinstalldjango-celery-resultspipinstalldjango-
Redis的持久化和高可用性小辛学西嘎嘎 redis 数据库缓存
目录一、淘汰策略1、背景2、淘汰策略二、持久化1、背景2、fork进程写时复制机制3、Redis持久化方式1、aof2、rdb三、高可用1、主从复制2、Redis哨兵模式3、Rediscluster集群一、淘汰策略1、背景首先Redis是一个内存数据库，将所有数据存放在内存中，通过对K值进行hash后存储在散列表中。有一个小问题Redis数据库占96G，但为什么最终占满只有48G呢。因为中间有个过
【Redis】Redis缓存 1886i Java Redis 缓存 redis 数据库
目录一、缓存1、概念2、作用3、缺点二、缓存模型三、缓存的更新1、更新策略2、主动更新的三种模式1.cacheasidepattern2.read/writethroughpattern3.writebehindcachingpattern3、线程安全问题1.缓存删除还是更新缓存2.先删除缓存后操作数据库3.先操作数据库后删除缓存4.如何保证缓存与数据库操作同时成功或失败4、最佳选择一、缓存1、概
Windows系统下安装Redis bjzhang75 windows redis 数据库
文章目录1、下载Redis安装包2、解压压缩包3、运行Redis4、Redis连接检测5、Redis相关设置5.1设置环境变量PATH5.2Redis配置文件修改1、下载Redis安装包Windows版本的Redis可以在Github中下载：下载Redis2、解压压缩包将下载的压缩包解压到某个目录下，比如：C:\redis。3、运行Redis在cmd窗口中运行命令redis-serverredis
实现多级缓存的六种策略方法 Kixuan214 缓存 redis rabbitmq
保证多级缓存数据一致性是一个复杂的任务，尤其是在分布式和高并发环境中。以下是一些常见的方法和策略，可以帮助实现多级缓存的数据一致性1.缓存失效策略1.1主动失效在更新数据库时，主动使相关缓存失效。步骤：更新数据库删除或失效缓存publicclassCacheService{privateLocalCachelocalCache;privateRedisCacheredisCache;private
微信开发者验证接口开发 362217990 微信开发者 token 验证
微信开发者接口验证。 Token，自己随便定义，与微信填写一致就可以了。根据微信接入指南描述 http://mp.weixin.qq.com/wiki/17/2d4265491f12608cd170a95559800f2d.html 第一步：填写服务器配置第二步：验证服务器地址的有效性第三步：依据接口文档实现业务逻辑这里主要讲第二步验证服务器有效性。建一个
一个小编程题-类似约瑟夫环问题 BrokenDreams 编程
今天群友出了一题：一个数列,把第一个元素删除,然后把第二个元素放到数列的最后,依次操作下去,直到把数列中所有的数都删除,要求依次打印出这个过程中删除的数。 &
linux复习笔记之bash shell (5) 关于减号-的作用 eksliang linux关于减号“-”的含义 linux关于减号“-”的用途 linux关于“-”的含义 linux关于减号的含义
转载请出自出处： http://eksliang.iteye.com/blog/2105677 管道命令在bash的连续处理程序中是相当重要的，尤其在使用到前一个命令的studout（标准输出）作为这次的stdin（标准输入）时，就显得太重要了，某些命令需要用到文件名，例如上篇文档的的切割命令（split）、还有
Unix(3) 18289753290 unix ksh
1)若该变量需要在其他子进程执行，则可用"$变量名称"或${变量}累加内容什么是子进程？在我目前这个shell情况下，去打开一个新的shell，新的那个shell就是子进程。一般状态下，父进程的自定义变量是无法在子进程内使用的，但通过export将变量变成环境变量后就能够在子进程里面应用了。 2)条件判断： &&代表and ||代表or&nbs
关于ListView中性能优化中图片加载问题酷的飞上天空 ListView
ListView的性能优化网上很多信息，但是涉及到异步加载图片问题就会出现问题。具体参看上篇文章http://314858770.iteye.com/admin/blogs/1217594 如果每次都重新inflate一个新的View出来肯定会造成性能损失严重，可能会出现listview滚动是很卡的情况，还会出现内存溢出。现在想出一个方法就是每次都添加一个标识，然后设置图
德国总理默多克：给国人的一堂“震撼教育”课永夜-极光教育
http://bbs.voc.com.cn/topic-2443617-1-1.html德国总理默多克：给国人的一堂“震撼教育”课　安吉拉—默克尔，一位经历过社会主义的东德人，她利用自己的博客，发表一番来华前的谈话，该说的话，都在上面说了，全世界想看想传播——去看看默克尔总理的博客吧！　　德国总理默克尔以她的低调、朴素、谦和、平易近人等品格给国人留下了深刻印象。她以实际行动为中国人上了一堂
关于Java继承的一个小问题。。。随便小屋 java
今天看Java 编程思想的时候遇见一个问题，运行的结果和自己想想的完全不一样。先把代码贴出来！ //CanFight接口 interface Canfight { void fight(); } //ActionCharacter类 class ActionCharacter { public void fight() { System.out.pr
23种基本的设计模式 aijuans 设计模式
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。　　Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。　　Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。　　Builder：将一个复杂对象的构建与它的表示分离，使得同
《周鸿祎自述：我的互联网方法论》读书笔记 aoyouzi 读书笔记
从用户的角度来看,能解决问题的产品才是好产品,能方便/快速地解决问题的产品,就是一流产品. 商业模式不是赚钱模式一款产品免费获得海量用户后,它的边际成本趋于0,然后再通过广告或者增值服务的方式赚钱,实际上就是创造了新的价值链. 商业模式的基础是用户,木有用户,任何商业模式都是浮云.商业模式的核心是产品,本质是通过产品为用户创造价值. 商业模式还包括寻找需求
JavaScript动态改变样式访问技术百合不是茶 JavaScript style属性 ClassName属性
一:style属性格式: HTML元素.style.样式属性="值"; 创建菜单:在html标签中创建或者在head标签中用数组创建 <html> <head> <title>style改变样式</title> </head> &l
jQuery的deferred对象详解 bijian1013 jquery deferred对象
jQuery的开发速度很快，几乎每半年一个大版本，每两个月一个小版本。每个版本都会引入一些新功能，从jQuery 1.5.0版本开始引入的一个新功能----deferred对象。 &nb
淘宝开放平台TOP Bill_chen C++c 物流 C#
淘宝网开放平台首页：http://open.taobao.com/ 淘宝开放平台是淘宝TOP团队的产品，TOP即TaoBao Open Platform，是淘宝合作伙伴开发、发布、交易其服务的平台。支撑TOP的三条主线为： 1.开放数据和业务流程 * 以API数据形式开放商品、交易、物流等业务； &
【大型网站架构一】大型网站架构概述 bit1129 网站架构
大型互联网特点面对海量用户、海量数据大型互联网架构的关键指标高并发高性能高可用高可扩展性线性伸缩性安全性大型互联网技术要点前端优化 CDN缓存反向代理 KV缓存消息系统分布式存储 NoSQL数据库搜索监控安全想到的问题： 1.对于订单系统这种事务型系统，如
eclipse插件hibernate tools安装白糖_ Hibernate
eclipse helios(3.6)版 1.启动eclipse 2.选择 Help > Install New Software...> 3.添加如下地址： http://download.jboss.org/jbosstools/updates/stable/helios/ 4.选择性安装：hibernate tools在All Jboss tool
Jquery easyui Form表单提交注意事项 bozch jquery easyui
jquery easyui对表单的提交进行了封装，提交的方式采用的是ajax的方式，在开发的时候应该注意的事项如下： 1、在定义form标签的时候，要将method属性设置成post或者get，特别是进行大字段的文本信息提交的时候，要将method设置成post方式提交，否则页面会抛出跨域访问等异常。所以这个要
Trie tree(字典树)的Java实现及其应用-统计以某字符串为前缀的单词的数量 bylijinnan java实现
import java.util.LinkedList; public class CaseInsensitiveTrie { /** 字典树的Java实现。实现了插入、查询以及深度优先遍历。 Trie tree's java implementation.(Insert,Search,DFS) Problem Description Igna
html css 鼠标形状样式汇总 chenbowen00 html css
css鼠标手型cursor中hand与pointer Example：CSS鼠标手型效果 <a href="#" style="cursor:hand">CSS鼠标手型效果</a><br/> Example：CSS鼠标手型效果 <a href="#" style=&qu
[IT与投资]IT投资的几个原则 comsci it
无论是想在电商,软件,硬件还是互联网领域投资,都需要大量资金,虽然各个国家政府在媒体上都给予大家承诺,既要让市场的流动性宽松,又要保持经济的高速增长....但是,事实上,整个市场和社会对于真正的资金投入是非常渴望的,也就是说,表面上看起来,市场很活跃,但是投入的资金并不是很充足的......
oracle with语句详解 daizj oracle with with as
oracle with语句详解转在oracle中，select 查询语句，可以使用with,就是一个子查询，oracle 会把子查询的结果放到临时表中，可以反复使用例子:注意，这是sql语句，不是pl/sql语句，可以直接放到jdbc执行的 ----------------------------------------------------------------
hbase的简单操作 deng520159 数据库 hbase
近期公司用hbase来存储日志,然后再来分析 ,把hbase开发经常要用的命令找了出来. 用ssh登陆安装hbase那台linux后用hbase shell进行hbase命令控制台! 表的管理 1）查看有哪些表 hbase(main)> list 2）创建表 # 语法：create <table>, {NAME => <family&g
C语言scanf继续学习、算术运算符学习和逻辑运算符 dcj3sjt126com c
/* 2013年3月11日20:37:32 地点：北京潘家园功能：完成用户格式化输入多个值目的：学习scanf函数的使用 */ # include <stdio.h> int main(void) { int i, j, k; printf("please input three number:\n"); //提示用
2015越来越好 dcj3sjt126com 歌曲
越来越好房子大了电话小了感觉越来越好假期多了收入高了工作越来越好商品精了价格活了心情越来越好天更蓝了水更清了环境越来越好活得有奔头人会步步高想做到你要努力去做到幸福的笑容天天挂眉梢越来越好婆媳和了家庭暖了生活越来越好孩子高了懂事多了学习越来越好朋友多了心相通了大家越来越好道路宽了心气顺了日子越来越好活的有精神人就不显
java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Tim feiteyizu mysql
数据表中有记录的time字段（属性为timestamp）其值为：“0000-00-00 00:00:00” 程序使用select 语句从中取数据时出现以下异常： java.sql.SQLException:Value '0000-00-00' can not be represented as java.sql.Date java.sql.SQLException: Valu
Ehcache（07）——Ehcache对并发的支持 234390216 并发 ehcache 锁 ReadLock WriteLock
Ehcache对并发的支持在高并发的情况下，使用Ehcache缓存时，由于并发的读与写，我们读的数据有可能是错误的，我们写的数据也有可能意外的被覆盖。所幸的是Ehcache为我们提供了针对于缓存元素Key的Read（读）、Write（写）锁。当一个线程获取了某一Key的Read锁之后，其它线程获取针对于同
mysql中blob,text字段的合成索引 jackyrong mysql
在mysql中，原来有一个叫合成索引的，可以提高blob,text字段的效率性能，但只能用在精确查询，核心是增加一个列，然后可以用md5进行散列，用散列值查找则速度快比如： create table abc(id varchar(10),context blog,hash_value varchar(40)); insert into abc(1,rep
逻辑运算与移位运算 latty 位运算逻辑运算
源码：正数的补码与原码相同例+7 源码：00000111 补码：00000111 （用8位二进制表示一个数）负数的补码：符号位为1，其余位为该数绝对值的原码按位取反；然后整个数加1。 -7 源码： 10000111 ，其绝对值为00000111 取反加一：11111001 为-7补码已知一个数的补码，求原码的操作分两种情况：
利用XSD 验证XML文件 newerdragon java xml xsd
XSD文件（XML Schema 语言也称作 XML Schema 定义（XML Schema Definition，XSD）。具体使用方法和定义请参看： http://www.w3school.com.cn/schema/index.asp java自jdk1.5以上新增了SchemaFactory类可以实现对XSD验证的支持，使用起来也很方便。以下代码可用在J
搭建 CentOS 6 服务器(12) - Samba rensanning centos
（1）安装 # yum -y install samba Installed: samba.i686 0:3.6.9-169.el6_5 # pdbedit -a rensn new password:123456 retype new password:123456 …… （2）Home文件夹 # mkdir /etc
Learn Nodejs 01 toknowme nodejs
（1）下载nodejs https://nodejs.org/download/ 选择相应的版本进行下载（2）安装nodejs 安装的方式比较多，请baidu下我这边下载的是“node-v0.12.7-linux-x64.tar.gz”这个版本（1）上传服务器（2）解压 tar -zxvf node-v0.12.
jquery控制自动刷新的代码举例 xp9802 jquery
1、html内容部分复制代码代码示例: <div id='log_reload'> <select name="id_s" size="1"> <option value='2'>-2s-</option> <option value='3'>-3s-</option