谈谈我项目中用到的RabbitMQ/RocketMQ

前两天看了看一下消息队列——RabbitMQ，从配置到使用，说说消息队列MQ的工作机制.

　　用户再指定队列内发送消息，消息会被发送到消息队列服务器（如果是本地，则为127.0.0.1）的交换机上，缓存到broker上，交换机会根据指定的路由的key来匹配所要消费的队列 而消费监听器在不断拉取或者消息路由器推送要消费的消息，如果消息消费完成，确认消息，进而broker上再删除该消息；如果抛异常了，重试消费，到达设定的阈值之后还未消费成功，则进入了死信队列，因此在监听消费者队列中，大都需要创建一个死信队列，用来对消费失败或者队列不存在的消息进行重新路由消费（在1000并发下[jmeter]消费速度明显比rocketmq慢【可能跟硬件有关】）。

RocketMQ是用java语言开发的一款消息队列，之前金融的项目中用到了这款消息队列。流程大致是先发送消息，然后记录该消息的状态，如果消息没有消费，重新发送至消费方让其消费，消费完成之后再确认消息。其实原理大致都一样，如果用户选择的是Topic（也就是订阅/发布），broker会匹配当前订阅的topic[主题]（消息队列的组，比如订单topic，支付topic 等都分开路由）以及指定的队列匹配规则(rabbitmq为 queue.# [表示发送到该队列下的所有key都在这个队列下消费]、RocketMQ为shardingKey[会先根据topic分组，然后再根据tag【子标签】进行分类，比如充值，下单都订阅的支付的topic，但其tag可为recharge_tag,invest_tag，最后用shardingkey来对消息进行排序路由，天然支持顺序消费，金融类用的较多]），在使用rocketmq，发送消息之前需要对消息防重复crc32校验并序列化到硬盘（mysql/redis/等等***/），防止重复发送同一消息导致失去了幂等性，再消费完成消息之后再进行确认消息（rocketmq丢失消息率几乎为0，消息堆积能力非常高，可在配置文件中配置多个属性）。