附: Kafka Connect

2015年，Kafka 0.9版本增加了一个新的特性Kafka Connect, 可以更方便的创建和管理数据流管道, 通过connectors可以将数据从其它系统导入到Kafka中，也可以从Kafka中导出到其它系统。

例如想要把数据从MySQL迁移到ElasticSearch，为了保证高效和数据不会丢失，可以选择MQ作为中间件保存数据。这时候我们需要一个生产者线程，不断的从MySQL中读取数据并发送到MQ，还需要一个消费者线程消费MQ的数据写到ElasticSearch，这件事情似乎很简单，不需要任何框架。

但是如果我们想要保证生产者和消费者服务的高可用性，例如重启后生产者恢复到之前读取的位置，分布式部署并且节点宕机后将任务转移到其他节点。如果要加上这些的话，这件事就变得复杂起来了，而Kafka Connect 已经为我们造好这些轮子。

Kafka Connect可以将完整的数据库注入到Kafka的Topic中，或者将一些服务器的系统监控指标注入到Kafka。而导出工作则是将数据从Kafka Topic中导出到其它数据存储系统、查询系统或者离线分析系统等，比如数据库、ElasticSearch等。

image-20220508104945136

Kafka Connect特性包括：

  • Kafka connector通用框架, 提供统一的集成API
  • 同时支持分布式模式和单机模式
  • REST 接口，用来查看和管理Kafka connectors
  • 自动化的offset管理，开发人员不必担心错误处理的影响
  • 分布式、可扩展
  • 流/批处理集成

Architecture

Connectors： 连接器，分为两种—— Source（从源数据库拉取数据写入Kafka），Sink（从Kafka消费数据写入目标数据）

image-20220508151923042

Task：实际进行数据传输的单元，和连接器一样同样分为 Source和Sink

Workers: 刚刚我们讲的Connectors 和Task 属于逻辑单元，而Worker 是实际运行逻辑单元的进程，Worker 分为两种模式，单机模式和分布式模式

单机模式：比较简单，但是功能也受限，只有一些特殊的场景会使用到，例如收集主机的日志、或者用户开发测试环境。通常来说更多的是使用分布式模式

分布式模式：为Kafka Connect提供了可扩展和故障转移。相同group.id的Worker，会自动组成集群。当新增Worker，或者有Worker挂掉时，集群会自动协调分配所有的Connector 和 Task（这个过程称为Rebalance）：

image-20220507220749929

image-20220507220828555