Kafka

MQ

　　Message Queue(MQ)，消息队列中间件。MQ通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是--MQ是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议,定义了一套应用层的、更加简单的通讯协议。

有Broker的MQ

　　这个流通常有一台服务器作为Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker则把消息主动推送给消费者(或者消费者主动轮询)

重 Topic

　　kafka、rocketMQ、JMS(ActiveMQ)就属于这个流派，生产者会发送key和数据到Broker，由 Broker比较 key 之后决定给哪个消费者。这种模式是我们最常见的模式，是我们对 MQ 最多的印象。在这种下一个topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个topic，topic 某种意义上就是 queue，生产者发送 key 相于说:“hi，把数据放到 key 的队列中”。
　　kafka:全球消息处理性能最快的一款MQ。
　　rocketMQ:阿里内部一个大神，根据kafka的内部执行原理，手写的一个消息队列中间件。性能是与Kafka相比肩，除此之外，在功能上封装了更多的功能。

轻 Topic

　　这种的代表是RabbitMQ(或者说是AMQP)。生产者发送 key和数据，消费者定义订阅的队列，Broker 收到数据之后会通过一定的逻辑计算出 key 对应的队列，然后把数据交给队列。
　　rabbitMQ:内部的功能性是非常强的。

无 Broker的MQ

　　无 Broker 的 MQ的代表是 ZeroMQ。该作者非常容智，他非常敏锐的意识到--MQ 是更高级的 Socket，它是解决通讯问题的。所以
ZeroMQ 被设计成了一个“库”而不是一个中间件，这种实现也可以达到--没有 Broker 的目的。

　　节点之间通讯的消息都是发送到彼此的队列中，每个节点都既是生产者又是消费者。ZeroMQ做的事情就是封装出一套类似于 Socket 的API可以完成发送数据，读取数据。
　　ZeroMQ 其实就是一个跨语言的、重量级的 Actor 模型邮箱库。你可以把自己的程序想象成一个Actor，ZeroMQ 就是提供邮箱功能的库;ZeroMQ 可以实现同一台机器的 RPC通讯也可以实现不同机器的 TCP、UDP 通讯，如果你需要一个强大的、灵活、野蛮的通讯能力，别犹豫 ZeroMQ。

Kafka

　　Kafka是最初由Linkedin公司开发，是一个分在式、支持分区的(partition)、多副本的(replica)，基于zookeeper协调的分布式消息系统。它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、Storm/spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
1.Kafka的使用场景
日志收集:一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
消息系统:解耦和生产者和消费者、缓存消息等
用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

业务场景决定了产品的特点。所以Kafka最典型的产品特点有以下几点:
1、数据吞吐量很大:需要能够快速收集各个渠道的海量日志
2、集群容错性高:允许集群中少量节点崩溃
3、功能不需要太复杂:Kalka的设计目标景离吞吐、低还迟和可扩展，主要关注消息传递而不是消息处理。所以，Kafka并没有支持死信队列、顺序消息等高级功能
4、允许少量数据丢失:在海量的应用日志中，少量的日志丢失是不会影响结果的。所以Kafka的设计初衷是允许少量数据丢失的。当然Kafka本身也在不断优化数据安全问题。

基础的消息：

Broker：消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
Topic：Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
Producer：消息生产者，向Broker发送消息的客户端
Consumer：消息消费者，从Broker读取消息的客户端
ConsumerGroup：每个Consumer属于一个特定的Consumer Group，一条消息可以被多个不同的Consumer Group消费，但是一个Consumer Group中只能有一个Consumer能够消费该消息。
Partition：物理上的概念，一个topic可以分为多个partition，每个partition内部消息是有序的