-
Notifications
You must be signed in to change notification settings - Fork 1
ActiveMQ In Action读书笔记(七)
订阅多个destination使用wildcard, 发送消息到多个destination使用composite destination. 通配符包括:
- 点号(.): 用于分隔destination名称中的元素
- 星号(*): 用于匹配单个元素
- 大于号(>): 用于匹配单个或所有后续元素
组合destination通过逗号(,)来表示, 组合destination可以混合queue和topic类型, 这是通过queue://
或topic://
前缀类区分的
通知消息是由于broker发生变化而由broker产生的消息. 这类消息为topic消息,对应的destination为ActiveMQ系统内部定义的,可查看org.apache.activemq.advisory.AdvisorySupport获取有哪些destination
有些通知消息默认是不打开的, 比如消息传递,慢速消费者, 快速生产者情况下, 这可以在<policyEntry>标签的属性(比如advisoryForSlowConsumers)上做修改.
通知消息destination说明如下:
ActiveMQ中,topic只有在持久订阅(durable subscription)下是持久化的。存在持久订阅时,每个持久订阅者,都相当于一个持久化的queue的客户端,它会收取所有消息。这种情况下存在两个问题:
- 同一应用内consumer端负载均衡的问题: 同一个应用上的一个持久订阅不能使用多个consumer来共同承担消息处理功能。因为每个都会获取所有消息。queue模式可以解决这个问题,broker端又不能将消息发送到多个应用端。所以,既要发布订阅,又要让消费者分组,这个功能jms规范本身是没有的。
- 同一应用内consumer端failover的问题:由于只能使用单个的持久订阅者,如果这个订阅者出错,则应用就无法处理消息了,系统的健壮性不高。
Virtual Topic使得producer发送消息到topic上, consumer以loadbalance的方式消费消息(类似于queue的方式): 如果没有问题的话消息将会被均分, 如果一个consumer出现问题,则消息会被另一个consumer消费
配置规范:
- prducer topic名称格式为
VirtualTopic.<topic name>
;consumer topic名称格式为Consumer.<consumer name>.VirtualTopic.<virtual topic name>
对于非持久化的topic消息, consumer只有在启动后才能消费消息, 否则会存在消息丢失的情况. 这可以通过消费者回溯功能来避免.
- 打开回溯开关: consumer创建topic时设置参数consumer.retroactive=true
- broker相应的destination中选择回溯策略
消息在broker过期后,就会被放入DLQ中,并在如下的情况发生时redelivery:
- client使用事务并明确调用了callback()
- client使用事务并在commit之前关闭
- client给session发送CLIENT_ACKNOWLEDGE但又再次session上调用了recover()方法