Kafka

1 什么是kafka Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。 2 为什么要使用 kafka，为什么要使用消息队列 缓冲和削峰： 上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。 解耦和扩展性： 项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。 冗余： 可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。 健壮性： 消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。 异步通信： 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 3.Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么 ISR:In-Sync Replicas 副本同步队列 AR:Assigned Replicas 所有副本

官网文档： http://kafka.apache.org/082/documentation.html#brokerconfigs 修改config/server.properties文件如下： 集群后还要修改broker id和主机名 启动kafka（后台进程）： $ bin/kafka-server-start.sh -daemon config/server.properties CREATE $ bin/kafka-topics.sh --create --zookeeper bigdata-hpsk01.ziboit.com:2181 --replication-factor 1 --partitions 1 --topic testTopic LIST $ bin/kafka-topics.sh --list --zookeeper bigdata-hpsk01.ziboit.com:2181/kafka SEND $ bin/kafka-console-producer.sh --broker-list bigdata-hpsk01.ziboit.com:9092 --topic testTopic $ bin/kafka-console-consumer.sh --zookeeper bigdata-hpsk01.ziboit.com:2181 --topic

Flink 在 Flink 中需要端到端精准一次处理的位置有三个： Source 端 ：数据从上一阶段进入到 Flink 时，需要保证消息精准一次消费。 Flink 内部端 ：这个我们已经了解，利用 Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。不了解的小伙伴可以看下我之前的文章： Flink可靠性的基石-checkpoint机制详细解析 Sink 端 ：将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。 在 Flink 1.4 版本之前，精准一次处理只限于 Flink 应用内，也就是所有的 Operator 完全由 Flink 状态保存并管理的才能实现精确一次处理。但 Flink 处理完数据后大多需要将结果发送到外部系统，比如 Sink 到 Kafka 中，这个过程中 Flink 并不保证精准一次处理。 在 Flink 1.4 版本正式引入了一个里程碑式的功能：两阶段提交 Sink，即 TwoPhaseCommitSinkFunction 函数。该 SinkFunction 提取并封装 了两阶段提交协议 中的公共逻辑，自此 Flink 搭配特定 Source 和 Sink（如 Kafka 0.11 版） 实现精确一次处理语义 (英文简称：EOS，即 Exactly-Once Semantics)。

1. 下载 2.解压后修改配置文件 #唯一编号 broker.id=1 #用来监听的地址 listeners=PLAINTEXT://127.0.0.1:9092 #日志路径 log.dirs=E:/kafka_2.13-2.7.0/kafka_2.13-2.7.0/tmp/kafka-logs #zk的连接 zookeeper.connect=localhost:2181 3.启动 1.先启动zk 2.启动kafka kafka-server-start.bat ..\..\config\server.properties #创建主题 kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic kafka-test-topic #查看创建的主题 kafka-topics.bat --list --zookeeper localhost:2181 #启动生产者 kafka-console-producer.bat --broker-list localhost:9092 --topic kafka-test-topic #启动消费者 kafka-console-consumer.bat --bootstrap-server localhost

package com.qianlima.solr.qy.configuration ; import org.apache.kafka.clients.consumer.ConsumerConfig ; import org.apache.kafka.common.serialization.StringDeserializer ; import org.springframework.context.annotation.Bean ; import org.springframework.context.annotation.Configuration ; import org.springframework.kafka.annotation.EnableKafka ; import org.springframework.kafka.config.ConcurrentKafkaListenerContainerFactory ; import org.springframework.kafka.config.KafkaListenerContainerFactory ; import org.springframework.kafka.core.ConsumerFactory ; import org.springframework.kafka.core

谈谈注册中心 zookeeper 和 eureka中的CP和 AP 前言 在分布式架构中往往伴随CAP的理论。因为分布式的架构，不再使用传统的单机架构，多机为了提供可靠服务所以需要冗余数据因而会存在分区容忍性Ｐ。 冗余数据的同时会在复制数据的同时伴随着可用性A 和强一致性C的问题。是选择停止可用性达到强一致性还是保留可用性选择最终一致性。通常选择后者。 其中 zookeeper 和 eureka分别是注册中心CP AP 的两种的实践。他们都提供服务注册中心的功能。建议使用AP。不强求数据的强一致性，达成数据的最终一致性。 服务注册中心的数据也就是返回的可用服务节点(ip+端口号) 服务A开了0-9十个服务节点，服务B需要调用服务A，两次查询返回0-8，1-9 不一致的数据。产生的影响就是0 和9 节点的负载不均衡 只要注册中心在 SLA 承诺的时间内（例如 1s 内）将数据收敛到一致状态（即满足最终一致），流量将很快趋于统计学意义上的一致，所以注册中心以最终一致的模型设计在生产实践中完全可以接受。 1 eureka AP eureka 保证了可用性，实现最终一致性。 Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点

Kafka Streams 1 概述 Kafka Streams是一个客户端程序库，用于处理和分析存储在Kafka中的数据，并将得到的数据写回Kafka或发送到外部系统。Kafka Stream基于一个重要的流处理概念。如正确的区分事件时间和处理时间，窗口支持，以及简单而有效的应用程序状态管理。Kafka Streams的 入口门槛很低 : 你可以快速的编写和在单台机器上运行一个小规模的概念证明（proof-of-concept）；而你只需要运行你的应用程序部署到多台机器上，以扩展高容量的生产负载。Kafka Stream利用kafka的并行模型来透明的处理相同的应用程序作负载平衡。 Kafka Stream 的亮点： 设计一个 简单的、轻量级的客户端库 ，可以很容易地嵌入在任何java应用程序与任何现有应用程序封装集成。 Apache Kafka本身作为内部消息层， 没有外部系统的依赖 ，还有，它使用kafka的分区模型水平扩展处理，并同时保证有序。 支持 本地状态容错 ，非常快速、高效的状态操作（如join和窗口的聚合）。 采用 one-recored-at-a-time（一次一个消息） 处理以实现低延迟，并支持 基于事件时间(event-time)的窗口操作 。 提供必要的流处理原语(primitive)，以及一个 高级别的Steram DSL 和 低级别的Processor

导语： 由中国信息通信研究院、中国通信标准化协会联合主办的“2020可信云大会”于昨天圆满结束，会上发布了2020年可信云上半年最新评估结果。其中腾讯云中间件—— 分布式消息队列 TDMQ 凭借其优秀的技术能力，获得了 可信云最高级认证证书 。 01 TDMQ喜获可信云最高级认证证书 在刚刚过去的“2020可信云大会”在线上大会上，腾讯云中间件——分布式消息队列TDMQ喜获可信云 最高级认证证书 ！代码编号：No.MQ-0003 TDMQ刚刚出道，便获得了可信云软件认证的最高级证书，这是对产品服务能力和腾讯云中间件技术能力的最佳认可。 02 创新定义，开启消息队列新时代 TDMQ基于开源Pulsar 存储计算分离 架构，完美支持 按量使用无限扩展 ， 专为云而生的消息队列 ，并 兼容主流消息队列产品。 03 超强服务能力 1. 高一致性 采用raft算法 。 同步刷盘 。 多副本 。 2. 高性能低延迟 高效支持 亿级消息生产和消费 。 单集群 QPS 超过10万 。 时耗方面有保护机制来保证低延迟，帮助您轻松满足业务性能需求 。 3. 百万级 To pic 计算与存储架构的分离 设计，可以轻松 支持百万级消息主题 。 多租户，完善的自助运维管理工具 。 4. 丰富的消息类型 提供丰富的消息类型，涵盖普通消息、顺序消息（全局顺序 / 分区顺序）、分布式事务消息、定时消息等。 5.

软件工程师对于最荒渺的事情非常热衷。我们倾向于认为自己是超理性的，但是当我们面临一种技术选择的时候，我们最终会陷入一种疯狂状态——从一个人的Hacker News评论跳到另一个人的博客文章，直到变得麻木，我们无助地漂浮朝着最明亮的光线倾斜，并且俯卧在它的前面，而忽略了我们最初寻找的东西。 这不是理性的人做出决定的方式，而是软件工程师决定使用MapReduce的方式。 正如Joe Hellerstein在他的本科数据库课程[1]上所说的（在54分钟）： 问题是世界上有5家公司从事如此大的工作。对于其他所有人……你正在为实际上不需要的容错能力执行所有这些I/O。人们在2000年代有点Google的狂热：“我们将像Google一样做所有事情，因为我们也运行着世界上最大的互联网数据服务” [横摆倾斜，等待笑声] 你们的数据中心大楼有几层？Google在俄克拉荷马州梅斯县的数据中心是4层。 拥有比所需更多的容错能力可能听起来不错，但考虑到成本：不仅会做更多的I/O，而且可能会从一个成熟的系统（如事务，索引和查询优化器）过渡到某种相对不成熟的系统上。真是倒退了一大步[2]。有多少Hadoop用户自觉地进行了这些折衷？有多少用户明智地进行了这些折衷？ 目前，MapReduce/Hadoop仅仅是一个简单的目标（soft target），即使开发人员已经意识到目标不是很合适。但是

与生产者对应的是消费者，应用程序可以通过 KafkaConsumer 来订阅主题，并从订阅的主题中拉取消息。不过在使用 KafkaConsumer 消费消息之前需要先了解消费者和消费组的概念，否则无法理解如何使用KafkaConsumer。 今天先讲解消费者与消费组之间的关系，后续再结合案例再细致地讲解如何使用。 消费者负责订阅 Kafka 中的主题（Topic），并且从订阅的主题上拉取消息。与其他一些消息中间件不同的是：在 Kafka 的消费理念中还有一层消费组的概念，每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。 如上图所示，某个主题中共有4个分区（Partition）：P0、P1、P2、P3。有两个消费组A和B都订阅了这个主题，消费组A中有4个消费者（C0、C1、C2和C3），消费组B中有2个消费者（C4和C5）。按照 Kafka 默认的规则，最后的分配结果是消费组A中的每一个消费者分配到1个分区，消费组B中的每一个消费者分配到2个分区，两个消费组之间互不影响。每个消费者只能消费所分配到的分区中的消息。换言之，每一个分区只能被一个消费组中的一个消费者所消费。 我们再来看一下消费组内的消费者个数变化时所对应的分区分配的演变。假设目前某消费组内只有一个消费者C0，订阅了一个主题，这个主题包含7个分区：P0、P1、P2、P3、P4