同事问：订单状态怎么倒着走了 做微服务改造时，订单状态变更要通过 MQ 广播给下游（积分、优惠券、物流、通知）。上线一周后，物流组的同事找过来："你们发的消息顺序不对，我这边先收到'已发货'，后收到'已付款'，状态机直接报错。" 我看了一眼他的日志，确实是反的： 14:03:21.114 收到订单消
运营找上门：同一笔积分被发了两次 七月的一个下午，运营拿着工单来找我："用户 88372 投诉，说下单后积分到账两次，多领了 300 积分。" 我第一反应是代码里有循环或者被调用了两次。翻了消费日志，同一个 msgId 确实处理了两遍： 2020-07-05 14:22:31.117 [Consum
面试官问：你们的分布式锁为什么选 Redis 不选 ZK 七月底跳槽面试，被问到分布式锁。我说我们用 Redis + Redisson。面试官追了一句："Redis 锁在主从切换时会丢锁，你们业务能接受？为什么不用 Zookeeper？" 我当时答得挺虚的。回来把三种实现都搭了一遍，用 JMeter
高并发系统限流方案：Sentinel 实战 在微服务架构中，流量控制是保证系统稳定性的关键技术。Sentinel 是阿里巴巴开源的流量控制框架，提供了丰富的限流功能。 Sentinel 核心功能 流量控制 基于 QPS 的直接限流 基于并发数的限流 基于匀速排队的限流 熔断降级 慢调用比例熔断 异常
早上八点，消费积压告警：lag 320 万 6 月 1 号早上八点十几分，钉钉机器人开始刷屏：ORDER_EVENT_TOPIC 的消费 lag 突破 300 万，还在涨。 这个 topic 是订单事件流，下游有 5 个消费者组：风控、数据同步、搜索索引、积分、客服。lag 涨到 320 万意味着这
财务对账少了 38 笔，消息不知道去哪了 1 月 10 号早上，财务那边甩过来一张表：12 月的积分发放记录比订单表少了 38 笔。我们发积分是下单成功后发一条 ORDER_PAID_TOPIC，积分服务消费它加积分。订单在，积分没加，说明消息在中途没了。 38 笔，占当月 47 万订单的万分之零点
第一次把单体拆出 Dubbo 服务，踩了五个坑 11 月，组里决定把用户中心从订单系统里拆出来，做成独立的 Dubbo 服务。这是我第一次真正搭分布式服务，之前只在本地 demo 里跑过。 技术选型是 Dubbo 2.7.3 + Zookeeper 3.4.14 + Spring Boot 2.1.
短信服务商挂了 23 分钟，我们丢了 1247 单 那是去年 11 月的事。我们合作的短信服务商机房故障，接口全部超时。按理说短信发不出去不是什么大事，但那天下单成功率从 99.9% 掉到了 63%，23 分钟里少成交了 1247 单。 原因很简单：下单接口里同步调用了发短信，短信服务超时 30 秒
方案评审上，我们为一个超时场景吵了一小时 5 月初做支付回调的改造，评审会上卡在一个问题上：调用支付网关的查询接口超时了，这笔订单该标记为成功、失败，还是"处理中"？ 一派说标记为失败，让用户重新支付；另一派说标记成成功，反正钱已经扣了；还有人说先挂着，等定时任务去查。三种意见都有道理，谁也说服不了
