souryou

EQtxg3Z8sxZRHi7FFuCZRHuWKHZrVhc4i23RMgfXWv9d

感谢大佬 空投

EQtxg3Z8sxZRHi7FFuCZRHuWKHZrVhc4i23RMgfXWv9d

EQtxg3Z8sxZRHi7FFuCZRHuWKHZrVhc4i23RMgfXWv9d
蟹蟹老板

你这个问题还真不好说，你说的网线大概率是 300Mbps ，理论上能跑 37.5MB/s,全双工就没啥影响;我感觉网络上没啥问题，你说过了，单独到电脑是 ok 的。现在怀疑电脑硬盘读写跟不上，你测试下在硬盘中拷贝东西，然后同时上传到 nas ，这样没有下载网速，但是有上传（通过资源管理器看下磁盘读写，尽量跟你现在情况保持一致），看下打开网页如何

插眼关注，感觉不是线程问题（或者看下 2 楼说的？有资源竞争问题吗）。在排查下队列问题吧，有些队列有调度机制，会不会认为你的处理速度上有问题，然后给的调度少了，楼主用的什么队列，可以的话剥离业务逻辑，show your code

@daimaosix
1. 它俩的确认应该都不用在编程逻辑中处理，需要处理的就是消息去重逻辑，避免二次消费

2. 对于 consumer 数量问题，是不是可以考虑每个客户对应一个 agent 来消费来自这个客户的 topic ，然后在根据服务器 ip 、mac 等唯一参数，进一步划分二级 topic ；或者根据客户 ID 加上服务器 ID 直接细化 topic ，但是每引进一个中间（件）过程，系统的鲁棒性就多一次考验。


将所有用户的客户端全部作为消费者来消费这一个主题，让消费者来根据消息内容中的用户 ID 来决定是否消费，这样是否可行呢?

不建议这么搞。这个无用处理有点儿多（每个机器处理客户机器数量 n 的消息，但是有 n-1 是忽略的），而且属于广播模式，恰巧应该消费的机器由于网络或真实掉线，消息容易丢失。

恰巧两个都用过，不过没在 rust 下用过

1.对于这个 '发现 Kafka 对于消费结果确认似乎不如 RabbitMQ 方便' 我没有太理解不方便指具体是哪方面，我看 [demo]( https://github.com/kafka-rust/kafka-rust/blob/master/examples/example-consume.rs#L47) 中没有太复杂

2. 你所提到的 3000-5000 负载远远没有达到他俩的正常运行阈值，所以这点应该没啥问题，这个量再 X10 的话推荐 Kafka

3. 'Kafka 性能要比 RabbitMQ 优异' ,这个也得结合具体项目来看，按照你说的极端情况在 5k 左右的话，他俩哪个都没有问题

4. 其他方面还要根据项目、人员使用熟练度来选

**注意 ** : 一个客户一个主题，客户下设备数量需要考虑

kafka 根据 consumer 多于 partition 数量会闲置，rabbit 默认是轮训