小菜鸟

MongoDB 简介：面向文档的分布式数据库

MongoDB 是一款高性能、开源、面向文档的 NoSQL 数据库，由 C++ 编写，专为处理海量非结构化或半结构化数据设计。它打破了传统关系型数据库的表结构限制，采用灵活的文档模型，非常适合 Web 应用、大数据存储和快速迭代的业务场景。

核心特性

面向文档的存储模型

• 文档（Document）：MongoDB 的基本数据单元，类似 JSON 格式的BSON（Binary JSON），支持嵌套结构、数组等复杂数据类型。

  示例文档：

  1 2 3 4 5 6 7 8 9 10 11

  { "_id": ObjectId("507f1f77bcf86cd799439011"), // 自动生成的唯一标识 "name": "MongoDB", "type": "database", "features": ["high performance", "high availability", "easy scalability"], "version": "6.0", "metrics": { "downloads": 1000000, "users": 500000 } }

• 集合（Collection）：多个文档的集合，类似关系型数据库的 “表”，但无需预先定义结构（模式自由），同一集合中的文档可以有不同的字段。

模式自由（Schema-less）

• 无需预先定义表结构（Schema），文档的字段可以动态添加或修改，适应业务快速迭代。

• 例如，同一users集合中可以同时存在以下文档：

1
2
3
4

// 文档1
{ "name": "Alice", "age": 25, "email": "alice@example.com" }
// 文档2（字段不同）
{ "name": "Bob", "phone": "123456789", "address": { "city": "Beijing" } }

高性能

• 内存映射（MMAP）：通过内存映射文件（MMAP）技术将数据文件直接映射到进程内存，读写操作通过内存完成，减少传统 I/O 开销。
• 索引支持：支持单字段索引、复合索引、地理空间索引等，加速查询（类似关系型数据库的索引）。
• 读写分离：支持副本集（Replica Set），主节点处理写操作，从节点分担读压力，提高吞吐量。

高可用性与扩展性

• 副本集（Replica Set）：由多个节点组成的集群，自动实现故障转移（主节点故障时，从节点自动选举新主节点），确保数据不丢失。
• 分片（Sharding）：将海量数据分散存储到多个分片服务器，支持水平扩展，应对数据量增长。

丰富的查询与聚合能力

• 支持类似 SQL 的查询语法，包括过滤、排序、分页、嵌套查询等。

• 提供强大的聚合框架（Aggregation Pipeline），支持数据分组、统计、转换等复杂操作。

• 示例查询：

LVS（Linux Virtual Server）：高性能 Linux 虚拟服务器集群方案

在高并发场景中，单台服务器难以承载海量请求，而 LVS（Linux Virtual Server）作为基于 Linux 内核的负载均衡技术，通过将请求分发到后端服务器集群，实现了服务的高可用与高扩展性。本文将深入解析 LVS 的核心架构、负载均衡技术及适用场景。

LVS 核心架构：分层设计与角色划分

LVS 的核心思想是通过负载调度器将客户端请求分发到后端真实服务器集群，整个集群对客户端透明（客户端仅感知调度器的 IP）。其架构包含三个关键角色：

• Director Server（调度器）：
  前端负载均衡节点，负责接收客户端请求，根据预设算法将请求转发至后端真实服务器。调度器是 LVS 的核心，运行着 IPVS（IP Virtual Server）模块（Linux 内核级软件）。
• Real Server（真实服务器）：
  后端提供实际服务的节点（如 Web 服务器、数据库服务器），接收调度器转发的请求并处理，最终将响应返回给客户端（部分模式下无需经过调度器）。
• Virtual IP（VIP）：
  调度器对外暴露的虚拟 IP 地址，客户端通过 VIP 访问服务，无需关心后端真实服务器的具体 IP。

IPVS：LVS 的内核级负载均衡核心

IPVS 是 LVS 的核心模块，集成在 Linux 内核中，负责实现请求的转发与调度。它支持三种核心负载均衡技术，适用于不同的网络场景：

1. NAT 模式（Network Address Translation，网络地址转换）

原理：

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

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

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

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

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）。