Codis proxy layer HA, codisproxy layer HA

Codis proxy layer HA, codisproxy layer HA

For Java users, you can use the modified Jedis ------- Jodis to implement HA on the proxy layer. It monitors the registration information on zk to obtain the list of currently available proxies in real time, which can ensure high availability or achieve Load Balancing by requesting all proxies in turn.

The jodis address is as follows:

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

The specific usage is as follows:

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");}

Some jedis parameters are set as follows:

// Maximum number of available connection instances. The default value is 8. // if the value is-1, no restriction is imposed. If maxActive jedis instances have been allocated to the pool, then, the pool status is exhausted (exhausted ). Private static int MAX_ACTIVE = 10; // controls the maximum number of idle jedis instances in a pool. The default value is 8. Private static int MAX_IDLE = 5; // maximum waiting time for available connections, in milliseconds. The default value is-1, indicating that the connection never times out. If the wait time is exceeded, JedisConnectionException is directly thrown; private static int MAX_WAIT = 3000; private static int TIMEOUT = 5000;

An error is reported during actual operation. Some errors are as follows:

Redis. clients. jedis. exceptions. JedisConnectionException: cocould 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)

As prompted above:

The connection pool set in jedis is too small. When the connection pool is fully occupied, no instance is released during the "MAX_WAIT" wait time, thus timeout, resulting in cocould not get a resource from the pool.

In the zookeeper output log zookeeper. out, you can also see:

10:15:35, 247 [myid: 1]-INFO [NIOServerCxn. Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxnFactory @ 197]-Accepted socket connection from/192.168.1.119: 30275
10:15:35, 254 [myid: 1]-INFO [NIOServerCxn. Factory: 0.0.0.0/0.0.0.0: 2181: ZooKeeperServer @ 868]-Client attempting to establish new session at/192.168.1.119: 30275
10:15:35, 257 [myid: 1]-INFO [CommitProcessor: 1: ZooKeeperServer @ 617]-Established session 0x14e67e71be5003d with negotiated timeout 5000 for client/192.168.1.119: 30275
10:20:24, 576 [myid: 1]-WARN [NIOServerCxn. Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 357]-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)
10:20:24, 577 [myid: 1]-INFO [NIOServerCxn. Factory: 0.0.0.0/0.0.0.0: 2181: NIOServerCnxn @ 1007]-Closed socket connection for client/192.168.1.119: 30275 which had sessionid created later
10:20:30, 000 [myid: 1]-INFO [SessionTracker: ZooKeeperServer @ 347]-Expiring session 0x14e67e71be5003d, timeout of 5000 ms exceeded
10:20:30, 001 [myid: 1]-INFO [ProcessThread (sid: 1 cport:-1): PrepRequestProcessor @ 494]-Processed session termination for sessionid: 0x14e67e71be5003dG

We can draw a conclusion from the above red mark:

When the jodis client times out, the socket is closed, causing the newly created session of zookeeper to expire and be released.

Solution:

Reset the following parameters to increase the number of connection instances and idle instances in the connection pool, and increase the timeout wait time to ensure that the connection instance is released.

Max_actively = 1024

Max_idle= 200

Max_wait= 10000

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.