Redis学习之路总结

288 阅读25分钟

CAP原理+BASE

CAP

  • C(Consistency):强一致性
  • A(Availability):高可用性
  • P(Partition tolerance):分区容错性

CAP的核心理论

一个分布式系统不可能同时很好的满足强一致性、可用性和分区容错性这三个需求,最多只能同时满足两个。

因此根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则、满足AP原则三大类:

  • CA:单点集群,满足强一致性和高可用性的系统,通常在可扩展性上不强。 传统关系型数据库的选择。
  • CP:满足强一致性、分区容错性的系统,通常性能不是很好。
  • AP:满足高可用性、分区容错性的系统,通常可能对一致性要求低一些, 大多数网站架构的选择,选择弱一致性、高可用行、分区容错性。

BASE

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写

  • 基本可用(Basically Available)
  • 软状态(Soft state)
  • 最终一致(Eventually consistent)

他的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上的改观。

原因是大型系统往往由于地域分布和极高性能的要求,不能采用分布式事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来实现,这里BASE就是解决了这个问题。

Redis的特点

  • Redis支持数据持久化,可以将内存中的数据保存到磁盘中,重启的时候可以再次加载使用
  • Redis不仅仅支持简单的Key-Value类型的数据,同时还提供了list、set、zset、hash等数据结构的存储。
  • Redis支持数据的备份,即master-slave模式的数据备份。

Redis的作用

  • 内存存储和持久化:redis支持异步将内存中的数据存储到磁盘上,同时不影响继续服务。
  • 取最新的N个数据的操作:例如可以将最新的10条评论的ID放在Redis的list集合中。
  • 模拟类似于HttpSession这种需要设定过期时间的功能。
  • 发布、订阅消息管理。
  • 定时器、计数器。

Redis启动后杂项基础知识

  • Redis是单进程的:Redis使用单进程模型来处理客户端的请求,对读写事务的响应是通过对epoll函数的包装来实现的。Redis的实际处理速度完全依靠主线程的执行效率。 Epoll函数是Linux内核为处理大批量文件描述符而做了改进的epoll,是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。

  • 默认16个数据库,类似数组下标从0开始,初始默认使用0号库,可以使用select命令切换数据库。

  • 统一密码管理,16个库的密码相同。

  • Redis的索引都是从0开始。

  • 默认端口是6379。

redis.conf配置文件及重要参数

  • Units单位:配置大小单位,在配置文件中定义了一些基本的度量单位,只支持bytes,不支持bit,而且对大小写不明显。

  • INCLUDE包含:和Struts2配置文件类似,可以通过includes包含,redis.conf可以作为总闸,包含其它的redis文件。

  • GENERAL通用:

daemonize: 用来指定redis是否以守护线程的方式启动,默认为no。

daemonize设置为no,当前界面进入redis的命令行界面,exit强制退出或者关闭连接工具(例如Xshell)都会导致redis进程退出。 当daemonize设置为yes,redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时,代表开启守护进程模式。在该模式下,redis会在后台运行,并将进程pid号写入至redis.conf选项pidfile设置的文件中,此时redis将一直运行,除非手动kill该进程。

tcp-backlog: 设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列+已经完成三次握手队列。在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和tcp_max_syn_backlog两个值。tcp-backlog默认值为511

timeout: 指定客户端连接redis服务器时,当闲置的时间为多少(如300)时,关闭连接。默认值为0,表示不会关闭客户端。

tcp-keepalive: 单位为秒,如果设置为0,则不会进行keepalive检测,建议设置为60s。

loglevel: 设置日志级别。

Redis的默认有4个日志级别。debug、verbose、notice、warning四个日志级别越高越高,即打印的日志信息越来越少,debug适合在开发测试时使用,warning适合在系统稳定后使用。

Syslog-enabled: 是否把日志输出到syslog中。

Syslog-ident: 指定syslog里的日志标示。

Syslog-facility: 指定syslog设备,值可以是USER或者LOCAL0~LOCAL7。默认为LOCAL0。

  • SECURIY安全:访问密码的查看、设置和取消。

在连接上redis客户端之后可以通过config get requirepass命令查看当前redis的密码,默认密码为空。

  • LIMITS限制:

(1):Maxclients: (2):Maxmemory: (3):Maxmemory-policy

缓存过期策略: 1):volatile-lru:使用LRU算法(最近最少使用算法)移除key,只对设置了过期的键。 2):allkeys-lru:使用LRU(最近最少使用算法)算法移除key。 3):volatile-random:在过期集合中移除随机的key,只对设置了过期时间的键。 4):allkeys-random:移除随机的key。 5):volatile-ttl:移除哪些TTL值最小的key,即那些最近要过期的key。 6):noeviction:不进行移除,针对写操作,只是返回错误信息。

(4):Maxmemory-samples:设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值,所以可以设置样本的大小,redis默认会检查这么多个key并选择其中LRU的那个。默认值为5.

Redis持久化

RDB(Redis DataBase)

RDB定义

在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读取到内存中。

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,等到持久化过程都结束了,再用这个临时文件替换上次持久好的文件。整个过程中,主进程是不会进行任何IO操作的,这就确保了极高的性能。 如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失。

Fork定义

Fork的作用是复制一个与当前线程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都与原进程一样,但是是一个全新的线程,并作为原进程的子进程。

RDB保存的是dump.rdb文件。

redis.conf配置文件中关于RDB的配置

SNAPSHOTTING快照

  • Save:RDB是整个内存的压缩过的Snapshot,RDB的数据结构,可以配置复合的快照出发条件,默认为:一分钟该一万次或者五分钟改了10次或者15分钟内改了1次。

  • 如果想禁用RDB持久化策略,只要不设置任何save指令,或者给save传入一个空字符串参数也可以。

  • Stop-writes-on-bgsave-error:默认为yes,表示当后台save的过程中出错了,前台要停止写操作,若设置为no,表示不在乎数据是否不一致。

  • rdbcompression:默认为yes,表示在将数据持久化到磁盘时,redis会采用LZF算法进行压缩。若不想消耗CPU资源来进行压缩的话,可以设置为no。

  • rdbchecksum:在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增大约10%的性能消耗,如果希望获取到最大性能,可以设为no。

如何触发RDB快照

  • 通过配置文件中默认的快照配置,还可以冷拷贝之后重新使用,就是指将主机上的日志文件拷贝到从机上。
  • 命令save或者bgsave save:save只管保存。其它不管,全部阻塞 bgsave:redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
  • 执行flushall命令也会产生dump.rdb文件,但里面是空的,无意义。

如何恢复RDB

  • 将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
  • CONFIG GET dir获取目录

RDB优势

  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不太高

RDB的劣势

  • 在一定间隔内做一次备份,所以如果redis以外宕机的话,就会丢失最后一次快照后的所有修改。
  • fork的时候。内存中的数据被克隆了一份,大至两倍的膨胀性需要考虑。

如何禁用RDB

  • 动态的停止所有的RDB保存规则的方法:redis-cli config set save=“”

RDB总结

  • RDB是一个非常紧凑的文件
  • RDB在保存RDB文件时父进程唯一要做的就是fork出一个子进程,接下来的工作全部交给子进程来做,父进程不需要再进行任何的IO操作,所以RDB持久化方式可以最大化Redis的性能。
  • 与AOF比,再恢复大的数据集的时候,RDB方式会更快一些。
  • 数据丢失风险大
  • RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork是非常耗时的,可能会导致redis在一些毫秒级不能响应客户端请求。

AOF

AOF定义

AOF是以日志的形式来记录每个操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redia启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一遍以完成数据的恢复工作。

AOF保存的是appendolly.aof文件。

redis.conf中关于AOF的配置

APPEND ONLY MODE

  • appendonly 默认为no,设置为yes表示开启AOF持久化。
  • appendfilename 设置aop持久化的日志名称,通常使用默认名即可。
  • Appendfsync 1):Always:同步持久化,每次发生数据变更会被立刻记录到磁盘,性能比较差但是数据完整性比较好。 2):Everysec:出厂默认推荐,异步操作,每秒记录一次,若一秒内宕机,有数据丢失。 3):No
  • No-appendfsync-on-rewrite:重写时是否可以运用Appendfsync,用默认no即可,保证数据安全性。
  • Auto-aof-rewrite-min-size:设置重写的基准值
  • Auto-aof-rewrite-percentage:设置重写的基准值

AOF启动/修复/恢复

  • 正常恢复 启动:修改redis.conf中的appendonly属性为yes 将有数据的aof文件复制一份保存到对应目录(config get dir) 恢复:重启redis然后重新加载
  • 异常恢复 备份被写坏的AOF文件 修复:Redis-check-aof --fix进行修复 恢复:重启redis然后重新加载

Rewrite重写

Rewrite定义

AOF采用文件追加方式,文件会越来越大,为了避免出现这种情况,新增加了重写机制。当AOF文件的大小超过所设定的阈值时,Redis会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof。

Rewrite原理

AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件然后rename),遍历新进程的内存中的数据,每条记录有一条set一句。重写AOF文件的操作,并没有读取旧的AOF文件,而是将整个内存中的数据库内容用命令的方式写了一个新的AOF文件,这点和快照类似。

Rewrite触发机制

Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一半且文件大于64M时触发。

AOF优势

  • 每修改同步:appendfsync always 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差但是数据完整性好。
  • 每秒同步:appendfsync everysec 异步操作,每秒记录,如果一秒内宕机,有数据丢失
  • 不同步:appendfsync no 从不同步。

AOF劣势

  • 相同数据集的数据而言,AOF文件要远大于RDB文件,恢复速度慢于RDB文件。
  • AOF运行效率慢于RDB,每秒同步策略效率较好,不同步效率和RDB相同。

APF总结

  • AOF文件是一个只进行追加的日志文件。
  • Redis可以在AOF文件体积变得过大时,自动的在后台进行重写(Rewrite)。
  • AOF文件有序的保存了对数据库执行的所有写入操作,这些写入操作以Redis协议的格式保存,因此AOF的内容非常的易懂,对文件进行分析也很轻松。
  • 对于相同的数据来说,AOF文件的体积要大于RDB文件的体积。
  • 根据所使用的fsync策略。AOF的速度可能会慢于RDB。

RDB和AOF的区别

  • RDB持久化方式能够在指定的时间间隔内对数据进行快照存储
  • AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以Redis协议追加保存每次写的操作到文件末尾,Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

RDB和AOF的选择

  • 只做缓存:如果你只希望你的数据在服务器运行的时候存在,可以不使用任何持久化方式。
  • 同时开启两种持久化方式 在这种情况下,当AOF重启的时候会有优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集完整。 RDB的数据不实时,同时使用这两者时服务器也只会找AOF文件。建议不要只使用AOF,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF潜在的bug。
  • 因为RDB文件只用作后背用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,即只保留save 900 1这条规则。 如果开启了AOF,好处是在最恶劣的情况下也只会丢失不超过两秒的数据,启动脚本较简单只load自己的AOF文件就可以了。代价是带来了持续的IO,二是AOF的Rewrite的最后将Rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应尽量减少AOF Rewrite的频率,AOF重写的基础大小默认是64M太小了,可以设置到5GB以下。默认超过原大小的100%大小时重写可以改到适当的数值。 如果不开启AOF,仅靠Master-Slave Replication实现高可用也可以。能省掉一大笔IO也叫少了Rewrite时带来的系统波动,代价是如果Master/Slave同时挂掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。

Redis事务

Redis事务定义

可以一次执行多个命令,本质是一组命令的集合,一个事务中的所有命令都会被序列化,按顺序的串行化执行而不会被其他命令插入,不许加塞。是在一个队列中,一次性的、顺序的、排他性的执行一系列命令。

Redis事务相关命令

-DISCARD:取消事务,放弃执行事务块内的所有命令。

  • EXEC:执行所有事务块内的命令。
  • MULTI:标记一个事务的开始。
  • UNWATCH:取消WATCH命令对所有key的监控。
  • WATCH(key...):监控一个或者多个key,如果在事务执行之前这个(或这些)key被其它命令所改动,那么事务将被打断。

Redis事务执行流程

  • 开启:以MULTI开始一个事务
  • 入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
  • 执行:由EXEC命令触发事务

Redis事务特性

  • 单独的隔离操作:事务中的所有命令都会序列化,按照顺序执行,事务在执行的过程中,不会被其他的客户端发送来的命令请求所打断。
  • 没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,在事务外查询不能看到”的问题了。
  • 不保证原子性:redis同一个事务如果有一条命令执行失败,其他的命令仍会执行,不会回滚。

Redis的WATCH监控

  • Watch指令,类似于乐观锁,事务提交时,如果key的值已经被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行。
  • 通过WATCH命令在事务执行之前监控了多个keys,倘若在WATCH之后有任何key的值发生了变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

  • 悲观锁:
  • 乐观锁:
  • CAS(check and set)

Redis的发布订阅

Redis发布订阅机制定义

进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接受消息

Redis发布订阅相关命令

  • PSUBSCRIBEpattern [pattern...]:订阅一个或者多个符合给定模式的频道。
  • PUBSUB subcommand [argument [argument...]]:查看订阅与发布系统状态。
  • PUBLISH channel message:将信息发送到指定的频道。
  • PUNSUBSCRIBE [pattern [pattern...]]:退订所有给定模式的频道。
  • SUBSCRIBE channel[channel...]:订阅给定的一个或多个频道的信息。
  • UNSUBSCRIBE [channel [channel]...]:指退订给定的频道。

Redis的复制

Redis的复制定义

也就是主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slave机制,Master以写为主,Slave以读为主。

Redis主从复制的常用模式

  • 上一个Slave可以是下一个Slave的Master,Slave同样可以接受其他Slaves的连接和同步请求,那么该Slave座位了链条中下一个的master,可以有效的减轻master的写压力。

  • 以一主而从的集群为例,若master宕机,另外的两个slave可以使用SLAVEOF no one命令使当前redis节点停止与其它redis节点的同步,转成master,之后如果宕机了的master恢复了,它的身份依然是master,但是没有从机。

Redis复制的原理

  • Slave启动成功连接到Master后会发送一个sync命令。
  • Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集的命令,在后台进程执行完毕后,master将传送整个数据文件到slave,以完成一次完全同步。
  • 全量复制:slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
  • 增量复制:Master继续将新的所有收集到的修改命令依此传递给slave,完成同步。
  • 但是只要是重新连接master,一次完全同步(全量复制)将会被执行。

哨兵模式

哨兵机制的功能

  • 监控:哨兵会不断的检查master和slave是否运行正常。
  • 提醒:当被监控的某个redis节点出现问题,哨兵可以通过API向管理员或者其它应用程序发送通知。
  • 自动故障迁移:当一个Master不能正常工作,哨兵会开始一次自动故障迁移操作,会将失效的Masher的其中一个Slave升级为新的Master,并让失效的Master的slave改为复制新的Masher,当客户端试图连接失效的Master时,集群会向客户端返回新的Master的地址,使得集群可以使用新的Master代替失效的Master。

哨兵机制工作原理

哨兵是一个分布式系统,可以在一个架构中运行多个哨兵进程,这些进程使用流言协议来接受关于Master是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵会向其它哨兵、master、slave定时发送消息,以确认对方是否活着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已经死亡,若哨兵集群的多数都报告该master没响应,系统才会认为该master确实死亡,然后通过一定的vote算法,从剩下的slave中选出新的master,然后自动修改相关配置。

虽然哨兵是一个单独的可执行文件,但实际上它是一个运行在特殊模式下的redis服务器,可以在启动普通redis服务器后通过--sentinel选项来启动哨兵。 哨兵的一些设计思想和zookeeper很相似。

监控原理

  • 哨兵会以每秒一次的频率与之前创建了命令连接的实例发送PING,包括master、slave、哨兵实例,以此来判断当前实例的状态,down-after-milliseconds时间内PING无响应,则将该实例视为主观下线。之后该哨兵会向其它监控同一主服务器的哨兵实例询问是否也将该服务器视为主观下线,当超过了quorum后将视为该节点真正死亡。

  • 当master被认为真正死亡后,该哨兵会与其他的哨兵协商选出领头的哨兵进行故障转移工作。每个发现master真正死亡的哨兵都可以要求其它哨兵选择自己为领头的哨兵,选举是先到先得,如果有半数以上的哨兵选择了某一个哨兵作为零头的哨兵,则该哨兵进行故障转移工作。

故障转移原理

  • 首先是从master的slave中选出一个slave作为新的master,选择的依据是:网络连接正常->5秒内回复过INFO命令->10*down-after-milliseconds内与主机连接过的->从服务器优先级->复制偏移量->运行id比较小的。选出之后通过slaveif no out将该slave升级为新的master。
  • 通过slaveof ip port命令让其它slave制该新的master。
  • 最后当旧的master重新连接上集群后,将会变成新的master的slave。
  • 故障转移成功后会通过发布订阅连接广播新的配置信息,其他哨兵收到配置信息后根据配置信息来更新主服务器信息。

哨兵机制的缺陷

  • master的数据要经常进行主从复制,这样会造成性能下降
  • 当master宕机,slave切换成master的这段时间内,服务是不能用的。

假设当前redis集群为一主二从,master端口为79,slave端口分别为80和81

  • 首先在master节点的相应文件夹中新建sentinel.conf文件(名字不能错).
  • vim编辑sentinel文件,添加 sentinel monitor 被监控节点名字 127.0.0.1 被监控端口号 1
  • 其中末尾的1表示master宕机挂掉之后,slave投票看让谁接替成为主机,得票数多了多少之后变成master,1就表示当某一个slave节点的票数比另外的slave节点数大1时,该节点就成为master。
  • 启动哨兵:Redis-sentinel .../sentinel.conf

例如当前master为79端口,此时79端口宕机,则会进行投票,投票后选出新的master,若为80,则80为新的master,当79端口节点恢复正常再次加入集群后,会以slave的身份加入,此时集群的master仍然是80端口的redis节点。

Redis集群的内部结构

是一个提供多个Redis(分布式)节点间共享数据的程序集。 Redis集群的键空间被分割为16384个hash槽(slot),集群将16384个slot分配给不同的节点。slot里存放了大量的key。

Redis槽的原理

Redis Cluster在设计中没用到一致性哈希算法,而是使用数据分片引入哈希槽来实现。一个Redis Cluster包含16384(0~16383)个哈希槽,存储在Redis Cluster中的所有键都会被影射到这些slot中,集群中的每个键都属于这16384中的一个,集群中使用公示slot=CRC16(key)/16384来计算key属于哪个槽,其中CRC16(key)语句用于计算key的CRC16校验和。

若redis集群中新增加一个节点,需要将其它节点上的数据迁移一部分到新节点,迁移节点的单位时slot,而不是key。

Redis3.0之后真正的集群的特点

  • 无中心架构,不存在proxy(代理)。
  • 数据以slot存储分布在多个节点上,节点之间数据共享,可动态调整。
  • 可扩展到1000个节点,节点可动态添加和删除。
  • 高可用,同时通过增加slave做备份数据。
  • 自动故障转移:节点间通过gossip协议交换状态信息,用投票机制完成slave到master的角色转换。
  • 缺陷: (1):资源隔离性较差,容易出现相互影响。 (2):数据通过异步复制,不保证数据的强一致性。

Gossip协议的特点

  • 扩展性:网络可以允许节点的任意增加和减少,新增加的节点的状态最终会与其它节点一致。
  • 容错:网络中任何节点的宕机和重启都不会影响Gossip消息的传播,Gossip协议具有天然的分布式系统容错特性。
  • 去中心化:Gossip协议不要求有任何的中心节点,所有节点都可以是对等的,任何一个节点无需知道整个网络情况,只要网络是联通的,任意一个节点就可以把消息散播到全网。
  • 一致性收敛:Gossip协议中的消息一传、十传百一样的指数级速度在网络中快速传播,因此系统状态的不一致可以在很快的时间内收敛到一致。消息传播速度达到了logN。
  • 简单:Gossip协议的过程极其简单,实现起来几乎没有太多复杂性。

JedisPoll配置

  • maxActive:控制一个poll可分配多少jidis实例,通过poll.getresource()来获取,如果赋值为-1,则表示不限制;如果poll已经分配了maxActive个jedis实例,则此时poll的状态为exhausted。
  • maxIdle:控制一个poll最多有多少个状态为idle(空闲)的jedis实例。
  • whenExhaustedAction:表示当前poll中的jedis实例都被allocated完时,poll要采取的操作,有三个: (1):WHEN_ENHAUSTED_FAIL:表示无jedis实例时,直接跑出NoSuchElementException。 (2):WHEN_EXHAUSTED_BLOCK:表示阻塞,或者达到maxWait时抛出JedisConnectionException。 (3):WHEN_EXHAUSTED_GROW:表示新建一个jedis实例,也就是说设置maxActive没用
  • MaxWait:表示当borrow一个jedis实例时,最大的等待时间,如果超过等待时间,直接抛出JedisConnectionException。
  • testOnBorrow:获得一个Jedis实例的时候是否检查连续可用性(ping);如果为true,则得到的jedis实例均是可用的。
  • testOnReturn:return一个jedis实例给poll时,是否检查连续可用性(ping)。
  • testWhileIdle:如果为true,表示有一个idle object evitor线程对idle object进行扫描,如果validate失败,此object会被从poll中drop掉,这一项只有在timeBetweenEvictionRunsMillis大于0时才有效。
  • timeBetweenEvictionRunsMillis:表示idle object evitor两次扫描之间需要sleep的毫秒数。
  • numTestsPerEvictionRun:表示idle object evitor每次扫描的最多的对象数。