一.Kafka 概述
1.1 音讯队列简介
音讯队列就是一个寄存音讯的容器 (MQ)，当咱们须要应用音讯的应用能够从中取出音讯。
次要类型有两种，点对点音讯队列和公布 - 订阅者音讯队列.
- 1. 点对点音讯队列
音讯生产者生产音讯发送到音讯队列中，而后音讯消费者从 Queue 中取出并且生产音讯。
音讯被生产当前，Queue 中不再有存储，所以音讯消费者不可能生产到曾经被生产的音讯。
点对点音讯队列模式反对存在多个消费者，然而对一个音讯而言，只会有一个消费者能够生产。
- 2. 公布 - 订阅音讯队列
音讯生产者（公布）将音讯公布到 topic 中，同时有多个音讯消费者（订阅）生产该音讯。和点对点形式不同，公布到 topic 的音讯会被所有订阅者生产。数据被生产后不会立马删除。在公布 - 订阅音讯零碎中，音讯的生产者称为发布者，消费者称为订阅者。
1.2 kafka 介绍
Kafka 是一个分布式的基于公布 / 订阅模式的音讯队列，具备高性能、长久化、多正本备份、横向扩大能力。生产者往队列里写音讯，消费者从队列里取音讯进行业务逻辑。个别在架构设计中起到解耦、削峰、异步解决的作用。
次要利用场景是：日志收集零碎和音讯零碎。
1.3 Kafka 术语
在了解 kafa 之前，先理解下 kafka 的术语，见下图
1）broker
kafka 急大众蕴含一个或多个服务器，服务器节点就称之为 broker。
2）Topic
每条公布到 kafk 的音讯都有一个类别，这个类别就是 topic。
物理上不同 Topic 的音讯离开存储，逻辑上一个 Topic 的音讯尽管保留于一个或多个 broker 上但用户只需指定音讯的 Topic 即可生产或生产数据而不用关怀数据存于何处
3）Partition
topic 中的数据会被宰割为一个或者多个 Partition。每个 topic 至多一个 Partition。
每个 Partition 中的数据应用多个 segment 文件存储。Partition 中的数据是有序的，但不同的 Partition 间的数据失落数据的程序，如果 topic 有多个 Partition，那生产数据时不能保证数据的程序，在须要严格保障音讯程序的场景下，Partition 数据须要设置为 1.
4）Producer
生产者，就数据的发布者，它将数据公布到 kafka 的 topic 中。
broker 承受到发布者发送的音讯数据，将该音讯追加到以后用于追加数据的 segment 中。
发布者发送的音讯，存储到一个 Partition 中，生产者也能够指定数据存储的 Partition。
5）Consumer
消费者也就是订阅者，从 broker 中读取数据，消费者能够读取多个 topic 中的数据。
6）Consumer Group
每个 Consumer 属于一个特定的 Consumer Group。
7）Leader
每个 Partition 有多个正本，其中有且仅有一个作为 Leader，Leader 负责以后数据读写。
8）Follower
Follower 追随 Leader，所有读写申请都通过 Leader，数据变更会播送给所有 Follower，Follower 与 Leader 保持数据同步。
如果 Leader 生效，则从 Follower 中选举出一个新的 Leader。当 Follower 与 Leader 挂掉、卡住或者同步太慢，leader 会把这个 follower 从“in sync replicas”（ISR）列表中删除，从新创立一个 Follower。
二. 为什么应用 kafka
当然更精确的说，为什么要应用队列？kafka 只是咱们抉择的队列。
2.1 解耦
举一个例子，咱们有一个 A 零碎，它要把数据发到 B、C 两个零碎，这时候来了一个需要，D 零碎说“我也须要 A 零碎的数据，你发过来吧”，负责 A 零碎的程序员开始改代码，没有费多少力量，批改好了。
过了两天，D 零碎说“我当初不须要 A 零碎的数据了。”
A：“。。。。”
又过了两天，D 零碎“A 零碎，不行啊，我还是得须要你的数据。”
周而复始，负责 A 零碎的程序员“心态崩了。。。”
那咱们当初引入了 Kafka，当然这并不只是 Kafka 的劣势，其余音讯队列同样能够实现解耦哦，具体依据业务状况来抉择，这里只说 kafka。
有了 kafka 后，当初 A 的数据只发送到 kafka 中，其他人想要应用数据从 kafka 中取就是了。
这样 A 零碎就跟其余零碎解耦了。
2.2 异步通信
假设这样一个场景，还是 A 零碎，从浏览器承受了一个申请，在本人本地写库，速度 1ms，之后须要 BC 两零碎也要写库，但速度要慢，B 零碎须要 600ms，C 零碎须要 500ms，这个时候用户从浏览器发动申请到失去相应须要 1ms+600ms+800ms，那用户体验必定不好。
但应用音讯队列能够实现异步解耦
A 零碎取得申请后，发送两条音讯到音讯队列，假设只有 2ms 实现，之后 A 就能够响应用户了，总共耗时 1ms+2ms，也就是 3ms，那用户体验必定不差，这就是异步通信。
2.3 冗余
有些状况下，解决数据的过程可能会失败，这时候数据除非被长久化，佛足额就会失落。
音讯队列把数据进行长久化，直到他们曾经被齐全解决，通过这种形式躲避了数据失落的危险。
2.4 削峰
还是举例，平时 A 零碎，每秒并发量也就是 100 左右，这时赶上双 11，并发量可是能突增到 50k 以上，这对系统还有数据库的压力可是极大的，搞不好就把零碎搞解体了。
就像咱们 mysql，每秒 2000 多的并发申请就
然而双 11 一过，又回到日常 100 左右并发。
这时候，我引入音讯队列，申请先进入音讯队列中，假设每秒 5k 个，A 零碎从音讯队列拉取申请，每秒解决 3k 个，音讯队列以 5k 个申请进入，3k 个申请被拉取出去，这样就能够顶住顶峰期间的拜访压力，不会因为突发的超顶峰负荷导致系统解体。
2.5 可恢复性
A 零碎把数据发到音讯队列中，B 从音讯队列中拉取数据，忽然 B 挂掉了，但队列中保留的数据还在，所以当 B 复原后，还能够持续解决之前的数据。
3. 罕用 MQ 介绍
3.1 RabbitMQ
RabbitMQ 是应用 Erlang 编写的一个开源的音讯队列，反对很多的协定：AMQP，XMPP, SMTP, STOMP。
它反对多种语言，Python、Java、Ruby、C、PHP 等，反对事务、公布确认和音讯长久化。
那个很火的 Openstack 中用到的就是 RabbitMQ。
3.2 Redis
Redis 是一个 NoSql 数据库，基于 k - v 对，尽管是一个 k - v 的 NoSql 数据，但自身反对 MQ 性能。
同样很多语言都反对 Redis，像会话缓存、音讯队列，还有流动排行榜等。
对于 RabbitMQ 和 Redis 的入队和入列性能测试，对两者出入队操作，各执行 100 万次，每 10 万次记录一次执行工夫，测试数据别离为 128Bytes、512Bytes、1K 和 10K 四个不同大小的数据。
结果表明：
入队时，当数据比拟小时 Redis 的性能要高于 RabbitMQ，而如果数据大小超过了 10K，Redis 则慢的无法忍受；
出队时，无论数据大小，Redis 都体现出十分好的性能，而 RabbitMQ 的出队性能则远低于 Redis。
在抉择 MQ 时，要结合实际业务状况来抉择。
Redis 是轻量级、高并发、提早敏感，在做缓存、即时数据分析等场景能够思考。
3.3 ActiveMQ
性能比拟差，版本迭代慢，当初应用的应该不多了。
3.4 RocketMQ
阿里出品，Java 系开源我的项目，
参考文档：http://rocketmq.apache.org/
3.5 Kafka
Apache 下的一个子项目，这是一个分布式公布 / 订阅音讯队列零碎，咱们 hadoop 生态中，就应用 kafka。