dubbo反序列化异常导致服务负载飙高、吞吐率下降

发现问题

如果consumer端的pojo对象的版本号低于provider端,provider端返回consumer端不存在的pojo对象。dubbo默认用hession在consmer端反序列化时,会抛出一个warning的异常。如图:

看了下dubbo源码,发现hession在反序列化,调用Class.ForName(type, false, classLoader)失败时会抛出此异常warning。这里hession会兼容这个异常,返回空。而不像kryo等其他序列化工具那样直接返回请求失败。所以大家最好不要轻易更换dubbo序列化工具,默认选择hession,dubbo肯定是考虑的多方面的因素。这里抛出的这个异常说明在consumer端当前线程的classloader中没有这个pojo对象。

这里注意下如果Class.ForName(type, false, classLoader)反射正常,dubbo会将反序列化的对象cache起来。即反射只会执行一次,后续同样type的请求走缓存。但是如果反射失败,每次请求都会执行Class.ForName(type, false, classLoader)。说到这里大家应该知道了为啥服务飙高、吞吐率下降了吧。

解决方案

定位了问题,那么逆向思考,只要保证在反序列化发生异常时反射也只发生一两次,服务的负载就不会飙高,吞吐率也不会下降。所以在反射失败时动态想classloader创建一个空的pojo class,或者在dubbo缓存的map中,针对当前type指定一个占位符,即可解决问题 

示例代码

这里用到了javassist创建动态的type类型的代理对象,在ctClass.toClass()放入当前线程的classloader后,重新反序列化一次,这样dubbo就会将type类型的反序列化对象cache起来。

dubbo默认是使用Hessian2SerializerFactory做序列化工作,那么如何用自定义的Hessian2SerializerFactoryExtension扩展对象替换下默认的Hessian2SerializerFactory呢?继续翻源码,发现所有的序列化实现都被dubbo缓存到CodecSupport.java的ID_SERIALIZATION_MAP中了,那么我只需要获取到这个map,用Hessian2SerializerFactoryExtension覆盖Hessian2SerializerFactory即可。

参考代码地址:https://github.com/qinpeirong0011/dubbox/tree/2018-01-18-qinpr

你可能感兴趣的:(dubbo反序列化异常导致服务负载飙高、吞吐率下降)