codis的proxy层HA

对Java用户来说,可以使用经过修改过的Jedis-------Jodis,来实现proxy层的HA。它会通过监控zk上的注册信息来实时获得当前可用的proxy列表,既可以保证高可用性,也可以通过轮流请求所有的proxy实现负载均衡。

jodis的地址如下:

https://github.com/wandoulabs/codis/tree/master/extern/jodis

具体使用如下:

JedisResourcePool jedisPool = new RoundRobinJedisPool("zkserver:2181", 30000, "/zk/codis/db_xxx/proxy", new JedisPoolConfig());
try (Jedis jedis = jedisPool.getResource()) {
    jedis.set("foo", "bar");
    String value = jedis.get("foo");
}

其中部分jedis参数设置如下:

//可用连接实例的最大数目,默认值为8;
//如果赋值为-1,则表示不限制;如果pool已经分配了maxActive个jedis实例,则此时pool的状态为exhausted(耗尽)。
private static int MAX_ACTIVE = 10;
//控制一个pool最多有多少个状态为idle(空闲的)的jedis实例,默认值也是8。
private static int MAX_IDLE = 5;
//等待可用连接的最大时间,单位毫秒,默认值为-1,表示永不超时。如果超过等待时间,则直接抛出JedisConnectionException;
private static int MAX_WAIT = 3000;
private static int TIMEOUT = 5000;

在实际运行过程中会报错,部分错误如下:

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool 

at redis.clients.util.Pool.getResource(Pool.java:50)

at redis.clients.jedis.JedisPool.getResource(JedisPool.java:86)

at xt.city.edi.dao.redis.RedisUtil.getJedis(RedisUtil.java:81)

at xt.city.edi.service.account.pojo.DefaultAccountManager.addUserlist(DefaultAccountManager.java:172)

……

……

Caused by: java.util.NoSuchElementException: Timeout waiting for idle object 

at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)

at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363)

at redis.clients.util.Pool.getResource(Pool.java:48)

正如上面提示:

我们jedis设置的连接池设置的太小,当连接池全被占用后,在“MAX_WAIT”的等待时间内,没有实例被释放,从而超时等待,导致could not get a resource from the pool。

在zookeeper的输出日志zookeeper.out也可以看到:

2015-07-24 10:15:35,247 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:[email protected]] - Accepted socket connection from /192.168.1.119:30275

2015-07-24 10:15:35,254 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:[email protected]] - Client attempting to establish new session at /192.168.1.119:30275

2015-07-24 10:15:35,257 [myid:1] - INFO [CommitProcessor:1:[email protected]] - Established session 0x14e67e71be5003d with negotiated timeout 5000 for client /192.168.1.119:30275

2015-07-24 10:20:24,576 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:[email protected]] - caught end of stream exception

EndOfStreamException: Unable to read additional data from client sessionid 0x14e67e71be5003d, likely client has closed socket

at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)

at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)

at java.lang.Thread.run(Thread.java:745)

2015-07-24 10:20:24,577 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:[email protected]] - Closed socket connection for client /192.168.1.119:30275 which had sessionid 0x14e67e71be5003d

2015-07-24 10:20:30,000 [myid:1] - INFO [SessionTracker:[email protected]] - Expiring session 0x14e67e71be5003d, timeout of 5000ms exceeded

2015-07-24 10:20:30,001 [myid:1] - INFO [ProcessThread(sid:1 cport:-1)::[email protected]] - Processed session termination for sessionid: 0x14e67e71be5003dG

从上面红色标注处可以得出结论:

jodis客户端超时了会关闭socket,导致zookeeper刚建立的session过期释放。

解决方案:

重新设置以下参数,将连接池中的连接实例和空闲实例增大,另外适当增大超时等待时间,以保证连接实例被释放。

MAX_ACTIVE=1024

MAX_IDLE = 200

MAX_WAIT = 10000

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-12 22:29:50

codis的proxy层HA的相关文章

2F+1模式才是高可用 途牛旅游网 还是通过proxy层

2F+1模式才是高可用 途牛旅游网 还是通过proxy层 f f f f f f f f f

豌豆荚codis描述

Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务. Codis 由四部分组成: Codis Proxy (codis-proxy) Cod

[转载] Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑们

原文: http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=208733458&idx=1&sn=691bfde670fb2dd649685723f7358fea&scene=1&key=c76941211a49ab58cb17c68ecaeeda0f1c083d9508a0f6629461fff9025fd87de4706bd9c1730e0ddbab70568b34b16a&ascene=0&

Codis——分布式Redis服务的解决方案

Codis——分布式Redis服务的解决方案 之前介绍过的 Twemproxy 是一种Redis代理,但它不支持集群的动态伸缩,而codis则支持动态的增减Redis节点:另外,官方的redis 3.0开始支持cluster. codis和twemproxy最大的区别有两个: codis支持动态水平扩展,对client完全透明不影响服务的情况下可以完成增减redis实例的操作: codis是用go语言写的并支持多线程,twemproxy用C并只用单线程. 后者又意味着:codis在多核机器上的性

Codis作者黄东旭细说分布式Redis架构设计和踩过的那些坑们

本次分享的内容主要包括五个大部分: Redis.RedisCluster和Codis; 我们更爱一致性; Codis在生产环境中的使用的经验和坑们; 对于分布式数据库和分布式架构的一些看法; Q & A环节. ??Codis是一个分布式Redis解决方案,与官方的纯P2P的模式不同,Codis采用的是Proxy-based的方案.今天我们介绍一下Codis及下一个大版本RebornDB的设计,同时会介绍一些Codis在实际应用场景中的tips.最后抛砖引玉,会介绍一下我对分布式存储的一些观点和看

十一、codis

一.简介 Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 , 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务. 组成部分 编辑 Codis Proxy (codis-proxy) Codis Manager

安装codis 以及遇到的一些问题

redis集群安装用的是codis ,由豌豆荚开源,相比较twemproxy的好处有很多,参考http://blog.csdn.net/hunci/article/details/51799468 不废话,搞起 下面的安装文档抄袭了小炒肉的,连接如下 https://www.kissni.com/2017/04/06/codis-redis/ 但是部署中也遇到了一些问题 1,在codis make 的时候出现错误 go build -i -o bin/codis-dashboard ./cmd/

redis的分布式解决方式--codis (转)

codis是豌豆荚开源的分布式server.眼下处于稳定阶段. 原文地址:https://github.com/wandoulabs/codis/blob/master/doc/tutorial_zh.md Codis 是一个分布式 Redis 解决方式, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的差别 (不支持的命令列表), 上层应用能够像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作

使用Codis搭建redis集群服务

转(http://www.jianshu.com/p/f8e968e57863) 一. 应用场景 redis 作为数据结构存储引擎,有着很多优点 高性能单机引擎可以达到5-10W qps 数据结构全面,支持快速开发业务string,list,set,sorted set, hashes 问题: 存储容量受限单机最大容量即为单机内存最大容量 单机数据的持久化依赖aof和rdb机制,如果机器整个down掉,服务不可用 二. redis集群选型 正是由于单机redis引擎有着这样的问题,所以,基本每个