Kafka 技术内幕笔记

已于 2024-05-20 15:02:12 修改
阅读量761 收藏 8
点赞数 14
CC 4.0 BY-SA版权
分类专栏： 存储系统 文章标签： kafka
于 2024-04-13 21:17:30 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_42270334/article/details/137718785

Kafka 技术内幕笔记

kafka 是什么：

	Event streaming is the digital equivalent of the human body's central nervous system.
 	It is the technological foundation for the 'always-on' world where businesses are 
 increasingly software-defined and automated, and where the user of software is more 
 software.
	Technically speaking, event streaming is the practice of capturing data in real-time from event sources like databases, sensors, mobile devices, cloud services, and 
software applications in the form of streams of events;
	 storing these event streams durably for later retrieval; 
	 manipulating, processing, and reacting to the event streams in real-time as 
 well as retrospectively; 
	 and routing the event streams to different destination technologies as needed. 
	 Event streaming thus ensures a continuous flow and interpretation of data so 
 that the right information is at the right place, at the right time.
 
	Kafka 作为一个 event streaming 的平台来进行设计的。

kafka 架构
引用自https://blog.youkuaiyun.com/m0_57015193/article/details/119383861
功能的使用上是基于消费订阅模式设计的，在配置变更的维护上采用监听者模式实现的，其中ZK作为监听者模式的 context 存在的。

角色概览

Event

An event records the fact that “something happened” in the world or in your business. It is also called record or message in the documentation.
信息载体

Topic

Very simplified, a topic is similar to a folder in a filesystem, and the events are the files in that folder.
具有相同特质的 event 的集合。

分片机制：
Topics are partitioned, meaning a topic is spread over a number of “buckets” located on different Kafka brokers. This distributed placement of your data is very important for scalability because it allows client applications to both read and write the data from/to many brokers at the same time.

Producer

The producer sends data directly to the broker that is the leader for the partition without any intervening routing tier.
a. 支持同步和异步的发送
b. 异步发送时进行累积，可以配置超时或者超过某数量后发送

配置详解：https://kafka.apache.org/documentation/#producerconfigs

Consumer

Kafka consumer works by issuing “fetch” requests to the brokers leading the partitions it wants to consume. The consumer specifies its offset in the log with each request and receives back a chunk of log beginning from that position.

消费者设计中可以采取拉取或者推送的方式，两种导致的流量压力承担角色不同。并且对数据消费的主导权也会不同。
data is pushed to the broker from the producer and pulled from the broker by the consumer.

消费位置保存：消费者和生产者需要产生共识，kafka 通过 partition 和 偏移量机制解决。
Our topic is divided into a set of totally ordered partitions, each of which is consumed by exactly one consumer within each subscribing consumer group at any given time. This means that the position of a consumer in each partition is just a single integer, the offset of the next message to consume. This makes the state about what has been consumed very small, just one number for each partition. This state can be periodically checkpointed. This makes the equivalent of message acknowledgements very cheap.

消费者组：相当于多个消费者消费同一个topic，根据具体的负载策略来分配每个消费者对应的 partition。

Broker

消息代理。进行 partion 的维护、消息的持久化、和一些元数据的维护。
Broker 之间会通过在 ZK 竞争创建 controllor 来选举出来一个 controllor 节点，该节点负责系统级别的配置（topic 创建、分区状态管理、监听器注册等）

Controllor

  1. 选举产生controllor。// 注意区分leader 和 replicate 的区别；
    在这里插入图片描述

Cordinator

cordinator 是具体负责管理消费者组状态、元数据、负载逻辑和处理并发冲突的单元。

Replication

为了提高可用性，采用主备的思想来解决。
Kafka replicates the log for each topic’s partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a server in the cluster fails so messages remain available in the presence of failures.

失败选举机制：采用的 PacificA 协议。
The most similar academic publication we are aware of to Kafka’s actual implementation is PacificA from Microsoft.

ISR集合：具有选举权和投票权的集合，即同步完整的集合。
in-sync replicas (ISR) that are caught-up to the leader.A write to a Kafka partition is not considered committed until all in-sync replicas have received the write.

ISR集合为空的问题：

  1. Wait for a replica in the ISR to come back to life and choose this replica as the leader (hopefully it still has all its data).
  2. Choose the first replica (not necessarily in the ISR) that comes back to life as the leader.可能导致数据一致性被破坏

消费者

  • 消费者仅允许通副本的 leader 建立连接关机。
  • 服务端保证高水位 HW 之前的消息全部提交，但是之后的消息不保证，所以拉取偏移量的时候不会超过 HW
  • 注意压缩问题，可能会返回一批消息，所以需要过滤掉比需要的消息偏移量小的数据。
  • 消费者线程分为拉取线程和消费线程，二者通过队列建立联系。
  • 一个消费者可以对应多个 topic，但是每个topic下只对应一个 partition。
  • 一个消费者触发再平衡时，会导致消费者组都进行再平衡的操作。

加入消费者组

消费者的加入主要由协调者负责
这个过程中，协调者就是相关系统配置数据的proxy。

  1. 消费者发送加入请求
  2. 协调者收集全部消费者信息
  3. 协调者整理分区信息，交给主消费者进行分区的分配（为了减少协调者的负担）
  4. 主消费者分配完成后，将数据传回给协调者进行扩散。

加入消费者组：
./bin/kafka-console-consumer.sh --bootstrap-server <kafka服务器地址:端口> --topic <主题名> --group <组名>

生产者

  • 通过缓存队列、发送线程组织数据、客户端对象真正发送（超过大小、超过时间）。
  • 提供同步和异步的发送，异步发送需要注册自己的回调函数。
  • 未指定消息的分区 key，则通过轮询分发。
  • 消费者可以同时并行的将消息发送给多个 partition （topic 可以被分解为多个 partition，每个partition 同样存在自己的副本，副本需要和主副本在不同节点上）

指定分区

发送消息时可以指定对应的 partition

package kafka

import (
	"context"
	"fmt"

	"github.com/segmentio/kafka-go"
)

func TestKafka() {
	// 创建一个Writer，指定topic和分区
	w := kafka.NewWriter(kafka.WriterConfig{
		Brokers: []string{"localhost:9092"},
		Topic:   "my-topic",
	})
	defer w.Close()

	// 发送消息到指定分区
	err := w.WriteMessages(context.Background(),
		kafka.Message{
			Key:       []byte("key"),
			Value:     []byte("value"),
			Partition: 0, // 指定分区为0
		},
	)
	if err != nil {
		panic(err)
	}
	fmt.Println("消息发送成功")

	// 创建一个Reader，指定topic、分区和offset
	r := kafka.NewReader(kafka.ReaderConfig{
		Brokers:   []string{"localhost:9092"},
		Topic:     "my-topic",
		Partition: 0,    // 指定分区为0
		MinBytes:  10e3, // 10KB
		MaxBytes:  10e6, // 10MB
	})
	defer r.Close()

	// 从指定分区读取消息
	m, err := r.ReadMessage(context.Background())
	if err != nil {
		panic(err)
	}
	fmt.Printf("消息分区:%d 偏移量:%d 值:%s\n", m.Partition, m.Offset, string(m.Value))
}

控制器

控制器负责管理分区的选举、分区状态机、分区副本状态机、多种类型的监听机制。

控制器初始化

onControllerFailover 方法

  1. 注册管理性质的监听器
  2. 分区状态机中注册更改主题的监听器
  3. 注册更改代理节点的监听器
  4. 初始化控制器的上下文，包括读取监听器的相关 ZK 节点
  5. 启动副本状态机和分区状态机，在分区状态机中为每个主题注册更改分区的监听器
  6. 执行步骤 1 中注册的分区重新分配、最优副本选举
  7. 将分区的主副本信息、ISR信息发送给所有的存活的 broker
  8. 如果开启了主副本自动平衡机制，启动一个定时检查分区平衡的线程（尽量让第一个副本作为主副本存在）
  9. 启动删除主题的管理器线程，异步的

控制器选举算法

控制器选举采用“抢先”的算法，通过向 ZK 注册临时controllor节点来竞争。 临时节点在关联的机器宕机或者失联的时候会自动删掉。会触发新的选举竞争。

实现原理主要是利用的 ZK 的 watcher 和 控制器来实现的。

  1. 控制器向 ZK 注册监听器，每个监听器都绑定了对应的事件处理逻辑
  2. ZK 节点数据更新，产生变动，触发监听器
  3. 控制器执行具体的事件处理逻辑，处理完成后重新注册监听器

注册监听器

核心监听器

  1. 主题改变监听器 ： brokers/topics/[topic_name] 下，监听增加和删除操作，添加子节点时触发 onNewTopicCreation 方法
  2. 分区改变监听器： brokers/topics/[topic]，监听数据变化事件。比如分区增加事件，触发 onNewPartitionCreattion 方法
  3. 代理节点改变监听器：brokers/ids/ ，监听代理节点上下线事件，比如代理节点上线，触发 onBrokerStart 方法。

分区初始化与 topic 创建流程

分区：分区在kafka 中代表最小的存储单元，即一个挂载点，挂载点可能是一个磁盘也可能是一个磁盘阵列，通常是磁盘阵列。分区具有自己的副本，分区信息可以在 tmp/kakfka-logs 下查找。

分区状态转换

分区副本状态机和分区状态机共用四个状态：新建、在线（Online）、下限、不存在

  1. 副本不存在到新建：新建主题或者重新分配分区的时候会导致副本从不存在到新建的状态。
  2. 分区不存在到新建：分区创建，存在AR，但是没有主副本的时候，会让分区从不存在到新建状态。

新建 topic

创建topic 的时候，会触发 onNewTopicCreation 方法。

创建主题的主要流程如下：

  1. 创建主题，在 /brokers/topics/ 创建子节点，触发分区监听器；
  2. 更改主题监听器 调用 onNewTopicCreation 方法，注册 “更改分区监听器”，并对所有分区调用 onNewPartitionCreation 方法。
  3. 触发所有分区、副本状态转换机，转换为“上线”状态；
  4. 分区从新建状态转到上线状态，控制器将选举出的主副本、创建分区状态的ZK节点、LeaderAndIsr请求同步给副本

新建状态到上线状态的主副本选取直接从AR中第一个存活

分区选举流程

新建状态到上线状态：

下线、上线状态到上线状态：
需要从 ISR 中选取第一个存活的副本，如果ISR没有，则从AR集合中选取第一个存活的副本。通过 ZK 来扩散最新的主副本信息和ISR信息。

最优副本机制：
主副本是IO的入口，最优副本机制优化的是防止分区的第一个副本（kakfa 的负载均衡策略会尽量将副本的第一个节点分散在不同的broker 上）不是主副本导致的过多的主副本集中在同一个 broker 上导致的负载不均衡问题。定时线程会调用 selectLeader，如果发现最优副本存活但是不是主副本，会调整主副本。

主副本的变化势必导致部分时间的消息不可用。

偏移量管理

参考：https://blog.youkuaiyun.com/wzxue1984/article/details/131966439

提交管理

  1. 手动管理
    手动提交偏移量：消费者可以通过调用commitSync或commitAsync方法手动提交偏移量到Kafka。手动提交偏移量的方式需要开发者在适当的时机调用提交方法，确保消费者处理完消息后再提交偏移量。这种方式对于灵活性和精确控制偏移量非常有用，但需要开发者自行考虑提交的时机和异常处理。

  2. 自动管理
    自动提交偏移量：消费者可以配置为在后台自动提交偏移量。这意味着消费者会定期自动提交已经处理的消息的偏移量给Kafka，而不需要开发者手动处理。通过配置参数enable.auto.commit为true，以及设置auto.commit.interval.ms参数来控制自动提交的频率。自动提交偏移量简化了管理，但可能会导致消息的重复处理或丢失，因此需要根据具体业务场景谨慎配置。

  3. 协调器管理
    管理在 __consumer_offsets topic 上。
    组管理协调器（Group Coordinator）：Kafka提供了消费者组的概念，多个消费者可以组成一个消费者组来协同消费消息。消费者组中的消费者会协调管理分区的分配和偏移量的提交。消费者组的协调器负责跟踪每个分区的偏移量，并协调进行偏移量的提交。每个消费者在消费消息时，会根据协调器返回的偏移量进行消费。这种方式对于横向扩展和高可用性非常有用，但需要注意消费者组的动态变化和再均衡操作。

2. 偏移量的生产

producer 产生新的消息的时候，会将消息直接发送给对应的 partition。 这里产生一个新的偏移量。
consumer 消费的时候，如果是初始化，会从 ZK/主题 中拉取消费者组的偏移量信息，当消费成功后，将消费成功的偏移量存储到 ZK/主题。

存储到主题的流程：

  1. 消费成功，周期时间到，向协调者发送更新请求。
  2. 协调者持久化数据到对应的 topic 日志中。
  3. 协调者缓存消费着组的偏移量信息，方便再平衡的时候重新发放。

消费者组的偏移量存放在 consumer_topic 的好处：
4. 方便做负载，
5. 方便在 再平衡等分区分配发生变化的时候快速获取消费者组的偏移量。
6. 可以减少对 ZK 的依赖，复用kakfa 的集群功能。

偏移量获取

参考：https://zhmin.github.io/posts/kafka-consumer-offset/

在自动的提交过程中，会检查本地和 cordinator 获取本消费组消费位置。

初始化策略

auto.offset.reset ： 当未找到消费偏移量（本地不存在、初始化时未指定）的策略。

LATEST 策略 ： 选择此时分区的末尾位置（最新一条）。因为有可能会有新的数据添加进来，这样末尾位置就会改变，所以只选择此时的位置。
EARLIEST 策略：选择此时目前分区的开始位置（最旧一条）。因为有可能会有旧的数据被删除，这样开始位置就会改变，所以只选择此时的位置。
NONE 策略：如果没有找到当前消费组的消费偏移量，抛出异常

常见配置

消息过期

kafka消息过期时间设置（全局和特定topic）_kafka过期时间-优快云博客

全局设置

  • log.retention.hours=168 (配置该参数即可) // 默认过期时间
  • log.cleanup.policy=delete （默认，可不配置）// 过期后的清除策略

对所有topic全部生效，缺点是需要重启kafka服务

单独的 topic 设置

mytopic 为目标 topic
./kafka-configs.sh --zookeeper localhost:2181 --alter --entity-name mytopic --entity-type topics --add-configretention.ms=86400000

参考：https://blog.youkuaiyun.com/u012809308/article/details/110006925

producer 配置

producer 可以使用 api 进行同步/异步 的发送过程。
sarama 中的异步和同步发送举例：https://www.lixueduan.com/posts/kafka/05-quick-start/

常见问题

消息可靠性

首先分析kafka 的数据流走向，讨论每个阶段可能产生的问题和对应处理单元和路径上是怎么处理的。

producer ：
kafka自己采用的 tcp；
消息确认机制；
配置重试机制；
增加合适的错误持久化和报警功能；
broker ：
通过主备的集群的方式保证数据可用性，避免单店故障导致数据丢失；
通过 offset 的一致性的保证不会跳过消费阶段；
consumer ：
通过 offset 机制来记录消费状态；
配置手动或者自动的提交。
手动提交可以实现业务语意上的“不丢失”，单要通过业务上自定义处理逻辑来保证不产生错误的消费。

消息的重复消费问题

消息语意：至少一次、至多一次、仅一次

在提交成功之前，可能发生崩溃，导致消费者重新上线后重复消费消息。

  1. 提供幂等机制；
  2. 增加偏移量的提交频率。
  3. 可以本地管理，将业务最终逻辑和偏移量的保存放在一个原子操作中

可用性保障

主要就是通过ISR集合机制和投票共识协议来完成的。

消息积压问题

  1. 做好压测
  2. 找到积压原因：生产过多、节点宕机、消费慢、网络原因、负载不均匀
  3. kafka 本身系统优化
  4. 增加 partition
  5. 增加消费
  6. 消费和业务处理异步
  7. key 的设置，保证负载均匀

消息发送流程

Created with Raphaël 2.3.0 生产者 1. 消息结构：record{key，value，header} 2. 消息队列：recordBach ，对应配置：batch.size（到达批次大小就发送，默认16Kb）、linger.ms（超时就发送） 可选配置：压缩算法，默认不开启 3. 消息分发：默认根据 key hash来选择分片，如果key 未设置，默认采用轮询的负载算法 4. 缓冲队列：net 的缓冲大小， 5. 发送到对应主题的 leader 所在节点 5.1 ack 机制： ack = 0 ，不进行确认，ack = 1 只确认主节点，ack = -1 需要leader和ISR同步完成。 消息代理 1. 从 net 的buffer 中获取数据 2. 消息进入request queue 进行排队 3. 工作线程获取数据， ---提交到 page cache（可以理解为交换区，写入磁盘前的缓存） ---通知副本持久化数据 4. 数据持久化（kafka 是顺序存储的，采用异步的刷盘机制） --- log.flush.interval.mesaages 达到多少条后持久化 --- log.flush.interval.ms 每隔多少秒持久化一次 --- log.flush.schedule.interval.ms 周期刷盘 6. 副本同步成功（ISR集合），返回确认信息 --- ISR 大小配置： ------ default.replication.factor=3 // 副本数量 ------ min.insync.replicas=2 // 允许的未同步的副本数量 7. 返回消息放入响应队列

从消息的发送流程来看，我们可以干预和优化的地方分为以下：
producer ：

  1. 消息的压缩
  2. 消息的 batchSize
  3. 发送端 net 缓存

broker 内部：

  1. ISR 集合大小
  2. partition 大小
  3. 缓存队列大小：queue.max.request,最大个数；queue.max.request.bytes, bytes 大小；到达最大容量后新的请求到达后会阻塞。个数的经验值为活跃的客户端数量，或者根据客户端的经验速率进行加权。
  4. 接收 net 缓存大小 ：
    6.1 socket.receive.buffer.bytes , 设置为 -1 会使用系统的，经验设置要参考 rtt，比如往返 100ms，网络带宽 10M/S ，那么可以计算出 缓冲大小应该 bufferSize * 1s/100ms > 10Mb/s ==> bufferSize > 1Mb
  5. 对应要增加线程的本地缓存大小：socket.request.max.bytes 默认已经足够大，一般无需修改
  6. 网络 IO 线程：network.threads 线程数大小，如果启用了 SSL 的时候，线程数过多会导致 cpu 使用增加，不启用的时候可以更好的使用到 零拷贝 机制。
  7. 刷盘线程数 ： num.io.threads,默认为8，写磁盘用到的线程数
  8. pageCache 持久化策略：
    10.1 log.flush.interval.ms，null , 每隔多少进行刷盘；
    10.2 log.flush.interval.messages,long.max,达到多少条触发刷盘。
  9. 调整副本：
    12.1 num.replica.fetchers,1,副本拉取线程数，这个参数占总核数的50%的1/3；
    12.2 replica.fetch.min.bytes,复制过程中最少要完成的同步数据大小，不足会阻塞；
    12.3 replica.fetch.wait.max.ms,复制时候的超时事件

网络协议：
如果启用了 SSL 协议，那么加密流程会使用到CPU 计算，从而无法利用到 mmp，生产者开启多线程的时候会加重 CPU 的使用。

常用配置

官方配置文档列表

producer

  • ack ： ack = 0 ，不进行确认，ack = 1 只确认主节点，ack = -1 需要leader和ISR同步完成。
  • batch.size ：一批请求的大小，default 16384B （16KB）

broker

https://kafka.apache.org/documentation/#brokerconfigs

  • 缓存

    • socket.receive.buffer.bytes , 设置为 -1 会使用系统的，经验设置要参考 rtt，比如往返 100ms，网络带宽 10M/S ，那么可以计算出 缓冲大小应该 bufferSize * 1s/100ms > 10Mb/s ==> bufferSize > 1Mb
    • 缓存队列大小：queue.max.request,最大个数；queue.max.request.bytes, bytes 大小；

  • 线程

    • 网络 IO 线程：network.threads 线程数大小
    • 刷盘线程数 ： num.io.threads,默认为8

  • 持久化

    • log.flush.interval.ms，null , 每隔多少进行刷盘；
    • log.flush.interval.messages,long.max,达到多少条触发刷盘。

  • 集群相关

    • 副本数量：num.partitions

    • ISR集合大小：transaction.state.log.min.isr

    • 副本

      • num.replica.fetchers,1,副本拉取线程数，这个参数占总核数的50%的1/3；
      • replica.fetch.min.bytes,复制过程中最少要完成的同步数据大小，不足会阻塞；
      • replica.fetch.wait.max.ms,复制时候的超时事件

compose 文件标签:https://blog.youkuaiyun.com/lihongbao80/article/details/102679569

常见应用

使用 docker 搭建集群

version: "3"
 
networks:
  zk-net:
    external:
      name: zk-net
 
services:
  kafka01:
    image: 'bitnami/kafka:2.7.0'
    restart: always    
    container_name: kafka01
    hostname: kafka01
    ports:
      - '9092:9092'
    environment:
      - KAFKA_BROKER_ID=1
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://127.22.157.170:9092
      - KAFKA_CFG_ZOOKEEPER_CONNECT=127.22.157.170:2181
      - ALLOW_PLAINTEXT_LISTENER=yes
    volumes:
      - /E/soft/docker/kafka/kafka1:/bitnami/kafka     
    networks:
      - zk-net
  kafka02:
    image: 'bitnami/kafka:2.7.0'
    restart: always       
    container_name: kafka02
    hostname: kafka02
    ports:
      - '9093:9093'
    environment:
      - KAFKA_BROKER_ID=2
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9093
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://127.22.157.170:9093
      - KAFKA_CFG_ZOOKEEPER_CONNECT=127.22.157.170:2181
      - ALLOW_PLAINTEXT_LISTENER=yes
    volumes:
      - /E/soft/docker/kafka/kafka2:/bitnami/kafka       
    networks:
      - zk-net
  kafka03:
    image: 'bitnami/kafka:2.7.0'
    restart: always       
    container_name: kafka03
    hostname: kafka03
    ports:
      - '9094:9094'
    environment:
      - KAFKA_BROKER_ID=3
      - KAFKA_CFG_LISTENERS=PLAINTEXT://:9094    
      - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://127.22.157.170:9094
      - KAFKA_CFG_ZOOKEEPER_CONNECT=127.22.157.170:2181
      - ALLOW_PLAINTEXT_LISTENER=yes
    volumes:
      - /E/soft/docker/kafka/kafka3:/bitnami/kafka   
 
    networks:
      - zk-net

docker-compose -f \Users\december\Desktop\kafka-cluster.yml up -d

延迟队列

采用多级队列，对不同延迟的请求发送到不同的队列中，比如 20 min，60min。
粒度较粗，需要设计单独的消费者定时或者周期的扫描客户端并管理自己的调度周期。

日志聚合和异步提交

Many people use Kafka as a replacement for a log aggregation solution.
Log aggregation typically collects physical log files off servers and puts them in a central place (a file server or HDFS perhaps) for processing.
Kafka abstracts away the details of files and gives a cleaner abstraction of log or event data as a stream of messages. This allows for lower-latency processing and easier support for multiple data sources and distributed data consumption. In comparison to log-centric systems like Scribe or Flume, Kafka offers equally good performance, stronger durability guarantees due to replication, and much lower end-to-end latency.

腾讯面试经历：程序职业生涯学习成长的宝贵财富
AI天才研究院
06-05 691
本文聚焦"腾讯面试经历"这一具体场景，通过复盘作者从简历投递到终面通过的完整过程，提炼出技术能力、思维方式、职业认知三个维度的成长启示。内容覆盖面试前的准备策略、面试中的典型问题解析、面试后的反思沉淀，以及这些经验如何反哺日常工作与长期职业发展。本文将按照"故事引入→核心能力拆解→实战案例分析→成长启示总结"的逻辑展开。通过真实的面试场景（如算法题、系统设计题、项目深挖），讲解腾讯面试考察的底层能力模型；结合具体代码与设计方案，展示"如何将日常学习转化为面试竞争力"；最后提炼出可复用的职业成长方法论。
Java开发技术总结！java博客项目用到什么
m0_56662269的博客
05-25 380
前言 京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。 我们把订单数据存储在MySQL中，但显然只通过DB来支撑大量的查询是不可取的。同时对于一些复杂的查询，MySQL支持得不够友好，所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。 Elasticsearch作为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用，目前订单中心ES集群存储数据量达到10
Kafka技术内幕
weixin_33711647的博客
07-28 885
第一部分:初步了解Kafka Apache Kafka是一个分布式流媒体平台。这到底是什么意思？ 流媒体平台具有三个关键功能： 发布和订阅记录流，类似于消息队列或企业消息系统。 以容错的持久方式存储记录流。 记录发生时的处理流。 卡夫卡通常用于两类广泛的应用： 1.建立实时流数据管道，在系统...
kafka源码_10小时，这回一次搞定 Kafka 源码！
weixin_39638526的博客
12-03 193
Kafka因其优越的特性广泛用于日志收集、用户活动跟踪等方面，也得到越来越多企业的青睐，很多 IT 界前辈更是在技术层面不断深挖。目前，如果你还局限在 Kafka 的基本应用，将很难 cover 住各种 trouble shooting，就连面试都会被整懵逼：为什么要用 Apache Kafka 集群？kafka 如何不消费重复数据？Kafka Producer 如何优化打入速度？解释...
＜KAFKA技术内幕＞ 解读
weixin_60786515的博客
04-16 211
3.计算分区原消息发送到那个分区（下面细说）4.确认消息大少是否超过最大值，5.根据消息封装到分区对象，6.给每一条消息绑定回调函数（异步发送才有，同步没有）7.把消息导入到消息推送器（下面细说）8.唤醒send线程（消息发送，回调处理）处理模式有点像Reactor模式。2.没有指明 partition 值但有 key 的情况下，将 key 的 hash 值与 topic 的 partition 数进行取余得到 partition 值；1.消息发送是消息队列满就会连接服务器准备发送消息。
五年Java编程生涯，大专学历最终逆袭阿里，面试，kafka项目实战
m0_64867896的博客
12-13 493
对于程序员来说，英语是相当重要的，不可否认吧？但我竟然连 4 级都没有过——惭愧惭愧，快来羞辱我吧。那为什么两年时间，我没有进步呢？我来当个标本从里到外剖析一下。 第一，我失去了目标。上小学、上初中、上高中，目标很明确，考大学走出农村嘛。考了两年，竟然只能上个大专，无所谓了，瞎胡混呗。 第二，学校氛围不行。我的自控力很一般，是个随波逐流的家伙。大专院校嘛，自然学生的整体学习能力和本科相比，还是有差距的。没办法，只能自甘堕落。 第三，我打游戏，不学习。上课还带着笔记本打单机游戏呢，那时候最爱的就是极品飞车，现
java8源码-becoming-programming-god:成为编程之神，记录所有技术难点，梳理个人技术栈，从编程语言到分布式系统，到服
06-04
java8 源码 becoming-programming-god 成为编程之神 1. 基础知识 (basic) 1.1 数据结构(data structure) ...Mysql技术内幕 3.7 高性能mysqlss 3.8 Kafka权威指南 3.9 Http权威指南 3.10 Java8实战 3.11
工作记录笔记
逍遥飞鹤的专栏
04-16 7649
Java相关原理和深入学习：http://wiki.jikexueyuan.com/list/java/ RPC框架：         http://www.cnblogs.com/luxiaoxun/p/5272384.html https://my.oschina.net/huangyong/blog/361751 编程狂人周刊：http://www.tuicool.c
kafka技术内幕
03-06
kafka技术内幕，2017.11月最新出版，基于0.10版本，非常不错的一本书，由于是高清，本人帐号最大上传文件为220MB，所以分两次上传！
Kafka技术内幕：图文详解Kafka源码设计与实现+书签.pdf+源码
12-02
Kafka技术内幕：图文详解Kafka源码设计与实现 有书签 有源码
Kafka技术内幕：图文详解Kafka源码设计与实现 高清带书签
12-02
图文详解kafka的内部原理、设计、与实现，全面分析以kafa为中心的分布式流平台。
Kafka技术内幕：图文详解Kafka源码设计与实现 PD
03-16
Kafka技术内幕：图文详解Kafka源码设计与实现 PDF 下载 Kafka技术内幕：图文详解Kafka源码设计与实现 PDF 下载
Kafka技术内幕及源码设计与实现（第一部分）
04-13
Kafka技术内幕及源码设计与实现，这是一本很全的书，很值得学习
kafka技术内幕（一）
demon7552003的小本本
04-04 454
文章目录概念基本概念topic，partition副本生产者重要组件发送消息流程元数据的更新消费者消费者与消费组客户端订阅主题与分区消息消费位移提交控制或关闭消费指定位移消费再均衡消费者拦截器多线程实现主题和分区主题的管理KafkaAdminClient分区的管理选择合适的分区数日志存储文件目录布局日志格式日志索引偏移量索引时间戳索引日志清理日志删除基于时间基于日志大小基于日志起始偏移量日志压缩磁盘存储页缓存零拷贝附录服务端参数配置**`server.properties`**配置必配置属性参数说明Lea.
kafka 技术内幕 图文详解Kafka源码设计与实现
04-09
kafka 技术内幕 图文详解Kafka源码设计与实现 kafka 源码
Kafka技术内幕：图文详解Kafka源码设计与实现.郑奇煌(2017.11).pdf
04-10
Kafka技术内幕：图文详解Kafka源码设计与实现.郑奇煌(2017.11).pdfKafka技术内幕：图文详解Kafka源码设计与实现.郑奇煌(2017.11).pdf
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值