Ⅰ Kafka集群部署（Docker容器的方式）
文章主要介绍以docker容器的方式部署kafka集群。
上述配置文件中的server.x，数字x对应到data/myid文件中的值。三台机器x的值分别就是1,2,3。参数详细说明请参考 官网文档 。
1.--net=host: 容器与主机共享同一Network Namespace，即容器与网络看到的是相同的网络视图（host模式存在一定的风险，对安全要求很高的生产环境最好不要用host模式，应考虑除此之外的其他几种模式）
2.-v: 指定主机到容器的目录映射关系
这样就以容器的方式启动了zookeeper的服务，可以通过 "docker exec -it zookeeper bash" 命令进入容器中进行一些操作，例如查看服务启动是否正常。也可以通过查看2181端口是否被监听判断zookeeper的服务是否运行
详细的参数配置说明请参考 官方文档 ，参数不仅可以通过上述文件的方式来配置，也可以通过容器环境变量的方式来配置，这里结合两种方式使用。
1.KAFKA_ADVERTISED_HOST_NAME、KAFKA_BROKER_ID的值要结合每台机器自身设置
2./etc/hosts文件中最好配置ip与hostname的映射关系，否则会报出如下错误" Error: Exception thrown by the agent : java.net.MalformedURLException: Local host name unknown: java.net.UnknownHostException: node0: node0: System error "
3.通过-e 指定的环境变量与在server.properties中配置的选项其效果是一样的
4.配置文件中的选项若要通过环境变量来指定，方式为：如broker.id对应KAFKA_BROKER_ID，类似的log.dirs对应KAFKA_LOG_DIRS
5.KAFKA_HEAP_OPTS="-Xmx6G -Xms6G"指java堆内存大小的设置，6G大小是kafka官网给出的数值，此数值要结合机器的内存大小给出。超过6G的内存，可以设置为6G；若机器的内存低于6G而设置6G，则会报错。
5.启动成功后，可以通过"docker logs kafka"命令查看日志
1.ZK_HOSTS：ZooKeeper访问地址（需指定机器的ip，localhost:2181或127.0.0.1:2181均会报 "java.net.ConnectException: Connection refused" 异常）
Ⅱ Kafka 基础原理及工作流程简述
Kafka 工作流程
基础总结：
1）broker :broker代表kafka的节点， Broker是分布式部署并且相互之间相互独立的， 启动的时候向zookeeper 注册，在Zookeeper上会有一个专门 用来进行Broker服务器列表记录 的节点：/brokers/ids。每个Broker在启动时，都会到Zookeeper上进行注册，即到/brokers/ids下创建属于自己的节点，如/brokers/ids/[0...N]。Kafka使用了全局唯一的数字来指代每个Broker服务器，不同的Broker必须使用不同的Broker ID进行注册，创建完节点后， 每个Broker就会将自己的IP地址和端口信息记录 到该节点中去。其中，Broker创建的节点类型是 临时节点 ，一旦Broker 宕机 ，则 对应的临时节点也会被自动删除 。
2）topic：消息主题，在Kafka中，同一个 Topic的消息会被分成多个分区 并将其分布在多个Broker上， 这些分区信息及与Broker的对应关系 也都是由Zookeeper在维护，由专门的节点来记录，如：/borkers/topics Kafka中每个Topic都会以/brokers/topics/[topic]的形式被记录，如/brokers/topics/login和/brokers/topics/search等。Broker服务器启动后，会到对应Topic节点（/brokers/topics）上注册自己的Broker ID并写入针对该Topic的分区总数，如/brokers/topics/login/3->2，这个节点表示Broker ID为3的一个Broker服务器，对于"login"这个Topic的消息，提供了2个分区进行消息存储，同样，这个分区节点也是临时节点。
3）partition ：同一topic类型消息的分区，如图，每个分区都存在一个leader 和N个follower（副本），副本个数在创建topic的时候可以指定创建多少个。消息生产者生产消息和消费组消费消息都是通过leader完成，副本的存在是为了防止发生节点宕机，导致leader挂了，follower随时顶上去变成leader，继续恢复生产。重点来了，leader所在节点挂了，会有follower变成leader，所以同一个topic的同一个partition的leader与follower不可能在同一个broker，这样才能做到这个broker上的某个topic的某个partition的leader挂了，其他正常节点上的这个topic的这个partition的follower会顶上来。
4）生产者发送消息的 负载均衡 ：由于同一个Topic消息会被分区并将其分布在多个Broker上，因此， 生产者需要将消息合理地发送到这些分布式的Broker上 ，那么如何实现生产者的负载均衡，Kafka支持传统的四层负载均衡，也支持Zookeeper方式实现负载均衡。 (4.1) 四层负载均衡，根据生产者的IP地址和端口来为其确定一个相关联的Broker。通常，一个生产者只会对应单个Broker，然后该生产者产生的消息都发往该Broker。这种方式逻辑简单，每个生产者不需要同其他系统建立额外的TCP连接，只需要和Broker维护单个TCP连接即可。但是，其无法做到真正的负载均衡，因为实际系统中的每个生产者产生的消息量及每个Broker的消息存储量都是不一样的，如果有些生产者产生的消息远多于其他生产者的话，那么会导致不同的Broker接收到的消息总数差异巨大，同时，生产者也无法实时感知到Broker的新增和删除。 (4.2) 使用Zookeeper进行负载均衡，由于每个Broker启动时，都会完成Broker注册过程，生产者会通过该节点的变化来动态地感知到Broker服务器列表的变更，这样就可以实现动态的负载均衡机制。
5）消费者负载均衡：与生产者类似，Kafka中的消费者同样需要进行负载均衡来实现多个消费者合理地从对应的Broker服务器上接收消息，每个消费组分组包含若干消费者， 每条消息都只会发送给分组中的一个消费者 ，不同的消费者分组消费自己特定的Topic下面的消息，互不干扰。
6）分区与消费者 的关系： 消费组 (Consumer Group) consumer group 下有多个 Consumer（消费者）。对于每个消费者组 (Consumer Group)，Kafka都会为其分配一个全局唯一的Group ID，Group 内部的所有消费者共享该 ID。订阅的topic下的每个分区只能分配给某个 group 下的一个consumer(当然该分区还可以被分配给其他group)。同时，Kafka为每个消费者分配一个Consumer ID，通常采用"Hostname:UUID"形式表示。在Kafka中，规定了 每个消息分区 只能被同组的一个消费者进行消费 ，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：/consumers/[group_id]/owners/[topic]/[broker_id-partition_id] 其中，[broker_id-partition_id]就是一个 消息分区 的标识，节点内容就是该 消息分区 上 消费者的Consumer ID。
7）消息的消费进度Offset 记录：在消费者对指定消息分区进行消息消费的过程中， 需要定时地将分区消息的消费进度Offset记录到Zookeeper上 ，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] 节点内容就是Offset的值。这是kafka0.9和之前版本offset记录的方式，之后的版本offset都改为存在kafka本地，当然了这里的本地是指磁盘不是内存。。。
8）消费者注册：每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。 对 消费者分组 中的 消费者 的变化注册监听 。每个 消费者 都需要关注所属 消费者分组 中其他消费者服务器的变化情况，即对/consumers/[group_id]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。 对Broker服务器变化注册监听 。消费者需要对/broker/ids/[0-N]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。 进行消费者负载均衡 。为了让同一个Topic下不同分区的消息尽量均衡地被多个 消费者 消费而进行 消费者 与 消息 分区分配的过程，通常，对于一个消费者分组，如果组内的消费者服务器发生变更或Broker服务器发生变更，会发出消费者负载均衡。
Ⅲ 服务端技术实战系列——Kafka篇
一．概念&原理
[if !supportLists]1. [endif]主题(topic)：主题是对消息的分类。
[if !supportLists]2. [endif]消息(message)：消息是kafka通信的基本单位。
[if !supportLists]3. [endif]分区(partition)： 一组 消息对应 一个 主题， 一个 主题对应 一个或多个 分区。每个分区为一系列有序消息组成的 有序队列 ；每个分区在物理上对应一个文件夹。
[if !supportLists]4. [endif]副本(replica)：每个分区有 一个或多个 副本，分区的副本分布在集群的 不同 代理（机器）上，以提高可用性；分区的副本与日志对象是一一对应的。
[if !supportLists]5. [endif]Kafka只保证一个 分区内 的消息 有序性 ，不保证跨分区消息的有序性。消息被追加到相应分区中， 顺序写入磁盘 ，效率非常高。
[if !supportLists]6. [endif]Kafka选取某个某个分区的 一个 副本作为leader副本，该分区的 其他 副本为follower副本。 只有leader副本负责处理客户端读/写请求 ，follower副本从leader副本同步数据。
[if !supportLists]7. [endif]任何发布到分区的消息都会追加到日志文件的尾部， 每条消息 在日志文件中的 位置 都对应一个 按序递增的偏移量 ；偏移量在一个分区下严格有序。
[if !supportLists]8. [endif]Kafka不允许对消息进行随机读写。
[if !supportLists]9. [endif]新版消费者将 消费偏移量 保存到kafka内部的一个主题中。
[if !supportLists]10. [endif]Kafka集群由 一个或多个代理 （Broker，也称为kafka实例）构成。可以在 一台 服务器上配置 一个或多个代理 ，每个代理具有唯一标识broker.id。
[if !supportLists]11. [endif]生产者将消息 发送给代理 （Broker）。
[if !supportLists]12. [endif]消费者以 拉取 （pull）方式拉取数据，每个消费者都属于一个消费组。
[if !supportLists]13. [endif]同一个主题的一条消息只能被 同一个消费组 下的某一个消费者消费，但 不同消费组 的消费者可以 同时 消费该消息。
[if !supportLists]14. [endif]消息 广播 ：指定各消费者属于不同消费组；消息 单播 ：指定各消费者属于同一个消费组。
[if !supportLists]15. [endif]Kafka启动时在Zookeeper上创建相应节点来保存 元数据 ，元数据包括：代理节点信息、集群信息、主题信息、分区状态信息、分区副本分配方案、动态配置等；
[if !supportLists]16. [endif]Kafka通过 监听 机制在节点注册监听器来监听节点元数据变化；
[if !supportLists]17. [endif]Kafka将数据写入 磁盘 ，以文件系统来存数据；
[if !supportLists]18. [endif]生产环境一般将zookeeper集群和kafka集群 分机架 部署；
[if !supportLists]二．[endif] Kafka Procer
配置：
/**
* xTestProxy——KafkaConfigConstant
*
* @author ZhangChi
* @date 2018年6月20日---下午5:50:44
* @version 1.0
*/
public class KafkaConfigConstant {
public static final String KAFKA_CLUSTER = "fa-common1.hangzhou-1.kafka.internal.lede.com:9200,fa-common2.hangzhou-1.kafka.internal.lede.com:9200,fa-common3.hangzhou-1.kafka.internal.lede.com:9200";
}
生产者配置：
/**
* xTestProxy——HttpKafkaProcerFactory
*
* @author ZhangChi
* @date 2018年6月11日---下午2:37:51
* @version 1.0
*/
public class HttpKafkaProcerFactory {
// 真正的KafkaProcer仅有一份
private static KafkaProcer kafkaProcer = null ;
private static Properties property ;
public static KafkaProcer getKafkaProcer() {
if ( kafkaProcer == null ) {
synchronized (HttpKafkaProcerFactory. class ) {
if ( kafkaProcer == null ) {
property = buildKafkaProperty ();
kafkaProcer = new KafkaProcer( property );
}
}
}
return kafkaProcer ;
}
public static Properties buildKafkaProperty() {
Properties props = new Properties();
props.put(ProcerConfig. BOOTSTRAP_SERVERS_CONFIG , KafkaConfigConstant. KAFKA_CLUSTER );
props.put(ProcerConfig. ACKS_CONFIG , "all");
props.put(ProcerConfig. RETRIES_CONFIG , 0);
props.put(ProcerConfig. BATCH_SIZE_CONFIG , 16384);
props.put(ProcerConfig. BUFFER_MEMORY_CONFIG , 33554432);
props.put(ProcerConfig. LINGER_MS_CONFIG , 1);
props.put(ProcerConfig. KEY_SERIALIZER_CLASS_CONFIG , "org.apache.kafka.common.serialization.StringSerializer");
props.put(ProcerConfig. VALUE_SERIALIZER_CLASS_CONFIG ,
"org.apache.kafka.common.serialization.StringSerializer");
return props;
}
}
生产者线程组：
/**
* xTestProxy——HttpKafkaProcerThread
* 多线程每次new一个实例
*
* @author ZhangChi
* @date 2018年6月25日---下午2:09:39
* @version 1.0
*/
public class HttpKafkaProcerThread implements Runnable {
private static Logger logger = LoggerFactory. getLogger ("HttpKafkaProcerThread");
private final String KAFKA_TOPIC = KafkaConstant. HTTP_REQ_RESP_TOPIC ;
private String kafkaMessageJson;
private KafkaProcer procer;
public String messageType;
public String originalMessage;
private static KafkaMessage kafkaMessage = new KafkaMessage();
public HttpKafkaProcerThread(KafkaProcer procer, String messageType, String originalMessage) {
this .procer = procer;
this .messageType = messageType;
this .originalMessage = originalMessage;
}
@Override
public void run() {
// TODO Auto-generated method stub
/* 1.构建kafka消息*/
kafkaMessageJson = generateKafkaMessage( this .messageType, this .originalMessage);
/* 2.发送kafka消息*/
if (kafkaMessageJson != null && !StringUtils. isEmpty (kafkaMessageJson)) {
logger .info("create message start:" + kafkaMessageJson);
procer.send( new ProcerRecord( this .KAFKA_TOPIC, kafkaMessageJson));
} else {
logger .info("kafkaMessageJson is null!");
}
}
private String generateKafkaMessage(String messageType, String originalMessage) {
if (StringUtils. isBlank (messageType) || StringUtils. isBlank (originalMessage)) {
return null ;
}
kafkaMessage .setMessageId(KafkaMessageUtils. generateId ());
kafkaMessage .setMessageTime(KafkaMessageUtils. generateTime ());
kafkaMessage .setMessageType(messageType);
kafkaMessage .setMessage(originalMessage);
String kafkaMessageToJson = null ;
try {
kafkaMessageToJson = KafkaMessageUtils. objectToJson ( kafkaMessage );
} catch (JsonProcessingException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
kafkaMessageJson = kafkaMessageToJson;
return kafkaMessageToJson;
}
}
[if !supportLists]三．[endif] Kafka Consumer
消费者配置：
private static Properties buildKafkaProperty() {
Properties properties = new Properties();
// 测试环境kafka的端口号是9200
properties.put(ConsumerConfig. BOOTSTRAP_SERVERS_CONFIG , KafkaConfigConstant. KAFKA_CLUSTER );
// 消费组名称
properties.put(ConsumerConfig. GROUP_ID_CONFIG , KafkaConfigConstant. GROUP_ID );
properties.put(ConsumerConfig. CLIENT_ID_CONFIG , "test");
// 从头消费
properties.put(ConsumerConfig. AUTO_OFFSET_RESET_CONFIG , "earliest");
// 自动提交偏移量
properties.put(ConsumerConfig. ENABLE_AUTO_COMMIT_CONFIG , "true");
// 时间间隔1s
properties.put(ConsumerConfig. AUTO_COMMIT_INTERVAL_MS_CONFIG , "1000");
properties.put(ConsumerConfig. KEY_DESERIALIZER_CLASS_CONFIG ,
"org.apache.kafka.common.serialization.StringDeserializer");
properties.put(ConsumerConfig. VALUE_DESERIALIZER_CLASS_CONFIG ,
"org.apache.kafka.common.serialization.StringDeserializer");
return properties;
}
消费者线程组：
/**
* AnalysisEngine——HttpKafkaConsumerGroup
*
* @author ZhangChi
* @date 2018年6月11日---下午6:20:47
* @version 1.0
*/
@Service("httpKafkaConsumerGroup")
public class HttpKafkaConsumerGroup {
@Autowired
private RequestAnalyzer requestAnalyzer;
@Autowired
private EsDocumentServiceImpl esDocumentServiceImpl;
@Autowired
private AnalysisEngineClient analysisEngineClient;
@Autowired
private MongoTemplate mongoTemplate;
private List httpKafkaConsumerList = new ArrayList();
public void initHttpKafkaConsumerGroup( int consumerNumber, RunModeEnum mode) {
for ( int i = 0; i < consumerNumber; i++) {
/**
* 将注入的服务当做构造参数，这样保证每个子线程都能拿到服务实例而不是空指针！
*/
HttpKafkaConsumer consumerThread = new HttpKafkaConsumer(requestAnalyzer, esDocumentServiceImpl, mode, analysisEngineClient, mongoTemplate);
httpKafkaConsumerList.add(consumerThread);
}
}
public void consumeGroupStart() {
for (HttpKafkaConsumer item : httpKafkaConsumerList) {
LogConstant. runLog .info("httpKafkaConsumerList size : " + httpKafkaConsumerList.size());
Thread consumerThread = new Thread(item);
consumerThread.start();
}
}
}
先逐个初始化消费者实例，然后将这些消费者加入到消费组列表中。消费组启动后，会循环产生消费者线程。
Ⅳ Kafka相关内容总结（Kafka集群搭建手记）
Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类，发送消息者成为Procer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是procer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。
入门请参照： https://www.ibm.com/developerworks/cn/opensource/os-cn-kafka/index.html
在此不再赘述。
这部分不是本文的重点，但是kafka需要用到kafka集群，所以先搭建kafka集群。
从kafka官方文档看到，kafka似乎在未来的版本希望抛弃zookeep集群，自己维护集群的一致性，拭目以待吧。
我们搭建集群使用的是三台同机房的机器，因为zookeeper不怎么占资源也不怎么占空间（我们的业务目前比较简单），所以三台机器上都搭建了zookeeper集群。
搭建zookeeper集群没什么难度，参考文档： http://www.cnblogs.com/huangxincheng/p/5654170.html
下面列一下我的配置并解析：
一共用三台物理机器，搭建一个Kafka集群。
每台服务器的硬盘划分都是一样的，每个独立的物理磁盘挂在一个单独的分区里面，这样很方便用于Kafka多个partition的数据读写与冗余。
/data1比较小，为了不成为集群的瓶颈，所以/data1用于存放kafka以及Zookeeper
每台机器的磁盘分布如下：
下面是kafka的简单配置，三台服务器都一样，如有不一致的在下文有说明。
kafka安装在目录/usr/local/kafka/下，下面的说明以10.1.xxx.57为例。
最重要的配置文件server.properties，需要配置的信息如下：
从上面的配置看到，kafka集群不需要像hadoop集群那样，配置ssh通讯，而且一个kafka服务器（官方文档称之为broker，下面统一使用这个称呼）并不知道其他的kafka服务器的存在，因此你需要逐个broker去启动kafka。各个broker根据自己的配置，会自动去配置文件上的zk服务器报到，这就是一个有zk服务器粘合起来的kafka集群。
我写了一个启动脚本，放在 /usr/local/kafka/bin 下面。启动脚本每个broker都一样：
如同kafka集群里面每一个broker都需要单独启动一样，kafka集群里面每一个broker都需要单独关闭。
官方给出的关闭脚本是单独运行 bin/kafka-server-stop.sh
但是我运行的结果是无法关闭。打开脚本一看，才发现是最简单的办法，发一个TERM信号到kafka的java进程，官方脚本给出的grep有点问题。
发信号之后，一直tail着kafka日志，看到正常关闭。
指定zookeeper服务器，topic名称是LvsKafka（注意topic名称不能有英文句号(.)和下划线(_)，否则会通不过，理由是名称会冲突，下文对此略有解析）
replication-factor指出重复因子是2，也就是每条数据有两个拷贝，可靠性考虑。
partitions 指出需要多少个partition，数据量大的多一点，无论生产和消费，这是负载均衡和高并发的需要。
可以看到刚才新建的24个partition，比如partition 5， 他的leader是broker 59，也就是10.1.xxx.59这台机器。
建立topic时我们指出需要2个拷贝，从上面的输出的Replicas字段看到，这两个拷贝放在59,58两个机器，也就是10.1.xxx.59和10.1.xxx.58.
Isr表示当前partition的所有拷贝所在的机器中，哪些是还活着（可以提供服务）的。现在是59和58都还存活。
这个命令另外还会看到一些类似于下面的内容：
__consumer_offsets到底是什么呢？其实就是客户端的消费进度，客户端会定时上报到kafka集群，而kafka集群会把每个客户端的消费进度放入一个自己内部的topic中，这个topic就是__consumer_offsets。我查看过__consumer_offsets的内容，其实就是每个客户端的消费进度作为一条消息，放入__consumer_offsets这个topic中。
这里给了我们两个提示：
1、kafka自己管理客户端的消费进度，而不是依靠zk，这就是kafka官方文档说的kafka未来会抛弃zk的底气之一；
2、留意到这个kafka自己的topic是带下划线的，也就是，kafka担心我们自己建的topic如果带下划线的话会跟这些内部自用的topic冲突；
Ⅳ windows 下远程连接kafka服务器并创建topic 部署服务
一.打包项目镜像:
利用Dockerfile 来打包项目的镜像
本次项目共依赖两个镜像(一个基础系统环境和一个项目镜像)
本次直接将Dockerfile写好后,用shell脚本build.sh启动打包:
然后切换到项目的目录下找到build.sh,运行即可打包项目镜像
若
报错:"failed to dial gRPC: cannot connect to the Docker daemon. Is 'docker daemon' running on this host?: dial unix /var/run/docker.sock: connect: permission denied
"
就用
出现以下说明打包成功,接下来可以开始部署:
https://jingyan..com/article/9113f81b49ed2f2b3214c7fa.html
注意:如果遇到只读权限不能修改时,将host文件复制一份到桌面,修改后在替换原来的host文件
在hosts文件末尾加上kafka服务器< !外网! 39. 0.25...>地址,修改后的格式如下:
1.1注意: 修改阿里云服务器的hosts 文件来配置 kafka的服务器地址:
在hosts 文件最后加入:
添加的 kafka-server 就是以下创建topic命令中的 kafka-server别名,
监听远程kafka:新建消费者:
远程创建topic的实例:
查看远程已创建的topc:
本地:
远程修改后的kafka topic:
2.通过git Bash 切换到kafka客户端的bin目录:
桌面打开 gitBash,切换到本地kafka软件目录:
这里一定要切换为windows
3.查看已经有的topic
--topic 指定topic名字
--replication-factor 指定副本数，因为我的是集群环境，这里副本数就为3
--partitions 指定分区数，这个参数需要根据broker数和数据量决定，正常情况下，每个broker上两个partition最好
注意:服务器部署时候一定要用内网172. .开头的,外部访问设为外网ip
不然会导致Kafka写入数据的时候报错 : TImeout
4.1本地docker创建topic：
4.2 本地windows 创建topic
进入本地软件路径KAFKA/BIN/WIONDOWS
创建topic
5.修改服务器的host:
一定要注意加sudo 不然会导致readonly 无法修改
在host 文件的末尾加上以下:
6.切换到工程部署的目录
7.清理redis,不然数据有残留:
7.1服务器上的redis挂载清除:
在 docker-compose.yml中注销这几行: 目的是每次启动不必记录上次没有执行完的数据.
这个是用来记录redis中假如上次指定的是1到100万块,没有执行完.下次接着执行没执行完的任务,测试时暂时关闭
7.2删除volume:
7.3 如果volume文件被占用时,先删除占用容器:
7.4 清除redis中的数据
进入redis容器中：
8.部署命令:
8.1开启docker可视化web上监控docker:
然后访问: http://39.100.48.41:9000
宿主机IP + 9000端口
8.2执行部署命令,启动服务:
9.部署时报错: yaml: line 46: did not find expected key
原因: docker-compose.yml文件中第46行 报错
解决:将所有数据对齐,不要有多余的空格.
Ⅵ arm架构服务器kafka安装
主要操作在主机vcapp250上进行
编辑config/zookeeper.properties
编辑config/server.properties
编辑bin/kafka-run-class.sh
将安装目录拷贝到剩余主机的对应目录中
启动zookeeper
启动kafka
Ⅶ Kafka Connect的安装和配置
在使用Kafka Connect时，需要注意一些事项，以帮助你构建适应长期需求的datapipeline。本章旨在提供有关的一些上下文。
要开始使用Kafka Connect，只有一个硬性的先决条件：一个Kafka的broker集群。然而，随着集群增长，有几个问题需要提前考虑：
在开始之前，确定哪种模式最适合您的环境非常有用。 对于适合单个代理的环境（例如从web服务器向Kafka发送日志），standalone模式非常适合。在单个source或sink可能需要大量数据的用例中（例如，将数据从Kafka发送到HDFS），分布式模式在可伸缩性方面更加灵活，并提供了高可用性服务，从而最小化停机时间。
Kafka Connect插件是一组jar文件，Kafka Connect可以在其中找到一个或多个connector、transform、以及converter的实现。Kafka Connect将每个插件彼此隔离，这样一个插件中的库就不会受到其他插件库的影响，这点非常重要。
Kafka Connect plugin是：
（1）在一个uber jar文件中包含插件及所有第三方依赖；或
（2）一个包含jar包和第三方依赖的目录。
Kafka Connect使用plugin path找到插件，这是Kafka Connect在worker配置文件中定义的一个以逗号分隔的目录列表。要安装插件，请将目录或uber jar放在plugin path路径中列出的目录中。
举个例子 ，我们在每台机器上创建一个/usr/local/share/kafka/plugins目录，然后将我们所有的插件jar或插件目录放入其中。然后在worker的配置文件中加入如下配置项：
现在，当我们启动worker时，Kafka Connect可以发现这些插件中定义的所有connector、transform以及converter。Kafka Connect显式地避免了其他插件中的库， 并防止了冲突。
如果要在同一个机器上运行多个standalone实例，有一些参数需要是独一无二的：
（1）offset.storage.file.filename：connector偏移量的存储。
（2）rest.port：用于监听http请求的rest接口所占用的端口。
connector和task的配置，offsets和状态会存储在Kafka的内部主题中，Kafka Connect会自动创建这些主题，且所有topic都使用了压缩清理策略。
如果要手动创建这些topic，推荐使用如下命令：
这里只列出一些有疑问的。
配置了group.id的worker会自动发现彼此并形成集群。一个集群中的所有worker必须使用相同的三个Kafka topic来共享配置、偏移量以及状态，所有worker必须配置相同的config.storage.topic、offset.storage.topic以及status.storage.topic。
每个converter实现类都有自己的相关配置需求。下面的例子展示了一个worker属性文件，其中使用的AvroConverter需要将Schema Registry的url作为属性进行传递。
注意： 除了其配置覆盖这些配置的connector，worker上运行的所有connector都使用这些converter。