转自 http://blog.csdn.net/kongqz/article/details/8912000
1、我们为什么需要可靠消息？或者希望消息带有事务？
（1）、我们的某些业务场景希望消息的发送消息和数据库操作是绑定到一起的-》-需要事务性消息
（2）、我们某些业务场景不希望对外的消息发送丢失，导致业务无法继续--》消息要可靠
2、消息可靠了，我们会损失什么？
（1）、消息的顺序性
因为有些消息可能因为网络等原因当时发送不出去，后续的消息先发送出去被消费。后续的网络
（2）、消息的实时性
有些消息
（3）、业务必须幂等--》额外的重复接收消息处理的工作量
3、一个activemq消息服务器会出现哪些问题？
（1）、消息丢失
没发送到broker上就一定丢失了，在broker上消息丢失，从broker到订阅者过程中丢失
（2）、并发量大的时候承接不了，服务器假死
单个mq服务器在并发量大的时候会出现网络io等，cpu爆满的瓶颈。
（3）、集群的failover失败
有些消息体很大的时候。当主服务器假死的时候，从服务器是不知道的。所以无法进行failover。
4、如何解决较大的并发量？
（1）、创建多组集群，在多组集群上创建相同的队列。集群采用failover的方式做ha
（2）、封装生产者客户端，将消息轮询发送到多组集群的队列上。
（3）、封装订阅者客户端，监控多组集群的相同队列，将消息消费。
5、如何解决这些问题
（1）、没发送到broker上就丢失了：在发送broker之前，将消息本地化存储。收到发送成功的反馈后移除本地文件。实时检索本地文件，发现超过一定时间没有发送直接重新发送。
（2）、在broker上丢失：将broker的持久化改成数据库，将数据库做主从处理
（3）、从broker到订阅者丢失：在没有收到订阅者成功接收的时候，不移除broker的持久化数据，其实这个貌似有事务支持
（4）、集群的failover失败：建立一个测试队列，定时发送消息测试每个节点是否服务正常。只能通过之类心跳类监控手段来确认服务器是否正常。
6、现阶段市场上有哪些解决方案
阿里的notify策略比较类似。metaq更加侧重的是订阅端的数据pull