MQ见解

MQ

　消息队列是系统级、模块级的通信。RPC是对象级、函数级通信。　

1） 什么是推模式，什么是拉模式

2） 有没有消息丢失情况，如何防止

3） MQ用来解决什么问题

4） 你们用的什么MQ，为什么要用这个，它的最大吞吐量是多少

AcitveMQ是作为一种消息存储和分发组件

　　ActiveMQ默认的使用的协议是openWire，端口号：61616 　　一条消息从producer端发出之后，一旦被broker正确保存，那么它将会被consumer消费，然后ACK，broker端才会删除；不过当消息过期或者存储设备溢出时，也会终结它

持久化 　　非持久化消息是存储在内存中的，持久化消息是存储在文件中的 ActiveMQ会将内存中的非持久化消息写入临时文件中，以腾出内存。虽然都保存到了文件里，但它和持久化消息的区别是，重启后持久化消息会从文件中恢复，非持久化的临时文件会直接删除 　　设置2G左右的持久化文件限制，大量生产持久化消息直到文件达到最大限制，此时生产者阻塞，但消费者可正常连接并消费消息，等消息消费掉一部分，文件删除又腾出空间之后，生产者又可继续发送消息，服务自动恢复正常。

　　设置2G左右的临时文件限制，大量生产非持久化消息并写入临时文件，在达到最大限制时，生产者阻塞，消费者可正常连接但不能消费消息，或者原本慢速消费的消费者，消费突然停止。整个系统可连接，但是无法提供服务，就这样挂了。

　　解决方案：尽量不要用非持久化消息，非要用的话，将临时文件限制尽可能的调大

死信队列 　　一条消息不能正常处理.重发给其他服务器处理依旧不能处理.重试6次(重试次数可配置)后MQ就把这条消息放到死信队列 optimizeACK(可优化的ACK 延迟确认”的语义(ACK时机))和 prefethSize(批量预获取(默认1000)) 　　optimizeACK时机 () optimizeACK优化了消息确认的性能 　　　　只有当session的ACK_MODE为AUTO_ACKNOWLEDGE时才会生效 client端在消费消息后暂且不发送ACK，而是把它缓存下来(pendingACK)，等到这些消息的条数达到一定阀值时，只需要通过一个ACK指令把它们全部确认；这比对每条消息都逐个确认，在性能上要提高很多 　　　　optimizeACK有效时，如果客户端已经消费但尚未确认的消息(deliveredMessage)达到prefetch * 0.65，consumer端将会自动进行ACK；同时如果离上一次ACK的时间间隔，已经超过"optimizeAcknowledgeTimout"毫秒，也会导致自动进行ACK。 　　　　prefetchACK为true，那么prefetch必须大于0；当prefetchACK为false时，你可以指定prefethSize为0以及任意大小的正数 prefethSize(默认1000) prefethSize优化了消息传送的性能 　　批量获取消息，并“延迟”确认(ACK)。prefethSize表达了“批量获取”消息的语义，broker端主动的批量push多条消息给client端，总比client多次发送PULL指令然后broker返回一条消息的方式要优秀很多，它不仅减少了client端在获取消息时阻塞的次数和阻塞的时间，还能够大大的减少网络开支 　　prefethSize=0时，表示consumer将使用PULL(拉取)的方式从broker端获取消息，broker端将不会主动push消息给client端，直到client端发送PullCommand时 　　当prefethSize=>0时，表示consumer将接受broker端PUSh(推送)的方式获取消息，此后只要当client端消费且ACK了一定的消息之后，会立即push给client端多条消息

consumer获取消息的方式 　　使用receive()方法同步获取消息 　　　　prefethSize可以为0和任意正值；当prefethSize=0时，那么receive()方法将会首先发送一个PULL指令并阻塞，直到broker端返回消息为止，这也意味着消息只能逐个获取(类似于Request<->Response)，这也是Activemq中PULL消息模式；当prefethSize > 0时，broker端将会批量push给client 一定数量的消息(<= prefethSize),client端会把这些消息(unconsumedMessage)放入到本地的队列中，只要此队列有消息，那么receive方法将会立即返回，当一定量的消息ACK之后，broker端会继续批量push消息给client端

使用MessageListener异步获取消息 　　这就需要开发设定的prefethSize值必须 >=1,即至少为1；在异步消费消息模式中，设定prefethSize=0,是相悖的，也将获得一个Exception 　　消息的确认是在onMessage方法返回之后，如果onMessage方法异常，会导致消息不能被ACK，会触发重发

consumer的消费能力 　　如果consumer端消费速度很慢(对消息的处理是耗时的) 过大的prefetchSize，并不能有效的提升性能，反而不利于consumer端的负载均衡(只针对queue),使用较小的prefetchSize，同时关闭optimizeACK，可以让消息在多个consumer间“负载均衡” 　　如果较大的prefetchSize，将会导致broker一次性push给client大量的消息，但是这些消息需要很久才能ACK(消息积压)，而且在client故障时，还会导致这些消息的重发 　　如果consumer端消费速度很快，但是producer端生成消息的速率较慢 .开启optimizeACK，但是需要设置较小的prefetchSize；这样可以保证每个consumer都能有"活干"，否则将会出现一个consumer非常忙碌，但是其他consumer几乎收不到消息。 　　如果消息很重要，那么我们需要将optimizeACK=false，prefetchSize=1 　　总之消费端要对重复消息做幂等控制,在消息被消费之后还没有来得及确认时，client端发生故障，那么这些消息就有可能会被重新发送给其他consumer ACK模式 JMS API中约定了Client端可以使用四种ACK_MODE,在javax.jms.Session接口中: AUTO_ACKNOWLEDGE = 1 自动确认 CLIENT_ACKNOWLEDGE = 2 客户端手动确认  DUPS_OK_ACKNOWLEDGE = 3 自动批量确认 SESSION_TRANSACTED = 0 事务提交并确认 INDIVIDUAL_ACKNOWLEDGE = 4 单条消息确认(AcitveMQ补充了一个自定义的ACK_MODE)

ActiveMQ中定义了如下几种ACK_TYPE(参看MessageAck类):

• DELIVERED_ACK_TYPE = 0    消息"已接收"，但尚未处理结束
• STANDARD_ACK_TYPE = 2    "标准"类型,通常表示为消息"处理成功"，broker端可以删除消息了
• POSION_ACK_TYPE = 1    消息"错误",通常表示"抛弃"此消息，比如消息重发多次后，都无法正确处理时，消息将会被删除或者DLQ(死信队列)
• REDELIVERED_ACK_TYPE = 3    消息需"重发"，比如consumer处理消息时抛出了异常，broker稍后会重新发送此消息
• INDIVIDUAL_ACK_TYPE = 4    表示只确认"单条消息",无论在任何ACK_MODE下    
• UNMATCHED_ACK_TYPE = 5    在Topic中，如果一条消息在转发给“订阅者”时，发现此消息不符合Selector过滤条件，那么此消息将 不会转发给订阅者，消息将会被存储引擎删除(相当于在Broker上确认了消息)