一、Kafka是什么 一句话:Kafka是一个 分布式的、基于日志(log)的消息系统 。它的核心思想很简单——把消息像写日志一样"追加"到磁盘文件里,消费者按顺序"读"这个文件,仅此而已。这个简单模型是它高吞吐的根本原因。 二、核心架构组件 在讲数据流之前,先认识几个名词: Producer(生产者) :发消息的一方,比如你的业务代码 Broker :Kafka的服务器节点,多个Broker组成一个 Cluster(集群) Topic(主题) :消息的分类,比如"订单创建"topic Partition(分区) :每个Topic会被切成多个分区,分区是Kafka 并行处理和存储的最小单位 Replica(副本) :每个分区有多个副本分布在不同Broker上,其中一个是 Leader (负责读写),其余是 Follower (只同步数据,不对外服务) Consumer(消费者) / Consumer Group(消费组) :消费消息的一方,同一个组内的消费者共同"瓜分"一个Topic的所有分区 Controller :集群里选出的一个特殊Broker,负责管理分区Leader选举等元数据工作(以前靠ZooKeeper协调,新版本Kafka用内置的KRaft协议取代了ZooKeeper)## 三、数据从Producer到Broker再到Consumer的完整过程 Producer发送消息 :业务代码调用 send() ,消息先进入客户端本地的一个内存缓冲区( RecordAccumulator ),并不是发一条就立刻走网络 选择分区 :如果你指定了key,Kafka默认对key做hash来决定发到哪个分区(保证同key的消息永远进同一个分区,从而保证顺序);没指定key则轮询或用粘性分区策略 批量发送 :客户端把同一分区的多条消息打包成一个batch,达到大小或时间阈值后一起发给对应分区的 Leader Broker (这是Kafka高吞吐的关键之一——减少网络往返) Leader写入日志 :Leader收到消息后,以 顺序追加 的方式写入本地磁盘的log文件,并分配一个递增的 offset 副本同步 :Follower副本主动从Leader拉取新消息...
MySQL 架构、数据管理与数据流动学习文档 面向对象：已经会写 SELECT / INSERT 等基本语句，但想真正理解"一条 SQL 语句进去之后，MySQL 内部到底发生了什么"的开发者。 阅读方式建议：不必从头背诵，遇到工作中的实际问题（比如"为什么这条查询这么慢""为什么加了索引还是全表扫描"）时，回来对照相应章节。 目录 MySQL 整体架构总览 一条 SQL 语句的完整生命周期 INSERT / SELECT 基础回顾（从语法到底层） InnoDB 存储引擎深度剖析 索引原理（B+树、聚簇索引、联合索引） 复杂查询案例解析（GROUP BY / JOIN / HAVING / LIMIT / ORDER BY） 数据流动全景图（总结） 诊断与优化工具 延伸学习路线 第一章：MySQL 整体架构总览 MySQL 的架构可以分为两大块： Server 层 （所有存储引擎共用）和 存储引擎层 （可插拔，最常用的是 InnoDB）。 ┌─────────────────────────┐ │ 客户端 / 应用 │ └────────────┬─────────────┘ │ TCP / Socket ┌────────────▼─────────────┐ │ 连接器 (Connectors) │ ← 建立连接、权限校验、维持长连接 └────────────┬─────────────┘ ┌─────────────────────────────┼─────────────────────────────┐ │ Server 层 │ ...