配置：
1. brokerURL
failover:(tcp://xxx.xxx.xxx.1:61616?tcpNoDelay=true,tcp://xxx.xxx.xxx.2:61616?tcpNoDelay=true,tcp://xxx.xxx.xxx.3:61616?tcpNoDelay=true)?timeout=10000&randomize=false
主从模式必须加上randomize=false。
发送：
1. 重要消息采用默认的同步发送useAsyncSend=true；
2. 加上线程池；
3. 批量发送加上事务。
同步发送采用线程池和事务批量发送的话，本机测试(levelDB持久化) 10W消息12秒发送完比，约8000/S。
接收：
1. 加上线程池；
2. 重要消息加上事务，保证一个consumer抛Exception后消息能转发到其它consumer；
3. 不能容忍重复的消息一定要加上去重处理，当consumer没有ACK之前停机一定会发生重复消息且redeliveryCounter=0(这里不知是否没配置对)。可运行activeMQ自己的测试类RedeliveryPolicyTest.java中的testRepeatedRedelivery*方法，在“connection.close()”之前停止运行。
消息确认：
1. optimizeAcknowledge：每批次消息消费65%后发送确认，假如某个queue的destination为"queue.test.msg?consumer.prefetchSize=10"，客户端在处理完第7条消息时会发送第1~7条消息的ACK。也就是说某个consumer在处理完这10条后停机，后面的3条消息会得不到确认，再开启一个consumer会重新收到这3条且redeliveryCounter=0。
2. optimizeAcknowledgeTimeOut：系统时间 - 前条消息处理时间 > optimizeAcknowledgeTimeOut即发送ACK，如果条件不成立则按optimizeAcknowledge处理。
3. optimizedAckScheduledAckInterval：每隔optimizedAckScheduledAckInterval就发送ACK，如果条件不成立则按optimizeAcknowledge处理。