koutann2022-09-07 来自上海运维同事分别在客户端和 MQ 服务器上，在服务器上写一个脚本，每 500ms 采集一次 netstat 。从客户端的日志信息发现Recv-Q 中出现大量积压 ====== 这里MQ服务端采集到的netstat日志Send-Q有积压现象吗？ 如果没有积压的话，因为服务器IO线程数量不足导致的问题，为啥会导致客户端的Recv-Q出现积压呢作者回复: 这个问题问的非常棒，讲真，其实这里的逻辑，受限于我网络方面的知识，目前还不能给出一个底层的逻辑，后续解决这个问题，还是想着从网络层面再想想版本，就仔细阅读了相关的源码，发现的那两个参数，调整后确实效果好了，问题得以解决，关于网络方面，我估计在今年4季度会针对性的学习，学习成功将发布在我的公众「中间件兴趣圈」，欢迎关注，我们后续多多交流。
共 3 条评论2
越过山丘2022-09-11 来自上海return producer.send(msg,500); //设置超时时间，为 500ms，内部有重试机制 这里的500ms低于 Broker maxWaitTimeMillsInQueue=1000 会不会导致 Broker繁忙时候或者网络抖动时间，响应时间超过了500ms，导致客户端所有消息都重试多次，重试消息和之前的消息都积压在Broker的内存中，一方面对Broker造成压力，影响Broker的正常处理能力，一方面造成消息的重复率变高 目的是让客户端快速作者回复: 对的，为你👍，消息发送阶段的重复率会变高，这里需要做权衡，主要是因为消息发送超时，会占用线程资源，如果并发比较高，消息发送超时发生概率大，就有阻塞线程，导致线程容易耗尽，造成用户使用响应极慢。当然在实践过程中，可以让设置的超时时间大于maxWaitTimeMillsInQueue
小杰2022-08-04 来自北京请教老师： 1、netstat里面的队列是tcp的发送和接受队列吗？ 2、netty的发送缓存和tcp的发送缓存怎么个区别呢？怎么看这两个呢？ 3、老师给的那个awk -F '[, ,:]' '$12>2' r.log |wc -l 为啥是12列，咋看不懂呢？