亲热接触Redis-次日（Redis Sentinel）

时间 2019-11-21

原文原文链接

简单介绍

通过上次轻松搭建了一个Redis的环境并用Java代码调通后。此次咱们要来看看Redis的一些坑以及Redis2.8之后带来的一个新的特性即支持高可用特性功能的Sentinel（哨兵）。html

Redis的一些坑

Redis是一个很优秀的NoSql，它支持键值对，查询方便，被大量应用在Internet的应用中。它即可以用做Http Session的分离如上一次举例中的和Spring Session的结合。还可以直接配置在Tomcat中和Tomcat容器结合并可以本身主动使用Redis做Session盛载器，同一时候它也可以做为一个分布式缓存。java

Redis是单线程工做的

这边的单线程不是指它就是顺序式工做的，这边的单线程主要关注的是Redis的一个很重要的功能即“持久化”工做机制。node

Redis一般会使用两种持久化工做机制，这样的工做机制假设在单个Redis Node下工做是没有意义的，所以你必需要有两个Redis Nodes，如：

linux

IP	端口	身份
192.168.56.101	7001	主节点
192.168.56.101	7002	备节点

RDB模式
AOF模式

Redis所谓的持久化就是在N个Redis节点间进行数据同步用的，因为在复杂的网络环境下Redis服务有时会崩溃，此时主备结构就成了高可用方案中最常用的一种手段，那么在主机宕机时，备机顶上此时会存在一个主机和备机间数据同步的问题。最好的状况是备机可以保有主机中所有的数据以便在主机宕掉时无差别的为客户进行着持续化的服务。所以Redis会使用RDB和AOF模式来保持多个Redis节点间的数据同步。

RDB

RDB 的长处:

RDB 是一个很紧凑（compact）的文件。它保存了 Redis 在某个时间点上的数据集。

这样的文件很适合用于进行备份：比方说，你可以在近期的 24 小时内，每小时备份一次 RDB 文件。并且在每个月的每一天，也备份一个 RDB 文件。web

这样的话。即便赶上问题，也可以随时将数据集还原到不一样的版本号。RDB 很适用于灾难恢复（disaster recovery）：它仅仅有一个文件，并且内容都很紧凑。可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时惟一要作的就是 fork 出一个子进程，而后这个子进程就会处理接下来的所有保存工做，父进程无须运行不论什么磁盘 I/O 操做。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点:
假设你需要尽可能避免在server故障时丢失数据，那么 RDB 不适合你。尽管 Redis 赞成你设置不一样的保存点（save point）来控制保存 RDB 文件的频率，但是，因为RDB 文件需要保存整个数据集的状态。因此它并不是一个轻松的操做。redis

所以你可能会至少 5 分钟才保存一次 RDB 文件。在这样的状况下，一旦发生问题停机，你就可能会丢失好几分钟的数据。spring

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工做。数据库

在数据集比較庞大时， fork() 可能会很耗时。形成server在某某毫秒内中止处理client；假设数据集很巨大。并且 CPU 时间很紧张的话，那么这样的中止时间甚至可能会长达整整一秒。尽管 AOF 重写也需要进行 fork() ，但不管 AOF 重写的运行间隔有多长，数据的耐久性都不会有不论什么损失。apache

AOF

AOF 的长处:
使用 AOF 持久化会让 Redis 变得很耐久（much more durable）：你可以设置不一样的 fsync 策略。比方无 fsync ，每秒钟一次 fsync 。或者每次运行写入命令时 fsync 。

AOF 的默认策略为每秒钟 fsync 一次，在这样的配置下，Redis 仍然可以保持良好的性能，并且就算发生问题停机，也最多仅仅会丢失一秒钟的数据（ fsync 会在后台线程运行。因此主线程可以继续努力地处理命令请求）。windows

AOF 文件是一个仅仅进行追加操做的日志文件（append only log）。所以对 AOF 文件的写入不需要进行 seek ，即便日志因为某些缘由而包括了未写入完整的命令（比方写入时磁盘已满，写入中途停机。等等）， redis-check-aof 工具也可以轻易地修复这样的问题。

Redis 可以在 AOF 文件体积变得过大时，本身主动地在后台对 AOF 进行重写：重写后的新 AOF 文件包括了恢复当前数据集所需的最小命令集合。整个重写操做是绝对安全的，因为 Redis 在建立新 AOF 文件的过程当中，会继续将命令追加到现有的 AOF 文件里面，即便重写过程当中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件建立完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并開始对新 AOF 文件进行追加操做。AOF 文件有序地保存了对数据库运行的所有写入操做，这些写入操做以 Redis 协议的格式保存。所以 AOF 文件的内容很easy被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也很easy：举个样例。假设你不当心运行了 FLUSHALL 命令，但仅仅要 AOF 文件未被重写，那么仅仅要中止server，移除 AOF 文件末尾的 FLUSHALL 命令。并从新启动 Redis 。就可以将数据集恢复到 FLUSHALL 运行以前的状态。

AOF 的缺点:
对于一样的数据集来讲。AOF 文件的体积一般要大于 RDB 文件的体积。

依据所使用的 fsync 策略。AOF 的速度可能会慢于 RDB 。

在普通状况下，每秒 fsync 的性能依旧很高，而关闭 fsync 可以让 AOF 的速度和 RDB 同样快。即便在高负荷之下也是如此。只是在处理巨大的写入加载时。RDB 可以提供更有保证的最大延迟时间（latency）。AOF 在过去之前发生过这样的 bug ：因为个别命令的缘由，致使 AOF 文件在又一次加载时，没法将数据集恢复成保存时的原样。

（举个样例，堵塞命令 BRPOPLPUSH 就之前引发过这样的 bug 。）測试套件里为这样的状况增长了測试：它们会本身主动生成随机的、复杂的数据集。并经过又一次加载这些数据来确保一切正常。

尽管这样的 bug 在 AOF 文件里并不常见。但是对照来讲， RDB 差点儿是不可能出现这样的 bug 的。

RDB 和 AOF间的选择

通常来讲,假设想达到足以媲美 PostgreSQL 的数据安全性，你应该同一时候使用两种持久化功能。假设你很关心你的数据,但仍然可以承受数分钟之内的数据丢失，那么你可以仅仅使用 RDB 持久化。有许多用户都仅仅使用 AOF 持久化，但咱们并不推荐这样的方式：因为定时生成 RDB 快照（snapshot）很便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此以外，使用 RDB 还可以避免以前提到的 AOF 程序的 bug 。

如我在上篇中所述，RDB与AOF可以同一时候启用，那么就作到了“数据高同步不丢失”的效果。但是你会应此付出高昂的网络IO开销，因为在使用AOF进行数据同步时形成的网络读写也是开销很大的。

所以这就要看你的设计了。通常来讲一个设计不可以因为缓冲服务宕了或者不可用了而影响到整个应用不能使用。假设设计成这样那么这样的架构是比較糟糕的。

举一例来讲：

用户登陆后正在操做。他正在查询着订单，当中有一部分数据来自于缓存，这时缓存死了。用户的查询行为此时应该被导向至DB而等缓存被恢复后才应该又一次去查缓存。固然假设在缓存中找不到相关的信息天然仍是应该去找数据库，对不正确？

所以你的伪代码应该是：

object=queryFromCache();

if(object==null||queryFromCache throw any exception)
{
  object=queryFromDB();
}

假设因为缓存服务不存在而在queryFromCache时抛错一个exception以至于页面直接回一个HTTP 500 error给用户那是至关的不合理的。

所以，在缓存服务中止时你的DB在缓存被恢复前是需要顶出去的，假设说你的DB连这点时间都不能顶。那就需要好好的来优化你的DB内的操做了。

再举一例来讲：

在一主一备的缓存环境下。用户正在訪问。此时主缓存server宕机了，备用机顶上去了，而此时当中有7-10分钟左右数据丢失。这样的数据丢失不该该影响用户的连续性操做即用户不该该感受到有服务切换的这样的感受比方说：要求用户又一次作一个什么操做，这样的设计是不正确的。所以你的设计上要有冗余，比方说用户正在操做时此时一切都在master nodes中，而此时master nodes忽然崩溃了你的slave nodes顶上时在设计上你要赞成用户可以丢失缓存中的数据这样的形为，比方说可以用DB顶上，或者是用二级缓存。或者是用内存数据库。。

。bla...bla...bla...这里详细就要看业务了。

上面说了这些，并不是说咱们就可以所以不追求数据同步完整性了。而是要回到Redis这个坑，即数据同步时的一个坑。

Redis它是单线程的，当master和slave在正常工做时everything ok。它会保持着两个节点中数据主要的同步，假设你开了AOF那你的同步率会很高。

但是，一旦当master宕机时。slave会变成master，这时它会使用它自己所在文件夹内的RDB文件来做为持久化的入口，此时仍是everything ok，接着那台原先宕机的旧master又一次被恢复后。

。。此时这台旧的master上的RDB文件和从slave位置被提高成master(new master）间的RDB文件的出入，是否是就会比較高啊。

。。

所以此时old master会试图和新的master进行RDB间的数据同步。而这个同步。。。是很要命的，假设你的用户并发量很大。在一瞬时内你的rdb增加的会很高。所以当两个redis nodes在同步RDB文件时就会直接把你的现在的new master（原来的slave）搞死进而搞死你的old master（原来的master），因为它是单线程的，大数据量在同步时它会ban掉不论什么的訪问请求。

所以。在设有master & slave模式环境内的redis，请必定记得把配置文件里的这一行： slave-serve-stale-data 设置为 yes。

来看看slave-server-stale-data为何要设成yes的缘由吧：

1) 假设 slave-serve-stale-data 设置成 'yes' (the default) slave会仍然响应client请求,此时可能会有问题。

2) 假设 slave-serve-stale data设置成 'no' slave会返回"SYNC with master in progress"这样的错误信息。

但 INFO 和SLAVEOF命令除外。

想一下，当master-slave节点在因为master节点有问题作切换时，此时不管是因为slave在被提高(promopted）到master时需要同步数据仍是因为原有的master在宕机后再恢复而被decreased成了slave而同步new master数据时形成的“堵塞”。假设此时slave-server-stale-data设成了no。

。。那么你将会没有一个可用的redis节点进而把整个环境搞死。

所以这也是为何我上面要说设计上不能过多依赖于Redis的缘由，它仅仅因该是你一个锦上添花的东西，是一个辅助手段。

THP（Transparent Huge Pages）

这也是Redis的一个坑。来看看什么是THP吧，Transparent Huge Pages。

Redis是安装在Linux上的一个服务

Linux自己的页大小是固定的4KB，在2.6.38内核新增了THP，透明地支持huge page（2MB）的使用，并且默认开启。

开启THP的优点在于:

下降page fault。一次page fault可以加载更大的内存块.。
更小的页表。一样的内存大小，需要更少的页。
因为页表更小，虚拟地址到物理地址的翻译也更快。

劣势在于:

下降分配内存效率。需要大块、连续内存块，内核线程会比較激进的进行compaction。解决内存碎片，加重锁争用。
下降IO吞吐。因为swapable huge page。在swap时需要切分红原有的4K的页。Oracle的測试数据显示会下降30%的IO吞吐。

对于redis而言。开启THP的优点：fork子进程的时间大幅下降。fork进程的主要开销是拷贝页表、fd列表等进程数据结构。
因为页表大幅较小（2MB / 4KB = 512倍）,fork的耗时也会大幅下降。

劣势在于: fork以后。父子进程间以copy-on-write方式共享地址空间。假设父进程有大量写操做，并且不具备locality，会有大量的页被写。并需要拷贝。同一时候。因为开启THP，每个页2MB。会大幅增长内存拷贝。

针对这个特性，我作了一个測试，分别在开启和关闭THP的状况下，測试redis的fork、响应时间。

測试条件：redis数据集大小20G， rdb文件大小4.2G 我用jmeter作了100个并发乘1万的压力測试。測试过程当中写要比读频繁。

fork时间对照开启THP后，fork大幅下降。
超时次数对照开启THP后，超时次数明显增多。但是每次超时时间较短。
而关闭THP后。仅仅有4次超时，缘由是与fork在同一事件循环的请求受到fork的影响。关闭THP影响的仅仅是零星几个请求，而开启后，尽管超时时间短了，但是影响面扩大了进而致使了整个Linux系统的不稳定。

所以，针对上述状况，建议你们在Linux系统中发一条这个命令：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Redis的maxmemory 0的问题

Redis配置文件里的这一行表明Redis会使用系统内存，你不应去限制Redis的内存开销如：JVM中的-xmx这个參数，而是要让Redis本身主动去使用系统的内存以得到最高的性能，所以咱们会把这个值设成0即表明无限使用系统内存，系统内存有多少咱们用多少。默认它启动后会消耗掉1个G的系统自有内存。

所以linux系统中有一个系统參数叫overcommit_memory，它表明的是内存分配策略，可选值为：0、一、2。

0，表示内核将检查是否有足够的可用内存供应用进程使用；假设有足够的可用内存，内存申请赞成；不然，内存申请失败，并把错误返回给应用进程。
1，表示内核赞成分配所有的物理内存。而不管当前的内存状态怎样。

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

因此咱们结合咱们的Redis使用如下的linux命令：

echo 1 > /proc/sys/vm/overcommit_memory

上述两条命令发完后不要完了刷新系统内存策略，所以咱们接着发出一条命令

sysctl -p

Redis在Linux系统中Too many open files的问题

有时位于系统訪问高峰时间段突发的大量请求致使redis链接数过大。你会收到这样的错误信息：

Too many open files.

这是因为频繁訪问Redis时形成了TCP链接数打开过大的主要缘由, 这是因为Redis源代码中在accept tcp socket时的实现里面遇到句柄数不够的处理方法为：留在下次处理，而不是断开TCP链接。

但这一行为就会致使监听套接字不断有可读消息，但却accept没法接受，从而listen的backlog被塞满。从而致使后面的链接被RST了。

这里我多啰嗦一下也就是Redis和Memcached的比較。memcached对于这样的状况的处理有点特殊，或者说周到！

假设memcache accept 的时候返回EMFILE，那么它会立刻调用listen(sfd, 0) ，也就是将监听套接字的等待accept队列的backlog设置为0，从而拒绝掉这部分请求。减轻系统负载。保全自我。

所以为了对付这个too many open files问题咱们需要在Linux下作点小动做来改变ulimit的配置。

改动/etc/security/limits.conf

经过 vi /etc/security/limits.conf改动其内容。在文件最后增长（数值也可以自定义）：

* soft  nofile = 65535
* hard  nofile = 65535

改动/etc/profile

经过vi /etc/profile改动，在最后增长如下内容

ulimit -n 65535

改动完后从新启动Linux系统。

经过上述一些设置，咱们基本完毕了Redis在作集群前的准备工做了，如下就来使用Redis的Sentinel来作咱们的高可用方案吧。

使用Redis Sentinel来作HA

sentinel是一个管理redis实例的工具，它可以实现对redis的监控、通知、本身主动故障转移。sentinel不断的检測redis实例可否够正常工做。经过API向其它程序报告redis的状态，假设redis master不能工做，则会本身主动启动故障转移进程，将当中的一个slave提高为master，其它的slave又一次设置新的masterserver。
sentinel是一个分布式系统。在源代码包的src文件夹下会有redis-sentinel命令。你甚至还可以在多台机器上部署sentinel进程。共同监控redis实例。

一个Master可以有多个Slave。
Redis使用异步复制。从2.8開始。Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度。
不只主server可以有从server，从server也可以有本身的从server，多个从server之间可以构成一个图状结构。
复制在Master端是非堵塞模式的。这意味着即使是多个Slave运行首次同步时。Master依旧可以提供查询服务。
复制在Slave端也是非堵塞模式的：假设你在redis.conf作了设置，Slave在运行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回client一个错误提示；
当Slave要删掉旧的数据集，并又一次加载新版数据时，Slave会堵塞链接请求（通常发生在与Master断开重连后的恢复阶段）；
复制功能可以单纯地用于数据冗余（data redundancy），也可以经过让多个从server处理仅仅读命令请求来提高扩展性（scalability）：比方说。繁重的 SORT 命令可以交给附属节点去运行。
可以经过改动Master端的redis.config来避免在Master端运行持久化操做（Save），由Slave端来运行持久化。

Redis Sentinel规划

考虑到大多数学习者环境有限。咱们使用例如如下配置：

IP	端口	身份
192.168.56.101	7001	master
192.168.56.101	7002	slave
192.168.56.101	26379	sentinel

因此咱们在一台server上安装3个文件夹：

redis1-相应master
redis2-相应slave
redis-sentinel相应sentinel。它使用26379这个端口来监控master和slave

所以咱们使用redis-stable源代码包来如此构建咱们的实验环境

make PREFIX=/usr/local/redis1 install
make PREFIX=/usr/local/redis2 install
make PREFIX=/usr/local/redis-sentinel install

如下给出sentinel的配置

Sentinel中的配置

更改/usr/local/redis-sentinel/bin/sentinel.conf文件：

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor master1 192.168.56.101 7001 1
sentinel down-after-milliseconds master1 1000
sentinel failover-timeout master1 5000
#sentinel can-failover master1 yes #remove from 2.8 and aboved version

daemonize yes – 之后台进程模式运行
port 26379 – 哨兵的端口号。该端口号默以为26379，不得与不论什么redis node的端口号反复
logfile “/var/log/redis/sentinel.log“ – log文件所在地
sentinel monitor master1 192.168.56.101 7001 1 – （第一次配置时）哨兵对哪一个master进行监測，此处的master1为一“别名”可以随意如sentinel-26379，而后哨兵会经过这个别名后的IP知道整个该master内的slave关系。所以你不用在此配置slave是什么而由哨兵本身去维护这个“链表”。
sentinel monitor master1 192.168.56.101 7001 1 – 这边有一个“1”，这个“1”表明当新master产生时，同一时候进行“slaveof”到新master并进行同步复制的slave个数。在salve运行salveof与同步时，将会终止client请求。此值较大。意味着“集群”终止client请求的时间总和和较大。此值较小,意味着“集群”在故障转移期间，多个salve向client提供服务时仍然使用旧数据。咱们这边仅仅想让一个slave来作此时的响应以取得较好的client体验。
sentinel down-after-milliseconds master1 1000 – 假设master在多少秒内无反应哨兵会開始进行master-slave间的切换。使用“选举”机制
sentinel failover-timeout master1 5000 – 假设在多少秒内没有把宕掉的那台master恢复，那哨兵以为这是一次真正的宕机。而排除该宕掉的master做为节点选取时可用的node而后等待必定的设定值的毫秒数后再来探測该节点是否恢复，假设恢复就把它做为一台slave增长哨兵监測节点群并在下一次切换时为他分配一个“选取号”。
#sentinel can-failover master1 yes #remove from 2.8 and aboved version – 该功能已经从2.6版之后去除，所以凝视掉，网上的教程不适合于redis-stable版

在配置Redis Sentinel作Redis的HA场景时，必定要注意如下几个点：

除非有多机房HA场景的存在，坚持使用单向连接式的master->slave的配置如：node3->node2->node1，把node1设为master
假设sentinel（哨兵）或者是HA群从新启动，必定要使用如此顺序：先启master，再启slave，再启哨兵
第一次配置完毕“哨兵”HA群时每次启动不需要手动再去每个redis node中去更改master slave这些參数了。哨兵会在第一次启动后记录和动态改动每个节点间的关系。第一次配置好启动“哨兵”后由哨兵之后自行维护普通状况下不需要人为干涉，假设切换过一次master/slave后也因该记得永远先起master再起slave再起哨兵这个顺序，详细当前哪一个是master可以直接看哨兵的sentinel.conf文件里最末尾哨兵自行的记录

Redis Master和Redis Slave的配置

这部分配置除了端口号。所在文件夹。pid文件与log文件不一样其它配置一样，所以如下仅仅给出一份配置：

daemonize yes

pidfile "/var/run/redis/redis1.pid"

port 7001

tcp-backlog 511
timeout 0

tcp-keepalive 0

loglevel notice

logfile "/var/log/redis/redis1.log"

databases 16


save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error no
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/usr/local/redis1/data"

slave-serve-stale-data yes
slave-read-only yes #slave仅仅读,当你的应用程序试图向一个slave写数据时你会获得一个错误

repl-diskless-sync no

repl-disable-tcp-nodelay no

slave-priority 100

maxmemory 0


appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"


# appendfsync always
#appendfsync everysec
appendfsync no #关闭AOF


no-appendfsync-on-rewrite yes


auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

aof-load-truncated yes

lua-time-limit 5000


slowlog-log-slower-than 10000


slowlog-max-len 128

latency-monitor-threshold 0

notify-keyspace-events "gxE"

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

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

当中：

slave-read-only yes 咱们把slave设成仅仅读,当你的应用程序试图向一个slave写数据时你会获得一个错误
appendfsync no 咱们关闭了AOF功能

这是192.168.56.101:7001master上的配置。你要把192.168.56.101:7002做为slave，那很easy，你仅仅需要在redis2的配置文件的最未尾增长一句：

slaveof 192.168.56.101 7001

配完了master, slave和sentinel后。咱们依照这个顺序来启动redis HA：

master->slave->sentinel

启动后咱们经过windowsclient使用命令：

redis-cli -p 26379 -h 192.168.56.101

进入咱们配置好的sentinel后并使用： info命令来查看咱们的redis sentinel HA配置。

可以看到眼下它的master为7001，它有一个slave。

为了确认。咱们另外开一个command窗体，经过：

redis-cli -p 7001 -h 192.168.56.101

进入到7001后再使用redis内部命令info replication来查看相关信息

咱们还可以经过命令：

redis-cli -h 192.168.56.101 -p 7002

进入到7002中并经过info replication来查看7002内的状况：

好了，环境有了，咱们接下来要使用：

模拟代码
模拟并发測试工具

来測一下咱们这个redis sentinel了的本身主动故障转移功能了。

使用 Spring Data + Jedis来訪问咱们的Redis Sentinel

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>webpoc</groupId>
	<artifactId>webpoc</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>war</packaging>
	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<java.version>1.8</java.version>
		<jetty.version>9.3.3.v20150827</jetty.version>
		<slf4j.version>1.7.7</slf4j.version>
		<spring.version>4.2.1.RELEASE</spring.version>
		<spring.session.version>1.0.2.RELEASE</spring.session.version>
		<javax.servlet-api.version>2.5</javax.servlet-api.version>
		<activemq_version>5.8.0</activemq_version>
		<poi_version>3.8</poi_version>
	</properties>
	<dependencies>
		<!-- poi start -->
		<dependency>
			<groupId>org.apache.poi</groupId>
			<artifactId>poi</artifactId>
			<version>${poi_version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.poi</groupId>
			<artifactId>poi-ooxml-schemas</artifactId>
			<version>${poi_version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.poi</groupId>
			<artifactId>poi-scratchpad</artifactId>
			<version>${poi_version}</version>
		</dependency>
		<dependency>
			<groupId>org.apache.poi</groupId>
			<artifactId>poi-ooxml</artifactId>
			<version>${poi_version}</version>
		</dependency>
		<!-- poi end -->
		<!-- active mq start -->
		<dependency>
			<groupId>org.apache.activemq</groupId>
			<artifactId>activemq-all</artifactId>
			<version>5.8.0</version>
		</dependency>

		<dependency>
			<groupId>org.apache.activemq</groupId>
			<artifactId>activemq-pool</artifactId>
			<version>${activemq_version}</version>
		</dependency>

		<dependency>
			<groupId>org.apache.xbean</groupId>
			<artifactId>xbean-spring</artifactId>
			<version>3.16</version>
		</dependency>
		<!-- active mq end -->

		<!-- servlet start -->
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>servlet-api</artifactId>
			<version>${javax.servlet-api.version}</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>javax.servlet.jsp</groupId>
			<artifactId>jsp-api</artifactId>
			<version>2.1</version>
			<scope>provided</scope>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.2</version>
		</dependency>
		<!-- servlet end -->

		<!-- redis start -->
		<dependency>
			<groupId>redis.clients</groupId>
			<artifactId>jedis</artifactId>
			<version>2.7.2</version>
		</dependency>
		<dependency>
			<groupId>org.redisson</groupId>
			<artifactId>redisson</artifactId>
			<version>1.0.2</version>
		</dependency>
		<!-- redis end -->
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>jcl-over-slf4j</artifactId>
			<version>${slf4j.version}</version>
		</dependency>
		<dependency>
			<groupId>org.slf4j</groupId>
			<artifactId>slf4j-log4j12</artifactId>
			<version>${slf4j.version}</version>
		</dependency>

		<!-- spring conf start -->
		<dependency>
			<groupId>org.springframework.data</groupId>
			<artifactId>spring-data-redis</artifactId>
			<version>1.6.2.RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-webmvc</artifactId>
			<version>${spring.version}</version>
			<exclusions>
				<exclusion>
					<groupId>commons-logging</groupId>
					<artifactId>commons-logging</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-tx</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-aop</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context-support</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-orm</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-jms</artifactId>
			<version>${spring.version}</version>
		</dependency>

		<dependency>
			<groupId>org.springframework.session</groupId>
			<artifactId>spring-session</artifactId>
			<version>${spring.session.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<!-- spring conf end -->
	</dependencies>
	<build>
		<sourceDirectory>src</sourceDirectory>
		<plugins>
			<plugin>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.1</version>
				<configuration>
					<source>1.7</source>
					<target>1.7</target>
				</configuration>
			</plugin>
			<plugin>
				<artifactId>maven-war-plugin</artifactId>
				<version>2.4</version>
				<configuration>
					<warSourceDirectory>WebContent</warSourceDirectory>
					<failOnMissingWebXml>false</failOnMissingWebXml>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

applicationContext.xml文件

<?
xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:jee="http://www.springframework.org/schema/jee" xmlns:tx="http://www.springframework.org/schema/tx"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xsi:schemaLocation="  
            http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd  
            http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

	<context:property-placeholder location="classpath:/spring/redis.properties" />
	<context:component-scan base-package="org.sky.redis">
	</context:component-scan>

	<bean id="jedisConnectionFactory"
		class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
		<constructor-arg index="0" ref="redisSentinelConfiguration" />
		<constructor-arg index="1" ref="jedisPoolConfig" />
	</bean>

	<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
		<property name="maxTotal" value="${redis.maxTotal}" />
		<property name="maxIdle" value="${redis.maxIdle}" />
		<property name="maxWaitMillis" value="${redis.maxWait}" />
		<property name="testOnBorrow" value="${redis.testOnBorrow}" />
		<property name="testOnReturn" value="${redis.testOnReturn}" />
	</bean>
	<bean id="redisSentinelConfiguration"
		class="org.springframework.data.redis.connection.RedisSentinelConfiguration">
		<property name="master">
			<bean class="org.springframework.data.redis.connection.RedisNode">
				<property name="name" value="master1" />
			</bean>
		</property>
		<property name="sentinels">
			<set>
				<bean class="org.springframework.data.redis.connection.RedisNode">
					<constructor-arg name="host" value="192.168.56.101" />
					<constructor-arg name="port" value="26379" />
				</bean>
			</set>
		</property>
	</bean>

	<bean id="redisTemplate" class="org.springframework.data.redis.core.StringRedisTemplate">
		<property name="connectionFactory" ref="jedisConnectionFactory" />
	</bean>

	<!--将session放入redis -->
	<bean id="redisHttpSessionConfiguration"
		class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
		<property name="maxInactiveIntervalInSeconds" value="1800" />
	</bean>
	<bean id="customExceptionHandler" class="sample.MyHandlerExceptionResolver" />
</beans>

当中：

<property name="master">
			<bean class="org.springframework.data.redis.connection.RedisNode">
				<property name="name" value="master1" />
			</bean>
</property>

此处的master1需要与sentinel中的名字一致：

sentinel down-after-milliseconds master1 1000

redis.properties文件

# Redis settings

redis.host.ip=192.168.56.101
redis.host.port=7001
  

redis.maxTotal=1000  
redis.maxIdle=100
redis.maxWait=2000
redis.testOnBorrow=false
redis.testOnReturn=true

redis.sentinel.addr=192.168.56.101:26379

SentinelController.java文件

package sample;

import java.util.HashMap;
import java.util.Map;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.data.redis.core.BoundHashOperations;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RequestMapping;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
import util.CountCreater;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

/**
 * Created by xin on 15/1/7.
 */
@Controller
public class SentinelController {
	private final Logger logger = LoggerFactory.getLogger(this.getClass());
	@Autowired
	private StringRedisTemplate redisTemplate;

	@RequestMapping("/sentinelTest")
	public String sentinelTest(final Model model,
			final HttpServletRequest request, final String action) {
		return "sentinelTest";
	}

	@ExceptionHandler(value = { java.lang.Exception.class })
	@RequestMapping("/setValueToRedis")
	public String setValueToRedis(final Model model,
			final HttpServletRequest request, final String action)
			throws Exception {
		CountCreater.setCount();
		String key = String.valueOf(CountCreater.getCount());
		Map mapValue = new HashMap();
		for (int i = 0; i < 1000; i++) {
			mapValue.put(String.valueOf(i), String.valueOf(i));
		}
		try {
			BoundHashOperations<String, String, String> boundHashOperations = redisTemplate
					.boundHashOps(key);
			boundHashOperations.putAll(mapValue);
			logger.info("put key into redis");
		} catch (Exception e) {
			logger.error(e.getMessage(), e);
			throw new Exception(e);
		}

		return "sentinelTest";
	}

}

这个controller假设返回success会跳转到一个叫/page/sentinelTest.jsp文件里，它的内容例如如下：

sentinelTest.jsp文件

<%@ page language="java" contentType="text/html; charset=UTF-8"
	pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; UTF-8">
<title>test sentinel r/w</title>
</head>
<body>

</body>
</html>

这个jsp文件的<title>内含有 test sentinel r/w字样，咱们在后面的jmeter压力測试中就会用一个assertion（断言）来推断此字样以示SentinelController成功跳转。假设在jmeter的assertion中没有读到controller跳转后的response中有此字样，那么这个请求即为failed。

測试代码运行

把工程编译后启动起来，启动前不要忘了依照master->slave->sentinel的顺序来启动redis的sentinel HA群。

启动后咱们訪问

http://localhost:8080/webpoc/setValueToRedis

看到咱们的eclipse控制台有这一行输出。表明咱们的sentinel群和代码已经完美合起来了。

因而咱们分别登陆master和slave来查看咱们刚才插的值

可以看到，在master被插入值后。slave从master处同步了相应的值过来。

測试master不可訪问时sentinel的本身主动切换

咱们现在的状况为：

master-7001
slave-7002

因而。咱们在Linux中发出一条命令

这条命令表明封闭192.168.56.101上的7001端口到达不论什么地方的路由，即人为形成了一次master服务的“宕机”。

先来看eclipse中控制台的状况：

看到没有。。。

jedispool to master at 192.168.56.101:7002，7002已经变成master了。

再来看咱们的redis。看。

。

。7001上的服务不可用已经被咱们位于26379端口的哨兵探測到了，它已经把7002变成master了。

不信，咱们再登陆7002来看一下咱们的服务

那么咱们可以确认，从7001宕机后7002已经从slave变成了master。

因而，咱们在linux端打开sentinel.conf文件看一下，它已经发生了变化。这个变化是sentinel本身本身主动往配置文件里增长的内容：

现在，咱们把7001又一次“恢复”起来，所以咱们发出例如如下的命令：

此刻咱们再来登陆7001来看看它变成什么状态了：

看。

。。7001恢复后从原来的old master成了new slave了。

那么sentinel究竟作了什么，咱们来看看sentinel的log日志一探究竟吧：

咱们再来看看redis1中的redis.conf文件里的内容：

再来看看redis2中的redis.conf文件

以上实验成功，咱们如下就用jmeter来进行大并发用户操做下的sentinel切换吧。

使用jmter模拟大并发用户操做下的故障本身主动转移

压力測试计划

在个人jmeter測试计划中我增长了4个监听器，它们分别为：

TPS值
summary report
表格查看结果
树形查看结果

咱们现在就来去选这个以 ” 100个并发以每秒一次的请求来点击这个SentinelController并永远点击下去“ 的压力測试吧，在測试时咱们会有意将master搞宕。

点击菜单中的”运行->启动“，不一会咱们可以看到jmeter中的TPS与Summary Report中的数字開始飞速转动了起来。

人为有益形成一次宕机

咱们现在的master为7002, 7001为slave，所以，咱们就把7002搞“崩”吧。

再看来jmeter中的TPS显示：

经过TPS咱们可以发觉有蓝色的线，这表明“出错率”，这个出错率应该是7002在“崩”掉后，7001从slave升级成master时redis对client没法及时响应时抛出的HTTP 500即service unavailable的错。

经过Summary Report咱们可以看到在主从切换的那一刻咱们的fail rate为千分之0.5，这个fail rate是全然可以在接受范围内的，通常错误率在千分之中的一个就已经很好了。

可以看到咱们在搞“死”7002时。7001本身主动顶到了master的位置并及时响应了用户的请求。要知道咱们这个測试仅仅是在一台4GB的虚拟出来的Linux Fedora22上进行的redis 一主一备的sentinel測试，可以达到这个測试结果已是至关的perfect了。

因而咱们登陆一下7001来看看

咱们可以看到，7001成了master了。

因而咱们”恢复“7002。

它便本身成了slave了。而此时7001做为new master正在承担着client的訪问。

结束今天的教程。