It all depends on the type of game, the update frequency, and the amount of data you are sending.  Are you doing authoritative physics for a real-time shared simulation like in a fast FPS game?  Then this "might" not work for you.  It all depends on how much performance you need, and how much data you are intending to send/receive.  There's also TCP vs UDP, RabbitMQ I believe only works over TCP, so you'll be incurring significant extra lag when you lose packets.

If your game only needs to communicate simple data bits infrequently (10 updates per second or less), and you can tolerate up to 1second lag times, then you might be fine. 

Otherwise I would recommend a library that uses UDP or writing the UDP netcode code yourself.

Best of luck!

There are two things you need to consider here.

First: Message queues are great at throughput -- measured in megabytes per second or perhaps messages per second. But they generally get this benefit by being less great at latency. There may be significant initial latency even at low load, and latencies may start going up as load increases. If you measure these quantities, and they are sufficient for your gameplay needs, then that's not an actual problem for you, but for most action-oriented games, these have not worked out in the past.

Second: Message queues are generally programmable APIs. But you don't want your players to program the message queue, so you have to make sure that the security configuration of the message queues is water tight. Often this ends up being hard because the notion message queues have for queue lifetime, or permissions, or users, match poorly with the needs of a multiplayer game. (One message queue I tested ten years ago had to be restarted each time a new user was added to the set of allowed users!) The work-around here is generally to build a front tier of application servers that actually talk to the game clients, and not let the game clients talk directly to the message queue. The application servers then have to do user identification and topic permission checking in a way that matches the need of the game. At that point, the message queue is just a back-end switching fabric, and there are plenty of other options that might work just as well, or better, for games -- from "there's one server, and everything talks in memory" to "everyone shares a UDP broadcast domain" to "Use ZeroMQ for application servers to find each other and route messages" to "use Redis Pub/Sub" are all reasonable options, depending on the specifics of your game.

Which of these properties matter for your particular game? I don't know. You'll have to figure it out and let us know!