消息中间件 RabbitMq

消息中间件详解:异步处理与系统解耦
消息中间件是用于在应用程序之间进行异步通信的工具,确保消息即使在接收者不可用时也能传递。它分为点对点和发布/订阅两种模型。点对点模型中,消息仅有一个消费者,而发布/订阅模型允许多个订阅者接收同一消息。消息中间件有助于实现系统的松耦合,例如在支付系统和订单系统之间的解耦,提高系统稳定性。

消息中间件是什么?

消息中间件是在消息的传输过程中保存消息的容器。消息中间件再将消息从它的源中继到它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递;如果发送消息时接收者不可用,消息队列会保留消息,直到可以成功地传递它为止,当然,消息队列保存消息也是有期限的。

消息中间件 特点

1、采用异步处理模式
消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虚拟的通道(主题或队列)上,消息接收者则订阅或是监听该通道。一条消息可能最终转发给个或多个消息接收者,这些接收者都无需对消息发送者做出同步回应。整个过程是异步的。比如用户信息注册。注册完毕后过段时间发送邮件或者短信。


2、应用程序和应用程序调用关系为松耦合关系
发送者和接受者不必了解对方、只需要确认消息,发送者和接受者不必同时在线;
比如在线交易系统为了保证数据的最终一致,在支付系统处理完成后会把支付结果放到消息中间件里通知订单系统修改订单支付状态。两个系统通过消息中间件解耦;

消息中间件传递模型

1、点对点模型(PTP)

点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对应于消息服务中的一个队列(Queue),在消息传递给消费者之前它被存储在这个队列中。队列消息可以放在内存中也可以是持久的,以保证在消息服务出现故障时仍然能够传递消息。

     1、每个消息只用一个消费者
     2、发送者和接受者没有时间依赖
     3、接受者确认消息接受和处理成功

2、发布/订阅模型(pub/sub)

发布者/订阅者模型支持向一个特定的消息主题生产消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下,发布者和订阅者彼此不知道对方。这种模式好比是匿名公告板。这种模式被概括为:多个消费者可以获得消息.在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅(subscription),以便能够消费者订阅。订阅者必须保持持续的活动状态以接收消息,除非订阅者建立了持久的订阅。在这种情况下,在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。

1、每个消息可以有多个订阅者
2、客户端只有订阅后才能接收到消息
3、持久订阅和非持久订阅

 

 

### RabbitMQ 消息中间件使用教程 #### 添加开机启动 RabbitMQ 服务 为了确保 RabbitMQ 在服务器重启后能够自动运行,可以通过 `chkconfig` 命令将其设置为开机自启。执行以下命令即可完成配置: ```bash chkconfig rabbitmq-server on ``` 此操作适用于基于 SysVinit 的系统环境[^1]。 #### 开启用户远程登录 如果需要允许远程客户端连接到 RabbitMQ 实例,则需修改其配置文件以支持远程访问。具体步骤如下: 1. 进入 `/etc/rabbitmq/` 目录并复制默认的配置模板至当前目录: ```bash cp /usr/share/doc/rabbitmq-server-3.7.5/rabbitmq.config.example /etc/rabbitmq/rabbitmq.config ``` 2. 编辑 `rabbitmq.config` 文件,在其中定义必要的参数来启用远程访问功能。例如,可以指定监听地址和端口等选项[^2]: ```erlang [ {rabbit, [ {loopback_users, []}, {tcp_listeners, [{"0.0.0.0", 5672}]} ]} ]. ``` 上述配置移除了仅限本地回环用户的限制,并设置了全局 IP 地址作为 TCP 监听器的目标位置。 #### 高并发下的消息顺序性保障 尽管 RabbitMQ 提供了出色的性能表现,但在某些特定情况下可能会遇到消息乱序的问题。针对这一挑战,可通过以下几个方面加以改善: - **队列设计优化**: 创建多个独立队列分别对应不同的业务逻辑分支,从而减少竞争条件的发生概率。 - **消费者线程管理**: 控制单个消费者的并发数量,避免因过度争抢资源而导致数据错位现象。 - **持久化策略调整**: 对于关键事务型消息实施强制写盘措施,即使发生崩溃也能恢复原始状态[^3]。 #### 关键问题及其应对方法 以下是关于 RabbitMQ 中几个典型难题的具体解答思路: ##### 如何防止消息丢失? 在整个生命周期里(即从创建到最终被接收),采取以下手段可有效降低风险: - 生产者发送确认机制:等待 broker 明确告知已成功接收到某条记录后再继续下一步动作; - 存储环节可靠性增强:激活镜像队列或者 HAProxy 等冗余保护设施; - 客户端签收反馈:只有当目标程序真正完成了对该项任务的操作之后才向源端汇报已完成情况[^4]。 ##### 处理重复提交的情况 由于网络波动等原因可能导致同一份资料多次抵达目的地。为此建议引入唯一标识符字段用于辨别是否存在冲突实例;同时建立幂等接口使得即便再次触发相同请求也不会造成额外影响。 ##### 维护良好的次序关系 参见前文提到的方法论部分——通过精细化分割工作流单元以及严格限定各节点间的交互模式达成预期效果。 ##### 应对积压状况 当负载过高致使未处理项目累积过多时,应当考虑扩展集群规模、增加订阅方数目等方式缓解压力水平。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

ITdada

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值