博客 2015-08-18


1.VIP:port 提供服务:

       

    唯一标记一个redis实例的是ip和端口,前端是用tcp方式来访问redis的,我们提供给应用访问的是一个vip+63379(一般使用63379) 端口,,vip一定是在master上面的.


因此我们执行如下命令检查redis状态:


[wls81@CNSH044446 ~]$ /wls/wls81/redis/bin/redis-cli -h {vip}  -p 63379 -a {password}  info replication


# Replication

role:master

connected_slaves:1

slave0:ip=10.11.93.12,port=63379,state=online,offset=146649,lag=1

master_repl_offset:146649

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:2

repl_backlog_histlen:146648


上面的role这个值一定是master的,只要保证vip在master上我们的Padis cache服务就是没有问题的,如果不通或者role的角色是slave


那就得继续查看是什么问题.



2. 两个redis的角色都是slave的问题


    当两个主机都挂了或者我们自己不小心将两个redis停了,并且我们用下面的命令检查


     /wls/wls81/redis/bin/redis-cli -h  {ip} -p {port} -a {password}  info replication


     发现无论是vip还是另外的两个ip都是role:slave 的角色,这个时候需要对vip所在的主机执行slaveof no one 的操作,将


     vip 所在的redis变成master,如:


     /wls/wls81/redis/bin/redis-cli -h  {vip} -p {port} -a {password}  slaveof no one



3. sentinel的配置参数


    我们的sentinel 配置文件(如:/wls/apache/servers/pds_jks-core-prd/conf/pds_jks-core-prd-1.conf) 里面有两个重要的配置


   sentinel monitor pds_jks-core-prd 10.33.94.65 63379 1          -----------配置的ip和端口任何时候都需要是master的ip端口,切换的时候程序自动会改           

   sentinel down-after-milliseconds pds_jks-core-prd 15000          ----------这个是sentinel连接master的超时时间,超过这个时间就认为master挂了,实现自动切换


  这个默认是30秒,这个时间得调节好,大了会在真正出现故障的时候切换时间会长,小了有时候master由于持久化数据,繁忙不响应,会导致自动切换,实际只是瞬间不可用,现在认为设置为15秒为宜.


 


4. AOF日志


    这个日志记录了每一个写入命令或者删除命令的,这个对于我们审计功能是有用的,由于占用很多磁盘,默认我们是关闭的


    如果开启会生成一个.aof的文 件在data文件中. 如:  /wls/apache/servers/pds_jks-core-prd/data


    在redis运行中中开启:


     /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} config set appendonly yes


     开启了可以查看日志,记录每一个命令,如有必要可以开启查完问题后关闭. 同时说明一下


      /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} config set 可以在redis运行的时候设置多个它的参数



5. 空闲连接的timeout


     redis服务端不会自动断开客户端来的连接,redis服务端有设置客户端空闲连接超时时间,可用命令


      /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} config get timeout


      查看当前timeout时间,默认是0,就是不断开空闲的连接,如果不断开空闲的连接,就会造成redis连接过多


      所以一般情况下可以设置为3600秒:


      /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} config set timeout  3600


      也就是3600秒后将空闲的连接关闭掉.  可以用下面的命令查看某个连接空闲了多久:


       /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} client list


 


6.  开启慢日志


     redis有记录哪个命令执行了多久的功能,但是都需要开启,用命令:


     /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} config set slowlog-log-slower-than {number}


     {number} 是一个微妙为单位的数字,如500,上面的命令的意思是执行时间超过500微妙的命令记录出来


     记录的信息可以用如下命令获取:


     /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password}  slowlog get


    


    1) 1) (integer) 16167


         2) (integer) 1425018348


         3) (integer) 100303


        4) 1) "DEL"


             2) "CARD:List:1"


    slowlog 可以看到是上面格式的记录,其中1425018348这个是开始处理时间,可以用date -d "@1425018348" 这个命令查看具体的时间


    100303是执行时间,以微秒为单位.  后面的是执行命令。     


 


7. 监控redis执行的命令


    /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} monitor


    上述这个monitor命令可以查看redis执行了什么命令,有时候查问题很有必要用到,我们可以知道那段时间redis执行了什么


     从而进行我们的问题诊断


 


8.  key的查找与执行


      /wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port}  -a {password} keys "*"


      keys这个命令查找所有的key,但是最好慎用,因为它很耗redis的性能,每个key都遍历一遍. 也可以进行模糊匹配如: keys "send*"


      千万记住在生产环境上不能随便乱用,因为它会将redis性能耗尽,导致其他连接获取不到响应.


       /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password}  dbsize


       dbsize 这个命令可以看到整一个redis里面有多少个key,当然和keys "*" | wc -l结果是一样的。


      当我们需要批量删除key值时可以用如下命令即可:


       /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password} keys "send*" | xargs  /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password} del


       我们需要将整个db都flush掉可以用:


        /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password} -a MamcCorePrd  flushdb


9. 防火墙 

no-sequence-check 不检查包的序列号(no-sequence-check 就是在防火墙上不检查tcp 的握手过程),导致redis访问丢包问题,详细见case:


      http://case.paic.com.cn/case/task/getTaskDetail.shtml?id=00616625


     这个问题实际上与redis没有关系,只是我们需要知道如果跨区域访问redis,中间有防火墙,例如我们的SF区经过防火墙访问DMZ区的redis


     就可能由于这个no-sequence-check 的原因导致不能正常访问,这种现象出现的频率很低


 


 


10. 由于连接redis的客户端使用jedisPool(实际上是apache的commonPool)


如果设置了

       redis.pool.testOnBorrow.REL=true

       redis.pool.testOnReturn.REL=true


      这两个参数是说在或者pool中的连接和返回连接给pool的时候都需要检查一下连接的有用性,也就是ping一下这个redis是不是好的,


      这样在高并发的时候,由于并发线程太多,ping操作相对线程启动来说很慢,因此,应用会堵在类似如下线程dump的地方


      "[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'" id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon

    at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)

    at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:32)

    at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)

    at java/net/SocketInputStream.read(SocketInputStream.java:129)

    at java/net/SocketInputStream.read(SocketInputStream.java:90)

    at redis/clients/util/RedisInputStream.fill(RedisInputStream.java:109)

    at redis/clients/util/RedisInputStream.readByte(RedisInputStream.java:45)

    at redis/clients/jedis/Protocol.process(Protocol.java:64)

    at redis/clients/jedis/Protocol.read(Protocol.java:131)

    at redis/clients/jedis/Connection.getStatusCodeReply(Connection.java:162)

    at redis/clients/jedis/Jedis.ping(Jedis.java:35)

    at redis/clients/jedis/JedisPool$JedisFactory.validateObject(JedisPool.java:104)

    at org/apache/commons/pool/impl/GenericObjectPool.addObjectToPool(GenericObjectPool.java:922)

    at org/apache/commons/pool/impl/GenericObjectPool.returnObject(GenericObjectPool.java:917)

    ^-- Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]

    at redis/clients/util/Pool.returnResourceObject(Pool.java:29)

    at redis/clients/util/Pool.returnResource(Pool.java:41)

    at com/paic/icore/mams/common/jedis/util/RedisPoolCacheTools.release(RedisPoolCacheTools.java:43)


    虽然后面会自动恢复,不过导致应用响应缓慢.解决方法是将该两个参数设置为false,并且定期检查:


    testOnBorrow.REL=false

    testOnReturn.REL=false

    timeBetweenEvictionRunsMillis=60000            -------每隔60秒定期检查空闲连接

    minEvictableIdleTimeMillis=120000                 ---------连接在池中保持空闲而不被空闲连接回收器线程回收的最小时间值,单位毫秒                       


    numTestsPerEvictionRun=-1                              ----------空闲连接扫描时,每次最多扫描的连接数,一般设置为-1,全部扫描


     设置成这样之后就不用每次都测试了,这样就提高了应用的性能. 具体过程见附件:


      答复 答复  生产环境redis报错.rar


 


11. master和slave之间由于沟通不了导致的切换,切换时间会影响客户端的连接,短暂访问不了,经过检查这个原因是由于key较多的情况下


       有同事在上面执行了 keys "*"  操作导致的,所以慎用keys "*" .  


        还有flsushall()的客户端的命令也是会导致master整个缓慢的,请切记使用     


 


12. 有时候由于持久化导致master变得缓慢,所以建议关闭master的持久化,让slave持久化


      关闭持久化   /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password} config set save ""


      开通持久化  /wls/wls81/redis/bin/redis-cli -h {ip} -p {port}  -a {password}  config set save "900 1 300 10 60 10000"


       关闭持久化后如果发生主备切换了,请将master的持久化关闭,slave的持久化开启   


 


上面的是一般redis常见命令和问题的处理办法,由于redis的命令众多,详细可可以参考官方文档: http://redis.io/