Jedis集成与踩坑经历

Jedis简介

Jedis是Redis的Java客户端实现，封装了对Redis的通讯和命令处理等。

Jedis提供了资源池，能够很方便地实现对Redis的API调用。

Jedis集成

目标

以前是经过组内对Jedis封装的Spring Bean来获取和使用Jedis的，如今但愿自行实现相似功能，设计目标以下：

1. 封装为Spring FactoryBean
2. 集成目前自行实现的基于ZooKeeper的配置中心组件
3. 获取单个链接，避免每次调用须要从资源池中获取一个链接的额外操做（其实还有归还操做）
4. 实如今服务启动依赖注入后配置变动仍然能生效

思路

具体思路就是针对设计目标而定的：

1. 实现FactoryBean
2. 接入Config组件
3. DCL单例生成资源池JedisPool，并经过动态代理提供Jedis链接，链接从JedisPool中获取
4. 配置变动后使用新的JedisPool替换旧的

具体实现

因为需求比较基础，尚未太多应用场景，实现也没考虑太复杂。总体逻辑不到50行，能够在个人GitHub上大体看一下。

后续使用能够直接使用Spring将Bean注入。

Jedis踩坑

因为不按常规方法使用JedisPool可能背离了JedisPool设计的使用场景，所以在其中踩了很多坑。

其次，虽然日常经常使用组内的Jedis组件，但实际上对Jedis的API不了解，本次根据日常使用过程当中的一些感觉进行“黑盒临摹”，在爬坑过程当中其实也学习了其余一些方面的经验，好比Guava Reflections等。

坑#1 并发异常

背景

最开始经过FactoryBean提供的链接并未使用动态代理，也就是说仅提供了一个Jedis，全部线程使用同一个Jedis链接。

现象

业务中较频繁地报异常，异常信息为java.lang.ClassCastException: java.util.ArrayList cannot be cast to [B等，基本是ClassCastException，异常抛出位置为调用Jedis的位置。

• 初看觉得是Jedis的泛型bug，但不是必现，能够排除这种猜想；
• 有人认为是对于Redis的响应命令处理不完善，如OK、NIL等响应，但这种bug过低级了，不该该出如今Jedis这种久经考验的库中，排除；
• 有人认为发生异常状况时Jedis的buffer未清空，致使后续使用中残存以前的错误数据，这个却是有点道理，由于这种状况不是必现，但同上一条，不该该出如今这种库中；

缘由

最终在另外一篇资料指引下来到jedis/issues，在参考资料中发现了最可信最合理的缘由：Jedis并不是线程安全，不该当并发操做。

正确使用

Single connection. Single thread.

正如参考资料中回答提到的，每一个线程（每次调用）都从JedisPool中获取一个链接，并在使用后归还。

也正是由于这一点跟最初的FactoryBean封装方式冲突了，后来才改用提供动态代理类的方式封装FactoryBean。

坑#2 须要手动归还链接

背景

我使用的Jedis版本为3.0.1，网上的很多资料指出在使用链接后归还可使用JedisPool的void returnResource(Jedis resource)方法，但在3.0.1版本中这个方法是protected可见的，没有间接调用方法。

另外Jedis源码中找不到注释，这有点奇怪，我想固然地认为版本升级后能够自动归还资源了，因而仅在设置最大链接数以后就部署到业务中了。

现象

业务线程启动后每访问必定次数（调用Jedis达到必定次数）后就彻底不响应请求了：

• 后续全部请求超时无响应
• CPU正常，内存正常
• Java线程有很多处于等待状态，GC正常，但从日志看没有任何请求到达Servlet
• Nginx（用于反向代理）日志中响应状态码是499
  • 499是Nginx自定义的，对应的是client has closed connection即用户浏览器断开Http链接了

仍是在参考资料的指引下查看Tomcat监听的端口，的确不少链接处于CLOSE_WAIT状态，代表客户端已断开链接（我本身测试的时候刷新页面太多，不少就中途断开了）。

缘由

结合TCP四次挥手过程，应该是中间有资源释放不了致使没有进入LAST_ACK状态，推测是Jedis链接资源未归还而总链接数有限制，致使不少线程在等待获取Jedis资源。

正确使用

在Jedis链接使用完毕后，须要调用Jedis的close()方法将资源归还JedisPool，close方法是用于替代returnResource方法的。

这个方法语义比较奇怪，真实做用是“归还或关闭链接”，最开始其实就是考虑到资源复用的问题才没有考虑使用这个close方法的。

能够优化的点

对比了一下组内的组件，思路差很少，还有如下的点可以扩展：

1. 多种资源池的兼容性
2. 接入监控上报

参考资料

ClassCastException - B cannot be cast to java.lang.Long · Issue #186 · xetorthio/jedis

nginx 499状态码 - 微信-大数据从业者 - 博客园

深刻分析Tomcat无响应问题及解决方法 - 月下狼的我的页面 - OSCHINA

jedis:链接池(JedisPool)使用示例 - 10km的专栏 - CSDN博客

Jedis使用|returnBrokenResource|returnResource废弃替代 - 诗人不写诗 - CSDN博客

本文搬自个人博客，欢迎参观！