网络游戏一般使用RabbitMQ做消息队列吗

不太适合。游戏消息量多而且同步要求高,消息一般不需要缓存,实时响应发出较多。另外,类似战斗或移动的消息,量大而且要求响应迅速用mq性能会有问题。想了下,唯一可能用mq的是聊天服务器,这个实时性要求不高,而且属于不太重要的系统。
■网友
个人理解,网游这种实时性和一致性要求较强的系统,使用MQ来做通信中间件不大合适。更多的肯定还是靠RPC吧。

【网络游戏一般使用RabbitMQ做消息队列吗】 消息队列的场景不是在能够保证有single source of truth的情况下去同步其他服务的状态维护最终一致性的吗?

■网友
消息队列当然 非常有用。
但是 RabbitMQ 估计达不到 这么高的要求。
对于 移动 技能pk 动作 操作 等实时性要求较高的数据当然 不应该用RabbitMQ。
但是如果可以 可以自己搞一个实时性更高的 更简单 延迟更低的消息队列,最简单的比如 Queue 呗。服务器更新的消息可以合并。在Tick允许的时间内的所有消息合并后一次发出去。

RabbitMQ 当然有用比如工会聊天啥的?又或者 和NPC对话之类的消息? 总之 实时要求不高的完全可以胜任。
当然我对 RabbitMQ 还不是很熟悉。
但是印象中 性能不咋地。所以如果有其他性能更好的选择,可以考虑选别的。




■网友
rmq比较注重事务性,一致性,用在企业的业务系统之间通信可能会比较合适。
■网友
谢邀。“一般”这个范围我不好定义,但是即使是现在用erlang做服务器的似乎不是很多(这块真没法统计,只是纯揣测),RabbitMQ的前提是Erlang所以……不过MQ这个概念对于游戏开发来说又有点意思,通过名词(消息队列)曲解他的话其实可以用在很多游戏中,但事实上他给我的感觉又是一种数据驱动的模式(不好意思,我不是程序员,算是个外行看热闹的),而国内游戏行业一则对于数据驱动理解还很浅,二则愿意潜心研究实现的人不多(工资、环境等各方面影响造成),所以残念……因此这个“一般”可能不太合适,不过国内的交流环境真的很差,即使是“开源”都很有“特色”,所以真不好说,还是收集大家的意见吧。


    推荐阅读