开发者社区> 超努力的写代码> 正文

一起变更引发的惨案(下)

简介: 一起变更引发的惨案(下)
+关注继续查看

四. 为什么会分配176兆的内存空间?

解决这个问题,有助于了解哪些场景下会触发OOM,从而更好地避免。


参考Thrift TServiceClient的receiveBase()方法,详细介绍了返回值的解析过程,参考下图可以更好地理解,基本上是一个从前到后类似堆栈的反序列化:


image.png


前面已经介绍过,如果返回值中多了参数、或者参数类型不对,Thrift可以通过skip()操作对该字段进行忽略。但thrift对struct结构体有个额外的操作,就是解析完成后的调用validate()方法,如果结构不合法,会抛出异常:


image.png


正常情况下,这里抛出异常,请求失败,应该关闭该连接,或者想重用连接的话,要先把底层Socket的输入流做清零处理。但Thrift未对输入流做任何处理,直接重用了该CLient实例及其底层的Socket连接,导致下一次解析响应数据时,读取的是上一次请求失败未处理完的数据。由于连接及底层Socket被重用,下一次发出请求,很快收到响应,Thrift惯例开始读取消息头:readMessageBegin→readI32(),由于存在未清空的脏数据,根据上图的堆栈分析,readI32()时读取的这4个字节,分别是:




byte type = TType.STRING; // 字节0:Item第一个字段(name)的类型,String,值为11

short id = 1;             // 字节1和2:Item第一个字段(name)的位置,值为1

int size = 6;             // 字节3:Item第一个字段(name)的size的首字节,值为6


byte(1个字节)+short(2个字节)+int(第1个字节),按big endian编码,其值恰好等于184549632:


image.png


小结:184549632的出现有其必然性,不恰当的IDL变更,Thrift客户端抛出异常后未做输入流清理,下一个请求会把之前的残留数据,错误解析成字符串大小,很快导致OOM。


五. 没遇到OOM,我是不是很幸运?


当然依IDL不同、异常抛出的位置不同,读取消息头时readI32()读取的数字不一定恰好是184549632。项目中提供了一个叫做sample2的IDL,旧Client访问新server时,该值的大小是8388864,大约等于8M,因此10个并发甚至100个并发也不一定会触发OOM。


所以当有不恰当的IDL变更,你没遇到OOM,只是幸运而已。


但进一步分析,这种情况虽不会触发OOM,但客户端一直等待服务端返回8388864个字节的数据,久等而不得,于是该连接被阻塞了,一直到超时。


image.png


小结:不恰当的IDL变更,不会全部导致OOM,也有可能导致大量连接被阻塞,直到超时错误。


六. 如何修复OOM?


参考Thrift themissing guide文档,IDL变更要有规范,并在团队内反复宣导。

讽刺的是,“通过规范、最佳实践来避免Crash类问题”,本身就不是一种最佳实践,至少使用Http协议不用遇到这种问题。


这可以认为是Thrift自身的一个缺陷,作为当前广泛使用的RPC协议,需要优雅地处理用户必须遇到的IDL变更的问题。


思路一:读取任何struct类型的字段时,catch住异常,保障thrift把输入流的所有数据读完


Thrift在反序列化阶段,遇到任何struct类型的字段,读取结束后都会调用validate()方法,因此在struct类型字段的读取时,可以添加try-catch校验异常,保证thrift读完所有的数据。


image.png


该思路经测试验证可以,但需要修改的地方较多,不具备可操作性。

思路二:无论是否抛出异常,从协议层面保证清空输入流的残留数据

该思路具备较好的收敛性,只需要修改Thrift源码的2个文件:TServiceClient修改如下图1,TSocket类的修改如下图2:


image.png


经压测验证,在Macbook Air上,使用100个并发进行验证,持续15分钟,累计发送~160万次请求,单次请求响应数据量~0.5K,除了正常报错,客户端、服务端内存无任何异常。

小结:Thrift IDL变更不可避免,上下游版本不一致也不可避免,协议其实可以做到优雅地去处理,而不是OOM了事。

七. 有没有临时方案?

思路一:使用严格读模式?

Thrift众多的配置项中,有严格读(strictRead)、严格写(strictWrite)两个选项,由于严格读默认值为False,改为true是否可以呢?如果OK的话,只需要修改配置而无需修改源码,这将会是最轻量级的方案。查看Thrift源码,如果命中严格读会提前报错,避免下方readStringBody()方法分配太大的内存空间:


image.png


// 很多情况下大家如此使用TProtocol创建连接,此时strictWrite值为true,而、strictRead值为false;

TProtocol protocol = new  TBinaryProtocol(transport);

// 严格读:直接创建TBinaryProtocol,传入参数

TProtocol protocol = new  TBinaryProtocol(transport, true, true);

// 严格读:使用Protocol工厂模式,传入参数

TBinaryProtocol.Factory protFactory = new  TBinaryProtocol.Factory(true, true);


经测试验证,使用严格读之后,客户端还会报错,但OOM问题消失了!“貌似”这也是我们想要的结果,压测效果如何呢?

在MacbookAir上,使用100个并发进行验证,5分钟之后,发送大约56万请求,客户端出现大量的SocketException(Broken pipe),甚至客户端开始宕死。

究其原因,strictRead虽然避免了创建大量字节数组,但抛异常时thrift也未对输入流做任何清理,会产生误读取残余数据,甚至引起连接阻塞。

所以使用严格读,并不能解决这一问题,同样thrift提供了另外一个配置项“读取字符串或字节的最大长度(stringLengthLimit_)”,也不能解决该问题。


思路二:使用短连接?

每个请求创建一个短连接,用完就关闭?这样虽可以避免请求之间的数据污染,但毫无疑问也会带来较大的性能损失,通常不建议。


思路三:使用TFramedTransport?

TFramedTransport对整帧数据使用了缓存,一次性把底层Socket中Inputstream中的数据完全读到了readBuffer,理论上不会出现OOM了。

验证了一把,很可惜还是会OOM,原因是抛异常之后,TFramedTransport中的readBuffer中的数据未做清理,下次请求会错误读取readBuffer中的残余数据。

如果你想验证,可以运行OldClientNewServerTest中的测试用例:oldclient_should_oom_if_use_TFramedTransport_at_concurrency_10

小结:使用严格读、限制字符串长度等配置方式,使用TFramedTransport都不能完美解决问题,要么OOM,要么连接被阻塞。而短连接对性能影响较大,在Thrift中也很少使用。

八. 总结

Thrift IDL不恰当地变更,当上下游IDL版本不一致时,极易引发字段错位、连接阻塞、甚至OOM。Java、Go等语言实现中均存在该问题,并广泛存在于Thrift 0.9到最新的0.13.0-snapshot等各个版本。

该问题触发的根本原因是:客户端接收数据后,对struct类型做validate()时抛出异常,并未对底层的socket输入流做清零处理,后续请求误把残留数据读作字节长度,极易引发OOM,或者导致Socket连接阻塞超时。

Thrift IDL变更不可避免,上下游版本不一致也不可避免,从协议层面提供优雅支持是完全可能的。已向Thrift提交Issue,以及部分语言实现的Pull Request,但争吵几轮之后,Thrift维护人员拒绝合并,认为“遵守最佳实践就够了”,他们敷衍的态度太让人piss off了。

所以当前最好的办法是,在团队内部反复宣导:Thrift IDL变更要遵守规范,尤其不要更改已有字段的序列号,任何变更记得通知调用方,以及Thrift themissing guide里面的更多内容。

 

作者介绍:张晓庆,滴滴高级技术专家,目前主要从事压测、容量管理方向的工作,您可以通过微信aqignsao916或者GitHub联系他,https://github.com/aqingsao

往期推荐

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
18623 0
使用SSH远程登录阿里云ECS服务器
远程连接服务器以及配置环境
12392 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,大概有三种登录方式:
8936 0
如何设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云安全组设置详细图文教程(收藏起来) 阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程。阿里云会要求客户设置安全组,如果不设置,阿里云会指定默认的安全组。那么,这个安全组是什么呢?顾名思义,就是为了服务器安全设置的。安全组其实就是一个虚拟的防火墙,可以让用户从端口、IP的维度来筛选对应服务器的访问者,从而形成一个云上的安全域。
16961 0
windows server 2008阿里云ECS服务器安全设置
最近我们Sinesafe安全公司在为客户使用阿里云ecs服务器做安全的过程中,发现服务器基础安全性都没有做。为了为站长们提供更加有效的安全基础解决方案,我们Sinesafe将对阿里云服务器win2008 系统进行基础安全部署实战过程! 比较重要的几部分 1.
11692 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
17894 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
24727 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
19579 0
1946
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载