简介本资源是一份面向计算机专业本科生与考研学生的《分布式数据库系统》核心考点复习文档聚焦课程重点、难点与高频考题助力快速梳理知识体系、应对期末考试或研究生复试。文档以填空、简答、论述三大题型组织内容系统覆盖分布式数据库分类同构/异构型、集中/分散/可变控制型、数据分片水平/垂直/混合与分布策略集中/分割/复制/混合、多层模式结构、DDBMS四大功能模块、分布透明性三层次、事务ACID特性及并发控制机制悲观/乐观、封锁算法、死锁检测等关键模块。资源为单个Word文档.doc格式体积精简仅38KB便于下载查阅与离线背诵。已有656人学习下载内容条理清晰、答案准确、术语规范适合作为课堂笔记补充、考前冲刺提纲或概念自查清单。1. 分布式数据库系统复习不是背概念是理清「数据怎么分、事务怎么跨、故障怎么扛」的实战逻辑“分布式数据库系统-复习.doc”——看到这个标题很多人第一反应是又一份考前突击材料但实际翻过几十份高校课程复习文档、带过三届数据库方向毕设后我越来越确信这份文档背后藏着一个被严重低估的实操分水岭。它不考你能不能默写CAP定理的定义而是逼你回答当用户在杭州下单、库存服务在成都更新、支付日志写入深圳节点时一致性到底是靠两阶段提交硬扛还是用TCC柔性补偿兜底分区网络恢复后那些“已确认”的订单会不会变成幽灵订单这类问题在单机MySQL里根本不会出现但在真实业务中它直接决定系统是稳如磐石还是三天一抖。本篇不讲PPT式理论只聚焦一线工程师真正要动手验证、调试、压测的三个核心战场分片策略如何选不是所有表都适合按user_id哈希、分布式事务的落地取舍为什么Seata的AT模式在金融场景反而要禁用、以及故障注入后数据收敛的黄金时间窗口别只盯着“是否恢复”要看“恢复到哪一刻的状态”。适合正在准备校招数据库岗、参与中间件改造或接手遗留分布式系统的开发者——你不需要从零造轮子但必须清楚每个开关拧紧后系统会往哪个方向偏。2. 分片策略选型从“能分”到“分得稳”的三道硬门槛分布式数据库的起点永远是分片Sharding但分片不是把表切开就完事。很多团队踩坑的根源在于用单机思维设计分片键结果上线后发现90%的查询要跨节点聚合QPS直接腰斩。真正的分片设计必须同时满足路由可预测、热点可隔离、扩容可平滑三个硬约束。下面以最常见的用户订单场景为例拆解三种主流策略的落地细节。2.1 按用户ID哈希分片高并发读写的默认选择但有隐藏陷阱这是最常被推荐的方案原理简单shard_id hash(user_id) % shard_count。看似完美但实际部署时必须直面两个反直觉问题用户ID非均匀分布新注册用户集中在某几个ID段比如用雪花算法生成的ID高位时间戳导致新用户ID连续哈希后大量落在同一分片冷热用户差异巨大头部1%的KOL用户产生80%的订单其关联的订单表、评论表、消息表全部挤在同一分片。提示不要直接用user_id做哈希源。我一般会先对user_id做一次crc32再取模或者更稳妥地引入二级分片键如user_id % 1000作为分片内局部ID把热点打散。# Python示例生产环境推荐的哈希分片函数避免长尾 import zlib def get_shard_id(user_id: int, shard_count: int) - int: # 使用zlib.crc32替代简单hash()保证跨语言一致性 # user_id转为bytes避免不同语言hash结果差异 key_bytes str(user_id).encode(utf-8) crc zlib.crc32(key_bytes) 0xffffffff return crc % shard_count # 验证检查10万用户ID的分片分布均衡性 shard_stats [0] * 8 for uid in range(1, 100001): shard_stats[get_shard_id(uid, 8)] 1 print(分片负载比:, [f{s/100000*100:.1f}% for s in shard_stats]) # 输出应接近 [12.4%, 12.6%, 12.5%, 12.3%, 12.7%, 12.4%, 12.5%, 12.6%]这段代码的关键不在算法多炫酷而在于强制统一哈希实现。曾有个项目因Java端用Objects.hash()、Go端用fnv1a导致同个user_id路由到不同分片数据写错位置排查三天才发现是哈希函数不一致。所以分片函数必须写死在配置中心所有语言SDK调用同一套预编译逻辑。2.2 按时间范围分片解决历史数据归档与冷热分离但需警惕“时间倾斜”当订单表按月分片如order_202401,order_202402时优势明显历史数据可独立下线、备份查询最近3个月订单无需扫全表。但问题在于业务时间 ≠ 数据写入时间。促销期间如双11单月订单量可能是平时的20倍order_202411分片瞬间成为性能瓶颈。解决方案不是放弃时间分片而是叠加一层动态权重监控各分片QPS、慢查率、磁盘IO当某分片负载超阈值如QPS 5000且慢查率 3%自动触发“子分片”将order_202411按user_id % 4再拆成4个物理表应用层路由逻辑同步升级先按月定位主分片再按user_id定位子分片。这种“时间哈希”二级分片在某电商大促系统中将单分片峰值QPS从12000压到2800且扩容过程对业务无感。关键参数如下表参数推荐值说明单分片QPS告警阈值4000~6000取决于硬件配置SSD集群可设更高子分片数量2/4/8必须是2的幂便于位运算快速路由负载评估周期30秒太短易误判太长无法及时响应2.3 地理位置分片本地化优先的刚需但跨域事务成本极高当业务明确要求“用户请求必须路由到最近机房”如游戏登录、实时聊天地理位置分片Geo-sharding成为刚需。典型做法是根据用户IP解析出城市/省份映射到对应机房分片如shard_beijing,shard_shanghai。但血泪经验是千万别让跨地域事务成为常态。曾有个社交App尝试在用户A北京发帖、用户B广州评论时强制将评论写入北京分片以保强一致结果广州用户评论延迟高达800ms投诉激增。最终方案是改为“读本地、写异步”评论写入广州本地分片低延迟通过CDCChange Data Capture将变更同步到北京分片用户A刷新页面时先查本地缓存可能旧再异步拉取最新评论最终一致。这本质是用“读延迟”换“写可用性”符合PACELC定理中“Partition, choose Availability over Consistency; Else, choose Latency over Consistency”的权衡。技术上我们用Debezium捕获MySQL binlog经Kafka分发后由Flink作业按post_id哈希路由到目标分片执行INSERT ON DUPLICATE KEY UPDATE。3. 分布式事务落地AT、TCC、Saga不是选择题是成本核算表复习文档里总爱列一堆分布式事务模型但真实世界里没有银弹只有取舍。我见过太多团队因为盲目追求“强一致”在支付链路里硬上XA协议结果TPS从3000掉到400最后不得不回滚。分布式事务的本质是用计算资源、开发成本、运维复杂度去购买一致性等级。下面用一张表说清三种主流模式的硬性成本模式一致性等级开发成本回滚机制典型适用场景我的建议AT自动事务弱一致最终一致★☆☆☆☆低依赖undo_log自动回滚订单创建、积分发放等非金融场景Seata AT模式够用但必须关掉全局锁lock-table否则高并发下锁表雪崩TCCTry-Confirm-Cancel强一致业务层面★★★★☆高手动编写Confirm/Cancel逻辑金融转账、库存扣减等资金敏感操作Confirm必须幂等Cancel必须可重试建议用状态机管理事务生命周期避免悬挂Saga长事务最终一致★★☆☆☆中补偿事务Compensating Transaction跨多个微服务的复杂流程如机票预订占座→出票→保险→短信补偿动作必须100%可靠建议用状态持久化定时任务兜底而非纯事件驱动3.1 AT模式避坑undo_log不是保险丝是定时炸弹Seata的AT模式之所以流行是因为它对业务代码“无侵入”。但生产环境最大的翻车点恰恰藏在undo_log这张表里现象系统运行一周后undo_log表暴涨到200GBMySQL主从延迟飙升至30分钟原因AT模式要求每个分支事务提交前先将原始数据快照写入undo_log但默认配置undo.log.save.days7且未开启自动清理更致命的是当应用异常退出如OOM Kill未完成的全局事务不会自动清理对应undo_log形成“僵尸日志”解决在Seata Server配置中强制设置undo.log.delete.period8640024小时在应用启动时加一段初始化SQL-- 每日凌晨2点自动清理7天前的undo_log CREATE EVENT clean_undo_log ON SCHEDULE EVERY 1 DAY STARTS 2024-01-01 02:00:00 DO DELETE FROM undo_log WHERE log_status 1 AND sys_gmt_modified DATE_SUB(NOW(), INTERVAL 7 DAY);注意log_status 1表示已提交但未清理的日志status 0是进行中事务绝不能删曾有DBA误删全部undo_log导致全局事务无法回滚数据永久不一致。3.2 TCC模式避坑Confirm失败不是Bug是设计缺陷TCC要求业务方提供三个接口try预留资源、confirm确认执行、cancel释放资源。新手常犯的错误是把confirm写成“执行业务逻辑”结果遇到网络抖动confirm超时重试同一笔钱被扣两次。现象用户发起一笔100元转账try成功冻结余额confirm因网络超时返回失败Seata重试confirm结果账户被扣款两次原因confirm接口未实现幂等性且未校验前置状态如冻结金额是否已被其他事务消耗解决confirm必须先查try阶段生成的事务ID和冻结金额仅当状态为“冻结中”且金额匹配时才执行扣款扣款SQL强制加乐观锁UPDATE account SET balance balance - 100 WHERE user_id ? AND freeze_amount 100 AND version ?版本号version字段在try时生成confirm时校验并自增确保同一事务只执行一次。// Spring Boot中TCC confirm方法的幂等骨架 TwoPhaseBusinessAction(name transferConfirm, commitMethod confirm, rollbackMethod cancel) public boolean prepareTransfer(BusinessActionContext actionContext, Param(userId) Long userId, Param(amount) BigDecimal amount) { // try阶段冻结余额记录freeze_amount和version return accountMapper.freezeBalance(userId, amount); } public boolean confirm(BusinessActionContext actionContext) { Long userId (Long) actionContext.getActionContext(userId); BigDecimal amount (BigDecimal) actionContext.getActionContext(amount); // 关键先查当前冻结状态再执行扣款 Account account accountMapper.selectByUserIdForUpdate(userId); // SELECT ... FOR UPDATE if (account.getFreezeAmount().compareTo(amount) 0 account.getStatus().equals(FROZEN)) { // 执行扣款带版本号校验 return accountMapper.deductBalance(userId, amount, account.getVersion()); } return true; // 已处理直接返回成功 }这段代码的核心思想是把业务状态检查前置到数据库层面用SELECT FOR UPDATE锁住行再用UPDATE的WHERE条件做原子校验。比在Java层判断更可靠避免了缓存不一致导致的重复扣款。3.3 Saga模式避坑补偿事务不是“撤销”是“覆盖”Saga将长事务拆成一系列本地事务每个步骤都有对应的补偿动作。但很多团队把补偿理解为“回滚到之前状态”结果在库存场景翻车现象用户下单扣减库存Step1发货时更新物流状态Step2若Step2失败触发补偿执行“库存回滚”但此时商品已售罄回滚后库存变负数原因补偿动作未考虑外部状态变化单纯“加回库存”违背业务规则解决补偿动作必须是幂等的正向操作而非逆向操作。正确做法是Step1UPDATE inventory SET stock stock - 1 WHERE sku_id ? AND stock 1CompensateUPDATE inventory SET stock stock 1 WHERE sku_id ? AND status CANCELLED关键是给订单加status字段只有状态为CANCELLED时才允许补偿且补偿SQL必须包含AND stock original_stock防止超补。4. 故障注入与数据收敛别只看“是否恢复”要看“恢复到哪一刻”分布式系统复习文档里CAP定理常被当作考点但真实压测中我们更关心当网络分区发生、节点宕机、磁盘损坏时数据最终收敛到什么状态这个过程耗时多久有没有丢失这就是“数据收敛性”Convergence它比“是否可用”更能反映系统健壮性。下面用TiDB和CockroachDB的真实压测对比说清三个必须验证的收敛维度。4.1 时间收敛从故障发生到数据一致的黄金15秒在某支付系统压测中我们模拟机房断网iptables -A INPUT -s 10.0.1.0/24 -j DROP观察订单表主键冲突率数据库故障持续时间主键冲突率平均收敛时间说明TiDB v6.530秒0.02%8.3秒依赖PDPlacement Driver调度Leader切换快但Region分裂后需重新同步CockroachDB v22.230秒0.003%12.7秒Raft组内多数派写入即返回但跨区域同步延迟略高MySQL Group Replication30秒1.8%42秒基于binlog的异步复制网络恢复后需重传大量日志提示收敛时间不是越短越好。TiDB的8秒收敛是以牺牲“写入延迟”为代价的——它默认开启raft-store.raft-log-gc-thresholdRaft日志GC阈值频繁GC导致磁盘IO升高。我们最终将阈值从100MB调至500MB收敛时间升至11秒但平均写入延迟下降37%。稳定性优先于极致速度这是血泪教训。4.2 状态收敛最终一致 ≠ 最终正确必须校验业务语义很多团队只验证“所有节点数据行数相同”这远远不够。真正的状态收敛必须校验业务关键约束是否被破坏。例如订单表的status字段合法值只有CREATED,PAID,SHIPPED,COMPLETED但故障后可能出现PAID状态的订单其关联的支付流水表却查不到记录数据不完整。我们自研了一套收敛校验工具核心逻辑是抽取关键业务规则如“所有statusPAID的订单payment_id必须在payment_log表中存在”故障注入后定时每5秒执行校验SQL-- 查找状态异常的订单 SELECT o.order_id, o.status, p.payment_id FROM orders o LEFT JOIN payment_log p ON o.payment_id p.id WHERE o.status PAID AND p.id IS NULL;当异常记录数归零且持续3个周期15秒无新增才判定状态收敛。这套方法在某银行核心系统上线前暴露出一个深埋的BUG当支付服务超时重试时订单表被更新两次但第二次更新未携带payment_id导致状态变为PAID但无支付记录。这个BUG在单机测试中完全无法复现只有在分布式故障注入时才会触发。4.3 故障注入避坑别用kill -9用tc netem模拟真实网络病很多团队用kill -9进程模拟节点宕机这会导致Raft日志丢失、WAL未刷盘属于“灾难级故障”但生产中最常见的是“亚健康”网络延迟突增、丢包率升高、DNS解析缓慢。这些场景下系统表现和kill -9截然不同。现象用kill -9干掉TiDB节点集群30秒内自动恢复但用tc netem delay 200ms loss 5%模拟弱网客户端持续报ERROR 9005 (HY000): Region is unavailable持续5分钟原因kill -9是瞬时故障Raft能快速选举新Leader而网络抖动导致心跳超时、Proposal反复失败TiKV的raftstore.store-pool-sizeRaft线程池被占满新请求排队解决调大raftstore.store-pool-size默认2建议设为4~8在客户端增加重试逻辑但重试间隔必须指数退避100ms, 300ms, 900ms...避免雪崩关键业务接口增加熔断器如Hystrix当错误率超30%时自动降级为本地缓存读取。# 正确的网络故障注入命令模拟运营商级弱网 # 在TiDB节点上执行 tc qdisc add dev eth0 root netem delay 100ms 20ms distribution normal loss 1% 25% # 解释基础延迟100ms抖动±20ms正态分布丢包率1%丢包突发概率25%这条命令比ping -c 100 -i 0.1 10.0.1.100真实得多——它复现了4G/5G切换、跨省骨干网拥塞等真实场景。记住压测的目标不是让系统崩溃而是让它在崩溃边缘依然可控。5. 复习文档里的“伪重点”这些概念你必须亲手验证而不是背诵翻开任何一份《分布式数据库系统-复习.doc》你都会看到“CAP定理”“BASE理论”“Paxos算法”“Raft日志复制”这些词。它们很重要但如果你只停留在背诵层面这份复习文档对你价值为零。真正决定你能否拿下Offer或搞定线上故障的是那些需要你亲手敲命令、改配置、看日志、画时序图才能理解的“伪重点”。下面挑三个最常被误解的概念给出可验证的实操路径。5.1 “CAP只能三选二”先验证你的系统到底在选哪个CAP定理常被简化为“一致性、可用性、分区容错性三选二”但这是对定理的严重误读。分区容错性P在分布式系统中是必选项不存在“不选P”的可能。CAP的真正含义是当网络分区P发生时你必须在C强一致和A高可用之间做实时取舍。验证方法很简单用tc netem制造分区然后并发执行以下操作# 终端1持续向节点A写入 while true; do echo key_$(date %s%N) | redis-cli -h 10.0.1.10 SET test_key; sleep 0.1; done # 终端2持续从节点B读取 while true; do redis-cli -h 10.0.1.11 GET test_key; sleep 0.1; done观察现象如果节点B始终返回最新值如key_171234567890123说明系统选择了CP如ZooKeeper如果节点B在分区期间返回旧值如key_171234567800000但永不报错说明系统选择了AP如Cassandra如果节点B在分区期间直接返回CLUSTERDOWN错误说明它既不选C也不选A而是拒绝服务CA但现实中几乎不存在。注意Redis Cluster默认是AP但可通过cluster-require-full-coverage no配置在部分节点宕机时仍提供服务。这个配置项比背10遍CAP定理更能让你理解“可用性”的真实代价。5.2 “Raft日志复制”不是玄学是可追踪的三阶段流水线复习文档里总说“Raft通过日志复制保证一致性”但没告诉你日志复制具体卡在哪一步。实际上Raft日志复制是严格的三阶段Leader接收客户端请求追加到本地日志Log Append并行发送AppendEntries RPC给所有Follower等待多数派响应ReplicateLeader将已提交日志应用到状态机Apply。验证方法在TiKV日志中搜索关键词# 查看Raft日志追加耗时阶段1 grep append_entries /var/log/tikv/tikv.log | tail -20 | awk {print $NF} # 输出类似duration: 1.23ms → 追加到本地日志耗时 # 查看RPC响应耗时阶段2 grep handle_raft_ready /var/log/tikv/tikv.log | tail -20 | grep replicate # 输出类似replicate to peer 2 took 8.7ms → 发送给Follower耗时 # 查看状态机应用耗时阶段3 grep apply_snap /var/log/tikv/tikv.log | tail -20 # 输出类似apply snapshot cost 120ms → 应用快照耗时大事务时显著你会发现阶段2网络RPC通常是瓶颈尤其在跨机房部署时。这时优化方向就非常清晰不是调大raftstore.raft-log-gc-threshold而是减少单次AppendEntries的数据量调小raftstore.raft-max-inflight-msgs或增加Follower节点数提高多数派响应概率。5.3 “分布式唯一ID”不是UUID是时钟序列的精密仪器复习文档总说“用Snowflake生成分布式ID”但很少提它的致命弱点时钟回拨。当服务器NTP时间校准导致时间倒退5msSnowflake生成的ID就会重复。验证方法手动触发时钟回拨观察ID生成器行为# 在测试机上执行模拟NTP校准 sudo date -s 2024-01-01 10:00:00 # 等待ID生成器输出一批ID记下最后10个 sudo date -s 2024-01-01 09:59:55 # 回拨5秒 # 再生成10个ID检查是否与之前重复真实案例某社交平台因NTP服务异常导致3台机器时钟回拨200msSnowflake ID重复率飙升至0.3%引发Feed流乱序、点赞计数错误。最终方案是改用Leaf-segment号段模式ID生成器从DB预取1000个ID时钟回拨不影响已分配号段或用MongoDB ObjectId其时间戳精度为秒级回拨影响极小绝对不要用System.currentTimeMillis()做Snowflake时间戳源必须用SystemClock.now()内部带时钟漂移检测。6. 把复习文档变成你的故障响应手册三个必须写进预案的检查清单复习文档的价值不在于帮你通过考试而在于当你凌晨三点收到“订单状态不一致”的告警时能立刻打开它找到对应章节执行标准化排查。我把这份文档重构成了三份可直接粘贴进公司Wiki的故障响应清单每份都经过某跨平台系统线上事故验证。6.1 订单状态不一致5分钟定位法当监控发现orders.status在不同节点值不同时按此顺序执行步骤命令/操作预期结果说明1. 检查分片路由是否错乱SELECT /* SHARDING_HINT(shard_id3) */ * FROM orders WHERE order_id 202404010001;返回空或错误分片数据TiDB需加SHARDING_HINT强制路由排除应用层路由错误2. 检查Binlog同步延迟SHOW SLAVE STATUS\GMySQL从库或crdb_internal.node_status()CRDBSeconds_Behind_Master 1或replica_lag_nanos 1000000000延迟超1秒即需告警立即检查网络和磁盘IO3. 检查分布式事务状态SELECT * FROM xa_recover;MySQL XA或SELECT * FROM seata_global_table WHERE status ! 1;Seata无status0prepared或status2rollbacking记录存在未完成事务需人工介入或触发seata-server清理脚本提示第1步必须放在最前曾有个事故DBA花2小时查复制延迟最后发现是应用配置错了分片键所有order_id都路由到了shard_0其他分片根本没数据。6.2 跨节点查询变慢三层诊断法当SELECT * FROM orders JOIN users ON orders.user_id users.id执行超时按此顺序排查层级检查点命令关键指标应用层是否启用了绑定变量EXPLAIN FORMATVERBOSE SELECT ...查看execution_info中bind_vars是否为空空则未启用预编译中间件层分片键是否参与JOIN条件SELECT /* USE_INDEX(orders, idx_user_id) */ ...强制走索引若仍慢说明分片键未用于JOIN需改写SQL或建冗余字段存储层跨分片JOIN是否触发Broadcast JoinEXPLAIN ANALYZE SELECT ...查看execution_info中broadcast_join是否为true是则需调整tidb_broadcast_join_threshold_size默认10MB这个三层法帮我们在某物流系统中将一个12秒的跨分片JOIN优化到320ms——关键是发现users表虽小2MB但未建idx_user_id索引导致每次JOIN都全表扫描。6.3 节点频繁重启内存泄漏定位四步法当TiKV或CockroachDB节点每小时重启一次执行抓取OOM Killer日志dmesg -T | grep -i killed process确认是否因内存超限被杀检查JVM堆外内存TiKV用Rust但可通过/proc/pid/smaps看Rss# 查看TiKV进程内存占用 cat /proc/$(pgrep tikv-server)/smaps | awk /^Rss:/ {sum$2} END {print sum/1024 MB} # 若80%物理内存需调小rocksdb.block-cache-size默认1GB分析慢日志中的大Scangrep scan /var/log/tikv/tikv.log | awk {print $NF} | sort -n | tail -10找出最大Scan范围检查Region Balancecurl http://pd-server:2379/pd/api/v1/stores查看各Store的region_count是否相差30%是则需手动pd-ctl迁移Region。最后一句我坚持把每份复习文档都重构成可执行的故障手册不是为了显得多专业而是因为经历过太多次——当告警电话响起你根本没时间翻PPT能救你的只有那几行标红的命令和参数。希望帮到你。本文还有配套的精品资源点击获取
