标签：man keep 场景 不同 producer 技术 可靠 毕业 设置
Kafka概述
Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
传统消息队列的应用场景
使用消息队列的好处
1:解耦
允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2:可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
3:缓冲--> 削峰平谷
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
4:灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5:异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
消息队列的两种模式
点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。
消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
发布/订阅模式（一对多，消费者消费数据之后不会清除消息）
消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
kafka是基于发布/订阅模式，但是结合了点对点模式消费者自己拉取的模式获取消息，
这样的好处是1. 支持多个消费者，2.消费者端决定消费速度，这样的弊端是需要维护一个服务。长轮询监控消息队列是否有消息，这样比较浪费资源。
仕么是kafka
Kafka是一个分布式的数据流式传输平台。
在流式计算中，Kafka一般用来缓存数据，Spark通过消费Kafka的数据进行计算。
1:Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。
2:Kafka最初是由LinkedIn公司开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。
3:Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。
4:无论是kafka集群，还是consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。
kafka特点
作为一个数据流式传输平台，kafka有以下三大特点：
类似于消息队列和商业的消息系统，kafka提供对流式数据的发布和订阅
kafka提供一种持久的容错的方式存储流式数据
kafka拥有良好的性能，可以及时地处理流式数据
基于以上三种特点，kafka在以下两种应用之间流行：
①需要在多个应用和系统间提供高可靠的实时数据通道
②一些需要实时传输数据及及时计算的应用
此外，kafka还有以下特点：
Kafka主要集群方式运行在一个或多个可跨多个数据中心的服务器上
Kafka集群将数据按照类别记录存储，这种类别在kafka中称为主题
每条记录由一个键，一个值和一个时间戳组成
Kafka核心概念
Broker:
一台kafka服务器就是一个broker。一个集群由多个broker组成。
Topic:
Topic 就是数据主题，kafka建议根据业务系统将不同的数据存放在不同的topic中！Kafka中的Topics总是多订阅者模式，一个topic可以拥有一个或者多个消费者来订阅它的数据。一个大的Topic可以分布式存储在多个kafka broker中！Topic可以类比为数据库中的库！
Partition:
每个topic可以有多个分区，通过分区的设计，topic可以不断进行扩展！即一个Topic的多个分区分布式存储在多个broker!
此外通过分区还可以让一个topic被多个consumer进行消费！以达到并行处理！分区可以类比为数据库中的表！
kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。
数据会按照时间顺序被不断追加到分区的一个结构化的commit log中！每个分区中存储的记录都是有序的，且顺序不可变！
这个顺序是通过一个称之为offset的id来唯一标识！因此也可以认为offset是有序且不可变的！
在每一个消费者端，会唯一保存的元数据是offset（偏移量）,即消费在log中的位置.偏移量由消费者所控制。通常在读取记录后，消费者会以线性的方式增加偏移量，但是实际上，由于这个位置由消费者控制，所以消费者可以采用任何顺序来消费记录。例如，一个消费者可以重置到一个旧的偏移量，从而重新处理过去的数据；也可以跳过最近的记录，从"现在"开始消费。
这些细节说明Kafka 消费者是非常廉价的—消费者的增加和减少，对集群或者其他消费者没有多大的影响。比如，你可以使用命令行工具，对一些topic内容执行 tail操作，并不会影响已存在的消费者消费数据。
Topic 拓扑结构
数据流
Producer:
消息生产者，就是向kafka broker发消息的客户端。生产者负责将记录分配到topic的指定 partition（分区）中
Consumer:
消息消费者，向kafka broker取到消息的客户端。每个消费者都要维护自己读取数据的offset。低版本0.9之前将offset默认保存在Zookeeper中，0.9及之后默认保存在Kafka的“__consumer_offsets”主题中。
Consumer Group:
每个消费者都会使用一个消费组名称来进行标识。同一个组中的不同的消费者实例，可以分布在多个进程或多个机器上！
如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例（单播）。即每个消费者可以同时读取一个topic一个分区！
如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程(广播)。
如果需要实现广播，只要每个consumer有一个独立的组就可以了。要实现单播只要所有的consumer在同一个组。
一个topic可以有多个consumer group。topic的消息会复制（不是真的复制，是概念上的）到所有的CG，但每个partion只会把消息发给该CG中的一个consumer。
持久化
Kafka 集群保留所有发布的记录—无论他们是否已被消费—并通过一个可配置的参数——保留期限来控制。举个例子， 如果保留策略设置为2天，一条记录发布后两天内，可以随时被消费，两天过后这条记录会被清除并释放磁盘空间。
Kafka的性能和数据大小无关，所以长时间存储数据没有什么问题。
副本机制
日志的分区partition （分布）在Kafka集群的服务器上。每个服务器在处理数据和请求时，共享这些分区。每一个分区都会在已配置的服务器上进行备份，确保容错性。
每个分区都有一台 server 作为 “leader”，零台或者多台server作为 follwers 。leader server 处理一切对 partition （分区）的读写请求，而follwers只需被动的同步leader上的数据。当leader宕机了，followers 中的一台服务器会自动成为新的 leader。通过这种机制，既可以保证数据有多个副本，也实现了一个高可用的机制！
基于安全考虑/负载均衡的考虑，每个分区的Leader和follower不会分到一个broker上.相同分区的不同副本本身就不可能在一个broker上。
Kafka基础架构
kafka 0.9版本之前，消费者的偏移量信息保存在zk上，这样导致频繁的访问zk，影响性能，0.9之后，把offset信息保存在kafka的一个topic里面了
标签：man keep 场景 不同 producer 技术 可靠 毕业 设置
原文地址：https://www.cnblogs.com/comw/p/14205103.html
