在后台开发领域，高并发的扣减一直是比较热门的话题。在各类技术博客、大会分享以及面试问题中，出现频率都非常高，可见它的重要性和技术知识点的密集性。从本讲开始，我将由浅入深、由简至繁地介绍三种能够支撑不同并发量级的解决方案，首先介绍的是基于纯数据库实现的扣减方案。 什么是扣减类业务 看到这个标题很多人可
发布于 2025-12-25
在上一讲的实现方案里我们讨论了采用纯数据库的扣减实现方案，如果以常规的机器或者 Docker 来进行评估，此方案较难实现单机过万的 TPS。之所以介绍，是想告诉你，架构是面向业务功能、成本、实现难度、时间等因素的取舍，而不是绝对地追求高性能、高并发及高可用等非功能性指标。 另外，在上一讲里介绍的扣减
发布于 2025-12-25
本模块的前几讲里围绕着分库分表，以及外部依赖治理的话题进行了讨论，通过上述方案来提升写业务的高可用和高性能。 但分库分表以及无状态存储也带来了另外一个问题，即数据按路由规则分散后，如何满足无路由字段的多维度富查询？ 异构定制化实现 在“第 8 讲”，我介绍了一个关于订单模块的分库分表案例，我们先回顾
发布于 2025-12-25
在上一讲里，我介绍了如何实现分库分表的架构方案，以及如何解决业务不断发展所产生的数据容量的问题。 但是分库分表只解决了容量的问题，并没有解决写服务的高可用问题，或者说分库分表在一定程度上增加了系统故障的概率。从概率上看，原有的单库架构有 50% 的可能性会发生数据库故障。但如果是 5 个分库，则会有
发布于 2025-12-25
本模块的前几讲讨论了在存储上如何分库分表、如何构建无状态存储集群，来打造一个高可用的、支持海量数据存储的写业务的系统架构。 在写业务的系统架构里，除了需要关注存储上的高可用，写链路上的各项外部依赖的管控同样十分重要。因为即使存储的高可用做好了，也可能会因为外部依赖的不可用进而导致系统故障。比如写链路
发布于 2025-12-25
在上一模块里，我们讲解了如何使用懒加载、全量缓存等机制构建一个能够支撑百万并发的读服务，同时介绍了如何使用自动化回放来提升读服务的测试与回归效率，直接跳读到本模块的同学有空可以返回去学习一下。 在本模块的四讲里，将会介绍如何构建与读服务有着相反差异的写服务。并发百万的读服务每一次请求都不会产生新数据
发布于 2025-12-25
在本模块的前四讲里，我向你介绍了可以直接落地的、能够支撑百万并发的读服务的系统架构，包含懒加载缓存、全量缓存，以及数据同步等方案的技术细节。 基于上述方案及细节，你可以直接对你所负责的读服务进行架构升级，将性能进一步提升。在升级系统架构时，有一个很重要的点容易被研发同学忽略——只评估了升级的工作量，
发布于 2025-12-25
在“04 讲和 05 讲”里，我们介绍了基于 Binlog 实现的全量缓存的读服务，以及如何实现一个低延迟、可扩展的同步架构。通过这两讲的学习，你可以构建出一个无毛刺且平均性能在 100ms 以内的读接口。对缓存进行分布式部署后，抗住秒级百万的 QPS 毫无压力。不管是在面试还是在实战中，关于“如何
发布于 2025-12-25
在上一讲里，我介绍了基于 Binlog 完成数据同步的全量缓存的读服务架构方案，可以实现平均性能在一百毫秒以内的高可用方案。此方案不仅可以满足缓存同步的实时性要求，还能够降低同步的复杂度，以及解决分布式事务问题。 那是不是上述方案已经十分完善，可以直接进行落地复用了呢？其实还有很多重要的点待明确。在
发布于 2025-12-25
上一讲我们介绍了一个简单易实现，且成本较低的高性能读服务方案及其升级方案，但其中仍有两个问题暂未完全解决： 第一个问题是为了保证缓存更新实时性而带来的分布式事务的问题； 第二个问题是懒加载导致的毛刺问题。 在本讲里，我将针对上述两个问题，和你一起利用全量缓存打造一个无毛刺、平均性能在 100ms 以
发布于 2025-12-25
