Kafka 架构和原理机制 (图文全面详解)

Posted mikechen的互联网架构

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Kafka 架构和原理机制 (图文全面详解)相关的知识,希望对你有一定的参考价值。

目录

一:Kafka 简介

Apache Kafka 是分布式发布 - 订阅消息系统,在 kafka 官网上对 kafka 的定义:一个分布式发布 - 订阅消息传递系统。

Kafka 最初由 LinkedIn 公司开发,Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。

Kafka 的主要应用场景有:日志收集系统和消息系统。

二:Kafka 基本架构

Kafka 的架构包括以下组件:

1、话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名;

2、生产者(Producer):是能够发布消息到话题的任何对象;

3、服务代理(Broker):已发布的消息保存在一组服务器中,它们被称为代理(Broker)或 Kafka 集群;

4、消费者(Consumer):可以订阅一个或多个话题,并从 Broker 拉数据,从而消费这些已发布的消息;

上图中可以看出,生产者将数据发送到 Broker 代理,Broker 代理有多个话题 topic ,消费者从 Broker 获取数据。

三:Kafka 基本原理

我们将消息的发布(publish)称作 producer,将消息的订阅(subscribe)表述为 consumer,将中间的存储阵列称作 broker (代理),这样就可以大致描绘出这样一个场面:

生产者将数据生产出来,交给 broker 进行存储,消费者需要消费数据了,就从 broker 中去拿出数据来,然后完成一系列对数据的处理操作。

多个 broker 协同合作,producer 和 consumer 部署在各个业务逻辑中被频繁的调用,三者通过 zookeeper 管理协调请求和转发,这样一个高性能的分布式消息发布订阅系统就完成了。

图上有个细节需要注意,producer 到 broker 的过程是 push,也就是有数据就推送到 broker,而 consumer 到 broker 的过程是 pull,是通过 consumer 主动去拉数据的。

四:Zookeeper 在 Kafka 的作用

1.  无论是 Kafka 集群,还是 producer 和 consumer ,都依赖于 Zookeeper 来保证系统可用性集群保存一些 meta 信息。

2.  Kafka 使用 Zookeeper 作为其分布式协调框架,可以很好地将消息生产、消息存储、消息消费的过程结合在一起。

3.  Kafka 借助 Zookeeper,让生产者、消费者和 broker 在内的所有组件,在无状态的情况下,建立起生产者和消费者的订阅关系,并实现生产者与消费者的负载均衡。

五:Kafka 的特性

1. 高吞吐量、低延迟

Kafka 每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个 topic 可以分多个 partition ,  consumer group 对 partition 进行 consume 操作。

2. 可扩展性

Kafka 集群支持热扩展。

3.  持久性、可靠性

消息被持久化到本地磁盘,并且支持数据备份防止数据丢失。

4.  容错性

允许集群中节点失败(若副本数量为 n, 则允许 n-1 个节点失败)

5.  高并发

支持数千个客户端同时读写。

六:Kafka 的应用场景

1.  日志收集

一个公司可以用 Kafka 收集各种服务的 log ,通过 Kafka 以统一接口服务的方式开放给各种 consumer,例如:hadoop、Hbase、Solr 等。

2.  消息系统

解耦和生产者和消费者、缓存消息等。

3. 用户活动跟踪

Kafka 经常被用来记录 web 用户、或者 app 用户的各种活动,例如:浏览网页、搜索、点击等活动。

这些活动信息,被各个服务器发布到 Kafka 的 topic 中,订阅者再通过订阅这些 topic 来做实时的监控分析,或者装载到 hadoop 、数据仓库中做离线分析和挖掘。

4.  运营指标

Kafka 也经常用来记录运营监控数据。

包括收集各种分布式应用的数据,生产各种操作的集中反馈等,例如:报警和报告。

5. 流式处理

例如:spark streaming、storm 。

以上!

作者简介

陈睿 | mikechen , 10 年 + 大厂架构经验,「mikechen 的互联网架构」系列文章作者,专注于互联网架构技术。

阅读「mikechen 的互联网架构」40W 字技术文章合集

Java 并发 | JVM | MySQL | Spring | Redis | 分布式 | 高并发

Dubbo原理和机制详解(非常全面)

Dubbo是一款Java RPC框架,致力于提供高性能的RPC远程服务调用方案。Dubbo 作为主流的微服务框架之一,为开发人员带来了非常多的便利。

本文我们重点详解 Dubbo 的原理机制 @mikechen

目录

1️⃣ Dubbo核心功能

Dubbo主要提供了3大核心功能:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

 1)远程方法调用

网络通信框架,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。

 2)智能容错和负载均衡

提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。

3)服务注册和发现

服务注册,基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

2️⃣ Dubbo核心组件

Dubbo角色,主要包含如下几个核心组件:

1)注册中心(registry)

生产者在此注册并发布内容,消费者在此订阅并接收发布的内容。

2)消费者(consumer)

客户端,从注册中心获取到方法,可以调用生产者中的方法。

3)生产者(provider)

服务端,生产内容,生产前需要依赖容器(先启动容器)。

4)容器(container)

生产者在启动执行的时候,必须依赖容器才能正常启动(默认依赖的是spring容器),

5)监控(Monitor)

统计服务的调用次数与时间等。

3️⃣ Dubbo的架构设计

Dubbo整体架构如下图所示:

图中:

  • 左边(淡蓝背景):为服务消费方使用的接口
  • 右边(淡绿色背景):为服务提供方使用的接口
  • 位于中轴线上:为双方都用到的接口。

Dubbo 框架设计一共划分了10个层:

1. 服务接口层(Service)

该层是与实际业务逻辑相关的,根据服务提供方和服务消费方的业务设计对应的接口和实现。

2. 配置层(Config)

对外配置接口,以ServiceConfig和ReferenceConfig为中心,可以直接new配置类,也可以通过spring解析配置生成配置类。

 3.服务代理层(Proxy)

服务接口透明代理,生成服务的客户端Stub和服务器端Skeleton,以ServiceProxy为中心,扩展接口为ProxyFactory。

 4.服务注册层(Registry)

封装服务地址的注册与发现,以服务URL为中心,扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心,此时服务提供方直接暴露服务。

 5.集群层(Cluster)

封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方,实现对服务消费方来透明,只需要与一个服务提供方进行交互。

 6.监控层(Monitor)

RPC调用次数和调用时间监控,以Statistics为中心,扩展接口为MonitorFactory、Monitor和MonitorService。

 7.远程调用层(Protocol)

封将RPC调用,以Invocation和Result为中心,扩展接口为Protocol、Invoker和Exporter。Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠扰,或转换成它,它代表一个可执行体,可向它发起invoke调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。

8. 信息交换层(Exchange)

封装请求响应模式,同步转异步,以Request和Response为中心,扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

 9.网络传输层(Transport)

抽象mina和netty为统一接口,以 Message 为中心,扩展接口为 Channel、Transporter、Client、Server和Codec。

10.数据序列化层(Serialize)

可复用的一些工具,扩展接口为 Serialization、 ObjectInput、ObjectOutput和ThreadPool。

4️⃣ Dubbo调用流程

对照上面的整体架构图,大致分为以下8大步骤:

1、服务提供者启动,开启Netty服务,创建Zookeeper客户端,向注册中心注册服务;

2、服务消费者启动,通过Zookeeper向注册中心获取服务提供者列表,与服务提供者通过Netty建立长连接;

3、服务消费者通过接口开始远程调用服务,ProxyFactory通过初始化Proxy对象,Proxy通过创建动态代理对象;

4、动态代理对象通过invoke方法,层层包装生成一个Invoker对象,该对象包含了代理对象;

5、Invoker通过路由,负载均衡选择了一个最合适的服务提供者,在通过加入各种过滤器,协议层包装生成一个新的DubboInvoker对象;

6、再通过交换成将DubboInvoker对象包装成一个Reuqest对象,该对象通过序列化通过NettyClient传输到服务提供者的NettyServer端;

7、到了服务提供者这边,再通过反序列化、协议解密等操作生成一个DubboExporter对象,再层层传递处理,会生成一个服务提供端的Invoker对象;

8、这个Invoker对象会调用本地服务,获得结果再通过层层回调返回到服务消费者,服务消费者拿到结果后,再解析获得最终结果。

以上,是关于 Dubbo 原理及机制的详细解析,可以作为 Dubbo 的参考学习资料,建议收藏、时常温顾。

如果觉得有用,请点击 点赞 + 转发 支持下,谢谢~

作者简介

陈睿 | mikechen,10年+大厂架构经验,「mikechen 的互联网架构」系列文章作者,专注互联网架构技术。

阅读「mikechen 的互联网架构」的更多技术文章:

Java并发 | JVM | MySQL | Spring | Redis | 分布式 | 高并发 

以上是关于Kafka 架构和原理机制 (图文全面详解)的主要内容,如果未能解决你的问题,请参考以下文章

Dubbo原理和机制详解(非常全面)

图文详解HDFS工作机制

如何快速全面掌握Kafka?5000字吐血整理

图文详解一文全面彻底搞懂HBaseLevelDBRocksDB等NoSQL背后的存储原理:LSM-tree日志结构合并树...

图文详解一文全面彻底搞懂HBaseLevelDBRocksDB等NoSQL背后的存储原理:LSM-tree日志结构合并树...

图文详解一文全面彻底搞懂HBaseLevelDBRocksDB等NoSQL背后的存储原理:LSM-tree日志结构合并树...