持久化存储是发送者发送消息后，消息中心首先将消息存储到本地文件/DB（activemq_msgs（存储消息），activemq_acks（订阅关系）和activemq_lock（集群环境下用）），然后试图将消息发送给接收者，发送成功则将消息从存储中删除，失败则继续尝试，消息中心启动后首先检查指定的存储位置，如果有未发送成功的消息，就把他发出去
事务性会话中，一个事物被提交，确认自动发生，非事务性会话中，消息确认取决于配置的应答模式
auto_ack...从receive方法返回的时候或者从messagelistener.onMessage方法返回的时候，会话自动确认客户收到消息（业务是否完成等问题，保证至多一次）
client_ack...客户端通过acknowledge方法确认消息，这个确认是在会话层面（业务完成后手动确认，至少一次）
在非持久化存储时，消息在内存中，重启失效，持久化可以配置消
息持久化到DB硬盘之类的，保证重启不失效
非持久化存储在超出最大内存使用配置之后，会临时部分置换到磁盘，满了可能会阻塞消费者出问题，原因不详，但是重启依然失效，尽量用持久化消息
消息一直不消费生产者阻塞
activemq用心跳包判断客户端是否在线，阻塞造成超时导致socket关闭无法都缓存
开启事物，commit会等待服务器返回，不会关闭连接导致消息丢失
非持久化是异步发送，持久化是同步到硬盘，但开启事物都是同步发送的，建议持久化时无比开启事务
activemq有prefetch机制，相当于一次一批，所以可能你分配了好多台客户端，只有一个在工作，可以将prefetch设置为1，避免分配不均
自动确认（这种情况下还有listener一类的在确认之前可以稍加处理）和ack代码确认
队列P2P时，一个消息只能被一个消费者消费
Pub/Sub时，一个消息会重复被多个订阅集群同时消费
业务需要实现一个消息按照Queue模式被集群消费，在集群内以订阅方式消费，需要自行开发或者多层
客户端丢失：producer发送消息到消息队列，客户端接受消息进行处理，在处理过程中，客户端挂了，此时正在处理的消息和已经分配到该客户端的未处理消息将面临丢失。
---消息确认，当客户端消息处理完毕后会给消息服务器发送确认消息，此时消息服务器可以删除此消息，如果连接断开或者客户端主动关闭channel前没有收到确认，则认为客户端挂了，这一批消息将重新发送给其他在线消费客户端执行
未知delivery tag错误，由自动ack引起，关闭即可
---消息系统可配置持久化消息到硬盘，消费者可配置在消费确认之前不接收新消息，关闭自动确认，并在finally中发送确认消息给消息服务器，以防止消息永久保留，越积越多造成内存泄漏
业务系统==》发送消息到消息系统==》存储消息为待处理状态==》返回给业务系统结果==》业务系统开始业务流程，将结果告知消息系统==》消息变为待投递
中间如果出现问题，消息为待处理状态，消息系统可以反向询问业务处理结果，由此更新消息状态。
消息可以设计为跟业务系统同数据库，将业务DB操作和消息操作作为一个本地事物保证一致性
消息存储可以设计消息表和投递表（可以安排投递某个订阅集群的消息），也可以放在一起（只能按照消息进行投递）效率相对低
