每次发版都有一小撮用户报"请求失败"，比例不高，但稳定复现——问题不在代码，在滚动发布的那几十秒：实例已经被摘掉流量，手里还没处理完的请求却被直接杀死；或者注册...

下单要同时扣库存、建订单、加司机余额，三张表分在三个库——跨库更新没有本地事务可用，这是分布式事务问题真正的起点。三马代驾的资金链路踩过"钱扣了单没建"的坑，本...

凌晨两点的告警里，最让人摸不着头脑的一种是 Deadlock found when trying to get lock——两个事务互相等待对方释放锁，数据库只...

一次派单请求要串起派单、计价、消息推送三个下游。任何一个卡住，用户的请求就跟着卡住。没有超时的调用是最大的风险，而有超时没重试、有重试没退避、有熔断没降级，都会...

更新一条数据，顺手把缓存删掉——几乎所有团队都是这么写的。但当三马代驾的司机结算金额在缓存里"旧了一分钟"被投诉时，我们才把缓存与数据库的一致性当成一个正式问题...

定时任务是最容易被低估的组件：写个 cron、循环跑一遍，看起来谁都会。但在三马代驾的生产环境里，超时关单、对账补偿、报表统计全部跑在定时任务上，一旦重复执行或...

派单、支付、结算这几个关键动作，在三马代驾的架构里全都依赖消息队列解耦。队列一抖，丢一条消息，用户侧看到的就是"订单状态卡住"。这篇文章把我们在生产上踩过的消息...

三马代驾的订单表在两年里从 300 万行涨到 2.1 亿行，DBA 第一次提"该分表了"时被我们驳回了——那时候慢查询占比不到 0.2%。半年后大促一来，单表写...

三马代驾在分布式锁上踩过的坑足够写一篇事故集：先用 SETNX + EXPIRE 两条命令，进程崩溃在两句之间导致锁永远不释放；后来改原子命令，又因为业务执行超...

三马代驾的一次下单要穿过网关、风控、定价、派单、支付、通知六个服务，外加两个 MQ 和三次数据库写。有一次司机反馈"付了钱没收到接单确认"，两个值班同学翻日志翻...

三马代驾经历过一次"最贵的教训"：某年跨年活动前，所有人凭感觉拍了一个数——"峰值撑住 3 倍日常就行"，结果跨年夜第一个小时实际流量是日常的 7.2 倍，派单...

三马代驾的缓存曾经在早高峰出过一次小事故：司机端"附近车辆"接口 5 分钟内 RT 从 30ms 涨到 900ms，数据库连接池一度打满。事后复盘，起因是一个运...

三马代驾的派单服务去年有过一段黑暗期：高峰期总有司机反馈"点接单转圈"，监控上数据库 CPU 却不算高。后来一条慢日志把问题钉死了——派单候选查询在某个城市走了...

三马代驾去年吃过一次发布事故：结算服务带着一个空指针直接全量上线，五分钟内所有司机的当日账单接口报错，回滚又因为配置不兼容花了二十分钟。那次之后我们把"能不能灰...

去年双十一前夜，三马代驾的派单接口被脚本刷了四十多万次：不是竞争对手，是有人拿脚本批量领取优惠券。那次事故没宕机，但正常司机的抢单请求被拖慢了两秒。之后我们把防...

支付回调是代驾系统里容错率最低的入口：它直接决定钱有没有到账、券有没有退、订单能不能往下走。三马代驾接入第三方支付的第一年，吃过两次大亏——一次是渠道重发通知导...

网约车业务里最容易出诡异 bug 的地方，往往不是高并发链路，而是订单状态。三马代驾早期的订单服务里，状态判断散落在十几个 service 中，"司机取消之后支...

代驾履约的临门一脚是派单：乘客发单之后，系统要把单子递到最合适的司机手上。递得不准，司机绕路过来乘客已经取消；递得不快，池子里的单没人接直到超时。三马代驾的派单...

拉新补贴是代驾平台增长最快也最烧钱的模块，同时是黑产最集中的入口。三马代驾在补贴风控上迭代了三个版本，第一版只靠手机号黑名单，被薅到怀疑人生；现在跑的这版把设备...

前一篇聊了三马代驾系统的整体架构和三级派单，这次往细里抠一层：司机端和乘客端挂在 Netty 长连接上，手机进电梯、切后台、弱网闪断都是家常便饭，连接断了之后怎...