课程目录速查

分布式数据库技术

数据库概述

授课教师

闫宗尧

  • 毕业院校：韩国亚洲大学
  • 专业背景：
    - 软件与计算机工学
    - 计算机科学与技术（大数据）
  • 邮箱：blitzmomo@163.com
钉钉二维码

山东外国语职业技术大学

课程安排

课时安排

每周 4 课时
  • 理论课： 2 课时
  • 实践课： 2 课时

课后任务

每周 2 份作业
  • 理论作业： 1 份
  • 实践作业： 1 份

成绩评定

平时 50%
+
期末 50%

⬇ 过程性成绩 (50%) 分数占比

  • 出勤：40%
  • 作业：20%
  • 实训：20%
  • 课堂参与度：20%

核心路线图

史前时代

从结绳记事到文件系统，数据如何存储？到底什么是数据库？

黄金时代

关系型数据库 (RDBMS) 称霸四十年。解密二维表与强大的 ACID 魔法。

分布式纪元

当数据量爆炸，单机撑不住时怎么办？带你拆解现代分布式架构的核心！

课前灵魂拷问：

大家平时都用过 Excel（或 WPS 表格）。
它也能建表格、存数据、还能搜索和筛选。
那么，如果把全校 2 万名学生的学籍和成绩，
或者全中国 14 亿人的微信好友名单全部存在 Excel 里，

你们认为，会发生什么可怕的灾难？

远古时代：如果没有数据库...

纯手工的痛

在计算机普及之前，人类用账本、卡片盒、甚至打孔卡来记录数据。


  • 查询靠吼： "张三的档案在哪？"
  • 检索靠翻： 从第一页翻到最后一页。
  • 灾难恢复靠命： 一场火灾，所有数据灰飞烟灭。
物理档案柜

电子化第一步：文件系统

TXT / Excel

把纸塞进硬盘

50年代，数据被存入磁带和硬盘。这就是文件系统 (File System) 时代。数据就像一堆 txt 文本文件。


看起来高科技了，但本质上只是把“物理文件柜”变成了“电子文件柜”。
大家能想到这种方式的致命弱点吗？

弱点一：数据冗余与不一致

"张三到底住哪？"的千古难题

假设学校有三个部门（教务处、财务处、宿管科），每个部门都有一个独立的 Excel 文件记录学生信息。

教务处.xlsx

张三，地址：北京

财务处.xlsx

张三，地址：北京

宿管科.xlsx

张三，地址：北京

灾难来了：张三搬家到了上海。他去教务处改了地址，但财务和宿管科没改。
——这就是数据冗余导致的【数据不一致】！

弱点二：并发修改冲突

千万别两个人同时点保存！

假设你们组两个人同时打开了一个存放着班费记录的文本文档：

  • 初始班费：100元
  • 同学A读取100，写入充值50，准备保存为150。
  • 同学B读取100，写入消费20，准备保存为80。
  • 结果： 后保存的人会直接覆盖前一个人的数据。钱对不上了！

文件系统没有强大的“并发控制机制”（锁机制）。

多并发冲突

到底什么是“数据库” (DB)？

智能超级大仓库

告别混乱的文件堆

为了解决文件系统的痛点，数据库 (Database) 诞生了。

官方定义： 长期存放在计算机内、有组织、统一管理、可以表现为多种形式、可共享的大量数据的集合。

通俗理解： 就像一个极其高度现代化的智能大仓库。里面的货物（数据）不再是乱扔的，而是按照严格的规格、分门别类地摆放在专属货架上，随时可以极速定位和提取。

数据库管理系统 (DBMS)

千万别把 DB 和 DBMS 搞混了！

DB (Database)

数据本身。
就像仓库里满地的货物，静静地躺在硬盘里。

DBMS (数据库管理系统)

管理数据的超级软件。
比如 MySQL, Oracle。它们是“智能仓库管理员”，帮你建表、查数据、防黑客、处理并发！

平时大家随口说的“数据库”，其实是 DBMS 软件！

数据库万年发展史

数据库系统演进时间轴

1960s

第一代
网状与层次模型

1970-80s

第二代
关系型数据库(RDBMS)

1990s

第三代
面向对象与数据仓库

2000s

第四代
NoSQL运动崛起

2010s+

第五代
分布式与NewSQL

接下来，让我们沿着时间轴，逐一解密每一代数据库的核心突破！

1960s：层次数据模型与网状数据模型

早期 DBMS 为了把数据“有组织”地存放，发明了非常“硬核”的结构（数据模型）：

层次数据模型 (Hierarchical)

典型代表是阿波罗登月计划使用的 IMS。数据呈树状结构（套娃，1对多）。缺点：必须从根节点一层层往下找，非常死板。

网状数据模型 (Network)

数据通过复杂的指针连接成一张网（多对多）。找数据就像走迷宫，一旦指针断了，数据就彻底找不到了。

"在那个年代，程序员写查询代码，不是在写逻辑，而是在写物理导航路线。"

如果表结构稍微改动一点，所有的查询代码必须全部重写！
网状和层次模型导致开发效率极低，维护极其痛苦。

1970年：一声惊雷

IBM 研究员 Edgar F. Codd（埃德加·科德）
发表了改变整个 IT 历史的论文：

《大型共享数据库的数据关系模型》
(A Relational Model of Data for Large Shared Data Banks)

救世主：关系数据模型 (Relational)

二维表

其实就是"高级版 Excel"

Codd 提出：废弃复杂的树和网！人类最容易理解的逻辑结构是二维表格。这就是现代 RDBMS (如 MySQL) 的核心。

  • 表 (Table/Relation)： 数据的集合（比如学生表）。
  • 行 (Row/Tuple)： 一条具体的记录（比如张三的完整信息）。
  • 列 (Column/Attribute)： 数据的属性（比如姓名、专业）。

为什么叫 "关系" (Relational)？

数据不再像文件系统那样冗余存储，而是通过 主键 (Primary Key) 和 外键 (Foreign Key) 关联起来。

学生表 (Student)

学号: 001 | 姓名: 张三 | 系别ID: D01

系别表 (Department)

系别ID: D01 | 系名: 大数据系 | 主任: 李四

好处：如果系主任换人了，只需要修改“系别表”一次，所有学生的资料自动映射出新的主任！彻底解决数据不一致！

SQL：数据库的“普通话”

告诉系统“你要什么”，而不是“怎么找”

基于关系模型的 SQL (结构化查询语言) 的伟大在于它是声明式的。

SELECT 姓名, 成绩
FROM 学生表
WHERE 成绩 > 90;

你只需要写这一句话，DBMS 内部的优化器会自动决定是扫全表还是走索引。程序员彻底解放！

Declarative Magic

1980s：关系型数据库的商业化浪潮

从理论走向印钞机

1970年代的理论，在1980年代彻底爆发，诞生了至今仍统治地球的商业巨头：

  • Oracle 的崛起： Larry Ellison 看到了 Codd 的论文，率先推出了商用关系型数据库 Oracle。
  • DB2 与 SQL 标准： IBM 推出了 DB2，随后 SQL 逐渐被 ANSI 确立为国际标准。
  • 统一天下： 全球的银行、电信、航空系统全面转向 RDBMS，开启了长达数十年的黄金时代。
商业巨头崛起

1990s：面向对象与数据仓库

数据分析与报表

探索新边界

随着互联网前夕和企业管理升级，需求开始变复杂：

  • 面向对象数据库 (OODBMS)： 为了配合 Java/C++ 等面向对象语言，试图把数据直接当成“对象”存起来（虽然最终没能取代关系型）。
  • 数据仓库 (Data Warehouse)： 企业发现，存数据不仅仅是为了交易，更是为了“看报表”。于是诞生了专门用于历史数据分析、商业智能 (BI) 的系统。

数据库的四大天王：ACID

关系型数据库之所以能接管全球的金融、交易系统，
靠的就是对事务 (Transaction)的严密保护。

（接下来的四页，是任何面试必考的硬核考点！）

A - Atomicity (原子性)

“同生共死，不可分割”

场景：张三给李四转账100元。

  • 动作1：张三账户扣除100元。
  • 动作2：李四账户增加100元。

问题：如果动作1执行完，系统突然断电了怎么办？张三钱扣了，李四没收到？

原子性保证：这两个动作被捆绑在一起。要么全部成功，要么全部失败（自动回滚，把张三的钱退回去）。绝不会停在中间状态！

C - Consistency (一致性)

“规矩就是规矩”

数据库状态必须从一个一致性状态转变到另一个一致性状态。满足你设定的所有业务规则。


例子：

  • 你设置了“年龄不能小于0”。
  • 你设置了“账户余额不能为负数”。

如果有任何操作试图打破这些规矩，数据库会直接拒绝执行报错！保证数据的绝对合法。

I - Isolation (隔离性)

“并发执行，互不干扰”

场景：周杰伦演唱会只剩最后1张票，你和另一个人同时点击了购买。


如果没有隔离性：两个人的查询都显示有票，然后系统分别卖给你们，导致超卖（1张票卖了2次）！

隔离性保证：通过复杂的锁机制（Locking）或多版本并发控制（MVCC），让同时发生的事务就像排好队一个一个执行一样，互不干扰。

D - Durability (持久性)

“落子无悔，刻在石碑上”

只要系统提示你“交易成功”（Commit），那么这个数据就永远保存下来了。


哪怕下一秒机房停电、服务器死机卡死、甚至主板烧了，只要硬盘物理没碎，系统重启后，你刚才存入的数据依然在！

（底层原理：RDBMS通过先写日志 Redo Log 的方式来实现这一点。）

危机暗涌：Web 2.0 时代的暴击

Oracle、MySQL 等传统关系型 DBMS 统治了企业界几十年。
在只有银行柜员、超市收银员使用系统的年代，它们完美无缺。

但是，互联网时代来了！网民数量从百万激增到十亿级别！

瓶颈一：单机存储的天花板

硬盘再大，也装不下整个世界

传统 RDBMS 设计之初，默认数据是存放在一台机器上的。

  • 一张表几百万条数据？轻松拿捏。
  • 一张表一亿条数据？加点索引勉强能跑。
  • 一张表几十亿、上百亿条数据？（比如微信的聊天记录总表）

单台服务器的硬盘容量是有限的，而且数据越大，查询像蜗牛一样慢（B+树过深）。

瓶颈二：并发性能大崩溃

一个人终究干不过千军万马

想象一个餐厅只有一个超级大厨（单台数据库服务器的 CPU 和内存）。

平时应付几十桌客人游刃有余。但在节假日（比如双十一、抢火车票），瞬间涌入上千万个点单请求（高并发 QPS）！


CPU 瞬间飙升到 100%，内存爆满，系统直接拒绝服务，页面显示“502 Bad Gateway”。

传统抢救法：Scale-Up (垂直扩容)

"买更贵的机器！"

以前遇到瓶颈，企业的做法简单粗暴：这台服务器不行？换最顶配的小型机！换最昂贵的闪存存储！

普通服务器 ($2,000)

高端小型机 ($1,000,000)

"你无法培养出一头像大象那么大的猪。"

硬件的单机性能存在物理极限。
性能提升 1 倍，成本可能飙升 100 倍！
马云当年提出“去IOE”就是因为淘宝的数据量涨得太快，
按照 Scale-Up 模式，买机器能把阿里巴巴买破产。

另辟蹊径：2000s NoSQL 运动

"既然ACID太重，那我们不要了！"

2000年代，为了追求极致的并发和扩展性，诞生了 Redis、MongoDB、HBase 等 NoSQL (Not Only SQL)。

  • 放弃了复杂的二维表和外键关联。
  • 放宽了严格的 ACID 一致性要求。
  • 换来了极易扩展、性能逆天的读写能力。

但在涉及钱（金融、交易）的场景，依然不敢用 NoSQL，强一致性不能丢！

破局之道：分布式体系结构

Scale-Out (水平扩展)

既然买不起一头巨大无比的牛，不如用 100 匹普通马拉车！
用一堆廉价的普通 PC 服务器，通过高速网络连接起来，软件层面让它们协同工作。

什么是真正的分布式数据库？

物理上分散，逻辑上统一

对于使用系统的程序员来说，他们感觉不到背后是一百台机器。
他们依然只看到一个入口，使用标准的 SQL 进行查询。

所有的路由、分片、节点故障切换，全部由分布式数据库系统在底层偷偷搞定！

分布式核心体系结构

现代分布式数据库（如 TiDB, OceanBase）通常采用存算分离架构，分为三个核心层：

1

计算层 (Compute)

系统的大脑。
只负责解析SQL，生成执行计划。它是无状态的，随时可以增加节点来抗并发压力。

2

存储层 (Storage)

系统的躯干。
真正存数据的地方。数据被切成小块，分散存在成千上万台存储节点上。

3

协调层 (Meta)

系统的总管。
记录元数据（谁存了什么）。负责发号施令，监控各节点的死活。

核心魔法一：数据分片 (Sharding)

化整为零的艺术

一张 100 亿行的表，一台机器装不下也查不动。

分布式系统会自动把它“切”成 100 份（每份 1 亿行），均匀分布在 100 台存储节点上。

  • 存储无限： 容量不够了？加机器！
  • 算力暴增： 查询这 100 亿数据时，100台机器同时搜索自己那份，然后汇总，速度提升近百倍！

怎么切？Hash vs Range

策略 A：Range 分片

按数据的范围切。

例如：节点1存用户1~1000万，节点2存1000万~2000万...

  • ✅ 优点：范围查询（找某个区间的用户）特别快。
  • ❌ 缺点：容易产生热点数据（比如新注册用户全涌向最后一个节点）。

策略 B：Hash 分片

通过 Hash 函数把数据打散。

例如：学号模除3，余数决定去哪个节点。

  • ✅ 优点：数据分布极其均匀，请求被完美平摊。
  • ❌ 缺点：范围查询很惨，必须所有节点一起查。

核心魔法二：多副本 (Replication)

影分身之术与高可用

既然机器多了，机器宕机、硬盘损坏就变成了常态。

为了保证数据不丢，每一个数据分片，都会在不同的物理机器上存 3 份副本（1个 Leader，2个 Follower）。

  • 平时大家都只找 Leader 读写。
  • 如果存 Leader 的机器冒烟了，剩下的 Follower 们会在几秒内自动投票选举出新的 Leader 继续接客。业务完全无感知！

分布式事务难题：两阶段提交

跨越机器的 ACID 挑战

张三（数据在机器A）给李四（数据在机器B）转账。
如何保证A扣钱和B加钱必须同时成功？这就是著名的分布式事务难题。

2PC (两阶段提交) 机制：引入一个协调者。

阶段1 (准备)： 协调者问 A和B："能干不？" A和B分别锁住资源，回答"准备好了！"

阶段2 (提交)： 协调者收到所有同意后，大喊："动手！" A和B同时落盘。如果有任何一个报错，协调者大喊："全部撤销！"

分布式系统的终极魔咒：CAP定理

在分布式世界里，你不可能什么都要。
一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition tolerance)。

C 要绝对精准
A 要永不宕机
P 要允许断网

鱼与熊掌不可兼得，最多只能三选二！
(由于网络必有波动，P必须选，实际上是在 C 和 A 之间权衡)

妥协的艺术：BASE 理论

最终一致性 (Eventual Consistency)

对于大部分互联网应用（如点赞、评论），没必要追求死板的强一致性 (C)，那样系统太容易卡顿。

  • BA (Basically Available)： 基本可用。大促时，允许部分边缘功能（如看评价）变慢。
  • S (Soft State)： 软状态。允许数据在节点之间同步时存在极短的延迟状态。
  • E (Eventual Consistency)： 最终一致性。你发的朋友圈，别人晚个零点几秒看到没关系，只要最终大家看到的一样就行！

终极形态：NewSQL 的崛起

小孩子才做选择，大人全都要！

2010年代后，Google Spanner, TiDB, OceanBase 等 NewSQL 横空出世。

传统 RDBMS 的强 ACID NoSQL 的无限横向扩展

它们既能像支付宝一样一分钱不差，又能像双十一一样抗住千万级高并发。
它们是目前云原生时代大厂的核心基石。

核心场景 1：电商极限并发

双十一零点秒杀：系统是如何稳住的？

  • 弹性扩容： 提前一个月通过增加云端节点（Scale-Out），将算力扩充10倍。大促结束后一键销毁，节约成本。
  • 热点打散： 茅台抢购？通过智能分片策略，把茅台的库存数据打散到多个节点，防止单个机器被流量压垮。
  • 内存计算： 结合分布式缓存，将高频读取的数据放在内存中极速响应。

什么是 HTAP？一边交易一边分析

以前，老板要看报表，得把交易库的数据抽取到专门的数据仓库，要等一天 (T+1)。

HTAP (混合事务/分析处理)： 现代分布式数据库的新魔法！

行存节点 (TP)

专门负责高并发的订单写入、扣款等交易业务。

列存节点 (AP)

数据实时同步过来并转为列式存储，专门负责生成实时数据大屏，毫秒级分析全国销量。

同一套系统，两套引擎，互不干扰！

核心场景 2：金融核心与异地多活

哪怕城市断网，支付不能停

金融机构采用"两地三中心"或"三地五中心"的分布式部署架构。

  • 数据分片分布在不同城市的机房。
  • 通过 Paxos/Raft 协议，保证哪怕整个杭州的机房遭遇地震断电。
  • 北京和深圳的节点依然包含完整副本，并能在 RTO < 30秒内自动接管所有核心银行业务，数据零丢失 (RPO=0)！

核心场景 3：智能物联网 (IoT)

吞吐量怪兽：时序数据

全国 100 万辆新能源汽车，每辆车每 10 秒上传一次电池温度、车速、位置。

这种数据叫时序数据 (Time-Series)，特点是：疯狂只写不改，数据量按 PB 级增长。

  • 分布式时序数据库 (如 InfluxDB, TDengine) 通过极高压缩率和分布式写入机制。
  • 支撑车企实时分析哪批次电池存在过热风险。

数据库的下一站

Serverless 云原生

彻底按需付费，你连服务器配置都不用选，流量来了系统自动“膨胀”，没有流量自动缩为零，像用水电一样用数据库。

AI for DB (自动驾驶)

让 AI 来管理数据库！自动发现慢 SQL，自动建索引，自动预测明天的流量并提前扩容。未来的 DBA 可能就是 AI 监督员。