RabbitMQ实战指南第四版：分布式消息系统入门

需积分: 10 2 浏览量更新于2024-07-27 收藏 4.49MB PDF 举报

《RabbitMQ实战指南第四版》(RabbitMQ in Action version 4) 是一本专为IT专业人士编写的分布式消息传递技术手册。该书由Manning Publications于2011年出版，旨在帮助读者理解和应用RabbitMQ这一强大的开源消息代理系统，实现高效、可靠的通信架构。本书分为多个章节，涵盖了RabbitMQ的各个方面： 1. **入门与实践**：章节“Pulling RabbitMQ out of the hat”引导读者快速了解并设置RabbitMQ的基本概念和环境，使初学者能迅速上手。 2. **理解消息传递**：通过深入浅出的讲解，章节"Understanding messaging"解释了消息传递的核心原理和在软件系统中的角色，为后续实践打下理论基础。 3. **运行与管理RabbitMQ**：这部分介绍了如何配置、启动和监控RabbitMQ服务器，确保其稳定运行，包括日常维护和故障排查。 4. **解决RabbitMQ问题：编码与模式**：探讨了如何通过编程技巧和设计模式来处理各种与RabbitMQ相关的挑战，提升代码的健壮性。 5. **集群与处理故障**：讲述了RabbitMQ的高可用性和容错机制，包括集群配置和故障恢复策略。 6. **编写经受住故障的代码**：关注在分布式环境下如何编写稳健的代码，确保服务的连续性。 7. **队列与复制：故障转移与数据冗余**：深入讨论了队列管理和数据备份的重要性，以及如何在RabbitMQ中实现这些功能。 8. **Web界面管理与REST API**：展示了如何通过RabbitMQ的Web管理工具和RESTful API进行高级操作和配置。 9. **监控与问题追踪**：“Monitoring: Houston we have a problem”章节着重于实时监控和故障诊断，帮助运维人员保持对系统的掌控。 10. **测试RabbitMQ**：提供了一套完整的测试方法和实践，确保系统的性能和稳定性。 11. **扩展RabbitMQ：智能兔子**：介绍如何利用RabbitMQ的插件和自定义扩展，提升系统的功能和灵活性。附录部分进一步扩展了学习资料，包括： - **Java和.NET的RabbitMQ使用**：针对两种常见编程语言的API和示例。 - **资源汇总**：汇集了社区、文档和工具的相关链接，便于进一步学习和参考。 - **AMQP协议详解**：深入理解RabbitMQ所基于的高级消息队列协议。 - **其他平台部署指南**：指导用户在不同操作系统上安装和配置RabbitMQ。 - **从源码构建Erlang**：对于想要深入了解底层实现的读者，提供了Erlang语言的基础知识。《RabbitMQ实战第四版》是一本实用的指南，无论你是初识RabbitMQ的新手还是经验丰富的开发者，都能从中收获宝贵的知识和实践经验。同时，作者鼓励读者在Manning的在线论坛上提出反馈和问题，共同促进技术交流和进步。

Figure 1.3 Checking RabbitMQ Status

As we can see on figure 1.3, this command will output the status of the broker,

the running applications and nodes. At this point we have a RabbitMQ broker

running in our computer with the default configuration. Let's review what we did:

Downloaded the server package

Unpacked it in our tests folder

Set up the required folder structure

Started the RabbitMQ server

Checked the server status

With those easy steps we got kickstarted with RabbitMQ. Now a little bit more

theory about Me

ssaging and then we will start running some examples against the

broker.

1.6 Summary

Now you can see why we love RabbitMQ so much...despite being the progeny of

technology from the financial industry, it's dead simple to set up. You get complex

routing and reliability features pioneered by folks like TIBCO and IBM but in a

package that's easier to manage and use....and the best part, it's open source! We've

shown how far messaging has come in the past 30 years, from a simple software

bus linking together financial traders, to message routing monsters that are the

beating heart of everything from financial exchanges to the manufacturing lines at

semiconductor fabs. Now you have that kind of power running on your dev

laptop...and we've only finished chapter 1! With RabbitMQ running, it's time to

dive into the building blocks of messaging: queues, bindings, exchanges and

virtual hosts. Let's see how they all fit together and get Rabbit saying "Hello

World"!

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=720

Licensed to Michael Wall <michael.wall@welocalize.com>

Understanding Messaging

When you say "messaging", programmers think of a lot of different things. Email

and IM come most readily to mind, but these models are not what we mean when

we talk about messaging in terms of RabbitMQ. Messaging in RabbitMQ has some

elements in common with e-mail and IM, but really is a completely different

paradigm. For example, while AMQP, like email, does store messages for

consumers who aren't online, those messages are routed based on tags that are

much more flexible. Also different from email, the messages have no set structure

and can even store binary data directly. Unlike IM protocols, AMQP hides the

sender and receiver from each other. There is no concept of presence. As a result,

you have a very flexible infrastructure that encourages pervasive decoupling of

your applications. AMQP messages can be routed one-to-many both in a broadcast

pattern or selectively, as well as, one-to-one. With IM you typically only get

one-to-one.

Since AMQP messaging is very different from other messaging protocols, we're

ing to spend the next few sections explaining the lingo and building blocks of

AMQP. If you have a good basis in enterprise messaging systems like TIBCO or

IBM's MQseries, a lot of this will be familiar to you. Because RabbitMQ's focus is

on application-to-application messaging it's important to understand the concepts

of that messaging pattern clearly. Let's start by forgetting the client/server

distinction we've had ingrained in us and begin figuring out consumers and

producers.

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=720

Licensed to Michael Wall <michael.wall@welocalize.com>

2.1 Consumers and Producers (not a lesson in econ)

If you've ever worked with software that uses the network, you're probably used to

thinking about clients and servers. Whether it's a browser and a web server, or your

app and a MySQL server, you've got someone making requests and someone

servicing them. You could call it the food truck model. Your app places the order

and the food truck fulfills it. The source of the data you want is the food truck

server. It's usually how we try to understand anything that involves our app and a

service. So, with this new messaging approach the first thing you might ask is:

who's the customer, who's the food truck and how do I order?

That's the problem though. RabbitMQ isn't a food truck...it's a delivery service.

e "data" your app gets from RabbitMQ is no more served from Rabbit than the

package you pick up was produced by FedEx. So let's think about Rabbit as a

delivery service. Your app can send and receive packages. The server with the data

you need can send and receive too. The role RabbitMQ plays is as the router

between your app and the "server" it's talking to. So, when your app connects to

RabbitMQ, it has a decision to make: am I sending or receiving? Or in AMQP talk:

am I a producer or a consumer?

Producers create messages and publish (send) them to a broker server

abbitMQ). What is a message? A message has two parts: a payload and a label.

The payload is the data you want to transmit. It can be anything from a JSON array

to an MPEG-4 of your favorite iguana Ziggy. RabbitMQ doesn't care. The label is

a little more interesting. It describes the payload, and is how RabbitMQ will

determine who should get a copy of your message. Unlike say TCP, where you

specify a specific sender and a specific receiver, AMQP only describes the

message with a label (an exchange name and optionally a topic tag) and leaves it to

Rabbit to send it to interested receivers based on that label. The communication is

fire-and-forget and one-directional. We'll get more into how RabbitMQ interprets

the "label" later when we talk about exchanges and bindings. For now, all you need

to know is that producers create messages and label them for routing.

©Manning Publications Co. Please post comments or corrections to the Author Online forum:

http://www.manning-sandbox.com/forum.jspa?forumID=720

Licensed to Michael Wall <michael.wall@welocalize.com>

the letter inside. Similarly, if you need to know specifically who produced an

AMQP message, it's up to the producer to include that information as a part of the

message payload.

From the outside it's pretty simple: producers create messages and consumers

receive them. Your app can be a producer when it needs to send a message to

another app, or it can be a consumer when it needs to receive. It can also switch

between the two. However, before it can do either it has to set up a channel. Wait a

minute...what's a channel?

Before you consume from or publish to Rabbit, you first have to connect to it.

connecting, you're creating a TCP connection between your app and the Rabbit

broker. Once the TCP connection is open (and you've authenticated), your app then

creates an AMQP channel. This channel is a "virtual" connection inside the "real"

TCP connection, and it is over the channel that you issue AMQP commands. Every

channel has a unique ID assigned to it (your AMQP library of choice will handle

remembering the ID for you). Whether you're publishing a message, subscribing to

a queue or receiving a message, it's all done over a channel. Why do we need

channels you might ask? Why not just issue AMQP commands directly over the

TCP connection? The main reason is that setting up and tearing down TCP

sessions is expensive for an operating system. Let's say your app consumes

messages from a queue and spins up or down threads based on service demand. If

all we had were TCP connections, each thread would have to have its own

connection to Rabbit, which could mean hundreds of connects per second during

high load periods. Not only would this be a massive waste of TCP connections, but

there's only so many new connections per second an operating system can build.

So we could quickly hit a performance wall. Wouldn't it be cool if we could use

one TCP connection for all of our threads for performance, but get the same

privacy as giving each thread it's own connection? This is where a channel comes

in. As each thread spins up, it creates a channel on the existing connection and gets

it's own private communication path to Rabbit without any additional load on your

operating system's TCP stack. As a result, you can create a channel hundreds or

thousands of times a second without your operating system seeing so much as a

blip. There's no limit to how many AMQP channels you can have on one TCP

connection. Think of it like a bundle of fiber optic cable.

http://www.manning-sandbox.com/forum.jspa?forumID=720

Licensed to Michael Wall <michael.wall@welocalize.com>

剩余151页未读，继续阅读

dangmail

粉丝: 0
资源: 5

RabbitMQ实战指南第四版：分布式消息系统入门

深入理解RabbitMQ：分布式消息传递实战

RabbitMQ实战指南：分布式消息传递专家

深入理解RabbitMQ：分布式消息传递的必备指南

learning rabbitmq

【Log4j 2深度解析】：配置与性能优化技巧

RabbitMQ实践指南：分布式消息传递

精选微信小程序源码：生鲜商城小程序（含源码+源码导入视频教程&文档教程，亲测可用）

Docker-compose容器编排

整合Springboot shiro jpa mysql 实现权限管理系统（附源码地址）

自定义图片裁剪View

最新资源