MQ相关
关键特征：
1、可靠性（一般通过消息持久化实现，可持久化到磁盘、数据库等，没有持久化的可靠性如何保证）
2、优先级（0-9，这个是JMS的规范）
3、节点间组网（分布式特性，实现消息跨节点路由）
4、消息模型（PTP || Pub/Sub，这个是JMS的规范）
性能指标：
4、高吞吐量
5、低延迟
1、AMQ是完全遵循JMS1.1规范的；有多种协议支持：openwire（nio）、stomp、mqtt、amqp
2、Moquette不遵循JMS1.1规范，实现了MQTT协议，能做到高吞吐量和低延迟==>注意：moquette是基于Netty实现的，其是一个客户端/服务器端模式，因此其不支持节点间组网。
3、Kafka
>>>MQ性能指标测试http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
>>>影响性能的因素有以下：
1.the network topology
2.transport protocols used
3.quality of service
4.hardware, network, JVM and operating system
5.number of producers, number of consumers
6.distribution of messages across destinations along with message size
1、使用的网络拓扑和技术（网络环境：卫星、专网、广域网、个域网）；
2、使用的传输协议：opwenwire、stomp、amqp、mqtt；
3、服务质量（处理消息的超时时间、使用topic还是queue、消息是否持久化<某些场景允许消息可丢>）；
4、硬件、网络（网卡百兆还是千兆），JVM和操作系统；
5、生产者数量、消费者数量；
6、要分发到目标的消息大小；
提示：对于1-2K的消息，单个topic，1个生产者和1个消费者，21000--22000/sec
>>>不能单说某个MQ性能最快，而要聚焦到具体的应用场景，而且每个MQ不同版本也有区别，
建议用较新版本的。
>>>为什么影响MQ性能的因素和消费者的数量有关系？==>
例如：对于队列的预取值，如果队列只有一个消费者时，预取值可以稍大些，但是当队列有多个消费者时，预取值尽量小点，设置为1最好。
因为：有多个消费者时，慢的消费者会在它所在的客户端累积消息，而其他快的消费者又消费不了这些消息，导致MQ整体的吞吐量下降。
/////////////////////begin////////////
To evaluate the performance of a broker correctly you should ask yourself the following questions:
1.Do I need a broker for financial transactions or online games?
2.What is more important for the use: guaranteed transactional service or speed and bandwidth?
3.How big may be the delay in delivery of messages?
4.What size are the messages to be transmitted?
5.How many queues are needed?
6.How many clients simultaneously access the broker?
为了正确评估Broker的性能，你应该问下你自己以下几个问题：
1.你所用的Broker是用于金融交易还是在线游戏？==>MQ用在什么地方？
2.使用中更看重哪项指标：保证交易服务还是速度和带宽？==>关心什么指标
3.消息分发需要有多大的延迟？==>服务质量
4.要传输的消息大小是多少？==>消息大小
5.需要多少个队列？==>队列个数
6.有多少个客户端同时访问Broker？==>并发客户端个数
/////////////////////end//////////////
///////begin/////////
Practical experience:
Usually not the brokers is the bottleneck, but message consumer that are slowed down by slow backend systems or database queries.
实际经验告诉我们：
通常，Broker不是瓶颈，而消息的消费者成为了瓶颈，由于后端系统或者数据库查询导致消费者慢下来。
///////end////////////
>>>JMeter测试方式
>>JMeter实测及调优：
性能和环境因素的关系：如：网络状况、磁盘IO等有较大关系
LevelDB没有像官网上说的那样，比KahaDB性能高（使用LevelDB同样的配置，对带宽的利用率没有KahaDB高）
>> 环境：
>> 调优要点：
1、传输通道采用nio模式，即：nio://0.0.0.0:61617，客户端采用failover方式，如：failover:(tcp://10.88.112.165:61617)
2、队列分发策略调优参数：
2.1：optimizedDispatch="true"
2.2：lazyDispatch="false"
2.3：producerFlowControl="true"
2.4：<fileQueueCursor/>
2.5：useCache="true"
2.6：queuePrefetch="1" or queuePrefetch="0"
2.7：memoryLimit="128MB"
3、JVM参数：
-Xms1024M -Xmx1024M -Xmn256M -Xss228K -Dcom.rf.emq.UseDedicatedTaskRunner=false -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError
4、OS：
4.1：ulimit -n 65535
4.2：采用磁盘的异步写IO，要求MQserver实现真正的异步IO调用才可以。（JDK1.7已经支持异步IO，即NIO2.0）
>> 监控方法：
1、查看tcp连接数及是否稳定：
1.1、netstat -an|grep '61617' |grep 'ESTABLISHED' |wc -l
1.2、netstat -an|grep '61617' |grep 'CLOSE_WAIT' |wc -l
2、查看文件句柄数：
lsof -p <pid> |wc -l
3、查看MQ server资源使用情况：memory、cpu
top -p <pid>
>>结论：
1、在该环境下，消息大小为1KB时，最大吞吐量为4250个/sec，最大并发在3000个连接数（客户端）。
2、每个连接会对应三个线程：
2.1:EMQ Connection Dispatcher: tcp://10.88.112.165:42079
2.2:Timer-*
2.3:EMQ NIO Worker *
3、在并发500客户端时达到最大吞吐量，JVM线程保持在1500以下， JVM线程数大概为并发连接数的3倍左右。
注意：并发500时线程数为1426个，并发520个时，达到1470个线程，并发480时，达到1384个线程；
4、在500个客户端并发连接（JVM线程达快达到1500时），对网络带宽的利用率基本保持在95%以上，偶尔100%。
Tip：通过Apollo测试磁盘IO效率，如下：
>>windows环境调整：
1、线程模型
2、TCP MTU：
1、可靠性（一般通过消息持久化实现，可持久化到磁盘、数据库等，没有持久化的可靠性如何保证）
2、优先级（0-9，这个是JMS的规范）
3、节点间组网（分布式特性，实现消息跨节点路由）
4、消息模型（PTP || Pub/Sub，这个是JMS的规范）
性能指标：
4、高吞吐量
5、低延迟
1、AMQ是完全遵循JMS1.1规范的；有多种协议支持：openwire（nio）、stomp、mqtt、amqp
2、Moquette不遵循JMS1.1规范，实现了MQTT协议，能做到高吞吐量和低延迟==>注意：moquette是基于Netty实现的，其是一个客户端/服务器端模式，因此其不支持节点间组网。
3、Kafka
>>>MQ性能指标测试http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
>>>影响性能的因素有以下：
1.the network topology
2.transport protocols used
3.quality of service
4.hardware, network, JVM and operating system
5.number of producers, number of consumers
6.distribution of messages across destinations along with message size
1、使用的网络拓扑和技术（网络环境：卫星、专网、广域网、个域网）；
2、使用的传输协议：opwenwire、stomp、amqp、mqtt；
3、服务质量（处理消息的超时时间、使用topic还是queue、消息是否持久化<某些场景允许消息可丢>）；
4、硬件、网络（网卡百兆还是千兆），JVM和操作系统；
5、生产者数量、消费者数量；
6、要分发到目标的消息大小；
提示：对于1-2K的消息，单个topic，1个生产者和1个消费者，21000--22000/sec
>>>不能单说某个MQ性能最快，而要聚焦到具体的应用场景，而且每个MQ不同版本也有区别，
建议用较新版本的。
>>>为什么影响MQ性能的因素和消费者的数量有关系？==>
例如：对于队列的预取值，如果队列只有一个消费者时，预取值可以稍大些，但是当队列有多个消费者时，预取值尽量小点，设置为1最好。
因为：有多个消费者时，慢的消费者会在它所在的客户端累积消息，而其他快的消费者又消费不了这些消息，导致MQ整体的吞吐量下降。
/////////////////////begin////////////
To evaluate the performance of a broker correctly you should ask yourself the following questions:
1.Do I need a broker for financial transactions or online games?
2.What is more important for the use: guaranteed transactional service or speed and bandwidth?
3.How big may be the delay in delivery of messages?
4.What size are the messages to be transmitted?
5.How many queues are needed?
6.How many clients simultaneously access the broker?
为了正确评估Broker的性能，你应该问下你自己以下几个问题：
1.你所用的Broker是用于金融交易还是在线游戏？==>MQ用在什么地方？
2.使用中更看重哪项指标：保证交易服务还是速度和带宽？==>关心什么指标
3.消息分发需要有多大的延迟？==>服务质量
4.要传输的消息大小是多少？==>消息大小
5.需要多少个队列？==>队列个数
6.有多少个客户端同时访问Broker？==>并发客户端个数
/////////////////////end//////////////
///////begin/////////
Practical experience:
Usually not the brokers is the bottleneck, but message consumer that are slowed down by slow backend systems or database queries.
实际经验告诉我们：
通常，Broker不是瓶颈，而消息的消费者成为了瓶颈，由于后端系统或者数据库查询导致消费者慢下来。
///////end////////////
>>>JMeter测试方式
>>JMeter实测及调优：
性能和环境因素的关系：如：网络状况、磁盘IO等有较大关系
LevelDB没有像官网上说的那样，比KahaDB性能高（使用LevelDB同样的配置，对带宽的利用率没有KahaDB高）
>> 环境：
>> 调优要点：
1、传输通道采用nio模式，即：nio://0.0.0.0:61617，客户端采用failover方式，如：failover:(tcp://10.88.112.165:61617)
2、队列分发策略调优参数：
2.1：optimizedDispatch="true"
2.2：lazyDispatch="false"
2.3：producerFlowControl="true"
2.4：<fileQueueCursor/>
2.5：useCache="true"
2.6：queuePrefetch="1" or queuePrefetch="0"
2.7：memoryLimit="128MB"
3、JVM参数：
-Xms1024M -Xmx1024M -Xmn256M -Xss228K -Dcom.rf.emq.UseDedicatedTaskRunner=false -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError
4、OS：
4.1：ulimit -n 65535
4.2：采用磁盘的异步写IO，要求MQserver实现真正的异步IO调用才可以。（JDK1.7已经支持异步IO，即NIO2.0）
>> 监控方法：
1、查看tcp连接数及是否稳定：
1.1、netstat -an|grep '61617' |grep 'ESTABLISHED' |wc -l
1.2、netstat -an|grep '61617' |grep 'CLOSE_WAIT' |wc -l
2、查看文件句柄数：
lsof -p <pid> |wc -l
3、查看MQ server资源使用情况：memory、cpu
top -p <pid>
>>结论：
1、在该环境下，消息大小为1KB时，最大吞吐量为4250个/sec，最大并发在3000个连接数（客户端）。
2、每个连接会对应三个线程：
2.1:EMQ Connection Dispatcher: tcp://10.88.112.165:42079
2.2:Timer-*
2.3:EMQ NIO Worker *
3、在并发500客户端时达到最大吞吐量，JVM线程保持在1500以下， JVM线程数大概为并发连接数的3倍左右。
注意：并发500时线程数为1426个，并发520个时，达到1470个线程，并发480时，达到1384个线程；
4、在500个客户端并发连接（JVM线程达快达到1500时），对网络带宽的利用率基本保持在95%以上，偶尔100%。
Tip：通过Apollo测试磁盘IO效率，如下：
>>windows环境调整：
1、线程模型
2、TCP MTU：