souryou

插眼关注，感觉不是线程问题（或者看下 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 默认是轮训

@zero47 哈哈哈，给他们那个钱还不如去老马家找个维修的，不过不是磕碰或者进水一般没啥大事儿。我的 304 ，vertical ，g903 都没啥问题，除了连击。啥毛病没有

没啥可纠结的，我 20 年买的 vertiacl ，现在还在服役。期间连击了（这个是罗技的通病）然后自己换了微动，现在 300 多万次点击了，没有肉眼可见的问题。电池依然坚挺，就是它这个材质有点留下痕迹了

@maclanelf134 成功定位问题，已经解决一半了，op 加油还有半天周末愉快

op 3 楼说的是梯，可以爬上去看得高的那种梯可理解？看似就是网络问题，你说两台机器都有问题，两台机器都是双网卡吗？你的 c 和 p 貌似没在一个网段呢，如果双网卡，确定 10 跟 192 通吗？指定下注册、消费网段一致尝试下呢。另外把当前环境，使用版本，服务部署情况尽量多提供些，方便帮忙排查

你的 usb 切换器是哪个品牌型号的？我盲猜的，usb 切换瞬间应该是掉电了，造成键盘重新初始化（你可以验证下不通过切换器，就是重新插拔下键盘看看是不是背光又打开了？），如果是这样可以给切换器加个电容试下。简单点儿可以通过软件共享键鼠，类似逻技的 flow （不知道能不能满足你的场景需求）

谢谢 op ，参与一下 盼望中奖。