比如某系统有三个子系统，登录系统、积分系统群、日志系统群。
一个用户登录了系统，将发送通知给积分系统集群和日志系统集群，要求积分系统集群和日志系统集群都能接收到完整的登录实现通知，类似于主题模式，同时在其中任一个系统群中不能让一个消息被集群中的多个系统重复处理，这类似于队列模式。
实际业务场景特点:
子业务系统都有集群的可能性
同一个消息会广播给关注该类消息的所有子业务系统
同一类消息在集群中被负载消费
业务的发生和消息的发布最终一致性
需要解决的问题:
不同业务系统分别处理同一消息，同一业务系统负载处理同类消息
解决消息发送时的一致性问题
解决消息处理时的幂等性问题
基于消息机制建立事件总线
问题:不同业务系统分别处理同一消息，同一业务系统负载处理同类消息
使用ActiveMQ的虚拟主题解决方案
发布者:
将消息发布到一个主题中，主题名以VirtualTopic开头，如VirtualTopic.TEST
消费者:
从队列中获取信息，在队列名中表明自己身份，如Consumer.A.VirtualTopic.TEST，通过这种方式把主题中的消息自动中转到队列中，由队列负载处理
此流程类似于下图:
问题:解决消息发送时的一致性问题
使用内存日志的解决方案
内存日志可持久化到本地文件，同时支持集群复制，若当前业务子系统挂掉也能保证消息不丢失
问题:解决消息处理时的幂等性问题
所谓幂等，简单地说，就是对接口的多次调用所产生的结果和调用一次是一致的。扩展一下，这里的接口，可以理解为对外发布的HTTP接口或者Thrift接口，也可以是接收消息的内部接口，甚至是一个内部方法或操作。
那么我们为什么需要接口具有幂等性呢？设想一下以下情形：
在App中下订单的时候，点击确认之后，没反应，就又点击了几次。在这种情况下，如果无法保证该接口的幂等性，那么将会出现重复下单问题。在接收消息的时候，消息推送重复。如果处理消息的接口无法保证幂等，那么重复消费消息产生的影响可能会非常大。使用内存日志的解决方案
消费者在接收消息后，去内存日志中查询该消息是否被处理过，若没有，则调用业务进行处理，处理成功后更新内存日志，确认消息。
问题:基于消息机制建立事件总线
系统之间的消息发布类似于事件，发送者就是事件的发起人，消费者就是事件的影响人，这样的架构方式称为事件驱动。
什么是事件驱动架构?
事件驱动架构(EDA)定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。简单来说一句话"有事我叫你，没事别烦我"
事件驱动架构模型
首先有三个业务系统，使用一个事件总线简化业务系统之间的事件发布，业务系统B、C通过事件总线提供的方法进行事件注册，业务发起系统A使用事件总线提供的方法发起事件，这样事件总线就封装了消息的发送和接收以及内存日志的处理，但这样事件总线还不具备消息中间件的功能，所以事件总线还需定义一个抽象的消息提供者，再根据不同的消息中间件提供具体的消息提供者，比如"activemq等"
|
