小菜鸟

B + 树：多路搜索树的优化变体与数据库索引核心

B + 树是 B - 树的改进版本，作为一种多路平衡搜索树，它在 B - 树的基础上强化了对范围查询的支持和存储效率，成为数据库索引（如 MySQL InnoDB、PostgreSQL）和文件系统的核心数据结构。其设计充分适配磁盘 IO 特性，通过有序的叶子节点链表和集中存储的数据，实现高效的单点查询和范围查询。

B + 树的核心特点

m 阶 B + 树（m 为阶数，即节点最多的子节点数）具有以下关键特性：

1. 节点结构：
   • 每个非叶节点（索引节点）最多有m个子节点，存储m个关键字（用于索引子节点范围）。
   • 非根节点的关键字数量k满足：⌈m/2⌉ ≤ k ≤ m（⌈m/2⌉为向上取整，保证节点不过于稀疏）。
2. 数据存储：
   • 所有实际数据（记录）仅存储在叶子节点，非叶节点仅作为索引（不存数据）。
   • 叶子节点按关键字大小有序排列，且相邻叶子节点通过双向链表连接（形成有序链表），便于范围查询。
3. 平衡性：
   • 所有叶子节点位于同一层，保证查询效率稳定（最坏情况与平均情况性能一致）。

示例：3 阶 B + 树结构

1
2
3

          [10, 20]       // 非叶节点（索引节点）：2个关键字，3个子节点
         /    |    \
[5,10] <-> [15,20] <-> [25,30]  // 叶子节点（数据节点）：双向链表连接，存储所有记录

• 非叶节点[10,20]的关键字用于划分范围：左子节点存储≤10 的记录，中间存储 10~20 的记录，右子节点存储≥20 的记录。
• 叶子节点[5,10]、[15,20]、[25,30]通过指针串联，支持从 5 到 30 的连续范围查询。

B + 树的插入操作

B + 树的插入仅在叶子节点进行，插入后需保持节点有序和平衡性，核心处理 “节点溢出”（关键字数量超过m）的情况。

B - 树（B 树）：多路平衡查找树的磁盘优化设计

B - 树（B 树）是一种多路平衡查找树，专为磁盘等外存设备设计，通过降低树的高度减少磁盘 IO 次数，广泛应用于数据库索引（如 MySQL 的 InnoDB 引擎）和文件系统。与二叉树相比，B 树允许每个节点包含多个关键字和子树，在相同数据量下具有更低的高度，显著提升大规模数据的查询效率。

B - 树的核心概念

关键术语

• 阶数（m）：B 树的阶数是指一个节点最多可拥有的子节点数量（即多路的 “路数”）。例如，m 阶 B 树的一个节点最多有 m 个子节点。
• 关键字：节点中存储的用于查找的数值（如数据库中的索引键），每个关键字对应一条记录或指向记录的指针。
• 度：一个节点实际拥有的子节点数量（≤ 阶数 m）。

m 阶 B 树的定义与特性

一个 m 阶 B 树需满足以下属性，以保证平衡性和高效查找：

1. 节点结构：
   • 每个非叶节点包含 k-1 个关键字和 k 个子节点（k 为该节点的度，2 ≤ k ≤ m）。
   • 关键字按升序排列：key₁ < key₂ < ... < keyₖ₋₁，且第 i 个子节点中的所有关键字均满足 keyᵢ₋₁ < 子节点关键字 < keyᵢ（边界关键字除外）。
2. 根节点特殊规则：
   • 根节点至少有 2 个子节点（k ≥ 2），除非树中仅含根节点（空树或仅一个节点）。
3. 非根节点规则：
   • 每个非根节点的度 k 满足：⌈m/2⌉ ≤ k ≤ m（⌈m/2⌉ 表示向上取整，如 m=5 时，⌈5/2⌉=3）。
   • 关键字数量 j 满足：⌈m/2⌉ - 1 ≤ j ≤ m - 1（如 m=5 时，关键字数量为 2~4）。
4. 叶子节点：
   • 所有叶子节点位于同一层（平衡特性），且不含子节点（或子节点为 null）。

示例：3 阶 B 树

3 阶 B 树（m=3）的特性：

树（Tree）：层次结构的数据结构基础

树是一种非线性数据结构，由节点（Node）和边（Edge）组成，呈现层次化的分支关系。它广泛应用于文件系统、数据库索引、决策分析等场景，是理解更复杂数据结构（如二叉树、B 树）的基础。

树的核心概念与特性

基本定义

树是由n（n ≥ 0）个节点组成的有限集合：

• 当n = 0时，称为空树。
• 当n > 0时，有且仅有一个根节点（Root），其余节点分为若干个互不相交的子集，每个子集本身也是一棵树（称为子树）。

关键术语

• 节点的度：一个节点拥有的子节点数量（如叶子节点的度为 0）。
• 树的度：树中所有节点的最大度数（反映树的 “分支能力”）。
• 父节点与子节点：若节点A是节点B的直接前驱，则A是B的父节点，B是A的子节点。
• 叶子节点：度为 0 的节点（无任何子节点）。
• 深度：从根节点到当前节点的路径长度（根节点深度为 0，子节点深度为父节点深度 + 1）。
• 高度：从当前节点到最深叶子节点的路径长度（叶子节点高度为 0，父节点高度为子节点高度的最大值 + 1）。

核心特性

• 唯一性：根节点唯一，非根节点有且仅有一个父节点。
• 无环性：任意两个节点之间的路径唯一，不存在环路。
• 层次性：节点按 “根→子树” 的层次关系组织。

树的表示方式

树的存储需体现节点间的父子关系，常见表示方法有以下两种：

1. 父节点表示法（数组存储）

Nacos 持久化配置：从嵌入式数据库到 MySQL 集群方案

Nacos 默认使用嵌入式数据库 Derby 存储配置和服务元数据，但其仅适用于单机模式。在生产环境的集群部署中，为保证数据一致性和高可用性，需将数据持久化到外置数据库（目前官方仅支持 MySQL）。本文详细介绍 Nacos 持久化的配置步骤及注意事项。

为什么需要持久化？

• Derby 的局限性：嵌入式数据库仅存在于当前 Nacos 节点的内存和本地文件中，集群环境下各节点数据无法同步，导致配置和服务信息不一致；
• 数据可靠性：MySQL 支持数据持久化和主从备份，避免 Nacos 节点故障导致数据丢失；
• 集群一致性：Nacos 集群所有节点连接同一 MySQL 数据库，确保配置和服务信息全局一致。

Nacos 持久化到 MySQL 的步骤

1. 环境准备

• MySQL 版本：推荐 5.7 及以上（需支持 InnoDB 引擎）；
• Nacos 版本：2.0.x 及以上（确保兼容 MySQL 驱动）；
• 权限：拥有 MySQL 数据库的创建、表操作权限。

2. 初始化数据库脚本

Nacos 提供了内置的数据库初始化脚本，步骤如下：

Nacos 配置分离：基于三元组模型的精细化配置管理

Nacos 通过Namespace（命名空间）、Group（分组）、Data ID（配置集 ID） 三元组模型实现配置的精细化管理，支持多环境隔离、多业务分组和多服务配置分离。这种模型能有效解决复杂微服务架构中配置混乱的问题，是 Nacos 配置中心的核心设计亮点。

Nacos 数据模型：三元组唯一标识配置

Nacos 的配置数据模型由三个维度构成，共同唯一确定一个配置项：

关系示意图：

1

Namespace（环境） → Group（业务组） → Data ID（服务配置）

例如：

• 生产环境（prod命名空间）→ 订单服务组（ORDER_GROUP）→ 订单服务配置（order-service-prod.yaml）
• 测试环境（test命名空间）→ 用户服务组（USER_GROUP）→ 用户服务配置（user-service-test.yaml）

配置分离的核心场景与实现

1. 环境隔离：Namespace 的应用

场景：开发、测试、生产环境的配置需要严格隔离（如数据库地址、密钥不同）。

实现步骤：

（1）创建命名空间
登录 Nacos 控制台，进入「命名空间」→「新建命名空间」：