进击消息中间件系列（一）：Kafka 入门（基本概念与架构）【转】
在这之前，我们相继卷完了：关系型数据库 MySQL 、 NoSQL 数据库 Redis 、 MongoDB 、搜索引擎 ElasticSearch 、大数据 Hadoop框架、PostgreSQL 数据库这些系列的知识体系。今天开始，我们将踏上另一个学习之路：中间件！第一个要学习的中间件就是：Kafka。
消息队列介绍
传统消息队列的应用场景
- 场景说明：用户注册后，需要发注册邮件和注册短信，传统的做法有两种 1，串行的方式 2，并行的方式
- 串行方式：将注册信息写入数据库后，发送注册邮件，再发送注册短信，以上三个任务全部完成之后才返回给客户端。这样会让客户等待比较久的时间，影响客户体验
- 并行方式：将注册信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间
- 消息列队：引入消息队列后，把发送邮件，短信不是必要的业务逻辑异步处理
使用消息队列的好处
解耦
可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
消息队列的两种模式
我们知道常见的消息系统有Kafka、RabbitMQ、ActiveMQ等等，但是这些消息系统中所使用的消息模式如下两种：
点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
- 消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
发布/订阅模式（一对多，消费者消费数据之后不会清除消息）
- 消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。
- 更多关于消息中间件 Kafka 系列的学习文章，请参阅：消息中间件 Kafka，本系列持续更新中。
常用消息系统对比
- 1、RabbitMQ Erlang编写，支持多协议 AMQP，XMPP，SMTP，STOMP。支持负载均衡、数据持久化。同时支持Peer-to-Peer和发布/订阅模式。
- 2、Redis 基于Key-Value对的NoSQL数据库，同时支持MQ功能，可做轻量级队列服务使用。就入队操作而言，Redis对短消息(小于10KB)的性能比RabbitMQ好，长消息的性能比RabbitMQ差。
- 3、ZeroMQ轻量级，不需要单独的消息服务器或中间件，应用程序本身扮演该角色，Peer-to-Peer。它实质上是一个库，需要开发人员自己组合多种技术，使用复杂度高。
- 4、ActiveMQ JMS实现，Peer-to-Peer，支持持久化、XA事务。
- 5、Kafka/Jafka 高性能跨语言的分布式发布/订阅消息系统，数据持久化，全分布式，同时支持在线和离线处理。
- 6、MetaQ/RocketMQ 纯Java实现，发布/订阅消息系统，支持本地事务和XA分布式事务。
Kafka 详解
什么是Kafka
Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目，该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。
Kafka是一个分布式消息队列：生产者、消费者的功能。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。
Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。
kakfa与zookeeper的关系？
- 1、所有Broker的管理，broker 会向 zookeeper
- 发送心跳请求来上报自己的状态。体现在zookeeper上会有一个专门用来Broker服务器列表记录的点，节点路径为/brokers/ids
- 2、zookeeper 保存了 topic 相关配置，例如 topic 列表、每个 topic 的 partition数量、副本的位置等等。
- 3、kafka 集群中有一个或多个broker，其中有一个通过zookeeper选举为leader控制器。控制器负责管理整个集群所有分区和副本的状态，例如某个分区的 leader 故障了，控制器会选举新的 leader。
Kafka的几个概念
- 1、Kafka作为一个集群运行在一个或多个服务器上，这些服务器可以跨多个机房，所以说kafka是分布式的发布订阅消息队列系统。
- 2、Kafka集群将记录流存储在称为Topic的类别中。
- 3、每条记录由键值；"key value"和一个时间戳组成。
- 更多关于消息中间件 Kafka 系列的学习文章，请参阅：消息中间件 Kafka，本系列持续更新中。
版本演变
0.7 #上古版本，提供了最基础的消息队列功能
0.8 #引入了副本机制，成为了一个真正意义上完备的分布式高可靠消息队列解决方案
0.8.2 #新版本 Producer API，即需要指定 Broker 地址的 Producer
0.9 #增加了基础的安全认证 / 权限，Java 重写了新版本消费者 API
0.10.0.0 #引入了 Kafka Streams
0.11.0.0 #提供幂等性 Producer API 以及事务（Transaction） API，对 Kafka 消息格式做了重构。
1.0 #Kafka Streams 的各种改进
2.0 #Kafka Streams 的各种改进
Kafka六大特点
- 1、高吞吐量、低延迟：可以满足每秒百万级别消息的生产和消费。它的延迟最低只有几毫秒，topic可以分多个partition, consumer group 对partition进行consumer操作。
- 2、持久性、可靠性：有一套完善的消息存储机制，确保数据高效安全且持久化。消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 。
- 3、分布式：基于分布式的扩展；Kafka的数据都会复制到几台服务器上，当某台故障失效时，生产者和消费者转而使用其它的Kafka。
- 4、可扩展性：kafka集群支持热扩展 。
- 5、容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）。
- 6、高并发：支持数千个客户端同时读写。
Kafka 架构
1）Producer：消息生产者，就是向 kafka broker 发消息的客户端；
2）Consumer：消息消费者，向 kafka broker 取消息的客户端；
3）Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。
5）Topic：可以理解为一个队列，生产者和消费者面向的都是一个topic；
6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个partition，每个 partition 是一个有序的队列；
7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个leader和若干个follower。
8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader 。
9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和leader数据的同步。leader 发生故障时，某个 follower 会成为新的 leader。
注：Kafka从0.8版本开始，Producer并不需要根据ZooKeeper来获取集群状态，而是在配置中指定多个Broker节点进行发送消息，同时跟指定的Broker建立连接，来从该Broker中获取集群的状态信息，所以Producer可以知道集群中有多少个Broker是否在存活状态，每个Broker上的Topic有多少个Partition。更多关于消息中间件 Kafka 系列的学习文章，请参阅：消息中间件 Kafka，本系列持续更新中。
Kafka数据处理步骤
- 1、Producer产生消息，发送到Broker中
- 2、Leader状态的Broker接收消息，写入到相应topic中
- 3、Leader状态的Broker接收完毕以后，传给Follow状态的Broker作为副本备份
- 4、Consumer消费Broker中的消息
Consumer与topic关系
kafka只支持Topic
1、每个group中可以有多个consumer，每个consumer属于一个consumer group；通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中的某个consumer失效那么其消费的partitions将会有其他consumer自动接管。
2、对于Topic中的一条特定的消息，只会被订阅此Topic的每个group中的其中一个consumer消费，此消息不会发送给一个group的多个consumer；那么一个group中所有的consumer将会交错的消费整个Topic，每个group中consumer消息消费互相独立，我们可以认为一个group是一个"订阅"者。
3、在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)；
一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。
4、kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。
kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来说,当有多个partitions时,消息仍不是全局有序的。
Kafka消息的分发
- 1、Producer客户端负责消息的分发
- 2、kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"、“partitions
- leader列表"等信息；
- 3、当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
- 4、消息由producer直接通过socket发送到broker，中间不会经过任何"路由层”。
事实上，消息被路由到哪个partition上由producer客户端决定，比如可以采用"random"“key-hash”"轮询"等。
如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
- 1、在producer端的配置文件中,开发者可以指定partition路由的方式。
- 2、Producer消息发送的应答机制设置发送数据是否需要服务端的反馈,有三个值0,1,-1
- 0: producer不会等待broker发送ack
- 1: 当leader接收到消息之后发送ack
- -1: 当所有的follower都同步消息成功后发送ack request.required.acks=0
Consumer的负载均衡
当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：
- 1、假如topic1,具有如下
partitions: P0,P1,P2,P3 - 2、加入group A 中,有如下
consumer:C0,C1 - 3、首先根据partition索引号对partitions排序:
P0,P1,P2,P3 - 4、根据consumer.id排序:
C0,C1 - 5、计算倍数:
M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整) - 6、然后依次分配
partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)]
kafka的应用场景
- 日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口开放给各种消费端，例如hadoop、Hbase、Solr等。
- 消息系统：解耦生产者和消费者、缓存消息等。
- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索记录、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标：Kafka也经常用来记录运营监控数据。
- 流式处理
更多关于消息中间件 Kafka 系列的学习文章，请参阅：消息中间件 Kafka，本系列持续更新中。
转自
进击消息中间件系列（一）：Kafka 入门（基本概念与架构）
https://mp.weixin.qq.com/s?__biz=MzI0MDQ4MTM5NQ==&mid=2247542083&idx=2&sn=4cadf1b97d6820eb220f6e43fc22bf7f&chksm=e918405fde6fc94999c7af29328b2953cb595eee12c21920ed9cdd3363cd599f2d9d11a68f3d&scene=178&cur_album_id=3002038547455180802#rd
转自民工哥牛X系列！
#消息中间件 Kafka
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzI0MDQ4MTM5NQ==&action=getalbum&album_id=3002038547455180802&scene=21#wechat_redirect
