小菜鸟

Elasticsearch 简介：分布式搜索引擎的核心架构与概念

Elasticsearch（简称 ES）是基于 Lucene 的分布式开源搜索引擎，它封装了 Lucene 的复杂性，通过简单的 RESTful API 提供高效的全文检索、分析和存储能力。广泛应用于日志分析、电商搜索、实时监控等场景。本文将详细解析其核心概念、架构设计及数据模型。

核心概念解析

文档（Document）

• 定义：ES 中最小的数据单元，类似关系型数据库中的 “一行记录”，以 JSON 格式存储。
• 特点：
  • 每个文档有唯一 ID（可自动生成或手动指定）。
  • 文档字段支持多种类型（文本、数字、日期、数组等），且会被索引以支持检索。
• 示例：一篇博客文章的文档可能包含 title（标题）、content（内容）、publish_time（发布时间）等字段。

类型（Type）

• 历史角色：早期设计中，类型用于对索引内的文档进行逻辑分类（类似关系型数据库的 “表”）。
• 现状：
  • ES 6.x 中限制每个索引只能有 1 个类型。
  • ES 7.x 及以上彻底移除类型，仅保留默认类型 _doc。
• 移除原因：
  • 不同类型的文档在物理存储上并未分离（同属一个 Lucene 索引），可能导致字段冲突（如同一字段在不同类型中类型不同）。
  • 与 Lucene 模型冲突：Lucene 索引本质是 “文档集合”，类型的划分增加了复杂度，不符合分布式存储逻辑。

索引（Index）

MySQL 事务的实现机制：redo log 与 undo log 详解

MySQL 事务的 ACID 特性（原子性、一致性、隔离性、持久性）依赖于底层的日志机制和锁机制。其中，redo log（重做日志） 和 undo log（回滚日志） 是保障事务持久性和原子性的核心组件，配合 “日志先行（Write-Ahead Logging, WAL）” 策略，实现了高效且可靠的事务处理。

事务实现的核心思想：日志先行（WAL）

MySQL 执行事务时，采用 “先写日志，再写数据” 的策略（WAL），即：

• 事务修改数据前，先将修改操作记录到日志中；
• 确保日志写入磁盘后，再异步将数据更新到磁盘中的数据文件（如 .ibd）。

这一策略的优势在于：

• 日志文件是顺序写入的，而数据文件的修改可能是随机的（效率更高）；
• 即使系统崩溃，未写入数据文件的修改可通过日志恢复，保证事务持久性。

redo log：保障事务的持久性

redo log 的作用

redo log 记录了事务对数据页的修改操作（如 “将 id=1 的行的 name 字段从 ‘A’ 改为 ‘B’”），用于在系统崩溃后恢复未写入数据文件的已提交事务，确保已提交的事务不会丢失（持久性）。

redo log 的写入流程

redo log 的写入涉及三个关键区域：

磁盘性能指标详解：从指标含义到瓶颈诊断

磁盘性能是影响系统整体响应速度的关键因素，尤其是在数据库、文件服务器等 IO 密集型场景中。理解磁盘性能指标不仅能帮助定位性能瓶颈，还能为系统优化和硬件选型提供依据。以下是对常见磁盘性能指标的详细解析。

核心磁盘性能指标

1. 磁盘 IO 等待（% iowait）

• 定义：CPU 处于空闲状态且等待 IO 操作完成的时间占比（通过 iostat 或 vmstat 查看）。
• 含义：反映 IO 操作对 CPU 的阻塞程度。若该值持续超过 20%，说明 IO 操作成为系统瓶颈，CPU 大量时间浪费在等待磁盘响应上。
• 示例：数据库服务器 %iowait 长期处于 30%，可能是 SQL 查询导致大量随机 IO，需优化索引或升级磁盘。

2. 队列平均长度（avgqu-sz）

• 定义：单位时间内等待处理的 IO 请求队列长度（通过 iostat -x 查看）。
• 理想值：正常情况下应保持在 2~3（约为磁盘物理磁头数的 1.5 倍）。
• 瓶颈判断：若长期超过 5，说明 IO 请求堆积，磁盘处理能力不足（如机械硬盘队列过长可能因磁头寻道延迟导致）。

3. 平均等待时间（await）

• 定义：单个 IO 请求从发出到完成的平均时间（包括在队列中等待的时间 + 实际 IO 操作时间），单位为毫秒（ms）。
• 理想值：
  • 机械硬盘（HDD）：应低于 20ms；
  • 固态硬盘（SSD）：应低于 5ms。
• 分析：若 await 远高于磁盘本身的 IO 处理时间（svctm），说明队列等待时间过长，需优化 IO 调度或升级磁盘。

4. 每秒 IO 操作数（tps）

• 定义：每秒完成的 IO 请求总数（包括读和写），反映磁盘的并发处理能力。
• 性能参考：
  • 机械硬盘（HDD）：随机 IO 场景下约 100~200 tps；
  • 固态硬盘（SSD）：随机 IO 场景下可达数千 tps；
  • 高端 NVMe SSD：可超过 10 万 tps。
• 注意：该指标需结合 IO 类型（随机 / 顺序），顺序 IO 的 tps 通常高于随机 IO。

内存性能指标深度解析：从指标含义到瓶颈识别

内存性能是决定系统运行效率的核心因素之一，尤其是在高并发应用、数据库服务等场景中，内存不足或交换频繁会直接导致系统响应迟缓。以下是对内存关键性能指标的详细解析，帮助你全面理解内存状态并定位瓶颈。

核心内存性能指标

1. 空闲内存（Free Memory）

• 定义：系统中未被使用的物理内存，通常需要结合缓冲（Buffers）和缓存（Cache）计算实际可用内存。

• 计算方式：
  实际可用内存 = 空闲内存（free） + 缓冲区（buffers） + 缓存（cache）
  （Linux 内核会将未使用的内存用于缓存文件数据，这部分内存可被进程随时占用，因此需纳入 “可用” 范畴）。

• 查看方式：

  1	free -h # 其中 "available" 字段直接显示实际可用内存

• 瓶颈判断：若实际可用内存长期低于总内存的 10%，且频繁触发内存回收（可通过 dmesg | grep "out of memory" 检查），说明内存资源紧张。

2. 交换空间使用（Swap Usage）

• 定义：当物理内存不足时，系统将部分不活跃的内存数据写入磁盘交换分区（Swap），以释放物理内存。相关指标包括：
  • Swap 已用空间：已使用的交换分区大小（通过 free -h 或 swapon -s 查看）。
  • Swap In/Out 速率：每秒从交换分区读入内存（Swap In）和从内存写入交换分区（Swap Out）的页数（通过 vmstat 查看 si 和 so 字段）。
• 瓶颈判断：
  • 若 Swap 已用空间超过交换分区总容量的 50%，且 si/so 长期大于 200-300 页 / 秒（1 页通常为 4KB），说明物理内存严重不足，系统频繁进行内存与磁盘的交换（“换页”）。
  • 频繁换页会导致大量磁盘 IO，显著降低系统性能（磁盘速度远低于内存）。

CPU 性能指标全面解析：从使用率到瓶颈定位

CPU 作为系统的 “大脑”，其性能直接决定了系统的处理能力。理解 CPU 的各项性能指标，不仅能帮助判断系统是否存在计算瓶颈，还能精准定位瓶颈来源（如应用程序、内核或 IO 等待）。以下是对 CPU 关键性能指标的详细解析。

核心 CPU 性能指标

1. CPU 使用率（Overall CPU Usage）

• 定义：CPU 在单位时间内用于处理任务的时间占比，是反映 CPU 负载的最直观指标。
• 计算方式：
  使用率 = 100% - 空闲率（%id）
  （涵盖用户态、系统态、IO 等待等所有非空闲状态）。
• 瓶颈判断：
  长期（如 5 分钟以上）使用率超过 80%，说明 CPU 资源紧张；超过 90% 则可能导致任务排队、响应延迟。

2. 用户态占比（% us, User Space）

• 定义：CPU 用于执行用户应用程序（如 Java 进程、Python 脚本）的时间占比。
• 意义：反映应用程序的计算密集程度。
• 瓶颈判断：
  • 若%us长期超过 70%，说明应用程序消耗大量 CPU（如复杂计算、无限循环），需优化代码（如减少冗余计算、使用异步处理）。
  • 示例：数据库查询未走索引导致全表扫描，可能使%us骤升。