为什么要使用消息中间件？
解决系统间耦合调用的问题-解耦
异步模型-异步
抵御洪峰流量，达到保护主业务的目的-削峰
要做到系统解耦，当新的模块接入进来时，可以做到代码改动最小：能够解耦
设置流量缓冲池，可以让后端系统按照自身吞吐能力进行消费，不被冲垮：能够削峰
强弱依赖梳理能够将非关键调用链的操作异步化并提升整体系统的吞吐能力：能够异步。
端口：61616
bin/activemq start 后台启动
bin/activemq restart 重启
bin/activemq stop 停止
查看进程
ps -ef|grep activemq
不显示grep
ps -ef|grep activemq | grep -v grep
根据端口查看
netstat -anp|grep 61616
或者
lsof -i:61616
带运行日志的启动方式
bin/activemq start > /output/activemq.log
通过浏览器访问
http://127.0.0.1:8161/admin/
用户名密码 admin / admin
JMS 规范和落地产品
分布式事务解决方案
刚性事务
全局事务（标准的分布式事务）
柔性事务
可靠消息最终一致（异步确保型）
TCC（两阶段提交、补偿型）
最大努力通知（非可靠消息、定期校对）
柔性事务解决方案：可靠消息最终一致性（异步确保型）
实现：业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。
业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送。
消息：业务处理服务在业务事务回滚后，向实时消息服务取消发送。
消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，
业务处理服务根据消息ID或消息内容确定该消息是否有效。
约束：被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作。
成本：可靠消息系统建设成本；一次消息发送需要两次请求，业务处理服务需要实现消息状态回查接口。
优点、适用范围
消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合。
对最终一致性时间敏感度较高，降低业务被动方实现成本。
用到的服务模式：可查询操作、幂等操作。
方案特点：
兼容所有实现JMS标准的MQ中间件
确保业务数据可靠的前提下，实现业务数据的最终一致性（理想状态下基本准实时一致）。
行业应用案例：
支付宝、eBay、去哪儿……
