Kafka

日常开发中，置信大家都对 Kafka 有所耳闻，Kafka 作为一个分布式的流解决平台，个别用来存储和传输大量的音讯数据。在 Kafka 中有三个重要概念，别离是 topic、partition 和 offset。 topic 是 kafka 中的音讯以主题为单位进行归类的逻辑概念，生产者负责将音讯发送到特定的主题，消费者负责订阅主题并进行生产。partition 是 topic 的物理概念，每个 topic 能够细分为多个 partition，每个 partition 只属于单个 topic，并且蕴含不同的音讯，partition 用于进步 topic 的存储和生产的性能和可扩展性，能够将 topic 扩散在多个 broker 上，并反对多个 consumer 并行生产。offset 是 partition 中每条音讯的惟一标识，是一个枯燥递增且不变的值，由 kafka 主动保护，offset 用于定位和记录音讯在 partition 中的地位和生产进度，保障 partition 内的音讯有序。本文将给大家介绍 offset 的相干概念，纲要如下： offset 的作用和意义offset 的存储和治理offset 的提交和重置offset 的生产和保障offset 的作用和意义 offset 是 Kafka 为每条音讯调配的一个惟一的编号，它示意音讯在分区中的程序地位。offset 是从 0 开始的，每当有新的音讯写入分区时，offset 就会加 1。offset 是不可变的，即便音讯被删除或过期，offset 也不会扭转或重用。 offset 的作用次要有两个： 一是用来定位音讯。通过指定 offset，消费者能够精确地找到分区中的某条音讯，或者从某个地位开始生产音讯。二是用来记录生产进度。消费者在生产完一条音讯后，须要提交 offset 来通知 Kafka broker 本人生产到哪里了。这样，如果消费者产生故障或重启，它能够依据保留的 offset 来复原生产状态。offset 的存储和治理offset 的存储和治理次要波及到两个方面：生产者端和消费者端。 ...

一、什么是KafkaMQ音讯队列作为最罕用的中间件之一，其次要个性有：解耦、异步、限流/削峰。 Kafka 和传统的音讯零碎(也称作消息中间件)都具备零碎解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等性能。与此同时，Kafka 还提供了大多数音讯零碎难以实现的音讯程序性保障及回溯生产的性能。 二、Kafka罕用概念2.1 Topic与PartitionTopic（主题）是一个逻辑概念，在物理上并不存储。次要用于形容一个类型的音讯。例如咱们有一个业务零碎会发送一个形容用户订单状态的音讯，那么这一个类型外面所有的音讯就是一个Topic，又比方这个业务零碎同时还会发送形容会员余额的音讯，那么这个就是一个新的音讯类型，也就是一个新的Topic。 **Partition（分区）**是一个物理概念，是理论存在于物理设施上的。一个Topic由多个Partition独特组成。Partition的存在是为了进步音讯的性能与吞吐量，多个分区多个过程音讯处理速度必定要比单分区快的多。 2.2 Broker与PartitionBroker作为分布式的实现，其实能够间接简略了解为一个Kafka过程就是一个Broker。 咱们之前提到Partition是物理存在的，其物理的存在的地位就在Broker中。同时，为了服务具备肯定的可靠性，每一个分区都有几个正本，每个正本存在于不同的Broker中。 咱们之前提到的Topic是逻辑概念即在于此，并没有物理存在，图中每个TopicA-x都是一个Partition，其中前面的数字代表了一个分区中的第几个正本，每个Broker中都有不同的正本，目标就是当有Broker宕机时，其余的正本还存在保证系统的可用性。 此外，多个正本Partition中会选取一个作为leader，其余的作为follower。咱们的生产者在发送数据的时候，是间接发送到leader partition外面，而后follower partition会去leader那里自行同步数据，消费者生产数据的时候，也是从leader那去生产数据的。 正本处于不同的 broker 中，当 leader 正本呈现故障时，从 follower 正本中从新选举新的 leader 正本对外提供服务。Kafka 通过多正本机制实现了故障的主动转移，当 Kafka 集群中某个 broker 生效时依然能保障服务可用。 2.3 生产者消费者与ZooKeeper产生音讯的角色或零碎称之为生产者，例如上述某个业务零碎产生了对于订单状态的相干音讯，那么该业务零碎即为生产者。 消费者则是负责接管或者应用音讯的角色或零碎。 ZooKeeper 是 Kafka 用来负责集群元数据的治理、控制器 的选举等操作的。Producer 将音讯发送到 Broker，Broker 负责将收到的音讯存储到磁盘中，而 Consumer 负责从 Broker 订阅并生产音讯。 在每一个Broker在启动时都会像向ZK注册信息，ZK会选取一个最早注册的Broker作为Controller，前面Controller会与ZK进行数据交互获取元数据（即整个Kafka集群的信息，例如有那些Broker,每个Broker中有那些Partition等信息），而后其余Broker再与Controller交互进而所有的Broker都能感知到整个集群的所有信息. 2.4 消费者组目前大部分业务零碎架构都是分布式的，即一个利用会部署多个节点。失常来说，一条音讯只应该被其中某一个节点生产掉，而不应该是所有被所有的消费者同时生产一遍。因而就产生了消费者组的概念，在一个消费者组中，一条音讯只会被消费者组中的一个消费者所生产。 从应用上来说，个别配置为一个利用为一个消费者组，或一个利用中不同的环境也能够配置不必的消费者组。例如生产环境的节点与预发环境的节点能够配置两套消费者组，这样在有新的改变部署在预发时，即时本次改变批改了生产动作的相干逻辑，也不会影响生产的数据。 消费者与生产组这种模型能够让整体的生产能力具备横向伸缩性，咱们能够减少(或缩小) 消费者的个数来进步(或升高)整体的生产能力。对于分区数固定的状况，一味地减少消费者 并不会让生产能力始终失去晋升，如果消费者过多，呈现了消费者的个数大于分区个数的状况， 就会有消费者调配不到任何分区。参考下图（右下），一共有 8 个消费者，7 个分区，那么最初的生产 者 C7 因为调配不到任何分区而无奈生产任何音讯。 2.5 ISR、HW、LEOKafka通过ISR机制尽量保障音讯不会失落。 一个Partition中所有正本称为AR(Assigned Replicas)，所有与 leader 正本放弃肯定水平同步的正本(包含 leader 正本在内)组成 **ISR (In-Sync Replicas)。**咱们上文提到，follower 正本只负责音讯的同步，很多时候 follower 正本中的音讯绝对 leader 正本而言会有肯定的滞后，而及时与leader正本保持数据统一的就能够成为ISR成员。与 leader 正本同步滞后过多的正本(不包含 leader 正本)组成OSR (Out-of-Sync Replicas)，由此可见，AR=ISR+OSR。 在失常状况下，所有的 follower 正本都应该与 leader 正本放弃肯定水平的同步，即 AR=ISR， OSR 汇合为空。 ...

kafka 为什么这么快批量解决0拷贝技术程序写

次要从三方面来介绍，音讯发送端保证数据不失落，kafka服务保障音讯不失落，消费者保障音讯不失落。 基础知识kafka 能够保障分区音讯的程序，同一个分区，先发送到kafka分区的音讯，会被先生产掉。kafka 是通过一个集群对外提供服务，只有是集群中多个正本中有一个正本是沉闷的，那么收到的音讯就不会失落。kafka集群保证数据不失落先思考一个问题：kafka集群什么时候会失落音讯? 这就要从kafka的复制机制开始讲了。 kafka每个topic有多个分区，分区存储在磁盘上，kafka能够保障分区的数据是有序的，每个分区能够有多个正本。 正本依照是否是领袖，能够分为领袖正本和跟随者正本（这里对应的就是kafka集群中的leader和follower）。 所有的音讯都是发送给leader的，音讯生产也是从leader获取的。领袖正本第一工夫收到音讯，或者生产音讯，他肯定是同步正本。 其余follower都是和leader放弃通信，同步leader的音讯。当leader不可用时，会选举一个follower会变成leader。 对于一个主一个从的两个kafka，做的集群来说。 （此时的kafka复制系数是2. 对应的配置参数是replication,factor） 一个是leader正本，一个是follower正本。当follower正本始终能与leader正本放弃同步的时候 follower正本是 同步正本， 当follower与leader无奈放弃同步的时候 follower正本则变成非同步正本。 如果leader宕机，这时候零碎须要选举一个follower来作为领袖，kafka优先选择同步正本作为领袖，当零碎没有同步正本的时候。 kafka如果抉择非同步正本作为领袖，则会失落一部分数据，（这一部分数据就是非同步正本无奈及时从领袖正本更新的音讯）。 kafka如果不抉择非同步正本作为领袖，则此时kafka集群不可用。 kafka 抉择非同步正本作为领袖正本的行为叫做，不齐全领袖选举。如何管制kafka在leader宕机时，同步正本不可用时，是否抉择非同步 作为领袖？通过kafka的另外一个参数来管制的 ： unclean.leader.election. 如果是true 则会产生不齐全领袖选举。 正本数倡议3个就能够，多的话须要更多的磁盘，unclean.leader.election倡议false. 对于两个kafka做的集群来说，必定是不平安的。那么三个节点的kafka平安吗？ 答案是 也不肯定平安 因为即便三个正本，也有可能是两个从都是非同步正本，此时主宕机，从要么不可用（影响高可用），要么成为主（数据失落）。 这里就须要保障kafka零碎中至多有两个同步正本。一个必定是领袖正本，另外一个是从的正本。 此时须要kafka的另外一个参数 最小同步正本数 min,insync.replicas 只有保障kafka收到生产者的音讯之后，至多有 “最小同步正本数“ 的正本收到音讯，能力保障在主宕机时音讯不失落。 这个参数的意思是 kafka收到生产者音讯之后，至多几个同步正本，同步之后，才给客户端音讯确认。 数量多能保障高可用，然而就义效率。 kafka 如何判断一个follower正本是不是同步正本？满足两个条件 在过来10秒内从领袖获取过音讯，并且是最新消息。过来6秒内 和 zk间接发送过心跳。疑难：如果kafka 长时间未收到音讯，第一条如何满足？ 音讯发送者正确的发送姿态音讯怎么才算是产生胜利？音讯的生产者向kafka集群发送音讯，须要期待kafka集群确认，这里波及到一个参数 acks 他的值有三个 0, 1, all 如果是0 ，那么代表发送过来，不期待kafka音讯确认，认为胜利肯定会失落音讯，可能kafka集群正在选举，此时就无奈收到任何异样。 如果是1，那么代表发送过来，期待领袖正本确认音讯，认为胜利领袖必定收到了音讯，写入了分区文件（不肯定落盘）。 如果是all, 那么代表发送过来之后，音讯被写入所有同步正本之后 ，认为胜利。留神这里是 所有同步正本，不是所有正本。 具体是多少同步正本，还要取决于kafka集群设置的最小同步正本数，和集群以后的同步正本数。 抉择这种配置，会牢靠，然而就义效率，能够通过，增大批和应用异步模式，提高效率。 如果音讯产生异样怎么办？重试吗？哪些异样须要重试？网络异样和集群无主，或者正在选举的异样是能够重试的。 哪些不须要重试？配置异样。 其余异样怎么办？序列化异样，内存溢出，栈溢出等。 重要的配置参数如果网络异样收不到响应，则期待，这里有个配置等待时间 request.timeout.ms 发送音讯等待时间。 ...

Kafka是一个分布式、分区的、多正本的、多订阅者，基于zookeeper协调的分布式音讯零碎。kafka 实现高吞吐量和性能，次要通过以下几点： 磁盘程序读写，保障了音讯的沉积程序读写，磁盘会预读，预读即在读取的起始地址间断读取多个页面，次要工夫破费在了传输工夫，而这个工夫两种读写能够认为是一样的。随机读写，因为数据没有在一起，将预读节约掉了。须要屡次寻道和旋转提早。而这个工夫可能是传输工夫的好多倍。零拷贝linux操作系统 “零拷贝” 机制应用了sendfile办法， 容许操作系统将数据从Page Cache 间接发送到网络，只须要最初一步的copy操作将数据复制到 NIC 缓冲区， 这样防止从新复制数据 。示意图如下： 大家应该都晓得，从 Kafka 里常常要生产数据，那么生产的时候实际上就是要从 kafka 的磁盘文件里读取某条数据而后发送给上游的消费者，那么这里如果频繁的从磁盘读数据而后发给消费者，会减少两次没必要的拷贝。 一次是从操作系统的 cache 里拷贝到利用过程的缓存里，接着又从应用程序缓存里拷贝回操作系统的 Socket 缓存里。 而且为了进行这两次拷贝，两头还产生了好几次上下文切换，一会儿是应用程序在执行，一会儿上下文切换到操作系统来执行。所以这种形式来读取数据是比拟耗费性能的。 Kafka 为了解决这个问题，在读数据的时候是引入零拷贝技术。 也就是说，间接让操作系统的 cache 中的数据发送到网卡后传输给上游的消费者，两头跳过了两次拷贝数据的步骤，Socket 缓存中仅仅会拷贝一个描述符过来，不会拷贝数据到 Socket 缓存 通过 零拷贝技术，就不须要把 os cache 里的数据拷贝到利用缓存，再从利用缓存拷贝到 Socket 缓存了，两次拷贝都省略了，所以叫做零拷贝。 对 Socket 缓存仅仅就是拷贝数据的描述符过来，而后数据就间接从 os cache 中发送到网卡下来了，这个过程大大的晋升了数据生产时读取文件数据的性能。 Kafka 从磁盘读数据的时候，会先看看 os cache 内存中是否有，如果有的话，其实读数据都是间接读内存的。 kafka 集群通过良好的调优，数据间接写入 os cache 中，而后读数据的时候也是从 os cache 中读。相当于 Kafka 齐全基于内存提供数据的写和读了，所以这个整体性能会极其的高。 页缓存技术Kafka是基于 操作系统 的页缓存来实现文件写入的。 操作系统自身有一层缓存，叫做 page cache，是在内存里的缓存，咱们也能够称之为 os cache，意思就是操作系统本人治理的缓存。 间接操作page cache，而不是JVM，防止GC耗时及对象创立耗时，且读写速度更高，过程重启、缓存也不会失落。 ...

背景在应用 Kafka 音讯队列时，申请 Kafka 资源波及 Topic 名称、分区数、ClientId 等参数。ClientId 在 Kafka 中次要用于标识和治理客户端应用程序，以及为监控、日志记录和资源管理提供反对。通过为每个客户端调配惟一的 ClientId，你能够更好地跟踪和治理 Kafka 集群中的各个客户端连贯。然而在某些公司，ClientId 是用于鉴权和限流的，因而在应用 Kafka 时须要确保 ClientId 与申请 Topic 时的 ClientId 保持一致。这与个别的 Kafka 应用形式有所不同。在应用 spring-kafka 包和原生 kafka-clients 包的多线程环境下，固定的 ClientId 并不能满足需要，须要重写 spring-kafka 包的 ProducerFactory 和 ConsumerFactory，或者申请多个 ClientId。本文将探讨在应用 Kafka 时遇到的对于 ClientId 的问题以及倡议的解决办法。 过程大多数 Java 应用程序都集成了 Spring 框架，因而咱们能够基于 Spring 定义生产者和消费者。 生产者@Configurationpublic class KafkaProducerConfig { @Bean public ProducerFactory<String, Object> producerFactory() { Map<String, Object> configProps = new HashMap<>(); configProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); configProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); configProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); configProps.put(ProducerConfig.CLIENT_ID_CONFIG, "your-client-id"); return new DefaultKafkaProducerFactory<>(configProps); } @Bean public KafkaTemplate<String, Object> kafkaTemplate() { return new KafkaTemplate<>(producerFactory()); }}在须要发送音讯的中央，咱们注入 KafkaTemplate： ...

1. rebalance的定义再均衡：Reblance是一种协定，规定了一个Consumer Group下所有Consumer如何达成统一，来调配订阅Topic的每个分区，尽量让每个消费者调配到绝对平均的分区，使Consumer的资源都能失去充分利用，避免有的Consumer比较忙，有的Consumer比拟闲。 2.Reblance触发的机会当kafka感知到存在让分区和消费者调配不平均的事件产生时，就会触发Reblance 消费者组生产的分区个数发生变化。消费者组生产的主题个数发生变化。消费者组内的消费者个数发生变化。3.分区调配的策略1.Range调配策略是指依照分区号的范畴进行分区调配。kafka 默认应用 RangeAssignor。 2.RoundRobin调配策略是指轮询每个分区，将分区一一调配给消费者 3.StickyAssignor分区策略，又称为粘性调配，所谓的有粘性，是指每次 Rebalance 时，该策略会尽可能地保留之前的调配计划，尽量实现分区调配的最小变动，消费者连贯这些分区所在 Broker 的 TCP 连贯就能够持续应用。 协调者(Coordinator)是broker过程中的一个组件，每一个broker都会有一个Coordinator，协调者的职责在于：服务ConsumerGroup，实现整个Reblance的过程，提供Consumer Group位移的治理，以及组内成员的治理。消费者会定时向协调者发送心跳，当协调者发现某个消费者长时间没有发送心跳，那么协调者就会认为这个消费者挂了，把这个消费者从消费者组中剔除进来，而后在其余Consumer的心跳申请中回复 reblance_need,让每个消费者进行音讯生产，并开启Reblance。当各个消费者收到reblance_need响应后，都会进行音讯生产，并向协调者发送 SyncGroup申请，来询问调配给本人的分区信息 4.Reblance产生的影响1.影响生产效率因为产生Reblance时，所有消费者都会进行生产，比拟影响音讯生产效率 2.可能会产生音讯反复生产 5.缩小Reblance1.session.timeout.ms（查看整个消费者死亡超时工夫，默认10s） session.timeout.ms >= 3 * heartbeat.interval.ms（心跳查看超时工夫） 2.max.poll.interval.ms(消费者每次去kafka拉取数据最大距离) 在业务中，该参数能够设置的长一些，默认5分钟。

ISR 概念首先ISR的全称为 In-Sync Replicas (同步正本集), 能够了解为与leader放弃同步的所有正本的汇合（蕴含 Leader 自身）。一个分区的所有正本汇合叫做AR (Assigned Repllicas)，与leader-replica未能放弃同步的正本集叫做OSR (Out-Sync Relipcas)。 ISR动静保护了一个和leader正本放弃同步的正本汇合，ISR中的正本全副都和leader的数据放弃同步。 为什么要设计 ISR 机制ISR 机制通过正本冗余机制，提供了 Kafka 音讯的高可靠性。ISR 机制能够做到故障转移，保障服务的可用性。ISR 均衡了主从架构下，复制计划的抉择（同步 / 异步 / 多数遵从少数），让使用者依据参数自行抉择。在一些中间件中，都有正本的概念，在不同的场景下写入数据时，要求写入正本的个数也不尽相同。 例如 zk 中要求写入的节点个数大于一半才算胜利，或者有些要求高可靠性的场景，规定写入所有正本能力算胜利。 而 kafka 的 ISR 能够容许生产音讯时，依据本人的业务场景自行配置想要达到的成果： acks=0：fire and forget，也就是我发了就算完了，后续成不胜利我都不论，这种设置下音讯的高可靠性简直没有保障，然而有极大的吞吐量。 acks=1：写入主节点就算胜利，这种设置，能够保障肯定的高可靠性，也具备不错的吞吐量。 acks=all：也就是写入 ISR 中所有的正本才算胜利，这种设置下，就能提供较高的高可靠性，然而吞吐量就绝对较低。 咱们在思考生产音讯时，ISR 机制能够敌对的让使用者依据本人的业务需要去设置参数，去抉择本人想要达到什么水平的可靠性，而不是只提供一种可靠性抉择。 【什么是生效正本？】 性能生效：节点宕机，在该节点上的正本都属于性能生效正本。 同步生效：follower 正本所在的 broker 因为带宽或者负载等因素无奈及时实现同步，导致被踢出 ISR。 ISR 伸缩控制参数在Kafka 0.9x 版本之前，有一个控制参数：replica.lag.max.messages 默认值为 4000，示意如果 follower 的音讯个数落后 leader 个数 4000，那么就会被踢出 ISR 列表；然而这个参数在不同场景下，很难给出一个正当的值。如果设置的很大，那么这个参数也就失去了意义，因为 ISR 列表都不会变动。如果设置的很小，那么在高吞吐的场景下，又会造成 ISR 列表的频繁变动。 因而从Kafka 0.9x 版本开始，移除了该参数。当初用来管制的参数是：replica.log.time.max.ms。 默认值是 10000ms，即 10 秒；也就是说 follower 在 10s 内都没能追上 Leader 的 LEO，就会被踢出 ISR。 ...

1 前言置信各位小伙伴之前或多或少接触过音讯队列，比拟出名的蕴含Rocket MQ和Kafka，在京东外部应用的是自研的消息中间件JMQ，从JMQ2降级到JMQ4的也是带来了性能上的显著晋升，并且JMQ4的底层也是参考Kafka去做的设计。在这里我会给大家展现Kafka它的高性能是如何设计的，大家也能够学习相干方法论将其利用在理论我的项目中，兴许下一个顶级我的项目就在各位的代码中产生了。 2 如何了解高性能设计2.1 高性能设计的”秘籍”先抛开kafka，咱们先来议论一下高性能设计的实质，在这里借用一下网上的一张总结高性能的思维导图： 从中能够看到，高性能设计的伎俩还是十分多，从”宏观设计”上的无锁化、序列化，到”宏观设计”上的缓存、存储等，能够说是形形色色，令人目迷五色。然而在我看来实质就两点：计算和IO。上面将从这两点来浅析一下我认为的高性能的”道”。 2.2 高性能设计的”道法”2.2.1 计算上的”道”计算上的优化伎俩无外乎两种形式：1.缩小计算量 2.放慢单位工夫的计算量 缩小计算量：比方用索引来取代全局扫描、用同步代替异步、通过限流来缩小申请处理量、采纳更高效的数据结构和算法等。(举例：mysql的BTree，redis的跳表等)放慢单位工夫的计算量：能够利用CPU多核的个性，比方用多线程代替单线程、用集群代替单机等。(举例：多线程编程、分治计算等)2.2.2 IO上的”道”IO上的优化伎俩也能够从两个方面来体现：1.缩小IO次数或者IO数据量 2.放慢IO速度 缩小IO次数或者IO数据量：比方借助零碎缓存或者内部缓存、通过零拷贝技术缩小 IO 复制次数、批量读写、数据压缩等。放慢IO速度：比方用磁盘程序写代替随机写、用 NIO 代替 BIO、用性能更好的 SSD 代替机械硬盘等。3 kafka高性能设计了解了高性能设计的伎俩和实质之后，咱们再来看看kafka外面应用到的性能优化办法。各类消息中间件的实质都是一个生产者-消费者模型，生产者发送音讯给服务端进行暂存，消费者从服务端获取音讯进行生产。也就是说kafka分为三个局部：生产者-服务端-消费者，咱们能够依照这三个来别离演绎一下其对于性能优化的伎俩，这些伎俩也会涵盖在咱们之前梳理的脑图外面。 3.1 生产者的高性能设计3.1.1 批量发送音讯之前在下面说过，高性能的”道”在于计算和IO上，咱们先来看看在IO上kafka是如何做设计的。 IO上的优化 kafka是一个消息中间件，数据的载体就是音讯，如何将音讯高效的进行传递和长久化是kafka高性能设计的一个重点。基于此剖析kafka必定是IO密集型利用，producer须要通过网络IO将消息传递给broker，broker须要通过磁盘IO将音讯长久化，consumer须要通过网络IO将音讯从broker上拉取生产。 网络IO上的优化：producer->broker发送音讯不是一条一条发送的，kafka模式会有个音讯发送提早机制，会将一批音讯进行聚合，一口气打包发送给broker，这样就胜利缩小了IO的次数。除了传输音讯自身以外，还要传输十分多的网络协议自身的一些内容（称为Overhead），所以将多条音讯合并到一起传输，可无效缩小网络传输的Overhead，进而进步了传输效率。磁盘IO上的优化：大家晓得磁盘和内存的存储速度是不同的，在磁盘上操作的速度是远低于内存，然而在老本上内存是高于磁盘。kafka是面向大数据量的消息中间件，也就是说须要将大批量的数据长久化，这些数据放在内存上也是不事实。那kafka是怎么在磁盘IO上进行优化的呢？在这里我先间接给出办法，具体细节在后文中解释（它是借助于一种磁盘程序写的机制来晋升写入速度）。3.1.2 负载平衡1.kafka负载平衡设计 Kafka有主题（Topic）概念，他是承载实在数据的逻辑容器，主题之下还分为若干个分区，Kafka音讯组织形式实际上是三级构造：主题-分区-音讯。主题下的每条音讯只会在某一个分区中，而不会在多个分区中被保留多份。 Kafka这样设计，应用分区的作用就是提供负载平衡的能力，对数据进行分区的次要目标就是为了实现零碎的高伸缩性（Scalability）。不同的分区可能放在不同的节点的机器上，而数据的读写操作也都是针对分区这个粒度进行的，每个节点的机器都能独立地执行各自分区读写申请。咱们还能够通过减少节点来晋升整体零碎的吞吐量。Kafka的分区设计，还能够实现业务级别的音讯程序的问题。 2.具体分区策略 所谓的分区策略是指决定生产者将音讯发送到那个分区的算法。Kafka提供了默认的分区策略是轮询，同时kafka也反对用户本人制订。轮询策略：也称为Round-robin策略，即程序调配。轮询的长处是有着优良的负载平衡的体现。随机策略：尽管也是谋求负载平衡，但总体体现差于轮询。音讯键划分策略：还要一种是为每条音讯配置一个key，按音讯的key来存。Kafka容许为每条音讯指定一个key。一旦指定了key ，那么会对key进行hash计算，将雷同的key存入雷同的分区中，而且每个分区下的音讯都是有序的。key的作用很大，能够是一个有着明确业务含意的字符串，也能够是用来表征音讯的元数据。其余的分区策略：基于地理位置的分区。能够从所有分区中找出那些 Leader 正本在某个地理位置所有分区，而后随机筛选一个进行音讯发送。3.1.3 异步发送1.线程模型 之前曾经说了kafka是抉择批量发送音讯来晋升整体的IO性能，具体流程是kafka生产者应用批处理试图在内存中积攒数据，主线程将多条音讯通过一个ProduceRequest申请批量发送进来，发送的音讯暂存在一个队列(RecordAccumulator)中，再由sender线程去获取一批数据或者不超过某个延迟时间内的数据发送给broker进行长久化。 长处: 能够晋升kafka整体的吞吐量，缩小网络IO的次数;进步数据压缩效率(个别压缩算法都是数据量越大越能靠近预期的压缩成果)；毛病: 数据发送有肯定提早，然而这个提早能够由业务因素来自行设置。3.1.4 高效序列化1.序列化的劣势 Kafka 音讯中的 Key 和 Value，都反对自定义类型，只须要提供相应的序列化和反序列化器即可。因而，用户能够依据理论状况选用疾速且紧凑的序列化形式（比方 ProtoBuf、Avro）来缩小理论的网络传输量以及磁盘存储量，进一步提高吞吐量。 2.内置的序列化器 org.apache.kafka.common.serialization.StringSerializer；org.apache.kafka.common.serialization.LongSerializer；org.apache.kafka.common.serialization.IntegerSerializer；org.apache.kafka.common.serialization.ShortSerializer；org.apache.kafka.common.serialization.FloatSerializer；org.apache.kafka.common.serialization.DoubleSerializer；org.apache.kafka.common.serialization.BytesSerializer；org.apache.kafka.common.serialization.ByteBufferSerializer；org.apache.kafka.common.serialization.ByteArraySerializer；3.1.5 消息压缩1.压缩的目标 压缩秉承了用工夫换空间的经典trade-off思维，即用CPU的工夫去换取磁盘空间或网络I/O传输量，Kafka的压缩算法也是出于这种目标。并且通常是：数据量越大，压缩成果才会越好。 因为有了批量发送这个后期，从而使得 Kafka 的消息压缩机制能真正施展出它的威力（压缩的实质取决于多音讯的重复性）。比照压缩单条音讯，同时对多条音讯进行压缩，能大幅缩小数据量，从而更大程度进步网络传输率。 2.压缩的办法 想理解kafka消息压缩的设计，就须要先理解kafka音讯的格局： Kafka的音讯档次分为：音讯汇合（message set）和音讯（message）；一个音讯汇合中蕴含若干条日志项（record item），而日志项才是真正封装音讯的中央。Kafka底层的消息日志由一系列音讯汇合-日志项组成。Kafka通常不会间接操作具体的一条条音讯，他总是在音讯汇合这个层面上进行写入操作。每条音讯都含有本人的元数据信息，kafka会将一批音讯雷同的元数据信息给晋升到外层的音讯汇合外面，而后再对整个音讯汇合来进行压缩。批量音讯在长久化到 Broker 中的磁盘时，依然放弃的是压缩状态，最终是在 Consumer 端做理解压缩操作。 压缩算法效率比照 Kafka 共反对四种次要的压缩类型：Gzip、Snappy、Lz4 和 Zstd，具体效率比照如下： ...

背景介绍随着 IT 技术与大数据的一直倒退，越来越多的企业开始意识到数据的价值，通过大数据分析，能够帮忙企业更深刻地理解用户需要、更好地洞察市场趋势。目前大数据分析在每个业务经营中都施展着重要作用，成为企业晋升市场竞争力的要害动作之一。通常企业会构建数据湖仓，将多个数据源通过数据集成技术，会集一起进行数据分析。由此，数据集成成为了构建数据湖仓的必经之路，然而企业在数据集成过程中却面临很多辣手问题。 全量+增量数据集成割裂。传统的数据集成大多仅反对全量数据，对于全量+增量的一并集成，则须要别离部署链路，获取到数据后再手动合并。 多个数据源头，操作与保护简单。表构造频繁变更，无奈主动同步表构造变更到数据湖仓，手动保护老本高。另外无奈”一键”整库同步，追加同步对象操作简单等。 数据获取时效性差。传统的数据集成技术建模门路较长，依照T+1的形式同步到数据仓库中，时效性差。须要做到实时数据集成和剖析，能力帮忙用户依据最新的数据做出更快、更精确的决策。 基于数据集成的外围痛点和用户诉求，近期腾讯云数据传输服务 DTS 联结 CKafka 重磅公布全新数据集成计划，该计划采取全增量数据一起的同步形式，将数据源先同步到 CKafka，再从 CKafka 生产数据投递到数据湖仓，能够无效帮忙用户解决数据湖仓建设后期数据集成的问题。 基于 DTS 的数据集成计划DTS 在做数据集成计划的初期，产研团队做了十分充沛的调研，并剖析出了用户的外围诉求，次要聚焦以下四个方面： 反对全量+增量数据同步：不便疾速将全量+增量数据全副同步至上游数据分析工具中。按序生产：数据生产时须要依照数据生产的程序进行。数据不失落：数据在上游生产时至多要呈现一次，不能失落业务数据。保护便捷：库表构造变更，或者库表对象追加须要不便操作。DTS 的「数据订阅」模块能够利用于数据集成并散发到上游的场景中，但订阅模块次要解决增量数据，无奈实现全量+增量一起同步。通过屡次的技术探讨和验证后，咱们最终决定基于「数据同步」模块来做数据集成，技术计划：数据源先通过 DTS 同步数据到 CKafka，再从 CKafka 生产数据投递到数据湖仓。 不过理论落地中，咱们还是遇到了一些挑战。 全量局部数据块很大，如何晋升导出导入效率？应用 DTS 数据同步模块来做数据集成，能够满足全量+增量一起同步的诉求，但在大数据场景下，又不得不面临两个问题：对于大表（如10亿行以上），如何晋升同步作业效率？对于超大的存量数据，在全量阶段遇到工作中断时，如何确保数据重入？ 基于以上问题，DTS 设计了分块导出计划，针对大表场景（如10亿行以上），从源库导出数据时将一张大表分为多个分块，一个分块连贯一个线程，这样一张大表就可实现多分块同时导出，晋升大表的同步效率。 在导入到指标 CKafka 时，也是依照分块导入的，同时这些分块都会进行标记，如果 CKafka 产生重启，能够依据标记来辨认中断的分块地位，从中断的分块开始持续向指标 CKafka 写入。应用这个形式，在遇到 CKafka 异样时，就不须要从头从新写，大大晋升用户体验。 多分区，如何保障按序生产？为了晋升用户生产的速率，音讯投递到 CKafka 时个别采纳投递到 CKafka 的多个分区的模式，多个分区能够并行生产以晋升生产速率，但在多分区处理过程中，会波及投递程序的问题，须要保障投递到每个分区的音讯与业务生产的音讯程序保持一致。 在实现中，DTS 向 CKafka 投递音讯时，依照源库日志解析后的程序来写入，因而能够实现写入 CKafka 程序与业务生成程序的统一。 全局程序性DTS 在拉取源库的 Binlog 日志时，采纳单线程机制，先保障日志解析后果与业务生产程序保持一致，等写入到 CKafka 的多个分区时，再依照多线程并发，最终实现了每个分区的音讯都是按序排列。 这里须要阐明下，投递到多 Topic+ 多分区这种模式中，每个分区内的音讯都是按程序投递的，然而多个分区同时生产时，无奈保障分区间按序生产，如果用户对生产到的音讯程序有严格要求，倡议抉择投递到单 Topic+ 单分区的模式。 表级别程序性在抉择按表名分区的场景中，源库同一个表的数据变更都会投递到指标 Topic 下的同一个分区中，因为日志的解析是按序排列，所以投递到 Topic 分区中的音讯也是按序排列。 总之， 不管抉择哪种分区策略，DTS 都能够保障投递到各分区中音讯的程序性。 ...

前言最近应用helm3装置好了kafka和rabbitmq，并且想集成到spring中，发现集成不是那么简略的，尽管有官网实例，然而实例下面短少必要的代码所以通过本人摸索一步步实现，分享给大家。 操作首先，装置好kafka装置和rabbitmq装置环境，装置好之后，咱们就能够配置spring了。 1、首先引入相干依赖包：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-kafka</artifactId></dependency><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream-binder-rabbit</artifactId></dependency>2、配置application.yml文件上面是我的配置，如下所示： spring: cloud: stream: function: definition: testKafkaOut;testKafkaIn;testRabbitOut;testRabbitIn bindings: testKafkaOut-out-0: binder: kafka-binder destination: test #设置音讯类型，本次为json，文本则设置"text/plain" content-type: application/json testKafkaIn-in-0: binder: kafka-binder destination: test content-type: application/json group: log_group testRabbitOut-out-0: binder: rabbit-binder destination: dev content-type: application/json testRabbitIn-in-0: binder: rabbit-binder destination: dev content-type: application/json group: dev-group binders: kafka-binder: type: kafka environment: spring: cloud: stream: kafka: binder: brokers: xxx.xxx.xxx.xxx:xxxx auto-create-topics: true rabbit-binder: type: rabbit # 音讯组件类型 environment: # 设置rabbitmq的相干的环境配置 spring: rabbitmq: host: xxx.xxx.xxx.xxx port: xxxx username: user password: password virtual-host: dev这样就实现了spring cloud stream和kafka以及rabbitmq的配置。 ...

前言：周末闲暇工夫无心找到了一套个性化举荐的源码，整体我的项目使用了SSH，HDFS，Flume，Hive，Kafka，Spark，Scala等。运行时，原本通过spark计算业务埋点数据时，却发现本地没有Kafka。因为我始终也没应用过Kafka，所以也作为新人，浅谈以下Kafka的环境装置与别离在PHP，Scala中的应用。  比照：1. 横向，相比其余中间件。对于kafka与其余消息中间件的比拟，网上很多的博主，不论是从运行原理还是中间件架构都有很具体的介绍。因为我平时用Rabbit居多，在没有看他人介绍前。Rabbi比Kafka于PHP开发更敌对。因为kafka除了PHP的composer依赖包长年不更新外，kafka在windows下的PHP扩大须要本人编译。从这一点上看Rabbit就更适宜业务性的音讯队列，更别说他还有事务等对音讯生产的高保障。kafka在数据增量方面更具劣势，所以少数在大数据和举荐零碎中都有使用。 2. 纵向，相比其余版本。如题目所见，这里次要是2.8+与之前版本的比照。因为在2.8以前，kafka装置前须要装置zookeeper。这里只是一小个区别，其余的新个性具体参考kafka官网文档，因为我看到网上对于kafka的装置文章，他人都会装置zookeeper，所以这里就特地阐明以下，以及前面启动时与其他人博客的不同。 装置：1. 下载下载地址能够在浏览器搜寻kafka官网自行下载，见上图。 2. 配置下载完后目录构造如下，进入config, 次要对zookeeper.properties和server.properties进行散布节点，服务端口，日志寄存目录等等的设置，后期也是什么不必管放弃默认配置进行启动。         3. 启动也不晓得是不是从2.8开始，bin目录下多了一个windows。所以在windows下启动进入到改目录，运行如下命令执行bat文件。留神启动的时候先zookeeper后kafka，进行的时候先kafka后zookeeper。 (1). zookeeper启动zookeeper-server-start.bat ....\config\zookeeper.properties & (2).kafka启动kafka-server-start.bat ....\config\server.properties & (3). 其余命令 查看所有topicskafka-topics.bat --list --zookeeper localhost:2181新增topics kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic testKafka存储机制：topic中partition存储散布partiton中文件存储形式partiton中segment文件存储构造在partition中通过offset查找message  图形化工具：后期能够借助图形化工具疾速具象的查看kafka的音讯数据，也能便于了解其基本操作流程。以下举荐一块桌面端工具——offsetexplorer，能够在网上搜寻下载，当然web控制台也不错，比方kafka manager。 1. kafka连贯 2. Cluster name查看这个值如果没有设置的状况是生成的，能够在启动日志中查看，根目录/logs/server.log 3. Topics查看通过运行一下新增topics或新增音讯后就能够在Offset Explorer查看了，更多的应用办法也能够在网上找到。 PHP操作：1. 下载依赖composer require nmred/kafka-php 2.  生产者Producer.php <?php require './vendor/autoload.php'; date_default_timezone_set('PRC'); /* 创立一个配置实例 */$config = \Kafka\ProducerConfig::getInstance(); /* Topic的元信息刷新的距离 */$config->setMetadataRefreshIntervalMs(10000); /* 设置broker的地址 */$config->setMetadataBrokerList('127.0.0.1:9092'); /* 设置broker的代理版本 */$config->setBrokerVersion('1.0.0'); /* 只须要leader确认音讯 */$config->setRequiredAck(1); /* 抉择异步 */$config->setIsAsyn(false); /* 每500毫秒发送音讯 */$config->setProduceInterval(500); /* 创立一个生产者实例 */$producer = new \Kafka\Producer(); for($i = 0; $i < 100; $i++ ) { $producer->send([ [ 'topic' => 'test', 'value' => 'test'.$i, ], ]);}3. 消费者Consumer.php ...

作者：vivo 互联网搜寻团队- Deng JieKafka中的实时数据是以Topic的概念进行分类存储，而Topic的数据是有肯定时效性的，比方保留24小时、36小时、48小时等。而在定位一些实时数据的Case时，如果没有对实时数据进行历史归档，在排查问题时，没有日志追述，会很难定位是哪个环节的问题。 一、背景Kafka中的实时数据是以Topic的概念进行分类存储，而Topic的数据是有肯定时效性的，比方保留24小时、36小时、48小时等。而在定位一些实时数据的Case时，如果没有对实时数据进行历史归档，在排查问题时，没有日志追述，会很难定位是哪个环节的问题。因而，咱们须要对解决的这些实时数据进行记录归档并存储。 二、内容2.1 案例剖析这里以i视频和vivo短视频实时数据为例，之前存在这样的合作问题： 数据上游内容方提供实时Topic（寄存i视频和vivo短视频相干实时数据），数据侧对实时数据进行逻辑解决后，发送给上游工程去建库实时索引，当工作执行一段时间后，工程侧建索引偶然会提出数据没有发送过来的Case，后期因为没有对数据做存储，在定位问题的时候会比拟麻烦，常常需要查看实时日志，须要破费很长的工夫来剖析这些Case是呈现在哪个环节。为了解决这个问题，咱们能够将实时Topic中的数据，在发送给其余Topic的时候，增加跟踪机制，进行数据分流，Sink到存储介质（比方HDFS、Hive等）。这里，咱们抉择应用Hive来进行存储，次要是查问不便，反对SQL来疾速查问。如下图所示： 在实现优化后的计划时，有两种形式能够实现跟踪机制，它们别离是Flink SQL写Hive、Flink DataStream写Hive。接下来，别离对这两种实现计划进行介绍和实际。 2.2 计划一：Flink SQL写Hive这种形式比拟间接，能够在Flink工作外面间接操作实时Topic数据后，将生产后的数据进行分流跟踪，作为日志记录写入到Hive表中，具体实现步骤如下： 结构Hive Catalog；创立Hive表；写入实时数据到Hive表。2.2.1 结构Hive Catalog在结构Hive Catalog时，须要初始化Hive的相干信息，局部代码片段如下所示： // 设置执行环境 StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); EnvironmentSettings settings = EnvironmentSettings.newInstance().useBlinkPlanner().build(); StreamTableEnvironment tEnv = StreamTableEnvironment.create(env,settings); // 结构 Hive Catalog 名称 String name = "video-hive-catalog"; // 初始化数据库名 String defaultDatabase = "comsearch"; // Hive 配置文件门路地址 String hiveConfDir = "/appcom/hive/conf"; // Hive 版本号 String version = "3.1.2"; // 实例化一个 HiveCatalog 对象 HiveCatalog hive = new HiveCatalog(name, defaultDatabase, hiveConfDir, version); // 注册HiveCatalog tEnv.registerCatalog(name, hive); // 设定以后 HiveCatalog tEnv.useCatalog(name); // 设置执行SQL为Hive tEnv.getConfig().setSqlDialect(SqlDialect.HIVE); // 应用数据库 tEnv.useDatabase("db1");在以上代码中，咱们首先设置了 Flink 的执行环境和表环境，而后创立了一个 HiveCatalog，并将其注册到表环境中。 ...

大家应该对 Kubernetes Events 并不生疏，特地是当你应用 kubectl describe 命令或 Event API 资源来理解集群中的故障时。  $ kubectl get events15m Warning FailedCreate replicaset/ml-pipeline-visualizationserver-865c7865bc Error creating: pods "ml-pipeline-visualizationserver-865c7865bc-" is forbidden: error looking up service account default/default-editor: serviceaccount "default-editor" not found  只管这些信息非常有用，但它只是长期的，保留工夫最长为30天。如果出于审计或是故障诊断等目标，你可能想要把这些信息保留得更久，比方保留在像 Kafka 这样更长久、高效的存储中。而后你能够借助其余工具（如 Argo Events）或本人的应用程序订阅 Kafka 主题来对某些事件做出响应。  构建K8s事件处理链路咱们将构建一整套 Kubernetes 事件处理链路，其次要形成为： Eventrouter，开源的 Kubernetes event 处理器，它能够将所有集群事件整合汇总到某个 Kafka 主题中。Strimzi Operator，在 Kubernetes 中轻松治理 Kafka broker。自定义 Go 二进制文件以将事件散发到相应的 Kafka 主题中。 为什么要把事件散发到不同的主题中？比方说，在集群的每个命名空间中存在与特定客户相干的 Kubernetes 资产，那么在应用这些资产之前你当然心愿将相干事件隔离开。  本示例中所有的配置、源代码和具体设置批示都曾经放在以下代码仓库中：[](https://github.com/esys/kube-events-kafka)    创立 Kafka broker 和主题我抉择应用 Strimzi（[strimzi.io/]()） 将 Kafka 部署到 Kubernetes 中。简而言之，它是用于创立和更新 Kafka broker 和主题的。你能够在官网文档中找到如何装置该 Operator 的具体阐明：[](https://strimzi.io/docs/operators/latest/overview.html)  ...

1、生产者生产者发送音讯流程在音讯发送的过程中，波及到了两个线程 : main线程和Sender线程。在main线程中创立了一个双端队列RecordAccumulator。main线程将音讯发送给 RecordAccumulator，Sender线程一直从RecordAccumulator中拉取音讯发送到Kafka Broker Main线程Producer(send ProducerRecord) -> Interceptors(拦截器) -> Serializer(序列化器) -> Paritioner(分区器)，最终放入到 RecordAccumulator(默认32M)，双端队列，最小单位是ProducerBatch 默认16K Sender线程NetworkClient 网络通信组件，Selector一旦有写事件，将通过 batch.size或linger.ms 来判断是否要发送。同时会在应用inFlightRequests，默认每个broker节点最多缓存5个申请 留神 : linger.ms生产环境是必须要设置的，默认是0，就是说会外面发送数据，必定是不行的(吞吐量太小)。那linger.ms设置多大比拟好呢？没有绝对值，只有相对值，绝对谁？绝对batch.size，batch.size默认是16kb，linger.ms指定时间段内，肯定要大于16kb的数据才有意义，不然每次触发的条件都是linger.ms了，batch.size默认是16kb就失去了意义 生产者参数讲解buffer.memory : RecordAccumulator缓冲区总大小，默认32mbatch.size : 16kb linger.ms : 默认值0，示意没有提早，立刻发送。生产环境倡议该值大小为 5-100ms 之间acks : 0 : 生产者发送过去的数据，不须要等数据落盘应答1 : 生产者发送过去的数据，Leader 收到数据后应答 -1(all) : 生产者发送过去的数据，Leader+和 isr 队列 外面的所有节点收齐数据后应答默认值是-1，-1 和 all 是等价的 max.in.flight.requests.per.connection : 容许最多没有返回 ack 的次数，默认为 5，开启幂等性 要保障该值是 1-5 的数字retries : 当音讯发送呈现谬误的时候，零碎会重发消息。retries 示意重试次数。默认是 int 最大值，2147483647。 如果设置了重试，还想保障音讯的有序性，须要设置 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1 否则在重试此失败音讯的时候，其余的音讯可能发送 胜利了retry.backoff.ms : 两次重试之间的工夫距离，默认是 100msenable.idempotence : 是否开启幂等性，默认 true，开启幂等性compression.type : 生产者发送的所有数据的压缩形式。默认是none，也就是不压缩。反对压缩类型:none、gzip、snappy、lz4和zstd ...

这个逻辑是从一个视频上看来的, b站的某个视频,视频里是小米公司的大拿讲设计方面的计划, 提到了 用refreshTime来作为度量,判断mq积压的水平.refreshTime是一个时间差, 用生产时的以后工夫,减去 mq生成时的创立工夫, 视频上用的如同叫refresh, 当初想想, 用ttl更适合, time to live. 这个思路很牛.

1111111111111111111111111111111111111 2122222222222222222222222222

 linux版本：Ubuntu20.04 1.装好一个之后，先配置虚构网络。这里改成NAT模式 编辑 这里NAT设置外面有网关信息，先记上编辑 ubuntu20.04的网络配置在/etc/netplan上面。外面有一个yaml文件，咱们用vi 命令关上：而后进行如下设置，改为动态ip network:  version: 2  renderer: networkd  ethernets:    enp0s3:     dhcp4: no     addresses: [192.168.208.121/24]      gateway4: 192.168.208.2     nameservers:       addresses: [8.8.8.8,8.8.4.4]    这里addresses就是你的虚拟机ip 联合第1步的子网ip和掩码设置一个，gateway4字段是第2步网关ip。最初的nameservers是配置域名服务器，这里是谷歌的dns服务器地址。配置完之后，执行： sudo netplan --debug apply 对于第二第三台虚拟机，咱们只须要改addresses，换另外一个就行。 4.改完之后用以下命令验证：       networkctl status 5.咱们vi关上/etc/hosts这个文件， 加上域名和ip的映射。 192.168.208.121 moyu1 192.168.208.122 moyu2 192.168.208.123 moyu3 改完之后重启server（这步是必须的，不然会导致本机ping不通虚拟机），而后关上xshell而后虚拟机相互ping对方的域名测试，本机和虚拟机相互ping 测试。确保网络没有问题。8.关上xshell，进行如下设置，这里把主机改为虚拟机的ip地址 编辑  xshell会提醒你生成秘钥，在生成秘钥文件后，而后将秘钥文件放入每个虚拟机的.ssh目录下。 能够抉择将秘钥文件内容追加或笼罩到authorized_keys文件。这里因为是新建的虚拟机，没有其余秘钥，间接用mv命令笼罩了  mv sourcefile authorized_keys 接下来就用xshell连贯三台服务器，功败垂成！ 

前段时间在看 kafka 相干内容，发现 kafka “所有的”读写流量都在主 partition 上，从 partition 只负责备份数据。 那么为什么 kafka 从 partition 不跟其余中间件一样承接读流量？读写拆散的初衷读写拆散的初衷我感觉是利用读流量 & 写流量不同的个性做针对性的优化，而这两种流量我感觉区别如下 读流量写流量业务个性展现类的业务操作类业务流量占比高低可承受数据提早较大十分小增长的可预见性顶峰/平安攻打可能会突发增长总体安稳应用 kafka 的业务特色操作型业务，consumer 生产 producer 生产的音讯，进行本身业务，这个音讯就相似于 trigger可撑持的流量较大，并且可撑持上游 consumer 较多，rebalance 须要肯定的工夫kafka 架构以 topic 为单位，一 topic 可拆分多个 partition，每个 partition 都能够有多个从 partition，不同 partition 散布在不同 broker 上以 partition 为单位，造成 AR（Assigned Repllicas），ISR（In Sync Repllicas），OSR（Out Sync Repllicas），主 partition 接管到音讯后依照 ack 策略同步到 ISR 中从 partition ack = 0，producer 收回音讯后就不论了ack = 1，producer 收回音讯写入主 partition 所在 broker 的磁盘就算胜利ack = all，producer 收回音讯写入主 partition 以及 ISR 上所有副 partition 的磁盘才算胜利kafka 没有主从读写拆散的起因不能主从读写拆散的起因 ...

导语本文介绍了 Kafka 跨数据中心的两种部署形式，简要剖析两种形式下的不同架构以及优缺点，对这些架构可能碰到的问题也提供了一些解决思路；同时也阐明了 Kafka 跨数据中心部署的社区解决方案和商业化解决方案。 背景Kafka 作为世界上最风行的消息中间件之一，个别是客户数据链路中的外围组件，高可用性是客户很关注的因素。近期在对接云上客户时发现，客户对 Kafka 的高可用也有需要，行业架构师也想理解 Kafka 高可用的计划细节；有些客户须要云上 Kafka 的高可用能力；有些客户须要 IDC 中的 Kafka 与云上 Kafka 建设高可用架构;有些客户须要与其余友商云进行跨云高可用。单集群的高可用探讨得比拟多，但跨数据中心的形式比拟多，绝对简单。本文心愿借由对 Kafka 跨数据中心高可用架构的剖析，为以上场景的解决方案提供一些思路。 相干术语RTO(Recovery Time Objective)：即数据恢复工夫指标。指如果产生故障，产生故障转移时业务零碎所能容忍的最长进行服务工夫。如果须要 RTO 越低，就越要防止手工操作，只有自动化故障转移能力实现比拟低的 RTO。RPO(Recovery Point Objective)：即数据恢复点指标。指如果产生故障，故障转移须要从数据历史记录中的哪个点复原。换句话说，有多少数据会在故障期间失落。劫难复原(Disaster Recovery): 涵盖所有容许应用程序从劫难中复原的体系结构、实现、工具、策略和过程的总称，在本文档的上下文中，是指整个区域故障。高可用性(High Availability): 一个高度可用的零碎即便在呈现故障的状况下也能够间断运行。在多区域架构的上下文中，高可用性应用程序即便在整个区域故障期间也能够运行。HA 应用程序具备劫难复原策略。产生故障的场景在以后基础设施丰盛的时代，咱们很容易认为不须要思考故障场景。然而现实情况是，不论是在虚拟化或容器化架构下，还是在提供成熟服务的云厂商上，只管概率各不相同，但都有可能产生部分和系统故障。架构师须要思考特定类型故障的可能性以及对其整体零碎可用性的影响。 上面列出一些典型的故障场景 序号故障场景影响缓解措施1单节点故障单个节点或托管在该节点上的 VM 的性能丢失集群部署2机架或交换机故障该机架内托管的所有节点/虚拟机（和/或连贯）失落集群部署散布在多个机架和/或网络故障域中3DC/DC-机房故障在该 DC/DC 机房内托管的所有节点/虚拟机（和/或连贯）失落扩大集群、复制部署4区域故障该区域内托管的所有节点/虚拟机（和/或连贯）失落天文延长集群（提早相干）和/或复制部署5全球性系统性中断（DNS 故障、路由故障等）影响客户和员工的所有零碎和服务齐全中断离线备份；第三方域中的正本6人为行为（无心或歹意）在检测之前，人为行为可能会毁坏数据和任何同步正本的可用性离线备份这篇文章重点围绕故障场景2、3、4阐明 Kafka 中有哪些计划来应答这几类故障场景。第1种单节点故障，Kafka 集群高可用能够应答；第5、6种故障能够思考将数据存储到第三方零碎，如果在云上能够转储到 COS。 Kafka 体系架构简介以下是 Kafka 的软件架构，整个 Kafka 体系结构由 Producer、Consumer、Broker、ZooKeeper 组成。Broker 又由 Topic、分区、正本组成。  具体能够参考 Kafka 官网文档，Kafka introduce。 单套 Kafka 集群是通过正本复制来保障集群的高可用，但在理论生产状况下，单数据中心单集群不肯定能满足生产上须要的高可用需要，也难以应答简单的业务场景。咱们上面来看看跨数据中心下几种常见的利用场景。 跨数据中心的利用场景跨地区复制 有时候，一家公司可能会在不同的天文区域、城市或大洲有多个数据中心。每个数据中心都有本人的 Kafka 集群。有些应用程序只须要与本地的 Kafka 集群通信，有些应用程序则须要拜访多个数据中心的数据（否则就没有必要跨数据中心的复制计划了）。有很多状况须要跨数据中心拜访数据，例如，依据供需状况批改商品价格就是一个典型的利用场景。该公司在每个城市都有一个数据中心，用于收集每个城市的供需信息，而后依据整体的供需状况调整商品价格。这些信息会被镜像到核心集群，而后业务分析员会基于核心集群中的数据生成整个公司的收益报告。灾备 Kafka 集群可能因为某些起因不可用，为了实现冗余，须要有另外一个与第一个集群完全相同的集群。如果有第一个集群不可用的状况产生，能够将应用程序从新定向到第二个集群。集群的物理隔离 有些客户须要将生产环境数据镜像到测试环境，进行验证。云迁徙和混合云部署 在云计算风行的明天，局部公司会将业务同时部署在本地 IDC 和云端。本地 IDC 和每个云服务区域可能都会有 Kafka 集群，应用程序会在这些 Kafka 集群之间传输数据。例如，云端部署了一个利用，它须要拜访 IDC 里的数据，IDC 里的应用程序负责更新这个数据，并保留在本地的数据库中。能够捕捉这些数据变更，而后保留在 IDC 的 Kafka 集群中，而后再镜像到云端的 Kafka 集群中，让云端的应用程序能够拜访这些数据。这样既有助于管制跨数据中心的流量老本，也有助于进步流量的监管合规性和安全性。法律和法规要求 越来越多的国家和地区对数据安全都很器重，都有出台相应的信息爱护法律法规。如果有数据波及到跨境被拜访，能够利用kafka的镜像能力，在传输到境外之前，进行数据脱敏、传输加密等一系列的解决。 为了合乎不同国家的法律和监管要求，一家公司在不同国家的经营也可能须要不同的配置和策略。例如，一些数据可能须要被保留在具备严格访问控制的独立集群中，一些数据则能够被复制到具备宽松拜访权限的其余集群。为了满足不同区域对数据保留期限的合规性要求，保留在不同区域集群中的数据能够应用不同的配置。跨数据中心Kafka的部署状态一般来说，Kafka 跨数据中心部署大体分两种状态：Stretched Cluster和Connected Cluster。 ...

有个开发需要是预警日志每天只发送一次，当初遇到个bug，测试环境没有发送数据，我在本地启动后有新的预警日志产生，kafka没看到谬误日志，而代码里没有其余更多的逻辑，所以我猜想就是每天只发送一次的这个逻辑产生了谬误 因为我后面日志都是用的流计算kafka stream统计ip频繁查问次数，key为ip，value为次数，为此这里我定义了一个static的map来判断以后key是否有从新发送 private static Map<String, Integer> ipMap = new ConcurrentHashMap<>();//上面是流解决的伪代码stream.groupByKey(ip).windowedBy().count()..toStream().foreach((key,value)->{ if(value.intValue() >= 20 ) {//这里是超过20次才预警 if(ipMap.get(key.key()) == null || value.intValue() < ipMap.get(key.key())) { //这里实现一天最多发一条 ipMap.put(key.key(), value.intValue()); //...业务逻辑 } }})代码的具体逻辑就是我首先判断以后次数是否超过20次了，才预警，而后上面的ipMap逻辑就是为了解决一天只发送一条的实现，我会把value次数存起来，因为我这个工夫窗口范畴是一天，所以其实每个key的value预计的状况是每天同一个key的value都是从0开始一直增长的，然而到第二天的时候，value又会从0开始累加，我按照这个特点实现了上述代码，当当初的value小于上一次的value时，阐明是新的一天了，这时候就能够执行业务逻辑发送预警 （为什么不必获取以后工夫来判断呢？思考到可能日志是昨天发的，然而因为执行或者其余导致提早，聚合事件的时候曾经是第二天了，所以是不牢靠的） 然而应该是有问题的，本地我新启动的话又没问题，因为我的static的ipMap是空的了，所以我借助Arthas来在线查看测试环境的内容 我间接下载好后关上arthas，执行java -jar arthas-boot.jar，这里我还遇到了一个问题，如果启动说3658被占用，是因为上一次抉择过程进行连贯没有失常退出，arthas会保留上一次监听过程，导致本次抉择新过程进行连贯时，与监听中记录的过程id不同，后果呈现谬误，持续抉择上一个过程进行连贯，执行胜利后执行 stop 命令完结连贯 而后我通过getstatic命令 查看到这个ipMap字段的内容，发现这个map的以后ip的key的value内容为20，所以下面代码有两种状况不会执行预警逻辑 一是流计算的value.intValue() >= ipMap.get(key.key())，这种状况有没有可能产生呢，是有可能的，因为这个value.intValue()是kafka进行key（ip）聚合后的总数，然而这个办法并不是每次进来一条数据就会触发一次，而是肯定的策略才产生触发（或者因为各种起因导致音讯沉积），有可能kafka stream一下子解决了超过20条的记录而后再聚合发送到上游时.foreach((key,value) -> {})这里的value的值就会呈现比上一次ipMap里的value值要大，就不会执行预警逻辑， 二是明天的次数刚好是20，昨天的次数也刚好是20，因为我写的value.intValue() < ipMap.get(key.key())所以这种状况也不会执行预警 为了查看流返回的value值，咱们持续应用arthas进行查看，首先咱们须要找到该办法：因为kafka stream的逻辑都是用Lambda表达式来写的，实际上是一个匿名办法，所以我首先在本地通过javap -p 类.class来查看这个办法的匿名办法名是什么（我这里看了一下是lambda$null$8，匿名办法的程序如同和其余办法的程序正好相同，是写在越后面的编译后的地位越在前面），而后我通过arthas的tt -t class method查看进入办法的入参值，后果也如我所料，这个value的值是57，大于20 所以我这个代码是有问题的，解决方案最初还是用工夫来进行判断的，不过不是取以后零碎工夫来判断，而是通过聚合后的.foreach((key,value)->{})中的key，不仅蕴含了自定义的ip，其中的key.window()会蕴含是属于哪个窗口的数据，这样的话我还是用一个map存起来，而后存的是这个窗口的工夫，应用这个窗口的工夫进行判断是不是同一个就晓得是不是明天了，是的话阐明曾经发送过了 这里的map不会进行回收，前面我会换成可过期key的缓存即可，过期工夫设置成1天就好了

version: "3.3"services: zookeeper-server: image: zookeeper:3.7 volumes: # zookeeper快照数据 - "zookeeper_data:/data" # zookeeper事务日志 - "zookeeper_datalog:/datalog" ports: # 对client提供服务 - "3181:2181" restart: always zookeeper-ui: image: juris/zkui:latest ports: # zookeeper-ui的http端口，拜访http://主机ip:主机映射端口(如3180) - "3180:9090" environment: # zk-server地址和端口(配置服务名:容器端口) ZK_SERVER: "zookeeper-server:2181" # admin明码 USER_SET: '{"users":[{"username":"admin", "password":"admin", "role":"ADMIN"}]}' restart: always depends_on: - zookeeper-server kafka-server: image: bitnami/kafka:3.4.0 ports: # kafka客户端连贯端口：毋庸身份认证 - "3092:9092" # kafka客户端连贯端口：须要身份认证 - "3093:9093" volumes: # kafka数据卷 - "kafka_data:/bitnami/kafka" # 启用SASL_PLAINTEXT身份认证 - "./kafka-config/kafka_jaas.conf:/opt/bitnami/kafka/config/kafka_jaas.conf" # 上面是两个身份认证须要的库文件 jackson-all-1.8.4.jar & VSaslLoginModule-1.0.jar - "./kafka-libs/jackson-all-1.8.4.jar:/opt/bitnami/kafka/libs/jackson-all-1.8.4.jar" - "./kafka-libs/VSaslLoginModule-1.0.jar:/opt/bitnami/kafka/libs/VSaslLoginModule-1.0.jar" environment: # 具体的环境变量参考：https://github.com/bitnami/containers/tree/main/bitnami/kafka，所有server.properties中的配置能够转化成：KAFKA_CFG_，例如：KAFKA_CFG_BACKGROUND_THREADS等价于background.threads # zookeeper地址:端口(配置服务名:容器端口) KAFKA_CFG_ZOOKEEPER_CONNECT: "zookeeper-server:2181" # 容许客户端 免明码登录、明文通信 ALLOW_PLAINTEXT_LISTENER: "yes" # kafka监听端口 9092为免登录端口，9093须要身份认证 KAFKA_CFG_LISTENERS: "PLAINTEXT://:9092,SASL_PLAINTEXT://:9093" # 本服务供内部拜访的地址 KAFKA_CFG_ADVERTISED_LISTENERS: "PLAINTEXT://10.1.27.89:3092,SASL_PLAINTEXT://10.1.27.89:3093" # 猜想：批示kafka节点之间的拜访应用哪种协定-->对应后面的ADVERTISED_LISTENERS参数 KAFKA_CFG_SECURITY_INTER_BROKER_PROTOCOL: "PLAINTEXT" # 猜想：和SECURITY_INTER_BROKER_PROTOCOL一个含意 KAFKA_CFG_SASL_MECHANISM_INTER_BROKER_PROTOCOL: "PLAIN" # 猜想：和SECURITY_INTER_BROKER_PROTOCOL一个含意 KAFKA_CFG_SASL_ENABLED_MECHANISMS: "PLAIN" # SASL_PLAINTEXT协定指定的身份认证回调 KAFKA_CFG_LISTENER_NAME_SASL_PLAINTEXT_PLAIN_SASL_SERVER_CALLBACK_HANDLER_CLASS: "com.toone.v3.platform.kafka.server.login.VSaslServerCallbackHandler" # kafka集群中本节点的标识 KAFKA_BROKER_ID: "1" #内存设置 KAFKA_HEAP_OPTS: "-Xms1024m -Xmx2048m" restart: always depends_on: - zookeeper-server kafka-ui: # 参见：https://www.kafkamagic.com/start/ image: digitsy/kafka-magic:latest ports: # 拜访kafka 治理界面：http://主机ip:主机映射端口(如3080) - "3080:80" volumes: # 长久化kafka集群配置 - "./kafka_ui_config:/config" environment: KMAGIC_ALLOW_TOPIC_DELETE: "true" KMAGIC_ALLOW_SCHEMA_DELETE: "true" KMAGIC_CONFIG_STORE_TYPE: "file" KMAGIC_CONFIG_STORE_CONNECTION: "Data Source=/config/KafkaMagicConfig.db;" KMAGIC_CONFIG_ENCRYPTION_KEY: "ENTER_YOUR_KEY_HERE" restart: alwaysvolumes: zookeeper_data: zookeeper_datalog: kafka_data:

音讯队列是什么音讯队列是一种在应用程序之间进行通信的技术，容许将音讯从一个应用程序发送到另一个应用程序，而无需明确的连贯这些应用程序。音讯队列中的音讯被存储在一种称为队列的数据结构中，这些音讯在队列中保留，直到被消费者接管。这使得音讯的发送者和接收者可能异步地通信，而不用期待对方的响应，从而进步了零碎的可伸缩性和弹性。音讯队列还能够通过实现各种模式（例如公布/订阅模式、申请/响应模式等）来反对不同类型的应用程序通信。 音讯队列的要害概念音讯队列中的要害概念包含： 音讯：要传递的数据或信息。队列：用于存储音讯的数据结构，具备先进先出（FIFO）的个性。生产者：向音讯队列发送音讯的应用程序。消费者：从音讯队列接管音讯的应用程序。绑定（Binding）：将一个音讯队列绑定到一个交换机上，以确保音讯被路由到正确的队列。交换机（Exchange）：接管来自生产者的音讯并将其路由到一个或多个队列中。路由键（Routing Key）：用于将音讯从交换机路由到正确的队列。“ 这些概念组成了音讯队列的外围，使得生产者和消费者可能异步地通信，从而进步了零碎的可伸缩性和弹性。 ” 音讯队列的利用场景音讯队列的利用场景十分宽泛，以下是其中一些常见的利用场景： 异步工作：将须要执行的工作放入音讯队列中，由消费者异步地执行工作，进步零碎的响应速度和并发性。分布式系统：在分布式系统中，通过音讯队列实现各个组件之间的异步通信，进步零碎的可伸缩性和弹性。利用解耦：将音讯队列作为中间件，将各个应用程序解耦，防止间接依赖和影响，进步零碎的可维护性和可扩展性。日志收集：通过将日志音讯发送到音讯队列，使得日志的收集和剖析能够异步地进行，防止间接影响业务解决。音讯告诉：通过音讯队列向用户发送告诉音讯，如短信、邮件等，进步零碎的实时性和可靠性。数据缓存：通过将热点数据缓存到音讯队列中，缩小零碎的拜访压力和响应工夫。“ 总之，音讯队列能够在各种分布式系统和异步场景中发挥作用，使得零碎更加高效、灵便和牢靠。 ” 支流的音讯队列有哪些以下是一些支流的音讯队列： Apache Kafka：Apache Kafka 是一种分布式公布-订阅音讯零碎，用于解决高吞吐量的实时数据。它是由 LinkedIn 开发的。RabbitMQ：RabbitMQ 是一个开源的音讯代理，用于反对多种音讯协定。它能够与多种编程语言一起应用，并且具备可扩展性和高可用性。Apache ActiveMQ：Apache ActiveMQ 是一个开源的音讯代理，它实现了 JMS（Java 音讯服务）标准，反对多种传输协定和音讯格局。Amazon SQS：Amazon SQS 是亚马逊提供的一种齐全托管的音讯队列服务，它具备高可用性和可扩展性。Microsoft Azure Service Bus：Microsoft Azure Service Bus 是微软提供的一种齐全托管的音讯队列服务，反对多种协定和语言，具备高可用性和可扩展性。Google Cloud Pub/Sub：Google Cloud Pub/Sub 是 Google 提供的一种齐全托管的音讯队列服务，用于解决大量的实时数据流。支流的音讯队列比照以下是一些常见的音讯队列零碎的比照： RabbitMQ：RabbitMQ 是一个风行的 AMQP（高级音讯队列协定）音讯代理。它具备良好的性能，可靠性和稳定性，并反对多种协定。RabbitMQ 是一个成熟的音讯队列零碎，具备宽泛的社区反对和丰盛的性能。它的治理界面易于应用，可用于监督和治理队列。Apache Kafka：Apache Kafka 是一个高性能的分布式流解决零碎和音讯队列平台。它设计用于解决大量的实时数据，并提供可扩展性，高吞吐量和低提早的个性。Kafka 的音讯模型是基于公布/订阅模式的，并反对多个消费者组，能够实现高效的音讯散发和负载平衡。ActiveMQ：Apache ActiveMQ 是一个风行的开源音讯代理，反对多种传输协定和编程语言，并提供高可用性和可扩展性的个性。它反对 JMS（Java 音讯服务）标准，并提供牢靠的消息传递和事务反对。Redis：Redis 是一种内存数据库，但它也能够用作音讯队列。Redis 的音讯队列模型是基于公布/订阅模式的，并反对多种数据结构和高级性能。Redis 的音讯队列性能较高，但可靠性和持久性取决于其配置和应用形式。Apache Pulsar：Apache Pulsar 是一个开源的分布式流解决零碎和音讯队列平台，具备高可用性和可扩展性。它反对多种协定和编程语言，并提供高效的消息传递和低提早的个性。Pulsar 的音讯模型是基于公布/订阅和队列模式的，并反对多个消费者组和程序音讯。“ 总的来说，每个音讯队列零碎都有本人的优缺点和实用场景，具体抉择取决于理论需要和条件。 ” 支流的音讯队列利用场景不同的音讯队列实用于不同的利用场景。以下是一些支流的音讯队列的利用场景： RabbitMQ：高吞吐量的音讯队列多种语言客户端库反对反对多种音讯协定反对简单的路由规定反对音讯确认机制适宜工作队列、日志解决、音讯通信等场景Kafka：高吞吐量的音讯队列分布式的设计，反对高可用和程度扩大反对音讯的长久化和多正本备份反对批量发送和生产音讯适宜日志收集、流解决、音讯通信等场景ActiveMQ：反对多种协定，如AMQP、STOMP、OpenWire等反对多种音讯模式，如点对点、公布订阅等反对事务、音讯确认等机制反对集群和主从模式适宜音讯通信、工作队列、日志解决等场景RocketMQ：高吞吐量的音讯队列反对分布式和高可用架构反对多种音讯协定反对批量发送和生产音讯反对事务音讯和音讯轨迹适宜大规模分布式系统、电商场景、金融场景等Redis：反对多种数据结构和多种操作，如list、pub/sub等反对长久化和复制反对Lua脚本扩大适宜高速缓存、音讯通信、工作队列等场景Pulsar：适宜大规模分布式系统、物联网等场景反对音讯的长久化和多正本备份反对多租户、多协定和多种语言客户端反对流解决和事务反对动静扩大和缩减“ 总的来说，不同的音讯队列实用于不同的场景和需要，须要依据具体的业务需要抉择适合的音讯队列。 ” Kafka入门实战要害概念Kafka是一个分布式的流解决平台，罕用于高吞吐量的数据管道和实时流数据处理。以下是Kafka的要害概念： Topic（主题）：Kafka中的音讯都被公布到topic，一个topic能够被认为是一个数据源，也能够被认为是一个音讯的分类。Partition（分区）：每个topic能够被分为多个partition，每个partition能够存储特定数量的音讯。每个partition都有一个惟一的标识符（partition id）。Offset：每个partition中的每个音讯都会被调配一个惟一的offset，它是该音讯在partition中的惟一标识符。Producer（生产者）：负责将音讯公布到指定的topic。Consumer（消费者）：消费者订阅了一个或多个topic，并解决被公布到这些topic的音讯。Consumer Group：一组消费者能够组成一个消费者组，这些消费者一起生产一个topic中的所有partition，每个partition只能由一个消费者组中的消费者进行生产。Broker：Kafka集群中的每个节点都称为broker，负责接管和解决音讯，一个Kafka集群能够由多个broker组成。ZooKeeper：Kafka应用ZooKeeper来保护集群的元数据，如broker的状态、topic和partition的状态等。“ ...

Kafka 监听器详解Kafka Assistant 是一款 Kafka GUI 管理工具——治理Broker,Topic,Group、查看生产详情、监控服务器状态、反对多种音讯格局。[TOC] 你须要将 advertised.listeners（如果你应用Docker镜像，则为 KAFKA_ADVERTISED_LISTENERS）设置为内部地址（host/IP），以便客户端能够正确地连贯到它。否则，他们会尝试连贯到外部主机地址--如果无奈达到，问题就会接踵而来。 换一种说法，由Spencer Ruport提供。 listeners 是Kafka所绑定的接口。advertised.listeners 是客户端的连贯形式。 在这篇文章中，我将议论为什么这是有必要的配置 listeners 和 advertised.listeners，而后展现如何基于几个场景--Docker和AWS来做。 是谁在监听Apache Kafka是一个分布式系统。数据是从一个给定的分区的领导者那里读取和写入的，这个领导者能够是集群中的任何一个Broker。当一个客户端（生产者/消费者）启动时，它将申请对于哪个broker是一个分区的领导者的元数据--它能够从任何broker那里做到这一点。返回的元数据将包含该分区的领导者broker的可用端点，而后客户端将应用这些端点连贯到broker，依据须要读/写数据。 正是这些端点给人们带来了麻烦。在单机上，运行裸机（没有虚拟机，没有Docker），可能只须要应用主机名（或只是localhost），这很容易。然而，一旦你进入更简单的网络设置和多节点，你就必须更加留神。 让咱们假如你有一个以上的网络。比方： Docker外部网络（）加上主机云中的Broker（如AWS EC2）和本地的企业外部机器（甚至在另一个云中）。你须要通知Kafka Broker如何互相分割，但也要确保内部客户端（生产者/消费者）能够分割到他们须要分割的Broker。 最要害的是，当你运行一个客户端时，你传递给它的Broker只是它要去的中央，并从那里取得集群中Broker的元数据。它为读/写数据而连贯的理论主机和IP是基于Broker在初始连贯中传递回来的数据--即便它只是一个繁多的节点，而且返回的Broker与它所连贯的Broker雷同。 为了正确配置，你须要理解Kafka Broker能够有多个监听器。一个监听器是一个组合： Host/IPPortProtocol让咱们来看看一些配置。通常状况下，协定也被用于监听器的名称，但在这里，让咱们通过应用监听器的形象名称来使它变得丑陋和清晰。 KAFKA_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://localhost:9092KAFKA_ADVERTISED_LISTENERS: LISTENER_BOB://kafka0:29092,LISTENER_FRED://localhost:9092KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_BOB:PLAINTEXT,LISTENER_FRED:PLAINTEXTKAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_BOB我应用的是Docker配置名称--如果你间接配置 server.properties（例如，在AWS等），其对应名称在以下列表中缩进显示。 KAFKA_LISTENERS 是一个以逗号分隔的监听器列表，以及Kafka绑定监听的主机/IP和端口。对于更简单的网络，这可能是一个与机器上的特定网络接口相干的IP地址。默认是0.0.0.0，这意味着在所有接口上进行监听。 listenersKAFKA_ADVERTISED_LISTENERS 是一个以逗号分隔的监听器列表，包含它们的主机/IP和端口。这是传回给客户端的元数据。 advertised.listenersKAFKA_LISTENER_SECURITY_PROTOCOL_MAP 定义了每个监听器名称要应用的平安协定的键/值对。 listener.security.protocol.mapKafka Broker之间的通信，通常是在外部网络（如Docker网络，AWS VPC等）。要定义应用哪个监听器，请指定 KAFKA_INTER_BROKER_LISTENER_NAME（inter.broker.listener.name）。应用的主机/IP必须是其他人能够从Broker机器上拜访的。 Kafka客户端很可能不在Broker的网络中，这就是额定监听器的作用。 每个监听器在被连贯到时，都会报告它能够被接连到的地址。你达到Broker的地址取决于所应用的网络。如果你从外部网络连接到经纪人，它将是一个不同于内部连贯的主机/IP。 当连贯到Broker时，返回给客户端的监听器将是你连贯到的监听器（基于端口）。 kafkacat是一个摸索这个问题的有用工具。应用 -L，你能够看到你所连贯的监听器的元数据。基于上述雷同的监听器配置（LISTENER_BOB/LISTENER_FRED），留神察看返回的后果： 在9092端口（咱们映射为 LISTENER_FRED）进行连贯，Broker的地址被反馈为 localhost。 $ kafkacat -b kafka0:9092 \ -LMetadata for all topics (from broker -1: kafka0:9092/bootstrap):1 brokers:broker 0 at localhost:9092在29092端口（咱们将其映射为 LISTENER_BOB）进行连贯，Broker的地址被反馈为kafka0。 ...

Apache Kafka教程--Kafka新手入门Kafka Assistant 是一款 Kafka GUI 管理工具——治理Broker,Topic,Group、查看生产详情、监控服务器状态、反对多种音讯格局。[TOC] 摘要明天，咱们开始了咱们的新旅程，这就是Apache Kafka教程。在这个Kafka教程中，咱们将看到什么是Kafka，Apache Kafka的历史，为什么是Kafka。此外，咱们还将学习Kafka架构、Kafka的组件和Kafka分区。此外，咱们还将探讨Kafka的各种比拟和Kafka的应用案例。除此之外，咱们将在这个Kafka教程中看到各种术语，如Kafka Broker、Kafka Cluster、Kafka Consumer、Kafka Topics等。 那么，让咱们开始学习Apache Kafka教程吧。 什么是Kafka？当波及到应用基于音讯的主题实现生产者和消费者之间的通信时，咱们应用Apache Kafka。Apache Kafka是一个疾速、可扩大、容错、公布-订阅的消息传递零碎。基本上，它为高端的新一代分布式应用设计了一个平台。同时，它容许大量的永久性或临时性的消费者。Kafka的一个最好的特点是，它具备高度的可用性和对节点故障的弹性，并反对主动复原。这个特点使得Apache Kafka成为事实世界数据系统中大规模数据系统组件之间的现实通信和集成工具。 此外，这项技术取代了传统的音讯 Broker，可能像JMS、AMQP等一样给出更高的吞吐量、可靠性和复制。此外，Kafka提供了一个Kafka Broker、一个Kafka Producer和一个Kafka Consumer。Kafka Broker是Kafka集群上的一个节点，它的作用是保持和复制数据。Kafka生产者将音讯推送到称为Kafka Topic的音讯容器中。而Kafka消费者则从Kafka Topic中提取音讯。 在持续学习Kafka教程之前，让咱们先理解一下Kafka中Messaging System这一术语的理论含意。 Kafka中的消息传递零碎当咱们将数据从一个应用程序转移到另一个应用程序时，咱们应用了消息传递零碎。它的后果是，不必放心如何分享数据，应用程序能够只关注数据。分布式消息传递是建设在牢靠的音讯队列上。尽管，音讯在客户端应用程序和消息传递零碎之间是异步排队的。有两种类型的消息传递模式，即点对点和公布-订阅（pub-sub）消息传递零碎。然而，大多数的消息传递模式都遵循pub-sub。 点对点消息传递零碎 在这里，音讯被保留在一个队列中。尽管，一个特定的音讯最多只能被一个消费者生产，即便一个或多个消费者能够订阅队列中的音讯。同时，它确保一旦消费者浏览了队列中的音讯，它就会从该队列中隐没。 公布-订阅音讯零碎 在这里，音讯被长久化在一个主题中。在这个零碎中，Kafka消费者能够订阅一个或多个主题并生产该主题中的所有音讯。此外，音讯生产者是指发布者，音讯消费者是指订阅者。 Apache Kafka的历史此前，LinkedIn面临着的问题是，将网站上的大量数据低提早地输出到一个可能解决实时事件的lambda架构中。作为一个解决方案，Apache Kafka在2010年被开发进去，因为之前没有一个解决方案能够解决这个问题。 然而，有一些技术可用于批处理，但这些技术的部署细节是与上游用户共享的。因而，当波及到实时处理时，这些技术并不适宜。而后，在2011年，Kafka被开源了。 为什么咱们要应用Apache Kafka集群？咱们都晓得，大数据中存在着微小的数据量。而且，当波及到大数据时，有两个次要挑战。一个是收集大量的数据，而另一个是剖析收集到的数据。因而，为了克服这些挑战，咱们须要一个消息传递零碎。那么Apache Kafka曾经证实了它的效用。Apache Kafka有许多益处，例如： 通过存储/发送实时过程的事件来跟踪网络流动。揭示和报告业务指标。将数据转换为规范格局。间断解决流媒体数据。因而，因为其宽泛的应用，这项技术正在给一些最风行的应用程序，如ActiveMQ、RabbitMQ、AWS等带来强烈的竞争。 Kafka教程 - 先决条件在持续学习Apache Kafka教程之前，你必须对Java和Linux环境有良好的理解。 Kafka架构上面咱们将在这个Apache Kafka教程中探讨四个外围API。 Kafka Producer API 这个Kafka Producer API容许一个应用程序将音讯公布到一个或多个Kafka主题。 Kafka Consumer API 为了订阅一个或多个主题并解决应用程序中产生的音讯，咱们应用这个Kafka Consumer API。 Kafka Streams API 为了充当流处理器，从一个或多个主题生产输出流，并向一个或多个输入主题产生输入流，同时无效地将输出流转化为输入流，这个Kafka Streams API给应用程序提供了便当。 ...

作者：京东科技 徐拥 入门1、什么是kafka?apache Kafka is a distributed streaming platform. What exactly dose that mean? Apache Kafka 是音讯引擎零碎，也是一个分布式流解决平台（Distributed Streaming Platform） 2、kafka全景图： 3、Kafka的版本演进： 4、kafka选型:Apache Kafka：也称社区版 Kafka。劣势在于迭代速度快，社区响应度高，应用它能够让你有更高的把控度；缺点在于仅提供根底外围组件，缺失一些高级的个性。（如果你仅仅须要一个音讯引擎零碎亦或是简略的流解决利用场景，同时须要对系统有较大把控度，那么我举荐你应用 Apache Kafka） Confluent Kafka ：Confluent 公司提供的 Kafka。劣势在于集成了很多高级个性且由 Kafka 原班人马打造，品质上有保障；缺点在于相干文档资料不全，普及率较低，没有太多可供参考的范例。（如果你须要用到 Kafka 的一些高级个性，那么举荐你应用 Confluent Kafka。） CDH/HDP Kafka：大数据云公司提供的 Kafka，内嵌 Apache Kafka。劣势在于操作简略，节俭运维老本；缺点在于把控度低，演进速度较慢。（如果你须要疾速地搭建音讯引擎零碎，或者你须要搭建的是多框架形成的数据平台且 Kafka 只是其中一个组件，那么我举荐你应用这些大数据云公司提供的 Kafka） 5、Kafka的基本概念： 6、Kafka的根本构造： 7、Kafka的集群构造： 8、kafka的利用场景(用户注册/异步)： 9、kafka队列模式---点对点： 10、kafka队列模式---公布/订阅： 11、kafka形成角色：1、broker：音讯格局: 主题 - 分区 - 音讯 、主题下的每条音讯只会保留在某一个分区中，而不会在多个分区中被保留多份 这样设计的起因是：不应用多topic做负载平衡，意义在于对业务屏蔽该逻辑。业务只须要对topic进行发送，指定负载平衡策略即可 同时 topic分区是实现负载平衡以及高吞吐量的要害 Topic的创立流程 2、Producer：发送音讯流程 3、Consumer：Kafka消费者对象订阅主题并接管Kafka的音讯，而后验证音讯并保留后果。Kafka消费者是消费者组的一部分。一个消费者组里的消费者订阅的是同一个主题，每个消费者接管主题一部分分区的音讯。消费者组的设计是对消费者进行的一个横向伸缩，用于解决消费者生产数据的速度跟不上生产者生产数据的速度的问题，通过减少消费者，让它们分担负载，别离解决局部分区的音讯 ...

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址：https://github.com/Tyson0314/Java-learning Kafka 都有哪些特点？高吞吐量、低提早：kafka每秒能够解决几十万条音讯，它的提早最低只有几毫秒，每个topic能够分多个partition, consumer group 对partition进行consume操作。可扩展性：kafka集群反对热扩大持久性、可靠性：音讯被长久化到本地磁盘，并且反对数据备份避免数据失落容错性：容许集群中节点失败（若正本数量为n,则容许n-1个节点失败）高并发：反对数千个客户端同时读写请简述下你在哪些场景下会抉择 Kafka？日志收集：一个公司能够用Kafka能够收集各种服务的log，通过kafka以对立接口服务的形式凋谢给各种consumer，例如hadoop、HBase、Solr等。音讯零碎：解耦和生产者和消费者、缓存音讯等。用户流动跟踪：Kafka常常被用来记录web用户或者app用户的各种流动，如浏览网页、搜寻、点击等流动，这些流动信息被各个服务器公布到kafka的topic中，而后订阅者通过订阅这些topic来做实时的监控剖析，或者装载到hadoop、数据仓库中做离线剖析和开掘。经营指标：Kafka也常常用来记录经营监控数据。包含收集各种分布式应用的数据，生产各种操作的集中反馈，比方报警和报告。流式解决：比方spark streaming和 FlinkKafka 的设计架构你晓得吗？Kafka 架构分为以下几个局部： Producer ：音讯生产者，就是向 kafka broker 发消息的客户端。Consumer ：音讯消费者，向 kafka broker 取音讯的客户端。Topic ：能够了解为一个队列，一个 Topic 又分为一个或多个分区，Consumer Group：这是 kafka 用来实现一个 topic 音讯的播送（发给所有的 consumer）和单播（发给任意一个 consumer）的伎俩。一个 topic 能够有多个 Consumer Group。Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 能够包容多个 topic。Partition：为了实现扩展性，一个十分大的 topic 能够散布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条音讯都会被调配一个有序的id（offset）。将音讯发给 consumer，kafka 只保障按一个 partition 中的音讯的程序，不保障一个 topic 的整体（多个 partition 间）的程序。Offset：kafka 的存储文件都是依照 offset.kafka 来命名，用 offset 做名字的益处是不便查找。例如你想找位于 2049 的地位，只有找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。Kafka 分区的目标？分区对于 Kafka 集群的益处是：实现负载平衡。分区对于消费者来说，能够进步并发度，提高效率。 ...

前言Kafka 是通过 Scala 和 Java独特编写的语言，之所以抉择2.7.2的版本是因为这个版本的Kafka是最初一版本保留ZK的版本。 为什么不间接部署最新版代码？ 因为过来很长一段时间Kafka都是和ZK配合的，并且有很多成熟我的项目都应用了带ZK的Kafka，去ZK的Kafka还有不少的路要走。 环境筹备JDK：1.8.0_351Scala：2.12.8Gradle：6.6Zookeeper：3.4.14Kafka 2.7.2倡议fork一个官网的分支到本人的仓库，不便本人学习的时候增加正文等内容。 地址：https://github.com/apache/kafka 装置JDK 1.8JDK的教程玩网上有十分多，寻找适合的JDK8的版本即可。 https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html 装置 Scala 2.12.8下载下载地址为：https://www.scala-lang.org/download/2.12.8.html 集体为Win 11，间接下载Windows 装置版本： 集体是window零碎，间接点击下一步即可，装置过程这里省略了。 配置 SCALA_HOME装置实现之后是在对应的操作系统配置环境变量，集体在Path变量中减少SCALA_HOME，并且指定地址即可。因为集体是Windows 装置版本装置，曾经主动配置了环境变量。装置实现之后后果如下： C:\Users\adong>scala -versionScala code runner version 2.12.8 -- Copyright 2002-2018, LAMP/EPFL and Lightbend, Inc. 装置 gradle 6.6下载地址：https://services.gradle.org/distributions/ 咱们抉择想要装置的公布版本，gradle-x.x-bin.zip 是须要下载的装置公布版，gradle-x.x-src.zip 是源码，gradle-x.x-all.zip 则是下载全副的文件。这里我抉择的是gradle-6.6.1-bin.zip。 配置 Gradle 环境变量间接把gradle 的装置目录bin地址贴到环境变量的Path当中。 E:\adongstack\mysoft\gradle-6.6.1\bin 而后是在cmd当中验证即可： C:\Users\adong>gradle -vWelcome to Gradle 6.6.1!Here are the highlights of this release: - Experimental build configuration caching - Built-in conventions for handling credentials - Java compilation supports --release flagFor more details see https://docs.gradle.org/6.6.1/release-notes.html------------------------------------------------------------Gradle 6.6.1------------------------------------------------------------Build time: 2020-08-25 16:29:12 UTCRevision: f2d1fb54a951d8b11d25748e4711bec8d128d7e3Kotlin: 1.3.72Groovy: 2.5.12Ant: Apache Ant(TM) version 1.10.8 compiled on May 10 2020JVM: 1.8.0_333 (Oracle Corporation 25.333-b02)OS: Windows 11 10.0 amd64装置 Zookeeper 3.4.14集体倡议装置到虚拟机的Linux零碎，装置的操作如下： ...

Kafka 是一款高性能、高可靠性、可程度扩大的分布式音讯队列零碎，由 Apache 软件基金会开发和保护。它能够实现音讯的异步解决和分布式计算，被广泛应用于大数据、实时数据流解决、监控报警等畛域。本文将具体介绍 Kafka 的装置过程。 一、环境要求在装置 Kafka 之前，须要满足以下环境要求： 1.Java 运行环境Kafka 是应用 Java 语言编写的，因而须要在装置 Kafka 之前先装置 Java 运行环境。Kafka 反对 Java 8 及以上版本。能够通过以下命令查看 Java 运行环境的版本：java -version如果 Java 运行环境未装置或版本过低，能够通过以下命令装置 Java 运行环境：sudo apt-get install default-jre2.硬件要求Kafka 能够在任何硬件上运行，然而在生产环境中，倡议应用具备足够内存和处理器外围的计算机。倡议至多具备以下硬件配置：内存：4GB 或以上。处理器外围数：2 核或以上。存储空间：100GB 或以上。3.操作系统要求Kafka 能够在多种操作系统上运行，包含 Linux、Windows 和 macOS。倡议在生产环境中应用 Linux 操作系统，例如 CentOS、Ubuntu 等。4.ZooKeeperKafka 应用 ZooKeeper 进行分布式协调，因而在装置 Kafka 之前，须要先装置 ZooKeeper。Kafka 反对 ZooKeeper 3.4.x 及以上版本。能够参考 ZooKeeper 的官网文档进行装置和配置。以上是 Kafka 装置的环境要求，须要满足这些要求能力顺利装置和应用 Kafka。 二、装置 Java 运行环境在装置 Kafka 之前，须要先装置 Java 运行环境。Kafka 反对 Java 8 及以上版本。能够通过以下步骤在 Ubuntu 操作系统上装置 Java 运行环境： ...

kafka集群的组成？1）producer：音讯生产者，向kafka的broker发送音讯的客户端。2）consumer： ：音讯消费者，向 kafka broker拉取音讯的客户端；3）consumer group：消费者组，由多个 consumer 组成。 消费者组内每个消费者负责生产不同分区的数据，一个分区只能由一个组内消费者生产；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。4）broker：一台kafka服务器就是一个broker，一个集群在有多个broker。一个broker内可寄存多个topic。5 ）topic ：能够了解为一个队列， 生产者和消费者面向的都是一个 topic。6 ）partition ：一个十分大的topic能够散布到多个broker上，一个 topic分为多个partition，每个partition是一个有序的队列。7）Replica：正本，为保障集群中的某个节点产生故障时，该节点上的 partition 数据不失落，使得kafka依然可能持续工作，kafka提供了正本机制，一个topic的每个分区都有若干个正本，一个leader和若干个follower。8 ）leader：每个分区多个正本的主节点，负责数据的读写，即生产者发送数据的对象，以及消费者生产数据的对象都是leader。9 ）follower：每个分区多个正本中的从节点，实时从leader中同步数据，放弃和leader数据同步。leader产生故障时，某个follower会成为新的leader。 kafka高可用性：分布式存储：每个 partition 能够存在于不同的 broker 上，每个 partition就放一部分数据。每个 partition 的数据都会同步到其它机器上，造成本人的多个 replica 正本。即每个broker寄存的是不同topic的partition。所有 replica 会选举一个 leader 进去，那么生产和生产都跟这个 leader 打交道，而后其余 replica 就是follower。写的时候，leader 会负责把数据同步到所有 follower 下来，读的时候就间接读 leader上的数据即可。如果某个 broker 宕机了，那个 broker 下面的 partition 在其余机器上都有正本的。如果这个宕机的 broker下面有某个 partition 的 leader，那么此时会从 follower 中从新选举一个新的 leader进去，大家持续读写那个新的 leader 即可。 kafka 的 ack 的三种机制?acks 参数，是管制发送进来的音讯的长久化机制的1、acks=0 at-most-onceproducer基本不论写入broker的音讯到底胜利没有，发送一条音讯进来，立马就能够发送下一条音讯，这是吞吐量最高的形式，可能音讯失落2、acks=all/acks=-1 at-least-once这个leader写入胜利当前，必须期待其余ISR中的正本都写入胜利，才能够返回响应说这条音讯写入胜利了，此时你会收到一个回调告诉3、acks=1 at-exactly-once只有leader写入胜利，就认为音讯胜利了。为何Kafka这么"快"

音讯队列 Kafka 简介Apache Kafka是一个分布式流平台，作为互联网畛域不可或缺的音讯组件，在寰球取得了宽泛的利用。在应用过程中，Kafka个别被作为音讯流转的外围枢纽，上下游零碎通过Kafka实现异步，削峰填谷。在大数据处理和实时数据处理畛域Kafka也是不可代替的组件。 Kafka应用十分宽泛，在有些畛域应用曾经十分成熟，如日志收集，大数据处理，数据库等畛域。Kafka跟上下游也有标准化的对接模块，如日志收集有Flume，Filebeat，Logstash，大数据处理有spark，flink等组件。同时在一些小众的畛域则没有现成的工具能够间接对接，如对接某个小众的数据库，或者用户本人定制化的零碎。这时个别的对接办法是自行开发Kafka生产生产程序对接。 在不同零碎对接时通常会遇到以下问题： 公司的不同团队对同一个零碎有对接需要，各自开发反复造轮子，且实现形式不一，降级运维老本高。各子系统由不同的团队开发，因而，各零碎中的数据在内容和格局上，存在人造的不一致性，须要进行格局解决，以打消各零碎数据之间格局的不同。基于Kafka应用的宽泛度和上下游零碎的多样性思考，Kafka推出了内置的上下游零碎对接框架Kafka Connect。 Kafka Connect 介绍Kafka Connect是一个用于将数据流输出和输入Kafka的框架。上面介绍connector的一些次要概念： Connectors：通过治理task来协调数据流的高级形象Tasks：如何将数据复制到Kafka或从Kafka复制数据的实现Workers：执行Connector和Task的运行过程Converters：用于在Connect和内部零碎发送或接收数据之间转换数据的代码Transforms：更改由连接器生成或发送到连接器的每个音讯的简略逻ConnectorsKafka Connect中的connector定义了数据应该从哪里复制到哪里。connector实例是一种逻辑作业，负责管理Kafka与另一个零碎之间的数据复制。 connector有一些开源的实现。同时用户也能够从头编写一个新的connector插件，编写流程个别如下： TasksTask是Connect数据模型中的次要解决数据的角色。每个connector实例协调一组理论复制数据的task。通过容许connector将单个作业合成为多个task，Kafka Connect提供了内置的对并行性和可伸缩数据复制的反对，只需很少的配置。这些工作没有存储任何状态。工作状态存储在Kafka中的非凡主题config.storage.topic和status.storage.topic中。因而，能够在任何时候启动、进行或重新启动工作，以提供弹性的、可伸缩的数据管道。 Task再均衡当connector首次提交到集群时，workers会从新均衡集群中的所有connector及其tasks，以便每个worker的工作量大致相同。当connector减少或缩小它们所需的task数量，或者更改connector的配置时，也会应用雷同的从新均衡过程。当一个worker失败时，task在流动的worker之间从新均衡。当一个task失败时，不会触发再均衡，因为task失败被认为是一个例外情况。因而，失败的task不会被框架主动重新启动，应该通过REST API重新启动。 Converters在向Kafka写入或从Kafka读取数据时，Converter是使Kafka Connect反对特定数据格式所必须的。task应用转换器将数据格式从字节更改为连贯外部数据格式，反之亦然。 默认提供以下converters： AvroConverter：与Schema Registry一起应用；JsonConverter：适宜构造数据；StringConverter：简略的字符串格局；ByteArrayConverter：提供不进行转换的“传递”选项；转换器与连接器自身解耦，以便在连接器之间天然地重用转换器。 TransformsConnector能够配置转换，以便对单个音讯进行简略且轻量的批改。这对于小数据的调整和事件路由非常不便，且能够在connector配置中将多个转换链接在一起。 开源问题Kafka connect线下独自部署时，设计的很不错了，但作为一个云服务提供时，还是存在了不少的问题，次要体现在以下几点： 与云服务的集成度不好：云厂商有不少闭源产品，对于开源产品的云托管版也会有访问控制等问题。占用Kafka集群资源：每个connector工作都须要三个内置元信息topic，占用云产品资源，对于元信息topic的误操作也会导致工作异样。运维管控接口和监控简略：管控接口没法管制运行资源粒度，监控短少connector工作维度的指标。与云原生架构联合不好：架构初始设计并非云原生，工作之间隔离度不够，负载平衡算法简略，没有动静自均衡能力。基于Kafka connect部署在云上的种种问题，音讯队列Kafka团队在兼容原生kafka connect框架的前提下，以云原生的形式从新实现了Kafka connect模块。 阿里云音讯队列 Kafka Connect 解决方案阿里云音讯队列Kafka Connect框架介绍架构设计将管制面和运行面离开，通过数据库和Etcd进行工作散发和模块通信。底层运行环境采纳K8S集群，更好的管制了资源的粒度和隔离水平，整体架构图如下： 该架构在很好的解决了Apache Kafka Connect模块在云上遇到的问题： 与云服务的对接：运行环境部署时默认网络买通，运行面买通了访问控制模块；占用Kafka集群资源：元信息采纳数据库和Etcd存储，不占用Kafka topic资源；运维管控接口加强：加强了资源层面的管控Api，能够精细化的管制每个工作的运行资源；监控指标加强：工作维度全链路运行时metrics收集，监控数据从流入到流出的不同阶段的运行状况，呈现问题是及时定位问题；云原生架构设计：管制面兼顾全局资源，实时监测集群负载，并可能主动实现负载平衡，失败重启，异样漂移等运维操作；阿里云Kafka Connect介绍阿里云音讯队列Kafka曾经反对的Connector类型如下： 涵盖了数据库，数据仓库，数据检索和报表，告警零碎，备份需要这些支流的应用场景。 依据不同场景的理论需要，阿里云音讯队列Kafka Connect次要两种实现形式： 通过扩大Kafka Connect框架，实现内部零碎与Kafka的间接对接。对于须要数据处理的工作类型，通过Kafka->函数计算（下简称fc）->内部零碎的，在fc上能够灵便的定制化解决逻辑。具体connect的实现形式如下： 数据库数据库之间备份个别不会走kafka，msyql->kafka个别都是为了将数据分发给上游订阅，在mysql数据有变更时作出告警或这其余响应，链路mysql->kafka->订阅程序->告警/变更其余零碎。 数据仓库数据仓库阿里云上罕用的是maxCompute，工作特点是吞吐量大，也有数据荡涤需要，个别流程为kafka->maxCompute，而后maxCompute外部工作进行数据转换。也能够在入maxCompute之前进行数据荡涤，链路个别为kafka->flink->maxCompute。对于数据转换简略或者数据量小的工作，能够应用函数计算替换flink，链路为kafka->fc->maxCompute。 数据检索和报表通用的数据检索和报表个别通过es，数据传入es前须要做荡涤解决，适宜的门路kafka->flink->es/kafka->fc->es。 告警零碎告警零碎中应用kafka个别流程 前置模块->kafka->订阅程序->告警模块，这种最好的形式是 前置模块->kafka->fc->告警。 备份需要有些数据可能须要定期归档，做长期保留，oss是一个不错的介质，这种场景个别只须要保留原属数据，所以好的形式可能是kafka->oss。如果数据须要解决，能够通过Kafka->fc->oss链路。阿里云音讯队列 Kafka 生态布局音讯队列Kafka以后反对的connect都采纳自研新架构独立开发，对于支流的应用场景曾经有了不错的笼罩，但同时也能够看到，Kafka生态倒退十分迅猛，Kafka的应用场景也越来越多，开源Kafka connect也在一直的倒退，下一步音讯队列Kafka会对接开源Kafka connect，让开源Kakfa connect能够无需批改，无缝的运行在自研的架构上。 总结Kafka在互联网架构中曾经占据了重要的地位，同时也在踊跃往上下游拓展，除了Kafka connect，还有Kafka Streams，Ksql，Kafka Rest Proxy等模块也在不断完善和成熟，置信在后续的倒退中，Kafka在软件架构中会表演越来越多的重要角色。 ...

Kafka-Server-start.sh if [ $# -lt 1 ]; then # 提醒命令应用办法 echo "USAGE: $0 [-daemon] server.properties [--override property=value]*" exit 1 fi base_dir=$(dirname $0) if [ "x$KAFKA_LOG4J_OPTS" = "x" ]; then export KAFKA_LOG4J_OPTS="-Dlog4j.configuration=file:$base_dir/../config/log4j.properties" fi if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" fi EXTRA_ARGS=${EXTRA_ARGS-'-name kafkaServer -loggc'} COMMAND=$1 case $COMMAND in -daemon) EXTRA_ARGS="-daemon "$EXTRA_ARGS shift ;; *) ;; esac exec $base_dir/kafka-run-class.sh $EXTRA_ARGS kafka.Kafka "$@"判断参数有没有，参数个数小于1就提醒用法；获取脚本以后门路赋值给变量 base_dir；判断日志参数 KAFKA_LOG4J_OPTS 是否为空，为空就给它一个值；判断堆参数 KAFKA_HEAP_OPTS是否为空，为空就默认给它赋值为 "-Xmx1G -Xms1G"，默认的堆空间指定为1G；判断启动命令中第一个参数是否为 -daemon，如果是就以守护过程启动（其实不是，是赋给另一个变量 EXTRA_ARGS）；执行命令。最初一个脚本是执行另一个脚本：kafka-run-class.sh，这个脚本的内容比较复杂了。 ...

具象化模型下图以订单、运输、告诉等信息，形容与kafka交互的过程，业务中的事件（如下单，领取，配送，评估，售后）会产生各类信息，最终以topic归类会集到kafka中 分区同一类的音讯都会会集到一个Topic中，一个Topic能够分为多个Partition，Partition是最小的贮存单元，每一个Partition贮存着一部分的音讯，每个Partition都是一个独自的log文件，每条记录都以追加的模式写入 偏移量 & 音讯程序Partition中每条记录都会被调配惟一的序号，称为Offset，即偏移量Offset是一个递增的，不可变的数字，由kafka主动保护当一条记录写入Partition的时候，它就被追加到log文件的开端，并被调配一个序号，作为 Offset 所以从Partition来看，单个Partition外部是有序的，但从Topic来看，音讯在Partition之间是无序的；如果心愿音讯保障齐全的程序，就只能存在一个Partition，又或者发送端指定发送到某个Partition，生产端指定从某个Partition生产Partition 扩大 & 冗余kafka集群由多个Broker形成，每个Broker中含有集群的局部数据，同一个Topic的多个 Partition将散布在多个Broker中；Partition会生成多个正本，它们会扩散在不同的Broker中，如果某个Broker故障了，Consumer能够在其余Broker上找到Partition的正本，持续获取音讯 Message 写入指定Partition Producer发送音讯时，可指定一个Partition Key 这样就能够写入特定的Partition Partition Key会依据一个Hash函数计算出写入哪个Partition Partition Key雷同的音讯，会被放到雷同的Partition 这种形式须要留神数据歪斜问题 随机Partition 如果没有应用Partition Key，kafka则会应用轮询的形式来决定写入哪个Partition 音讯会平衡的写入各个Partition，这样无奈确保音讯的有序性自定义规定 Kafka 反对自定义规定，一个 Producer 能够应用本人的分区指定规定。Message 读取kafka的音讯读取采纳的是pull形式，Consumer须要被动从Topic的Partition拉取音讯，Pull模式下，Consumer就能够依据本人的生产能力去决定生产策略但Pull有个毛病是，如果broker没有可供生产的音讯，将导致consumer一直在循环中轮询，直到新音讯达到为了防止这点，kafka有个参数能够让Consumer阻塞直到新音讯达到，也能够阻塞直到音讯的数量累积到某个特定的值再读取音讯的Offset就是Consumer的游标，依据Offset来记录音讯的生产状况读完一条音讯之后，Consumer会推动到Partition中的下一个Offset持续读取音讯Offset由Consumer负责保护 生产组Consumer Group下有一个或多个Consumer，这些Consumer有雷同的groupId，groupId是一个字符串，生产组的惟一标识Topic中的每个分区只能调配给某个Consumer Group的一个Consumer生产（该分区还能够被调配给其余生产组） 参考资料：https://medium.com/event-driv...本文中大部分的图来自上述博客，应该是一位印度工程师所写，原文为英文且查看须要翻墙https://www.bilibili.com/read...

前言分布式，是程序员必备技能之一，在面试过程中属于必备类的，在工作中更是会常常用到。而Kafka是一个分布式的基于公布订阅的音讯队列，目前它的魅力是无穷的，对于Kafka的神秘，还须要咱们细细去探寻。 要谈对Kafka有多相熟，我置信还是阿里的大佬们最有发言权，所以明天分享的内容，就是Alibaba外部供给的“限量笔记”，对于Kafka的精华全副写在这外面了，不得不感叹：不愧是Alibaba的技术官啊，真的服了！ 对于这份Kafka限量笔记，我只能在文章中展现局部的章节内容和外围截图，如果你须要残缺的pdf版本，能够【间接点击此处】支付哦。 一、对Kafka的意识1.Kafka的基本概念 2.装置与配置 3.生产与生产 4.服务端参数配置 二、生产者1.客户端开发 必要的参数配置音讯的发送序列化分区器生产者拦截器 2.原理剖析 整体架构元数据的更新 3.重要的生产者参数 三、消费者1.消费者与生产组 2.客户端开发 必要的参数配置订阅主题与分区反序列化音讯生产位移提交管制或敞开生产指定位移生产再平衡消费者拦截器多线程实现重要的消费者参数 四、主题与分区1.主题的治理 创立主题分区正本的调配查看主题批改主题配置管理主题端参数删除主题 2.初识KafkaAdminCilent 根本应用主题合法性验证 3.分区的治理 优先正本的选举分区重调配复制限流批改正本因子 4.如何抉择适合的分区数 性能测试工具分区数越多吞吐量就越高吗分区数的下限考量因素 五、日志存储1.文件目录布局 2.日志格局的演变 v0版本v1版本消息压缩变长字段v2版本 3.日志索引 偏移量索引工夫戳索引 4.日志清理 日志删除日志压缩 5.磁盘存储 页缓存磁盘I/O流程零拷贝 六、深刻服务端1.协定设计 2.工夫轮 3.延时操作 4.控制器 5.参数解密 七、深刻客户端1.分区调配策略 2.消费者协调器和组协调器 3._consumer_offsets分析 4.事务 八、可靠性探索1.正本分析 2.日志同步机制 3.可靠性剖析 [图片上传失败...(image-3b0595-1672367716850)] 九、Kafka利用1.命令行工具 2.Kafka Connect 3.Kafka Mirror Maker ...

1、请阐明什么是Apache Kafka?Apache Kafka是由Apache开发的一种公布订阅音讯零碎，它是一个分布式的、分区的和可复制的提交日志服务。 2、说说Kafka的应用场景？①异步解决 ②利用解耦 ③流量削峰 ④日志解决 ⑤音讯通信等。 3、应用Kafka有什么长处和毛病？长处： ①反对跨数据中心的音讯复制； ②单机吞吐量：十万级，最大的长处，就是吞吐量高;  ③topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度降落。所以在等同机器下，kafka尽量保障topic数量不要过多。如果要撑持大规模topic，须要减少更多的机器资源;  ④时效性：ms级;  ⑤可用性：十分高，kafka是分布式的，一个数据多个正本，多数机器宕机，不会失落数据，不会导致不可用;  ⑥音讯可靠性：通过参数优化配置，音讯能够做到0失落;  ⑦性能反对：性能较为简单，次要反对简略的MQ性能，在大数据畛域的实时计算以及日志采集被大规模应用。 毛病：  ①因为是批量发送，数据并非真正的实时； 仅反对对立分区内音讯有序，无奈实现全局音讯有序；  ②有可能音讯反复生产；  ③依赖zookeeper进行元数据管理，等等。 4、为什么说Kafka性能很好，体现在哪里？①程序读写  ②零拷贝  ③分区  ④批量发送  ⑤数据压缩  5、请阐明什么是传统的消息传递办法?传统的消息传递办法包含两种：  排队：在队列中，一组用户能够从服务器中读取音讯，每条音讯都发送给其中一个人。  公布-订阅：在这个模型中，音讯被播送给所有的用户。 6、请阐明Kafka绝对传统技术有什么劣势?①疾速:繁多的Kafka代理能够解决成千上万的客户端，每秒解决数兆字节的读写操作。 ②可伸缩:在一组机器上对数据进行分区和简化，以反对更大的数据③长久:音讯是持久性的，并在集群中进行复制，以避免数据失落。 ④设计:它提供了容错保障和持久性 7、解释Kafka的Zookeeper是什么?咱们能够在没有Zookeeper的状况下应用Kafka吗?Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。  不，不可能越过Zookeeper，间接分割Kafka broker。一旦Zookeeper进行工作，它就不能服务客户端申请。  Zookeeper次要用于在集群中不同节点之间进行通信  在Kafka中，它被用于提交偏移量，因而如果节点在任何状况下都失败了，它都能够从之前提交的偏移量中获取  除此之外，它还执行其余流动，如: leader检测、分布式同步、配置管理、辨认新节点何时来到或连贯、集群、节点实时状态等等。 8、解释Kafka的用户如何生产信息?在Kafka中传递音讯是通过应用sendfile API实现的。它反对将字节从套接口转移到磁盘，通过内核空间保留正本，并在内核用户之间调用内核。 9、解释如何进步近程用户的吞吐量?如果用户位于与broker不同的数据中心，则可能须要调优套接口缓冲区大小，以对长网络提早进行摊销。 10、解释一下，在数据制作过程中，你如何能从Kafka失去精确的信息?在数据中，为了准确地取得Kafka的音讯，你必须遵循两件事: 在数据耗费期间防止反复，在数据生产过程中防止反复。  这里有两种办法，能够在数据生成时精确地取得一个语义:  每个分区应用一个独自的写入器，每当你发现一个网络谬误，查看该分区中的最初一条音讯，以查看您的最初一次写入是否胜利  在音讯中蕴含一个主键(UUID或其余)，并在用户中进行重复制 11、解释如何缩小ISR中的扰动?broker什么时候来到ISR?ISR是一组与leaders齐全同步的音讯正本，也就是说ISR中蕴含了所有提交的音讯。ISR应该总是蕴含所有的正本，直到呈现真正的故障。如果一个正本从leader中脱离进去，将会从ISR中删除。 12、Kafka为什么须要复制?Kafka的信息复制确保了任何已公布的音讯不会失落，并且能够在机器谬误、程序谬误或更常见些的软件降级中应用。 13、如果正本在ISR中停留了很长时间表明什么?如果一个正本在ISR中保留了很长一段时间，那么它就表明，跟踪器无奈像在leader收集数据那样疾速地获取数据。 14、请阐明如果首选的正本不在ISR中会产生什么?如果首选的正本不在ISR中，控制器将无奈将leadership转移到首选的正本。 15、有可能在生产后产生音讯偏移吗?在大多数队列零碎中，作为生产者的类无奈做到这一点，它的作用是触发并遗记音讯。broker将实现剩下的工作，比方应用id进行适当的元数据处理、偏移量等。  作为音讯的用户，你能够从Kafka broker中取得弥补。如果你凝视SimpleConsumer类，你会留神到它会获取包含偏移量作为列表的MultiFetchResponse对象。此外，当你对Kafka音讯进行迭代时，你会领有包含偏移量和音讯发送的MessageAndOffset对象。 16、Kafka的设计时什么样的呢？Kafka将音讯以topic为单位进行演绎 将向Kafka topic公布音讯的程序成为producers. 将预订topics并生产音讯的程序成为consumer. Kafka以集群的形式运行，能够由一个或多个服务组成，每个服务叫做一个broker. producers通过网络将音讯发送到Kafka集群，集群向消费者提供音讯 17、数据传输的事物定义有哪三种？（1）最多一次:音讯不会被反复发送，最多被传输一次，但也有可能一次不传输 （2）起码一次: 音讯不会被漏发送，起码被传输一次，但也有可能被反复传输. （3）准确的一次（Exactly once）: 不会漏传输也不会反复传输,每个音讯都传输被一次而且仅仅被传输一次，这是大家所冀望的 18、Kafka判断一个节点是否还活着有那两个条件？（1）节点必须能够保护和ZooKeeper的连贯，Zookeeper通过心跳机制查看每个节点的连贯 （2）如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久 19、producer是否间接将数据发送到broker的leader(主节点)？producer间接将数据发送到broker的leader(主节点)，不须要在多个节点进行散发，为了帮忙producer做到这点，所有的Kafka节点都能够及时的告知: 哪些节点是流动的，指标topic指标分区的leader在哪。 这样producer就能够间接将音讯发送到目的地了。 20、Kafa consumer是否能够生产指定分区音讯？Kafa consumer生产音讯时，向broker收回"fetch"申请去生产特定分区的音讯，consumer指定音讯在日志中的偏移量（offset），就能够生产从这个地位开始的音讯，customer领有了offset的控制权，能够向后回滚去从新生产之前的音讯，这是很有意义的 21、Kafka音讯是采纳Pull模式，还是Push模式？Kafka最后思考的问题是，customer应该从brokes拉取音讯还是brokers将音讯推送到consumer，也就是pull还push。 ...

引言| 要确保Kafka在应用过程中的稳定性，须要从kafka在业务中的应用周期进行顺次保障。次要能够分为：当时预防（通过标准的应用、开发，预防问题产生）、运行时监控（保障集群稳固，出问题能及时发现）、故障时解决（有残缺的应急预案）这三阶段。 当时预防当时预防即通过标准的应用、开发，预防问题产生。次要蕴含集群/生产端/生产端的一些最佳实际、上线前测试以及一些针对紧急情况（如音讯积压等）的长期开关性能。 Kafka调优准则： 1.确定优化指标，并且定量给出指标（Kafka 常见的优化指标是吞吐量、延时、持久性和可用性）。 2.确定了指标之后，须要明确优化的维度。 通用性优化：操作系统、JVM 等。 针对性优化：优化 Kafka 的 TPS、处理速度、延时等。 （一）生产端最佳实际参数调优应用 Java 版的 Client；应用 kafka-producer-perf-test.sh 测试你的环境；设置内存、CPU、batch 压缩；batch.size：该值设置越大，吞吐越大，但提早也会越大；linger.ms：示意 batch 的超时工夫，该值越大，吞吐越大、但提早也会越大；max.in.flight.requests.per.connection：默认为5，示意 client 在 blocking 之前向单个连贯（broker）发送的未确认申请的最大数，超过1时，将会影响数据的程序性；compression.type：压缩设置，会进步吞吐量；acks：数据 durability 的设置；防止大音讯（占用过多内存、升高broker处理速度）；broker调整：减少 num.replica.fetchers，晋升 Follower 同步 TPS，防止 Broker Full GC 等；当吞吐量小于网络带宽时：减少线程、进步 batch.size、减少更多 producer 实例、减少 partition 数；设置 acks=-1 时，如果提早增大：能够增大 num.replica.fetchers（follower 同步数据的线程数）来调解；跨数据中心的传输：减少 socket 缓冲区设置以及 OS tcp 缓冲区设置。开发实际a.做好Topic隔离依据具体场景（是否容许肯定提早、实时音讯、定时周期工作等）辨别kafka topic，防止挤占或阻塞实时业务音讯的解决。 b.做好音讯流控如果上游音讯生产存在瓶颈或者集群负载过低等，须要在生产端（或音讯网关）施行流量生产速率的管制或者延时/暂定音讯发送等策略，防止短时间内发送大量音讯。 c.做好音讯补推手动去查问失落的那局部数据，而后将音讯从新发送到mq外面，把失落的数据从新补回来。 d.做好音讯程序性保障如果须要在保障Kafka在分区内严格有序的话（即须要保障两个音讯是有严格的先后顺序），须要设置key，让某类音讯依据指定规定路由到同一个topic的同一个分区中（能解决大部分生产程序的问题）。 然而，须要防止分区内音讯歪斜的问题（例如，依照店铺Id进行路由，容易导致音讯不平衡的问题）。 1.生产端：音讯发送指定key，确保雷同key的音讯发送到同一个partition。 2.生产端：单线程生产或者写 N 个内存 queue，具备雷同 key 的数据都到同一个内存 queue；而后对于 N 个线程，每个线程别离生产一个内存 queue。 ...

Linux解压装置KafkaMacBook Linux装置zookeeper MacBook Linux装置Kafka Kafka依赖ZookeeperKafka依赖Zookeeper,能够独自装置Zookeeper,也能够间接启动Kafka包里自带的Zookeeper Kafka 装置cd /data/software#下载wget http://mirror.bit.edu.cn/apache/kafka/2.0.1/kafka_2.11-2.0.1.tgzwget http://mirror.bit.edu.cn/apache/kafka/2.1.1/kafka_2.11-2.1.1.tgztar -zxvf kafka_2.11-2.0.1.tgzmv kafka_2.11-2.0.1 /data/apps/kafka_2.11-2.0.1cd /data/apps/kafka_2.11-2.0.1/批改配置vim config/server.propertieslisteners=PLAINTEXT://192.168.1.53:9092留神:该属性在config/server.properties中的形容如下：翻译过去就是hostname和端口是用来倡议给生产者和消费者应用的，如果没有设置，将会应用listeners的配置，如果listeners也没有配置，将应用java.net.InetAddress.getCanonicalHostName()来获取这个hostname和port，对于ipv4，根本就是localhost了。如果有设置hostname会去用hostname去连贯,就会报错advertised.listeners=PLAINTEXT://192.168.1.53:9092 delete.topic.enable=true如果没有设置 delete.topic.enable=true，则调用kafka 的delete命令无奈真正将topic删除，而是显示（marked for deletion）启动nohup bin/kafka-server-start.sh config/server.properties >> log.file 2>&1 &Kafka 常用命令应用bin/kafka-topics.sh --list --zookeeper localhost:2181 列表bin/kafka-topics.sh --list --zookeeper 192.168.1.53:2181bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 2 --topic inTopic 创立topic单机版 只能创立一个分区replication-factor 1,不然报错提醒 Replication factor: 3 larger than available brokers: 1能够多个正本partitions 2bin/kafka-topics.sh --zookeeper 192.168.1.53:2181 --describe --topic inTopic 查看topic形容bin/kafka-console-producer.sh --broker-list 192.168.1.53:9092 --topic my-topic 生产数据 输出数据bin/kafka-console-consumer.sh --bootstrap-server 192.168.1.53:9092 --topic my-topic --from-beginning 生产数据bin/kafka-topics.sh --delete --zookeeper localhost:2181 --topic my-topic 删除topic

wget https://downloads.apache.org/... tar -zxvf kafka_2.13-3.3.1.tgz cd /home/kafka_2.13-3.3.1 vi /home/kafka_2.13-3.3.1/config/server.properties 批改： broker.id=0 容许内部端口连贯listeners=PLAINTEXT://0.0.0.0:9092 内部代理地址advertised.listeners=PLAINTEXT://192.168.36.20:9092 应用kafka-server-start.sh启动kafka服务： sh /home/zookeeper/bin/zkServer.sh start nohup /home/kafka_2.13-3.3.1/bin/kafka-server-start.sh /home/kafka_2.13-3.3.1/config/server.properties >/dev/null 2>&1 & kafka进行： bin/kafka-server-stop.sh bin/zookeeper-server-stop.sh

过滤器（Filter）和拦截器（Interceptor）都是基于 AOP（Aspect Oriented Programming，面向切面编程）思维实现的，用来解决我的项目中某一类问题的两种“工具”，但二者有着显著的差距，接下来咱们一起来看。 实现过滤器和拦截器首先，咱们先来看一下二者在 Spring Boot 我的项目中的具体实现，这对后续了解二者的区别有很大的帮忙。 实现过滤器过滤器能够应用 Servlet 3.0 提供的 @WebFilter 注解，配置过滤的 URL 规定，而后再实现 Filter 接口，重写接口中的 doFilter 办法，具体实现代码如下： import org.springframework.stereotype.Component;import javax.servlet.*;import javax.servlet.annotation.WebFilter;import java.io.IOException;@Component@WebFilter(urlPatterns = "/*")public class TestFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { System.out.println("过滤器：执行 init 办法。"); } @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { System.out.println("过滤器：开始执行 doFilter 办法。"); // 申请放行 filterChain.doFilter(servletRequest, servletResponse); System.out.println("过滤器：完结执行 doFilter 办法。"); } @Override public void destroy() { System.out.println("过滤器：执行 destroy 办法。"); }}其中： ...

Kafka简略介绍Apache Kafka是一个分布式的 公布 - 订阅 消息传递零碎和一个弱小的队列，Kafka最后由Linkedin公司开发，是一个分布式、分区的、多正本的、多订阅者，基于zookeeper协调的分布式日志零碎（也能够当做MQ零碎), Linkedin于2010年奉献给了Apache基金会并成为顶级开源我的项目。 Kafka能够解决大量的数据，并使您可能将音讯从一个端点传递到另一个端点。 Kafka适宜离线和在线音讯生产。 Kafka音讯被保留在磁盘上并在集群内复制以避免数据失落。 Kafka建设在ZooKeeper同步服务之上。 它与Apache Storm和Spark完满集成，用于实时流数据分析。 长处: 可靠性 ---卡夫卡是分布式，分区，复制和容错。可扩展性 --- Kafka音讯零碎无需停机即可轻松扩大。耐用性 --- Kafka应用分布式提交日志，这意味着音讯尽可能快地保留在磁盘上，因而它是长久的。性能 ---Kafka对于公布和订阅音讯都有很高的吞吐量。 它保持稳定的性能，即便存储了许多TB数据量(级)的音讯。Kafka速度十分快，可确保零停机工夫和零数据失落。 官网下载地址: http://kafka.apache.org/downl...官网下载包: kafka_2.11-1.1.0.tgz Kafka依赖ZookeeperKafka依赖Zookeeper,能够独自装置Zookeeper,也能够间接启动Kafka包里自带的Zookeeper MacBook Linux装置zookeeper MacBook Linux装置Kafka#解压tar -zxvf kafka_2.11-1.1.0.tgz#进入解压目录cd kafka_2.11-1.1.0#创立日志目录mkdir kafka-logs#批改配置vim config/server.properties#指定日志目录log.dirs=/Users/liang/software/kafka_2.11-1.1.0/kafka-logs#启动自带的zookeeper,也能够应用内部的zookeeperbin/zookeeper-server-start.sh config/zookeeper.properties#后盾形式启动#bin/zookeeper-server-start.sh config/zookeeper.properties &#bin/zookeeper-server-start.sh -daemon config/zookeeper.properties &#启动kafka服务 bin/kafka-server-start.sh config/server.properties#后盾形式启动#bin/kafka-server-start.sh config/server.properties &#bin/kafka-server-start.sh -daemon config/server.properties &#nohup bin/kafka-server-start.sh config/server.properties > /dev/null 2>&1 &#进行kafkabin/kafka-server-stop.sh#进行zookeeperbin/zookeeper-server-stop.sh常用命令#查问topicbin/kafka-topics.sh --list --zookeeper localhost:2181#创立topic bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test#生产者 bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test#消费者 bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic test参考链接:https://www.cnblogs.com/dragk...https://blog.csdn.net/zxy9878...https://colobu.com/2014/08/06...https://www.cnblogs.com/zhaoj... ...

导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与宽泛开发者打造的分享交换窗口。栏目邀约腾讯技术人分享原创的技术积淀，与宽泛开发者互启迪共成长。本文作者是腾讯后端开发工程师刘国强。 应用kafka能够对系统解耦、流量削峰、缓冲，能够实现零碎间的异步通信等。在流动追踪、消息传递、度量指标、日志记录和流式解决等场景中非常适合应用kafka。这篇文章次要介绍下kafka中的基本概念。 kafka的整体构造下图展现了很多对于kafka的细节，临时先不必关注： 图中展现出了kafka的一些重要组件，接下来一一介绍一下。 （一）Broker服务代理节点。其实就是一个kafka实例或服务节点，多个broker形成了kafka cluster。 （二）Producer生产者。也就是写入音讯的一方，将音讯写入broker中。 （三）Consumer消费者。也就是读取音讯的一方，从broker中读取音讯。 （四）Consumer Group生产组。一个或多个消费者形成一个生产组，不同的生产组能够订阅同一个主题的音讯且互不影响。 （五）ZooKeeperkafka应用zookeeper来治理集群的元数据，以及控制器的选举等操作。 （六）Topic主题。每一个音讯都属于某个主题，kafka通过主题来划分音讯，是一个逻辑上的分类。 （七）Partition分区。同一个主题下的音讯还能够持续分成多个分区，一个分区只属于一个主 题。 （八）Replica正本。一个分区能够有多个副原本进步容灾性。 （九）Leader and Follower分区有了多个正本，那么就须要有同步形式。kafka应用一主多从进行音讯同步，主正本提供读写的能力，而从正本不提供读写，仅仅作为主正本的备份。 （十）Offset偏移。分区中的每一条音讯都有一个所在分区的偏移量，这个偏移量惟一标识了该音讯在以后这个分区的地位，并保障了在这个分区的程序性，不过不保障跨分区的程序性。 简略来说，作为音讯零碎的kafka实质上还是一个数据系统。既然是一个数据系统，那么就要解决两个基本问题： 当咱们把数据交给kafka的时候，kafka怎么存储；当咱们向kafka要回数据的时候，kafka怎么返回。 音讯如何存储(逻辑层面)目前大多数数据系统将数据存储在磁盘的格局有追加日志型以及B+树型。而kafka采纳了追加日志的格局将数据存储在磁盘上，整体的构造如下图： 追加日志的格局能够带来写性能的晋升（毕竟只须要往日志文件前面追加就能够了），然而同时对读的反对不是很敌对。为了晋升读性能，kafka须要额定的操作。 对于kafka的数据是如何存储的是一个比拟大的问题，这里先从逻辑层面开始。 （一）Topic+Partition的两层构造kafka对音讯进行了两个层级的分类，别离是topic主题和partition分区。 将一个主题划分成多个分区的益处是不言而喻的。多个分区能够为kafka提供可伸缩性、程度扩大的能力，同时对分区进行冗余还能够进步数据可靠性。 不同的分区还能够部署在不同的broker上，加上冗余正本就进步了可靠性。 （二）Offset对于追加日志格局，新来的数据只须要往文件开端追加即可。 对于有多个分区的主题来说，每一个音讯都有对应须要追加到的分区（分区器），这个音讯在所在的分区中都有一个惟一标识，就是offset偏移量： 这样的构造具备如下的特点： 分区进步了写性能，和数据可靠性；音讯在分区内保障程序性，但跨分区不保障。逻辑层面上晓得了kafka是如何存储音讯之后，再来看看作为使用者，如何写入以及读取数据。 如何写入数据接下来从使用者的角度来看看，如何将数据写入kafka。 （一）整体流程生产者将音讯写入kafka的整体流程如下图： 在生产端次要有两个线程：main和sender，两者通过共享内存RecordAccumulator通信。 各步骤如下： KafkaProducer创立音讯；生产者拦截器在音讯发送之前做一些筹备工作，比方过滤不符合要求的音讯、批改音讯的内容等；序列化器将音讯转换成字节数组的模式；分区器计算该音讯的指标分区，而后数据会存储在RecordAccumulator中；发送线程获取数据进行发送；创立具体的申请；如果申请过多，会将局部申请缓存起来；将筹备好的申请进行发送；发送到kafka集群；接管响应；清理数据。在音讯累加器RecordAccumulator中来进行缓存，缓存大小通过参数buffer.memory配置，默认32MB。累加器依据分区来治理每一个音讯，其中音讯又被组织成ProducerBatch的模式（通过batch.size管制大小，默认1MB），为了进步吞吐量升高网络申请次数，ProducerBatch中可能蕴含一个或多个音讯。 当音讯不多时一个Batch可能没有填满，但不会期待太长时间，能够通过linger.ms管制等待时间，默认0。增大这个值能够进步吞吐量，然而会减少提早。 当生产音讯的速度过快导致缓存满了的时候，持续发送音讯可能会有阻塞或异样，通过参数max.block.ms管制，默认60秒。 数据达到发送线程创立好申请之后，须要对其进行重新组合，依据须要发送到的broker节点分组，每个节点就是一个连贯，每个连贯能够缓存的申请数通过max.in.flight.requests.per.connection管制，默认5。每个申请的大小通过max.reqeust.size管制，默认1MB。 （二）发送形式音讯的发送有三种形式： 发后即忘（fire and forget）：只管发送不论后果，性能最高，可靠性也最差；同步（sync）：等集群确认音讯写入胜利再返回，可靠性最高，性能差很多；异步（async）：指定一个callback，kafka返回响应后调用来实现异步发送的确认。其中前两个是同步发送，后一个是异步发送。不过这里的异步发送没有提供callback的能力。 那么生产者发送音讯之后kafka怎么才算确认呢？这波及到acks参数： acks = 1, 默认值1，示意只有分区的leader正本胜利写入就算胜利；acks=0，生产者不须要期待任何服务端的响应，可能会失落数据；acks=-1或acks=all，须要全副处于同步状态的正本确认写入胜利，可靠性最强，性能也差。（三）生产者重要参数 如何读取音讯（一）生产音讯生产模式音讯的生产一般来说有两种模式：推模式和拉模式，而kafka中的生产是基于拉模式的。消费者通过一直地调用poll来获取音讯进行生产，基本模式如下（伪代码）： while(true) {    records := consumer.Pull()     for record := range records {          // do something with record     }}位移提交kafka中的音讯都有一个offset惟一标识，对于消费者来说，每生产完一个音讯须要告诉kafka，这样下次拉取音讯的时候才不会拉到已生产的数据（不思考反复生产的状况）。这个消费者已生产的音讯地位就是生产位移，比方： ...

什么是协调器协调器是用于协调多个消费者之间可能正确地工作的一个角色, 比方计算生产的分区调配策略，又或者消费者的退出组与来到组的解决逻辑, 有一点相似Kafka种的控制器的角色。协调器的作用协调器分为 生产组协调器 和 消费者协调器两种 生产组协调器组协调器(GroupCoordinator)能够了解为各个消费者协调器的一个中央处理器, 每个消费者的所有交互都是和组协调器(GroupCoordinator)进行的。 选举Leader消费者客户端解决申请加入组的客户端再均衡后同步新的调配计划保护与客户端的心跳检测治理消费者已生产偏移量,并存储至__consumer_offset中消费者协调器每个客户端都会有一个消费者协调器, 他的次要作用就是向组协调器发动申请做交互, 以及解决回调逻辑 向组协调器发动入组申请向组协调器发动同步组申请(如果是Leader客户端,则还会计算调配策略数据放到入参传入)发动离组申请放弃跟组协调器的心跳线程向组协调器发送提交已生产偏移量的申请协调器运行流程组协调器抉择逻辑生产组协调器的抉择kafka上的组协调器(GroupCoordinator)协调器有很多, 跟Controller不一样的是, Controller只有一个, 而组协调器(GroupCoordinator)是依据外部Topic __consumer_offset数量决定的，有多少个 __consumer_offset分区, 那么就有多少个组协调器(GroupCoordinator)。 然而每个分区可能有多个正本, 那么每个组协调器应该调配在哪里呢？ 每个__consumer_offset分区的Leader正本在哪个Broer上, 那么对应协调器就在哪里。 具体请看:寻找协调器FindCoordinatorRequest申请流程 如何确定每个生产组对应哪个协调器默认状况下, __consumer_offset有50个分区, 每个生产组都会对应其中的一个分区，对应的逻辑为 hash(group.id)%分区数； 消费者退出组流程JoinGroup客户端启动的时候, 或者重连的时候会发动JoinGroup的申请来申请加入的组中。 JoinGroup时序图 消费者客户端发动第一次申请, 协调器给它计算一个MemberId返回消费者客户端发动第二次申请,MemberId是刚刚失去的。生产组协调器解决申请,构建新的MemberMetadata元信息缓存到Group中。生产组协调器将状态流转为 PreparingRebalance初始化Generation数据,比方generationId+1, Group状态流转为 CompletingRebalance，当然如果以后Group的member是空的，则流转为 Empty ;将下面的数据组装一下为JoinGroupResult,返回给所有的Member, 当然如果是Leader Member的话, 还会额定给他所有Member的元信息(因为它要用这些数据去计算新的分区调配的数据。)消费者客户端拿到数据之后, 像生产组协调器发动SyncGroupRequest的申请, 如果是Leader Member的话, 则会依据分区策略去计算一下新的调配策略,并把数据带上发动SyncGroupRequest的申请。对于SyncGroupRequest请看: Kafka消费者 SyncGroupRequest 流程解析详情请看:Kafka消费者JoinGroupRequest流程解析 组协调器同步流程SyncGroup以后客户端都曾经实现JoinGroup之后, 客户端会收到JoinGroup的回调, 而后客户端会再次向组协调器发动SyncGroup的申请来获取新的调配计划。 然而在这一个过程中,新的调配计划是由Leader 客户端计算出来的,并且会同步给组协调器。 而后组协调器再把这些后果回调给泛滥客户端。 消费者离组流程LeaveGroup当消费者客户端关机/异样 时, 会触发离组LeaveGroup申请。 组协调器始终会有针对每个客户端的心跳检测, 如果监测失败,则就会将这个客户端踢出Group、 这个提出的流程也很简略 就是触发一下 再均衡。 心跳检测客户端退出组内后, 会始终放弃一个心跳线程,来放弃跟组协调器的一个感知。 并且组协调器会针对每个退出组的客户端做一个心跳监测，如果监测到过期, 则会将其踢出组内并再均衡。 分区调配策略Q&A1. 如果有多个客户端配置了不同的调配策略, 那么会以哪个配置失效呢？ 必定是须要生产组上面的所有成员都应用同一种调配策略来进行调配。所以GroupCoordinator就面临着抉择哪个调配策略。 抉择的逻辑如下 抉择所有Member都反对的调配策略在1的根底上,优先选择每个partition.assignment.strategy配置靠前的策略。请看上面的2个例子 Case-1 所有反对的调配策略为：roundrobin,rang每个consumer都在1的根底上,给本人排最后面的投票, consumer-0投roundrobin, consumer-1投rang, consumer-3投roundrobin；这样算下来 roundrobin是有2票的, 那么久抉择roundrobin为调配策略；Case-2 ...

下载镜像：docker pull provectuslabs/kafka-ui:latest拉起docker：docker run --name=kafka-ui -d \-e KAFKA_CLUSTERS_0_NAME=kafka_cluster \-e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=10.2x.5.xx:9092 -p 8080:8080 \provectuslabs/kafka-ui:latest

kafka中的exactly once semanticskafka0.11.0.0版本正式反对准确一次解决语义(exactly once semantics,EOS)，EOS次要体现在3个方面： 幂等producer:保障发送单个分区的音讯只会发送一次，不会呈现反复音讯事务：保障原子性地写入到多个分区，即写入到多个分区的音讯要么全胜利，要么失败回滚流解决EOS：流解决实质上可看成是‘读取-解决-写入’的管道。此EOS保障整个过程的操作是原子性。留神，这只实用kafka streams。下面3种EOS语义有着不同的利用范畴，幂等producer只能保障单分区上无反复音讯；事务能够保障多分区写入音讯的完整性；而流解决EOS保障的是端到端（E2E）音讯解决的EOS。不同的配置如下： 启用幂等producer：在producer程序中设置属性enable.idempotence=true，留神不要设置transactional.id，不要设置成null也不要设置成空字符串启用带伤反对：在producer程序中设置属性transcational.id为一个指定字符串，同时设置enable.idempotence=true启用流式解决EOS：在kafka streams程序中设置processing.guarantee=exactly_once接下来聊聊producer幂等性 producer幂等性producer幂等性指的是当发送同一条音讯时，数据在server端只会被长久化一次，数据不丢不重，然而这里的幂等是有条件的： 只能保障producer在单个会话内不丢不重，如果producer呈现重启是无奈保障幂等性的（在设置了幂等的状况下，是无奈获取之前的状态信息的，因而无奈做到跨会话级别的不丢不重）幂等性不能跨多个topic-partition，只能保障单个partition内的幂等性，当波及多个topic-partition时，这两头的状态并没有同步。如果须要跨会话、跨多个topic-partition的状况，须要应用kafka的事务性来实现。 幂等示例Properties props = new Properties();props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true");props.put("acks", "all"); // 当 enable.idempotence 为 true，这里默认为 allprops.put("bootstrap.servers", "localhost:9092");props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");KafkaProducer producer = new KafkaProducer(props);producer.send(new ProducerRecord(topic, "test");幂等实现原理kafka proudcer在实现幂等时有两个重要机制： PID（Producer ID)，用来标识每个producer clientsequence numbers,client发送的每条音讯都会带相应的sn,server端再依据这个值来判断数据是否反复PID 每个producer在初始化时都会被调配一个惟一的PID，这个PID对用户是通明的，没有裸露给用户。对于一个给定的PID，sequence number将会从0开始自增，每个topic-partition都会有一个独立的sequence number。producer在发送数据时，将会给每条音讯标识一个sn，而后server以此来验重。这里的PID是全局惟一的，如果producer重启后会被调配一个新的PID，这也是幂等性无奈做到跨会话的一个起因。 PID申请与治理 producer向broker发送一个申请获取PID（server端会抉择一台连贯数量起码的broker进行解决），broker收到申请PID的申请后，会尝试在ZK创立一个/latest_producer_id_block节点，每个broker向ZK申请一个PID段后，都会将本人申请的PID段信息写入到这个节点，这样当其余broker再申请PID段时，会首先读取这个节点的信息，而后依据block_end抉择一个PID段，最初再将信息写回到ZK的这个节点里，这个节点信息内容如下： {"version":1,"broker":35,"block_start":"4000","block_end":"4999"}broker与ZK交互流程： 先从ZK的/latest_producer_id_block节点读取最新曾经调配的PID段信息如果该节点不存在，间接从0开始调配，抉择0-1000的PID段（PidBlockSize默认为1000）如果该节点存在，读取其中数据，依据block_end抉择这个PID段在抉择了相应的PID段后，将这个PID段信息写回到ZK的这个节点中，如果写入胜利，证实PID段申请胜利；如果失败证实此时可能其它的broker曾经更新了这个节点，就须要从步骤1从新开始执行针对第4点再阐明下，在回写ZK节点时会判断以后节点的zkVersion是否与第1点里获取的zkVersion雷同，如果雷同才能够写入胜利，不同阐明这个节点被批改了则会写入失败。 client幂等时发送流程java producer(区别于scala producer)是双线程设计，分为用户主线程与sender线程，前者调用send办法将音讯写入到producer的内存缓冲区，即RecordAccumulator中，后者会定期从RecordAccumulator中获取音讯并将音讯纳入不同的batch中发送到对应的broker上。在幂等producer中，用户主线程的逻辑变动不大。send办法仍然是将音讯写入到RecordAccumulator。而Sender线程却有着很大的改支。 用户线程调用send办法将数据增加到RecordAccumulator中，增加时会判断是否须要新建一个ProducerBatch，这时的ProducerBatch还是没有PID和sequence numbersender线程在执行时，判断以后PID是否须要重置：如果有音讯重试屡次人失败最初因为超时而被移除，这时的seqeunce number有局部曾经调配进来，那这是不容许发送的。sender线程阻塞获取PID在ProducerBatch里设置相应的PID与sequence number，进行发送。server端解决producer申请server端会次要测验申请里是否有PID信息，校验batch是否反复： 如果PID不存在，那么判断sequence number是否从0开始，是的话，在缓存中记录PID的meta信息（PID,epoch,sequence number），并执行写入操作，否则返回UnknowProducerIdException(PID在server端曾经过期或这个PID写的数据曾经过期，但producer还在接着上次的sn发送数据)如果PID存在，先查看PID epoch与server端记录的是否雷同如果不同，且sn不是从0开始，那么返回OutOfOrderSequenceException异样如果雷同，那么依据缓存中记录的最近一次sn(currentLastSeq)查看是否为连贯，不连贯的状况下那么返回OutOfOrderSequenceException异样最初总结一下幂等音讯解决流程： 每个producer会被调配一个PID,SNproducer与broker端都有<PID,PartitionID>与SN的映射关系producer每发送一条音讯后就将对应的分区序列号加一broker会比拟序列号,如果new SN < old SN+1，阐明是过期的，会摈弃这条数据；如果new SN > old SN+1,阐明有音讯失落了，抛出异样。参考文章：Kafka 事务性之幂等性实现Kafka幂等性及事务对于Kafka幂等producer的探讨

kafka leader选举有三种： broker leader选举正本leader选举生产组leader选举broker leader选举 一个broker leader能够了解为一台机器，broker leader次要负责监控治理分区和正本的状态，在分区与正本状态发生变化时做出相应操作。比方：分区的leader正本呈现了故障，那么broker leader须要进行分区leader正本的选举。Broker leader称为Controller控制器。 选举过程 broker们会向zk进行节点/controller的创立，谁先创立胜利谁就是leader，并将本人的brokerId写入节点的值中，如果其它的broker发现节点的值不为-1，则放弃选举成为follower。 避免脑裂 当旧的leader从新上线后，而集群中新的leader曾经选出来了，整个集群就有两个leader，这就是脑裂。如何防止这种状况呢？broker在创立controller的时候，还会创立一个/controller epoch，每当新的节点成为控制器，就会主动加1，这样就避免了旧的leader的影响，如果它给ZK的值小于ZK中的epoch值，ZK会回绝它成为leader. controller的性能 监听分区变动，正本选举工作，重分区工作监听主题变动监听broker变动auto.leader.rebalance.enble(kafka的平衡机制)如果开启，则定期进行leader选举(不倡议开启，对消费者影响较大，见auto.leader.rebalance.enable阐明)controller须要监听zk上数据变动，并同步给其它节点，这些数据有：分区数变动，新的leader正本等。在controller呈现之前，所有节点都须要订阅ZK的事件，这会有羊群效应。有了controller之后，会通过一个LindBlockQueue，而后应用一个专有的线程对解决，来防止羊群效应的问题。 分区正本leader选举 分区正本leader选举触发状况： 分区正本创立或分区高低线的时候分区正本重新分配，因为须要放弃肯定负载平衡（分区的时候，数据的平衡保障不了）broker节点宕机消费者leader选举 随机的形式，从一个hash列表中取一个消费者作为leader。leader的选举是因为某一个消费者leader下线了，这时候就呈现同一组中消费者数量的变动，这就不得不提到生产组的再平衡。因为一些起因，分区没有人生产了，那么就须要将它们重新分配给新的消费者或者存活着的消费者，这个再平衡的过程会引起stop the world的状况。 哪些状况会产生再平衡的情景呢？ 同一组中消费者数量发生变化主题的分区数发生变化，加减分区组协调者节点下线这里再聊一下分区的调配策略。 RangeAssignor:针对一个主题下的消费者和分区按字典排序，而后partition size / consumer size = m 并且partition size % consumer size = n ，那么前n个生产都调配到m+1,其它消费者调配到m。RoundRobinAssignor(轮询)：将生产组内所有消费者和所有主题按字典程序排序，而后将分区顺次分给消费者。StickyAssignor:在初始状况下，它与轮询的后果是一样的，然而当呈现重新分配的时候，它会在尽可能保障分区不变动地位的状况下保障分区的平衡。分区地位尽可能不变动保障最终后果平衡最初再看几个问题 一，kafka为什么不反对主从读写1，首先第一个问题，主从读写解决了什么问题 解决了节点压力的问题，主节点写数据，从节点读数据，然而kafka利用partition的形式，曾经做到将同一个topic的数据扩散到不同节点了。 2，而后主从读写带来了什么问题 主从的模式带来的数据提早，从节点总是会落后主节点ms级别，甚至s级别。然而在kafka除了用做削峰，异步的中间件外，它还是流式解决中间件，比方Flink,Spark，Spark的实时性要求不高，它是一批一批解决，缩小批次间的距离来实现假的实时性能；但Flink对实时性要求比拟高。在实时性要求高的场景下，如果呈现秒级甚至因为网络的起因，呈现了分区级别的提早，这是不能承受的。 二，ISR 1，音讯从生产者写入kafka，首先写入正本leader，而后follower正本同步leader的音讯。同步音讯落后的正本会被踢出ISR，所以ISR的概念是，能追赶上leader的所有正本。 2，哪些状况会落后于leader？ 正本是新退出的，直到它同步与leader统一能力退出ISR正本卡死，正本机器死亡或GC卡死正本同步因为网络或其它起因导致提早3，怎么判断正本落后？replica.lag.time.max.ms参数：如果正本落后超过这个工夫就断定为落后了，直到它回来。音讯复制分为异步和同步，ISR是动静的，有进有出。

kafka server在启动的时候会初始化SocketServer、KafkaApis 和 KafkaRequestHandlerPool这三个对象，它们是kafka网络解决模型的次要组成部分，kafka所有的申请都是通过TCP网络以socket的形式进行通信的。该网络模型是基于java NIO机制实现的，依据其特点能够简略演绎为1+N+M模型，它与Reactor模式相似，其残缺流程图如下： 别离来看下Acceptor,Processor,KafkaRequestHandle这三局部： 1个Acceptor线程，负责监听socket新的连贯申请，注册了了OP_ACCEPT事件，将新的连贯依照round robin形式交给对应的Processor线程解决。N个Processor线程，其中每个Processor都有本人的selector，它会向Acceptor调配的SocketChannel注册相应的OP_READ事件，N的大小可由num.networker.threads配置，默认为3M个KafkaRequestHandler线程解决申请，并将解决的后果返回给Processor线程对应的response queue,由Processor将解决的后果返回给相应的申请发送者，M的大小可由num.io.threads配置，默认为8再对着上图说下流程： Acceptor监听到新连贯，而后按round robin的形式交给对应的Processor进行解决。Processor在SocketChannel上注册OP_READ事件并期待事件产生当申请到来时，Processor会将申请放入到一个Request Queue中，这是所有Processor共有的一个队列KafkaRequestHandler申请从Reqeust Queue中取出，并调用相应KafkaApis进行解决（如果是producer生产申请，则将音讯写入到底层的磁盘日志中；如果是fetch申请，则从磁盘或页缓存中读取音讯）解决的后果会放入到Processor对应的Response Queue中（每个申请都有标识它们来自哪个Processor），Request Queue的数量与Processor数量统一Processor从对应Response Queue中取出reponse并返回给对应的请求者。须要阐明下：Request Queue是所有Processor专用的一个队列，而Response Queue则是与Processor一一对的，因为每个Processor监听的SocketChannel并不是同一批，如果私有一个Response Queue,那么这N个Processor的selector就须要监听所有的SocketChannel，而Processor与Response Queue一一对应则Processor相应的selector只须要关注调配给本人的SocketChannel即可。 再补充下Purgatory组件，如下图： Purgatory组件是用来缓存延时申请（Delayed Request）的，所谓延时申请，就是那些一时未满足条件不能立即解决的申请，比方设置了acks=all的producer申请，一旦设置了acks=all，那么该申请就必须期待ISR中所有正本都接管了音讯后能力返回，此时算是该申请的IO线程就必须期待其余broker的写入后果。当申请不能立即解决时，它就会暂存在Purgatory中，稍后一旦满足了条件，IO线程会持续解决该申请，并将Response放入对应网络线程的响应队列中。 最初再来一张kafka的结构图： 参考文章：深入浅出kafka原理-4-kafka网络机制原理

上一篇有很大一部分也提到了正本同步机制，但有些细节点没提到，这里再转载一篇文章来聊聊正本同步机制。 正本同步机制咱们晓得,kafka每个topic的partition会有N个正本，kafka通过多正本机制实现故障主动转移，当kafka集群中一个broker生效状况下，会在N个正本中从新选出一个broker作为leader提供服务，从而做到高可用。N个正本中，其中一个为leader，其余的都为follower，leader解决partition的所有读写申请，follower会定期地复制leader上的数据。 Kafka提供了数据复制算法，如果leader产生故障或挂掉，Kafka确保从同步正本列表中选举一个正本为leader，新leader被选举并被承受客户端的音讯写入。leader负责保护ISR（In-Sync Replicas的缩写，示意正本同步队列）中所有音讯。当producer发送一条音讯到broker后，leader写入音讯，并复制到所有follower。音讯提交之后才被胜利复制到所有的同步正本。音讯复制提早受最慢的follower限度，kafka会检测慢正本，如果follower“落后”太多或者失败，leader将会把他从ISR中删除。 正本同步队列ISR所谓同步，必须满足两个条件： 正本节点必须能与zookeeper放弃会话（心跳机制）副本能复制leader上的所有写操作，并且不能落后太多（卡主或滞后的正本管制由replica.lag.time.max.ms配置）默认状况下，Kafka topic的replica数量为1，即每个partition都有一个惟一的leader，为了确保音讯的可靠性，通常利用中将其值（由broker的参数offsets.topic.replication.factor指定）大小设定为1。所有的正本（replicas）统称为AR (Assigned Replicas）。ISR是AR的一个子集，由leader保护ISR列表，follower从Leader同步数据有一些提早，任意一个超过阈值都会把follower踢出ISR，存入OSR（Outof-Sync Replicas）列表，新退出的follower也会先寄存到OSR中。AR = ISR + OSR HW（HighWatermark）俗称高水位，取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能生产到HW所在的地位。另外每个replica都有HW，leader和follower各自负责更新本人的HW的状态。对于leader新写入的音讯，consumer不能立刻生产，leader会期待该音讯被所有ISR中的replicas都同步后，才更新HW，此时音讯能力被consumer生产，这样就保障了如果Leader所在的broker生效，该音讯仍可从新选举的leader中获取。对于来自外部的broker的读取申请，没有HW的限度。 下图具体阐明了当producer生产音讯到broker后，ISR及HW和LEO(log end offset)的流转过程： 由此可见，Kafka的复制机制既不是齐全的同步复制，也不是单纯的异步复制。事实上，同步机制要求所有能工作的follower都复制完，这条音讯才会被commit，这种复制形式极大的影响了吞吐率。而异步复制形式下，follower异步的从leader复制数据，数据只有被Leader写入log就被工作曾经commit，这种状况下如果follower没有全复制完，落后与Leader，忽然leader宕机，则会丢数据。而Kafka这种应用ISR的形式则很好的平衡了确保数据不失落以及吞吐率。 Kafka的ISR治理最终都会反馈到Zookeeper节点上，具体位置为：/brokers/topics/[topic]/partitions/[partition]/state。目前有两个中央会对这个Zookeeper节点进行保护： Controller保护：Kafka集群中的其中一个Broker会被选举为Controller，次要负责Partition治理和正本状态治理，也会执行相似于重调配partition之类的治理工作。在合乎某些特定条件下，Controller下的LeaderSelector会选举新的leader, ISR和新的leader_epoch及controller_epoch写入Zookeeper的相干节点中。同时发动LeaderAndIsrRequest告诉所有的replicas。leader来保护：leader有独自的线程定期检查ISR中follower是否脱离ISR，如果发现ISR变动，则会将新的ISR的信息返回到Zookeeper的相干节点中。正本不同的异常情况： 慢正本：在肯定周期时间内，follower不能追赶上leader。最常见的起因之一是IO瓶颈导致follower追加复制音讯速度鳗鱼从leader拉取速度正本卡住：在肯定周期时间内，follower进行从leader拉取申请。follower replica卡住了是因为GC暂停或follower生效或死亡。新启动正本：当用户给topic减少正本因子时，新的follower不再同步正本列表中，直到他们齐全追赶上leader日志。

kafka里的HW（High Watermark）是与音讯offset相干的一个概念，本文会从上面这四个方面来开展。 HW的作用HW的更新机制正本同步机制解析leader epochHW的作用在kafka中，HW的作用次要有2个： 定义音讯的可见性，即用来标识分区下的哪些音讯是能够被消费者生产的帮忙kafka实现正本同步 假如这是某个分区Leader正本的HW图，咱们能够分明地看到‘已提交音讯’与‘未提交音讯’，在开展之前先解释下何为已提交音讯： 当kafka的若干个broker胜利地接管到一条音讯并写入到日志文件后，它们会通知生产者这条音讯已胜利提交，那么这条音讯就是‘已提交音讯’。留神这里应用的是若干个broker，这个是由使用者配置决定的，使用者能够配置只有有一个broker胜利保留该音讯就算是已提交，也能够配置令所有broker都胜利保留该音讯才算是已提交。回到HW上来，在上图中已提交的音讯才会对消费者可见，才会被消费者拉取生产。位移值等于高水位的音讯也属于未提交音讯，即高水位上的音讯是不能被消费者生产的。 图中还有一个日志末端的概念，Log End Offset(LEO)。它示意正本写入下一要音讯的位移值。留神，数字 15 所在的方框是虚线，这就阐明，这个正本以后只有 15 条音讯，位移值是从 0 到 14，下一条新音讯的位移是 15。显然，介于高水位和 LEO 之间的音讯就属于未提交音讯。这也从侧面通知了咱们一个重要的事实，那就是：同一个正本对象，其高水位值不会大于 LEO 值。 高水位和LEO是正本对象的两个重要属性。kafka所有正本都有对应的高水位和LEO值，而不仅仅是leader正本。只不过leader正本比拟非凡，kafka应用leader正本的高水位来定义所在分区的高水位。换句话说，分区的高水位就是其leader正本的高水位。

本文次要内容有： 日志治理相干实现类日志刷盘日志清理日志治理相干实现类kafka的日志治理是通过LogManager类实现的，它的次要作用是日志的创立、检索、清理。 kafkaServer启动LogManager线程 LogManager线程是在kafka节点服务启动的时候启动的，代码如下： //kafka.server.KafkaServerdef startup() { try { info("starting") /* start log manager */ //创立LogManager对象 logManager = createLogManager(zkUtils.zkClient, brokerState) //启动LogManager线程 logManager.startup() } catch { case e: Throwable => fatal("Fatal error during KafkaServer startup. Prepare to shutdown", e) isStartingUp.set(false) shutdown() throw e }}阐明，初始化LogManager的过程中会加载所有日志分区，对应办法为loadLogs(),在加载日志分区过程中会调用loadSegments()加载该分区所有的Segment文件，应用是的线程池进行加载的。 LogManager启动 在所有分区日志都加载实现后，KafkaServer调用startup()办法启动LogManager线程，在这个过程中会启动四个定时工作。 def startup() { /* Schedule the cleanup task to delete old logs */ if(scheduler != null) { //note: 定时清理过期的日志 segment,并保护日志的大小 info("Starting log cleanup with a period of %d ms.".format(retentionCheckMs)) scheduler.schedule("kafka-log-retention", cleanupLogs, delay = InitialTaskDelayMs, period = retentionCheckMs, TimeUnit.MILLISECONDS) //note: 定时刷新还没有写到磁盘上日志 info("Starting log flusher with a default period of %d ms.".format(flushCheckMs)) scheduler.schedule("kafka-log-flusher", flushDirtyLogs, delay = InitialTaskDelayMs, period = flushCheckMs, TimeUnit.MILLISECONDS) //note: 定时将所有数据目录所有日志的检查点写到检查点文件中 scheduler.schedule("kafka-recovery-point-checkpoint", checkpointRecoveryPointOffsets, delay = InitialTaskDelayMs, period = flushCheckpointMs, TimeUnit.MILLISECONDS) //note: 定时删除标记为 delete 的日志文件 scheduler.schedule("kafka-delete-logs", deleteLogs, delay = InitialTaskDelayMs, period = defaultConfig.fileDeleteDelayMs, TimeUnit.MILLISECONDS) } //note: 如果设置为 true， 主动清理 compaction 类型的 topic if(cleanerConfig.enableCleaner) cleaner.startup()}四个定时工作： ...

本文次要有两大块内容： patition里的segment file如何查找一条音讯先看下几个根本的概念： partition:topic物理上的分组，一个topic下能够有多个partition，每个partion是有序的segment:每个patition由多个segment file组成offset:partition中的每个音讯都有一个间断的序列号叫做offset，用于标识惟一一条partition里的音讯message:kafka中最小的存储单位，a commit log.kafka的message是以topic为根本单位，不同的topic之间的互相独立的，每个topic又能够分为几个不同的partition，每个partition存储一部分message。 patition里的segment filepartition里的segment file是以文件夹的模式存储在Broker上的，它们大小相等（具体大小能够通过config/server.properties中进行设置）。 segment file的特点 组成。由两局部组成，别离是index file与data file，这两个文件一一对应，后缀别离为.index与.log命名。partition的第一个segment从0开始，后续每个segment文件名为上一个segment文件最初一条音讯的offset，20位数字字符长度，有余用0填充。 index file与data file的关系先看一张图索引文件中存储着元数据，数据文件存储着音讯，依据索引文件中的元数据咱们能够疾速定位到数据文件里相应的音讯。以索引文件中的3,497为例，3指的是在数据文件中的第3个segment，它是一个逻辑地址；而497指的是该音讯在segment里的物理偏移地址为497。从上图咱们还能够晓得在00000000000000368769.log文件里的Message368772这个segment在全局partition示意第368772个message，也就是通过文件名咱们就能够晓得它所在的全局offset。 data file物理构造 在图里咱们能够分明地晓得data file里记录着音讯的大小(size)与具体内容(payload)等信息 如何查找一条音讯partition的音讯文件为什么要别离生成index file与data file这两个文件呢？很大一部分起因就是为了不便音讯的查找。这里也能看出kafka能够高效查找音讯的两个伎俩：分段与索引。 数据文件的分段 这个是比拟好了解的，退出有100条message，它们的offset是从0到99，假如将数据文件分为5段，第一段为0-19，第二段为20-39，顺次类推，每段放在一个独自的数据文件外面，数据文件以该段中最小的offset命名。这样在查找指定offset的Message的时候，用二分查找就能够定位到该Message在哪个段中。 为数据文件建索引 数据文件分段使得能够在一个较小的数据文件中查找对应offset的message了，然而这仍然须要程序扫描能力找到对应offset的message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建设了索引文件，文件名与数据文件的名字是一样的，只是文件扩大名为.index。 索引文件中蕴含若干个索引条目，每个条目示意数据文件中一条message的索引。索引蕴含两个局部（均为4个字节的数字），别离为绝对offset和position。 绝对offset：因为数据文件分段当前，每个数据文件的起始offset不为0，绝对offset示意这条message绝对于其所属数据文件中最小的offset的大小。举例，分段后的一个数据文件的offset是从20开始，那么offset为25的message在index文件中的绝对offset就是25-20 = 5。存储绝对offset能够减小索引文件占用的空间。position：示意该条message在数据文件中的相对地位。只有关上文件并挪动文件指针到这个position就能够读取对应的message了。通过offset查找message 假如咱们想读取offset=368776的message(参考第图二) 查找segment file00000000000000000000.index示意最开始的文件，起始偏移量(offset)为0.第二个文件00000000000000368769.index的音讯量起始偏移量为368770 = 368769 + 1.同样，第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1，其余后续文件顺次类推，以起始偏移量命名并排序这些文件，只有依据offset 二分查找文件列表，就能够疾速定位到具体文件。当offset=368776时定位到00000000000000368769.index|log 通过segment file查找message通过第一步定位到segment file，当offset=368776时，顺次定位到00000000000000368769.index的元数据物理地位（依据00000000000000368769.index这个文件是partition里的第几个文件）和00000000000000368769.log的物理偏移地址（依据索引文件里的物理偏移量），而后再通过00000000000000368769.log程序查找直到offset=368776为止。 segment index file并没有为数据文件中的每条message建设索引，而是采取稠密索引存储形式，每隔肯定字节的数据建设一条索引，它缩小了索引文件大小，通过map能够间接内存操作，稠密索引为数据文件的每个对应message设置一个元数据指针,它比浓密索引节俭了更多的存储空间

1. 前言 起源是某个客户线上环境的一次OOM，据说这种诡异的OOM曾经第二次了。首先形容一下OOM的相干信息： 堆内存13G；应用G1垃圾收集器；OOM后主动生成的dump文件7G；利用大抵性能是生产kafka数据，通过一些业务解决而后再次发回kafka【单条音讯据说32M左右】客户的疑点： 堆内存13G，dump文件7G，明明内存是够的，怎么就OOM了？因为线上环境问题，不能随便复盘调试，只有一份内存Dump文件能够剖析。 2. 线上Dump文件剖析2.1 问题点1 - kafka的RecordAccumulator占用大量内存 此处无截图（遗记了），脑补。一度狐疑是kafka的本地缓存导致的OOM。个别状况RecordAccumulator和KafkaProducer是一一对应的【KafkaProducer每次初始化的时候在结构行数中创立RecordAccumulator实例】。然而客户说KafkaProducer是存在ThreadLocal中的，不会无限度创立，即RecordAccumulator也不会无限度创立。 先保留此处问题可能性（而且RecordAccumulator透露的话也无法解释：明明内存是够的，怎么就OOM了？这个疑点）。 2.2 问题点1 - 线程栈里的OOM信息 发现kafka producer的业务线程栈有OOM的内容： 2.3 问题点2 - 线程栈中有kafka音讯发送失败的信息kafka producer回调函数中呈现RecordTooLargeExeception报错 kafka producer开始记录谬误日志 2.4 问题点3 - RecordTooLargeExeception 剖析完一圈内存Dump，我给了本人一个大胆的猜测，会不会是理论的堆内存够的，而是触发了某个别的什么条件，导致显示的抛出了OutOfMemoryError的报错。 带着这个纳闷，还是把注意力放在了线程栈上，再认真一看，忽然悟出了点什么。线程栈中是打印谬误日志的过程中抛出的OOM报错。而且是在构建日志音讯的过程中进行字符串拼接，进而进行StringBuilder扩容引起的数组拷贝，而后就是OOM了。至此，我把留神里转移到了StringBuilder上。 3. 扒一扒StringBuilder扩容 带着下面所以的猜测，认真翻阅了一下StringBuilder中append()的源码以及扩容机制。 在StringBuilder中，有一个字符数组叫value【申明在父类AbstractStringBuilder中】，这个才是用来寄存字符串内容的（在String类中同样有）。 StringBuilder.append()办法最终会调用父类的java.lang.AbstractStringBuilder#append(java.lang.String)办法，源码如下： public AbstractStringBuilder append(String str) { if (str == null) return appendNull(); // 获取要追加的字符串长度 int len = str.length(); // 查看StringBuilder中字符数组的容量，以确保能够追加胜利 ensureCapacityInternal(count + len); str.getChars(0, len, value, count); count += len; return this; }接下来看ensureCapacityInternal()办法： ...

有时候因为特定的业务须要,咱们的kafka分区的磁盘可能不够,这个时候咱们须要本身删除磁盘数据或者应用脚本定时检测删除生产完的磁盘数据。然而有一个重要的点是:咱们须要应用同一个topic主题，所以在删除数据之后咱们须要重置这些主题的offset。咱们以kafka容器集群部署形式为例。 查看分区应用主题大小1.进入kafka集群docker机器 docker exec -it kafka bash;2.进入数据目录下：有时候咱们的磁盘是挂载到本地磁盘的，所以咱们也能够在本地磁盘查看 cd /kafka/kafka-logs-kafka13.查看topic对应文件大小: du -sh *;呈现： 532G test-1532G test-6所以咱们的test主题的数据量比拟大。 4.而后进行服务,让对应的topic数据生产结束咱们在咱们的kafka-manager上进行操作:删除主题，在从新创立主题，设置分区。 5.重置生产group的偏移量lag bin/kafka-consumer-groups.sh --bootstrap-server 192.168.100.11:9092 --group process-group-news --topic test --to-earliest --reset-offsets --execute6.查看某个kafka生产组的分区offset状况 ./kafka-consumer-groups.sh --bootstrap-server 192.168.100.11:9092 --describe --group process-group-news7.查看数据总量 ./bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.100.11:9092 --topic test --time -18.删除主题 ./bin/kafka-topics.sh --delete --topic test --bootstrap-server 192.168.100.11:90929.删除生产组 ./bin/kafka-consumer-groups.sh --bootstrap-server 192.168.100.11:9092 --describe --group process-group-news10.获取1条数据 ./bin/kafka-console-consumer.sh --bootstrap-server 192.168.100.11:9092 --from-beginning --topic test --max-messages 1;

一、前言在现在的分布式环境时代，任何一款中间件产品，大多都有一套机制去保障一致性的，Kafka 作为一个商业级消息中间件，音讯一致性的重要性可想而知，那 Kafka 如何保障一致性的呢？本文从高水位更新机制、正本同步机制以及 Leader Epoch 几个方面去介绍 Kafka 是如何保障一致性的。 二、HW 和 LEO要想 Kafka 保障一致性，咱们必须先理解 HW（High Watermark）高水位和 LEO（Log End Offset）日志末端位移，看上面这张图你就清晰了： 高水位的作用： 定义音讯可见性，即用来标识分区下的哪些音讯是能够被消费者生产的。帮忙 Kafka 实现正本同步这里咱们不探讨 Kafka 事务，因为事务机制会影响消费者所能看到的音讯的范畴，它不只是简略依赖高水位来判断。它依附一个名为 LSO（Log Stable Offset）的位移值来判断事务型消费者的可见性。 日志末端位移的作用： 正本写入下一条音讯的位移值数字 15 所在的方框是虚线，这就阐明，这个正本以后只有 15 条音讯，位移值是从 0 到 14，下一条新音讯的位移是 15。介于高水位和 LEO 之间的音讯就属于未提交音讯。这也反馈出一个事实，那就是：同一个正本对象，其高水位值不会大于 LEO 值。高水位和 LEO 是正本对象的两个重要属性。Kafka 所有正本都有对应的高水位和 LEO 值，而不仅仅是 Leader 正本。只不过 Leader 正本比拟非凡，Kafka 应用 Leader 正本的高水位来定义所在分区的高水位。换句话说，分区的高水位就是其 Leader 正本的高水位。 三、HW 和 LEO 的更新机制当初，咱们晓得了每个正本对象都保留了一组高水位值和 LEO 值，但实际上，在 Leader 正本所在的 Broker 上，还保留了其余 Follower 正本的 LEO 值，请看下图： ...

vivo 互联网服务器团队-You Shuo 正本迁徙是Kafka最高频的操作，对于一个领有几十万个正本的集群，通过人工去实现正本迁徙是一件很艰难的事件。Cruise Control作为Kafka的运维工具，它蕴含了Kafka 服务高低线、集群内负载平衡、正本扩缩容、正本缺失修复以及节点降级等性能。显然，Cruise Control的呈现，使得咱们可能更容易的运维大规模Kafka集群。 备注：本文基于 Kafka 2.1.1发展。一、 Kafka 负载平衡1.1 生产者负载平衡Kafka 客户端能够应用分区器根据音讯的key计算分区，如果在发送音讯时未指定key，则默认分区器会基于round robin算法为每条音讯调配分区； 否则会基于murmur2哈希算法计算key的哈希值，并与分区数取模的到最初的分区编号。 很显然，这并不是咱们要探讨的Kafka负载平衡，因为生产者负载平衡看起来并不是那么的简单。 1.2 消费者负载平衡思考到消费者高低线、topic分区数变更等状况，KafkaConsumer还须要负责与服务端交互执行分区再调配操作，以保障消费者可能更加平衡的生产topic分区，从而晋升生产的性能； Kafka目前支流的分区调配策略有2种(默认是range，能够通过partition.assignment.strategy参数指定)： range: 在保障平衡的前提下，将间断的分区调配给消费者，对应的实现是RangeAssignor；round-robin：在保障平衡的前提下，轮询调配，对应的实现是RoundRobinAssignor；0.11.0.0版本引入了一种新的分区调配策略StickyAssignor，其劣势在于可能保障分区平衡的前提下尽量放弃原有的分区调配后果，从而防止许多冗余的分区调配操作，缩小分区再调配的执行工夫。无论是生产者还是消费者，Kafka 客户端外部曾经帮咱们做了负载平衡了，那咱们还有探讨负载平衡的必要吗？答案是必定的，因为Kafka负载不均的次要问题存在于服务端而不是客户端。 二、 Kafka 服务端为什么要做负载平衡咱们先来看一下Kafka集群的流量散布（图1）以及新上线机器后集群的流量散布（图2）： 从图1能够看出资源组内各broker的流量散布并不是很平衡，而且因为局部topic分区集中散布在某几个broker上，当topic流量突增的时候，会呈现只有局部broker流量突增。 这种状况下，咱们就须要扩容topic分区或手动执行迁挪动操作。 图2是咱们Kafka集群的一个资源组扩容后的流量散布状况，流量无奈主动的摊派到新扩容的节点上。此时，就须要咱们手动的触发数据迁徙，从而能力把流量引到新扩容的节点上。 2.1 Kafka 存储构造为什么会呈现上述的问题呢？这个就须要从Kafka的存储机制说起。 下图是Kafka topic的存储构造，其具体层级构造形容如下： 每个broker节点能够通过logDirs配置项指定多个log目录，咱们线上机器共有12块盘，每块盘都对应一个log目录。每个log目录下会有若干个[topic]-[x]字样的目录，该目录用于存储指定topic指定分区的数据，对应的如果该topic是3正本，那在集群的其余broker节点上会有两个和该目录同名的目录。客户端写入kafka的数据最终会依照工夫程序成对的生成.index、.timeindex、.snapshot以及.log文件，这些文件保留在对应的topic分区目录下。为了实现高可用目标，咱们线上的topic个别都是2正本/3正本，topic分区的每个正本都散布在不同的broker节点上，有时为了升高机架故障带来的危险，topic分区的不同正本也会被要求调配在不同机架的broker节点上。 理解完Kafka存储机制之后，咱们能够清晰的理解到，客户端写入Kafka的数据会依照topic分区被路由到broker的不同log目录下，只有咱们不人工干预，那每次路由的后果都不会扭转。因为每次路由后果都不会扭转，那么问题来了： 随着topic数量一直增多，每个topic的分区数量又不统一，最终就会呈现topic分区在Kafka集群内调配不均的状况。 比方：topic1是10个分区、topic2是15个分区、topic3是3个分区，咱们集群有6台机器。那6台broker上总会有4台broker有两个topic1的分区，有3台broke上有3个topic3分区等等。 这样的问题就会导致分区多的broker上的出入流量可能要比其余broker上要高，如果要思考同一topic不同分区流量不统一、不同topic流量又不统一，再加上咱们线上有7000个topic、13万个分区、27万个正本等等这些。 这么简单的状况下，集群内总会有broker负载特地高，有的broker负载特地低，当broker负载高到肯定的时候，此时就须要咱们的运维同学染指进来了，咱们须要帮这些broker减减压，从而间接的晋升集群总体的负载能力。 当集群整体负载都很高，业务流量会持续增长的时候，咱们会往集群内扩机器。有些同学想扩机器是坏事呀，这会有什么问题呢？问题和下面是一样的，因为发往topic分区的数据，其路由后果不会扭转，如果没有人工干预的话，那新扩进来机器的流量就始终是0，集群内原来的broker负载仍然得不到加重。 三、如何对 Kafka 做负载平衡3.1 人工生成迁徙打算和迁徙如下图所示，咱们模仿一个简略的场景，其中的T0-P0-R0示意topic-分区-正本，假如topic各分区流量雷同，假如每个分区R0正本是leader。 咱们能够看到，有两个topic T0和T1，T0是5分区2正本（出入流量为10和5），T1是3分区2正本（出入流量为5和1），如果严格思考机架的话，那topic正本的散布可能如下： 假如咱们当初新扩入一台broker3(Rack2)，如下图所示：因为之前思考了topic在机架上的散布，所以从整体上看，broker2的负载要高一些。 咱们当初想把broker2上的一些分区迁徙到新扩进来的broker3上，综合思考机架、流量、正本个数等因素，咱们将T0-P2-R0、T0-P3-R1、T0-P4-R0、T1-P0-R1四个分区迁徙到broker3上。 看起来还不是很平衡，咱们再将T1-P2分区切换一下leader： 经验一番折腾后，整个集群就平衡许多了，对于下面迁徙正本和leader切换的命令参考如下： Kafka 正本迁徙脚本# 正本迁徙脚本：kafka-reassign-partitions.sh# 1. 配置迁徙文件$ vi topic-reassignment.json{"version":1,"partitions":[{"topic":"T0","partition":2,"replicas":[broker3,broker1]},{"topic":"T0","partition":3,"replicas":[broker0,broker3]},{"topic":"T0","partition":4,"replicas":[broker3,broker1]},{"topic":"T1","partition":0,"replicas":[broker2,broker3]},{"topic":"T1","partition":2,"replicas":[broker2,broker0]}]}# 2. 执行迁徙命令bin/kafka-reassign-partitions.sh --throttle 73400320 --zookeeper zkurl --execute --reassignment-json-file topic-reassignment.json# 3. 查看迁徙状态/革除限速配置bin/kafka-reassign-partitions.sh --zookeeper zkurl --verify --reassignment-json-file topic-reassignment.json ...

对于Kafka的根本意识在我的项目中应用到了Kafka作为音讯队列中间件以同步容器状态，然而对于为什么应用Kafka，以及与其余的音讯队列中间件有什么区别不甚了解，因而撰写此文，作为日后学习Kafka的入门文章音讯队列的简介音讯队列的基本功能解耦 各个服务之间不是间接的调用关系，而是应用音讯队列进行解耦，音讯的生产者不必关系音讯如何被生产，消费者也不必关怀音讯如何被生产 能够联想下线程池中的阻塞工作队列异步 对于一些同步操作，比拟消耗工夫，导致响应会比较慢，如果不要求强实时性，就能够应用音讯队列将其转为异步执行的工作 比方短信服务、邮件服务等等除了思考到同步操作耗时之外，还有一些人造的异步动作，比方我的项目中的容器状态同步，须要应用到音讯队列来维持削峰 相当于做了一个蓄水池，申请比拟少时安然无恙，申请激增时应用音讯队列缓存申请（申请能够疾速的返回），生产零碎再去拉取音讯进行解决 和限流算法中的令牌桶算法比拟相似音讯队列的毛病升高零碎的可用性：零碎引入的内部依赖越多，越容易挂掉零碎复杂度进步：应用 MQ 后可能须要解决音讯没有被反复生产（音讯队列的幂等性问题）、音讯失落的状况，保障消息传递的程序性等等问题 音讯有序性音讯失落音讯反复生产音讯队列的两个实现标准JMSJMS（Java Message Service）是 Java 的音讯服务，能够视作一套API规范反对队列模型与公布订阅模型ActiveMQ 就是基于 JMS 标准实现的AMQPAMQP，即 Advanced Message Queuing Protocol，一个提供对立音讯服务的应用层规范 高级音讯队列协定（二进制应用层协定），是应用层协定的一个凋谢规范，为面向音讯的中间件设计，兼容 JMS。基于此协定的客户端与消息中间件可传递音讯，并不受客户端/中间件产品类型，开发语言等条件的限度 一套应用层协定而非API跨语言与平台仅反对二进制数据音讯队列零碎的几个要害的问题音讯队列中的音讯大量积压可能的起因就是生产端挂掉了，导致大量数据存储在音讯队列不能被生产 首先复原consumer的问题，保障其可用新建一个topic Partition设置为失常的十倍（视状况而定） 从新投递并生产是必要的，然而数据量比拟大，所以须要设置一个Partition扩充的topic长期写一个consumer，生产积压的数据，而后从新投递到新的topic中，次要的就是保障consumer疾速生产，而不像一般的consumer可能做一些比拟耗时的操作长期加服务器扩容consumer（也为之前的十倍，视状况而定）生产对应的topic中的数据生产结束后，进行可能的架构降级以保障后续不再产生生产端挂掉的状况音讯失落这里指的是因为音讯积压带来的音讯失落，手动写长期的程序，查出失落的程序，再将其投喂到音讯零碎中 前面有防止音讯失落的三个维度的计划Kafka简介Kafka是由LinkedIn开发的一个分布式的基于公布/订阅模型的音讯零碎，应用Scala编写，它以可程度扩大和高吞吐率（高性能）而被宽泛应用，同时反对音讯长久化。Kafka并不是JMS或AMQP任一规范的实现，Kafka自成规范 程度扩大：反对broker的增加与topic的Partition的扩大高吞吐率，生产者将音讯push到Partition的形式是追加的形式，是磁盘的程序IO，性能比拟高，并且因为同一主题能够有多个Partition，因而吞吐率高Kafka对音讯保留时依据 Topic 进行归类，发送音讯者称为 Producer，音讯接受者称为 Consumer，此外 Kafka集群有多个 Kafka 实例组成，每个实例(server)称为 broker常见的应用场景音讯零碎Kafka与传统的消息中间件都具备零碎解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等性能。与此同时，Kafka还提供了大多数音讯零碎难以实现的音讯程序性保障及回溯性生产的性能晚期的时候 Kafka 并不是一个合格的音讯队列，这也和 LinkedIn 最早开发 Kafka 用于解决海量的日志有很大关系，并不是作为音讯队列应用的，随着后续的倒退，这些短板都被 Kafka 逐渐修复欠缺存储系统Kafka把音讯长久化到磁盘，相比于其余基于内存存储的零碎而言，无效的升高了音讯失落的危险。这得益于其音讯长久化和多正本机制。也能够将Kafka作为长期的存储系统来应用，只须要把对应的数据保留策略设置为“永恒”或启用主题日志压缩性能流式解决平台Kafka为风行的流式解决框架提供了牢靠的数据起源，还提供了一个残缺的流式解决框架，比方窗口、连贯、变换和聚合等各类操作Website activity trackingKafka能够作为网站活性跟踪的最佳工具；能够将网页/用户操作等信息发送到Kafka中，并实时监控，或者离线统计分析等 MetricsKafka通常被用于可操作的监控数据。这包含从分布式应用程序来的聚合统计用来生产集中的经营数据提要 Log AggregationKafka的个性决定它非常适合作为日志收集核心；application能够将操作日志批量异步的发送到Kafka集群中，而不是保留在本地或者DB中；Kafka能够批量提交音讯/压缩音讯等，这对producer端而言，简直感觉不到性能的开销，此时consumer端能够是hadoop等其余系统化的存储和剖析零碎 Kafka的装置与应用办法举荐看另一篇文章，应用docker-compose部署KafkaKafka根底队列模型与公布订阅模型队列模型（一对一）应用队列保护音讯，只能保障一个音讯被一个消费者生产，当须要将特定的音讯分发给多个消费者时，则不适合了，能够应用线程池中的BlockingQueue来了解队列模型 比方有多个消费者连贯了同一个音讯队列，当生产者发送多条音讯A B C D后，多个Consumer可能别离只承受到其中一个音讯，这个过程是不受控的，因而队列模型更实用于一对一的音讯公布公布订阅模型通过订阅主题的形式实现音讯向多个消费者的散发在公布 - 订阅模型中，如果只有一个订阅者，那它和队列模型就根本是一样的了。所以说，公布 - 订阅模型在性能层面上是能够兼容队列模型的要留神的是Kafka的公布订阅模型中没有队列这个概念（即消息传递通道的角色），只有Partition的概念（实际上Partition用来反对某主题对应的音讯通道的程度扩大）Kafka应用的公布订阅模型常见的架构图 <img src="https://images.demoli.xyz/image-20210803211115318.png" alt="image-20210803211115318" style="zoom:67%;" /> 无论是 Kafka 集群，还是 consumer 都依赖于 Zookeeper 集群保留一些 meta 信息， 来保证系统可用性，不过在Kafka的2.8版本就曾经开始尝试摈弃Zookeeper了 ...

一、前言在现在的分布式环境时代，任何一款中间件产品，大多都有一套机制去保障高可用的，Kafka 作为一个商业级消息中间件，音讯可靠性的重要性可想而知，那 Kafka 如何保障可靠性的呢？本文从 Producer 往 Broker 发送音讯、Topic 分区正本以及 Leader 选举几个角度介绍 Kafka 是如何保障可靠性的。 二、Producer 往 Broker 发送音讯如果咱们要往 Kafka 对应的主题发送音讯，咱们须要通过 Producer 实现。后面咱们讲过 Kafka 主题对应了多个分区，每个分区上面又对应了多个正本；为了让用户设置数据可靠性， Kafka 在 Producer 外面提供了音讯确认机制。把选项提供给用户本人去抉择，咱们能够通过配置来决定音讯发送到对应分区的几个正本才算音讯发送胜利。能够在定义 Producer 时通过 acks 参数指定（在 0.8.2.X 版本之前是通过 request.required.acks 参数设置的，详见 KAFKA-3043）。 这个参数反对以下三种值： acks = 0：意味着如果生产者可能通过网络把音讯发送进来，那么就认为音讯已胜利写入 Kafka 。在这种状况下还是有可能产生谬误，比方发送的对象能干被序列化或者网卡产生故障，但如果是分区离线或整个集群长时间不可用，那就不会收到任何谬误。在 acks=0 模式下的运行速度是十分快的（这就是为什么很多基准测试都是基于这个模式），你能够失去惊人的吞吐量和带宽利用率，不过如果抉择了这种模式， 肯定会失落一些音讯。acks = 1：意味着 Leader 在收到音讯并把它写入到本地磁盘时会返回确认或谬误响应，不论其它的 Follower 正本有没有同步过这条音讯。在这个模式下，如果产生失常的 Leader 选举，生产者会在选举时收到一个 LeaderNotAvailableException 异样，如果生产者能失当地解决这个谬误，它会重试发送音讯，最终音讯会平安达到新的 Leader 那里。不过在这个模式下依然有可能失落数据，比方音讯曾经胜利写入 Leader，但在音讯被复制到 Follower 正本之前 Leader产生解体。acks = all（这个和 request.required.acks = -1 含意一样）：意味着 Leader 在返回确认或谬误响应之前，会期待所有同步正本都收到音讯。如果和 min.insync.replicas 参数联合起来，就能够决定在返回确认前至多有多少个正本可能收到音讯，生产者会始终重试直到音讯被胜利提交。不过这也是最慢的做法，因为生产者在持续发送其余音讯之前须要期待所有正本都收到以后的音讯。依据理论的利用场景，咱们设置不同的 acks，以此保证数据的可靠性。 ...

简介：Delta Lake是一个开源存储层，它为数据湖带来了可靠性。Delta Lake提供了ACID事务、可扩大的元数据处理，并对立了流式解决和批处理数据处理。Delta-Lake运行在现有数据湖之上，并且与Apache Spark API齐全兼容。心愿本篇能让大家更深刻理解Delta Lake，最终能够实际到工作当中。 作者： 李元健，Deltabricks软件工程师 冯加亮，阿里云开源大数据平台技术工程师 Delta Lake是一个开源存储层，它为数据湖带来了可靠性。Delta Lake提供了ACID事务、可扩大的元数据处理，并对立了流式解决和批处理数据处理。Delta-Lake运行在现有数据湖之上，并且与Apache Spark API齐全兼容。心愿本篇能让大家更深刻理解Delta Lake，最终能够实际到工作当中。 本篇文章将从3个局部介绍对于Delta Lake的一些个性： Delta Lake的我的项目背景以及想要解决的问题Delta Lake的实现原理Live Demo一、Delta Lake的我的项目背景以及想要解决的问题1）背景 置信大家在构建数仓解决数据方面都很有教训，而产业界也消耗了大量的资源来构建相干的零碎。 咱们发现有半结构化数据、实时数据、批量数据，用户数据等一系列数据存储在各个中央，别离以不同的解决模式为用户提供服务。 那么咱们冀望的现实的零碎是什么样的？ 更一体化或更加聚焦，让更业余的人干更业余的事件有同时解决流式和批量的能力能够提供举荐服务能够提供报警服务能够帮忙用户剖析一系列的问题 但现实情况却是： 低质量、不牢靠的数据导致一体化前进艰巨。差强人意的性能不肯定能达到实时的入库以及实时的查问要求。在这样的背景下，Delta Lake应运而生。 2）想要解决的问题 上面用一个常见的用户场景为例，如果没有Delta Lake，该如何解决这样的问题。 这可能是一个最常见的Delta Lake场景，比方咱们有一系列的流式数据，不停的从Kafka零碎流入，咱们冀望具备实时处理的能力。与此同时，咱们能够把数据周期性放在Delta Lake中。同时，咱们须要整套零碎的进口具备AI & Reporting能力。 1、历史查问 第一条解决流比较简单，比方通过Apach Spark间接应用Streaming Analytics买通实时流。 与此同时，须要离线流时，历史查问能够应用Lambda架构对应的形式。Apach Spark提供了很好的形象设计，咱们能够通过一种代码或API来实现流和实时的架构设计。 通过历史数据的查问,咱们能够进一步应用Spark进行SQL剖析，以及用Spark SQL的作业的模式来产生AI技术的能力。 2、数据校验 接下来咱们须要面对的第一个问题就是数据的校验。 咱们的流式数据和批量数据，假如以Lambda架构的模式存在时，如何确认咱们在某一个工夫点查出来的数据是对的？到底流式的数据和批量的数据差多少?咱们的批量数据什么时候该与流式数据进行同步? 所以Lambda架构还须要引入Validation，这须要咱们予以确认。尤其是像报表零碎面向用户的这种准确的数据分析系统，Validation这一步骤不可或缺。 因而，兴许咱们须要一支旁支来解决流式和批量之间的同步问题，以及对应的验证问题。 3、数据修复 假如如上问题解失去了解决，在零碎上了一段时间咱们会发现，如咱们对应的某个Partitioned数据出了问题，当天的脏数据在若干天之后须要修改。此时咱们须要怎么办？ 通常，咱们须要停掉线上的查问后再修复数据，修复完数据后从新复原线上的工作。如此折腾的过程，理论有形的给零碎架构又减少了一个修复以及过来版本回复的能力。因而，Reprocessing诞生了。 4、数据更新 假如解决完了Reprocessing问题，咱们在AI和Reporting最终的进口端，能够看到有新的一系列的需要。比方有一天业务部门或者上级部门、单干部门提出是否Schema Change，因为越来越多的人用数据，想把UserID这个维度加进去，此时该怎么解决？导到Delta Lake去加Schema、停留、对应的数据重新处理等一系列折腾。 所以大家能够看到解决了一个问题又会有新的问题。如果case by case的去解决会导致系统不停的往上打补丁。一个本来简略或者一体化的需要会变得越来越冗余和简单。 5、现实中的Delta Lake 所以现实当中的Delta Lake应该长什么样？ ...

一、前言上一篇咱们讲了 聊聊 Kafka：Kafka 音讯失落的场景以及最佳实际，这一篇咱们来说一说 Kafka 音讯反复的场景以及最佳实际。 咱们上面会从以下两个方面来说一下 Kafka 音讯反复的场景以及最佳实际。 生产者反复音讯消费者反复音讯二、Kafka 音讯反复的场景2.1 生产者反复音讯2.1.1 根本原因生产者发送的音讯没有收到 Broker 正确的响应，导致生产者重试。 生产者收回一条音讯，Broker 落盘当前因为网络等种种原因，发送端失去一个发送失败的响应或者网络中断，而后生产者收到一个可复原的 Exception 重试音讯导致音讯反复。 2.1.2 重试过程次要流程： new KafkaProducer() 后创立一个后盾线程 KafkaThread 扫描 RecordAccumulator 中是否有音讯；调用 KafkaProducer.send() 发送音讯，实际上只是把音讯保留到 RecordAccumulator 中；后盾线程 KafkaThread 扫描到 RecordAccumulator 中有音讯后，将音讯发送到 Kafka 集群；如果发送胜利，那么返回胜利；如果发送失败，那么判断是否容许重试。如果不容许重试，那么返回失败的后果；如果容许重试，把音讯再保留到 RecordAccumulator 中，期待后盾线程 KafkaThread 扫描再次发送。 具体的重试流程见下图： 2.1.3 可复原异样阐明从上面源码中不难发现异常是 RetriableException 类型或者音讯是事务类型 TransactionManager 容许重试；常见的 RetriableException 类继承关系如下： 2.1.4 记录程序问题如果设置 max.in.flight.requests.per.connection > 1（默认5，单个连贯上发送的未确认申请的最大数量，示意上一个收回的申请没有确认下一个申请又收回了）。大于1可能会扭转记录的程序，因为如果将两个 batch 发送到单个分区，第一个 batch 解决失败并重试，然而第二个 batch 解决胜利，那么第二个 batch 解决中的记录可能先呈现被生产。 设置 max.in.flight.requests.per.connection = 1，可能会影响吞吐量，能够解决单个生产者发送程序问题。如果多个生产者，生产者1先发送一个申请，生产者2后发送申请，此时生产者1返回可复原异样，重试肯定次数胜利了。尽管生产者1先发送音讯，但生产者2发送的音讯会被先生产。 2.2 消费者反复音讯2.2.1 根本原因数据生产完没有及时提交 offset 到 Broker ...

消费者启动的时候，次要是初始化几个外围的组件。 反序列器，次要是生产者发送的音讯是序列化到broker的，所以这边要反序列化进行解决。 NetworkClient之前在生产者曾经讲过了，用于网络通讯。 ConsumerCoordinator是协调器，如果同一个group进行生产的时候，须要进行协调，这里和rocketmq不同，rocketmq是消费者本人来协调的（RocketMQ -- 写在音讯拉取前），kafka是通过broker来协调。雷同的是，消费者须要发送心跳给broker，broker才晓得哪些音讯费须要生产。 Fetcher次要是用来拉取音讯的。 Consumer在初始化后，就开始拉取音讯，然而在拉取音讯之前，还须要确定Coordinator。 在没有Coordinator的时候，不如consumer1，他会随机的找到broker的地址，比方broker1。 调用broker1的接口，申请相干数据。 broker1接管到申请后，就会对groupid进行hash，并依据__consumer_offsets的topic数据进行取模，__consumer_offsets数量为50。 假如hash的值是10，而__consumer_offsets的partition为10在broker2上，那这个broker2就是Coordinator服务器。 consumer1晓得broker2是Coordinator服务器后，就开始向broker2进行注册并发送心跳。 同理，consumer2因为groupid是一样的，所以计算结果也是broker2，最终也向broker2进行注册并发送心跳。 broker2就会把相干consumer信息进行保留，并抉择leader consumer。 谁先注册上来，谁就是leader consumer。

一、前言大家好，我是老周，有快二十多天没有更新文章了，很多小伙伴始终在催更。先阐明下最近的状况，最近我的项目上线很忙，没有工夫写，并且组里有个共事应用 Kafka 不当，导致线上音讯失落，在修复一些线上的数据，人都麻了。事件是这样，有个 Kafka 消费者实例，部署到线下来，生产到了线上的数据，而新版本做了新的逻辑，新版本的业务逻辑与老版本的业务逻辑不兼容，间接导致生产失败，没有进行重试操作，要害还提交了 offset。间接这部分数据没有被业务解决，导致音讯失落，而后紧急修复线上数据。 刚好这些天忙完了有空，所以记录一下，同时看是否对大家能起到防止踩坑的作用，能有一些作用，那我写的也就值了。 咱们上面会从以下三个方面来说一下 Kafka 音讯失落的场景以及最佳实际。 生产者失落音讯Kafka Broker 服务端失落音讯消费者失落音讯二、Kafka 的三种音讯语义先说 Kafka 音讯失落的场景之前，咱们先来说下 Kafka 的三种音讯语义，不会还有人不晓得吧？这个不应该了，音讯零碎基本上形象成这以下三种音讯语义了： 最多传递一次起码传递一次仅有一次传递 类型音讯是否会反复音讯是否会失落劣势劣势实用场景最多一次否是生产端发送音讯后不必期待和解决服务端响应，音讯发送速度会很快。网络或服务端有问题会造成音讯的失落音讯零碎吞吐量大且对音讯的失落不敏感。例如：日志收集、用户行为等场景。起码一次是否生产端发送音讯后须要期待和解决服务端响应，如果失败会重试。吞吐量较低，有反复发送的音讯。音讯零碎吞吐量个别，然而绝不能丢音讯，对于反复音讯不敏感。有且仅有一次否否音讯不反复，音讯不失落，音讯可靠性很好。吞吐量较低对音讯的可靠性要求很高，同时能够容忍较小的吞吐量。三、Kafka 音讯失落的场景3.1 生产者失落音讯目前 Kafka Producer 是异步发送音讯的，如果你的 Producer 客户端应用了 producer.send(msg) 办法来发送音讯，办法会立刻返回，但此时并不能代表音讯曾经发送胜利了。如果音讯再发送的过程中产生了网络抖动，那么音讯可能没有传递到 Broker，那么音讯可能会失落。如果发送的音讯自身不合乎，如大小超过了 Broker 的承受能力等。3.2 Kafka Broker 服务端失落音讯Leader Broker 宕机了，触发选举过程，集群选举了一个落后 Leader 太多的 Broker 作为 Leader，那么落后的那些音讯就会失落了。Kafka 为了晋升性能，应用页缓存机制，将音讯写入页缓存而非间接长久化至磁盘，采纳了异步批量刷盘机制，也就是说，依照肯定的音讯量和工夫距离去刷盘，刷盘的动作由操作系统来调度的，如果刷盘之前，Broker 宕机了，重启后在页缓存的这部分音讯则会失落。3.3 消费者失落音讯消费者拉取了音讯，并解决了音讯，但解决音讯异样了导致失败，并且提交了偏移量，消费者重启后，会从之前已提交的位移的下一个地位从新开始生产，生产失败的那些音讯不会再次解决，即相当于消费者失落了音讯。消费者拉取了音讯，并提交了生产位移，然而在音讯解决完结之前忽然产生了宕机等故障，消费者重启后，会从之前已提交的位移的下一个地位从新开始生产，之前未解决实现的音讯不会再次解决，即相当于消费者失落了音讯。四、最佳实际4.1 生产端不要应用 producer.send(msg)，而要应用 producer.send(msg, callback)。带有回调告诉的 send 办法能够针对发送失败的音讯进行重试解决。设置 acks = all。代表了你对“已提交”音讯的定义。如果设置成 all，则表明所有正本 Broker 都要接管到音讯，该音讯才算是“已提交”。这是最高等级的“已提交”定义。 设置 retries = 3，当呈现网络的刹时抖动时，音讯发送可能会失败，此时配置了 retries > 0 的 Producer 可能主动重试音讯发送，防止音讯失落。 如果重试达到设定的次数，那么生产者就会放弃重试并返回异样。不过并不是所有的异样都是能够通过重试来解决的，比方音讯太大，超过max.request.size参数配置的值时，这种形式就不可行了。 设置 retry.backoff.ms = 300，正当估算重试的工夫距离，能够防止有效的频繁重试。它用来设定两次重试之间的工夫距离，防止有效的频繁重试。在配置 retries 和 retry.backoff.ms之前，最好先估算一下可能的异样复原工夫，这样能够设定总的重试工夫大于这个异样复原工夫，以此来防止生产者过早地放弃重试。 ...

原文地址：http://fxbing.github.io/2022/...本文次要对 Kafka 和 Pulsar 的 Log Compaction 原理进行介绍，并以我的了解进行简略的比照阐明。 在 Kafka 和 Pulsar 中，都具备 Log Campaction（日志挤压）的能力，Compaction 不同于 Log Compression（日志压缩），Compaction 是指将 Topic 历史日志中雷同 Key 的音讯只保留最新的一条，而 Compression 是指音讯维度利用各种压缩算法（如：gzip、lz4、zstd等）减小音讯大小但不扭转音讯内容。Compaction 的应用场景的特点：一是音讯有 key，二是雷同 key 的音讯只关怀最新的内容，例如：记录每支股票价格变动的 Topic，股票名称设置为 key，股票价格设置为 value，个别只关怀股票的最新价格。在这种场景下，配置 Compaction 能够让 Topic 存储的数据更少，从而在须要全量读取 Topic 内容时速度更快。 Kafka Log Compaction本文介绍基于 Kafka 2.8，并且疏忽了幂等音讯、事务音讯的相干解决逻辑，如有趣味，能够自行浏览源码理解。在 Kafka 中，Topic 配置 cleanup.policy用来管制 Topic 的数据清理策略，该配置的可选值有两个：一个是delete，示意 Topic 中数据超过保留工夫或保留大小限度时，间接删除最旧的数据；另一个是compact，示意对于 Topic 中的旧数据（非 Active Segment 中的数据）执行挤压，肯定范畴内，对于 key 雷同（没有 key 的音讯会被删除）的音讯，只保留最新的一条。对于每个 Topic 能够抉择一种清理策略进行配置，也能够同时配置两种策略。本文介绍的是 compact这个策略，在 Kafka 应用过程中，用来寄存 commit offset 信息的的外部 Topic:__consumer_offsets 会被配置为该策略，一般 Topic 个别很少应用。 ...

Kafka学习笔记Apache Kafka是一个分布式音讯公布订阅零碎。它最后由LinkedIn公司基于独特的设计实现为一个分布式的提交日志零碎( a distributed commit log)，之后成为Apache我的项目的一部分。Kafka零碎疾速、可扩大并且可长久化。它的分区个性，可复制和可容错都是其不错的个性介绍Kafka前，先来回顾一下消息中间件（MQ）的常识~~1.消息中间件介绍消息中间件相比大家应该不生疏，个别咱们也习惯称之为MQ。它其实没有很高大上，也是一个基于语言开发出的零碎，例如像：RocketMQ是阿里巴巴基于Java开发的作用有三：利用解耦、异步解决、限流削峰在市面上，罕用的MQ有：ActiveMQ，RabbitMQ，RocketMQ，Kafka MQ详解及四大MQ比拟 - 云+社区 - 腾讯云2.消息中间件的概念三大外围组件 Broker：音讯服务器，作为server提供音讯外围服务Provider：音讯提供者Consumer：音讯消费者（集群模式）两大通信模式 公布-订阅模式（也是我工作中所应用的）点对点模式Kafka的概念Partition(分区)：后面咱们提到，能够把Topic了解为一个数据汇合，那么一个Topic能够分成多个Partition（区），其中每个区的音讯是有序的 若你须要所有音讯都是有序的，那么你最好只用一个分区。另外partition反对音讯位移读取，音讯位移有消费者本身治理 Consumer Group（消费者组）：一群消费者的汇合。向Topic订阅生产音讯的单位是Consumers=ConsumerGroup，只不过Group能够是一个Consumer，也能够是多个 在我的微服务项目开发中，个别把Consumer Group设置成 以 微服务 为单位 对于此图的具体介绍，能够参考官网翻译： https://scala.cool/2018/03/le...Kafka的小Demo首先第一步须要装置环境啦，我是应用 Centos + docker + Portainer（Docker UI管理工具）去装置 Kafka须要装置 Zookeeper，Kafka和 Kafka Manager（UI治理页面）装置也比较简单，步骤可参考：docker下装置kafka和kafka-manager - 简书在Kafka Manager里创立 Cluster（因为Kafka是人造分布式的，都是以集群为单位创立和部署的），而后能够去创立一个 Topic 配置Yaml，再别离搭建 Provider 和 Consumer spring: # Kafka BeanConfig kafka: bootstrap-servers: 192.XXX.XXX.X:9082 # Kafka Broker address # Kafka Producer Config producer: acks: 1 retries: 3 # retry-count key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.springframework.kafka.support.serializer.JsonSerializer # Kafka Consumer Config consumer: auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer properties: spring: json: trusted: packages: cn.xxx.kafkademo.message # Kafka Consumer Listener Config listener: missing-topics-fatal: false@Componentpublic class DemoProducer { @Resource private KafkaTemplate<Object, Object> kafkaTemplate; public SendResult syncSend(Integer id) throws ExecutionException, InterruptedException { // 创立 DemoMessage 音讯 DemoMessage message = new DemoMessage(); message.setId(id); // 同步发送音讯 return kafkaTemplate.send(DemoMessage.TOPIC, message).get(); }}@Componentpublic class DemoConsumer { private Logger logger = LoggerFactory.getLogger(getClass()); @KafkaListener(topics = DemoMessage.TOPIC, groupId = "demo-consumer-group-" + DemoMessage.TOPIC) public void onMessage(DemoMessagemessage) { logger.info("[onMessage][线程编号:{} 音讯内容：{}]", Thread.currentThread().getId(), message); }}而后再模仿Provider往 Topic里发msg，此时Consumer应该能够收到msg ...

环境装置: 1、下载镜像这里应用了wurstmeister/kafka和wurstmeister/zookeeper这两个版本的镜像docker pull wurstmeister/zookeeperdocker pull wurstmeister/kafka在命令中运行docker images验证两个镜像曾经装置结束2.启动启动zookeeper容器docker run -d --name zookeeper -p 2181:2181 -t wurstmeister/zookeeper启动kafka容器docker run -d --name kafka --publish 9092:9092 --link zookeeper --env KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 --env KAFKA_ADVERTISED_HOST_NAME=127.0.0.1 --env KAFKA_ADVERTISED_PORT=9092 --volume /etc/localtime:/etc/localtime wurstmeister/kafka:latest127.0.0.1 改为宿主机器的IP地址，如果不这么设置，可能会导致在别的机器上拜访不到kafka。3. 测试kafka进入kafka容器的命令行运行 docker ps，找到kafka的 CONTAINER ID，运行 docker exec -it ${CONTAINER ID} /bin/bash，进入kafka容器。进入kafka默认目录 /opt/kafka_2.11-0.10.1.0生产者： package mainimport ( "fmt" "github.com/Shopify/sarama")//生产者模式func main() { fmt.Printf("producer_test\n") config := sarama.NewConfig() config.Producer.RequiredAcks = sarama.WaitForAll config.Producer.Partitioner = sarama.NewRandomPartitioner config.Producer.Return.Successes = true config.Producer.Return.Errors = true config.Version = sarama.V0_11_0_2 producer, err := sarama.NewAsyncProducer([]string{"localhost:9092"}, config) if err != nil { fmt.Printf("producer_test create producer error :%s\n", err.Error()) return } defer producer.AsyncClose() msg := &sarama.ProducerMessage{ Topic: "kafka_go_test", Key: sarama.StringEncoder("go_test"), } value := "this is message" for { fmt.Scanln(&value) msg.Value = sarama.ByteEncoder(value) fmt.Printf("input [%s]\n", value) // send to chain producer.Input() <- msg select { case suc := <-producer.Successes(): fmt.Printf("offset: %d, timestamp: %s", suc.Offset, suc.Timestamp.String()) case fail := <-producer.Errors(): fmt.Printf("err: %s\n", fail.Err.Error()) } }}消费者： ...

kafka 通过 topic 来分主题存放数据，主题内有分区，分区能够有多个正本，分区的外部还细分为若干个 segment。 所谓的分区其实就是在 kafka 对应存储目录下创立的文件夹，文件夹的名字是主题名加上分区编号，编号从 0 开始。 kafka全套视频学习材料：http://www.atguigu.com/download.shtml 1、segment所谓的 segment 其实就是在分区对应的文件夹下产生的文件。 一个分区会被划分成大小相等的若干 segment，这样一方面保障了分区的数据被划分到多个文件中保障不会产生体积过大的文件；另一方面能够基于这些 segment 文件进行历史数据的删除，提高效率。 一个 segment 又由一个.log 和一个.index 文件组成。 1．.log .log 文件为数据文件用来存放数据分段数据。 2．.index .index 为索引文件保留对对应的.log 文件的索引信息。 在.index 文件中，保留了对对应.log 文件的索引信息，通过查找.index 文件能够获知每个存储在以后 segment 中的 offset 在.log 文件中的开始地位，而每条日志有其固定格局，保留了包含 offset 编号、日志长度、key 的长度等相干信息，通过这个固定格局中的数据能够确定出以后 offset 的完结地位，从而对数据进行读取。 3．命名规定 这两个文件的命名规定为： partition 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个 segment 文件最初一条音讯的 offset 值，数值大小为 64 位，20 位数字字符长度，没有数字用 0 填充。 2、读取数据开始读取指定分区中某个 offset 对应的数据时，先依据 offset 和以后分区的所有 segment 的名称做比拟，确定出数据在哪个 segment 中，再查找该 segment 的索引文件，确定以后 offset 在数据文件中的开始地位，最初从该地位开始读取数据文件，在依据数据格式判断后果，获取残缺数据。 ...

简介：目前 Kafka ETL 正处于收费公测阶段，欢送大家体验试用。 作者：竹恩、岁月、不周 关键词：Kafka ETL，高弹性、免运维、低成本 引言：阿里云音讯队列 Kafka 版提供兼容 Apache Kafka 生态的全托管服务，彻底解决开源产品长期的痛点，是大数据生态中不可或缺的产品之一。随着 Kafka 越来越风行，最后只是作为简略的音讯总线，起初逐步成为数据集成系统，Kafka 牢靠的传递能力让它成为流式解决零碎牢靠的数据起源。在大数据工程畛域，Kafka 在承接上下游、串联数据流管道方面施展了重要作用，Kafka 利用流式框架解决音讯也逐步成为趋势。 音讯流解决框架选型说到流计算，罕用的便是 Storm、Spark Streaming 和 Flink，目前这些框架都曾经完满的反对流计算，并且都有相应的应用案例，但这些框架应用起来门槛绝对较高，首先要学习框架和各种技术、标准的应用，而后要将业务迁徙到这些框架中，最初线上应用、运维这些流计算框架，对于简略的流解决利用来说，可能较为简单。 在与传统流解决零碎对接中，因为所有的数据根底都要从一个零碎流入 Kafka 而后再流入到另一个零碎中，以至于引发 Kafka 社区的思考：与其把数据从一个零碎传递到下一个零碎中做解决，为何不本人实现一套流解决框架呢？基于这个考量，从 0.10.0 版本开始，Kafka 不仅为每一个风行的流式解决框架提供了牢靠的数据起源，还提供了一个弱小的流式解决类库 Kafka Streams，并将其作为客户端类的一部分。这样，开发人员就能够在应用程序里读取、解决和生成事件，而不须要再依赖内部的解决框架。 但因为 Kafka Streams 自身是一个 Java 客户端库，须要开发人员自行打包和部署；同时 Kafka Streams 是开源版本，可靠性和可用性不能失去很好的保障，也不能实现按需应用；此外应用过程中须要用到流的编程，应用的门槛也绝对较高。 音讯流解决框架次要面临的问题通过后面对常见的音讯流解决的介绍，不论是传统的流解决架构还是 Kafka Streams，对于开发人员来说都会面临一些问题，尤其是在面对 70% 以上简略流场景的需要，原有的计划弊病被一直放大，客户依然须要投入较大的人力老本和较高的资源，同时整个架构也很简单。总体来说，目前面临次要是四个方面的问题： 1、运维老本较大，研发团队自行编写代码，前期继续保护，运维老本较大； 2、技术老本较大，对于很多轻量或简略计算需要，须要进行技术选型，引入一个全新组件的技术老本过高； 3、学习老本不可预期，在某组件选定后，须要研发团队进行学习并继续保护，这就带来了不可预期的学习老本； 4、自行选用开源组件后，可靠性和可用性不能失去无效保障。 面对这些问题，阿里音讯队列 Kafka 也推出了相应的解决方案：Kafka ETL。 阿里云的解决方案 - Kafka ETLKafka ETL 简介阿里云音讯队列 Kafka 版推出更低成本的 Kafka –ETL 组件，是一款免运维的流计算组件，次要个性是反对配置化流式解决音讯。Kafka ETL 组件次要提供的是非工夫窗口相干的流计算服务，客户能够配置，甚至简略写入几行代码就能满足包含格局转换、内容富化、本地聚合、路由散发等罕用的数据处理需要。 ...

Spring Boot操作Kafka(1).Maven的配置<dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka_2.11</artifactId> <version>0.10.2.0</version></dependency>(2).增加配置文件: application.properties# kafka连贯地址,多个地址之间应用","隔开spring.kafka.bootstrap-servers = master:9092# 生产者配置spring.kafka.producer.acks = 0spring.kafka.producer.key-serializer = org.apache.kafka.common.serialization.StringSerializerspring.kafka.producer.value-serializer = org.apache.kafka.common.serialization.StringSerializerspring.kafka.producer.retries = 3spring.kafka.producer.batch-size = 4096spring.kafka.producer.buffer-memory = 33554432spring.kafka.producer.compression-type = gzip# 消费者配置spring.kafka.consumer.group-id = mygroupspring.kafka.consumer.auto-commit-interval = 5000spring.kafka.consumer.heartbeat-interval = 3000spring.kafka.consumer.key-deserializer = org.apache.kafka.common.serialization.StringDeserializerspring.kafka.consumer.value-deserializer = org.apache.kafka.common.serialization.StringDeserializerspring.kafka.consumer.auto-offset-reset = earliestspring.kafka.consumer.enable-auto-commit = true# listenner, 标识消费者监听的个数spring.kafka.listener.concurrency = 8# topic的名字kafka.topic1 = topic1(3).生产者代码import lombok.extern.slf4j.Slf4j;import org.springframework.beans.factory.annotation.Value;import org.springframework.kafka.core.KafkaTemplate;@Service@Slf4jpublic class MyKafkaProducerServiceImpl implements MyKafkaProducerService { @Resource private KafkaTemplate<String, String> kafkaTemplate; // 读取配置文件 @Value("${kafka.topic1}") private String topic; @Override public void sendKafka() { kafkaTemplate.send(topic, "hell world"); }}(4),消费者代码@Component@Slf4jpublic class MyKafkaConsumer { @KafkaListener(topics = "${kafka.topic1}") public void listen(ConsumerRecord<?, ?> record) { Optional<?> kafkaMessage = Optional.ofNullable(record.value()); if (kafkaMessage.isPresent()) { log.info("----------------- record =" + record); log.info("------------------ message =" + kafkaMessage.get());}

kafka整合Flume前提是曾经装置实现flume1、增加启动flume时的配置文件 # node01执行以下命令开发flume的配置文件cd /kkb/install/apache-flume-1.6.0-cdh5.14.2-bin/conf/### 编辑配置文件vi flume-kafka.conf#为咱们的source channel sink起名a1.sources = r1a1.channels = c1a1.sinks = k1#指定咱们的source数据收集策略a1.sources.r1.type = spooldira1.sources.r1.spoolDir = /kkb/install/flumeData/filesa1.sources.r1.inputCharset = utf-8#指定咱们的source收集到的数据发送到哪个管道a1.sources.r1.channels = c1#指定咱们的channel为memory,即示意所有的数据都装进memory当中a1.channels.c1.type = memorya1.channels.c1.capacity = 1000a1.channels.c1.transactionCapacity = 100#指定咱们的sink为kafka sink，并指定咱们的sink从哪个channel当中读取数据a1.sinks.k1.channel = c1a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSinka1.sinks.k1.kafka.topic = kaikebaa1.sinks.k1.kafka.bootstrap.servers = node01:9092,node02:9092,node03:9092a1.sinks.k1.kafka.flumeBatchSize = 20a1.sinks.k1.kafka.producer.acks = 12、node01执行以下命令创立Topic cd /kkb/install/kafka_2.11-1.1.0/bin/kafka-topics.sh --create --topic kaikeba --partitions 3 --replication-factor 2 --zookeeper node01:2181,node02:2181,node03:21813、启动Flume node01执行以下命令启动flume bin/flume-ng agent -n a1 -c conf -f conf/flume-kafka.conf -Dflume.root.logger=info,console4、启动kafka控制台消费者，验证数据写入胜利 node01执行以下命令生产kafka当中的数据 cd /kkb/install/kafka_2.11-1.1.0/bin/kafka-console-consumer.sh --topic kaikeba --bootstrap-server node01:9092,node02:9092,node03:9092 --from-beginning

在Kafka中Partition(分区)是真正保留音讯的中央，发送的音讯都寄存在这里。Partition(分区)又存在于Topic（主题）中，并且一个Topic（主题）能够指定多个Partition(分区)。 在Kafka中，只保障Partition(分区)内有序，不保障Topic所有分区都是有序的。 所以 Kafka 要保障音讯的生产程序，能够有2种办法：一、1个Topic（主题）只创立1个Partition(分区)，这样生产者的所有数据都发送到了一个Partition(分区)，保障了音讯的生产程序。二、生产者在发送音讯的时候指定要发送到哪个Partition(分区)。 那么问题来了：在1个topic中，有3个partition，那么如何保证数据的生产？ 1、如程序生产中的 "第①点" 和 "Kafka 要保障音讯的生产程序第二个办法" 阐明，生产者在写的时候，能够指定一个 key，比如说咱们指定了某个订单 id 作为 key，那么这个订单相干的数据，肯定会被散发到同一个 partition 中去，而且这个 partition 中的数据肯定是有程序的。 2、消费者从 partition 中取出来数据的时候，也肯定是有程序的。到这里，程序还是 ok 的，没有错乱。 3、然而消费者里可能会有多个线程来并发来解决音讯。因为如果消费者是单线程生产数据，那么这个吞吐量太低了。而多个线程并发的话，程序可能就乱掉了。 解决方案：写N个queue，将具备雷同key的数据都存储在同一个queue，而后对于N个线程，每个线程别离生产一个queue即可。 注：在单线程中，一个 topic，一个 partition，一个 consumer，外部单线程生产，这样的状态数据生产是有序的。但因为单线程吞吐量太低，在数据宏大的理论场景很少采纳。 然而以上生产线程模型，存在一个问题： 在生产过程中，如果 Kafka 生产组产生重均衡，此时的分区被调配给其它生产组了，如果拉取回来的音讯没有被生产，尽管 Kakfa 能够实现 ConsumerRebalanceListener 接口，在新一轮重均衡前被动提交生产偏移量，但这貌似解决不了未生产的音讯被打乱程序的可能性？ 因而在生产前，还须要被动进行判断此分区是否被调配给其它消费者解决，并且还须要锁定该分区在生产当中不能被调配到其它消费者中（但 kafka 目前做不到这一点）。 参考 RocketMQ 的做法： 在生产前被动调用 ProcessQueue#isDropped 办法判断队列是否已过期，并且对该队列进行加锁解决（向 broker 端申请该队列加锁）。 RocketMQRocketMQ 不像 Kafka 那么“原生”，RocketMQ 早已为你筹备好了你的需要，它自身的生产模型就是单 consumer 实例 + 多 worker 线程模型，有趣味的小伙伴能够从以下办法观摩 RocketMQ 的生产逻辑： org.apache.rocketmq.client.impl.consumer.PullMessageService#runRocketMQ 会为每个队列调配一个 PullRequest，并将其放入 pullRequestQueue，PullMessageService 线程会一直轮询从 pullRequestQueue 中取出 PullRequest 去拉取音讯，接着将拉取到的音讯给到 ConsumeMessageService 解决，ConsumeMessageService 有两个子接口： ...

一、Kafka 工作流程 Kafka 中用 topic 对音讯进行分类，生产者和消费者都面向 topic 解决数据。一个 topic 会分成多个 partition，放到不同的 broker 上用于进步吞吐量。同一个 partition 外部又会拆分成多个 segment，避免数据过多时单文件过大。 二、文件存储构造 硬盘上文件存储相似于： ├── my-topic-0│   ├── 00000000000000000000.index│   ├── 00000000000000000000.log│   ├── 00000000000000000000.timeindex│   ├── 00000000003432423452.index│   ├── 00000000003432423452.log│   ├── 00000000003432423452.timeindex│   └── leader-epoch-checkpoint├── your-topic-1│   ├── 00000000001237987534.index│   ├── 00000000001237987534.log│   ├── 00000000001237987534.timeindex│   ├── 00000000006732746781.index│   ├── 00000000006732746781.log│   ├── 00000000006732746781.timeindex│   └── leader-epoch-checkpoint每个文件夹对应一个 topic 分区，文件夹命名规定 [topic name]-[partition id]文件夹内是对应的 segment，每个 segment 次要蕴含 .log 和 .index 文件。后续每个Segment文件名为上一个Segment文件最初一条音讯的offset值，数值大小为64位，20位数字字符长度。 00000000000000000000.index00000000000000000000.log00000000000000000000.timeindex00000000003432423452.index00000000003432423452.log00000000003432423452.timeindexleader-epoch-checkpointSegment文件的具体内容：索引文件存储的元数据指向数据文件中的 message 的物理偏移地址 三、如何读取数据以上图为例，要读取offset=170418的音讯。 先通过二分查找确定在哪个 segment到对应的 index 文件中查问 offset=170418 的物理偏移地址依据物理偏移地址，到 log 文件中读取对应的数据

Kafka 动静配置实现Kafka 的动静配置基于 Zookeeper 实现，本文次要梳理了 Kafka（version：2.8） 中动静配置的实现逻辑。 背景信息在 Kafka 中，Zookeeper 客户端没有应用常见的客户端工具（如：Curator），而是间接基于原生的客户端实现了本人的 KafkaZkClient，将一些通用或特有的 Zookeeper 操作封装在内。因而，对于 Zookeeper 的应用及回调等逻辑也齐全是独立实现的。另外，因为 Zookeeper 中一个节点下的 Watcher 程序触发，如果同一个节点下有大量的 Watcher，将会产生性能瓶颈。上面将基于这些背景信息来介绍 Kafka 是如何基于 Zookeeper 实现高效的动静配置管理的。 Kafka 动静配置 Zookeeper 目录构造在以后版本的 Kafka 中，动静配置类型有 5 种：topic, client, user, broker, ip。Kafka 动静配置的目录构造为： /config/entityType/entityName ，entityType 代表配置的类型，entityName 代表具体某个实体，比方：Topic 类型对应的实体就是具体某个 Topic，某个配置类型下所有实体的默认配置的 entityName 为 <deafult>。具体来说，所有 Topic 的默认动静配置会放在 /config/topic/<default> 的节点信息中，Topic AAA 的所有动静配置会放在 /config/topic/AAA 的节点信息中。 Listener 实现上面介绍 Kafka 中 Zookeeper Listener 的实现。既然是基于 Zookeeper 实现，必然少不了 Zookeeper 的 Watcher 告诉机制，然而，如背景信息中所说，在 Watcher 数量过多的状况下，会存在性能瓶颈。以 Topic 配置变更为例，在生产环境中，一个 Topic 的 Partition 数量可能多达上千，如果每个 Partition Leader 都去监听这个 Topic 配置信息，那么在一个 Kafka 集群内，仅监听 Topic 配置的 Watcher 就会有上万个甚至更多。Kafka 通过独立的告诉机制来防止了这一问题，即：每次 AdminClient 进行配置变更时，会在 /config/changes/ 目录下创立以 config_change_ 为前缀的程序节点，Wather 只监听 /config/changes/ 目录的孩子节点变动，所以对于动静配置来说，所有 Broker 只监听 /config/changes/ 这一个目录，大大减少集群整体的 Watcher 数量。 ...

背景随着业务规模的倒退，须要的kafka集群越来越来，这给部署与治理带来了很大的挑战。咱们冀望可能利用K8S优良的扩容能力与疾速部署能力，为日常的工作减负。所以就kafka上K8S的可行性计划进行了调研。 像kafka集群这种，波及到的组件比拟多，且都是有状态的集群，业界采纳自定义operator的解决方案。目前GitHub上有多个相干的仓库，依据社区活跃度及应用数等综合思考，此次采纳Strimzi Github地址。 kafka组件交互图 计划应用阿里云K8S集群部署Strimzi因为组内应用的kafka是由开源版本二次开发而来，所以须要保护一个自定义的Strimzi-kafka镜像Strimzi治理kafka集群，其中蕴含kafka、zk、kafka-exporter、应用zoo-entrance 代理集群中的zk GitHub地址部署prometheus，采集kafka和zk的metrics开启服务端口，裸露kafka及zk给K8S集群内部应用实战过程构建自定义kafka镜像从公司Git上拉取最新代码 strimzi-kafka-operator （与开源版本有些微的改变，做试验可间接用开源版）在docker-images 文件夹下，有个Makefile文件，执行其中的docker_build, 它会去执行其中的build.sh脚本；此步会从官网拉取kafka的安装包，咱们须要将这一步的包批改为我司外部的安装包。构建完镜像，镜像在本地，咱们须要将镜像上传到公司外部的harbor服务器上部署operator每个K8S集群仅需部署一个operator 充沛必要条件：一个衰弱的k8s集群创立namespace, 如已有则跳过，默认应用kafka，kubectl create namespace kafka从公司Git上拉取最新代码（地址在前边）目前文件中默认监听的是名称为 kafka 的namespace，如果须要批改则执行 sed -i 's/namespace: ./namespace: kafka/' install/cluster-operator/RoleBinding*.yaml （将命令中的kafka/ 替换掉）而后将所有文件都利用一下 kubectl apply -f install/cluster-operator/ -n kafka此时稍等片刻，就能查看到创立的自定义资源以及operator了 kubectl get pods -nkafka,从阿里云的k8s管控台查看这些资源的创立状况，以及operator的运行状况部署kafka集群确保你的operator曾经部署胜利，且kafka部署的namespace需在上边operator的监控中 还是来到最新的代码目录中，其中examples/kafka目录下边就是本次部署所须要的文件了部署 kafka及zk查看kafka-persistent.yaml, 该文件就是外围文件了，这个文件部署了kafka与zk及kafka-exporter， 局部内容如下：apiVersion: kafka.strimzi.io/v1beta2kind: Kafkametadata: name: my-clusterspec: kafka: version: 2.8.1 replicas: 3 resources: requests: memory: 16Gi cpu: 4000m limits: memory: 16Gi cpu: 4000m image: repository.poizon.com/kafka-operator/poizon/kafka:2.8.4 jvmOptions: -Xms: 3072m -Xmx: 3072m listeners: - name: external port: 9092 type: nodeport tls: false - name: plain port: 9093 type: internal tls: false config: offsets.topic.replication.factor: 2 transaction.state.log.replication.factor: 2 transaction.state.log.min.isr: 1 default.replication.factor: 2 *** template: pod: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: strimzi.io/name operator: In values: - my-cluster-kafka topologyKey: "kubernetes.io/hostname" storage: type: persistent-claim size: 100Gi class: rocketmq-storage deleteClaim: false metricsConfig: type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: kafka-metrics key: kafka-metrics-config.yml zookeeper: replicas: 3 resources: requests: memory: 3Gi cpu: 1000m limits: memory: 3Gi cpu: 1000m jvmOptions: -Xms: 2048m -Xmx: 2048m jmxOptions: {} template: pod: affinity: podAntiAffinity: *** storage: type: persistent-claim size: 50Gi class: rocketmq-storage deleteClaim: false metricsConfig: type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: kafka-metrics key: zookeeper-metrics-config.yml *** ***可批改kafka集群的名称，在第四行的name属性，目前默认为 my-cluster可批改kafka的Pod个数，即节点数，默认为3可批改Pod配置 内存CPU可批改kafka JVM 启动的堆内存大小可批改kafka的配置，在36行 config配置可批改磁盘类型及大小，类型为第50行，可批改为其它的存储类，目前可选为高效云盘、SSD、ESSDzk批改同kafka，可批改的货色相似, 且在同一个文件中文件下边是kafka与zk须要裸露的metrics，可按需求增删改批改完配置之后，间接执行 kubect apply -f kafka-persistent.yaml -nkafka 即可创立部署 zk代理因为官网不反对内部组件间接拜访zk，所以采纳代理的形式拜访出于安全性 的思考，官网是成心不反对内部程序拜访zk的： https://github.com/strimzi/strimzi-kafka-operator/issues/1337解决方案：https://github.com/scholzj/zo...部署完zk的代理，咱们须要在k8s管制台上 创立一个loadbalance服务将这个代理裸露给集群外的利用进行连贯。具体操作：k8s控制台-->网络-->服务-->创立（抉择loadbalance创立，而后找到zoo-entrance这个利用即可）部署 zk-exporter官网operator中没有zk-exporter， 咱们采纳 https://github.com/dabealu/zo...在文件夹中的zk-exporter.yaml 文件中，咱们仅须要批改被监听的zk的地址（spec.container.args）执行kubectl apply -f zk-exporter.yaml即可部署实现部署 kafka-jmx因为ingress不反对tcp连贯，而loadbalance的老本又过高，所以kafka 的 jmx 应用nodeport对外裸露能够在阿里云管制台上创立相应的nodeport，也能够应用kafka-jmx.yaml 文件的形式创立apiVersion: v1kind: Servicemetadata: labels: strimzi.io/cluster: my-cluster strimzi.io/name: my-cluster-kafka-jmx name: my-cluster-kafka-jmx-0spec: ports: - name: kafka-jmx-nodeport port: 9999 protocol: TCP targetPort: 9999 selector: statefulset.kubernetes.io/pod-name: my-cluster-kafka-0 strimzi.io/cluster: my-cluster strimzi.io/kind: Kafka strimzi.io/name: my-cluster-kafka type: NodePort部署 kafka-exporter-service后面部署完kafka之后，咱们的配置中是开启了exporter的。然而官网开启完exporter之后，并没有主动生成一个相干的service，为了让Prometheus连贯更加不便，咱们部署了一个service在文件夹中kafka-exporter-service.yaml 文件中apiVersion: v1kind: Servicemetadata: labels: app: kafka-export-service name: my-cluster-kafka-exporter-servicespec: ports: - port: 9404 protocol: TCP targetPort: 9404 selector: strimzi.io/cluster: my-cluster strimzi.io/kind: Kafka strimzi.io/name: my-cluster-kafka-exporter type: ClusterIP执行kubectl apply -f kafka-exporter-service.yaml即可部署实现部署 kafka-prometheus如果将Prometheus部署在k8s集群外，数据采集会比拟麻烦，所以咱们间接将Prometheus部署到集群内在文件夹中kafka-prometheus.yaml文件中，能够选择性的批改其中prometheus的配置，比方须要的内存CPU的大小，比方监控数据保留工夫，外挂的云盘大小，以及须要监听的kafka与zk地址apiVersion: apps/v1kind: StatefulSetmetadata: name: kafka-prometheus labels: app: kafka-prometheusspec: replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app: kafka-prometheus serviceName: kafka-prometheus updateStrategy: type: RollingUpdate template: metadata: labels: app: kafka-prometheus spec: containers: - args: - '--query.max-concurrency=800' - '--query.max-samples=800000000' *** command: - /bin/prometheus image: 'repository.poizon.com/prometheus/prometheus:v2.28.1' imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 10 httpGet: path: /status port: web scheme: HTTP initialDelaySeconds: 300 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 3 name: kafka-prometheus resources: limits: cpu: 500m memory: 512Mi requests: cpu: 200m memory: 128Mi volumeMounts: - mountPath: /etc/localtime name: volume-localtime - mountPath: /data/prometheus/ name: kafka-prometheus-config - mountPath: /data/database/prometheus name: kafka-prometheus-db terminationMessagePath: /dev/termination-log terminationMessagePolicy: File terminationGracePeriodSeconds: 30 restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 0 volumes: - hostPath: path: /etc/localtime type: '' name: volume-localtime - configMap: defaultMode: 420 name: kafka-prometheus-config name: kafka-prometheus-config volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: kafka-prometheus-db spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: rocketmq-storage volumeMode: Filesystem status: phase: Pending执行kubectl apply -f kafka-prometheus.yaml即可部署实现部署实现后将prometheus裸露给监控组的grafana，能够直连pod IP做验证，而后在k8s管控台的 网络-->路由-->创立， 创立一个ingress，抉择刚刚部署的这个Prometheus的service，而后找运维申请域名，即可。总结长处疾速部署集群（分钟级），疾速集群扩容（秒级），疾速劫难复原（秒级）反对滚动更新，反对备份以及还原毛病引入较多组件，复杂度升高对K8S集群外的拜访不太敌对文/ZUOQI ...

基本概念kafka中的生产过程设计多个概念的配合，理清这些概念的关系，有利于了解kafka的生产机制。 角色作用producer生产音讯，向kafka推送音讯，非kafka组件之一topic逻辑概念，用于组织一类音讯brokerbroker运行着kafka实例partition存储同一个topic的分区（多个分区独特存储一个topic的音讯）replicationpartition的正本，为保障稳定性，同一个partition须要在不同broker上设置备份leaderpartition的泛滥replication的一个，生产方向其中写入，生产方从中读取followerpartition除leader外的replication。用于备份partition的内容保障稳定性下图直观反映了kafka的各种概念的关系。 zookeeper在kafka中的角色zookeeper为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。它能够保障一致性和分区容错性，在kafka中zookeeper为broker，producer和consumer提供统一的配置信息。在上面的解说中咱们将会具体展现。 生产过程produce会计算本条音讯须要发送的partition。produce依据发送的分区，向zookeeper获取对应partition的leader信息，发送音讯到leader所在的broker。leader在本地记录该音讯。follower通过轮询监控到leader新写入音讯，被动拉取音讯。follower同步音讯胜利向leader发送ack。leader收到所有follower同步的音讯，向producer发送确认ack。

偏移量索引偏移量索引是一个从逻辑偏移量映射到物理文件地位的索引。 每一个条数据占用 8B = 4B(relativeOffset) + 4B(position) 工夫索引工夫索引是一个日志段的工夫戳和偏移量的索引。 每一个条数据占用 12B = 8B(timestamp) + 4B(relativeOffset) 两个索引文件的特点： 两个文件都是稠密索引（Sparse indexes）预调配文件大小，默认为10MB，这个空间大小，只有在日志滚动时才会变成实在大小。工夫索引和偏移量索引共享雷同的索引大小配置，索引项文件的大小个别为偏移索引项大小的1.5倍。

ElasticsearchNode-1#装置dockersudo yum update -ysudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum install docker-ce -y;docker -v;mkdir -p /etc/docker;cd /etc/docker;cat > daemon.json <<EOF{"registry-mirrors": \["https://docker.mirrors.ustc.edu.cn"\]}EOFsudo curl -L "https://get.daocloud.io/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composedocker-compose -vsystemctl daemon-reload;systemctl restart docker;docker info;systemctl enable dockersystemctl start dockersystemctl status dockerdocker ps -a#创立目录上传证书mkdir -p /data/modules/es/certs#上传证书到/data/modules/es/config/certs#链接：https://pan.baidu.com/s/1_-RojJNqt1w_o8P9ugDyTQ 提取码：o93o mkdir -p /data/modules/es/configmkdir -p /data/modules/es/logsmkdir -p /data/modules/es/datamkdir -p /data/modules/es/plugins## 写入配置文件cd /data/modules/es/configcat > elasticsearch.yml << EOFcluster.name: es-clusternode.name: node-1network.host: 0.0.0.0network.publish_host: 10.0.0.21http.port: 9200transport.port: 9300bootstrap.memory_lock: truediscovery.seed_hosts: ["10.0.0.21:9300","10.0.0.22:9300","10.0.0.23:9300"]cluster.initial_master_nodes: ["10.0.0.21","10.0.0.22","10.0.0.23"]http.cors.enabled: truehttp.cors.allow-origin: "*"xpack.security.enabled: truexpack.security.transport.ssl.enabled: truexpack.security.transport.ssl.verification_mode: certificatexpack.security.transport.ssl.keystore.path: "certs/elastic-certificates.p12"xpack.security.transport.ssl.truststore.path: "certs/elastic-certificates.p12"xpack.monitoring.collection.enabled: truexpack.monitoring.exporters.my_local.type: localxpack.monitoring.exporters.my_local.use_ingest: falseEOF#受权开始口chown es:es /data/modules -Rfirewall-cmd --zone=public --add-port=9100/tcp --permanent;firewall-cmd --zone=public --add-port=9200/tcp --permanent;firewall-cmd --zone=public --add-port=9300/tcp --permanent;firewall-cmd --zone=public --add-service=http --permanent;firewall-cmd --zone=public --add-service=https --permanent;firewall-cmd --reload;firewall-cmd --list-all;#容器网络systemctl restart dockerdocker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net## 创立容器docker run --name es \-d --network=es-net \--ip=10.10.10.21 \--restart=always \--publish 9200:9200 \--publish 9300:9300 \--privileged=true \--ulimit nofile=655350 \--ulimit memlock=-1 \--memory=2G \--memory-swap=-1 \--volume /data/modules/es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \--volume /data/modules/es/data:/usr/share/elasticsearch/data \--volume /data/modules/es/logs:/usr/share/elasticsearch/logs \--volume /data/modules/es/certs:/usr/share/elasticsearch/config/certs \--volume /etc/localtime:/etc/localtime \-e TERM=dumb \-e ELASTIC_PASSWORD='elastic' \-e ES_JAVA_OPTS="-Xms256m -Xmx256m" \-e path.data=data \-e path.logs=logs \-e node.master=true \-e node.data=true \-e node.ingest=false \-e node.attr.rack="0402-K03" \-e gateway.recover_after_nodes=1 \-e bootstrap.memory_lock=true \-e bootstrap.system_call_filter=false \-e indices.fielddata.cache.size="25%" \elasticsearch:7.17.0#登陆账号密码elasticelasticNode-2sudo yum update -ysudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum install docker-ce -y;docker -v;mkdir -p /etc/docker;cd /etc/docker;cat > daemon.json <<EOF{"registry-mirrors": \["https://docker.mirrors.ustc.edu.cn"\]}EOFsudo curl -L "https://get.daocloud.io/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composedocker-compose -vsystemctl daemon-reload;systemctl restart docker;docker info;systemctl enable dockersystemctl start dockersystemctl status dockerdocker ps -a#创立目录上传证书mkdir -p /data/modules/es/certs#上传证书到/data/modules/es/config/certs#链接：https://pan.baidu.com/s/1_-RojJNqt1w_o8P9ugDyTQ 提取码：o93o mkdir -p /data/modules/es/configmkdir -p /data/modules/es/logsmkdir -p /data/modules/es/datamkdir -p /data/modules/es/plugins## 写入配置文件cd /data/modules/es/configcat > elasticsearch.yml << EOFcluster.name: es-clusternode.name: node-2network.host: 0.0.0.0network.publish_host: 10.0.0.22http.port: 9200transport.port: 9300bootstrap.memory_lock: truediscovery.seed_hosts: ["10.0.0.21:9300","10.0.0.22:9300","10.0.0.23:9300"]cluster.initial_master_nodes: ["10.0.0.21","10.0.0.22","10.0.0.23"]http.cors.enabled: truehttp.cors.allow-origin: "*"xpack.security.enabled: truexpack.security.transport.ssl.enabled: truexpack.security.transport.ssl.verification_mode: certificatexpack.security.transport.ssl.keystore.path: "certs/elastic-certificates.p12"xpack.security.transport.ssl.truststore.path: "certs/elastic-certificates.p12"xpack.monitoring.collection.enabled: truexpack.monitoring.exporters.my_local.type: localxpack.monitoring.exporters.my_local.use_ingest: falseEOF#受权开始口chown es:es /data/modules -Rfirewall-cmd --zone=public --add-port=9100/tcp --permanent;firewall-cmd --zone=public --add-port=9200/tcp --permanent;firewall-cmd --zone=public --add-port=9300/tcp --permanent;firewall-cmd --zone=public --add-service=http --permanent;firewall-cmd --zone=public --add-service=https --permanent;firewall-cmd --reload;firewall-cmd --list-all;#容器网络systemctl restart dockerdocker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net## 创立容器docker run --name es \-d --network=es-net \--ip=10.10.10.22 \--restart=always \--publish 9200:9200 \--publish 9300:9300 \--privileged=true \--ulimit nofile=655350 \--ulimit memlock=-1 \--memory=2G \--memory-swap=-1 \--volume /data/modules/es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \--volume /data/modules/es/data:/usr/share/elasticsearch/data \--volume /data/modules/es/logs:/usr/share/elasticsearch/logs \--volume /data/modules/es/certs:/usr/share/elasticsearch/config/certs \--volume /etc/localtime:/etc/localtime \-e TERM=dumb \-e ELASTIC_PASSWORD='elastic' \-e ES_JAVA_OPTS="-Xms256m -Xmx256m" \-e path.data=data \-e path.logs=logs \-e node.master=true \-e node.data=true \-e node.ingest=false \-e node.attr.rack="0402-K03" \-e gateway.recover_after_nodes=1 \-e bootstrap.memory_lock=true \-e bootstrap.system_call_filter=false \-e indices.fielddata.cache.size="25%" \elasticsearch:7.17.0#登陆账号密码elasticelasticnode-3sudo yum update -ysudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum install docker-ce -y;docker -v;mkdir -p /etc/docker;cd /etc/docker;cat > daemon.json <<EOF{"registry-mirrors": \["https://docker.mirrors.ustc.edu.cn"\]}EOFsudo curl -L "https://get.daocloud.io/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composedocker-compose -vsystemctl daemon-reload;systemctl restart docker;docker info;systemctl enable dockersystemctl start dockersystemctl status dockerdocker ps -a#创立目录上传证书mkdir -p /data/modules/es/certs#上传证书到/data/modules/es/config/certs#链接：https://pan.baidu.com/s/1_-RojJNqt1w_o8P9ugDyTQ 提取码：o93o mkdir -p /data/modules/es/configmkdir -p /data/modules/es/logsmkdir -p /data/modules/es/datamkdir -p /data/modules/es/plugins## 写入配置文件cd /data/modules/es/configcat > elasticsearch.yml << EOFcluster.name: es-clusternode.name: node-3network.host: 0.0.0.0network.publish_host: 10.0.0.23http.port: 9200transport.port: 9300bootstrap.memory_lock: truediscovery.seed_hosts: ["10.0.0.21:9300","10.0.0.22:9300","10.0.0.23:9300"]cluster.initial_master_nodes: ["10.0.0.21","10.0.0.22","10.0.0.23"]http.cors.enabled: truehttp.cors.allow-origin: "*"xpack.security.enabled: truexpack.security.transport.ssl.enabled: truexpack.security.transport.ssl.verification_mode: certificatexpack.security.transport.ssl.keystore.path: "certs/elastic-certificates.p12"xpack.security.transport.ssl.truststore.path: "certs/elastic-certificates.p12"xpack.monitoring.collection.enabled: truexpack.monitoring.exporters.my_local.type: localxpack.monitoring.exporters.my_local.use_ingest: falseEOF#受权开始口chown es:es /data/modules -Rfirewall-cmd --zone=public --add-port=9100/tcp --permanent;firewall-cmd --zone=public --add-port=9200/tcp --permanent;firewall-cmd --zone=public --add-port=9300/tcp --permanent;firewall-cmd --zone=public --add-service=http --permanent;firewall-cmd --zone=public --add-service=https --permanent;firewall-cmd --reload;firewall-cmd --list-all;#容器网络systemctl restart dockerdocker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net## 创立容器docker run --name es \-d --network=es-net \--ip=10.10.10.23 \--restart=always \--publish 9200:9200 \--publish 9300:9300 \--privileged=true \--ulimit nofile=655350 \--ulimit memlock=-1 \--memory=2G \--memory-swap=-1 \--volume /data/modules/es/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \--volume /data/modules/es/data:/usr/share/elasticsearch/data \--volume /data/modules/es/logs:/usr/share/elasticsearch/logs \--volume /data/modules/es/certs:/usr/share/elasticsearch/config/certs \--volume /etc/localtime:/etc/localtime \-e TERM=dumb \-e ELASTIC_PASSWORD='elastic' \-e ES_JAVA_OPTS="-Xms256m -Xmx256m" \-e path.data=data \-e path.logs=logs \-e node.master=true \-e node.data=true \-e node.ingest=false \-e node.attr.rack="0402-K03" \-e gateway.recover_after_nodes=1 \-e bootstrap.memory_lock=true \-e bootstrap.system_call_filter=false \-e indices.fielddata.cache.size="25%" \elasticsearch:7.17.0#登陆账号密码elasticelasticKibanaMaster#装置Dockersudo yum update -ysudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum install docker-ce -y;docker -v;mkdir -p /etc/docker;cd /etc/docker;cat > daemon.json <<EOF{"registry-mirrors": \["https://docker.mirrors.ustc.edu.cn"\]}EOF#装置docker-composesudo curl -L "https://get.daocloud.io/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composedocker-compose -v#重启dockersystemctl daemon-reload;systemctl restart docker;docker info;systemctl enable dockersystemctl start dockersystemctl status dockerdocker ps -a#开启防火墙firewall-cmd --zone=public --add-port=5601/tcp --permanent;firewall-cmd --zone=public --add-service=http --permanent;firewall-cmd --zone=public --add-service=https --permanent;firewall-cmd --reload;firewall-cmd --list-all;#创立容器网络docker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \elk-net#下载镜像docker pull kibana:7.17.0#装置Kibanadocker run --name kibana \-d --network=elk-net \--ip=10.10.10.11 \--restart=always \--publish 5601:5601 \--privileged=true \kibana:7.17.0#进入容器docker exec -it -u root kibana /bin/bashcd /usr/share/kibana/configcat > kibana.yml << EOFserver.name: kibanaserver.port: 5601i18n.locale: "zh-CN"server.host: "0.0.0.0"kibana.index: ".kibana"server.shutdownTimeout: "5s"server.publicBaseUrl: "http://10.0.0.11:5601"monitoring.ui.container.elasticsearch.enabled: trueelasticsearch.hosts: ["http://10.0.0.21:9200","http://10.0.0.22:9200","http://10.0.0.23:9200"]elasticsearch.username: "elastic"elasticsearch.password: "elastic"EOFexitdocker restart kibanaZookeeper+KafkaNode-1#Zookeeper-1#ELK同网络docker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net#创立映射目录mkdir -p /data/modules/zookeeper/datamkdir -p /data/modules/zookeeper/logsmkdir -p /data/modules/zookeeper/conf#(myid)须要与server.(id)雷同 cd /data/modules/zookeeper/datacat > myid << EOF1EOF#写入配置文件cd /data/modules/zookeeper/conf/cat > zoo.cfg << EOF#集群节点间心跳查看距离，单位是毫秒，后续所有和工夫相干的配置都是该值的倍数，进行整数倍的配置，如4等于8000tickTime=2000#集群其余节点与Master通信实现的初始通信工夫限度，这里代表10*2000initLimit=10#若Master节点在超过syncLimit*tickTime的工夫还未收到响应，认为该节点宕机syncLimit=5#数据寄存目录dataDir=/data#ZK日志文件寄存门路dataLogDir=/logs#ZK服务端口clientPort=2181#单个客户端最大连接数限度，0代表不限度maxClientCnxns=60#快照文件保留的数量autopurge.snapRetainCount=3#清理快照文件和事务日志文件的频率，默认为0代表不开启，单位是小时autopurge.purgeInterval=1#server.A=B:C:D 集群设置，#A示意第几号服务器；#B是IP;#C是该服务器与leader通信端口；#D是leader挂掉后从新选举所用通信端口；两个端口号能够随便server.1=0.0.0.0:2888:3888server.2=10.0.0.22:2888:3888server.3=10.0.0.23:2888:3888EOF#开启端口firewall-cmd --permanent --zone=public --add-port=2181/tcp;firewall-cmd --permanent --zone=public --add-port=2888/tcp;firewall-cmd --permanent --zone=public --add-port=3888/tcp;firewall-cmd --reload#下载镜像docker pull zookeeper:3.7.0#创立容器docker run -d \-p 2181:2181 \-p 2888:2888 \-p 3888:3888 \--network=es-net \--name zookeeper \--ip=10.10.10.31 \--privileged=true \--restart always \-v /data/modules/zookeeper/data:/data \-v /data/modules/zookeeper/logs:/logs \-v /data/modules/zookeeper/data/myid:/data/myid \-v /data/modules/zookeeper/conf/zoo.cfg:/conf/zoo.cfg \zookeeper:3.7.0#查看容器docker ps#装置Kafkadocker pull wurstmeister/kafka#创立日志目录mkdir -p /data/modules/kafka/logs#创立容器docker run -d --name kafka \--publish 9092:9092 \--network=es-net \--ip=10.10.10.41 \--privileged=true \--restart always \--link zookeeper \--env KAFKA_ZOOKEEPER_CONNECT=10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181 \--env KAFKA_ADVERTISED_HOST_NAME=10.0.0.21 \--env KAFKA_ADVERTISED_PORT=9092 \--env KAFKA_LOG_DIRS=/kafka/kafka-logs-1 \-v /data/modules/kafka/logs:/kafka/kafka-logs-1 \wurstmeister/kafka:2.13-2.8.1#下载镜像docker pull sheepkiller/kafka-manager:alpine#kafka-managerdocker run -itd --restart=always \--name=kafka-manager \-p 9000:9000 \--network=es-net \--ip=10.10.10.51 \--privileged=true \-e ZK_HOSTS="10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181" \sheepkiller/kafka-manager:alpineNode-2#Zookeeper-1#ELK同网络docker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net#创立映射目录mkdir -p /data/modules/zookeeper/datamkdir -p /data/modules/zookeeper/logsmkdir -p /data/modules/zookeeper/conf#(myid)须要与server.(id)雷同 cd /data/modules/zookeeper/datacat > myid << EOF2EOF#写入配置文件cd /data/modules/zookeeper/conf/cat > zoo.cfg << EOF#集群节点间心跳查看距离，单位是毫秒，后续所有和工夫相干的配置都是该值的倍数，进行整数倍的配置，如4等于8000tickTime=2000#集群其余节点与Master通信实现的初始通信工夫限度，这里代表10*2000initLimit=10#若Master节点在超过syncLimit*tickTime的工夫还未收到响应，认为该节点宕机syncLimit=5#数据寄存目录dataDir=/data#ZK日志文件寄存门路dataLogDir=/logs#ZK服务端口clientPort=2181#单个客户端最大连接数限度，0代表不限度maxClientCnxns=60#快照文件保留的数量autopurge.snapRetainCount=3#清理快照文件和事务日志文件的频率，默认为0代表不开启，单位是小时autopurge.purgeInterval=1#server.A=B:C:D 集群设置，#A示意第几号服务器；#B是IP;#C是该服务器与leader通信端口；#D是leader挂掉后从新选举所用通信端口；两个端口号能够随便server.1=10.0.0.21:2888:3888server.2=0.0.0.0:2888:3888server.3=10.0.0.23:2888:3888EOF#开启端口firewall-cmd --permanent --zone=public --add-port=2181/tcp;firewall-cmd --permanent --zone=public --add-port=2888/tcp;firewall-cmd --permanent --zone=public --add-port=3888/tcp;firewall-cmd --reload#下载镜像docker pull zookeeper:3.7.0#创立容器docker run -d \-p 2181:2181 \-p 2888:2888 \-p 3888:3888 \--network=es-net \--name zookeeper \--ip=10.10.10.32 \--privileged=true \--restart always \-v /data/modules/zookeeper/data:/data \-v /data/modules/zookeeper/logs:/logs \-v /data/modules/zookeeper/data/myid:/data/myid \-v /data/modules/zookeeper/conf/zoo.cfg:/conf/zoo.cfg \zookeeper:3.7.0#查看容器docker ps#装置Kafkadocker pull wurstmeister/kafka#创立日志目录mkdir -p /data/modules/kafka/logs#创立容器docker run -d --name kafka \--publish 9092:9092 \--network=es-net \--ip=10.10.10.42 \--privileged=true \--restart always \--link zookeeper \--env KAFKA_ZOOKEEPER_CONNECT=10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181 \--env KAFKA_ADVERTISED_HOST_NAME=10.0.0.22 \--env KAFKA_ADVERTISED_PORT=9092 \--env KAFKA_LOG_DIRS=/kafka/kafka-logs-1 \-v /data/modules/kafka/logs:/kafka/kafka-logs-1 \wurstmeister/kafka#下载镜像docker pull sheepkiller/kafka-manager:alpine#kafka-managerdocker run -itd --restart=always \--name=kafka-manager \-p 9000:9000 \--network=es-net \--ip=10.10.10.52 \--privileged=true \-e ZK_HOSTS="10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181" \sheepkiller/kafka-manager:alpineNode-3#Zookeeper-1#ELK同网络docker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \es-net#创立映射目录mkdir -p /data/modules/zookeeper/datamkdir -p /data/modules/zookeeper/logsmkdir -p /data/modules/zookeeper/conf#(myid)须要与server.(id)雷同 cd /data/modules/zookeeper/datacat > myid << EOF3EOF#写入配置文件cd /data/modules/zookeeper/conf/cat > zoo.cfg << EOF#集群节点间心跳查看距离，单位是毫秒，后续所有和工夫相干的配置都是该值的倍数，进行整数倍的配置，如4等于8000tickTime=2000#集群其余节点与Master通信实现的初始通信工夫限度，这里代表10*2000initLimit=10#若Master节点在超过syncLimit*tickTime的工夫还未收到响应，认为该节点宕机syncLimit=5#数据寄存目录dataDir=/data#ZK日志文件寄存门路dataLogDir=/logs#ZK服务端口clientPort=2181#单个客户端最大连接数限度，0代表不限度maxClientCnxns=60#快照文件保留的数量autopurge.snapRetainCount=3#清理快照文件和事务日志文件的频率，默认为0代表不开启，单位是小时autopurge.purgeInterval=1#server.A=B:C:D 集群设置，#A示意第几号服务器；#B是IP;#C是该服务器与leader通信端口；#D是leader挂掉后从新选举所用通信端口；两个端口号能够随便server.1=10.0.0.21:2888:3888server.2=10.0.0.22:2888:3888server.3=0.0.0.0:2888:3888EOF#开启端口firewall-cmd --permanent --zone=public --add-port=2181/tcp;firewall-cmd --permanent --zone=public --add-port=2888/tcp;firewall-cmd --permanent --zone=public --add-port=3888/tcp;firewall-cmd --reload#下载镜像docker pull zookeeper:3.7.0#创立容器docker run -d \-p 2181:2181 \-p 2888:2888 \-p 3888:3888 \--network=es-net \--name zookeeper \--ip=10.10.10.33 \--privileged=true \--restart always \-v /data/modules/zookeeper/data:/data \-v /data/modules/zookeeper/logs:/logs \-v /data/modules/zookeeper/data/myid:/data/myid \-v /data/modules/zookeeper/conf/zoo.cfg:/conf/zoo.cfg \zookeeper:3.7.0#查看容器docker ps#装置Kafkadocker pull wurstmeister/kafka#创立日志目录mkdir -p /data/modules/kafka/logs#创立容器docker run -d --name kafka \--publish 9092:9092 \--network=es-net \--ip=10.10.10.43 \--privileged=true \--restart always \--link zookeeper \--env KAFKA_ZOOKEEPER_CONNECT=10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181 \--env KAFKA_ADVERTISED_HOST_NAME=10.0.0.23 \--env KAFKA_ADVERTISED_PORT=9092 \--env KAFKA_LOG_DIRS=/kafka/kafka-logs-1 \-v /data/modules/kafka/logs:/kafka/kafka-logs-1 \wurstmeister/kafka#下载镜像docker pull sheepkiller/kafka-manager:alpine#kafka-managerdocker run -itd --restart=always \--name=kafka-manager \-p 9000:9000 \--network=es-net \--ip=10.10.10.53 \--privileged=true \-e ZK_HOSTS="10.0.0.21:2181,10.0.0.22:2181,10.0.0.23:2181" \sheepkiller/kafka-manager:alpineLogstashmaster#装置Dockersudo yum update -ysudo yum install -y yum-utils device-mapper-persistent-data lvm2sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.reposudo yum install docker-ce -y;docker -v;mkdir -p /etc/docker;cd /etc/docker;cat > daemon.json <<EOF{"registry-mirrors": \["https://docker.mirrors.ustc.edu.cn"\]}EOF#装置docker-composesudo curl -L "https://get.daocloud.io/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-composedocker-compose -v#重启dockersystemctl daemon-reload;systemctl restart docker;docker info;systemctl enable dockersystemctl start dockersystemctl status dockerdocker ps -a#开启防火墙firewall-cmd --zone=public --add-port=5044/tcp --permanent;firewall-cmd --zone=public --add-service=http --permanent;firewall-cmd --zone=public --add-service=https --permanent;firewall-cmd --reload;firewall-cmd --list-all;#对立目录if [ ! -d "/data/software" ]; then mkdir -p /data/software/fiif [ ! -d "/data/modules/mysql/" ]; then mkdir -p /data/modules/fimkdir -p /data/modules/logstash/conf/cd /data/modules/logstash/conf/cat > logstash.yml << EOFhttp.host: "0.0.0.0"path.config: /usr/share/logstash/config/conf.d/*.confpath.logs: /usr/share/logstash/logsxpack.monitoring.enabled: truexpack.monitoring.elasticsearch.username: elasticxpack.monitoring.elasticsearch.password: elasticxpack.monitoring.elasticsearch.hosts: [ "http://10.0.0.21:9200","http://10.0.0.22:9200","http://10.0.0.23:9200" ]EOFcat > conf.d << EOFinput { beats { port => 5044 } file { #Nginx日志目录 path => "/usr/local/nginx/logs/access.log" start_position => "beginning" }}filter { if [path] =~ "access" { mutate { replace => { "type" => "nginx_access" } } grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } } date { #工夫戳 match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ] }}output { elasticsearch { #承受主机 hosts => ["${NODE_1_IP}:9200","${NODE_2_IP}:9200","${NODE_3_IP}:9200"] } stdout { codec => rubydebug }}EOF#创立容器网络docker network create \--driver=bridge \--subnet=10.10.10.0/24 \--ip-range=10.10.10.0/24 \--gateway=10.10.10.254 \elk-net#下载镜像docker pull elastic/logstash:7.17.0#启动容器docker run -dit --name=logstash \-d --network=elk-net \--ip=10.10.10.12 \--publish 5044:5044 \--restart=always --privileged=true \-e ES_JAVA_OPTS="-Xms512m -Xmx512m" \-v /data/modules/logstash/conf/logstash.yml:/usr/share/logstash/config/logstash.yml \-v /data/modules/logstash/conf/conf.d/:/usr/share/logstash/config/conf.d/ \elastic/logstash:7.17.0FilebeatclientFilebeatmysql#!/bin/bashMYSQL_V=5.7.37TMP_DIR=/tmp INSTALL_DIR=/usr/localfunction install_mysql(){ MYSQL_BASE=/usr/local/mysql cd $TMP_DIR file="mysql-5.7.37-linux-glibc2.12-x86_64.tar.gz" if [ ! -f $file ]; then echo "File not found!" yum install -y wget && wget -c wget https://cdn.mysql.com//Downloads/MySQL-5.7/mysql-5.7.37-linux-glibc2.12-x86_64.tar.gz; echo "下载实现,正在解压......."; tar -zxvf mysql-5.7.37-linux-glibc2.12-x86_64.tar.gz mv mysql-5.7.37-linux-glibc2.12-x86_64 /usr/local/mysql cd /usr/local/mysql #exit 0 fi echo "创立用户组" userdel mysql; groupadd mysql; useradd -r -g mysql mysql; mkdir -p /data/mysql; chown mysql:mysql -R /data/mysql;cd /etcecho "写入配置文件"cat > my.cnf <<EOF[mysqld]bind-address=0.0.0.0 #绑定地址运行近程连贯port=3306 #Mysql凋谢的端口user=mysql #数据库登录用户basedir=/usr/local/mysql #Mysql装置的绝对路径datadir=/data/mysql #Mysql数据寄存的绝对路径socket=/tmp/mysql.sock #套接字文件log-error=/data/mysql/mysql.err #mysql生成的谬误日志寄存的门路pid-file=/data/mysql/mysql.pid #为mysqld程序指定一个寄存过程ID的文件character_set_server=utf8mb4 #数据库字符编码symbolic-links=0 #是否开启链接符号explicit_defaults_for_timestamp=true #数据库timestamp类型的列自动更新EOFecho "初始化Mysql"cd /usr/local/mysql/bin/./mysqld --defaults-file=/etc/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --user=mysql --initializesleep 2secho "启动mysql"cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqlservice mysql startservice mysql statusln -s /usr/local/mysql/bin/mysql /usr/binecho "获取mysql初始密码"PASSWORD=`cat /data/mysql/mysql.err |grep "temporary password"|awk -F"root@localhost: " '{print $2}'`echo "批改mysql明码"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock --connect-expired-password -uroot -p${PASSWORD} -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'root@.com';"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock -uroot -proot@.com -e "FLUSH PRIVILEGES;"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock -uroot -proot@.com -e "USE mysql;"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock -uroot -proot@.com -e "UPDATE user SET host = '%' WHERE user = 'root';"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock -uroot -proot@.com -e "FLUSH PRIVILEGES;"$MYSQL_BASE/bin/mysql --socket=/tmp/mysql.sock -uroot -proot@.com -e "exit;"echo "重启数据库"service mysql restart;service mysql status;service mysql stop;sleep 2s;echo "以服务项启动"cd /usr/lib/systemd/systemcat > mysq.service << EOF[Unit]Description=MysqlAfter=syslog.target network.target remote-fs.target nss-lookup.target[Service]Type=forkingPIDFile=/data/mysql/mysql.pidExecStart=/usr/local/mysql/support-files/mysql.server startExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s QUIT $MAINPIDPrivateTmp=false[Install]WantedBy=multi-user.targetEOFsystemctl start mysqlsystemctl enable mysqlsystemctl status mysql#cp /usr/local/mysql/support-files/mysql.server /etc/rc.d/init.d/mysqld;#chmod +x /etc/init.d/mysqld;#chkconfig --add mysqld;#chkconfig --list;firewall-cmd --zone=public --add-port=3306/tcp --permanent;firewall-cmd --reload;firewall-cmd --list-all;echo "=========> MYSQL信息 <========="echo " 数据库版本 : 5.7.37 "echo " 数据库明码 : root@.com "echo " 数据库端口 : 3306 "echo " BASEDIR目录: /usr/local/mysql "echo " DATADIR目录: /data/mysql "}install_mysqlnginx#!/bin/bash#Nginx版本NGINX_V=1.20.0#Nginx下载目录TMP_DIR=/tmp #Nginx装置目录INSTALL_DIR=/usr/localfunction install_nginx() {#下载依赖yum -y install gcc gcc-c++ automake pcre pcre-devel zlib zlib-devel openssl openssl-devel#下载Nginxcd ${TMP_DIR}yum install -y wget && wget -c wget http://nginx.org/download/nginx-${NGINX_V}.tar.gz#解压源码tar -zxvf ${TMP_DIR}/nginx-${NGINX_V}.tar.gzmv nginx-${NGINX_V} nginx;cd nginx;#预编译配置./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_modulesleep 2s#编译装置make && make install#以服务启动cd /usr/lib/systemd/system;cat > nginx.service <<EOF[Unit]Description=nginx - high performance web serverDocumentation=http://nginx.org/en/docs/After=network.target remote-fs.target nss-lookup.target [Service]Type=forkingPIDFile=/usr/local/nginx/logs/nginx.pidExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.confExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.confExecReload=/bin/kill -s HUP $MAINPIDExecStop=/bin/kill -s QUIT $MAINPIDPrivateTmp=true [Install]WantedBy=multi-user.targetEOFsystemctl restart firewalld;firewall-cmd --reload;systemctl start nginx;systemctl enable nginx;systemctl status nginx.service;}install_nginxredis#!/bin/bashsudo yum install net-tools -yIP=`ifconfig -a|grep inet|grep -v 127.0.0.1|grep -v inet6|awk '{print $2}'|tr -d "addr:"|grep "10."`REDIS_PASSWD=123456#编译环境yum -y install centos-release-scl devtoolset-9-gccyum -y install devtoolset-9-gcc-c++ devtoolset-9-binutilsscl enable devtoolset-9 bashecho "source /opt/rh/devtoolset-9/enable" >> /etc/profilegcc -vinstall_redis(){#对立目录if [ ! -d "/data/software" ]; then mkdir -p /data/software/fi#近程下载cd /data/software/file="redis-6.2.6.tar.gz"if [ ! -f $file ]; then yum install -y wget && wget http://download.redis.io/releases/redis-6.2.6.tar.gz #exit 0fi#解压编译cd /data/softwaretar -zxvf redis-6.2.6.tar.gz -C /usr/local/cd /usr/local/mv redis-6.2.6 rediscd redissudo makesleep 2ssudo make PREFIX=/usr/local/redis installmkdir /usr/local/redis/etc/cp /usr/local/redis/redis.conf /usr/local/redis/redis.conf.bak#写入配置cd /usr/local/rediscat > redis.conf << EOF//是否后盾运行，no不是，yes是daemonize no//端口 默认 6379port 6379//日志文件地址logfile "/var/log/redis.log"//如果要开启外网拜访请批改上面值bind 127.0.0.1protected-mode yes//明码requirepass 123456protected-mode no EOF#环境变量cd /etc/cat >> profile << EOFexport REDIS_HOME=/usr/local/redisexport PATH=$PATH:$REDIS_HOME/bin/EOFsource /etc/profile#端口firewall-cmd --permanent --zone=public --add-port=6379/tcpfirewall-cmd --reload#启动rediscd /usr/local/redis/binln -s /usr/local/redis/bin/redis-server /usr/bin/redis-serverln -s /usr/local/redis/bin/redis-cli /usr/bin/redis-cliredis-server}install_redis

Apache Kafka 是由 Apache 治理的开源流解决平台，由 Scala 和 Java 编写，为解决实时数据提供了对立、高吞吐、低提早的性能个性。 其长久化层实质上是一个“依照分布式事务日志架构的大规模公布/订阅音讯队列”，这使它作为企业级基础设施来解决流式数据十分有价值。目前已被数千家公司用于高性能数据管道、流剖析、数据集成和工作要害型应用程序等畛域。 实现形式：kafka-loggerApache APISIX 早在 1.2 版本开始就曾经提供了 kafka-logger 插件的反对，其后又通过屡次性能强化，目前已具备十分成熟且欠缺的性能。反对将 API 申请日志，甚至申请体和响应体以 JSON 格局推送至 Kafka 集群中。 应用 kafka-logger 时，用户能够发送多种数据并自定义发送的日志格局，同时还反对以批处理的形式打包发送日志或进行主动重试等性能。 如何应用步骤一：启动 Kafka 集群本文示例只演示了一种启动形式，其余启动形式细节可参考官网文档。 # 应用 docker-compose 启动一个具备 1个 zookeeper 节点、3个 kafka 节点的集群# 同时还启动一个 EFAK 用于数据监控。version: '3'services: zookeeper: image: confluentinc/cp-zookeeper:6.2.1 hostname: zookeeper ports: - "2181:2181" environment: ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_SERVER_ID: 1 ZOOKEEPER_SERVERS: zookeeper:2888:3888 kafka1: image: confluentinc/cp-kafka:6.2.1 hostname: kafka1 ports: - "9092:9092" environment: KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_INTERNAL://kafka1:19092,LISTENER_DOCKER_EXTERNAL://${DOCKER_HOST_IP:-127.0.0.1}:9092 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181" KAFKA_BROKER_ID: 1 KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO" depends_on: - zookeeper kafka2: image: confluentinc/cp-kafka:6.2.1 hostname: kafka2 ports: - "9093:9093" environment: KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_INTERNAL://kafka2:19093,LISTENER_DOCKER_EXTERNAL://${DOCKER_HOST_IP:-127.0.0.1}:9093 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181" KAFKA_BROKER_ID: 2 KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO" depends_on: - zookeeper kafka3: image: confluentinc/cp-kafka:6.2.1 hostname: kafka3 ports: - "9094:9094" environment: KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_INTERNAL://kafka3:19094,LISTENER_DOCKER_EXTERNAL://${DOCKER_HOST_IP:-127.0.0.1}:9094 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181" KAFKA_BROKER_ID: 3 KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO" depends_on: - zookeeper efak: image: nickzurich/kafka-eagle:2.0.9 hostname: efak ports: - "8048:8048" depends_on: - kafka1 - kafka2 - kafka3步骤二：创立 Topic接下来咱们创立 test Topic 用于收集日志。 ...

1、下载镜像 docker pull wurstmeister/zookeeperdocker pull wurstmeister/kafka2、启动zookeeper docker run -d --name zookeeper -p 2181:2181 -t wurstmeister/zookeeper3、启动kafka（如果服务器在云上，换成外网ip（192.168.1.1）） docker run -d --name kafka \-p 9092:9092 \-e KAFKA_BROKER_ID=0 \-e KAFKA_ZOOKEEPER_CONNECT=192.168.1.1:2181 \-e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.1.1:9092 \-e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 wurstmeister/kafka4、进入容器执行命令docker exec -it 容器id bashcd /opt/kafka_2.13-2.8.1/bin #创立主题kafka-topics.sh --create --zookeeper zookeeper地址:2181 --replication-factor 1 --partitions 1 --topic kafkatest #增加音讯kafka-console-producer.sh --broker-list localhost:9092 --topic kafkatest#生产音讯kafka-console-consumer.sh --zookeeper zookeeper地址:2181 --topic kafkatest --from-beginning

本文梳理次要梳理 Kafka 日志加载与复原的源码。（版本：2.8） 原文链接：http://fxbing.github.io/2022/...日志治理：LogManagerLogManager 是 kafka 日志管理子系统的入口点。负责日志的创立、检索和清理。所有读取和写入操作都委托给各个日志实例。LogManager 在一个或多个目录中保护日志。在日志起码的数据目录中创立新日志。预先不会尝试挪动分区或依据大小或 I/O 速率进行均衡。后盾线程通过定期截断多余的日志段来解决日志保留。LogManger 的启动次要包含三个局部： 日志加载与复原，即：loadLogs各个定时工作启动，次要包含： a. cleanupLogs：依据保留工夫和保留大小进行历史 segment 的清理 b. flushDirtyLogs：定时刷新还没有写到磁盘上日志 c. checkpointLogRecoveryOffsets：定时将所有数据目录所有日志的检查点写到检查点文件中 d. checkpointLogStartOffsets：将所有日志的以后日志开始偏移量写到日志目录中的文本文件中，以防止裸露已被 DeleteRecordsRequest 删除的数据 e. deleteLogs：定时删除标记为 delete 的日志文件启动 LogCleaner，负责进行日志 compaction本文次要对第一局部日志加载与复原进行梳理。 // visible for testingprivate[log] def startupWithConfigOverrides(topicConfigOverrides: Map[String, LogConfig]): Unit = { loadLogs(topicConfigOverrides) // this could take a while if shutdown was not clean /* Schedule the cleanup task to delete old logs */ if (scheduler != null) { info("Starting log cleanup with a period of %d ms.".format(retentionCheckMs)) scheduler.schedule("kafka-log-retention", cleanupLogs _, delay = InitialTaskDelayMs, period = retentionCheckMs, TimeUnit.MILLISECONDS) info("Starting log flusher with a default period of %d ms.".format(flushCheckMs)) scheduler.schedule("kafka-log-flusher", flushDirtyLogs _, delay = InitialTaskDelayMs, period = flushCheckMs, TimeUnit.MILLISECONDS) scheduler.schedule("kafka-recovery-point-checkpoint", checkpointLogRecoveryOffsets _, delay = InitialTaskDelayMs, period = flushRecoveryOffsetCheckpointMs, TimeUnit.MILLISECONDS) scheduler.schedule("kafka-log-start-offset-checkpoint", checkpointLogStartOffsets _, delay = InitialTaskDelayMs, period = flushStartOffsetCheckpointMs, TimeUnit.MILLISECONDS) scheduler.schedule("kafka-delete-logs", // will be rescheduled after each delete logs with a dynamic period deleteLogs _, delay = InitialTaskDelayMs, unit = TimeUnit.MILLISECONDS) } if (cleanerConfig.enableCleaner) { _cleaner = new LogCleaner(cleanerConfig, liveLogDirs, currentLogs, logDirFailureChannel, time = time) _cleaner.startup() }}全副日志加载与复原：loadLogs所有日志的加载与复原的流程次要蕴含以下几步： ...

简介滴滴Logi-KafkaManager脱胎于滴滴外部多年的Kafka经营实践经验，是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台。专一于Kafka运维管控、监控告警、资源治理等外围场景，经验过大规模集群、海量大数据的考验。 疾速部署Logikm首先依据官网文档装置 Rainbond LogiKm 已公布至 开源利用商店 ，用户可搜寻 logikm，一键装置 Logikm Kafka Manager 装置后，拜访 logikm-front即可进入，默认明码：admin / admin 疾速部署Kafka集群下面咱们曾经部署了 Logikm，接下来咱们也可通过 开源利用商店 装置Kafka集群并进行对接。 Kafka 已公布至 开源利用商店 ，用户可搜寻 kafka，一键装置 Kafka-Zookeeper-Bitnami 装置实现后，咱们进入 kafka1 和 kafka2 的组件 -> 环境变量 批改 KAFKA_CFG_ADVERTISED_LISTENERS 环境变量为组件9092端口的对外IP + 端口，例如：PLAINTEXT://192.168.3.162:10000 批改 JMX_PORT 环境变量为TCP对外端口地址供 Logikm 获取指标。例如：JMX_PORT为9999，组件对应的端口也要为9999，同时tcp对外端口也是9999 应用Logikm对接并治理Kafka集群接下来咱们通过 Logikm 对接刚刚装置的 kafka集群。 拜访 logikm-front，进入 运维管控 -> 接入集群，依据页面提醒填写对应信息。 对接实现后，咱们就可通过 Logikm 治理 kafka 集群啦。 Reference LinkLogikm Github https://github.com/didi/LogiKM 装置Rainbond https://www.rainbond.com/docs... 对于RainbondRainbond 是一个开源的云原生利用治理平台，应用简略，不须要懂容器和Kubernetes，反对治理多个Kubernetes集群，提供企业级利用的全生命周期治理，性能包含利用开发环境、利用市场、微服务架构、利用继续交付、利用运维、利用级多云治理等。 Github：https://github.com/goodrain/r... 官网：https://www.rainbond.com 微信群：关注 Rainbond 公众号退出技术交换群 钉钉群：请搜寻钉钉群号 31096419 ...

摘要：大海可能带走你的哀愁，就像带走每条河流…… 周三，一个一般的日子。 你孑然一身，但海哥陪你一起过！ 打怪降级涨姿态，不是节日胜似节日。 海哥闭关修炼多日，再次激情发新：尚硅谷Kafka新版视频教程公布！ 2022，大数据Kafka全新学习路线降级 Kafka是高吞吐量的分布式公布订阅音讯零碎，能够解决消费者在网站中的所有动作流数据。作为大数据畛域全面且开源的分布式事件流平台，已成为大数据从业人员的必备技能。 Kafka新版视频相较原版全方位大降级！ 基于Kafka 3.x最新稳定版解说，新增了Kafka-Kraft模式，内容更新更全面：一、新增内部系统集成，与Flume、Flink、Spring Boot、Spark集成；二、新增生产调优手册，依靠理论我的项目，更多更全的生产调优教训一网打尽；三、新增源码解析，对生产者源码、消费者源码深刻分析，揭开Kafka源码的神秘面纱。 教程既有经典知识点解说：Kafka架构解析、生产者API解说、消费者API解说、正本存储策略、分区分配机制等，助你轻松入门Kafka；更有进阶知识点解说：生产者可靠性及程序性保障、消费者自定义生产分区、offset和工夫、消费者事务解说、数据积压解决等，带你玩转Kafka！ 还是尚硅谷一贯的格调，手敲代码保姆式解说，教辅材料败家式赠送，视频、代码、材料、按出书规范编写的上课笔记、多达60页技术点详解的幻灯片动画，全副送送送！一套教程，满足你对学习Flink的全副空想。 关注尚硅谷官网账号，一手最新视频教程领先看！ 教程具体目录： 01.Kafka-课程简介02.Kafka-概述-定义03.Kafka-概述-音讯队列利用场景04.Kafka-概述-音讯队列两种模式05.Kafka-概述-基础架构06.Kafka-入门-装置Kafka07.Kafka-入门-启动进行脚本08.Kafka-入门-Topic命令09.Kafka-入门-命令行操作10.Kafka-生产者-原理11.Kafka-生产者-异步发送12.Kafka-生产者-回调异步发送13.Kafka-生产者-同步发送14.Kafka-生产者-分区15.Kafka-生产者-分区策略16.Kafka-生产者-自定义分区17.Kafka-生产者-进步生产者吞吐量18.Kafka-生产者-数据牢靠19.Kafka-生产者-数据反复20.Kafka-生产者-数据有序21.Kafka-生产者-数据乱序22.Kafka-Broker-ZK存储23.Kafka-Broker-工作原理24.Kafka-Broker-高低线25.Kafka-Broker-退役新节点（上）26.Kafka-Broker-退役新节点（下）27.Kafka-Broker-服役旧节点28.Kafka-每日回顾（上）29.Kafka-每日回顾（下）30.Kafka-Broker-正本根本信息31.Kafka-Broker-Leader选举32.Kafka-Broker-Follower故障33.Kafka-Broker-Leader故障34.Kafka-Broker-分区正本调配35.Kafka-Broker-手动调整分区正本调配 36.Kafka-Broker-LeaderPartition负载平衡37.Kafka-Broker-减少正本因子38.Kafka-Broker-文件存储机制39.Kafka-Broker-文件革除策略40.Kafka-Broker-高效读写41.Kafka-消费者-生产形式42.Kafka-消费者-消费者总体工作流程43.Kafka-消费者-消费者组工作原理44.Kafka-消费者-消费者组初始化45.Kafka-消费者-消费者组具体生产流程46.Kafka-消费者-生产一个主题47.Kafka-消费者-生产一个分区48.Kafka-消费者-消费者组案例49.Kafka-消费者-Range调配50.Kafka-消费者-Roundrobin51.Kafka-消费者-Sticky52.Kafka-消费者-offset保留地位53.Kafka-消费者-主动offset54.Kafka-消费者-手动offser55.Kafka-消费者-指定offset56.Kafka-消费者-依照工夫生产57.Kafka-消费者-消费者事务58.Kafka-消费者-数据积压59.Kafka-每日回顾（上）60.Kafka-每日回顾（下）61.Kafka-监控-MySQL环境筹备62.Kafka-监控-Kafka环境筹备63.Kafka-监控-Kafka-Eagle装置64.Kafka-监控-Kafka-Eagle监控页面65.Kafka-Kraft模式66.Kafka-集成-Flume环境筹备67.Kafka-集成-Flume生产者68.Kafka-集成-Flume消费者69.Kafka-集成-Flink生产者70.Kafka-集成-Flink消费者71.Kafka-集成-SpringBoot生产者72.Kafka-集成-SpringBoot消费者73.Kafka-集成-Spark生产者74.Kafka-集成-Spark消费者75.Kafka-调优-内容简介76.Kafka-调优-硬件抉择77.Kafka-调优-生产者调优78.Kafka-调优-Broker调优79.Kafka-调优-消费者调优80.Kafka-调优-总体调优81.Kafka-调优-生产者压力测试82.Kafka-调优-消费者压力测试83.Kafka-源码-环境筹备84.Kafka-源码-生产者原理回顾85.Kafka-源码-生产者初始化86.Kafka-源码-生产者发送数据到缓存87.Kafka-源码-生产者Sender线程88.Kafka-源码-消费者原理回顾89.Kafka-源码-消费者初始化90.Kafka-源码-消费者订阅主题91.Kafka-源码-生产总体流程92.Kafka-源码-消费者组初始化流程93.Kafka-源码-消费者组拉取和解决数据94.Kafka-源码-消费者Offset提交95.Kafka-源码-服务器端源码96.Kafka-结束语 关键词：大数据培训

Kafka 音讯以 Partition 作为存储单元，那么在 Partition 那音讯是以什么样的格局存储的呢，如何解决 Partition 中的音讯，又有哪些安全策略来保障音讯不会失落呢，这一篇咱们一起看看这些问题。 Partition 文件存储形式#每个 Topic 的音讯被一个或者多个 Partition 进行治理，Partition 是一个有序的，不变的音讯队列，音讯总是被追加到尾部。一个 Partition 不能被切分成多个散落在多个 broker 上或者多个磁盘上。 它作为音讯治理名义上最大的管家内里其实是由很多的 Segment 文件组成。如果一个 Partition 是一个单个十分长的文件的话，那么这个查找操作会十分慢并且容易出错。为解决这个问题，Partition 又被划分成多个 Segment 来组织数据。Segment 并不是终极存储，在它的上面还有两个组成部分： 索引文件：以 .index 后缀结尾，存储以后数据文件的索引；数据文件：以 .log 后缀结尾，存储以后索引文件名对应的数据文件。 Segment 文件的命名规定是： 某个 Partition 全局的第一个 Segment 从 0 开始，后续每个 Segment 文件名以以后 Partition 的最大 offset(音讯偏移量)为基准,文件名长度为 64 位 long 类型，19 位数字字符长度，有余局部用 0 填充。 如何通过 offset 找到 某一条音讯呢？首先会依据 offset 值去查找 Segment 中的 index 文件，因为 index 文件是以上个文件的最大 offset 偏移命名的所以能够通过二分法疾速定位到索引文件。找到索引文件后，索引文件中保留的是 offset 和对应的音讯行在 log 日志中的存储型号，因为 Kafka 采纳稠密矩阵的形式来存储索引信息，并不是每一条索引都存储，所以这里只是查到文件中合乎以后 offset 范畴的索引。拿到 以后查到的范畴索引对应的行号之后再去对应的 log 文件中从 以后 Position 地位开始查找 offset 对应的音讯，直到找到该 offset 为止。每一条音讯的组成内容有如下字段： ...

简介：本文通过喜马拉雅的RocketMQ治理实际分享，让大家理解应用消息中间件过程中可能遇到的问题，防止实战中踩坑。 作者：曹融，来自喜马拉雅，从事微服务和音讯相干中间件开发。 本文通过喜马拉雅的RocketMQ治理实际分享，让大家理解应用消息中间件过程中可能遇到的问题，防止实战中踩坑。 业务背景现状以及遇到的问题1、音讯队列详情（1）在线场景：RabbitMQ，实例数9个； （2）离线场景：Kafka，8个集群； 2、遇到的问题在线场景不足治理： • 业务混用，互相烦扰，非核心对接积压过多触发集群限流； • 节点负载不平衡，资源节约重大； • 资源和利用无关联，音讯积压； • 业务混用，互相烦扰，非核心对接积压过多触发集群限流； 在线MQ集群革新计划1、选型（1）业务便捷性：易于开发、应用、保护，提高效率，如自带重试、自带死信、自带事务保障； （2）性能：容纳业务的不确定性，如抗短时突发流量、抗积压等； （3）简略：架构实用于拆分小集群；Java语言易于排查问题和二次开发；社区沉闷，应用的人多，不便排查问题； 2、治理计划（1）集群划分方针：划分小集群，缩小互相烦扰，缩小影响面； （2）拆分计划： 如上图所示，对于公司和“钱”相干的业务及外围业务，不仅要给足资源，同时要保障较高的数据安全，在这里就应用了SYNC_MASTER； 对于非核心业务，咱们心愿它的性价比高，应用尽量少的资源去撑持足够多的数据量，此处就应用了ASYNC_MASTER，伸缩性会更好； 对于其它数据安全要求不高的业务，包含音讯轨迹，咱们应用单MASTER集群，保障了性能须要，资源应用也少； 对于延时集群，专一于积压音讯，pagecache利用率低，目前还没用做，将来思考在云上采纳按需购买的形式来应用；另外对于长期集群目前也没有波及。 3、管制面治理（1）对立音讯治理后盾； 对所有消息中间件的后盾做了一个对立的治理后盾，如上图。 （2）对RabbitMQ，仅保护，主动保护关联关系； （3）对于RocketMQ，用于晋升用户体验，比方发送/查问音讯、一键接入demo、死信重发等； 音讯治理界面 配置demo 死信重发 （4）PaaS化审批 咱们对音讯化的资源管理做了一个PaaS化的治理，对性能做了一些限度，开发和运维只能在测试环境下做申请和审批，审批通过后再同步到其它环境，而后创立资源、告诉用户。 4、对立接入SDK（1）用户只关怀用什么资源，不须要理解namesrv地址，缩小出错概率； （2）动静配置热失效，节约用户工夫； （3）收/发消息，失败重试，为中间件做兜底； （4）熔断限流，为业务做兜底； （5）灰度收音讯（音讯开关），满足业务非凡场景； （6）集成公司其余性能，如调用链、全链路压测等； 5、多维度监控运维：整体状况，cluster 内 top 状况，所属物理机状况； 资源：Topic 上下游 qps，lag 等； 用户：实例音讯收发平均，提早。 老集群迁徙计划1、人工迁徙场景：音讯上下游均为本人的服务； 迁徙流程：双收（RocketMQ&RabbitMQ）-> 双发-> 单发（RocketMQ）-> 单收； 须要留神的问题：业务重构，topic合并可能导致上游多tag音讯歪斜，导致lag异样问题； 2、主动迁徙RabbitMQ <--> RocketMQ 互相镜像迁徙； 粒度: exchange < -- > topic； ...

前言技术栈OS: Ubuntu 20.04 LTSdocker: 20.10.12docker-compose: 1.25.0kafka: 2.8.1kafka-map: 1.2.0搭建 kafkakafka docker 镜像：https://hub.docker.com/r/wurs...kafka docker 镜像 github： https://github.com/wurstmeister搜寻 kafka 镜像# docker search kafkaNAME DESCRIPTION STARS OFFICIAL AUTOMATEDwurstmeister/kafka Multi-Broker Apache Kafka Image 1469 [OK]spotify/kafka A simple docker image with both Kafka and Zo… 414 [OK]sheepkiller/kafka-manager kafka-manager 214 [OK]kafkamanager/kafka-manager Docker image for Kafka manager 145 ches/kafka Apache Kafka. Tagged versions. JMX. Cluster-… 117 [OK]列出 tagwget -q https://registry.hub.docker.com/v1/repositories/wurstmeister/kafka/tags -O - | sed -e 's/[][]//g' -e 's/"//g' -e 's/ //g' | tr '}' '\n' | awk -F: '{print $3}'也能够用 podman 命令列出docker image search --list-tags wurstmeister/kafka --limit 1000编排文件 docker-compose.ymlversion: '3.5'services: zookeeper: image: wurstmeister/zookeeper:3.4.6 container_name: zookeeper ports: - "2181:2181" restart: unless-stopped kafka: image: wurstmeister/kafka:2.13-2.8.1 container_name: kafka ports: - "9092:9092" environment: - KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181 - KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.1.46:9092 - KAFKA_LISTENERS=PLAINTEXT://:9092 volumes: - /var/run/docker.sock:/var/run/docker.sock restart: unless-stopped启动 kafka 和 zookeeperdocker-compose up -d查看 kafka 和 zookeeper 是否失常运行docker stats kafka zookeeper可视化工具试用了 LogiKM 2.6.0、Offset Explorer 2.2（kafka tool）都不太称心最初差强人意的抉择了国产的 kafka-mapdocker 装置 kafka-mapdocker run -d \ -p 8888:8080 \ -v /opt/kafka-map/data:/usr/local/kafka-map/data \ -e DEFAULT_USERNAME=admin \ -e DEFAULT_PASSWORD=admin \ --name kafka-map \ --restart unless-stopped dushixiang/kafka-map:latest装置完后用浏览器关上 http://192.168.1.46:8888，在 web 界面中接入 kafkaPython 读写 kafka未完待续...本文出自 qbit snap

简介Kafka起初是由LinkedIn公司采⽤Scala语⾔开发的⼀个多分区、多正本且基于ZooKeeper协调的分布式 音讯零碎，现已募捐给Apache基⾦会。⽬前Kafka曾经定位为⼀个分布式流式解决平台，它以⾼吞吐、 可长久化、可⽔平扩大、⽀持流数据处理等多种个性被⼴泛使⽤。 在0.10版本之前，Kafka次要定位是分布式、⾼吞吐、低提早的音讯引擎，平时⼯作中常⽤的消息中间件还有很多，⽐如RabbitMQ，RocketMQ等。 从0.10版本开始，Kafka提供了连接器（kafka connect）和流解决（kafka stream），定位也从音讯引擎变为流式解决平台。⽬前⽐较流⾏的另⼀个流式解决平台Pulsar。Pulsar与Kafka的对⽐也被⼤家津津有味，其⼤局部都是对⽐ Pulsar 和 Kafka 在性能、架构和个性⽅⾯的区别。 Kafka一些重要概念Producer：音讯⽣产者，向 Kafka Broker 发消息的客户端。Consumer：音讯消费者，从 Kafka Broker 取音讯的客户端。Consumer Group：消费者组(CG)，消费者组内每个消费者负责生产不同分区的数据，提⾼生产能 ⼒。⼀个分区只能由组内⼀个消费者生产，消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的⼀个订阅者。Broker：⼀台 Kafka 机器就是⼀个Broker。⼀个集群由多个 Broker 组成。⼀个 Broker 能够包容多个 Topic。Topic：能够了解为⼀个队列，Topic 将音讯分类，⽣产者和消费者⾯向的是同⼀个Topic。Partition：为了实现扩展性，提⾼并发能⼒，⼀个⾮常⼤的Topic 能够散布到多个 Broker (即服务器)上，⼀个Topic能够分为多个Partition，每个Partition是⼀个有序的队列。Replica：正本，为实现备份的性能，保障集群中的某个节点发⽣故障时，该节点上的Partition数据不失落，且 Kafka依然可能持续⼯作，Kafka提供了正本机制，⼀个Topic的每个分区都有若⼲个正本，⼀个 Leader和若⼲个Follower。Leader：每个分区多个正本的“主”正本，⽣产者发送数据的对象，以及消费者生产数据的对象，都是Leader。Follower：每个分区多个正本的“从”正本，实时从 Leader中同步数据，放弃和Leader数据的同步。Leader 发⽣故障时，某个Follower 还会成为新的Leader。Offset：消费者生产的地位信息，监控数据生产到什么地位，当消费者挂掉再从新复原的时候，能够从生产地位持续生产。Zookeeper：Kafka集群可能失常⼯作，须要依赖于 Zookeeper，Zookeeper 帮忙 Kafka 存储和 治理集群信息。Kafka原理控制器选举及复原控制器是Kafka的核⼼组件之⼀，它的次要作⽤是在 ZooKeeper 的帮忙下协调和治理整个Kafka集群。 Kafka 利⽤ZooKeeper 的领导者选举机制，每个Broker 都会参加竞选主控制器，然而最终只会有⼀个 Broker 能够成为主控制器。控制器有以下⼏个职责： 监听分区相干的变动，例如：运⾏kafka-reassign-partitions.sh 脚本对已有主题分区的细粒度的调配性能监听主题相干的变动监听broker相干的变动控制器选举：每个代理节点都会作为ZooKeeper的客户端，向ZooKeeper 服务端尝试创立 /controller 长期节点，然而最终只有 1 个Broker 能够胜利创立长期节点。因为 /controller 节点是长期节点，当主控制器呈现故障或者会话生效时，长期节点会被删除。此时所有的Broker 都会从新竞选 Leader，也就是尝试创立 /controller长期节点。 Kafka控制器将Broker节点信息寄存在 ZooKeeper 的 /controller节点上，每个broker都会在内存中保留以后控制器的brokerid值，这个值能够标识为activeControllerId，每个broker还会对/controller节点增加监听器，以此来监听此节点的数据变动。 当/controller节点的数据发⽣变动时，每个broker都会更新⾃身内存中保留的activeControllerId。如果 broker在数据变更前是控制器，在数据变更后⾃身的brokerid值与新的activeControllerId值不⼀致，那 么就须要“退位”，敞开相应的资源。有可能控制器因为异样⽽下线，造成/controller这个长期节点被⾃动 删除；也有可能是其余起因将此节点删除了。 ...

简介：本篇文章次要介绍 RocketMQ 的可观测性工具在线上生产环境的最佳实际。RocketMQ的可观测性能力当先业界同类产品，RocketMQ 的 Dashboard 和音讯轨迹等性能为业务外围链路保驾护航，有效应对线上大规模生产应用过程中遇到的容量布局、音讯收发问题排查以及自定义监控等场景。 作者：文婷、不周 引言：本篇文章次要介绍 RocketMQ 的可观测性工具在线上生产环境的最佳实际。RocketMQ的可观测性能力当先业界同类产品，RocketMQ 的 Dashboard 和音讯轨迹等性能为业务外围链路保驾护航，有效应对线上大规模生产应用过程中遇到的容量布局、音讯收发问题排查以及自定义监控等场景。 音讯队列简介进入主题之前，首先简要介绍下什么是阿里云的音讯队列？ 阿里云提供了丰盛的音讯产品家族，音讯产品矩阵涵盖了互联网、大数据、物联网等各个业务场景的畛域，为云上客户提供了多维度可选的音讯解决方案。无论哪一款音讯队列产品，外围都是帮忙用户解决业务和零碎的异步、解耦以及应答流量洪峰时的削峰填谷，同时具备分布式、高吞吐、低提早、高可扩大等个性。 然而不同的音讯产品在面向客户业务的利用中也有不同的偏重。简略来做，音讯队列 RocketMQ 是业务畛域的首选音讯通道；Kafka 是大数据畛域不可或缺的音讯产品；MQTT 是物联网畛域的音讯解决方案；RabbitMQ 侧重于传统业务音讯畛域；云原生的产品集成和事件流通道是通过音讯队列 MNS 来实现；最初事件总线 EventBridge 是一个阿里云上的一个事件枢纽，对立构建事件核心。 本篇次要讲的是业务畛域的音讯首选通道：音讯队列 RocketMQ。RocketMQ 诞生于阿里的电商零碎，具备高性能、低提早、削峰填谷等能力，并且提供了丰盛的在业务和音讯场景上应答刹时流量洪峰的性能，被集成在用户的外围业务链路上。 作为一个外围业务链路上的音讯，就要求 RocketMQ 具备十分高的可观测性能力，用户能通过可观测性能力及时的监控定位异样稳定，同时对具体的业务数据问题进行排查。由此，可观测性能力逐渐成为音讯队列 RocketMQ 的外围能力之一。 那么什么是可观测能力呢？上面简略对可观测能力进行介绍。 可观测能力提到可观测能力，大家可能最先想到的是可观测的三要素：Metrics（指标）、Tracing（追踪）和 Logging（日志）。 联合音讯队列的了解，可观测能力三要素的细化解释如下： Metrics：Dashborad 大盘 1）指标涵盖丰盛：蕴含音讯量、沉积量、各个阶段耗时等指标，每个指标从实例、Topic、生产 GroupID 多维度做聚合和展现； 2）音讯团队最佳实际模板：为用户提供最佳模板，特地是在简单的生产音讯场景，提供了丰盛的指标帮忙疾速定位问题，并继续迭代更新； 3）Prometheus + Grafana：Prometheus规范数据格式、利用Grafana展现，除了模板，用户也能够自定义展现大盘。 Tracing：音讯轨迹 1）OpenTelemetry tracing规范：RocketMQ tracing 规范曾经合并到 OpenTelemetry 开源规范，标准和丰盛 messaging tracing 场景定义； 2）音讯畛域定制化展现：依照音讯维度从新组织形象的申请 span 数据，展现一对多的生产，屡次生产信息，直观、不便了解； 3）可连接 tracing链路上下游：音讯的 tracing 可继承调用上下文，补充到残缺调用链路中，音讯链路信息串联了异步链路的上游和上游链路信息。 Logging：客户端日志标准化 1）Error Code标准化：不同的谬误有惟一的 error code； ...

本文转载自公众号 StreamCloudNative，作者薛松，就任于新大陆软件，负责高级软件工程师。  编辑：鸡排，StreamNative。 对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。  以后已有泛滥国内外大型互联网和传统行业公司采纳 Apache Pulsar，案例散布在人工智能、金融、电信运营商、直播与短视频、物联网、批发与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。  背景介绍Apache Pulsar 作为一个云原生的分布式音讯零碎，包含 Zookeeper、bookie、broker、functions-worker、proxy 等多个组件，并且所有的组件以分布式的形式部署在多台主机上，因而每个组件的日志文件也就扩散在多台主机上，当组件呈现问题时，因为日志比拟扩散，想要查看各个服务是否有报错信息，须要挨个服务去排查，比拟麻烦，通常咱们的做法是间接对日志文件进行 grep、awk 等命令就能够取得想要的信息。然而，随着利用和服务体量的减少，撑持的节点也随之减少，那么传统办法暴露出很多问题，比方：效率低下、日志量太大如何归档、文本搜寻太慢怎么办、如何多维度查问等等。所以咱们心愿通过对日志进行聚合、监控，可能疾速的找到 Pulsar 各个服务的报错信息，疾速的排查，使得运维更加具备目的性、针对性和间接性。 为了解决日志检索的问题，咱们团队思考应用集中式日志收集零碎，将 Pulsar 所有节点上的日志对立收集，治理，拜访。 一个残缺的集中式日志零碎，须要蕴含以下几个次要特点： 收集－可能采集多种起源的日志数据；传输－可能稳固的把日志数据传输到地方零碎；存储－如何存储日志数据；剖析－能够反对 UI 剖析；正告－可能提供错误报告，监控机制.ELK 提供了一整套解决方案，并且都是开源软件，之间互相配合应用，完满连接，高效的满足了很多场合的利用，是目前支流的一种日志零碎。咱们公司领有自研的大数据管理平台，通过大数据管理平台部署和治理 ELK，并且在生产零碎中曾经应用ELK 为多个业务零碎提供了撑持服务。 ELK 是三个开源软件的缩写，别离示意：Elasticsearch、Logstash、Kibana , 它们都是开源软件，最新版本曾经改名为 Elastic Stack，并新增了 Beats我的项目，其中包含 FileBeat，它是一个轻量级的日志收集解决工具 (Agent)，Filebeat 占用资源少，适宜于在各个服务器上收集日志后传输给 Logstash。 在上图中能够看到，如果 Pulsar 应用这种日志采集模式存在两个问题： 部署了 Pulsar 服务的主机必须部署一套 Filebeat 服务；Pulsar 服务的日志必须以文件的形式落一次磁盘，占用了主机磁盘的 IO。为此，咱们思考 Apache Pulsar 基于 Log4j2+Kafka+ELK 实现日志的疾速检索，Log4j2 默认反对将日志发送到 Kafka 的性能，应用 Kafka 自带的 Log4j2Appender，在 Log4j2 配置文件中进行相应的配置，即可实现将 Log4j2 产生的日志实时发送至 Kafka 中。 ...

<center>大家好,我是彦祖~</center> 问题形容最近彦祖发现,有不少同学 对 <font size=2 color=red>acks</font> 和 <font size=2 color=red>min.insync.replicas</font> 的配置存在不少误会. 刚好拿一个同学的问题,来好好阐明一下 依据下面提的几个问题, 整顿一下几个知识点 acks = all 的概念是什么？min.insync.replicas 是怎么用的？什么状况下会产生数据失落的危险？<font color=blue>为更好的浏览体验,和及时的勘误</font> 请拜访原文链接：acks和min.insync.replicas配置详解和数据失落场景的一次探讨 问题解答acks = all<font size=3 color=red>acks=0</font>: 生产者不会期待服务器的任何确认, 该记录将立刻增加到Socket Buffer Pool 并被视为已发送，这种状况,不保障发送胜利,可能会失落数据。 <font size=3 color=red>acks=1</font>: 这个保障了至多Leader正本会将数据写入到本地日志中,不论其余正本是否写入。所以当Leader同步胜利之后,还没有来得及同步给Follower正本就宕机了。那么就会失落数据。 <font size=3 color=red>acks=-1/all</font>: 这个确保<font color=blue>ISR中的所有同步正本列表</font>中都确认写入了数据之后,才会视为发送胜利, 所以这个配置能够提供最高级的数据可靠性的保障, 不会失落数据。 然而,就算咱们设置了<font size=3 color=red>acks=-1/all</font> , 并且也有3个正本, 然而这个时候 Follower正本都没有退出到ISR的汇合中, ISR 只剩下了一个 Leader 正本。如果这个Leader宕机了, 是不是可能会造成分区不可用或者数据失落的状况了 ！ 那么这种状况是不是就跟 ack=1的状况一样了, 相当于只保障了Leader写入了数据。还是达不到高可靠性。 那么，怎么解决这个问题呢？是不是只须要让 ISR 外面的同步正本 >1 就行了, 只有一个挂掉了,还有1个作为备份。 最小同步正本数 min.insync.replicas最小同步正本数, 示意的是 ISR 列表外面最小的个数。这个是跟<font size=3 color=red>acks=-1/all</font>配套应用的,默认是=1。 ...

计划背景 假如每天集群须要承载10亿数据。一天24小时，早晨12点到凌晨8点简直没多少数据。 应用二八法令预计，也就是80%的数据（8亿）会在16个小时涌入，而且8亿的80%的数据（6.4亿）会在这16个小时的20%工夫（3小时）涌入。 QPS计算公式：640000000 ÷ (3x60x60) = 60000，也就是说高峰期的时候Kafka集群要扛住每秒6万的并发。 磁盘空间计算，每天10亿数据，每条50kb，也就是46T的数据。保留2个正本（在上一篇中也提到过其实两个正本会比拟好，因为follower须要去leader那里同步数据，大数据培训同步数据的过程须要消耗网络，而且须要磁盘空间，然而这个须要依据理论状况思考），46 2 = 92T，保留最近3天的数据。故须要 92 3 = 276T。 QPS方面 部署Kafka，Hadoop，MySQL……等外围分布式系统，个别倡议间接采纳物理机，摈弃应用一些低配置的虚拟机的想法。高并发这个货色，不可能是说，你须要撑持6万QPS，你的集群就刚好把这6万并发卡的死死的。退出某一天出一些流动让数据量疯狂上涨，那整个集群就会垮掉。 然而，如果说你只有撑持6w QPS，单台物理机自身就能扛住4~5万的并发。所以这时2台物理机相对相对够了。然而这里有一个问题，咱们通常是倡议，公司估算短缺，尽量是让顶峰QPS管制在集群能承载的总QPS的30%左右（也就是集群的解决能力是高峰期的3~4倍这个样子），所以咱们搭建的kafka集群能承载的总QPS为20万~30万才是平安的。所以大体上来说，须要5~7台物理机来部署，基本上就很平安了，每台物理机要求吞吐量在每秒4~5万条数据就能够了，物理机的配置和性能也不须要特地高。 磁盘方面 磁盘数量 须要5台物理机的状况，须要存储276T的数据，均匀下来差不多一台56T的数据。这个具体看磁盘数和盘的大小。 SAS还是SSD 当初咱们须要思考一个问题：是须要SSD固态硬盘，还是一般机械硬盘？ SSD就是固态硬盘，比机械硬盘要快，那么到底是快在哪里呢？其实SSD的快次要是快在磁盘随机读写，就要对磁盘上的随机地位来读写的时候，SSD比机械硬盘要快。比如说MySQL这种就应该应用SSD了（MySQL须要随机读写）。北京大数据培训比如说咱们在布局和部署线上零碎的MySQL集群的时候，一般来说必须用SSD，性能能够进步很多，这样MySQL能够承载的并发申请量也会高很多，而且SQL语句执行的性能也会进步很多。 因为写磁盘的时候Kafka是程序写的。机械硬盘程序写的性能机会跟内存读写的性能是差不多的，所以对于Kafka集群来说其实应用机械硬盘就能够了。如果是须要本人守业或者是在公司老本有余的状况下，经费是可能缩减就尽量缩减的。 内存角度 JVM十分怕呈现full gc的状况。Kafka本身的JVM是用不了过多堆内存的，因为Kafka设计就是躲避掉用JVM对象来保留数据，防止频繁full gc导致的问题，所以个别Kafka本身的JVM堆内存，调配个10G左右就够了，剩下的内存全副留给OS cache。 那服务器须要多少内存呢。咱们估算一下，大略有100个topic，所以要保障有100个topic的leader partition的数据在操作系统的内存里。100个topic，一个topic有5个partition。那么总共会有500个partition。每个partition的大小是1G（在上一篇中的日志分段存储中规定了.log文件不能超过1个G），咱们有2个正本，也就是说要把100个topic的leader partition数据都驻留在内存里须要1000G的内存。 咱们当初有5台服务器，所以均匀下来每天服务器须要200G的内存，然而其实partition的数据咱们没必要所有的都要驻留在内存外面，只须要25%的数据在内存就行，200G * 0.25 = 50G就能够了（因为在集群中的生产者和消费者简直也算是实时的，根本不会呈现音讯积压太多的状况）。所以一共须要60G（附带上刚刚的10G Kafka服务）的内存，故咱们能够筛选64G内存的服务器也行，大不了partition的数据再少一点在内存，当然如果可能提供128G内存那就更好。 CPU core CPU布局，次要是看你的这个过程里会有多少个线程，线程次要是依靠多核CPU来执行的，如果你的线程特地多，然而CPU核很少，就会导致你的CPU负载很高，会导致整体工作线程执行的效率不太高，上一篇的Kafka的网络设计中讲过Kafka的Broker的模型。acceptor线程负责去接入客户端的连贯申请，然而他接入了之后其实就会把连贯调配给多个processor，默认是3个，然而个别生产环境倡议大家还是多加几个，整体能够晋升kafka的吞吐量比如说你能够减少到6个，或者是9个。另外就是负责解决申请的线程，是一个线程池，默认是8个线程，在生产集群里，倡议大家能够把这块的线程数量略微多加个2倍~3倍，其实都失常，比如说搞个16个工作线程，24个工作线程。 后盾会有很多的其余的一些线程，比如说定期清理7天前数据的线程，Controller负责感知和管控整个集群的线程，正本同步拉取数据的线程，这样算下来每个broker起码会有上百个线程。依据教训4个CPU core，一般来说几十个线程，在高峰期CPU简直都快打满了。8个CPU core，也就可能比拟拮据的撑持几十个线程忙碌的工作。所以Kafka的服务器个别是倡议16核，基本上能够hold住一两百线程的工作。当然如果能够给到32 CPU core那就最好不过了。 网卡 当初的网根本就是千兆网卡（1GB / s），还有万兆网卡（10GB / s）。kafka集群之间，broker和broker之间是会做数据同步的，因为leader要同步数据到follower下来，他们是在不同的broker机器上的，broker机器之间会进行频繁的数据同步，传输大量的数据。那每秒两台broker机器之间大略会传输多大的数据量？ 高峰期每秒大略会涌入6万条数据，约每天解决10000个申请，每个申请50kb，故每秒约进来488M数据，咱们还有正本同步数据，故高峰期的时候须要488M * 2 = 976M/s的网络带宽，所以在高峰期的时候，应用千兆带宽，网络还是十分有压力的。

一、前言咱们上一篇聊了 Rebalance 机制，置信你对生产组的重均衡有个整体的意识。这里再简略回顾一下，Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如何生产订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，Consumer Group 下所有的 Consumer 实例独特参加，在 Coordinator 协调者组件的帮忙下，实现订阅主题分区的调配。然而，在整个过程中，所有实例都不能生产任何音讯，因而它对 Consumer 的 TPS 影响很大。像不像 JVM 的 GC？咱们晓得 JVM 频繁 GC 的话，对时延敏感的业务来说，几乎是噩梦，所以咱们会针对 GC 进行相应的调优，让 JVM 不那么频繁的产生 STW。 Kafka 生产组的重均衡也是相似的，生产组产生重均衡，Consumer 就很慢，对于实时性不敏感的业务，慢一点也能承受，就怕 Consumer 解决业务超时了，生产组把 Consumer 踢出去了，业务设置重试机制，主动从线程池中拿出一个新线程作为消费者去订阅 topic，那么意味着有新消费者退出 Consumer Group，又会引发 Rebalance，新的消费者还是来不及解决完所有音讯，又被移出 Consumer Group。如此循环，就产生了频繁的 Rebalance 景象。 二、Rebalance 的弊病Rebalance 影响 Consumer 端 TPS，Coordinator 协调者组件实现订阅主题分区的调配的过程，该生产组下所有实例都不能生产任何音讯。如果你的组成员消费者实例很多的话，Rebalance 很慢，对业务会造成肯定的影响。Rebalance 效率不高。以后 Kafka 的设计机制决定了每次 Rebalance 时，Consumer Group 下的所有成员都要参加进来，而且通常不会思考局部性原理，但局部性原理对晋升零碎性能是特地重要的。对于第三点，你是不是感觉，Kafka 社区让所有成员都要参加进来很不合理啊，应该把那个退出生产组的消费者负责的分区随机调配给其它消费者，其它消费者的分区调配策略不变，这样就最大限度地缩小 Rebalance 对残余 Consumer 成员的冲击。 没错，你想到的社区也想到了，社区于 0.11.0.0 版本推出了 StickyAssignor，即有粘性的分区调配策略。所谓的有粘性，是指每次 Rebalance 时，该策略会尽可能地保留之前的调配计划，尽量实现分区调配的最小变动。不过有些遗憾的是，这个策略目前还有一些 bug，而且须要降级到 0.11.0.0 能力应用，因而在理论生产环境中用得还不是很多。 ...

作者：闻乃松 将Flink流式计算引擎作为实时计算作业的标配带来的重大挑战之一是资源占用问题，因为大量的Flink作业一旦启动，将始终占用调配的CPU和内存资源，而不会主动开释（除非是批处理模式），并且不会随着解决负载主动伸缩。本文探讨如何在计算资源无限的状况下，如何最大化利用计算资源。基本思路是将流式计算工作中基于工夫触发的子过程转化为离线定时调度计算工作。上面列举几种常见的场景，姑且当做验证。 一、Kafka数据入湖（仓）作业 比方这样一个kafka topic数据导入示例，将拉取的数据不加解决地写入到Iceberg表： CREATE TABLE KafkaTable ( `event_time` TIMESTAMP(3) METADATA FROM 'value.source.timestamp' VIRTUAL, -- from Debezium format `origin_table` STRING METADATA FROM 'value.source.table' VIRTUAL, -- from Debezium format `partition_id` BIGINT METADATA FROM 'partition' VIRTUAL, -- from Kafka connector `offset` BIGINT METADATA VIRTUAL, -- from Kafka connector `user_id` BIGINT, `item_id` BIGINT, `behavior` STRING) WITH ( 'connector' = 'kafka', 'topic' = 'user_behavior', 'properties.bootstrap.servers' = 'localhost:9092', 'properties.group.id' = 'testGroup', 'scan.startup.mode' = 'earliest-offset', 'value.format' = 'debezium-json');INSERT INTO `hive_catalog`.`default`.`sample` SELECT * from KafkaTable; -- insert into iceberg如果对拉取的频率要求不高，这种状况是能够转换为定时拉取，比方1分钟拉取一批，写入到iceberg，然而须要本人实现拉取的并发管制、状态保留、提交Iceberg的事务性、生产负载平衡等性能。 ...

计划背景假如每天集群须要承载10亿数据。一天24小时，早晨12点到凌晨8点简直没多少数据。 应用二八法令预计，也就是80%的数据（8亿）会在16个小时涌入，而且8亿的80%的数据（6.4亿）会在这16个小时的20%工夫（3小时）涌入。 QPS计算公式：640000000 ÷ (3x60x60) = 60000，也就是说高峰期的时候Kafka集群要扛住每秒6万的并发。 磁盘空间计算，每天10亿数据，每条50kb，也就是46T的数据。保留2个正本（在上一篇中也提到过其实两个正本会比拟好，因为follower须要去leader那里同步数据，大数据培训同步数据的过程须要消耗网络，而且须要磁盘空间，然而这个须要依据理论状况思考），46 2 = 92T，保留最近3天的数据。故须要 92 3 = 276T。 QPS方面部署Kafka，Hadoop，MySQL……等外围分布式系统，个别倡议间接采纳物理机，摈弃应用一些低配置的虚拟机的想法。高并发这个货色，不可能是说，你须要撑持6万QPS，你的集群就刚好把这6万并发卡的死死的。退出某一天出一些流动让数据量疯狂上涨，那整个集群就会垮掉。 然而，如果说你只有撑持6w QPS，单台物理机自身就能扛住4~5万的并发。所以这时2台物理机相对相对够了。然而这里有一个问题，咱们通常是倡议，公司估算短缺，尽量是让顶峰QPS管制在集群能承载的总QPS的30%左右（也就是集群的解决能力是高峰期的3~4倍这个样子），所以咱们搭建的kafka集群能承载的总QPS为20万~30万才是平安的。所以大体上来说，须要5~7台物理机来部署，基本上就很平安了，每台物理机要求吞吐量在每秒4~5万条数据就能够了，物理机的配置和性能也不须要特地高。 磁盘方面磁盘数量须要5台物理机的状况，须要存储276T的数据，均匀下来差不多一台56T的数据。这个具体看磁盘数和盘的大小。 SAS还是SSD当初咱们须要思考一个问题：是须要SSD固态硬盘，还是一般机械硬盘？ SSD就是固态硬盘，比机械硬盘要快，那么到底是快在哪里呢？其实SSD的快次要是快在磁盘随机读写，就要对磁盘上的随机地位来读写的时候，SSD比机械硬盘要快。比如说MySQL这种就应该应用SSD了（MySQL须要随机读写）。北京大数据培训比如说咱们在布局和部署线上零碎的MySQL集群的时候，一般来说必须用SSD，性能能够进步很多，这样MySQL能够承载的并发申请量也会高很多，而且SQL语句执行的性能也会进步很多。 因为写磁盘的时候Kafka是程序写的。机械硬盘程序写的性能机会跟内存读写的性能是差不多的，所以对于Kafka集群来说其实应用机械硬盘就能够了。如果是须要本人守业或者是在公司老本有余的状况下，经费是可能缩减就尽量缩减的。 内存角度JVM十分怕呈现full gc的状况。Kafka本身的JVM是用不了过多堆内存的，因为Kafka设计就是躲避掉用JVM对象来保留数据，防止频繁full gc导致的问题，所以个别Kafka本身的JVM堆内存，调配个10G左右就够了，剩下的内存全副留给OS cache。 那服务器须要多少内存呢。咱们估算一下，大略有100个topic，所以要保障有100个topic的leader partition的数据在操作系统的内存里。100个topic，一个topic有5个partition。那么总共会有500个partition。每个partition的大小是1G（在上一篇中的日志分段存储中规定了.log文件不能超过1个G），咱们有2个正本，也就是说要把100个topic的leader partition数据都驻留在内存里须要1000G的内存。 咱们当初有5台服务器，所以均匀下来每天服务器须要200G的内存，然而其实partition的数据咱们没必要所有的都要驻留在内存外面，只须要25%的数据在内存就行，200G * 0.25 = 50G就能够了（因为在集群中的生产者和消费者简直也算是实时的，根本不会呈现音讯积压太多的状况）。所以一共须要60G（附带上刚刚的10G Kafka服务）的内存，故咱们能够筛选64G内存的服务器也行，大不了partition的数据再少一点在内存，当然如果可能提供128G内存那就更好。 CPU coreCPU布局，次要是看你的这个过程里会有多少个线程，线程次要是依靠多核CPU来执行的，如果你的线程特地多，然而CPU核很少，就会导致你的CPU负载很高，会导致整体工作线程执行的效率不太高，上一篇的Kafka的网络设计中讲过Kafka的Broker的模型。acceptor线程负责去接入客户端的连贯申请，然而他接入了之后其实就会把连贯调配给多个processor，默认是3个，然而个别生产环境倡议大家还是多加几个，整体能够晋升kafka的吞吐量比如说你能够减少到6个，或者是9个。另外就是负责解决申请的线程，是一个线程池，默认是8个线程，在生产集群里，倡议大家能够把这块的线程数量略微多加个2倍~3倍，其实都失常，比如说搞个16个工作线程，24个工作线程。 后盾会有很多的其余的一些线程，比如说定期清理7天前数据的线程，Controller负责感知和管控整个集群的线程，正本同步拉取数据的线程，这样算下来每个broker起码会有上百个线程。依据教训4个CPU core，一般来说几十个线程，在高峰期CPU简直都快打满了。8个CPU core，也就可能比拟拮据的撑持几十个线程忙碌的工作。所以Kafka的服务器个别是倡议16核，基本上能够hold住一两百线程的工作。当然如果能够给到32 CPU core那就最好不过了。 网卡当初的网根本就是千兆网卡（1GB / s），还有万兆网卡（10GB / s）。kafka集群之间，broker和broker之间是会做数据同步的，因为leader要同步数据到follower下来，他们是在不同的broker机器上的，broker机器之间会进行频繁的数据同步，传输大量的数据。那每秒两台broker机器之间大略会传输多大的数据量？ 高峰期每秒大略会涌入6万条数据，约每天解决10000个申请，每个申请50kb，故每秒约进来488M数据，咱们还有正本同步数据，故高峰期的时候须要488M * 2 = 976M/s的网络带宽，所以在高峰期的时候，应用千兆带宽，网络还是十分有压力的。

@[TOC] 目录 思考几个问题什么是分区状态机？创立Topic的时候如何选举Leader？分区的所有正本都不在线, 这个时候启动一台之前不在ISR内的正本,它会入选为Leader吗？当所有正本都不在线,而后一个一个重启Broker上正本上线,谁会入选为Leader？谁先启动就谁入选吗？Broker下线了,Leader切换给了其余正本, 当Broker重启的时候,Leader会还给之前的正本吗?选举胜利的那一刻, 生产者和生产着都做了哪些事件？Leader选举期间对分区的影响<font color=blue>为更好的浏览体验,和及时的勘误</font> 请拜访原文链接：你想晓得的所有对于Kafka Leader选举流程和选举策略都在这(内含12张高清图,倡议珍藏) 分区Leader选举流程剖析在开始源码剖析之前, 大家先看上面这张图, 好让本人对Leader选举有一个十分清晰的认知，而后再去看前面的源码剖析文章,会更容易了解。 整个流程分为三大块 触发选举场景 图左执行选举流程 图中Leader选举策略 图右分区状态机首先大家得理解两个状态机 1. 分区状态机 管制分区状态流转 2. 正本状态机 管制正本状态流转 这里咱们次要解说分区状态机，这张图示意的是分区状态机 NonExistentPartition ：分区在将要被创立之前的初始状态是这个,示意不存在NewPartition： 示意正在创立新的分区, 是一个中间状态, 这个时候只是在Controller的内存中存了状态信息OnlinePartition： 在线状态, 失常的分区就应该是这种状态,只有在线的分区才可能提供服务OfflinePartition： 下线状态, 分区可能因为Broker宕机或者删除Topic等起因流转到这个状态, 下线了就不能提供服务了NonExistentPartition： 分区不存在的状态, 当Topic删除实现胜利之后, 就会流转到这个状态, 当还处在删除中的时候,还是停留在下线状态。咱们明天要讲的Leader选举 就是在之前状态=>OnlinePartition状态的时候产生的。 Leader选举流程剖析源码入口: PartitionStateMachine#electLeaderForPartitions /** * 状态机流转 解决 **/ private def doHandleStateChanges( partitions: Seq[TopicPartition], targetState: PartitionState, partitionLeaderElectionStrategyOpt: Option[PartitionLeaderElectionStrategy] ): Map[TopicPartition, Either[Throwable, LeaderAndIsr]] = { //不相干的代码省略了 targetState match { // 不相干的代码省略了, 这里状态流程到 OnlinePartition case OnlinePartition => // 分区状态是 OfflinePartition 或者 OnlinePartition 的话 就都须要执行一下选举策略 if (partitionsToElectLeader.nonEmpty) { // 依据选举策略 进行选举。这里只是找出 val electionResults = electLeaderForPartitions( partitionsToElectLeader, partitionLeaderElectionStrategyOpt.getOrElse( throw new IllegalArgumentException("Election strategy is a required field when the target state is OnlinePartition") ) ) } }能够看到 咱们最终是调用了doElectLeaderForPartitions 执行分区Leader选举。 ...

无关！ AMQP 是 RabbitMQ 的货色，和 kafka 无关。 参考文章：RabbitMq和kafka的区别

1、为什么会用到kafka（音讯队列的作用） 缓冲和削峰：上游数据时有突发流量，上游可能扛不住，或者上游没有足够多的机器来保障冗余，kafka在两头能够起到一个缓冲的作用，把音讯暂存在kafka中，上游服务就能够依照本人的节奏进行缓缓解决。 解耦和扩展性：我的项目开始的时候，并不能确定具体需要。音讯队列能够作为一个接口层，解耦重要的业务流程。只须要恪守约定，针对数据编程即可获取扩大能力。 冗余：能够采纳一对多的形式，一个生产者公布音讯，能够被多个订阅topic的服务生产到，供多个毫无关联的业务应用。 健壮性：音讯队列能够沉积申请，所以生产端业务即便短时间死掉，也不会影响次要业务的失常进行。 异步通信：很多时候，用户不想也不须要立刻解决音讯。音讯队列提供了异步解决机制，容许用户把一个音讯放入队列，但并不立刻解决它。想向队列中放入多少音讯就放多少，而后在须要的时候再去解决它们。 2、Kafka为什么这么快 利用 Partition 实现并行处理 不同 Partition 可位于不同机器，因而能够充分利用集群劣势，实现机器间的并行处理。另一方面，因为 Partition 在物理上对应一个文件夹，即便多个 Partition 位于同一个节点，也可通过配置让同一节点上的不同 Partition 置于不同的磁盘上，从而实现磁盘间的并行处理，充分发挥多磁盘的劣势。 利用了古代操作系统分页存储 Page Cache 来利用内存进步 I/O 效率 程序写 kafka的音讯是一直追加到文件中的，这个个性使kafka能够充分利用磁盘的程序读写性能因为古代的操作系统提供了预读和写技术，磁盘的程序写大多数状况下比随机写内存还要快。程序读写不须要硬盘磁头的寻道工夫，只需很少的扇区旋转工夫，所以速度远快于随机读写Zero-copy 零拷技术缩小拷贝次数数据批量解决。合并小的申请，而后以流的形式进行交互，直顶网络下限。在很多状况下，零碎的瓶颈不是 CPU 或磁盘，而是网络IO。因而，除了操作系统提供的低级批处理之外，Kafka 的客户端和 broker 还会在通过网络发送数据之前，大数据培训在一个批处理中累积多条记录 (包含读和写)。记录的批处理摊派了网络往返的开销，应用了更大的数据包从而进步了带宽利用率。Pull 拉模式 应用拉模式进行音讯的获取生产，与生产端解决能力相符。数据压缩Kafka还反对对音讯汇合进行压缩，Producer能够通过GZIP、Snappy、LZ4格局对音讯汇合进行压缩，数据压缩个别都是和批处理配套应用来作为优化伎俩的。压缩的益处就是缩小传输的数据量，加重对网络传输的压力Producer压缩之后，在Consumer需进行解压，尽管减少了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是CPU，所以这个老本很值得3、Kafka名词解释以及工作形式 Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker能够包容多个topic。Producer：音讯生产者，向kafka broker发送音讯的客户端。Consumer：音讯消费者，向kafka broker取音讯的客户端。Topic：队列，生产者和消费者通过此进行对接。Consumer Group （CG）：若干个Consumer组成的汇合。这是kafka用来实现一个topic音讯的播送（发给所有的consumer）和单播（发给任意一个consumer）的伎俩。一个topic能够有多个CG。topic的音讯会复制（不是真的复制，是概念上的）到所有的CG，但每个CG只会把音讯发给该CG中的一个consumer。如果须要实现播送，只有每个consumer有一个独立的CG就能够了。要实现单播只有所有的consumer在同一个CG。用CG还能够将consumer进行自在的分组而不须要屡次发送音讯到不同的topic。Partition：分区，为了实现扩展性，一个topic能够散布在多个broker上，一个topic能够分为多个partition，每个partition都是一个有序的队列。partition中的每条音讯都会被调配一个有序的id（offset）。kafka只保障同一个partition中的音讯程序，不保障一个topic的整体（多个partition之间）的程序。生产者和消费者应用时能够指定topic中的具体partition。正本：在kafka中，每个主题能够有多个分区，每个分区又能够有多个正本。这多个正本中，只有一个是leader，而其余的都是follower正本。仅有leader正本能够对外提供服务。多个follower正本通常寄存在和leader正本不同的broker中。通过这样的机制实现了高可用，当某台机器挂掉后，其余follower正本也能迅速”转正“，开始对外提供服务。offset：生产偏移量，topic中的每个分区都是有序且程序不可变的记录集，并且一直地追加到结构化的log文件。分区中的每一个记录都会调配一个id号来示意程序，咱们称之为offset，offset用来惟一的标识分区中每一条记录。能够设置为“主动提交”与“手动提交”。4、Kafka中的AR、ISR、OSR代表什么？HW、LEO、LSO等别离代表什么？ AR:Assigned Replicas 指以后分区中的所有正本。ISR:In-Sync Replicas 正本同步队列。ISR中包含Leader和Foller。如果Leader过程挂掉，会在ISR队列中抉择一个服务作为新的Leader。有replica.lag.max.message(提早条数)和replica.lag.time.max.ms(延迟时间)两个参数决定一台服务器是否能够退出ISR正本队列，在0.10版本之后移除了replica.lag.max.message(提早条数)参数，防治服务频繁的进出队列。任意一个维度超过阈值都会把Follower踢出ISR，存入OSR（Outof-Sync Replicas）列表，新退出的Follower也会先寄存在OSR中。OSR：（Out-of-Sync Replicas）非同步正本队列。与leader正本同步滞后过多的正本（不包含leader正本）组成OSR。如果OSR汇合中有follower正本“追上”了leader正本，那么leader正本会把它从OSR汇合转移至ISR汇合。默认状况下，当leader正本产生故障时，只有在ISR汇合中的正本才有资格被选举为新的leader，而在OSR汇合中的正本则没有任何机会（不过这个准则也能够通过批改unclean.leader.election.enable参数配置来扭转）。unclean.leader.election.enable 为true的话，意味着非ISR汇合的broker 也能够参加选举，这样就有可能产生数据失落和数据不统一的状况，Kafka的可靠性就会升高；而如果unclean.leader.election.enable参数设置为false，Kafka的可用性就会升高。 ISR的伸缩：1）Leader跟踪保护ISR中follower滞后状态，落后太多或生效时，leade把他们从ISR剔除。2）OSR中follower“追上”Leader，在ISR中才有资格选举leader。 LEO （Log End Offset），标识以后日志文件中下一条待写入的音讯的offset。上图中offset为9的地位即为以后日志文件的 LEO，LEO 的大小相当于以后日志分区中最初一条音讯的offset值加1.分区 ISR 汇合中的每个正本都会保护本身的 LEO ，而 ISR 汇合中最小的 LEO 即为分区的 HW，对消费者而言只能生产 HW 之前的音讯。 ...

kafka 应用c/c++ api记录总结confRdKafka::Conf createRdKafka::Conf *conf = RdKafka::create(RdKafka::Conf::CONF_GLOBAL);setConf::ConfResult set(const std::string &name, const std::string &value, std::string &errstr);设置配置对象的属性值，胜利返回CONF_OK，谬误时错误信息输入到errstr。

Kafka是由Apache软件基金会开发的一个开源流解决平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式公布订阅音讯零碎，它能够解决消费者在网站中的所有动作流数据。 （1）长处：kafka的长处十分多 高性能：单机测试能达到 100w tps；低延时：生产和生产的延时都很低，e2e的延时在失常的cluster中也很低；可用性高：replicate + isr + 选举 机制保障；工具链成熟：监控 运维 治理 计划齐全；生态成熟：大数据场景必不可少 kafka stream.（2）有余 无奈弹性扩容：对partition的读写都在partition leader所在的broker，如果该broker压力过大，也无奈通过新增broker来解决问题；扩容老本高：集群中新增的broker只会解决新topic，如果要分担老topic-partition的压力，须要手动迁徙partition，这时会占用大量集群带宽；消费者新退出和退出会造成整个生产组rebalance：导致数据反复生产，影响生产速度，减少e2e提早；partition过多会使得性能显著降落：ZK压力大，broker上partition过多让磁盘程序写简直进化成随机写。在理解了kafka的架构之后，你能够认真想一想，为什么kafka扩容这么吃力呢？其实这实质上和redis集群扩容是一样的！当redis集群呈现热key时，某个实例扛不住了，你通过加机器并不能解决什么问题，因为那个热key还是在之前的某个实例中，新扩容的实例起不到分流的作用。大数据培训kafka相似，它扩容有两种：新加机器（加broker）以及给topic减少partition。 给topic新加partition这个操作，你能够联想一下mysql的分表。比方用户订单表，因为量太大把它按用户id拆分成1024个子表user_order_{0..1023}，如果到前期发现还不够用，要减少这个分表数，就会比拟麻烦。因为分表总数增多，会让user_id的hash值发生变化，从而导致老的数据无奈查问。所以只能停服做数据迁徙，而后再从新上线。 kafka给topic新增partition一样的情理，比方在某些场景下msg蕴含key，那producer就要保障雷同的key放到雷同的partition。然而如果partition总量减少了，依据key去进行hash，比方 hash(key) % parition_num，失去的后果就不同，就无奈保障雷同的key存到同一个partition。 当然也能够在producer上实现一个自定义的partitioner，保障不论怎么扩partition雷同的key都落到雷同的partition上，然而这又会使得新减少的partition没有任何数据。 其实你能够发现一个问题，kafka的外围复杂度简直都在存储这一块。数据如何分片，如何高效的存储，如何高效地读取，如何保障一致性，如何从谬误中复原，如何扩容再均衡……

0 kafka 根本介绍kafka网上有有数的介绍，我这里只做最根底的介绍.所有为了pass demo test. Apache Kafka发祥于LinkedIn，Apache Kafka是一个疾速、可扩大的、高吞吐、可容错的分布式公布订阅音讯零碎.Kafka具备高吞吐量、内置分区的个性，适宜在大规模音讯解决场景中应用.实质上kafka就是音讯队列的一种实现. 和rabbitmq/rocketmq实现相似的性能. 上面依据图片解释kafka根本的概念 producer: 音讯的生成者，发送给brokerconsumer: 音讯的消费者,从broker拿到音讯broker: 音讯的中间人topics:逻辑层面的音讯分类划分partition:一个topic中能够有多个划分，每个划分中音讯保障程序，不同划分不保障程序 1 kafka 下载下载门路：https://kafka.apache.org/down...下载最新的kafka. $ tar -xzf kafka_2.13-3.0.0.tgz$ cd kafka_2.13-3.0.02 kafka 简略zookeeper启动$ bin/zookeeper-server-start.sh config/zookeeper.properties3 kafka 启动$ bin/kafka-server-start.sh config/server.properties4 librdkafka装置.从https://github.com/edenhill/l... 下载下来zip包。这是kafka的c/c++接口库 5 librdkafka make这个次要是为了跑example来验证是否装置librdkafka胜利. ./configure # Or, to automatically install dependencies using the system's package manager: # ./configure --install-deps # Or, build dependencies from source: # ./configure --install-deps --source-deps-only make sudo make install

一、创立maven工程并增加jar包创立maven工程并增加以下依赖jar包的坐标到pom.xml <dependencies><!-- https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients --><dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>1.0.0</version></dependency> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>1.0.0</version> </dependency> </dependencies> <build> <plugins> <!-- java编译插件 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.2</version> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </plugin> </plugins></build>二、生产者代码1、应用生产者，生产数据 /** * 订单的生产者代码， */public class OrderProducer { public static void main(String[] args) throws InterruptedException { /* 1、连贯集群，通过配置文件的形式 * 2、发送数据-topic:order，value */ Properties props = new Properties(); props.put("bootstrap.servers", "node01:9092"); props.put("acks", "all"); props.put("retries", 0); props.put("batch.size", 16384); props.put("linger.ms", 1); props.put("buffer.memory", 33554432); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String> (props); for (int i = 0; i < 1000; i++) {// 发送数据 ,须要一个producerRecord对象,起码参数 String topic, V value kafkaProducer.send(new ProducerRecord<String, String>("order", "订单信 息！"+i)); Thread.sleep(100); } }}2、kafka当中的数据分区kafka生产者发送的音讯，都是保留在broker当中，咱们能够自定义分区规定，决定音讯发送到哪个partition外面去进行保留查看ProducerRecord这个类的源码，就能够看到kafka的各种不同分区策略kafka当中反对以下四种数据的分区形式： ...

1.SocketServerSocketServer作为Broker对外提供Socket服务的模块，次要用于接管socket连贯的申请，而后产生相应为之服务的SocketChannel对象。外部次要包含三个模块：Acceptor次要用于监听Socket连贯；Processor次要用于转发Socket的申请和响应。RequestChannel次要用于缓存Socket的申请和响应。1.1Acceptor对象次要性能（1）开启socket服务（2）注册Accept事件（3）监听此ServerChannel上的ACCEPT事件，当其产生时，将其以轮询的形式把对应的 SocketChannel转交给Processor解决线程。1.2Processor对象次要性能（1）当有新的SocketChannel对象进来的时候，注册其上的OP_READ事件以便接管客户端的申请。（2）从RequestChannel中的响应队列获取对应客户端的申请，而后产生OP_WRITE事件。（3）监听selector上的事件。如果是读事件，阐明有新的request到来，须要转移给 RequestChannel的申请队列；如果是写事件，阐明之前的request曾经处理完毕，须要从 RequestChannel的响应队列获取响应并发送回客户端；如果是敞开事件，阐明客户端曾经敞开了 该Socket连贯，此时服务端也应该开释相干资源。1.3RequestChannel实质上就是为理解耦SocketServer和KafkaApis两个模块，外部蕴含Request的阻塞队列和Response的阻塞队列。注：SocketServer为了避免闲暇连贯大量存在，采纳了LRU算法，即最近起码应用算法，会将长时间没有交互的SocketChannel对象敞开，及时开释资源。因而Processor仅仅是起到了接管Request，发送Response的作用，其解决Request的具体业务逻辑是由KafkaApis层负责的，并且两者之间是通过RequestChannel互相分割起来的。总结可得，SocketServer负责上面三个方面：（1）建设Socket，放弃和客户端的通信；（2）转发客户端的Request；（3）返回Response给客户端。最初通过RequestChannel与其余模块解耦。2.KafkaRequestHandlerPoolKafkaRequestHandlerPool实质上就是一个线程池，外面蕴含了num.io.threads 个IO解决线程，默认 为8个。KafkaRequestHandlerPool在外部启动了若干个KafkaRequestHandler解决线程，并将RequestChannel对象和KafkaApis对象传递给了KafkaRequestHandler解决线程，因为KafkaRequestHandler须要从前者的requestQueue中取出Request，并且利用后者来实现具体的业务逻辑。3.KafkaApisKafkaApis负责具体的业务逻辑，它次要和Producer、Consumer、Broker Server交互。 KafkaApis次要依赖以下四个组件来实现具体的业务逻辑：LogManager提供针对Kafka的topic日志的读取和写入性能。ReplicaManager提供针对topic分区正本数据的同步性能。OffsetManager提供针对提交至Kafka偏移量的治理性能。KafkaSchedule为其余模块提供定时的调度和治理性能。3.1LogManagerLogManager负责提供Broker Server上topic的分区数据读取和写入性能，负责读取和写入位于Broker Server上的所有分区正本数据；如果Partition有多个Replica，则每个Broker Server不会存在雷同Partition的Replica；如果存在的话，一旦遇到Broker Server下线，则会立即失落Partition的多份正本，失去 了肯定的可靠性。Topic、Partition和Replica三者之间的关联关系：3.2ReplicaManagerReplicaManager负责提供针对topic的分区正本数据的同步性能，须要针对不同的变动做出及时响应，例如Partition的Replicas发送Leader切换时，Partition的Replicas所在的Broker Server离线的时候，Partition的Replicas产生Follower同步Leader数据异样的时候，等等。分区两个名词：AR和ISRAR是Assign Replicas的缩写，代表曾经调配给Partition的正本。ISR是In-Sync Replicas的缩写，代表处于同步状态的正本。并不是所有的AR都是ISR，尤其是当Broker Server离线的时候会导致对应TopicAndPartition的Replica没有及时同步Leader状态的Replica，从而该Replica不是ISR。a.ReplicaManager是如何实现Replica数据的同步？次要利用ReplicaFetcherThread（正本数据拉取线程）和Height Watermark Mechanism（高水位线机制）来实现数据的同步治理。b.什么是高水位？实质上代表的是ISR中的所有replicas的last commited message的最小起始偏移量，即在这偏移之前的数据都被ISR所有的replicas所接管，然而在这偏移之后的数据被ISR中的局部replicas所接管。其中RecoverPoint代表的是recover-point-offset-checkpoint文件中记录的偏移量，LogEndOffset代表的是以后TopicAndPartition的replica所接管到音讯的最大偏移量，HeightWatermark代表的是曾经同步给所有ISR的最小偏移量。Replica的HeightWatermark产生更新在以下两种状况：（1）Leader状态的Replica接管到其余Follower状态的Replica的FetchRequest申请时，会选择性得更新HeightWatermark。（2）Follower状态的Replica接管到来自Leader状态的Replica的FetchResponse时，会选择性更新HeightWatermark，即ReplicaFetcherThread外部的processPartitionData流程。4.OffsetManager4.1Kafka提供两种保留Consumer偏移量的办法：（1）将偏移量保留到Zookeeper中。（2）将偏移量保留至Kafka外部一个名为_consumer_offsets的Topic外面。将偏移量保留至Zookeeper中是kafka始终就反对的，然而思考到zookeeper并不太适宜大批量的频繁写入操作，大数据培训因而kafka开始反对将Consumer的偏移量保留再Kafka外部的topic中，即_consumer_offsets Topic。当用户配置offsets.storage=kafka时，高级消费者会将偏移量保留至Topic外面，同时通过OffsetManager提供对这些偏移量的治理。4.2 OffsetManager次要性能缓存最新的偏移量。提供对偏移量的查问。Compact，保留最新的偏移量，以此来管制Topic日志的大小。Kafka如何将Consumer Group 产生的偏移量信息保留在_consumer_offsets的不同分区？实质是通过计算不同Consumer Group的hash值和_consumer_offsets的分区数的模数，其后果作为指定分区的索引。5.KafkaSchedulerKafkaScheduler为其余模块提供定时工作的调度和治理，例如LogManager外部的cleanupLogs定时工作，flushDirtyLogs定时工作和checkpointRecoverPointOffsets定时工作；ReplicaManager模块外部的maybeShrinkIsr定时工作；OffsetManager外部的offsets-cache-compactor定时工作等等。KafkaScheduler外部是基于ScheduledThreadPoolExecutor实现的，对外封装了任务调度的接口schedule，线程个数由参数background.threads决定，默认值为10。6.KafkaHealthcheckKafkaHealthcheck次要提供Broker Server衰弱状态的上报。Broker Server衰弱状态实质上就是指Broker Server是否在线，如果Broker Server在线，阐明处于衰弱状态，如果Broker Server离线，阐明处于死亡状态。Broker Server如何上报衰弱状态？BrokerChangeListener通过监听目录为/brokers/ids的zookeeper门路，当产生有数据变动时，则获取当前目录下的数据，从而获取以后集群的在线Broker Server列表。而KafkaHealthcheck正是提供了在目录为/brokers/ids的Zookeeper门路上注册节点的能力，该节点所在门路为EphemeralPath（非永恒门路）,当Broker Server因为异常情况导致下线时，此EphemeralPath随着Broker Server和zookeeper链接的断开而隐没。7.TopicConfigManagerkafka提供对topic配置参数的在线批改能力，批改实现之后无需重新启动kafka集群，在线失效。Topic配置参数包含：数据文件的大小，索引文件的大小，索引项的大小，索引项的粒度，日志文件保留的策略等等；Topic的配置参数位于门路为/config/topics/[topic]的zookeeper上，Broker Server外部为了防止针对每个Topic都在相干门路上建设监听器，对外提供了一个被告诉的门路，其位于/brokers/config_changes，如果检测到该门路 上发生变化，则读取该门路上的数据，获取配置文件待更新的Topic，而后再从/config/topics/[topic]上加载最新的配置文件。

简介：阿里云 EMR OLAP 与 Flink 团队深度单干，反对了 Flink 到 ClickHouse 的 Exactly-Once写入来保障整个实时数仓数据的准确性。本文介绍了基于 EMR OLAP 的开源实时数仓解决方案。 作者简介 阿里云 EMR-OLAP 团队；次要负责开源大数据 OLAP 引擎的研发，例如 ClickHouse，Starrocks，Trino 等。通过 EMR 产品向阿里云用户提供一站式的大数据 OLAP 解决方案。 内容框架 背景机制梳理技术计划测试后果将来布局一、背景Flink 和 ClickHouse 别离是实时流式计算和 OLAP 畛域的翘楚，很多互联网、广告、游戏等客户都将两者联结应用于构建用户画像、实时 BI 报表、利用监控指标查问、监控等业务，造成了实时数仓解决方案（如图-1）。这些业务对数据的准确性要求都非常严格，所以实时数仓整个链路须要保障端到端的 Exactly-Once。 通常来说 Flink 的上游是能够反复读取或者生产的 pull-based 长久化存储（例如Kafka），要实现 Source 端的 Exactly-Once 只须要回溯 Source 端的读取进度即可。Sink 端的 Exactly-Once 则比较复杂，因为 Sink 是 push-based 的，须要依赖指标输入零碎的事务保障，但社区 ClickHouse 对事务并不反对。 所以针对此状况，阿里云 EMR ClickHouse 与 Flink 团队一起深度研发，反对了 Flink 到 ClickHouse 的 Exactly-Once写入来保障整个实时数仓数据的准确性。本文将别离介绍下现有机制以及实现计划。 图-1 实时数仓架构 ...

一、前言明天这一篇咱们来说一下 Consumer 是如何退出 Consumer Group 的，咱们后面有一篇 Kafka 的架构文章有说到，Consumer 有生产组（Consumer Group）的概念，而 Producer 没有生产组的概念。所以说 Consumer 侧会比 Producer 侧简单点，除了消费者有生产组的概念，还须要保护治理 offset 偏移量、反复生产等问题。 与生产组相干的两个组件，一个是消费者客户端的 ConsumerCoordinator，一个是 Kafka Broker 服务端的 GroupCoordinator。ConsumerCoordinator 负责与 GroupCoordinator 通信，Broker 启动的时候，都会启动一个 GroupCoordinator 实例，而一个集群中，会有多个 Broker，那么如何确定一个新的 Consumer 退出 Consumer Group 后，到底和哪个 Broker 上的 GroupCoordinator 进行交互呢？ 别急，聪慧的程序员必定是有方法的，咱们还是先来说一下 GroupCoordinator 吧。 二、GroupCoordinator别问，问就是有相应的算法和策略。那咱们就来看下是啥算法和策略实现 Consumer 正确找到 GroupCoordinator 的，这就和 Kafka 外部的 Topic __consumer_offsets 有关系了。 2.1 __consumer_offsets__consumer_offsets 这个外部 Topic，专门用来存储 Consumer Group 生产的状况，默认状况下有 50 个 partition，每个 partition 默认三个正本。如下图所示： 2.2 Consumer 如何找到 GroupCoordinator 的？每个 Consumer Group 都有其对应的 GroupCoordinator，当一个新的 Consumer 要寻找和它交互的 GroupCoordinator 时，须要先对它的 GroupId 进行 hash，而后取模 __consumer_offsets 的 partition 数量，最初失去的值就是对应 partition，那么这个 partition 的 leader 所在的 broker 即为这个 Consumer Group 要交互的 GroupCoordinator 所在的节点。获取 partition 公式如下： ...