分布式

大型电商的订单系统，如何设计分库分表方案？ 回答 大型电商的订单系统的分库分表，主要考虑的就是分表数量、分表字段、分表算法这几个方面。 1、 分库 vs 分表，怎么理解？ 分库、分表、分库分表，他是三

千万级数据量必须分库分表？揭秘几个主流打法！ 回答 不到万不得已，不建议大家直接做分库分表。 优先方案 数据库优化 缓存 分区 数据归档 分布式数据库

MySQL"瘦身"之：分区分表存储原理解密，性能飞起 回答 在Innodb中（8.0之前），表存储主要依赖两个文件，分别是.frm文件和.ibd文件。 .frm文件用于存储表结构定义信息， .ibd文

为什么单表2000万时，要考虑分表？从B+树的角度分析 回答 根据经验来说，单表抗 2000万 数据量时，就要考虑分表了。 那他背后的计算逻辑是什么呢？这个数据是如何计算出的呢？ 1、 B+ 树的高度

揭秘 20W 缓存如何扛 2000W 数据？预热+更新+淘汰+过期 回答 这个问题考查的是Redis的数据预热+更新+淘汰+过期相关的内容。主要从如下几个方面思考。 1. 数据预热 根据实际的业务情况

用 Redis 如何实现朋友圈点赞功能？ 回答 1、功能分析 首先，我们需要分析下朋友圈点赞需要有哪些功能 记录某个朋友圈的点赞数量， 支持点赞数数量的查看， 支持点赞和取消点赞操作。 支持查看哪些人

高并发场景下，优惠券秒杀系统的稳定性与公平性保障 背景 场景： 在“年度超级秒杀”活动中，限量100张（高价值优惠券），活动上线首秒吸引大量用户同时涌入，瞬时峰值QPS达10万次/秒。 核心诉求 服务

高并发扣款指南：如何终结超花危机？ 背景 业务场景 新活动刚开始，会有一段时间的高峰期。 部分用户会利用脚本发起批量操作，导致系统面临以下挑战： 超卖风险：账户余额仅10元，但并发请求可能导致实际扣减

高并发场景下做库存扣减，如何避免超卖和少卖？ 回答 一个典型的高并发场景下的超卖问题。 问题本质： 原子性定义： 有序性定义： 1、数据库 扣减 实现方案： 正常来说，MySQL 的热点行更新最多也就

MySQL 热点数据更新的秒杀级性能优化 回答 库存拆分：将大库存拆分为多个小库存，使扣减动作分散到不同库和表，降低锁粒度提升并发。 优点：实现相对简单。 缺点：存在数据碎片化问题，库存统一调控难度增

设计一个秒杀系统，需要考虑哪些问题？ 参考引用：Java 八股/让你设计一个秒杀系统，你会考虑哪些问题？ 回答 高并发瞬时流量：秒杀时流量瞬间增大，要保证系统稳定可用。 热点数据：如热门商品信息，更新

数据库乐观锁 vs 悲观锁 vs Redis分布式锁：高并发场景下的核心区别与选型指南 回答 1、悲观锁 悲观锁，假设最坏的情况。因此，在数据处理之前先加锁。 主要使用场景 当数据竞争较多，冲突频繁发

用了分布式锁，影响并发怎么办？ 背景 思考：我们在分布式场景下，用了分布式锁，那不是影响了并发度了么。这么做真的合适吗？ 回答 使用分布式锁的目的是什么？防止发生并发？这里的并发是什么并发？ 对共享资

分布式场景下，锁的粒度和事务的粒度，如何控制？ 业务背景 场景：在线电商平台的订单提交与库存扣减系统 用户行为：用户在商品详情页点击「立即下单」后，系统需同时完成以下操作： 创建订单记录：在订单服务中

不用 redis 分布式锁， 如何防止用户重复点击？ 业务背景 场景：业务订单提交系统 用户行为：用户页面点击「提交订单」按钮后，因网络延迟或误操作多次点击，导致同一订单被重复提交至后端。 核心问题：

Redis 的 Zset 回答 ZSet（Sorted Set）内部维护了一个有序的字典，这个字典的元素中既包括了一个成员（member），也包括了一个double类型的分值（score）。 Redi

Redis 大 Key 问题，解决之道 回答 0、BigKey 的定义 表示存储了大量数据的 Key， 表示 Key 的值很大， 表示这个 Key 对应的 value 占用空间很多的情况 1、Redi

Redis 热 Key 问题是什么？如何解决？ Redis 热 Key 问题的解决之道 回答 定义：在同一个时间点，Redis 中的同一个 key ，被大量访问。 热 Key 的主要处理方式： 事前预

数据库和缓存不一致性的问题，如何解决？ 回答 为了保证 Redis 和 数据库 的一致性，肯定要缓存和数据库双写。 业内常见的 3 种方案： 先更新数据库，再删除缓存 延迟双删 cache-aside

缓存穿透/缓存击穿/缓存雪崩 攻防录 参考：什么是缓存击穿、缓存穿透、缓存雪崩？ 参考：缓存的常见问题 回答 缓存穿透 缓存击穿 缓存雪崩 扩展 1、缓存穿透 解决方案一、缓存空值 解决方案二、布隆过