我们在上一篇文章里面详细讨论了缓存的架构方案，它可以减少数据库读操作的压力，却也存在着不足。比如写操作并发量大时，这个方案并不奏效，那该怎么办呢？我们先来看一个具体的业务场景。 有一个这样的场景：一场超低价预约大型线上活动，在某天9：00-9：15期间，用户可以前往预约详情页半…

在前面的四篇文章中，我们从数据持久化层来聊了一些架构设计方案，来处理数据量大读写缓慢的问题。但是架构设计并不是只有这一方面的设计思路，本篇开始我们来从缓存层面来一起看看如何设计。 在一个电商系统中，存放了50000多条商品数据，每次用户浏览商品详情页时，需要先从数据库中读取数据…

我们知道Elasticsearch（以下简称“ES”）是基于索引的设计，它没办法像MySQL那样使用join查询，所以，查询数据时我们需要把每条主数据及关联子表的数据全部整合在一条记录中。 | ... | ... | ... | ES是一个分布式查询系统，它的每一个节点都是一个…

某 SaaS 客服系统，系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。 面对如此庞大的数据量，跟前面的冷热分离一样，每次客户查询数据时几十秒才能返回结果，即便我们使用了索引、SQL 等数据库优化技巧，效果依…

业务场景一曾经经历过供应链相关的架构优化，当时平台上有一个订单功能，里面的主表有几千万数据量，加上关联表，数据量达到上亿。这么庞大的数据量，让平台的查询订单变得格外迟缓，查询一次都要二三十秒，而且多点

但是实际上，数据库层面的分库分表到底是用来干什么的，他的不同的作用如何应对不同的场景，我觉得很多同学可能都没搞清楚。 假如我们现在是一个小创业公司，注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。 天哪！就这种系统，随便找一个…

为了便于理解，我们通过一个业务场景来入手。 从上表中发现，目前订单数据量已达上亿，并且每日以百万级速度增长，之后还可能是千万级。 面对如此大的数据量，此时存储订单的数据库竟然还是一个单库单表。对于单库单表而言，一旦数据量实现疯狂增长，无论是IO还是CPU都会扛不住。 为了使系统…

分库分表看这一篇就够了：Sharding-Proxy 前言 Sharding-Proxy Sharding-Proxy 是 Apache ShardingSphere 项目的一部分，它是一个透明的数据

ShardingSphere 是 Apache 下的一个开源分布式数据库中间件，提供了 分库分表、读写分离 和 数据治理 的统一解决方案。它支持透明化的数据库分片、动态扩展能力以及与原有应用程序的无缝