最全技术架构—各类技术选型与区别答疑—【区别-缺点与不足】—(2)，讲的真透彻

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

两种方式的缺点与不足：

Push方式：	优点是可以尽可能快地将消息发送给消费者，缺点是如果消费者处理能力跟不上，消费者的缓冲区可能会溢出。
Pull方式：	优点是消费端可以按处理能力进行拉去，缺点是会增加消息延迟。

---

市面上常见消息中间件默认的方式：

RabbitMQ 消费者默认是推模式（也支持拉模式）。

RocketMQ 消费者默认是推模式（也支持拉模式）（从严格意义上说，RocketMQ并没有实现真正的消息消费的Push模式，而                                                        是对Pull模式进行了一定的优化）

Kafka 默认是拉模式。

处理 性能上： Kafka>RocketMQ>RabbitMQ。

---

各种消息中间件使用场景：

Kafka  是 高吞吐量消息中间件的行业老大。主要特点是基于Pull的模式来处理消息消费，支持数据持久化，

高效的磁盘顺序读写（这主要在于它的队列模式保证了写磁盘的过程是线性IO 即磁盘顺序读写。）Kafka 还支持batch 操作，

适合产生海量数据的互联网服务的数据收集业务。

RabbitMQ 基于AMQP协议来实现，对数据一致性、稳定性和可靠性要求很高的场景

AMQP协议更多用在企业级系统内，目前在 传统的信息系统项目中使用的多

RocketMQ 思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化

**（**RocketMQ是阿里开源的消息中间件 在淘宝系统中大量使用）

ActiveMQ: 基于JMS协议的消息队列，现在很少使用，处理性能不如以上3个

---

消息中间件相关的技术选型总结：

---

---

消息中间件RocketMQ执行原理：

目前企业消息中间件使用：

总体来讲Kafka特别适合的场景是 吞吐量的要求很大，实时数据分析，log分析等场景。但是如果用来做业务事件的分发，也非常适合。

如果业务场景压力不大，又比较传统，需要那些传统的JMS协议，用Active MQ完全够用，但同时也可以考虑一下RabbitMQ

电商类：RocketMQ

传统企业：RabbitMQ 、ActiveMQ

大数据行业：Kafka

一般满足如下场景都可以考虑使用：

当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。

消息队列主要解决了应用耦合、异步处理、流量削锋等问题。

---

消息中间件具体使用场景：

1. 分布式环境下事务：

思路：通过中间件，ack机制 协调多个事物的一致性

A账户向B账户进行转账为例：

A、B账户不在同一个DB中，此时无法像在单机情况下使用事物来实现。此时可以通过一下方式实现，将  转账操作分成      两个操作。通过消息中间件发送数据变更记录与ACK机制返回处理状态来做事物的提交与回滚

具体流程：

a） A账户

| 步骤 | 动作 |

| — | — |

| 1 | 锁定A的账户 |

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！