全部产品
云市场

消息队列最佳实践

更新时间:2019-09-20 20:47:29

命名规则

快速开始 中涉及了四个核心概念,包括:TOPIC,EVENTCODE,发布者 GROUP 和消费者 GROUP。其中 TOPIC 和 EVENTCODE 构成消息类型。这四个核心概念的命名规则约束如下所示:

  • TOPIC 命名规则:以“TP_”为前缀,大写字母组成,下划线分割,长度少于 32 个字符。
  • EVENTCODE 命名规则: 以“EC_”为前缀,大写字母组成,下划线分割,长度少于 64 个字符。
  • 发布者 GROUP 命名规则:以“P_”为前缀,大小写字母组成,长度少于 64 个字符,建议格式为 P\_appname\_service,其中 appname 是应用系统名称,service 是相关服务名称。
  • 消费者 GROUP 命名规则:以“S_”为前缀,大小写字母组成,长度少于 64 个字符,建议格式为 S\_appname\_service,其中 appname 是应用系统名称,service 是相关服务名称。

发送多个消息类型的发布者(Publisher)配置

一个应用系统可能发送多种消息类型,如果涉及多个 TOPIC,允许在一个 sofa:publisher 元素中配置多个 sofa:channel 元素,每个元素设置一个 TOPIC,而不是配置多个 sofa:publisher 实例。配置实例如下所示:

  1. <sofa:publisher id="mqPublisher" group="P_appname_service">
  2. <sofa:channels >
  3. <sofa:channel value="TP_DEFAULT_A"/>
  4. <sofa:channel value="TP_DEFAULT_B"/>
  5. </sofa:channels>
  6. <sofa:binding.msg_broker/>
  7. </sofa:publisher>

说明:一个应用系统推荐只配置一个 sofa:publisher 元素负责消息发布。

订阅多个消息类型的消费者(Consumer)配置

应用系统可能订阅多种消息类型,允许在一个 sofa:consumer 元素中配置多个 sofa:channel 元素,每个 sofa:channel 元素中配置多个 sofa:event 元素,而不是配置多个 sofa:consumer 实例。在这种场景下,订阅的全部消息由同一个 uniformEventMessageListener 实例负责消费,建议按照消息类型维度选择对应的消息处理逻辑。配置实例如下所示:

  1. <sofa:consumer id="mqConsumer" group="S_appname_service">
  2. <sofa:listener ref="mqMessageListener"/>
  3. <sofa:channels>
  4. <sofa:channel value="TP_DEFAULT_A">
  5. <sofa:event eventType="direct" eventCode="EC_DEFAULT_A" persistence="true"/>
  6. <sofa:event eventType="direct" eventCode="EC_DEFAULT_B" persistence="true"/>
  7. </sofa:channel>
  8. <sofa:channel value="TP_DEFAULT_B">
  9. <sofa:event eventType="direct" eventCode="EC_DEFAULT_C" persistence="false"/>
  10. </sofa:channel>
  11. </sofa:channels>
  12. <sofa:binding.msg_broker/>
  13. </sofa:consumer>
  14. <bean id="mqMessageListener" class="com.antcloud.tutorial.mq.endpoint.service.MqMessageListener"/>

说明:一个应用系统推荐只配置一个 sofa:consumer 元素负责订阅全部消息类型。

消息订阅持久型类型

消息订阅持久类型包括 持久型订阅非持久性订阅,具体区别如下:

  • 持久型订阅:当订阅端系统未连接到消息代理组件(Message Broker)时,消息代理组件负责保存消息,待订阅端系统连接后,完成投递。
  • 非持久型订阅:当订阅端系统未连接到消息代理组件(Message Broker)时,消息代理组件直接丢弃需要被投递的消息。此订阅类型一般应用于时效性较强的消息。