• 大规模分布式消息中间件考虑点


    当前各种 RPC 中间件技术已经广泛应用于各个领域。其中,服务器之间消息通讯这种功能广泛应用于这些中间件中,于是,将这种面向消息的中间件( Message Oriented Middleware , MOM )抽象出来,形成通用的消息中间件,成为业内主流。目前消息中间件的标准主要有: JMS 和 AMQP 。实现则是百花齐放。

    消息中间件从功能上需要解决以下问题:

    1. 同步或异步的消息传输,尤其是异步的消息传输

    同步发送消息是发送消息后,阻塞等待消息是否发送成功的回馈,如果设置有超时时间,则超时后跳出阻塞状态。

    异步发送消息是发送消息后,不阻塞立即执行其他操作。如果关心消息是否发送成功,则可以通过回调函数(Java 中的 Listener )处理消息是否成功。

    2. 消息的安全性,消息中间件对持久的支持

    在分布式系统中,消息从发送到接收,环节非常多,没有任何一个环节是安全的,而任何环节出了问题,都会导致丢消息。当有需求是,我们必须保证在不是绝对安全的多环节里,完成消息安全的传输。这其中,消息中间的持久是非常重要的。

    3. 消息的重发性

    如果使用的系统保证了幂等性,则对此没有要求。否则,有些场景需要保证消息不重发。在既要保证消息安全,又要保证消息不重发,是非常困难的。目前业内还没有人能解决此问题。

    目前,在有消息重发的情况下,使用的系统都是使用状态机保证了系统对消息的幂等性。

    4. 消息的顺序性

    如果使用的系统有要求,则有可能需要保证消息的顺序。在大规模分布式不可靠环境下,在保证消息传输高效和消息安全的情况下,要解决此问题,也是非常困难的。

    如果只是小规模的系统,对性能要求不高,可以以服务器时间为准,使用排队队列即可解决。

    如果以发送端时间为准,并且保持顺序的消息由此一个发送端发送,则使用消息序号即可解决。

    另外,有些系统只需要满足局部的消息顺序性,在排序消息数量不大的情况下,可以使用多条排序消息一次性发送解决。

    5. 消息传输模型:点对点的传输消息( PTP ),订阅 / 发布模型( Pub/Sub 

    PTP ,就是你在消息方设置消息接收者的唯一标识符,然后,消息发送方和消息接受方建立一一对应的关系。消息发送方发送所有的消息都被消息接收方接收。

    Pub/Sub ,就是消息发送方和消息接收方都确定自己的发送和接收消息的标签(或者你可以理解为组 GroupID),所有有这个标签的消息,订阅了这个标签的消息接收方一定能接收到。

    JMS ( Java 消息服务, Java Message Service )是专用于 J2EE 的一种消息中间件规范。它主要做了接口上的规范,消息传输模型和消息类型的规范,并没有给予实现。同样,它也完全没有给出服务器端的架构,你甚至可以不使用服务器直接在客户端之间传输消息(虽然可能最终结果只是一个玩具)。http://java.sun.com/products/jms/docs.html 。 JMS 也没有规定消息的顺序,安全,重发等特性。

    AMQP (高级消息队列协议, The Advanced Message Queuing Protocol )是一种和语言无关的,在金融行业使用的新兴消息中间件,目前成为消息中间件圈内关注的焦点。与 JMS 规范了 API 不同,它是一个异步消息传递所使用的应用层协议规范。 AMQP 的原始用途只是为金融界提供一个可以彼此协作的消息协议,而现在的目标则是为通用消息队列架构提供通用构建工具。 http://www.amqp.org/

  • 相关阅读:
    [转]Apache与Tomcat的关系
    [转]学习object-c,补习一下指针
    [转]深度解析苹果成功的六大原因——公众类产品学习的榜样
    datetimepicker日期时间选择器
    缓缓回到顶部效果的实现
    bootstrap4实现点击标签展示对应的内容
    禁止页面内容滚动( 禁用 ctrl
    UI中的暗黑模式
    如何通过空状态留住用户
    交互设计常用原则和定律
  • 原文地址:https://www.cnblogs.com/E-star/p/4306106.html
Copyright © 2020-2023  润新知