一、Kafka存在哪些方面的劣势
1. 多生产者
能够无缝地反对多个生产者，不论客户端在应用单个主题还是多个主题。
2. 多消费者
反对多个消费者从一个独自的音讯流上读取数据，而且消费者之间互不影响。
3. 基于磁盘的数据存储
反对消费者非实时地读取音讯，因为音讯被提交到磁盘，依据设置的规定进行保留。当消费者产生异样时候，意外离线，因为有长久化的数据保障，能够实现联机后从上次中断的中央持续解决音讯。
4. 伸缩性
用户在开发阶段能够先试用单个broker，再扩大到蕴含3个broker的小型开发集群，而后随着数据量一直增长，部署到生产环境的集群可能蕴含上百个broker。
5. 高性能
Kafka能够轻松解决微小的音讯流，在解决大量数据的共事，它还能保障亚秒级的音讯提早。
二、Kafka常见的应用场景
1. 音讯
kafka更好的替换传统的音讯零碎，音讯零碎被用于各种场景（解耦数据生产者，缓存未解决的音讯等），与大多数音讯零碎比拟，kafka有更好的吞吐量，内置分区，正本和故障转移，这有利于解决大规模的音讯。
依据咱们的教训，音讯往往用于较低的吞吐量，但须要低的端到端提早，并须要提供弱小的耐用性的保障。
在这一畛域的kafka比得上传统的音讯零碎，如ActiveMQ或RabbitMQ等。
2. 网站流动追踪
kafka本来的应用场景是用户的流动追踪，网站的流动（网页旅行，搜寻或其余用户的操作信息）公布到不同的话题核心，这些音讯可实时处理，实时监测，也可加载到Hadoop或离线解决数据仓库。
3. 指标
kafka也经常用于监测数据。分布式应用程序生成的统计数据集中聚合。
4. 日志聚合
许多人应用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件，并将它们放在地方地位（可能是文件服务器或HDFS）进行解决。Kafka形象出文件的细节，并将日志或事件数据更清晰地形象为音讯流。这容许更低提早的解决并更容易反对多个数据源和分布式数据生产。
5. 流解决
kafka中音讯解决个别蕴含多个阶段。其中原始输出数据是从kafka主题生产的，而后汇总，丰盛，或者以其余的形式解决转化为新主题，例如，一个举荐新闻文章，文章内容可能从“articles”主题获取；而后进一步解决内容，失去一个解决后的新内容，最初举荐给用户。这种解决是基于单个主题的实时数据流。从0.10.0.0开始，轻量，但功能强大的流解决，就能够这样进行数据处理了。
除了Kafka Streams，还有Apache Storm和Apache Samza可抉择。
6. 事件采集
事件采集是一种应用程序的设计格调，其中状态的变动依据工夫的程序记录下来，kafka反对这种十分大的存储日志数据的场景。
7. 提交日志
kafka能够作为一种分布式的内部日志，可帮忙节点之间复制数据，并作为失败的节点来复原数据从新同步，kafka的日志压缩性能很好的反对这种用法，这种用法相似于Apacha BookKeeper我的项目。
三、Kafka架构深度分析
1. Kafka数据处理步骤
1.1 Producer产生音讯，发送到Broker中
1.2 Leader状态的Broker接管音讯，写入到相应topic中
1.3 Leader状态的Broker接管结束当前，传给Follow状态的Broker作为正本备份
1.4 Consumer生产Broker中的音讯
2. Kafka 外围组件
2.1 Producer：音讯生产者，产生的音讯将会被发送到某个topic
2.2 Consumer：音讯消费者，生产的音讯内容来自某个topic
2.3 Topic：音讯依据topic进行归类，topic其本质是一个目录，行将同一主题音讯归类到同一个目录
2.4 Broker：每一个kafka实例（或者说每台kafka服务器节点）就是一个broker，一个broker能够有多个topic
2.5 Zookeeper： Zookeeper集群不属于kafka内的组件，但kafka依赖 Zookeeper集群保留meta信息，所以在此做申明其重要性。
3. broker和集群
一个独立的Kafka服务器称为broker，broker接管来自生产者的音讯，为音讯设置偏移量，并提交音讯到磁盘保留。broker为消费者提供服务，对读取分区的申请作出响应，返回曾经提交到磁盘上的音讯。依据特定的硬件及其性能特色，单个broker能够轻松解决数千个分区以及每秒百万级的音讯量。
broker是集群的组成部分。每个集群都有一个broker同时充当了集群控制器的角色（主动从集群的沉闷成员中选举进去）。控制器负责管理工作，包含将分区调配给broker和监控broker。在集群中，一个分区从属于一个broker，该broker被称为分区的领袖。一个分区能够调配多个broker，这个时候会产生分区复制。这种复制机制为分区提供了音讯冗余，如果一个broker生效，其余broker能够接管领导权。不过，相干的消费者和生产者都要从新连贯到新的领袖。
4. Consumer与topic关系
kafka只反对Topic
• 每个group中能够有多个consumer，每个consumer属于一个consumer group；通常状况下，一个group中会蕴含多个consumer，这样不仅能够进步topic中音讯的并发生产能力，而且还能进步”故障容错”性，如果group中的某个consumer生效那么其生产的partitions将会由其它consumer主动接管。
• 对于Topic中的一条特定的音讯，只会被订阅此Topic的每个group中的其中一个consumer生产，此音讯不会发送给一个group的多个consumer；那么一个group中所有的consumer将会交织的生产整个Topic，每个group中consumer音讯生产相互独立，咱们能够认为一个group是一个”订阅”者。
• 在kafka中,一个partition中的音讯只会被group中的一个consumer生产(同一时刻)；
一个Topic中的每个partions，只会被一个”订阅者”中的一个consumer生产，不过一个consumer能够同时生产多个partitions中的音讯。
• kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时生产，否则将意味着某些consumer将无奈失去音讯，而处于闲暇状态。
kafka只能保障一个partition中的音讯被某个consumer生产时是程序的；事实上，从Topic角度来说,当有多个partitions时,音讯仍不是全局有序的。
5. Kafka音讯的散发
• Producer客户端负责音讯的散发
• kafka集群中的任何一个broker都能够向producer提供metadata信息,这些metadata中蕴含”集群中存活的servers列表”、“partitions leader列表”等信息；
• 当producer获取到metadata信息之后, producer将会和Topic下所有partition leader放弃socket连贯；
• 音讯由producer间接通过socket发送到broker，两头不会通过任何”路由层”。事实上，音讯被路由到哪个partition上由producer客户端决定，比方能够采纳”random””key-hash””轮询”等。
• 如果一个topic中有多个partitions,那么在producer端实现”音讯平衡散发”是必要的。
• 在producer端的配置文件中,开发者能够指定partition路由的形式。
• Producer音讯发送的应答机制
设置发送数据是否须要服务端的反馈,有三个值0,1,-1
0: producer不会期待broker发送ack
1: 当leader接管到音讯之后发送ack
2: 当所有的follower都同步音讯胜利后发送ack
request.required.acks=0
6. Consumer的负载平衡
当一个group中,有consumer退出或者来到时,会触发partitions平衡.平衡的最终目标,是晋升topic的并发生产能力，步骤如下：
- 如果topic1,具备如下partitions: P0,P1,P2,P3
- 退出group A 中,有如下consumer: C0,C1
- 首先依据partition索引号对partitions排序: P0,P1,P2,P3
- 依据consumer.id排序: C0,C1
- 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
- 而后顺次调配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i M),P((i + 1) M -1)]
如果本文对您有帮忙，欢送
关注和点赞`，您的反对是我保持创作的能源。转载请注明出处！