Mac环境下Ruby使用RabbitMQ无法接收消息求助

Hey there! Let’s work through this together— I’ve run into this exact issue when starting out with RabbitMQ, so let’s break down the most common fixes step by step:

1. Double-Check Queue & Routing Key Match #

The #1 reason messages don’t get delivered is a mismatch between your publisher (new_task.rb) and worker (worker.rb) when it comes to queue names or routing keys.

• Make sure both files reference the exact same queue name. For example, if new_task.rb publishes to task_queue, your worker must be consuming from that exact queue (typos here are super easy to miss!).
• If you’re using an exchange (not the default one), confirm the routing key in the publisher matches the binding key in the worker. For the default exchange (empty string), the routing key must equal the queue name.

Quick sanity check snippets:
In new_task.rb, look for:

channel.default_exchange.publish('Hello World!', routing_key: 'task_queue')

In worker.rb, ensure you declare the same queue:

queue = channel.queue('task_queue', durable: true)

2. Verify Queue State & Durability Settings #

If you tweaked durability settings after creating the queue, RabbitMQ might be using an outdated queue with mismatched configs.

• Run rabbitmqctl list_queues in your terminal to see all existing queues. Look for your queue name—if it exists but has unexpected properties (like durable: false when you intended true), delete it with rabbitmqctl delete_queue task_queue, then restart both your publisher and worker.
• Even without persistence, messages should still deliver if both processes are running at the same time, but mismatched durability can cause silent failures.

3. Confirm Connection Details Match #

It’s rare on a local Mac setup, but sometimes the worker connects to a different RabbitMQ instance than the publisher.

• Check that both files use identical connection parameters. The default is localhost:5672 with guest/guest credentials, but if you changed any of these, make sure they’re consistent:

connection = Bunny.new(host: 'localhost', port: 5672, username: 'guest', password: 'guest')
connection.start

• You can also check RabbitMQ’s logs for connection issues. On Mac (if installed via Homebrew), logs live at /usr/local/var/log/rabbitmq/rabbit@localhost.log—look for errors like "connection refused" or authentication failures.

4. Check if Messages Are Actually Queued #

Let’s confirm messages are landing in the queue at all. After running ruby new_task.rb, run:

rabbitmqctl list_queues name messages_ready

You should see your queue name with a messages_ready count of 1 (or more if you ran the publisher multiple times). If the count is 0, your publisher isn’t sending messages to the right queue.

5. Ensure Your Worker’s Consumption Code is Correct #

Double-check that your worker is set up to properly listen for messages. It should look something like this:

queue.subscribe(block: true) do |delivery_info, properties, body|
  puts " [x] Received #{body}"
  # If you have a sleep here to simulate work, make sure it’s not hanging indefinitely
  sleep body.count('.')
  puts " [x] Done"
end

• The block: true flag is critical—it keeps the worker running and waiting for messages instead of exiting immediately.
• If you added custom error handling, make sure it’s not swallowing exceptions that would prevent message processing.

6. Restart Everything (Yes, Really!) #

Sometimes weird state issues get fixed with a fresh start:

• Stop RabbitMQ: brew services stop rabbitmq (if installed via Homebrew) or rabbitmqctl stop
• Start it back up: brew services start rabbitmq
• Kill any running Ruby processes (your worker and publisher) and restart them from scratch.

内容的提问来源于stack exchange，提问作者Tracey Wang