java操作redis有哪些方法
电脑安装Redis,然后通过JRedis(jar包)下的JRedis redis = new JRedis(address,port);就可以操作了,比连接数据库还简单,如果是windows的话 建议装虚拟机用linux安装redis,其他的只要你懂redis,用java操作redis太简单了
如何用java动态更改redis的配置
package redis;
import java.util.List;
import java.util.UUID;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.ShardedJedis;
import redis.clients.util.ShardInfo;
/**
* @author Andy
*/
public class RedisMasterSlaveTest {
private static final String HOST = “”;
private static final int PORT = 0;
/**
* 添加测试数据
*/
private static void setData(Jedis jedis) {
for (int i = 0; i 100; i++) {
final String a = UUID.randomUUID().toString();
jedis.set(a, a);
}
}
/**
* dbsize 数据库key总数
*/
private static long getDBSize(Jedis jedis) {
return jedis.dbSize();
}
/**
* 查询持久化策略
*/
private static ListString getSaveConfig(Jedis jedis) {
return jedis.configGet(“save”);
}
/**
* 设置持久化策略
*/
private static String setSaveConfig(Jedis jedis) {
String celue_1 = “800 1”;
String celue_2 = “400 2”;
return jedis.configSet(“save”, celue_1 + ” ” + celue_2);
}
/**
* 阻塞IO后持久化数据然后关闭redis (shutdown)
*/
private static String shutdown(Jedis jedis) {
return jedis.shutdown();
}
/**
* 将此redis设置为master主库
*/
private static String slaveofNoOne(Jedis jedis) {
return jedis.slaveofNoOne();
}
/**
* 将此redis根据host/port设置为slaveof从库
*/
private static String slaveof(Jedis jedis) {
return jedis.slaveof(HOST, PORT);
}
/**
* 查询redis的info信息
*/
private static String info(Jedis jedis) {
return jedis.info();
}
/**
* select?
*/
private static String select(Jedis jedis) {
return jedis.select(1);
}
}
////不要谢
redis主从集群 主挂掉 java怎样调用从
从机的redis命令行输入slaveofnoone转换为主机,然后要么修改主机ip要么修改java程序中的主机ip地址。
另外建议看下redis sentinel 主从切换(failover)解决方案
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操作相对线程启动来说很慢,因此,应用会堵在类似如下线程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/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执行的命令次数
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节点操作数据。Sharding架构如图:
庆幸的是,java redis客户端驱动jedis,已支持Redis Sharding功能,即ShardedJedis以及结合缓存池的ShardedJedisPool。
Jedis的Redis Sharding实现具有如下特点:
采
用一致性哈希算法(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节点,这在避免跨节点访问相关数据时很重要。
Redis Sharding采用客户端Sharding方式,服务端Redis还是一个个相对独立的Redis实例节点,没有做任何变动。同时,我们也不需要增加额外的中间处理组件,这是一种非常轻量、灵活的Redis多实例集群方法。
当然,Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容,当想要增加Redis节点时,尽管采用一致性哈希,毕竟还是会有key匹配不到而丢失,这时需要键值迁移。
作为轻量级客户端sharding,处理Redis键值迁移是不现实的,这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候,击穿缓存层,直接访问数据库层,会对系统访问造成很大压力。有没有其它手段改善这种情况?
Redis
作者给出了一个比较讨巧的办法–presharding,即预先根据系统规模尽量部署好多个Redis实例,这些实例占用系统资源很小,一台物理机可部
署多个,让他们都参与sharding,当需要扩容时,选中一个实例作为主节点,新加入的Redis节点作为从节点进行数据复制。数据同步后,修改
sharding配置,让指向原实例的Shard指向新机器上扩容后的Redis节点,同时调整新Redis节点为主节点,原实例可不再使用。
presharding
是预先分配好足够的分片,扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变,所以也
就不存在key值从一个区转移到另一个分片区的现象,只是将属于同分片区的键值从原Redis实例同步到新Redis实例。
并不是只有增
删Redis节点引起键值丢失问题,更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到,为不影响Redis性能,尽量不开启
AOF和RDB文件保存功能,可架构Redis主备模式,主Redis宕机,数据不会丢失,备Redis留有备份。
这样,我们的架构模式变
成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时,备Redis接管过来,上升为主Redis,继续提供服务。主
备共同组成一个Redis节点,通过自动故障转移,保证了节点的高可用性。则Sharding架构演变成:
Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。
高访问量下,即使采用Sharding分片,一个单独节点还是承担了很大的访问压力,这时我们还需要进一步分解。通常情况下,应用访问Redis读操作量和写操作量差异很大,读常常是写的数倍,这时我们可以将读写分离,而且读提供更多的实例数。
可以利用主从模式实现读写分离,主负责写,从负责只读,同时一主挂多个从。在Sentinel监控下,还可以保障节点故障的自动监测。
3.利用代理中间件实现大规模Redis集群
上面分别介绍了多Redis服务器集群的两种方式,它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。
客户端sharding技术其优势在于服务端的Redis实例彼此独立,相互无关联,每个Redis实例像单服务器一样运行,非常容易线性扩展,系统的灵活性很强。其不足之处在于:
由于sharding处理放到客户端,规模进步扩大时给运维带来挑战。
服务端Redis实例群拓扑结构有变化时,每个客户端都需要更新调整。
连接不能共享,当应用规模增大时,资源浪费制约优化。
服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时,客户端不需要感知,客户端像使用单Redis服务器一样使用Redis集群,运维管理也比较方便。
不过Redis Cluster正式版推出时间不长,系统稳定性、性能等都需要时间检验,尤其在大规模使用场合。
能不能结合二者优势?即能使服务端各实例彼此独立,支持线性可伸缩,同时sharding又能集中处理,方便统一管理?本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。
twemproxy处于客户端和服务器的中间,将客户端发来的请求,进行一定的处理后(如sharding),再转发给后端真正的Redis服务器。也就是说,客户端不直接访问Redis服务器,而是通过twemproxy代理中间件间接访问。
参照Redis Sharding架构,增加代理中间件的Redis集群架构如下:
twemproxy中间件的内部处理是无状态的,它本身可以很轻松地集群,这样可避免单点压力或故障。
twemproxy又叫nutcracker,起源于twitter系统中redis/memcached集群开发实践,运行效果良好,后代码奉献给开源社区。其轻量高效,采用C语言开发,工程网址是:GitHub – twitter/twemproxy: A fast, light-weight proxy for memcached and redis
twemproxy后端不仅支持redis,同时也支持memcached,这是twitter系统具体环境造成的。
由于使用了中间件,twemproxy可以通过共享与后端系统的连接,降低客户端直接连接后端服务器的连接数量。同时,它也提供sharding功能,支持后端服务器集群水平扩展。统一运维管理也带来了方便。
当然,也是由于使用了中间件代理,相比客户端直连服务器方式,性能上会有所损耗,实测结果大约降低了20%左右。