亲热接触Redis-第二天（Redis Sentinel）

简单介绍

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

Redis的一些坑

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

Redis是单线程工作的

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

Redis通常会使用两种持久化工作机制，这样的工作机制假设在单个Redis Node下工作是没有意义的，因此你必须要有两个Redis Nodes，如：

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 文件。

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

RDB 的缺点:
假设你须要尽量避免在server故障时丢失数据，那么 RDB 不适合你。 尽管 Redis 同意你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 可是， 由于RDB 文件须要保存整个数据集的状态。 所以它并非一个轻松的操作。

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

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

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

AOF

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

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

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的优势在于:

1.  降低page fault。一次page fault能够加载更大的内存块.。
2. 更小的页表。同样的内存大小，须要更少的页。
3. 由于页表更小，虚拟地址到物理地址的翻译也更快。    

• 劣势在于:

1. 降低分配内存效率。须要大块、连续内存块，内核线程会比較激进的进行compaction。解决内存碎片，加剧锁争用。
2. 降低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、1、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实例。

1. 一个Master能够有多个Slave。
2. Redis使用异步复制。从2.8開始。Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度。
3. 不仅主server能够有从server， 从server也能够有自己的从server， 多个从server之间能够构成一个图状结构。
4. 复制在Master端是非堵塞模式的。这意味着即便是多个Slave运行首次同步时。Master依旧能够提供查询服务。
5. 复制在Slave端也是非堵塞模式的：假设你在redis.conf做了设置，Slave在运行首次同步的时候仍能够使用旧数据集提供查询；你也能够配置为当Master与Slave失去联系时，让Slave返回client一个错误提示；
6. 当Slave要删掉旧的数据集，并又一次加载新版数据时，Slave会堵塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
7. 复制功能能够单纯地用于数据冗余（data redundancy），也能够通过让多个从server处理仅仅读命令请求来提升扩展性（scalability）： 比方说。 繁重的 SORT 命令能够交给附属节点去运行。
8. 能够通过改动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的訪问。

结束今天的教程。