一.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。