Thrift底层通信的是netty实现的吗?

发布于 2021-12-04 06:15:19 字数 494 浏览 812 评论 12

     我们的系统是基于thrift做的,现在出现的问题是 外部的连接过多或者有连接死掉了会导致我们的系统连接满了,也就是请求从client端无法连接到我们thrift的服务端,总报错超时,其实我们看了后台并没有报错,服务端也没接收到,所以推测可能是thrift连接满了,其他的请求进不来(网络问题都排除了)。

     所以目前我们想重构这里的实现逻辑,使用netty+protobuf或者直接使用netty+tcp(json形式传参数),不再使用netty。

     疑问如下:

1. thrift底层的通信模块是不是netty实现的?我看到thrift底层的Server模块提供了四种,但是这四种不知道区别,也不知道哪一个类似netty的机制。求大神告知?

2. thrift遇到我上述的问题如何优化?

3. netty+protobuf实现之后会不会再出现这种问题了?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(12

伪装你 2021-12-04 16:40:27

怎么串行?我们就是卡死导致的其他服务接入不进来

能否归途做我良人 2021-12-04 16:40:23

回复
客户端向RPC服务器发起调用的时候,把操作统一丢到一个线程去执行,而不是在各自的线程执行,如果在各自的线程执行RPC客户端端调用,需要加锁。从而保证RPC调用是个原子操作。 thrift RPC调用不是原子操作,如果同时2个rpc调用(在同一个连接)上,则会导致服务器卡主,无法回复,只能重启服务器,通过看服务器的调用堆栈是可以看出来thrift服务器卡在读数据那边。

如此安好 2021-12-04 16:40:22

请注意thrift的rpc调用是非线程安全的。相同的thrift链接,调用rpc时一定要串行。。否则会导致服务器一直卡住。从而无法继续提供thrift服务。

樱花落人离去 2021-12-04 16:40:17

是不再使用thrift吧?thrift底层的通信好像也是netty写的

爱的那么颓废 2021-12-04 16:40:17

thrift底层的通信是netty写的. 请注意server不同的线程服务模式.

最偏执的依靠 2021-12-04 16:40:17

ulimit

网名女生简单气质 2021-12-04 16:40:17

没懂啥意思?

滥情空心 2021-12-04 16:40:12

你们当初换掉thrift,改用netty作为底层通信模块的原因是什么?thrift性能有问题还是有其他的奇葩问题?

谁的新欢旧爱 2021-12-04 16:31:57

你提到thrift的server模块支持4种时我就猜到你看过这篇文章了,严格来说不止这4种。我可以很负责地回答你thrift性能不算差,我也没有完全用netty替换thrift,只是多提供了一种选择而已,你遇到的问题我估计是你们自己没有管理好socket造成的。

刘备忘录 2021-12-04 16:30:02

thrift和netty都是很好的项目,没有谁好谁坏一说。(补充一下:要判断thrift有没有用到netty很简单,libthrift源码下载来全文检索'netty'不就知道了么)

如日中天 2021-12-04 16:17:46

回复
我确定他没有使用netty,我想知道他的几个server的实现是不是高仿那个netty,高仿这种方式搜netty是不行的

柠檬 2021-12-04 15:53:33

回答你的问题:thrift默认不是netty实现的,但可以用nifty实现.nifty项目其实就是netty+thrift.

其实你想做的事情我已经做过了,可参考ikasoa项目.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文