系统设计 023三大核心表Sharding设计思路与最优解决方案✨前言Bilibili 同步视频一、分片设计核心底层逻辑二、Session Table 会话表分片实战2.1 表结构与业务场景2.2 查询逻辑分析2.3 分片方案设计2.4 核心代码示例分片路由逻辑2.5 方案优势总结三、NewsfeedTimeline 社交动态表分片实战3.1 业务定位区分3.2 分片逻辑拆解✅ Newsfeed 分片方案✅ Timeline 分片方案3.3 核心查询SQL示例3.4 方案设计价值四、Leetcode Submission 刷题提交记录表分片实战重难点4.1 表业务与字段说明4.2 双向查询需求核心冲突点4.3 单一分片键的致命缺陷4.4 最优解决方案主副表双分片设计1. 主表设计submission_main2. 辅助索引表设计submission_index4.5 双表查询逻辑代码示例4.6 方案核心优势分析五、全文核心总结与设计思维升华✨前言在分布式数据库架构设计中**分库分表Sharding**是解决单表数据量过大、查询性能瓶颈、系统吞吐量受限的核心技术手段。业界一直流传着一条黄金设计准则数据库的分片规则永远由业务查询逻辑决定。脱离查询场景的分片设计无异于无源之水、无本之木不仅无法优化性能反而会引发跨库查询、数据倾斜、维护困难等一系列问题。本文将结合三类高频实战数据表Session会话表、Newsfeed动态流表、Timeline个人主页表、Leetcode刷题提交记录表深度拆解不同业务场景下的分片设计逻辑、核心痛点与最优落地方案搭配原理详解实战代码场景适配分析全方位吃透分布式分片核心思维。Bilibili 同步视频系统设计 023三大核心表Sharding设计思路与最优解决方案一、分片设计核心底层逻辑在正式进入实战案例前我们先锚定分片设计的核心本质所有分片方案均围绕以下逻辑展开核心原则Query 决定 Sharding优先贴合高频查询维度设计分片键设计目标规避跨分片查询、减少全表扫描、均匀分散数据、提升读写性能核心痛点单分片键无法适配多维度查询场景是分布式分片最常见的设计难题二、Session Table 会话表分片实战2.1 表结构与业务场景Session会话表是后端系统的核心基础表主要用于存储用户登录会话信息维持用户在线状态核心字段如下session_key会话唯一标识Session Token全局唯一user_id关联用户ID标记会话所属用户expire_at会话过期时间用于清理失效会话数据create_time会话创建时间业务场景用户登录系统后浏览器会将session_key存储在本地Cookie中后续每一次接口请求、页面访问都会自动携带该Token完成身份校验。2.2 查询逻辑分析在真实业务场景中Session表99%的查询均基于session_key。用户请求身份校验时后端仅能获取请求携带的session_key无法提前预知当前请求的user_id因此绝对无法通过用户ID作为查询条件。2.3 分片方案设计基于查询逻辑Session表唯一最优分片键session_key✅通过session_key进行哈希分片可实现每一条会话数据精准落在对应分片身份校验查询仅需路由单个分片零跨分片查询、极速响应。2.4 核心代码示例分片路由逻辑/** * Session表分片路由工具类 * 分片规则session_key哈希取模固定路由分片 */publicclassSessionShardingUtil{// 分片总数可根据业务扩容调整privatestaticfinalintSHARDING_COUNT16;/** * 根据session_key获取目标分片 * param sessionKey 会话唯一Token * return 目标分片编号 */publicstaticintgetSessionShardIndex(StringsessionKey){// 哈希算法均匀打散数据避免数据倾斜inthashMath.abs(sessionKey.hashCode());returnhash%SHARDING_COUNT;}}2.5 方案优势总结完美适配高频查询场景单次身份校验查询耗时稳定在10ms以内⚡session_key全局唯一哈希分片可实现数据均匀分布无热点分片逻辑简单、维护成本低适配高并发登录、鉴权场景三、NewsfeedTimeline 社交动态表分片实战在社交、内容类系统中Newsfeed和Timeline是两大核心动态展示模块业务场景相近但定位不同分片逻辑均围绕用户维度展开是用户维度分片的经典落地案例。3.1 业务定位区分Newsfeed信息流用户关注好友、博主发布的所有内容汇总是「别人的内容给自己看」每个用户仅有权限查看属于自己的信息流Timeline个人主页单个用户自主发布的所有动态、帖子汇总是「自己的内容给别人/自己看」3.2 分片逻辑拆解✅ Newsfeed 分片方案Newsfeed表核心关联字段为owner_id信息流所属用户ID。业务查询逻辑固定为用户登录后通过自身user_id查询属于自己的信息流数据。因此Newsfeed表采用owner_id 作为分片键所有用户的信息流数据根据自身ID分片存储查询时精准路由对应分片。✅ Timeline 分片方案Timeline数据源自用户发布的帖子主表Post/Trend表查询逻辑固定为根据指定user_id筛选该用户发布的全部动态。因此Timeline体系统一采用user_id 作为分片键贴合「查询单人所有数据」的高频场景。3.3 核心查询SQL示例-- Newsfeed查询获取当前用户的信息流SELECT*FROMnewsfeed_tableWHEREowner_id#{current_user_id}ORDERBYpublish_timeDESCLIMIT20;-- Timeline查询获取指定用户的个人动态SELECT*FROMpost_tableWHEREuser_id#{target_user_id}ORDERBYpublish_timeDESCLIMIT20;3.4 方案设计价值社交类系统90%的内容查询均围绕「用户维度」展开基于user_id/owner_id分片可实现所有核心查询均命中单分片彻底规避跨分片聚合查询的性能损耗完美适配高并发刷动态、访问主页的业务场景。四、Leetcode Submission 刷题提交记录表分片实战重难点相较于前两类单维度查询场景Leetcode刷题提交记录表是多维度查询冲突的典型场景也是分布式分片设计的重难点案例极具学习参考价值。4.1 表业务与字段说明Submission表用于存储用户刷题的所有提交记录完整记录每一次代码提交的核心数据核心字段包含user_id刷题用户IDproblem_id题目唯一IDsubmit_time提交时间戳submit_code提交代码内容大体积文本status提交结果通过/超时/报错等code_length代码长度4.2 双向查询需求核心冲突点该表存在两个高频且优先级对等的查询维度也是分片设计的核心矛盾维度一题目维度查询查询某一道题目的所有用户提交记录按时间、代码长度排序用于展示题目排行榜、优秀题解维度二用户维度查询查询某一个用户的所有提交记录筛选刷题记录、通过题目、错题记录等个人数据4.3 单一分片键的致命缺陷若采用传统单分片键设计无论选择哪个维度都会出现性能瓶颈以user_id为分片键查询题目全量提交记录时需遍历所有分片数据全分片扫描性能极差以problem_id为分片键查询用户个人刷题记录时同样需要跨全分片聚合无法适配高频个人中心查询简言之单一分片键无法同时满足双向高频查询需求这也是分布式数据库多维度查询的通用痛点。4.4 最优解决方案主副表双分片设计结合业务查询频次、存储成本、性能损耗最终采用主表辅助表的双分片架构兼顾查询效率与存储性价比✅1. 主表设计submission_main分片键user_id原因用户个人刷题记录查询为高频日常操作优先级高于题目排行榜查询优先保障核心高频场景性能。主表存储全量完整数据包含代码、提交状态、时间等所有字段。2. 辅助索引表设计submission_index分片键problem_id核心设计思路冗余筛选字段、舍弃大体积数据。辅助表仅存储用于查询、筛选、排序的轻量级字段不存储大容量代码数据大幅降低存储成本。辅助表核心字段problem_id、user_id、submit_time、status、code_length4.5 双表查询逻辑代码示例/** * 刷题提交记录分片查询工具 * 主表user_id分片查询用户记录 * 辅助表problem_id分片查询题目记录 */publicclassSubmissionShardingUtil{privatestaticfinalintSHARDING_NUM16;// 用户维度查询路由主表publicstaticintgetUserSubmissionShard(LonguserId){returnMath.abs(userId.hashCode())%SHARDING_NUM;}// 题目维度查询路由辅助索引表publicstaticintgetProblemSubmissionShard(LongproblemId){returnMath.abs(problemId.hashCode())%SHARDING_NUM;}}4.6 方案核心优势分析性能最优双向查询均命中单分片彻底杜绝全分片扫描查询性能提升10倍以上⚡成本可控辅助表仅冗余轻量字段舍弃大容量代码数据存储冗余成本极低场景全覆盖同时适配用户个人记录、题目排行榜两大核心场景适配SQL数据库特性依托SQL数据库多索引能力弥补分布式分片的维度短板五、全文核心总结与设计思维升华通过三类实战数据表的分片设计拆解我们可以提炼出分布式数据库分片的通用设计思维适用于90%的业务场景场景优先Query驱动所有分片规则不凭经验、不凭直觉完全贴合业务高频查询逻辑这是分片设计的第一准则单维场景极简设计单一查询维度场景直接采用对应维度哈希分片简洁高效、零冗余、低维护多维场景冗余设计多查询维度冲突时拒绝单一分片键硬适配采用「主表兜底辅助表补全」的冗余方案以极小的存储成本换取极致查询性能冷热数据分层大体积、低频使用数据不冗余仅对筛选、排序核心字段做冗余存储平衡性能与成本分布式分片技术的核心从来不是复杂的算法与规则而是贴合业务、取舍有度的架构思维。读懂业务查询场景就掌握了分片设计的核心密码。
