目的
解耦、异步、削峰
问题
- 系统可用性降低，增加了mq环节，mq挂掉导致整个系统挂掉
- 系统复杂度提高，需要针对mq增加各种考虑
- 一致性问题
比较
| ActiveMQ | RabbitMQ | RocketMQ | Kafka | |
|---|---|---|---|---|
| 吞吐量 | 万级吞吐量 | 万级吞吐量 | 十万级吞吐量 | 十万级吞吐量 |
| topic对吞吐量的影响 | topic可以达到几百，几千个的级别时吞吐量会有较小幅度的下降 | topic从几十到几百的时候，吞吐量会大幅下降，所以同等机器下，保证topic数量不要过多 | ||
| 响应 | ms级响应 | 微秒级响应，延迟最低 | ms级响应 | ms级响应 |
| 高可用 | 高可用，基于主从架构实现 | 高可用，基于主从架构实现 | 非常高，分布式架构 | 非常高，分布式架构，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
| 数据安全 | 较低概率丢失消息 | 一般不会丢失消息 | 经过参数优化配置，可以做到0丢失 | 经过参数优化配置，可以做到0丢失 |
| 功能 | MQ领域的功能极其完备 | 基于erlang开发，并发能力很强，性能及其好，延时很低，MQ领域的功能比较完备 | MQ功能较为完备 | 功能很简单，简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的的标准 |
| 总结 | 非常成熟，业内大量公司使用，但是社区不活跃，版本越来越少，主要基于解耦与异步来用，很少用于大规模吞吐的场景 | 开源管理管理系统非常好用，社区比较活跃，更新维护频繁，国内近几年用的比较多，但因为是erlang开发，普通公司玩不转，吞吐量只有万级 | 接口易用，阿里开源，品质保障，社区活跃，支持复杂的业务场景，吞吐量特别大，分布式架构，但会有项目黄了的风险 | 功能少，吞吐量超高，易于拓展 |
高可用
RabbitMQ
- 单机模式
- demo级别，本地启动玩玩
- 普通集群模式
- 多台机器上启动多个实例，每个机器上一个，但是创建的queue只会放在一个实例上，其他实例只同步这个queue的元数据
- 缺点：可能会在集群内部产生大量数据的传输，可用性没有保障，queue所在节点宕机，queue里的数据就会丢失
- 镜像集群模式
- 实现高可用，每个实例都会同步queue的全部信息
- 缺点：性能开销太大，没有扩展性可言，网络压力和消耗很重
- 管理控制台，可以增加策略，按照镜像集群模式开始
Kafka
- 没台机器启动一个borker进程，可以认为是Kafka的一个节点
- 按照topic划分partition，实现分布式
- leader、follower、replica副本机制、选举，保证高可用
