activeMQ实践（五）--企业系统的最佳实践

之前我们都是基本的main方法和一个简单的图书插入功能，那么真正在企业开发时，activemq又处在什么位置？它最适合的场景又是什么呢？
一般来说，对于中间件实际业务场景有以下几点：
1.子业务系统都有集群的可能性
2.同一消息会广播给关注该类消息的所有子业务系统（比如积分系统和日志系统都会关注用户的登录）
3.同一类消息在集群中被负载消费
4.业务的发生和消息的发生的一致性
那么对于这些特点，需要解决的问题是：
1.不同业务系统分别处理同一个消息，同一个业务系统负载处理同类消息
2.解决消息发送的一致性问题
3.解决消息处理时的幂等性问题
4.基于消息机制建立事务总线

-那么我们首先看集群系统处理消息方案：
1.使用jms级联：

我们之前的图书管理系统的controller就属于A中转器，但这个方案有几个问题，每增加一个业务就需要重新增加中转器。
2.使用activeMQ的虚拟主题解决方案：

发布者将消息发送到主题中
从队列中获取消息，在队列中表明身份

-解决消息发布发送的一致性问题：
1.使用jms中XA系列接口保证一致性
引入分布式事务；要求业务操作必须支持XA协议
2.使用内存日志达到弱一致性的目的（即对时间无强烈要求）：

-解决消息处理时的幂等性问题（即多次请求只处理一次）
同样使用内存日志解决方案：

-引入一致性问题后，我们的代码变得非常复杂，而基于消息机制的事件总线就是一种好的处理方式。
首先了解什么事件驱动架构（EDA）的特点：有事我叫你，没事别烦我
根据我的理解：这个事件总线就是将我们之前spring结合图书管理系统的controller调用生产者和监听器调用的service分别挑出来组合在一块，再利用内存日志对事件弱一致性和幂等性进行处理。那么事件总线就和service和controller松耦合了，controller只管注册事件，有事件了事务总线就调用service解决。那么事务总线就可以统一解决问题2和问题3了。 这里理解的模模糊糊的，以后如果有相关实践了，再继续来完善吧。