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

亲密接触Redis-第二天（Redis Sentinel）
http://www.aboutyun.com/forum.php?mod=viewthread&tid=17673

(出处: about云开发)

问题导读





1.RDB有哪些优缺点？
2.AOF有哪些优缺点？
3.什么是THP？





简介

经过上次轻松搭建了一个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 的缺点:

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 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 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 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而等缓存被恢复后才应该重新去查缓存，当然如果在缓存中找不到相关的信息自然还是应该去找数据库，对不对？

因此你的伪代码应该是：

[AppleScript]  纯文本查看  复制代码

object = queryFromCache ( ) ;

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

如果因为缓存服务不存在而在queryFromCache时抛错一个exception以致于页面直接回一个HTTP 500 error给用户那是相当的不合理的。

因此，在缓存服务停止时你的DB在缓存被恢复前是需要顶出去的，如果说你的DB连这点时间都不能顶，那就需要好好的来优化你的DB内的操作了。

再举一例来说 ：

在一主一备的缓存环境下，用户正在访问，此时主缓存服务器宕机了，备用机顶上去了，而此时当中有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会仍然响应客户端请求,此时可能会有问题。

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系统中发一条这个命令：

[AppleScript]  纯文本查看  复制代码

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命令：

[AppleScript]  纯文本查看  复制代码

echo 1 > / proc / sys / vm / overcommit_memory

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

[AppleScript]  纯文本查看  复制代码

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修改其内容，在文件最后加入（数值也可以自己定义）：

[AppleScript]  纯文本查看  复制代码

* soft  nofile = 65535
* hard  nofile = 65535

• 修改/etc/profile
  

通过vi /etc/profile修改，在最后加入以下内容

[AppleScript]  纯文本查看  复制代码

ulimit - n 65535

修改完后重启Linux系统。

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

使用Redis Sentinel来做HA

sentinel是一个管理redis实例的工具，它可以实现对redis的监控、通知、自动故障转移。sentinel不断的检测redis实例是否可以正常工作，通过API向其他程序报告redis的状态，如果redis master不能工作，则会自动启动故障转移进程，将其中的一个slave提升为master，其他的slave重新设置新的master服务器。

sentinel是一个分布式系统，在源码包的src目录下会有redis-sentinel命令，你甚至还可以在多台机器上部署sentinel进程，共同监控redis实例。

• 一个Master可以有多个Slave；
• Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；
• 不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间可以构成一个图状结构；
• 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；
• 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；
• 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
• 复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（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

所以我们在一台服务器上安装3个目录：

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

因此我们使用redis-stable源码包来如此构建我们的实验环境

[AppleScript]  纯文本查看  复制代码

make PREFIX = / usr / local / redis 1 install
make PREFIX = / usr / local / redis 2 install
make PREFIX = / usr / local / redis - sentinel install

下面给出sentinel的配置


Sentinel中的配置

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

[AppleScript]  纯文本查看  复制代码

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
sentinel monitor master 1 192.1 68.5 6.1 01 7001 1
sentinel down - after - milliseconds master 1 1000
sentinel failover - timeout master 1 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与同步时，将会终止客户端请求。此值较大，意味着“集群”终止客户端请求的时间总和和较大。此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。我们这边只想让一个slave来做此时的响应以取得较好的客户端体验。
• 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文件不同其它配置相同，因此下面只给出一份配置：

[AppleScript]  纯文本查看  复制代码

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 64 mb

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 256 mb 64 mb 60
client - output - buffer - limit pubsub 32 mb 8 mb 60

hz 10

其中：

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

这是192.168.56.101:7001master上的配置，你要把192.168.56.101:7002作为slave，那很简单，你只需要在redis2的配置文件的最未尾加入一句：

[AppleScript]  纯文本查看  复制代码

slaveof 192.1 68.5 6.1 01 7001

配完了master, slave和sentinel后，我们按照这个顺序来启动redis HA：

master->slave->sentinel

启动后我们通过windows客户端使用命令：

[AppleScript]  纯文本查看  复制代码

redis - cli - p 26379 - h 192.1 68.5 6.1 01

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

可以看到目前它的master为7001，它有一个slave。

 
 

为了确认，我们另外开一个command窗口，通过：

[AppleScript]  纯文本查看  复制代码

redis - cli - p 7001 - h 192.1 68.5 6.1 01

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


 

我们还可以通过命令：

[AppleScript]  纯文本查看  复制代码

redis - cli - h 192.1 68.5 6.1 01 - p 7002

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

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

• 模拟代码
• 模拟并发测试工具
  

来测一下我们这个redis sentinel了的自动故障转移功能了。

使用 Spring Data + Jedis来访问我们的Redis Sentinel



pom.xml

[AppleScript]  纯文本查看  复制代码

< 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. v 20150827 < / jetty. version >
        < slf 4 j. version > 1.7 . 7 < / slf 4 j. 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 >