计数器系统设计方案对比
点赞数、阅读量、粉丝数——这些计数器是社交系统的血液。如何设计一个高性能、高可靠的计数器系统？ 一、计数器的业务场景 1.1 点赞数——每次点赞 +1 1.2 阅读量——每次访问 +1（去重？） 1.3 粉丝数——关注/取关 +1/-1 1.4 业务特点——写多读少，允许一定延迟 二、MySQL 自增的局限 2.1 热行竞争——行锁成为瓶颈 2.2 UPDATE 的 TPS 上限 三、Redis Hash 方案 3.1 一个 Hash 存储多条记录的计数——HINCRBY counter:post:{id} likes 1 3.2 优点——内存操作、原子性 3...
海量数据分页方案对比
LIMIT 1000000, 20 需要扫描 100 万行再丢弃，这就是 OFFSET 分页越往后越慢的根本原因。 一、OFFSET 分页的问题 1.1 原理——LIMIT offset, count → 扫描 offset + count 行 1.2 offset=0：扫描 20 行 1.3 offset=1000000：扫描 1000020 行 1.4 为什么不能跳过前面的行——B+Tree 有序但非跳跃 二、方案 1：游标分页（推荐） 2.1 原理——WHERE id > last_id ORDER BY id LIMIT 20 2.2 使用最后一条...
大促技术准备清单
双十一的技术准备不是拍脑袋扩容，而是一系列严谨的工程流程：压测、扩容、演练、监控。 一、大促前 30 天——压测 1.1 全链路压测——模拟真实流量 1.2 单接口压测——找到每个接口的极限 QPS 1.3 混合压测——按真实比例混合 1.4 瓶颈定位——CPU/内存/DB/Redis/带宽 1.5 压测报告模板 二、大促前 15 天——扩容 2.1 服务扩容——根据压测结果计算所需实例 2.2 数据库扩容——升配/加从库 2.3 Redis 扩容——分片/升配 2.4 带宽扩容 2.5 弹性伸缩策略配置 三、大促前 7...
并发工具类对比与实践
一个接口需要调用 3 个微服务，串行 300ms。用 CompletableFuture 并行调用只需 120ms。 一、场景描述 1.1 商品详情页——需要商品信息、库存、评价、推荐 1.2 串行调用——逐个等待，时间累加 1.3 并行调用的收益——总时间 = max(每个调用的时间) 二、CountDownLatch 2.1 原理——计数器，主线程等待所有子任务完成 2.2 代码示例——3 个线程并行获取数据 2.3 缺点——无法获取返回值、只能使用一次 三、CyclicBarrier 3.1 原理——所有线程到达 barrier 后一起继续 3.2 与 Count...
高并发热点账户处理方案
平台补贴账户、商户收款账户——这些”热点账户”被大量并发更新，数据库行锁成为瓶颈。如何设计记账方案？ 一、热点账户问题的本质 1.1 什么是热点账户——频繁被更新的账户（如平台补贴账户） 1.2 数据库行锁的瓶颈——TPS 上限约 500-1000 1.3 业务特点——余额正确性要求极高 二、方案 1：汇总记账 2.1 流水明细实时写入 2.2 账户余额定时汇总——每小时/每天更新一次 2.3 优点——零并发冲突 2.4 缺点——余额不实时 三、方案 2：缓冲记账 3.1 多个缓冲账户——account_0、account_1、…、account_9 3.2 写入时分发...
限流算法与实现
四种经典的限流算法，每种都有适用的场景。从原理到代码实现，一文讲透。 一、为什么要限流 1.1 保护系统——防止流量超过处理能力 1.2 公平性——防止个别用户占用过多资源 1.3 成本控制——第三方 API 调用次数限制 二、固定窗口算法 2.1 原理——在一个固定时间窗口内计数，超过阈值则拒绝 2.2 代码实现——AtomicLong + 定时重置 2.3 临界问题——窗口切换时的”突刺” 2.4 优点——实现简单 2.5 缺点——不够平滑 三、滑动窗口算法 3.1 原理——将窗口细分为多个小窗口，随时间滑动 3.2 代码实现——环形数组 + 时间戳 3.3 Sentinel...
高可用系统设计方案
从单机房到同城双活，再到异地多活——可用性的每一次提升，都伴随着架构的质变。 一、可用性度量 1.1 几个 9——99.9%（3 个 9）→ 年宕机 8.76 小时 1.2 99.99%（4 个 9）→ 年宕机 52.56 分钟 1.3 99.999%（5 个 9）→ 年宕机 5.26 分钟 1.4 可用性 = MTTF / (MTTF + MTTR) 二、单机房高可用 2.1 服务多实例——无单点 2.2 数据库主从——故障自动切换 2.3 限流熔断——防止级联故障 2.4 单机房的局限——机房级故障 三、同城双活 3.1 两个机房——延迟 1-3ms 3....
接口性能优化方法
接口慢了不要只盯着加索引。从代码到架构，性能优化有 10 个层次，越底层收益越大。 一、优化层次总览 1.1 金字塔模型——越往上效果越明显 1.2 优化原则——先测量再优化，从最慢的环节开始 二、层次 1：代码层 2.1 避免循环中的数据库调用 2.2 合理使用并行——CompletableFuture 2.3 减少不必要的对象创建 三、层次 2：SQL 层 3.1 索引优化 3.2 SQL 改写——子查询变 JOIN 3.3 避免 SELECT * 3.4 批量操作——batchInsert 四、层次 3：缓存层 4.1 本地缓存——Caffeine 4.2 分布式缓存——...
IM 系统长连接架构
微信如何保证消息不丢不重、实时到达？从一个简化的 IM 系统设计看长连接、消息可靠性和分布式架构。 一、IM 系统的核心挑战 1.1 实时性——毫秒级消息到达 1.2 可靠性——消息不丢不重 1.3 一致性——多端消息同步 1.4 海量连接——千万级长连接 二、通信协议选型 2.1 短轮询——简单但浪费资源 2.2 长轮询——半实时 2.3 WebSocket——全双工，浏览器原生支持 2.4 TCP 长连接——App 端最优选择 2.5 协议格式——Protobuf 二进制 三、长连接管理 3.1 连接建立——握手 + 鉴权 3.2 Session 管理——userId → c...
Feed 流系统架构设计
朋友圈、微博、抖音推荐流——Feed 流系统的设计是所有社交产品的核心。推模式、拉模式、推拉结合，怎么选？ 一、Feed 流的业务模型 1.1 什么是 Feed 流——关注的人发布的内容按时间排列 1.2 核心操作——发布内容、读取 Feed、关注/取关 1.3 粉丝数与内容频率的影响——大 V 的挑战 二、纯推模式（Push） 2.1 发布内容 → 写入所有粉丝的收件箱 2.2 读取 Feed → 读自己的收件箱 2.3 优点——读取极快 2.4 缺点——大 V（千万粉丝）写扩散巨大 2.5 优化——大 V 的粉丝异步推送（队列 + 批量） 三、纯拉模式（Pull） ...