微服务消息中间件ActiveMQ，RabbitMQ,kafka等的技术选择

在微服务盛行的时代，系统的分布式，让我们广泛的运用消息中间件来进行系统间的数据交换，而且通过消息的方式，便于系统间异步解耦。我们在谈技术选型的时候，不能脱离业务空谈选型，每种消息中间件必定有其优点和不足，我们根据我们自身的场景择优选择，结合我自己使用的二种类型的MQ简单说说：首先说说RabbitMQ，这是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。是AMQP协议领先的一个实现，它实现了代理(Broker)架构，意味着消息在发送到客户端之前可以在中央节点上排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。但是在集群使用的时候，分区配置不当偶尔会有脑残现象出现，总的来说，在支付行业用Rabbitmq还是非常多的。

再说说Kafka,kafka（是LinkedIn于2010年12月开发并开源的一个分布式MQ系统，现在是Apache的一个孵化项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，其性能和效率在行业中是领先的，但是原先的版本中kafka经过大量测试，因为其主备Partition同步信息的机制问题，偶尔会造成数据丢失等问题，所以更多的场景还是在大数据，监控等领域。

目前我知道的一些支付公司，像易宝支付，智惠支付，合众支付，头条支付等都在使用RabbitMQ来做消息中间件，虽然很重但是却满足支付行业的不丢消息，同时MQ相对稳定等特点。缺点则是不像ActiveMQ那样可以使用JAVA自己定制化，比如我想知道消息队列中有多少剩余消息没有消费，都是哪些通道获取过消息，共有多少条，是否可以手动或者自动触发重试等等监控和统计信息，目前还做的不是太完善，只能满足基本功能的要求。

接下来我们再来说说消息队列在技术领域的使用场景

1、可以做延迟设计

比如我们有一些数据，需要过五分钟后再被使用，这时候就需要使用延迟队列设计，比如在RabbitMQ中利用死信队列实现。

具体实现在这里：http://www.cnblogs.com/haoxinyue/p/6613706.html

2、异步处理

这个场景主要应用在多任务执行的场景。

3、应用解耦

在大型微服务架构中，有一些无状态的服务经常考虑使用mq做消息通知和转换。

4、分布式事务最终一致性

可以使用基于消息中间件的队列做分布式事务的消息补偿，实现最终一致性。

5、流量削峰

一般在秒杀或团抢活动中使用广泛，可以通过队列实现秒杀的人数和商品控制，还可以缓解短时间压垮应用系统。

6、日志处理

我们在做监控，或者日志采集的时候经常用队列来做消息的传输和暂存。

• 性能：吞吐量，如kafka zero copy
• 稳定性：高并发下
• 可靠性：消息持久化，是否可能丢消息等
• 支持的模式：发布订阅模式，点对点模式（关键模型是推还是拉）
• 事务消息：支持事务
• 消息确认：ack，重复消费
• 协议支持：等等
• 顺序消息：是否支持