1、消息引擎系统前端
这类系统引觉得豪的消息传递属性，像引擎同样，具有某种能量转换传输的能力java
消息引擎系统是一组规范，企业利用这组规范在不一样系统之间传递语义准确的消息，实现松耦合的异步式数据传递。通俗地讲就是系统A发送消息给消息引擎系统，系统B从消息引擎系统读取系统A的消息数据库
既然消息引擎系统是用于不一样系统之间传输消息的，如何设计待传输消息的格式，提供可重用性及通用性。kafka使用的是二进制的字节序列，固然消息仍是结构化的，只是在使用以前都要将其转换成二进制的字节序列。安全
消息引擎系统还要设定具体的传输协议，即我用什么方法把消息传输出去：性能优化
一、点对点模型：也叫消息队列模型，系统A发送的消息只能被系统B接收，其余任何系统都不能读取A发送的消息服务器
二、发布/订阅模型：一个主题(Topic)，能够理解为消息容器。多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息微信
kafka同时支持这两种消息引擎模型网络
做用：削峰填谷和松耦合架构
一、削峰填谷就是指缓冲上下游瞬时突发流量，使其平滑。一旦有了消息引擎系统，它可以有效地对抗上游的流量冲击，真正作到将上游的“峰”填满到“谷”中，避免了流量的震荡框架
二、发送方和接收方的松耦合，简化了应用的开发，减小了系统间没必要要的交互
相似于秒杀这样的业务时，上游订单流量会瞬时增长，可能出现的结果就是直接压垮下游子系统服务（调用支付宝和微信接口、查询登陆信息、商品信息等）。当引入kafka后，上游订单服务再也不直接与下游子服务进行交互。当新订单生成后它仅仅是向kafka broker发送一条订单消息便可。下游各个子服务订阅对应的主题，并实时从该主题的各自分区（Partition）中获取订单消息进行处理，从而实现上游订单服务与下游订单处理服务解耦。这样当出现秒杀业务时，kafka可以将瞬时增长的订单流量所有以消息形式保存在对应的主题中，既不影响上游服务的TPS，同时给下游子服务留出充足的时间消费它们。
2、kafka术语
kafka属于分布式的消息引擎系统，它的主要功能是提供一套完备的消息发布与订阅解决方案。在kafka中，发布订阅的对象是主题（Topic），你能够为每一个业务、每一个应用甚至是每类数据都建立专属的主题。
客户端：
一、生产者（Producer）
向主题发布消息的客户端应用程序，生产者程序一般持续不断地向一个或多个主题发送消息。
二、消费者（Consumer）
订阅主题消息的客户端应用程序，消费者也可以同时订阅多个主题的消息。
咱们把生产者和消费者统称为客户端（Clients），你能够同时运行多个生产者和消费者实例，这些实例会不断地向kafka集群中的多个主题生产和消费消息。
服务端：
kafka的服务器端由被称为Broker的服务进程构成，即一个kafka集群由多个Broker组成，Broker负责接收和处理客户端发送过来的请求，以及对消息进行持久化。
虽然多个Broker进程可以运行在同一台机器上，但更常见的作法是将不一样的Broker分散运行在不一样的机器上，这样若是集群中某一台机器宕机，即便在它上面运行的全部Broker进程都挂掉了，其余机器上的Broker也依然可以对外提供服务。这其实就是kafka提供高可用的手段之一。
实现高可用的另外一个手段就是备份机制（Replication）。就是把相同的数据拷贝到多台机器上，而这些相同的数据拷贝在kafka中被称为副本（Replica）。副本的数量是能够配置的，这些副本保存着相同的数据，但却有不一样的角色和做用。
kafka定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。前者对外提供服务，这里的对外指的是与客户端程序进行交互；而后者只是被动地追随领导者副本而已，不能与外界进行交互。可是好比MySQL的从库是能够处理读操做的，可是在kafka中追随者副本不会对外提供服务。
副本的工做机制：生成者老是向领导者副本写消息；而消费者老是从领导者副本读消息。至于追随者副本，只作一件事就是向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。
伸缩性即所谓的Scalability，是分布式系统中很是重要且必需要谨慎对待的问题。什么是伸缩性？如kafka，虽然有了领导者副本和追随者副本，但若是领导者副本积累了太多的数据以致于单台Broker机器都没法容纳，此时该怎么办？一个很天然的想法就是可否把数据分割成多份保存在不一样的Broker上，kafka就是这么设计的，这种机制就是所谓的分区（Partitioning）。
kafka中的分区机制指的是将每一个主题划分红多个分区，每一个分区是一组有序的消息日志。生成者生成的每条消息只会被发送到一个分区中，也就是说若是向一个双分区的主题发送一条消息，这条消息要么在分区0中，要么在分区1中。kafka的分区编号是从0开始的，若是主题有100个分区，那么它们的分区号就是从0到99。
实际上，副本是在分区这个层级定义的。每一个分区下能够配置若干个副本，其中只能有一个领导者副本和N-1个追随者副本。生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移老是从0开始，假设一个生产者向一个空分区写入了10条消息，那么这10条消息的位移依次是0、一、二、.....、9。
kafka的三层消息架构：
- 第一层是主题层，每一个主题能够配置M个分区，而每一个分区又能够配置N个副本
- 第二层是分区层，每一个分区的N个副本只能有一个领导者副本，对外提供服务；其余N-1个副本是追随者副本，只是提供数据冗余做用。
- 第三层是消息层，分区中包含若干条消息，每条消息的位移从0开始，依次递增。
- 最后，客户端程序只能与分区的领导者副本进行交互
kafka Broker如何持久化数据：
kafka使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写消息的物理文件。由于只能追加写入，故避免了缓慢的随机I/O操做，改成性能较好的顺序I/O写操做，这也是实现kafka高吞吐量特性的一个重要手段。若是不停地向一个日志写入消息，最终也会耗尽全部磁盘空间，所以kafka必然要按期地删除消息以回收磁盘。
kafka经过日志段机制删除消息。在kafka底层，一个日志又进一步细分红多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，kafka会自动切分出一个新的日志段，并将老的日志段封存起来。kafka在后台还有定时任务会按期地检查老的日志段是否可以被删除，从而实现回收磁盘空间的目的。
消费者组：
在kafka中实现点对点模型的方法就是引入消费者组。所谓的消费者组，指的是多个消费者实例（能够是运行消费者应用的进程，也能够是一个线程，它们都称为一个消费者实例）共同组成一个组来消费一组主题。这组主题中的每一个分区都只会被组内的一个消费者实例消费，其余消费者实例不能消费它。引入消费者组主要是为了提高消费者端的吞吐量，多个消费者实例同时消费，加速整个消费端的吞吐量。
kafka的重平衡：
消费者组里面的全部消费者实例不只瓜分订阅主题的数据，并且它们还能彼此协助。假设某个实例挂掉了，kafka会自动检测到，而后把这个挂掉的实例以前负责的分区转移给其余消费者。可是因为重平衡引起的消费者问题比比皆是，目前社区上不少的重平衡Bug都无力解决。
消费者位移：
每一个消费者在消费消息的过程当中必然须要有一个字段记录它当前消费到了分区的哪一个位置上，这个字段就是消费者位移（Consumer Offset）。注意，这和上面所说的位移彻底不是一个概念。上面的位移表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就是固定的了。而消费者位置则不一样，它多是随时变化的，毕竟它是消费者消费进度的指示器。每一个消费者有着本身的消费者位移，所以必定要区分开两个位移。我我的把消息在分区中的位置称为分区位移，而把消费者端的位移称为消费者位移。
总结：
- 消息：Record。这里的消息就是指kafka处理的主要对象。
- 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。
- 分区：Partition。一个有序不变的消息叙序列。每一个主题下能够有多个分区。
- 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
- 副本：Repilca。kafka中同一条消息可以被拷贝到多个地方以提供数据冗余，这些地方就是所谓副本。副本分为领导者副本和追随者副本，各自有不一样的角色划分。副本是在分区层级下的，每一个分区可配置多个副本实现高可用。
- 生产者：Producer。向主题发布新消息的应用程序。
- 消费者：Consumer。从主题订阅新消息的应用程序。
- 消费者位移：Consumer Offset。表征消费者消费进度，每一个消费者都有本身的消费者位移。
- 消费者组：Consumer Group。多个消费者实例共同组成的一个组，同时消费多个分区以实现高吞吐。
- 重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其余消费者实例自动从新分配订阅主题分区的过程。这也是kafka消费者端实现高可用的重要手段。
概念图：
3、kafka是消息引擎系统，也是一个分布式流处理平台
kafka是Linkedin公司内部孵化的项目，Linkedin最开始有强烈的数据强实时处理方面的需求，其内部的诸多子系统要执行多种类型的数据处理与分析，主要包括业务系统和应用程序性能监控，以及用户行为数据处理等。
当时他们碰到的主要问题包括：
一、数据正确性不足。
二、系统高度定制化，维护成本高。各个业务子系统都须要对接数据收集模块，引入了大量的定制开销和人工成本。
为了解决这些问题，Linkedin工程师尝试过使用ActiveMQ来解决这些问题，但效果并不理想，显然是须要有一个系统，而这个系统就是kafka。
kafka在设计之初就旨在提供三个方面的特性：
一、提供一套API实现生产者和消费者；
二、下降网络传输和磁盘存储开销；
三、实现高伸缩性架构。
开源以后的kafka被愈来愈多的公司应用到它们企业内部的数据管道中，特别是在大数据工程领域，kafka在承接上下游、串联数据流管道方面发挥了重要做用：全部的数据几乎都要从一个系统流入kafka而后再流向下游的另外一个系统中。这样的方式引起了一个思考：与其我把数据从一个系统传递到下一个系统中作处理，我为什么不本身实现一套流处理框架呢？基于这个考量，kafka社区于0.10.0.0版本正式推出了流处理组件kafka streams，也正是从这个版本开始，kafka正式变身为分布式的流处理平台，而不只仅是消息引擎系统了。今天kafka是和Apache Storm、Apace Spark和Apace Flink同等级的实时流处理平台。
kafka与其余主流大数据流式计算框架相比，优点在两个方面：
一、更容易实现端到端的正确性（Correctness）。实现正确性是流处理可以匹敌批处理的基石。正确性一直是批处理的强项，而实现正确性的基石则是要求框架能提供精确一次（Exactly-once）处理语义，即处理一条消息有且只有一次机会可以影响系统的状态。目前主流的大数据流处理框架都宣称实现了精确一次处理语义，但这是有限定条件的，即它们只能实现框架内的的精确一次处理语义，没法实现端到端的。由于当这些框架与外部消息引擎系统结合使用时，它们没法影响到外部系统的处理语义，因此若是你搭建了一套环境使得Spark从kafka读取消息以后进行有状态的数据计算，最后再写回kafka，那么你只能保证在Spark内部，这条消息对于状态的影响只有一次。可是计算结果有可能屡次写入到kafka，由于它们不能控制kafka的语义处理。相反地，由于kafka全部的数据流转和计算都在kafka内部完成，故kafka能够实现端到端的精确一次处理语义。
二、它本身对于流式计算的定位。kafka Streams是一个用于搭建实时流处理的客户端库而不是一个完整的功能系统。即你不能指望着kafka提供相似于集群调度、弹性部署等开箱即用的运维特性，你须要本身选择适合的工具或系统来帮助kafka流处理应用实现这些功能。对于大型公司的流处理平台必定是大规模部署的，所以具有集群调度功能以及灵活的部署方案是不可或缺的。可是对于中小企业，它们的流处理数据量并不巨大，逻辑也并不复杂，部署几台或十台机器足以应付。在这样的需求下，搭建重量级的完整平台实在是杀鸡焉用牛刀，而这时使用kafka流处理组件是很是合适的。
总结：Apace Kafka从一个优秀的消息引擎系统起家，逐渐演变成如今分布式的流处理平台。不只要熟练掌握它做为消息引擎系统的非凡特性及使用技巧，最好还要多了解下其流处理组件的设计与案例应用。
4、kafka的版本选择
你可能据说过Apache Storm、Apache Spark Streaming和Apache Flink，它们在大规模流处理领域但是响当当的名字。而kafka毕竟是从消息引擎半路出家转型成流处理平台，它在流处理方面的表现还须要通过时间的检验。
kafka的流处理生态圈：
kafka Streams组件提供实时处理流数据的能力。
kafka Connect经过一个个具体的链接器（Connector），串联起上下游的外部系统。
kafka的版本：
这里不是指它的版本，而是指存在多个组织或公司发布不一样的kafka
一、Apache Kafka
最“正宗”的kafka，自kafka开源伊始，它便在Apache基金会孵化并最终毕业成为顶级项目，它也被称为社区版kafka。它是后面其余全部版本的基础，Apache Kafka 是咱们学习和使用kafka的基础。
特色：
（1）优点：它依然是开发人数最多、版本迭代速度最快的kafka。若是你使用碰到任何问题并提交问题到社区，社区都会比较及时地响应你。这对于咱们普通使用者来讲无疑是很是友好的。
（2）劣势：它仅仅提供最最基础的组件，特别是前面提到的Kafka Connect而言，社区版只提供一种链接器，即读写磁盘文件的；链接器，而没有与其余外部系统交互的链接器。另外没有提供任何监控框架或工具，显然在线上环境不加监控确定是不可行的，你必然须要借助第三方的监控框架实现对kafka的监控。目前有一些开源的监控框架能够帮助用于监控kafka（好比kafka manager）
选择场景：
若是你仅仅须要一个消息引擎系统亦或是简单的流处理应用场景，同时须要对系统有较大把握度，那么推荐使用Apache Kafka
二、Confluent Kafka
Confluent公司是kafka的3个创始人离开Linkedin创办的，专一于提供基于kafka的企业级流处理解决方案。它主要从事商业化kafka工具开发，并在此基础上发布了Confluent Kafka。Confluent Kafka提供了一些Apache Kafka没有的高级特性，好比跨数据中心备份、Schema注册中心以及集群监控工具等。
特色：
（1）优点：目前分为免费版和企业版，前者和Apache Kafka很是像，除了常规的组件外，免费版还包含Schema注册中心和REST proxy两大功能，前者是帮助你集中管理kafka消息格式以实现数据前向/后向兼容，后者用开放HTTP接口的方式容许你经过网络访问kafka的各类功能，这两个是Apache Kafka所没有的。除此以外，免费版包含了更多的链接器，能够无偿使用。至于企业版，它提供的功能就更多了。最有用的当属跨数据中心备份和集群监控两大功能，多个数据中心之间数据的同步以及对集群的监控从来都是kafka的痛点。
（2）劣势：Confluent公司暂时没有发展国内业务，相关的资料以及技术支持都很欠缺，因此目前Confluent Kafka在国内的普及率比较低
选择场景：
若是你须要用到kafka的一些高级特性，那么推荐使用Confluent Kafka
三、Cloudera/Hortonworks Kafka
Cloudera提供的 CDH 和Hortonworks提供的 HDP 是很是著名的大数据平台，里面集成了目前主流的大数据框架，可以帮助用户实现从分布式存储、集群调度、流处理到机器学习、实时数据库等全方位的数据处理。无论是CDH仍是HDP里面都集成了Apache Kafka，所以我把这两款产品中的kafka称为CDH Kafka和HDK Kafka。2018年10月两家公司合并，共同打造世界领先的数据平台。
特色：
（1）优点：经过便捷化的界面操做将kafka的安装、运维、管理、监控所有统一在控制台中，使用很是方便，全部的操做均可以在前端UI界面上完成，而没必要去执行复杂的kafka命令。
（2）劣势：这样作的结果是直接下降你对kafka集群的掌控程度，毕竟对下层kafka集群一无所知。还有在于它的滞后性，因为它有本身的发布周期，可能包含的kafka版本不是最新的。
选择场景：
若是你须要快速地搭建消息引擎系统，或者你须要搭建的是多框架构成的数据平台且kafka只是其中一个组件，那么推荐使用这些大数据云公司提供的kafka。
不少小公司都以为CDH很方便，安装以后什么都有了
5、Apache Kafka版本号
kafka在实际应用时，如何评判当前业务需求须要使用哪一个kafka版本，这就首先须要了解各个版本之间的差别和功能变化。并不是使用最新版本在任何场景下都适用。
kafka版本命令：
在官网下载时，会看到这样的版本：
前面的版本号是编译kafka源码的Scala编译器版本，kafka服务器端的代码彻底由Scala语言编写。对于上面kafka-2.11-2.1.1，真正的kafka版本号实际是2.1.1，那么这个2.1.1又表示什么？前面的2表示大版本号（Major Version）；中间的1表示小版本号或次版本号（Minor Version）；最后的1表示修订版本号（Patch号）。kafka社区在发布1.0.0版本后，宣布kafka版本命名规则正式从4位演进到3位，好比0.11.0.0版本就是4位版本号。总结来讲，kafka版本号由3部分构成，即大版本号-小版本号-Patch号。
kafka版本演进：
目前总共演进了7个大版本，分别0.七、0.八、0.九、0.十、0.十一、1.0和2.0，其中的小版本和Patch本不少。若是你要向架构师转型或者已然是架构师，那么熟悉哪些版本引入了哪些重大的功能改进，那么这些能够帮助你进行技术选型、架构评估的重要依据。
一、0.7版本
最先开源时的的版本，只提供了最基础的消息队列功能，甚至连副本机制都没有，实在没有理由使用这个版本。
二、0.8版本
正式引入了副本机制，至此成为了一个真正意义上完备的分布式高可靠消息队列解决方案。那时候生成和消费消息使用的仍是老版本的客户端API，所谓的老版本是指当你用它们的API开发生成者和消费者应用时，你须要指定ZooKeeper的地址而非Broker的地址。老版本客户端有不少的问题，特别是生产者API，它默认使用同步方式发送消息，可见其吞吐量必定不会过高。虽然它也支持异步的方式，但实际场景中可能会形成消息的丢失，所以0.8.2.0版本引入了新版本Producer API，即须要指定Broker地址的Producer。建议至少升级到0.8.2.2，由于该版本中老版本消费者API是比较稳定的，另外在该版本中，不要使用新版本Producer API，此时它的Bug还很是多。
三、0.9版本
这是一个重量级的大版本更迭，增长了基础的安全认证/权限功能，同时使用java重写了新版消费者API，还引入了Kafka Connect组件用于实现高性能的数据抽取。新版本Producer API在这个版本中算比较稳定了。和0.8.2引入新API相似，不要使用新版本Consumer API，由于Bug超多。
四、0.10版本
是里程碑式的大版本，由于该版本引入了kafka Streams。从这个版本起，kafka升级成分布式流处理平台，虽然此时的kafka Streams还基本不能线上部署使用。0.10大版本包含两个小版本：0.10.1和0.10.2，它们主要功能变动都是在kafka Streams组件上。若是把kafka用做消息引擎，实际上该版本并无太多的功能提高。自0.10.2.2版本起，新版本Consumer API算是比较稳定了，还有该版本修复了一个可能致使Producer性能下降的Bug。基于性能若是你还在使用0.10大版本，你也应该升级到0.10.2.2。
五、0.11版本
引入两个重量级的功能变动：
一个是提供幂等性Producer API以及事务API（kafka实现流处理结果正确性的基石）。此时的事务API存在一些Bug，不算稳定，另外事务API主要是为Kafka Streams应用服务的。
另外一个是对kafka消息格式作了重构。可是由于格式变动引发消息格式转换而致使的性能问题在生产环境中家常便饭，全部要谨慎对待0.11版本这个变化。
该版本中各个大功能组件都变得很是稳定了，国内该版本的用户也不少，应该算是目前最流行的版本之一了。0.11.0.3这个版本的消息引擎功能已经很是完善了。
六、1.0和2.0版本
这两个大版本主要是Kafka Streams的各类改进，在消息引擎方面并未引入太多的重大功能特性。若是你是Kafka Streams的用户，至少选择2.0.0版本吧。若是你在乎的依然是消息引擎，那么这两个大版本都是适合于生产环境的。
最后建议，不论你用哪一个版本，都请尽可能保持服务器端版本和客户端版本一致，不然你将损失不少Kafka为你提供的性能优化收益。