-
改个字段要动四个服务:分布式单体避坑复盘
我们把一个几十万行的老单体"成功"拆成十几个微服务,上线时还挺有成就感,可没过几个月就发现不对劲:产品提了个不大的需求——给订单加个备注字段,放单体里半天的活,如今却要同时改订单、用户、通知、聚合查询四个服务,四个仓库四个团队,还因为链式依赖必须按顺序一起上线,排期排了一周半、上线那晚四拨人全在线上盯着。我统计了过去两个月的需求,几乎没有一个能在单个服务里闭环完成的,本该提速的…- 2
- 0
-
熔断降级完全指南:从一次"一个下游服务慢了、整个系统跟着雪崩"看懂熔断器
2020 年我维护一个电商的商品详情服务。它要做的事很简单:用户打开一个商品页,这个服务把商品基本信息、价格、库存,还有一项商品评价聚合起来返回。评价这块数据不在我这个服务里,它在另一个独立的评价服务上,我得调用它把评价数据取回来拼进商品详情。第一版我做得很直接:处理每个请求时同步地去调用评价服务,等它返回了再把数据拼好返回给用户。本地测试上线初期一切正常。直到有一天评价服务出了问题——不是挂掉而…- 2
- 0
-
消息队列削峰完全指南:从一次"秒杀活动瞬间把数据库打挂"看懂异步削峰
2021 年我做一个电商的秒杀功能。第一版做得很直白:用户点立即抢购,后端就同步地把这一整套流程跑完——校验库存、扣减库存、创建订单、写订单表、扣用户余额,全部做完才给前端返回抢购成功。平时测试一切正常响应飞快。可活动真正开始的那一秒系统崩了:活动开始前接口每秒几十个请求,活动开始那一刻每秒请求数瞬间冲到几万,这几万个请求每一个都触发了那套同步流程同时挤进数据库,连接池瞬间被占满,后面的请求全部排…- 0
- 0
-
接口幂等设计完全指南:从一次"网络重试把用户扣款扣了两次"看懂幂等
2019 年我做一个电商的下单支付接口,逻辑很直白:用户点提交订单,后端创建一条订单记录,从余额里扣钱,返回订单号。本地测试一切正常,上线后也好好的。直到客服转来一个投诉:一个用户只下了一单却被扣了两次钱。我查日志发现这个用户的下单接口在几秒内被调用了两次,参数一模一样,数据库里多了两条几乎相同的订单,扣款也执行了两遍。我第一反应是用户手抖点了两次,可继续查下去发现根本不是——很多重复请求用户只点…- 2
- 0
-
缓存穿透击穿雪崩完全指南:从一次"加了缓存数据库反而被打挂"看懂三大缓存问题
2020 年我维护一个商品详情服务,最初每个请求都直接查数据库,流量一大数据库就吃力。我给它加了一层 Redis 缓存:查询时先看缓存,命中就直接返回,没命中再查数据库、把结果写回缓存。上线后命中率稳定在 95% 以上,数据库负载降到原来的零头,我以为加了缓存数据库就高枕无忧了。可后来接连出过三次事故每次数据库都被打挂:第一次有人写脚本拿一堆不存在的商品 ID 狂刷,这些 ID 数据库查不到缓存也…- 0
- 0
-
接口限流完全指南:从一次"活动一开服务就被瞬时流量冲垮"看懂限流算法
2021 年我维护一个电商下单服务,平时流量平稳,我从没为它能扛多少操过心。直到运营搞了一场大促,海报一推送出去,大量用户在同一分钟涌进来抢购,我盯着监控看着请求量像火箭一样窜起来,然后服务就崩了。不是变慢是直接崩:接口大面积超时,数据库连接被瞬间占满,实例被一个个判定不健康踢出负载均衡,被踢掉的实例那份流量又分摊到剩下的实例上,一场标准的雪崩。我第一反应是加机器,可扩容要时间等新实例起来高峰早过…- 0
- 0
-
数据库连接池完全指南:从一次"流量一高数据库就报 Too many connections"看懂连接池
2022 年我写一个 Web 服务,处理数据库连接的方式是每个请求进来就 connect 建一个新连接,请求处理完就 close 关掉,用一个关一个看起来一点毛病没有。本地测试一路绿,小流量灰度也很稳,可真正放量后问题接连砸下来:先是接口整体变慢,而 SQL 本身只有几毫秒;然后是高峰期服务大面积报 Too many connections,数据库不再接受新连接。我第一反应是让运维调大数据库最大连…- 0
- 0
-
分布式锁完全指南:从一次"扩容后对账任务跑了三遍、结算被重复打款"看懂分布式锁
2023 年我维护一个对账定时任务,每天凌晨核对订单和支付流水、生成结算单、发结算邮件。单实例跑了大半年稳稳当当,直到运维把服务从 1 个实例扩容到 3 个,第二天就出事:同一用户收到三封结算邮件,有几笔结算被重复打款。翻代码一行 bug 都没有,盯着部署结构才反应过来:定时任务代码被原封不动部署到 3 个实例上,凌晨那一刻 3 个实例各自都跑了一遍。我以为代码里加了 Lock 就并发安全,真相是…- 0
- 0
-
接口幂等性完全指南:从一次"网络抖动让用户被扣了两次款"看懂幂等设计
2023 年我负责一个支付下单接口,扣余额、生成订单、返回成功。测试一路绿,上线几个月后客服转来投诉:一个用户只买了一次,余额被扣两次,订单列表躺着两笔一模一样的订单。翻日志才发现那个请求在服务器上确确实实被完整执行了两次。问题不在我的逻辑,在它之外:用户网络抖了一下,第一次请求其实已处理完,但响应在回程丢了,前端超时自动重发,第二次又被老老实实执行了一遍。我以为接口自己不写 bug 就不会重复扣…- 0
- 0
-
限流算法完全指南:从一次"促销把数据库打挂"看懂固定窗口、滑动窗口、令牌桶
2022 年我负责一个商品详情接口,平时扛得很轻松。直到一次运营促销,流量几十倍涌入,响应时间从几十毫秒飙到几秒,大面积超时,整个服务雪崩——不只是这个接口,同服务里别的功能全挂了。问题不是流量本身,是我的服务对"一瞬间涌进多少请求"毫无防备。我加了个固定窗口计数器每秒限 1000,本地完美,下一次促销系统还是被打出问题。我一直以为限流就是数个数够了就拒绝,真相是限流是一整套关…- 0
- 0
-
CAP 与 BASE 完全指南:分布式系统的一致性权衡
CAP 定理是分布式系统里最有名也最被误解的理论。"CAP 三选二" 这个口诀人人会背,但真要解释"为什么不能同时满足"、"P 不能放弃是什么意思"、"NoSQL 是 AP 还是 CP"、"BASE 和 ACID 怎么权衡",大多数工程师就开始打结。这篇文章把 CAP / PACELC / BASE…- 0
- 0
系统设计
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×