小菜鸟

限流算法详解：从计数器到令牌桶的实践与对比

在高并发场景中，限流是保护系统稳定的关键手段，通过限制单位时间内的请求量，避免服务因过载而崩溃。常见的限流方案包括计数器算法、漏桶算法和令牌桶算法，每种算法适用于不同的业务场景，各有优劣。

计数器算法：简单直观的流量控制

计数器算法是最基础的限流方式，通过统计单位时间内的请求数，超过阈值则拒绝新请求。分为固定窗口和滑动窗口两种实现。

1. 固定窗口计数器（Fixed Window）

原理

• 将时间划分为固定长度的 “窗口”（如 1 秒），维护一个计数器；
• 每个请求进入时，计数器加 1；若计数器超过阈值（如 100 次 / 秒），则拒绝请求；
• 窗口结束时，计数器重置为 0。

示例

• 阈值：100 次 / 秒，窗口大小 1 秒；
• 第 0-1 秒内，若请求达 100 次，后续请求被拒绝；
• 第 1 秒结束，计数器重置，第 1-2 秒重新计数。

优缺点

• 优点：实现简单（如用 Redis 的INCR+EXPIRE即可）；
• 缺点：存在 “窗口边界” 问题，可能出现突发流量。例如：
  • 第 0.9 秒内收到 99 次请求，第 1.1 秒内又收到 99 次请求；
  • 两个窗口均未超限，但 200ms 内总请求达 198 次，可能压垮服务。

适用场景

请求地址过长问题的排查与解决：Nginx 与 Resin 的协同配置

在 Web 开发中，表单提交或 API 请求若携带过多参数，可能导致 “请求地址过长” 的错误。这类问题往往涉及前端服务器（如 Nginx）和应用服务器（如 Resin）的多层配置限制，需逐层排查并调整参数。本文结合实际案例，详解问题根源及解决步骤。

问题现象与原因分析

现象：表单提交时，参数过多导致请求失败，浏览器可能提示 “414 Request-URI Too Long” 或应用服务器日志报错 “URL or HTTP headers are too long”。

根源：

• HTTP 协议中，GET 请求的参数通过 URL 传递，而服务器对 URL 长度和请求头大小通常有默认限制（避免恶意请求攻击）；
• 若参数过多（如复杂表单的批量提交），URL 长度或请求头大小超过服务器限制，请求会被直接拦截。

多层配置限制：从 Nginx 到 Resin

请求从客户端到应用服务器需经过多层处理，每层都可能存在长度限制，需逐一调整。

1. Nginx 的限制与配置

Nginx 作为前端反向代理，会先处理请求的 URL 和头部，默认对其长度有严格限制。

默认限制：

• client_header_buffer_size：默认 1k，用于存储普通请求头；
• large_client_header_buffers：默认 4 个缓冲区，每个 8k，用于存储大型请求头（如长 URL）。

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 的写入涉及三个关键区域：

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骤升。