3. 业务数据库基础：关系型数据库（MySQL）与非关系型数据库（Redis）的典型架构与数据模型
在构建倒排索引与业务数据库的一致性保障方案之前，必须深入理解两类核心业务数据库的底层架构与数据模型。MySQL 作为关系型数据库的代表，提供了强事务与结构化存储；Redis 作为非关系型数据库的代表，提供了高性能缓存与键值存储。两者的架构差异直接决定了数据同步策略的设计边界。
3.1 关系型数据库（MySQL）典型架构
MySQL 采用经典的客户端-服务器架构，核心组件包括连接层、SQL 层、存储引擎层与物理文件层。以下架构图展示了 MySQL 的内部模块与请求处理流程。
架构要点：MySQL 的 SQL 层与存储引擎层分离设计，使得 InnoDB 成为默认引擎后，事务、行锁、MVCC 等能力与倒排索引的变更日志（Binlog）紧密耦合。一致性保障方案必须关注 Binlog 的捕获时机与存储引擎的提交顺序。
3.2 MySQL 数据模型：关系、表与索引
MySQL 的数据模型基于关系代数，核心概念包括：
- 表（Table）：行与列的集合，每行代表一条记录，每列代表一个属性。
- 主键（Primary Key）：唯一标识一行，InnoDB 默认使用聚簇索引组织数据。
- 二级索引（Secondary Index）：非聚簇索引，叶子节点存储主键值，回表查询。
- 外键（Foreign Key）：维护表间引用完整性，但会降低写入性能。
| 概念 | 说明 | 与倒排索引的关系 |
|---|---|---|
| 聚簇索引 | 数据行与索引页物理连续存储 | 变更时需同步更新倒排索引的文档 ID 映射 |
| 二级索引 | 独立 B+ 树，叶子存主键值 | 倒排索引可视为特殊的二级索引 |
| 事务（ACID） | 原子性、一致性、隔离性、持久性 | 倒排索引更新需与业务事务保持最终一致 |
| Binlog | 记录所有数据变更的二进制日志 | 倒排索引同步的核心数据源 |
实践提示：在一致性保障方案中，MySQL 的 Binlog 通常以 Row 格式记录，确保每条 INSERT/UPDATE/DELETE 操作都能精确映射到倒排索引的文档变更。建议开启 Binlog 的完整镜像（full-image）以避免数据丢失。
3.3 非关系型数据库（Redis）典型架构
Redis 采用单线程事件循环 + 多数据类型的内存存储架构，强调极低延迟与高吞吐。以下架构图展示了 Redis 的核心模块与持久化策略。
架构要点：Redis 的单线程模型避免了并发竞争，但持久化（RDB/AOF）与主从复制可能引入数据不一致窗口。在倒排索引场景中，Redis 通常作为缓存层或二级索引加速层，其数据一致性依赖于与 MySQL 的同步策略。
3.4 Redis 数据模型：键值、哈希与有序集合
Redis 的数据模型以键（Key）为入口，支持多种数据结构。在倒排索引一致性场景中，最常用的类型包括：
- String：存储单个值，适合缓存文档内容或计数器。
- Hash：存储字段-值映射，适合表示文档的多个属性。
- Sorted Set：带权重的有序集合，适合存储倒排索引的 term → docID 列表及权重。
- Stream：消息队列，适合作为变更事件的缓冲通道。
| 数据类型 | 底层编码 | 倒排索引应用场景 | 一致性关注点 |
|---|---|---|---|
| String | int / embstr / raw | 缓存文档 ID 到内容的映射 | 过期时间与 MySQL 数据同步 |
| Hash | ziplist / hashtable | 存储文档的字段级属性 | 字段更新时需同步倒排索引 |
| Sorted Set | ziplist / skiplist | term → docID 列表 + 权重排序 | 增删文档时需原子更新集合 |
| Stream | listpack / rax | 变更事件缓冲，供消费者同步 | 消息确认与重试机制 |
一致性风险：Redis 默认不提供强一致性。当使用 Sorted Set 存储倒排索引时，若 Redis 宕机且未及时持久化，可能导致索引数据丢失。建议结合 AOF 的 everysec 策略与定期 RDB 快照，降低数据丢失窗口。
3.5 MySQL 与 Redis 的架构对比
下表从多个维度对比两种数据库的架构特性，为后续一致性方案设计提供决策依据。
| 维度 | MySQL（InnoDB） | Redis |
|---|---|---|
| 存储介质 | 磁盘（Buffer Pool 缓存） | 内存（磁盘持久化辅助） |
| 数据模型 | 关系型（表、行、列） | 键值型（多种数据结构） |
| 事务支持 | ACID 事务（MVCC + Redo Log） | Lua 脚本原子性，无回滚 |
| 一致性模型 | 强一致（主从异步可能弱一致） | 最终一致（主从异步） |
| 变更捕获 | Binlog（Row / Statement / Mixed） | 无原生变更日志，需 Keyspace Notification |
| 典型延迟 | 1~10ms（磁盘 I/O 影响） | <1ms（内存操作） |
| 扩展方式 | 读写分离 / 分库分表 | 主从复制 / 集群分片 |
设计启示：在倒排索引一致性方案中，MySQL 作为权威数据源（Source of Truth），Redis 作为加速缓存或二级索引。变更数据捕获（CDC）应基于 MySQL 的 Binlog，而 Redis 的更新应作为异步消费端，通过 Stream 或消息队列实现解耦。