[转载] 分布式消息队列的设计和使用

转载自http://blog.csdn.net/tenfyguo/article/details/7453355

在系统架构设计中,我们有时会用到消息队列,但对对应为什么需要用到消息队列,消息队列的引入是否对架构设计有更多的好处方面,我们是否有足够的认识?

是否存在为了用消息队列而引入呢?所以这里我们需要非常明确我们的架构目标,一般来说,消息队列能够提供以下几个方面的帮助:

1,保证消息的传递;

如果发送消息时接收者不可用,消息队列会保留消息,直到成功地传递它;

2,提供异步的通信协议;

消息的发送者将消息发送到消息队列后可以立即返回,不用等待接收者的响应,消息会被保存在队列中,直到接收者取出它;

3,解耦;

只要消息格式不变,即使接收者的接口、位置、或者配置改变,也不会给发送者带来任何改变;
而且,消息发送者无需知道消息接收者是谁,使得系统设计更清晰;

相反的,例如,远程过程调用(RPC)或者服务间通过socket建立连接,如果对方接口改变了或者对方ip、端口改变了,那么另一方需要改写代码或者改写配置;

4,提供路由;

发送者无需与接收者建立连接,双方通过消息队列保证消息能够从发送者路由到接收者,甚至对于本来相互网络不通的两个服务,也可以提供消息路由。

细节方面的关注:

1,支持并发模式和顺序模式
   顺序模式:
   消息接收后,在消息接收者来主动删除这条消息之前,队列中的其他消息不可被接收。这样保证应用在一个任务完成后再处理下一个任务,提供了强顺序性
   
   并发模式:
   消息被接收后,消息接收者主动删除前,队列的下一个消息仍可被其他应用接收,且可以一直并发获取下一个没有被接收的消息。
   如果消息被接收后持久(该时间可配)不被删除,则认为消息的原接收者处理失败,消息重新可见,
   可被其他应用再次接收(此特性为容错处理,“接收顺序队列消息”的功能也具备该特性)。
   
2,短暂锁模式:
   一个消息不会同时被多个服务接收,这是通过针对消息的短暂锁来保证的,消息的接收者可以指定消息被锁定的时间,
   如果接收者处理完消息需要主动将消息显示删除,如果接收者处理消息失败了,那么另一个服务可以在这个消息的锁失效后重新获得这个消息。

时间: 2024-10-16 00:37:10

[转载] 分布式消息队列的设计和使用的相关文章

[转载] 基于Redis实现分布式消息队列

转载自http://www.linuxidc.com/Linux/2015-05/117661.htm 1.为什么需要消息队列?当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力. 再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送. 再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开.

Netty构建分布式消息队列(AvatarMQ)设计指南之架构篇

目前业界流行的分布式消息队列系统(或者可以叫做消息中间件)种类繁多,比如,基于Erlang的RabbitMQ.基于Java的ActiveMQ/Apache Kafka.基于C/C++的ZeroMQ等等,都能进行大批量的消息路由转发.它们的共同特点是,都有一个消息中转路由节点,按照消息队列里面的专业术语,这个角色应该是broker.整个消息系统通过这个broker节点,进行从消息生产者Producer到消费者Consumer的消息路由.当然了,生产者和消费者可以是多对多的关系.消息路由的时候,可以

[.NET领域驱动设计实战系列]专题八:DDD案例:网上书店分布式消息队列和分布式缓存的实现

一.引言 在上一专题中,商家发货和用户确认收货功能引入了消息队列来实现的,引入消息队列的好处可以保证消息的顺序处理,并且具有良好的可扩展性.但是上一专题消息队列是基于内存中队列对象来实现,这样实现有一个弊端,就是一旦服务重启或出现故障时,此时消息队列中的消息会丢失,并且也记录不了日志.所以就会出现,商家发货成功后,用户并没有收到邮件通知,并且也没有日志让我们发现是否发送了邮件通知.为了解决这个问题,就需要引入一种可恢复的消息队列.目前有很多开源的消息队列都支持可恢复的,例如TibcoEms.ne

EQueue - 一个纯C#写的分布式消息队列介绍2

一年前,当我第一次开发完EQueue后,写过一篇文章介绍了其整体架构,做这个框架的背景,以及架构中的所有基本概念.通过那篇文章,大家可以对EQueue有一个基本的了解.经过了1年多的完善,EQueue无论是功能上还是成熟性上都完善了不少.所以,希望再写一篇文章,介绍一下EQueue的整体架构和关键特性. EQueue架构 EQueue是一个分布式的.轻量级.高性能.具有一定可靠性,纯C#编写的消息队列,支持消费者集群消费模式. 主要包括三个部分:producer, broker, consume

C#分布式消息队列 EQueue 2.0 发布啦

前言 最近花了我几个月的业余时间,对EQueue做了一个重大的改造,消息持久化采用本地写文件的方式.到现在为止,总算完成了,所以第一时间写文章分享给大家这段时间我所积累的一些成果. EQueue开源地址:https://github.com/tangxuehua/equeue EQueue相关文档:http://www.cnblogs.com/netfocus/category/598000.html EQueue Nuget地址:http://www.nuget.org/packages/eq

Netty构建分布式消息队列实现原理浅析

在本人的上一篇博客文章:Netty构建分布式消息队列(AvatarMQ)设计指南之架构篇 中,重点向大家介绍了AvatarMQ主要构成模块以及目前存在的优缺点.最后以一个生产者.消费者传递消息的例子,具体演示了AvatarMQ所具备的基本消息路由功能.而本文的写作目的,是想从开发.设计的角度,简单的对如何使用Netty,构建分布式消息队列背后的技术细节.原理,进行一下简单的分析和说明. 首先,在一个企业级的架构应用中,究竟何时需引入消息队列呢?本人认为,最经常的情况,无非这几种:做业务解耦.事件

大型网站架构系列:分布式消息队列(二)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

EQueue - 一个C#写的开源分布式消息队列的总体介绍(转)

源: EQueue - 一个C#写的开源分布式消息队列的总体介绍 EQueue - 一个纯C#写的分布式消息队列介绍2 EQueue - 详细谈一下消息持久化以及消息堆积的设计

Kafka 和 ZooKeeper 的分布式消息队列分析

1. Kafka 总体架构 基于 Kafka-ZooKeeper 的分布式消息队列系统总体架构如下: 如上图所示,一个典型的 Kafka 体系架构包括若干 Producer(消息生产者),若干 broker(作为 Kafka 节点的服务器),若干 Consumer(Group),以及一个 ZooKeeper 集群.Kafka通过 ZooKeeper 管理集群配置.选举 Leader 以及在 consumer group 发生变化时进行 Rebalance(即消费者负载均衡,在下一课介绍).Pro