每种技术都有其产生的业务背景，解决某一类问题，并不一定适应所有场景
自然就会有其最佳使用场景与不足。
本博客的出发点：
对面试而言：面试经常会问 1.各种区别 2.优缺点 3.为啥这么用 4.你们项目中如何使用的。。。。
对工作而言：搭建系统环境与技术选型（如果在基础架构部门的话），
开发部门会这些也可以提高自身编码的架构思维 写 出更好的代码来。
1. 采集数据为什么选择kafka
采集层 主要可以使用Flume, Kafka两种技术。
Flume：Flume 是管道流方式，提供了很多的默认实现（扇入流、扇出流等），让用户通过参数部署，也可扩展API.
Kafka：Kafka是一个可持久化的磁盘顺序存储（磁盘的顺序读写）的分布式的消息队列。你可以有许多生产者和很多的消费者共享多个主题Topics。消费方式采用pull方式 (主动消费类型)，兼顾了消费者的消费能力，消费可以根据自身消费能力消费数据，传统的消息队列系统能够很好的处理实时或者近似实时的应用，但未处理的数据通常不会写到磁盘上kafka 可持久化数据使其够很好地进行离线和在线处理。
相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化，并且集成了Hadoop的安全特性。所以，Cloudera 建议如果数据被多个系统消费的话，使用kafka；如果数据被设计给Hadoop使用，使用Flume。业务场景中可以同时使用Kafka与Flume，大概的架构图如下
拓展部分：
Cloudera ：(由于Hadoop深受客户欢迎，许多公司都推出了各自版本的Hadoop，也有一些公司则围绕Hadoop开发产品。在Hadoop生态系统中，规模最大、知名度最高的公司则是Cloudera)
1. 消息中间件的中数据的消费方式：
分类： 分为push和pull两种方式，push为被动消费类型，pull为主动消费类型
区别：
①Push方式：由消息中间件主动地将消息推送给消费者；
②Pull方式：由消费者主动向消息中间件拉取消息。
优缺点：
两种方式的缺点与不足：
| 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的账户 |
| 2 | 检查A账户是否有1元 |
| 3 | A的账户扣减1元 |
| 4 | 解锁A的账户 |
b) MQ消息
A账户数据发生变化时，发送MQ消息，MQ服务器将消息推送给转账系统，转账系统来给B账号加钱。操作是否成功返回ACK状 态，A进行提交或回滚处理
c) B账户
| 步骤 | 动作 |
|---|---|
| 1 | 锁定B的账户 |
| 2 | 给B的账户加1元 |
| 3 | 解锁B的账户 |
