导语
在使用大量的分布式数据库、分布式计算集群的时候会遇到如下的一些问题
- 1、想分析用户的行为，特别是在电商行业里面对于用户的分析对各方面的资源的整合是有很大的帮助。
- 2、对用户关键字进行统计，分析出当下热门或者是用户最喜欢的东西等等
- 3、对于有些日志数据存入数据库中对于数据库是一种浪费，但是直接存入磁盘中读写的速率又有点低。
有了上面这些问题，为了处理这些问题，就产生了消息系统，特别在现在分布式的系统中也出现了很多的额分布式消息系统。下面介绍的Kafka就是其中一种。
上面所提到的这些场景都有一个共同的特点就是数据由某个系统产生，这些数据有些是有价值的数据有些是没有价值的数据，下游的系统会使用到这些数据产生的数据价值，通过这些数据进行计算、处理、以及分析。这些场景中跟多的就是对接不同的系统，例如用户喜好是从A系统产生的、用户行为分析是从B系统产生的，但是A系统与B系统是完全独立的没有关系的两个系统，那么这两个系统之间怎么进行数据的整合呢？这里就需要使用到消息系统。
Kafka的定义
首先Kafka是作为一个分布式消息系统所存在的，是由LinkedIn使用Scala编写，要知道Scala在大数据领域是比较高效的编程语言。很多的数据分析数据优化都是通过Scala来实现的。作为LinkedIn的Activity Stream 和运营数据处理通道的基础支持，具有高水平扩展和吞吐量。
Kafka主要是用来做公司的多种类型数据管道和消息系统来使用，在现在这家公司中，由于做用户行为分析，所以要求所有的平台将日志数据传输到Hadoop 中，就需要对接不同的日志文件或者日志路径。通过Kafka来收集不同渠道的数据来进行处理。像是淘宝、支付宝、百度等大厂都在使用。
越来越多的开源的分布式处理系统例如像是Apache flume(用于日志收集)、Apache Storm(用于实时数据处理)、Spark(用于内存数据处理)、Elasticsearch(用于全文检索)等都支持与kafka的集成。在之前的博客中提到过关于flume的东西，当时就是为了让本人的平台去对接kafka 大数据平台，研究了一下关于flume。
各种消息中间件比较
| ActiveMQ | RabbitMQ | Kafka | |
|---|---|---|---|
| 所属公司 | Apache | Mozila Public License | Apache/LinkedIn |
| 开发语言 | Java | Erlang | Java/Scala |
| 支持协议 | OpenWire、STOMP、REST、XMPP、AMQP | AMQP | 仿AMQP |
| 事务 | 支持 | 不支持 | 不支持 |
| 集群 | 支持 | 支持 | 支持 |
| 负载均衡 | 支持 | 支持 | 支持 |
| 动态扩容 | 不支持 | 不支持 | 支持ZK |
其实上面缺少一个东西就是RockMQ。对于RockMQ后期会有博客与大家分享。
由于消息系统和消息中间件的设计就是用来进行系统间交互的，既然是用来系统间交互就需要两个系统共同遵守一套协议，也就是说中国人与外国人交流必须遵守的规范就是官方语言。而对于消息系统，或者是消息中间件来说也有自己支持的协议，其中比较著名的就是AMQP，很多的消息中间件消息系统都是围绕着它来支持的。可以说AMQP就是消息系统的官方语言。
对于事务来说，最早应该出现在数据库中，对于多个操作一起提交要么全部成功要么全部失败，不可能部分成功部分失败，一个最为简单的例子就是转账，A账户减少钱的同时B账户应该增加，两个操作要么一起成功，要么一起失败，不会出现A账户钱减少，而B账户的钱不增加的场景。对于消息系统来说就是说发送一个处理消息，当处理成功之后消费者才会给提供者一个信号用来确认是否成功。由于Kafka以性能著称所以对于这种消息处理机制并不支持。
Kafka相关概念
什么是AMQP协议？
这里简单的说一下AMQP协议，AMQP高级消息队列协议（Advanced Message Queue Protocol）是一个进程间传递异步消息的网络协议。
一些基本的概念
- 消费者 Consumer ，从消息队列中获取数据响应给客户端的组件
- 生产者 Producer , 向Broker中发送消息给对应客户端的组件
- AMQP服务器 Broker ,用来接收生产者发送的消息然后将这些消息由路由给服务消费队列
Kafka支持的客户端语言有那些？
Kafka 客户端支持大部分主流的开发语言，包括C、C++ 、Java、Erlang、.Net 、Perl 、PHP、Python 、Ruby、Go 、JavaScript可以使用任意一种语言和Kafka服务器进行通信，也就是是编写自己的Consumer和Producer。
Kafka的架构
会看到上面是是很多的生产者下面是很多的消费者，中间是用一个kafka进行连接与交互，在整个消息创建于交互的过程中数据模型与下图所示。
从上面图中可以看到最为经典的两个概念
- 主题(Topic)：一个类似于新闻分类的东西，在实际使用的时候一个业务表示一个主题
- 分区(Partition): 一个Topic中消息数据按照多个分区组织，分区是kafka消息队
列组织的最小单位，一个分区可以看做是一个FIFO(先进先出)的队列。
从上面图中可以看到Producer将数据push到Broker集群中，为了保证可靠性在kafka0.8开始对于数据进行备份，防止其中的一个Broker宕机造成数据不可用，这里有个概念需要声明一下，就是数据存储在集群中的时候并不是完全都存在于一个Broker上的，有可能有些数据在Broker1 上有在Broker2上也会有。两个Broker上分别是这条数据的两个部分，当然其中Zookeeper作为一个分布式状态管理、管理配置、分布式锁管理的集群处理方案存在。