本文环境：

jedis 2.1.0

redis 2.8.13

Redis无响应

我们的各个子系统均使用Jedis作为Redis的Java Client读写数据。

Jedis底层使用Apache的Common Pool，每个Jedis对象在底层都视为一个Object。

当释放连接失败后，我们的做法只是输出错误日志，这会导致该连接无法回收再利用，最终服务器的连接池会被拖垮，现象就是我们遇到的无响应、重启就好。

此前我们分析过，现在得出的结论是：这不是服务器操作系统连接数的问题，也不是数据频繁读写的问题，而是释放资源时遇到异常时，我们没有将该连接直接断掉、丢弃。

如下是AEnv代码的相关变更情况，仅做参考：

高效读写调研

常用的Jedis读写方式包括：set/get、hset/hget和mset/mget，分别用作基本读写、hash读写和批量读写。

对此，我进行了一次性能测试（见下图）。

从结果上看，批量读写的优势是非常明显的，如果子系统有类似业务逻辑，希望考虑这种形式。对于hash读写，在数据量聚集在某个特殊范围内时，其效率是比基本读写要高的。

另外，Jedis的单点是线程不安全的，通过Apache的Common Pool获取的Jedis实例是线程安全的，因此不建议子系统使用new一个实例的方式。

Master-Slave调研

Redis的主从环境，我已经使用Docker搭建好，参见[[Docker系列·10] 搭建Redis服务器](

本次调研的目的是：观察主从复制、读写分离是否可以提高读写效率（虽然主从模式会提供高可用性，但目前子系统更关注的是速度）。

测试采用两个Jedis线程池一主一辅，主写、辅读。

单线程的测试结果如读写性能并不高。

100个线程的测试情况如下。从图中可以看出，数据量增到10000条的时候是个拐点，读写分离在此处开始呈现优势。不管是否读写分离，单次SET永远不是高效的写入方式。

附：

Docker Redis示意图：

![2014_08_27_redis_master_slave]