分布式与高并发

容量评估、分布式锁、数据一致性与消息队列。

从哪里开始

先读容量评估，知道系统能扛多少；再按「锁 → 一致性 → 异步化」读分布式锁、订单一致性与延时任务。远程调用的超时与重试（先读超时分层，再读重试放大），接在订单一致性之后读。

文章

01容量评估与秒杀设计吞吐拐点实测、按最难扩的那层倒推容量、秒杀的流量漏斗与限流降级→02分布式锁的三种实现数据库、Redis、ZooKeeper 的失效方式；误删与续期实测→03分布式锁与并发控制实战锁与事务的先后顺序实测、防重复提交三层防线、能不用锁的场景→04订单、库存与数据一致性主键与订单号设计实测、状态机条件更新、幂等键、库存扣减与对账→05订单号重复了：雪花算法依赖的三件事时钟回拨 5 毫秒重复 500 个，重启后检查失效；机器号按 IP 截取或哈希会相同；一毫秒超过 4096 个时回绕；跨实例不严格有序→06一次 HTTP 调用超时了，对方到底执行了没有connectTimeout 管到 TLS 握手、请求超时只管到响应头；超时之后重试为什么需要幂等键→07每层都重试三次，最底下的服务收到二十七倍请求重试相乘与超时倒挂的实测；只在一层重试、10% 重试预算、传递截止时间→08请求在哪一跳分流，响应就走哪条路吗重定向、DNS 缓存、HTTP 与 TCP 代理的地址可见性；Nginx 显式允许非幂等重试后，POST 到达两个后端→09十个实例里一个变慢，十分之一的请求都超时了轮询把请求平均分给变慢的实例；按在途请求选择能避开它，却把 43% 的请求送给快速失败的实例；失败摘除、健康检查看不到的两种故障→10给慢请求再发一份，系统反而被压垮了负载一半时备份请求把 p99 从 300 ms 降到 40 ms；负载 89% 时 98% 的请求都发了备份、p50 到 10 秒；5% 的预算让它稳定→11下游挂了一分钟，熔断器始终没有打开默认要攒够 100 次调用才计算失败率；半开只放行 10 个，不返回就卡住；业务异常默认算失败；30 秒才返回不算慢；两个接口共用时互相牵连→12延时任务的六种实现定时扫表、ZSET 延时队列精度实测、RocketMQ 定时消息与兜底设计→13分库之后的关联查询五种做法的实时性与代价；N+1 与批量查询实测差 31 倍→14RabbitMQ 跨集群方案Shovel 与 Federation 的消息流向差异、选型与排查要点→15写入、复制、提交、读取不是同一个状态etcd 3.7.2 三节点分区实测：少数派节点写入与线性一致读失败、可串行读返回旧值；原 leader 被隔离后下台、多数派以更高 term 选主→16两阶段提交与 TCC准备好的 XA 分支在协调者消失、数据库重启后仍持有行锁；只提交一半时要靠协调者的决定；TCC 的空回滚、悬挂与重复确认→17W+R>N 之后还缺什么版本比较、失败写入被读到、时钟偏差下的最后写入获胜、版本向量、宽松 quorum 与读自己的写→18数据怎样移动，决定了执行计划的边界Spark 4.2 的 Exchange、局部聚合、热点分区、加盐与显式缓存；只按执行计划和结果等价性判断→19任务恢复成功，在线结果就正确了吗Flink 2.3 的单机 checkpoint 恢复；内部状态与外部副作用；特征事件时间和在线可用时间的差别→20一致性哈希减少了迁移，没有解决热点10 万个键：取模扩容迁移 90.8%，哈希环负载 2.26 倍，虚拟节点与有界负载，单个热点键→

相关专题

• 缓存 — 高并发读的第一道防线
• 消息与流处理 — Kafka 投递语义与幂等消费
• Domain Driven Kit · Seata — 分布式事务跨服务传播的一个实现