拓冰网站定制 
后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载本文基于仓库文档 data/guides/how-do-we-manage-data.md 展开系统讲解数据管理中最核心的 6 种模式Cache Aside、Materialized View、CQRS、Event Sourcing、Index Table 与 Sharding。文中逐一说明每种模式的核心思想、典型工作流、适用场景与权衡取舍并结合本仓库中相关文档缓存策略、数据库分片、事件溯源等进行交叉印证帮助你在系统设计面试与真实架构选型中做出更合理的决策。数据管理是系统设计中永恒的主题读多写少的场景如何降低成本复杂聚合查询如何加速读写负载差异巨大时如何优化高频写入下如何保持扩展性本仓库收录的这份文档data/guides/how-do-we-manage-data.md给出了答案——6 种经过大规模系统验证的数据管理模式覆盖了从单机缓存到分布式分片的完整谱系。一、六大模式总览模式核心思想解决的核心问题典型场景Cache Aside旁路缓存读时先查缓存未命中再回源数据库读压力大、读多写少热点数据、用户资料、商品详情Materialized View物化视图预计算并物理存储查询结果复杂聚合查询耗时长数据仓库、BI 报表CQRS命令查询职责分离读写模型分离、独立优化读写负载与需求差异大复杂业务系统、高并发读Event Sourcing事件溯源以事件日志代替当前状态存储审计、回放、状态重建金融交易、购物车、审计系统Index Table索引表为特定查询建附加表大数据集上的频繁查询二级索引、查询加速Sharding分片数据水平拆分到多台服务器单机数据量/请求量过大高并发、海量数据应用这 6 种模式并非互斥实际系统中往往组合使用例如 CQRS Event Sourcing 常成对出现下面逐一深入。二、Cache Aside先查缓存未命中再回源2.1 工作流程原文档给出的定义非常清晰应用访问数据时先检查缓存如果数据不存在cache miss则从数据存储data store中取出数据、写入缓存再返回给用户。整个过程可以拆解为四个步骤应用发起数据读取请求先查询缓存Cache命中则直接返回未命中Cache Miss则回源查询数据库Data Store将查询结果写入缓存返回给调用方。2.2 适用场景原文档指出这一模式特别适合读频繁、更新少read frequently but updated less often的数据。例如用户资料、商品详情、配置信息等一次写入可被反复读取缓存命中率高能大幅降低数据库的读压力。2.3 与写策略的配合write-around仓库中的姊妹文档 data/guides/top-5-caching-strategies.md 对缓存策略做了更完整的划分将缓存策略分为读策略与写策略两类读策略Cache Aside旁路缓存、Read Through读穿透写策略Write Around绕写、Write Back回写、Write Through写穿透。该文档特别强调缓存策略通常组合使用。例如Write Around 常与 Cache Aside 搭配——写操作直接落到数据库、不更新缓存从而保证缓存不被写操作污染而读操作通过 Cache Aside 在未命中时按需回填。这是实践中非常经典的旁路缓存 绕写组合。2.4 缓存层级的完整视角仓库文档 data/guides/cache-systems-every-developer-should-know.md 还提醒我们数据在系统中无处不在地被缓存从浏览器HTTP 响应缓存、CDN静态资源、负载均衡器到消息中间件如 Kafka 按保留策略落盘缓存消息、服务内部的内存缓存、分布式缓存Redis乃至数据库自身的 Bufferpool 与物化视图都属于缓存的不同形态。Cache Aside 正是服务层内存缓存 / 分布式缓存这一类中最常用的读取策略。参考阅读data/guides/top-5-caching-strategies.md、data/guides/cache-systems-every-developer-should-know.md三、Materialized View把复杂查询结果存起来3.1 与普通视图的本质区别原文档指出Materialized View 是一种数据库对象其内容是一次查询的结果并且是**物理存储physically stored**的——数据被真正计算并落盘而不是像普通视图那样在每次请求时动态生成。这一区别至关重要普通视图View逻辑上的虚拟表每次查询时实时执行底层 SQL物化视图Materialized View查询结果被实体化存储后续查询直接读取已算好的结果。对于原本需要即时计算的复杂计算或聚合complex calculations or aggregations物化视图能显著缩短查询时间。3.2 适用场景原文档明确指出物化视图在**数据仓库data warehousing与商业智能business intelligence**场景中尤其有价值——这些场景下查询性能是生死攸关的报表、多维分析、跨表聚合等查询往往耗时巨大而物化视图让这些高成本计算只执行一次。仓库文档 data/guides/7-must-know-strategies-to-scale-your-database.md 也把 Materialized Views 列为 7 大数据库扩展策略之一Pre-compute complex query results and store them for faster access预计算复杂查询结果并存储以获得更快的访问。3.3 物化视图的缓存本质data/guides/cache-systems-every-developer-should-know.md 从缓存视角给出了一个颇有启发性的类比Materialized Views 与缓存类似——它们存储的是高计算成本查询的结果数据库可以直接返回这些预计算结果而不必重新计算。同时该文档还介绍了数据库内部的另一层缓存Bufferpool——数据库内存中保存数据页副本的缓冲池用于减少磁盘 I/O。物化视图可以看作更宏观、面向查询语义的预计算结果缓存。参考阅读data/guides/7-must-know-strategies-to-scale-your-database.md、data/guides/cache-systems-every-developer-should-know.md四、CQRS读写模型分离各自优化4.1 核心思想CQRSCommand Query Responsibility Segregation是一种架构模式将数据的读取模型read与写入模型write分离。查询数据所用的结构与更新数据所用的结构相互独立。原文档强调这种分离允许对每个操作独立优化从而带来三方面的收益性能performance读模型可以为查询量身定制如使用专门的读库、宽表、缓存写模型专注于事务与一致性扩展性scalability读与写可以各自独立水平扩展互不拖累安全性security可以针对读写分别施加不同的权限控制。4.2 适用场景CQRS 在读写需求差异很大的复杂系统中尤其有用。例如一个订单系统写入侧需要强一致的事务模型而读取侧可能需要多维度、高并发的查询视图。4.3 与其他模式的组合仓库中多个文档都提到了 CQRS 的组合用法data/guides/top-eventual-consistency-patterns-you-must-know.md 将CQRS-based Eventual Consistency列为最终一致性的 4 大模式之一将读写操作分离到不同数据库读写模型可分别针对特定需求优化两者之间通过异步机制最终保持一致data/guides/how-will-you-design-the-stack-overflow-website.md 展示了面试中的典型期望——微服务 各自数据库 大量缓存 分片 消息队列异步通信 Event Sourcing 与 CQRS 最终一致性/CAP 等分布式系统知识这从侧面说明了 CQRS Event Sourcing 是分布式系统设计中秀肌肉的标准组合data/guides/top-7-most-used-distributed-system-patterns.md 将 CQRS、Event Sourcing、Sharding 一同列为最常用的 7 大分布式系统模式之一。参考阅读data/guides/top-eventual-consistency-patterns-you-must-know.md、data/guides/top-7-most-used-distributed-system-patterns.md五、Event Sourcing用事件日志重建一切状态5.1 核心思想Event Sourcing 的核心转变是不再只存储领域的当前状态而是存储随时间发生的全部变更事件序列。原文档给出了它的两个关键收益状态重建应用可以通过事件日志在任意时刻重建过去的状态reconstruct past states审计追踪天然提供完整的变更审计轨迹audit trail。它适用于复杂的业务事务、可审计性、以及回滚或重放事件rollback or replay events的场景。5.2 从存状态到存事件的范式转变仓库文档 data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md 一针见血地总结了这一转变Event sourcing changes the programming paradigm from persisting states to persisting events. The event store is the source of truth.事件溯源把编程范式从持久化状态转变为持久化事件事件存储是唯一的事实来源。data/guides/differences-in-event-sourcing-system-design.md 进一步指出事件溯源范式追求的是确定性determinism这与普通 CRUD 系统设计的哲学截然不同——CRUD 直接覆盖当前状态而事件溯源只追加事件、从不抹去历史。5.3 三个真实案例data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md 给出了三个极具参考价值的落地案例案例事件存储形态消费方式New York Times将自 1851 年以来的每篇文章、图片、署名byline存入事件存储原始数据被反范式化为不同视图灌入多个 ElasticSearch 节点支撑站内搜索CDC变更数据捕获CDC 连接器从数据库表抽取数据并转换为事件事件推入 Kafka其他消费者sink从 Kafka 拉取消费微服务连接器Kafka broker 充当事件存储如购物车服务产生添加/移除商品事件欺诈服务、计费服务、邮件服务等从事件存储消费事件各自按需构建领域模型其中第三个案例尤其值得品味由于事件是事实来源source of truth每个服务都可以自行决定自己的领域模型——这是微服务间通过事件解耦、各自演进的关键。5.4 与 CQRS 的组合事件溯源与 CQRS 是天然搭档写侧以事件流追加事件读侧以 CQRS 模式构建针对查询优化的投影projection。两者结合时系统既能获得完整的审计与重放能力又能让读模型保持高性能。参考阅读data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md、data/guides/differences-in-event-sourcing-system-design.md六、Index Table为高频查询建专用索引表6.1 核心思想Index Table 模式的做法是在数据库中创建额外的、针对特定查询操作优化的附加表。这些表充当**二级索引secondary indexes**的角色目标是不用全表扫描主数据存储primary data store就能快速取数。6.2 适用场景原文档指出索引表在两类情况下特别有价值数据集很大large datasets全表扫描代价过高某些查询被频繁执行把这些查询需要的字段提前组织成一张宽表避免每次实时扫描。这与 data/guides/7-must-know-strategies-to-scale-your-database.md 中的Indexing策略Check the query patterns of your application and create the right indexes——分析查询模式并建立正确的索引以及Denormalization策略Reduce complex joins to improve query performance——减少复杂 Join 以提升查询性能形成呼应索引表本质上是以空间换时间的工程化手段。6.3 与数据库索引数据结构的关系仓库文档 data/guides/8-data-structures-that-power-your-databases.md 介绍了数据库底层常用的索引数据结构有助于理解 Index Table 之上的实现机制Skiplist常见的内存索引Redis 使用Hash indexMap数据结构的常见实现SSTable不可变的磁盘 Map 实现LSM treeSkiplist SSTable写吞吐高B-tree磁盘友好读写性能稳定Inverted index文档索引Lucene 使用Suffix tree字符串模式搜索R-tree多维搜索如最近邻。Index Table 通常配合这些底层索引结构落地附加表可以按查询键建立 B-tree 或 Hash 索引从而在大型数据集上做到快速定位。参考阅读data/guides/8-data-structures-that-power-your-databases.md、data/guides/7-must-know-strategies-to-scale-your-database.md七、Sharding把数据拆开摊到更多机器上7.1 核心思想Sharding 是一种数据分区模式将数据切分为更小、更易管理的分片shards每个分片可以存储在不同的数据库服务器上。原文档指出它的两大目的提升扩展性scalability把数据分布到多台机器提升性能performance将负载分散到多台服务器支撑更多用户与事务。它在高流量high-volume应用中尤为有效是**水平扩展horizontal scaling**的核心手段。7.2 为什么要分片三大驱动力data/guides/a-crash-course-in-database-sharding.md 把分片的动机归纳为三个直白的痛点单机数据量过大一台数据库服务器能容纳的数据是有限的单机请求量过大一台服务器能处理的请求数有限延迟升高数据增长后查询延迟随之上升。7.3 分片键与分片算法分片落地需要两个核心要素见 data/guides/a-crash-course-in-database-sharding.md分片键Sharding Key表中决定数据如何分布到各分片的列分片算法依据它来判定某行数据应落入哪个分片分片算法Sharding Algorithm依据分片键决定行归属的逻辑。仓库文档归纳了三种经典算法data/guides/a-crash-course-in-database-sharding.md 与 data/guides/key-concepts-to-understand-database-sharding.md 相互印证算法原理示例Range-based基于范围按分片键的连续范围切分用户 ID 1–1000 在 shard 11001–2000 在 shard 2Hash-based基于哈希对分片键做哈希取模shard_id hash(user_id) % num_shardsDirectory-based基于目录用查找表目录映射分片键到分片位置类似电话簿的目录路由7.4 分片的三种落地方式data/guides/a-crash-course-in-database-sharding.md 还区分了三种实现层级应用层分片应用自己决定每个查询走哪个分片中间件分片在应用与数据库之间加一层中间件处理分片逻辑数据库原生分片数据库系统本身内置分片能力。7.5 分片的收益与代价data/guides/vertical-partitioning-vs-horizontal-partitioning.md 从路由算法视角做了补充水平分区即通常所说的分片它把一张表按行拆成多张更小的表每张表列数相同、行数更少收益便于水平扩展可以不断加机器分摊负载缩短响应时间查询只扫更少的行结果返回更快。代价drawbacksORDER BY等全局排序变复杂通常需要从多个分片取数后在应用层归并排序分布不均hotspot某些分片的数据量远大于其他分片形成热点——这正是 data/guides/handling-hotspot-accounts.md 讨论的支付场景痛点如大促时商家账户被大量并发更新行锁成为瓶颈需要限流、拆分账户、缓存先行等优化手段。7.6 一致性与分片键选择的延伸此外data/guides/a-crash-course-in-database-sharding.md 明确列出分片的四大挑战复杂度上升基础设施与应用代码都变复杂数据分布分片键与算法选择直接决定数据是否均匀、性能好坏跨分片 Join 与事务跨分片操作难度大可能需要分布式事务管理再分片Resharding分片方案上线后要变更是复杂且耗时的过程。关于均匀分布还可延伸阅读 data/guides/consistent-hashing.md——一致哈希正是为了解决简单取模在节点增减时引发大量数据迁移而设计的分布式数据分布方案被 Amazon DynamoDB、Apache Cassandra、Discord、Akamai CDN 等大规模系统采用。参考阅读data/guides/a-crash-course-in-database-sharding.md、data/guides/key-concepts-to-understand-database-sharding.md、data/guides/vertical-partitioning-vs-horizontal-partitioning.md八、如何选择与组合实战决策清单这 6 种模式没有银弹选择取决于你的读写比例、数据规模、一致性要求与团队复杂度预算读多写少、延迟敏感优先考虑Cache Aside配合 Write Around 写策略把热点数据推到更快的存储层复杂聚合查询拖垮报表引入Materialized View预计算结果或配合Index Table为高频查询建宽表读写需求差异极大采用CQRS将读写模型解耦各自独立优化、独立扩展需要审计、回放与状态重建采用Event Sourcing把事件流当作唯一事实来源常与 CQRS 组合使用单机数据量或请求量逼近上限走向Sharding提前规划好分片键与算法并警惕热点分片与跨分片事务组合演进路径单一模式往往不够典型的大型系统会按Cache Aside → Index Table / Materialized View → CQRS Event Sourcing → Sharding的阶梯逐步叠加。所有结论均可在本仓库对应文档中溯源验证六大模式的原始定义见 data/guides/how-do-we-manage-data.md缓存写策略的配合见 data/guides/top-5-caching-strategies.md数据库扩展策略全景见 data/guides/7-must-know-strategies-to-scale-your-database.md分片算法与挑战见 data/guides/a-crash-course-in-database-sharding.md事件溯源案例见 data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md。掌握这六种模式你就能在面试和真实项目中针对不同数据特征给出有理有据的架构方案。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐Video2X 视频超分辨率与补帧指南免费把 360P 老片拉到 4K、帧率变丝滑Video2X 视频超分辨率与补帧指南免费把 360P 老片拉到 4K、帧率变丝滑 Video2X 是一个机器学习视频超分辨率与补帧框架它用 Vulkan音视频视频处理图像处理深度学习Redis 十大实战场景深度解析从缓存到分布式锁的 System Design 101 仓库指南Redis 十大实战场景深度解析从缓存到分布式锁的 System Design 101 仓库指南 Redis 常被简单地当作缓存来使用但它的能力远不止于后端文档教程Video2X基于机器学习的视频超分辨率与帧插值工具Video2X基于机器学习的视频超分辨率与帧插值工具 在数字视频处理领域低分辨率视频的增强和帧率提升一直是技术挑战。Video2X作为一个基于机器学习的开源音视频视频处理图像处理深度学习上一篇GBFR Logs实战指南4个阶段把Relink伤害统计用到极致下一篇Weave Router前端仪表盘深挖6个关键点看懂Next.js管理界面的实现结构创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 system-design-101 数据管理六大模式详解：从旁路缓存到分片的实战指南
后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载本文基于仓库文档 data/guides/how-do-we-manage-data.md 展开系统讲解数据管理中最核心的 6 种模式Cache Aside、Materialized View、CQRS、Event Sourcing、Index Table 与 Sharding。文中逐一说明每种模式的核心思想、典型工作流、适用场景与权衡取舍并结合本仓库中相关文档缓存策略、数据库分片、事件溯源等进行交叉印证帮助你在系统设计面试与真实架构选型中做出更合理的决策。数据管理是系统设计中永恒的主题读多写少的场景如何降低成本复杂聚合查询如何加速读写负载差异巨大时如何优化高频写入下如何保持扩展性本仓库收录的这份文档data/guides/how-do-we-manage-data.md给出了答案——6 种经过大规模系统验证的数据管理模式覆盖了从单机缓存到分布式分片的完整谱系。一、六大模式总览模式核心思想解决的核心问题典型场景Cache Aside旁路缓存读时先查缓存未命中再回源数据库读压力大、读多写少热点数据、用户资料、商品详情Materialized View物化视图预计算并物理存储查询结果复杂聚合查询耗时长数据仓库、BI 报表CQRS命令查询职责分离读写模型分离、独立优化读写负载与需求差异大复杂业务系统、高并发读Event Sourcing事件溯源以事件日志代替当前状态存储审计、回放、状态重建金融交易、购物车、审计系统Index Table索引表为特定查询建附加表大数据集上的频繁查询二级索引、查询加速Sharding分片数据水平拆分到多台服务器单机数据量/请求量过大高并发、海量数据应用这 6 种模式并非互斥实际系统中往往组合使用例如 CQRS Event Sourcing 常成对出现下面逐一深入。二、Cache Aside先查缓存未命中再回源2.1 工作流程原文档给出的定义非常清晰应用访问数据时先检查缓存如果数据不存在cache miss则从数据存储data store中取出数据、写入缓存再返回给用户。整个过程可以拆解为四个步骤应用发起数据读取请求先查询缓存Cache命中则直接返回未命中Cache Miss则回源查询数据库Data Store将查询结果写入缓存返回给调用方。2.2 适用场景原文档指出这一模式特别适合读频繁、更新少read frequently but updated less often的数据。例如用户资料、商品详情、配置信息等一次写入可被反复读取缓存命中率高能大幅降低数据库的读压力。2.3 与写策略的配合write-around仓库中的姊妹文档 data/guides/top-5-caching-strategies.md 对缓存策略做了更完整的划分将缓存策略分为读策略与写策略两类读策略Cache Aside旁路缓存、Read Through读穿透写策略Write Around绕写、Write Back回写、Write Through写穿透。该文档特别强调缓存策略通常组合使用。例如Write Around 常与 Cache Aside 搭配——写操作直接落到数据库、不更新缓存从而保证缓存不被写操作污染而读操作通过 Cache Aside 在未命中时按需回填。这是实践中非常经典的旁路缓存 绕写组合。2.4 缓存层级的完整视角仓库文档 data/guides/cache-systems-every-developer-should-know.md 还提醒我们数据在系统中无处不在地被缓存从浏览器HTTP 响应缓存、CDN静态资源、负载均衡器到消息中间件如 Kafka 按保留策略落盘缓存消息、服务内部的内存缓存、分布式缓存Redis乃至数据库自身的 Bufferpool 与物化视图都属于缓存的不同形态。Cache Aside 正是服务层内存缓存 / 分布式缓存这一类中最常用的读取策略。参考阅读data/guides/top-5-caching-strategies.md、data/guides/cache-systems-every-developer-should-know.md三、Materialized View把复杂查询结果存起来3.1 与普通视图的本质区别原文档指出Materialized View 是一种数据库对象其内容是一次查询的结果并且是**物理存储physically stored**的——数据被真正计算并落盘而不是像普通视图那样在每次请求时动态生成。这一区别至关重要普通视图View逻辑上的虚拟表每次查询时实时执行底层 SQL物化视图Materialized View查询结果被实体化存储后续查询直接读取已算好的结果。对于原本需要即时计算的复杂计算或聚合complex calculations or aggregations物化视图能显著缩短查询时间。3.2 适用场景原文档明确指出物化视图在**数据仓库data warehousing与商业智能business intelligence**场景中尤其有价值——这些场景下查询性能是生死攸关的报表、多维分析、跨表聚合等查询往往耗时巨大而物化视图让这些高成本计算只执行一次。仓库文档 data/guides/7-must-know-strategies-to-scale-your-database.md 也把 Materialized Views 列为 7 大数据库扩展策略之一Pre-compute complex query results and store them for faster access预计算复杂查询结果并存储以获得更快的访问。3.3 物化视图的缓存本质data/guides/cache-systems-every-developer-should-know.md 从缓存视角给出了一个颇有启发性的类比Materialized Views 与缓存类似——它们存储的是高计算成本查询的结果数据库可以直接返回这些预计算结果而不必重新计算。同时该文档还介绍了数据库内部的另一层缓存Bufferpool——数据库内存中保存数据页副本的缓冲池用于减少磁盘 I/O。物化视图可以看作更宏观、面向查询语义的预计算结果缓存。参考阅读data/guides/7-must-know-strategies-to-scale-your-database.md、data/guides/cache-systems-every-developer-should-know.md四、CQRS读写模型分离各自优化4.1 核心思想CQRSCommand Query Responsibility Segregation是一种架构模式将数据的读取模型read与写入模型write分离。查询数据所用的结构与更新数据所用的结构相互独立。原文档强调这种分离允许对每个操作独立优化从而带来三方面的收益性能performance读模型可以为查询量身定制如使用专门的读库、宽表、缓存写模型专注于事务与一致性扩展性scalability读与写可以各自独立水平扩展互不拖累安全性security可以针对读写分别施加不同的权限控制。4.2 适用场景CQRS 在读写需求差异很大的复杂系统中尤其有用。例如一个订单系统写入侧需要强一致的事务模型而读取侧可能需要多维度、高并发的查询视图。4.3 与其他模式的组合仓库中多个文档都提到了 CQRS 的组合用法data/guides/top-eventual-consistency-patterns-you-must-know.md 将CQRS-based Eventual Consistency列为最终一致性的 4 大模式之一将读写操作分离到不同数据库读写模型可分别针对特定需求优化两者之间通过异步机制最终保持一致data/guides/how-will-you-design-the-stack-overflow-website.md 展示了面试中的典型期望——微服务 各自数据库 大量缓存 分片 消息队列异步通信 Event Sourcing 与 CQRS 最终一致性/CAP 等分布式系统知识这从侧面说明了 CQRS Event Sourcing 是分布式系统设计中秀肌肉的标准组合data/guides/top-7-most-used-distributed-system-patterns.md 将 CQRS、Event Sourcing、Sharding 一同列为最常用的 7 大分布式系统模式之一。参考阅读data/guides/top-eventual-consistency-patterns-you-must-know.md、data/guides/top-7-most-used-distributed-system-patterns.md五、Event Sourcing用事件日志重建一切状态5.1 核心思想Event Sourcing 的核心转变是不再只存储领域的当前状态而是存储随时间发生的全部变更事件序列。原文档给出了它的两个关键收益状态重建应用可以通过事件日志在任意时刻重建过去的状态reconstruct past states审计追踪天然提供完整的变更审计轨迹audit trail。它适用于复杂的业务事务、可审计性、以及回滚或重放事件rollback or replay events的场景。5.2 从存状态到存事件的范式转变仓库文档 data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md 一针见血地总结了这一转变Event sourcing changes the programming paradigm from persisting states to persisting events. The event store is the source of truth.事件溯源把编程范式从持久化状态转变为持久化事件事件存储是唯一的事实来源。data/guides/differences-in-event-sourcing-system-design.md 进一步指出事件溯源范式追求的是确定性determinism这与普通 CRUD 系统设计的哲学截然不同——CRUD 直接覆盖当前状态而事件溯源只追加事件、从不抹去历史。5.3 三个真实案例data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md 给出了三个极具参考价值的落地案例案例事件存储形态消费方式New York Times将自 1851 年以来的每篇文章、图片、署名byline存入事件存储原始数据被反范式化为不同视图灌入多个 ElasticSearch 节点支撑站内搜索CDC变更数据捕获CDC 连接器从数据库表抽取数据并转换为事件事件推入 Kafka其他消费者sink从 Kafka 拉取消费微服务连接器Kafka broker 充当事件存储如购物车服务产生添加/移除商品事件欺诈服务、计费服务、邮件服务等从事件存储消费事件各自按需构建领域模型其中第三个案例尤其值得品味由于事件是事实来源source of truth每个服务都可以自行决定自己的领域模型——这是微服务间通过事件解耦、各自演进的关键。5.4 与 CQRS 的组合事件溯源与 CQRS 是天然搭档写侧以事件流追加事件读侧以 CQRS 模式构建针对查询优化的投影projection。两者结合时系统既能获得完整的审计与重放能力又能让读模型保持高性能。参考阅读data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md、data/guides/differences-in-event-sourcing-system-design.md六、Index Table为高频查询建专用索引表6.1 核心思想Index Table 模式的做法是在数据库中创建额外的、针对特定查询操作优化的附加表。这些表充当**二级索引secondary indexes**的角色目标是不用全表扫描主数据存储primary data store就能快速取数。6.2 适用场景原文档指出索引表在两类情况下特别有价值数据集很大large datasets全表扫描代价过高某些查询被频繁执行把这些查询需要的字段提前组织成一张宽表避免每次实时扫描。这与 data/guides/7-must-know-strategies-to-scale-your-database.md 中的Indexing策略Check the query patterns of your application and create the right indexes——分析查询模式并建立正确的索引以及Denormalization策略Reduce complex joins to improve query performance——减少复杂 Join 以提升查询性能形成呼应索引表本质上是以空间换时间的工程化手段。6.3 与数据库索引数据结构的关系仓库文档 data/guides/8-data-structures-that-power-your-databases.md 介绍了数据库底层常用的索引数据结构有助于理解 Index Table 之上的实现机制Skiplist常见的内存索引Redis 使用Hash indexMap数据结构的常见实现SSTable不可变的磁盘 Map 实现LSM treeSkiplist SSTable写吞吐高B-tree磁盘友好读写性能稳定Inverted index文档索引Lucene 使用Suffix tree字符串模式搜索R-tree多维搜索如最近邻。Index Table 通常配合这些底层索引结构落地附加表可以按查询键建立 B-tree 或 Hash 索引从而在大型数据集上做到快速定位。参考阅读data/guides/8-data-structures-that-power-your-databases.md、data/guides/7-must-know-strategies-to-scale-your-database.md七、Sharding把数据拆开摊到更多机器上7.1 核心思想Sharding 是一种数据分区模式将数据切分为更小、更易管理的分片shards每个分片可以存储在不同的数据库服务器上。原文档指出它的两大目的提升扩展性scalability把数据分布到多台机器提升性能performance将负载分散到多台服务器支撑更多用户与事务。它在高流量high-volume应用中尤为有效是**水平扩展horizontal scaling**的核心手段。7.2 为什么要分片三大驱动力data/guides/a-crash-course-in-database-sharding.md 把分片的动机归纳为三个直白的痛点单机数据量过大一台数据库服务器能容纳的数据是有限的单机请求量过大一台服务器能处理的请求数有限延迟升高数据增长后查询延迟随之上升。7.3 分片键与分片算法分片落地需要两个核心要素见 data/guides/a-crash-course-in-database-sharding.md分片键Sharding Key表中决定数据如何分布到各分片的列分片算法依据它来判定某行数据应落入哪个分片分片算法Sharding Algorithm依据分片键决定行归属的逻辑。仓库文档归纳了三种经典算法data/guides/a-crash-course-in-database-sharding.md 与 data/guides/key-concepts-to-understand-database-sharding.md 相互印证算法原理示例Range-based基于范围按分片键的连续范围切分用户 ID 1–1000 在 shard 11001–2000 在 shard 2Hash-based基于哈希对分片键做哈希取模shard_id hash(user_id) % num_shardsDirectory-based基于目录用查找表目录映射分片键到分片位置类似电话簿的目录路由7.4 分片的三种落地方式data/guides/a-crash-course-in-database-sharding.md 还区分了三种实现层级应用层分片应用自己决定每个查询走哪个分片中间件分片在应用与数据库之间加一层中间件处理分片逻辑数据库原生分片数据库系统本身内置分片能力。7.5 分片的收益与代价data/guides/vertical-partitioning-vs-horizontal-partitioning.md 从路由算法视角做了补充水平分区即通常所说的分片它把一张表按行拆成多张更小的表每张表列数相同、行数更少收益便于水平扩展可以不断加机器分摊负载缩短响应时间查询只扫更少的行结果返回更快。代价drawbacksORDER BY等全局排序变复杂通常需要从多个分片取数后在应用层归并排序分布不均hotspot某些分片的数据量远大于其他分片形成热点——这正是 data/guides/handling-hotspot-accounts.md 讨论的支付场景痛点如大促时商家账户被大量并发更新行锁成为瓶颈需要限流、拆分账户、缓存先行等优化手段。7.6 一致性与分片键选择的延伸此外data/guides/a-crash-course-in-database-sharding.md 明确列出分片的四大挑战复杂度上升基础设施与应用代码都变复杂数据分布分片键与算法选择直接决定数据是否均匀、性能好坏跨分片 Join 与事务跨分片操作难度大可能需要分布式事务管理再分片Resharding分片方案上线后要变更是复杂且耗时的过程。关于均匀分布还可延伸阅读 data/guides/consistent-hashing.md——一致哈希正是为了解决简单取模在节点增减时引发大量数据迁移而设计的分布式数据分布方案被 Amazon DynamoDB、Apache Cassandra、Discord、Akamai CDN 等大规模系统采用。参考阅读data/guides/a-crash-course-in-database-sharding.md、data/guides/key-concepts-to-understand-database-sharding.md、data/guides/vertical-partitioning-vs-horizontal-partitioning.md八、如何选择与组合实战决策清单这 6 种模式没有银弹选择取决于你的读写比例、数据规模、一致性要求与团队复杂度预算读多写少、延迟敏感优先考虑Cache Aside配合 Write Around 写策略把热点数据推到更快的存储层复杂聚合查询拖垮报表引入Materialized View预计算结果或配合Index Table为高频查询建宽表读写需求差异极大采用CQRS将读写模型解耦各自独立优化、独立扩展需要审计、回放与状态重建采用Event Sourcing把事件流当作唯一事实来源常与 CQRS 组合使用单机数据量或请求量逼近上限走向Sharding提前规划好分片键与算法并警惕热点分片与跨分片事务组合演进路径单一模式往往不够典型的大型系统会按Cache Aside → Index Table / Materialized View → CQRS Event Sourcing → Sharding的阶梯逐步叠加。所有结论均可在本仓库对应文档中溯源验证六大模式的原始定义见 data/guides/how-do-we-manage-data.md缓存写策略的配合见 data/guides/top-5-caching-strategies.md数据库扩展策略全景见 data/guides/7-must-know-strategies-to-scale-your-database.md分片算法与挑战见 data/guides/a-crash-course-in-database-sharding.md事件溯源案例见 data/guides/how-do-we-incorporate-event-sourcing-into-the-systems.md。掌握这六种模式你就能在面试和真实项目中针对不同数据特征给出有理有据的架构方案。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐Video2X 视频超分辨率与补帧指南免费把 360P 老片拉到 4K、帧率变丝滑Video2X 视频超分辨率与补帧指南免费把 360P 老片拉到 4K、帧率变丝滑 Video2X 是一个机器学习视频超分辨率与补帧框架它用 Vulkan音视频视频处理图像处理深度学习Redis 十大实战场景深度解析从缓存到分布式锁的 System Design 101 仓库指南Redis 十大实战场景深度解析从缓存到分布式锁的 System Design 101 仓库指南 Redis 常被简单地当作缓存来使用但它的能力远不止于后端文档教程Video2X基于机器学习的视频超分辨率与帧插值工具Video2X基于机器学习的视频超分辨率与帧插值工具 在数字视频处理领域低分辨率视频的增强和帧率提升一直是技术挑战。Video2X作为一个基于机器学习的开源音视频视频处理图像处理深度学习上一篇GBFR Logs实战指南4个阶段把Relink伤害统计用到极致下一篇Weave Router前端仪表盘深挖6个关键点看懂Next.js管理界面的实现结构创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考