标签：处理 key 发送 在线升级 服务器角色 min mesos amqp 聚合
Kafka快速入门（一）——Kafka简介Apache Kafka是一款开源的消息引擎系统，同时也是分布式流处理平台。
消息引擎系统是一组在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递的规范。
Kafka的设计目标如下：
（1）以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
（2）高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
（3）支持Kafka Server间的消息分区及分布式消费，同时保证每个Partition内的消息顺序传输。
（4）同时支持离线数据处理和实时数据处理。
（5）支持在线水平扩展。
为了增加存储能力，Kafka将所有的消息都写入到了低速大容量的硬盘。Kafka主要采用以下方式实现高吞吐率：
（1）顺序读写：Kafka将消息顺序追加到Partition中，顺序读写要快于随机读写。
（2）Zero Copy：Kafka的生产者、消费者API对于Kafka消息采用零拷贝实现。Java类库通过java.nio.channels.FileChannel中的transferTo()方法(底层sendfile系统调用)在Linux和UNIX系统上支持Zero Copy，内核直接将数据从磁盘文件拷贝到Socket套接字，而无需通过应用程序。
（3）批量发送：Kafka允许批量发送模式。
（4）消息压缩：Kafka允许对消息集合进行压缩。
（5）操作系统页缓存：不直接写IO，直接写入页缓存；消费时大多命中缓存。
（1）点对点模型
点对点模式是一个基于拉取或轮询的消息传送模型，由消费者主动拉取数据，客户端需要实时开启一个线程监控队列中是否有数据。
在点对点的消息系统中，消息保留在队列中，一个或者多个消费者可以消费队列中的消息，但消息最多只能被一个消费者消费，一旦有一个消费者将其消费掉，消息就从队列中消失。多个消费者可以同时工作，但最终只有一个消费者可以消费消息。典型实例如订单处理系统，多个订单处理器可以同时工作，但对于一个特定的订单，只有其中一个订单处理器可以拿到并进行处理。
（2）发布/订阅模型
发布/订阅模式是一个基于推送的消息传送模型，由MQ主动推送消息给所有订阅者，即使当前订阅者不可用。
在发布-订阅系统中，消息被保留在主题中。消费者可以订阅一个或多个主题并使用主题中的所有消息。在发布-订阅系统中，消息生产者称为发布者，消息消费者称为订阅者。
流处理平台有三种特性:
（1）可以发布和订阅流式消息。
（2）可以储存流式消息，并且有较好的容错性。
（3）可以在流式消息产生时就进行处理。
（1）解耦
Kafka消息引擎系统可以将业务处理过程进行解耦，消息引擎两端的业务处理过程只需要实现接口即可。
（2）冗余
消息队列把消息进行持久化，直到消息被完全处理，进而规避数据丢失风险。
（3）扩展性
消息队列解耦了业务处理过程，所以很容易增大消息入队和处理的频率，只要另外增加处理过程即可，不需要改变代码、不需要调节参数。
（4）削峰填谷
削峰填谷是流量整形的形象表达，是为了应对上游瞬时大流量的冲击，避免出现流量毛刺，保护下游应用和数据库不被瞬时大流量打垮。
（5）可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
（6）顺序保证
Kafka保证一个Partition内的消息的有序性。
（7）缓冲
消息队列通过一个缓冲层来帮助任务最高效率的执行——写入队列的处理会尽可能的快速。缓冲有助于控制和优化数据流经过系统的速度。
（8）异步通信
消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理，在需要时再处理。
（1）RabbitMQ
RabbitMQ是使用Erlang编写的一个开源的重量级企业级消息队列，本身支持很多的协议：AMQP、XMPP、SMTP、STOMP。RabbitMQ实现了Broker构架，消息在发送给客户端时先在中心队列排队，对路由、负载均衡或者数据持久化支持很好。
（2）Redis
Redis是一个基于Key-Value对的NoSQL数据库，但支持MQ功能，可以作为轻量级的MQ使用。入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过10K，Redis较慢；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
（3）ZeroMQ
ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但开发人员需要自己组合多种技术框架，技术上的复杂度是对ZeroMQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，不需要安装和运行消息服务器或中间件，应用程序会扮个服务器角色，但ZeroMQ仅提供非持久性的队列。
（4）ActiveMQ
ActiveMQ能够以代理人和点对点的技术实现队列，少量代码就可以高效地实现高级应用场景。
（5）Kafka/Jafka
Apache Kafka是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是基于Kafka的升级版。特性如下：
A、快速持久化，可以在O(1)的系统开销下进行消息持久化；
B、高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；
C、完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；
D、支持Hadoop数据并行加载，Kafka通过Hadoop并行加载机制统一了在线和离线的消息处理。
（6）RocketMQ
Apache RocketMQ是阿里开源的纯Java实现的分布式消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。
Kafka最初由LinkedIn使用Scala进行开发，于2011年初加入Apache开源项目，2012年10月从Apache Incubator毕业，成为Apache顶级项目，即Apache Kafka。Apache Kafka的目标是为处理实时数据提供一个统一、高吞吐量、低延时的平台。
官方地址：http://kafka.apache.org
2014年，Kafka的创始人Jay Kreps、NahaNarkhede和饶军离开LinkedIn创立Confluent公司，专注于提供基于Kafka的企业级流处理解决方案，并发布了Confluent Kafka。Confluent Kafka分为开源版和企业版，企业版收费。
Confluent开源版特性如下：
（1）Confluent Kafka Connectors：支持Kafka Connect JDBC Connector、Kafka Connect HDFS Connector、Kafka Connect Elasticsearch Connector、Kafka Connect S3 Connector。
（2）多客户端支持：支持C/C++、Python、Go、.Net客户端。
（3）Confluent Schema Registry
（4）Confluent Kafka REST Proxy
Confluent企业版特性如下：
（1）Automatic Data Balancing
（2）Multi-DataCenter Replication
（3）Confluent Control Center
（4）JMS Client
2011年7月，Apache Kafka发布第一个开源版本0.7.0，提供最基础的消息引擎服务，主要特性是压缩以及MirrorMaker（跨集群之间的数据拷贝）。Apache Kafka 0.7是按纯字节组织数据的，其偏移量是基于字节的。
2012年10月，Apache Kafka正式成为Apache顶级项目并发布0.8版本，引入了集群间的备份机制，使得Apache Kafka成为完备的分布式消息引擎解决方案。
Apache Kafka 0.8版本更新了消息数据结构，把数据偏移量改成按逻辑的，每条信息的数据偏移量是1。
0.8.2.x：使用Java重写Producer API，替代Scala的Producer API。
2014年11月，Apache Kafka 0.9.0发布，主要特性如下：
（1）增加基础的安全认证/权限功能。
Apache Kafka 0.9.0首次增加了安全认证功能，安全特性如下：
A、客户端连接Broker使用SSL或SASL进行验证。
B、Broker连接ZooKeeper进行权限管理。
C、数据传输进行加密。
D、客户端读、写操作可以进行授权管理。
E、可以对外部的可插拔模块的进行授权管理。
（2）使用Java重写Consumer API。
新的Comsumer API不分high-level、low-level， Kafka可以自行维护Offset、Consumer的Position，也可以由开发者自己来维护Offset，实现相关的业务需求；消费时，可以只消费指定的Partitions；可以使用外部存储记录Offset；自行控制Consumer消费消息的Position；可以使用多线程进行消费。
（3）引入Kafka Connect组件用于实现高性能的数据抽取。
0.9版本中Producer API已经比较稳定，但Consumer API的Bug较多。
2016年5月，Apache Kafka 0.10发布，引入Kafka Streams，Apache Kafka正式升级成分布式流处理平台，其主要特性如下：
（1）Kafka Streams
Kafka Streams由Confluent Platform首先在其平台的技术预览中行提出，目前已经引入Apache Kafka 0.10.0.0。Kafka Streams是一套类库，使得Apache Kafka可以拥有流处理的能力。Kafka Streams包含了一整套描述常见流操作的高级语言API（比如 joining, filtering以及aggregating records），使得开发者可以快速开发强大的流处理应用程序。Kafka Streams提供了状态和无状态的处理能力，并且可以部署在很多系统上：Kafka Streams应用程序可以运行在YARN、Mesos、Docker containers上，甚至直接嵌入到现有的Java应用程序中。
（2）机架感知(Rack Awareness)
Apache Kafka 0.10已经内置了机架感知以便隔离副本，使得Kafka保证副本可以跨越到多个机架或者是可用区域，显著提高了Kafka的弹性和可用性，功能由Netflix提供。
（3）消息时间戳
Apache Kafka 0.10引入了消息时间戳，所有Kafka中的消息都包含时间戳字段，即消息产生的时间。消息时间戳使得Kafka Streams能够处理基于事件时间的流处理，而且可以通过时间寻找消息以及基于事件时间戳的进行垃圾回收。
（4）SASL改进
Apache Kafka 0.9.0.0版本引入了新的安全特性，包括通过SASL支持Kerberos。Apache Kafka 0.10.0.0支持更多的SASL特性，包括外部授权服务器，在一台服务器上支持多种类型的SASL认证以及其它改进。
（5）显示所有支持的Connectors和连接状态/控制的REST API
在Kafka 0.10.0.0中，Kafka Connect得到了持续提升。在Kafka 0.10版本前，用户需要监控日志以便看到各个Connectors以及Task的状态，Kafka 0.10.0增加了获取状态的API，同时也添加了控制相关的API，使得用户可以在进行维护的时候停止一个Connector或者手动地重启失败的Task。
（6）Kafka Consumer Max Records
在Apache Kafka 0.9.0.0，开发者在新consumer上使用poll()函数时几乎无法控制返回消息的条数。Apache Kafka 0.10.0.0引入了max.poll.records参数，允许开发者控制返回消息的条数。
（7）协议版本改进(Protocol Version Improvements)
Apache Kafka 0.10.0.0中，Kafka Brokers支持返回所有支持的协议版本的请求API，优点是以后将允许一个客户端支持多个Broker版本。
0.10.2.2版本修复了一个可能导致Producer性能降低的Bug，并且Consumer API已经比较稳定。
2017年6月，Apache Kafka 0.11.0发布，支持exactly-once semantics（EOS)，其主要特性如下：
（1）修改unclean.leader.election.enabled默认值
Apache Kafka将unclean.leader.election.enabled参数的默认值改成false，即不再允许出现unclean leader选举的情况，在正确性和高可用性之间选择了正确性。如果依然要启用，用户需要显式地在server.properties中设置参数为true。
（2）确保offsets.topic.replication.factor参数被正确应用__consumer_offsets是Kafka自动创建的Topic，在创建的时候如果集群Broker数小于offsets.topic.replication.factor，原先的版本取其小者，但会违背用户设置offsets.topic.replication.factor参数的初衷。因此在Kafka 0.11版本中，offsets.topic.replication.factor参数会被强制遵守，如果不满足参数设定的值，会抛出GROUP_COORDINATOR_NOT_AVAILABLE。
（3）优化对Snappy压缩的支持
Apache Kafka 0.11.0版本对Snappy的默认block size做了调整。
（4）消息增加头部信息(Header)
Record增加了Header，每个header是一个KV存储。
（5）空消费者组延时Rebalance
为了缩短多Consumer首次Rebalance的时间，增加了“group.initial.rebalance.delay.ms”用于设置Group开启Rebalance的延时时间。延时期间允许更多的Consumer加入组，避免不必要的JoinGroup与SyncGroup之间的切换。
（6）消息格式变更
Apache Kafka 0.11.0版本增加最新的magic值：2，增加header信息。同时为了支持幂等Producer和EOS，增加一些与事务相关的字段，使得单个record数据结构体积增加。但因为优化了RecordBatch使得整个batch所占体积反而减少，进一步降低了网络IO开销。
（7）新的StickyAssignor分配算法
StickyAssignor是比range和round-robin更加平衡的分配算法。可以通过partition.assignment.strategy = org.apache.kafka.clients.consumer.StickyAssignor指定。
（8）Controller重设计
Apache Kafka 0.11.0版本采用单线程+基于事件队列的方式重构了Controller。
（9）支持EOS
exactly-once semantics（EOS）是流式处理实现正确性的基石，主流流式处理框架基本都支持EOS（如Storm Trident、Spark Streaming、Flink）。
Apache Kafka 0.11.0通过三大特性：幂等的Producer、支持事务、支持EOS的流式处理(保证读-处理-写全链路的EOS)，实现对EOS的支持。
2017年11月，Apache Kafka 1.0发布，主要优化Kafka Streams API以及完善各种监控指标，主要如下：
（1）改进builder API（KIP-120），新增用于查看运行时活跃任务的API（KIP-130）和用于聚合分区的 cogroup API（KIP-150）。（2）增强print()和writeAsText()方法让调试变得更容易（KIP-160）。
（3）改进Connect的度量指标（KIP-196），新增大量用于健康监测的度量指标（KIP-188），并提供集群的GloabalTopicCount 和GlobalPartitionCount度量指标（KIP-168）。
（4）支持 Java 9，实现更快的TLS和CRC32C，加快加密速度，降低计算开销。
（5）调整了SASL认证模块的错误处理逻辑（KIP-152），认证错误信息会被清晰地记录到日志当中。
（6）更好地支持磁盘容错（KIP-112），更优雅地处理磁盘错误，单个JBOD上的磁盘错误不会导致整个集群崩溃。
（7）提升吞吐量。0.11.0版本中引入的幂等性生产者需要将max.in.flight.requests.per.connection参数设置为1，对吞吐量造成一定的限制，在1.0.0版本中，参数最大可以被设置为5（KAFKA-5949），极大提升吞吐量范围。
2018年7月，Apache Kafka 2.0发布，其主要特性如下：
（1）增加前缀通配符访问控制(ACL)的支持，可以更加细粒度的进行访问控制；
（2）更全面的数据安全支持，可以使用OAuth2 bearer tokens对访问Kafka Brokers 进行权限控制。
（3）SSL连接默认启用主机名验证（Host name verification），以确保默认SSL配置不受中间人***的影响。
（4）可以在不重启Broker的情况下动态更新SSL信任库（SSL truststores）；可以在启动Broker前在ZooKeeper中为Broker 侦听器（broker listeners）配置安全性，包括SSL密钥库和信任库密码以及SAS的JAAS配置。
（5）复制协议已得到改进，以避免在fast leader failover期间 Leader和Follower之间的日志分歧（log divergence）。
（6）保证在线升级的方便性，简化了Kafka Streams升级过程。
（7）进一步加强了Kafka的可监控性，包括添加了很多系统静态属性以及动态健康指标。
（8）放弃对Java 7的支持，并移除Scala编写的Producer API和Consumer API代码。
Kafka是一个非常好的存储系统，写入Kafka的数据将写入磁盘并进行复制以实现容错功能。Kafka允许生产者等待确认，以便直到完全复制并确保即使写入服务器失败的情况下写入也不会完成。
Kafka会认真对待存储并允许客户端控制其读取位置，因此可以将Kafka视为一种专用于高性能、低延迟提交日志存储、复制和传播的专用分布式文件系统。
消息传递具有排队和发布-订阅两种模型。排队模型中，一组使用者可以从服务器中读取内容，并且每条记录都将转到其中一个，优点在于允许将数据处理划分到多个使用者实例上，从而扩展处理量，缺点在于队列不是多用户的。发布-订阅模型中，消息会广播给所有消费者，优点在于允许将数据广播到多个进程，缺点在于每条消息都传递给每个订阅者，因此无法扩展处理。
Kafka的Consumer Group融合了排队模型和发布订阅模型的优点，Consumer Group允许将处理划分为一组进程（Consumer Group的成员）；Kafka允许将消息广播到多个Consumer Group。
传统队列将消息按顺序保留在服务器上，如果多个消费者从队列中消费，则服务器将按记录的存储顺序分发记录。尽管服务器按顺序分发消息，但消息是异步传递给消费者的，因此消息可能在不同的消费者上乱序到达，即在并行使用的情况下消息会乱序。
Kafka在Topic内具有并行性（即Partition），通过将Topic中的Partition分配给Consumer Group中的消费者，每个分区都由Consumer Group中的一个消费者完全消费，Kafka能够在用户进程池中提供排序保证和负载均衡。Consumer Group中的消费者实例数量不能超过分区数量。
在Kafka中，流处理器是指从输入主题中获取连续数据流，对输入进行一些处理并生成连续数据流以输出主题的任何东西。
Kafka提供了完全集成的Streams API，允许构建执行非重要处理的应用程序，流处理API建立在Kafka提供的核心原语上，使用生产者和使用者API进行输入，使用Kafka进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。
标签：处理 key 发送 在线升级 服务器角色 min mesos amqp 聚合
原文地址：https://blog.51cto.com/9291927/2493953
