javaredis集群

A. redis集群角色切换java调用异常

redis集群角色切换java调用异常
一、Redis状态检查

唯一标记一个redis实例的是ip和端口，前端是用tcp方式来访问redis的，我们提供给应用访问的是一个ip+63379(一般使用63379) 端口。因此我们执行如下命令检查redis状态:

上面的role这个值一定是master的，只要保证vip在master上我们的Padis cache服务就是没有问题的，如果不通或者role的角色是slave，那就得继续查看是什么问题.

二、两个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

三、sentinel的配置参数

我们的sentinel 配置文件里面有两个重要的配置

sentinel monitor pds_jks-core-prd 10.33.94.65 63379 1 -----------配置的ip和端口任何时候都需要是master的ip端口,切换的时候程序自动会改 。另外，红色所示部分pds_jks-core-prd为redis对外提供的主机名，一般Jedis在调用redis时会用到此名称。如果配置多个哨兵则一般要求此名称唯一标识

sentinel down-after-milliseconds pds_jks-core-prd 15000 ----------这个是sentinel连接master的超时时间，超过这个时间就认为master挂了，实现自动切换。这个默认是30秒，这个时间得调节好，大了会在真正出现故障的时候切换时间会长，小了有时候master由于持久化数据，繁忙不响应，会导致自动切换，实际只是瞬间不可用，现在认为设置为15秒为宜.

四、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运行的时候设置多个它的参数

五、空闲连接的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

六、监控redis执行的命令

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

上述这个monitor命令可以查看redis执行了什么命令，有时候查问题很有必要用到，我们可以知道那段时间redis执行了什么，从而进行我们的问题诊断。

七、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

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

八、由于连接redis的客户端使用jedisPool

如果设置了

redis.pool.testOnBorrow.REL=true

redis.pool.testOnReturn.REL=true

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

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

"[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/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，全部扫描

设置成这样之后就不用每次都测试了，这样就提高了应用的性能

有时候由于持久化导致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执行的命令次数

B. Java工程师是如何使用Redis的

redis算是用的最多的key-value型缓存组件了！

因为使用了key-value型，所以存取效率极好，简单来说就类似JAVA中的hashMap，不过是用整个服务器内存来当做map，但是redis的数据可以通过配置指令保存到硬盘(同步保存save，异步保存bgsave)！

当然，redis在使用过程中会存在持久化失败，缓存击穿，扩容困难等问题，不过无论如何，redis都是一款最值得用的缓存工具！

使用过程中有任何问题，欢迎大家一起交流，redis还有什么遗漏功能，也请大家补充，谢谢！

C. Redis怎么做集群

为什么集群？

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2.Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

1. 采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

2.为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

D. redis主从集群 主挂掉 java怎样调用从

从机的redis命令行输入slaveofnoone转换为主机，然后要么修改主机ip要么修改java程序中的主机ip地址。
另外建议看下redis sentinel 主从切换(failover)解决方案

E. java操作redis集群问题CLUSTERDOWN The cluster is down. Use CLUSTER INFO for more information

java操作redis集群问题CLUSTERDOWN The cluster is down. Use CLUSTER INFO for more information，配置没有配置好的问题。