定时任务从 Quartz 搬出来的契机 老系统用 Quartz 集群，任务一多就出现重复触发，两台机器各跑一遍，数据算重了还得手工修。排查发现是 Quartz 的数据库锁在高峰期没兜住。今年做调度中台，我在 XXL-JOB 和 Elastic-Job 之间选，两者都能解决分布式场景，但设计取向不同，
上线第二天：生成了两个一样的订单号 十二月十号，我们把自增主键换成了 Snowflake 生成分布式 ID。上线第二天，测试同学在日志里发现了重复： 2020-12-11 10:22:31.114 WARN IdGenerator - 检测到时钟回拨, workerId=3, lastTimest
刚上读写分离，客服就收到投诉了 十一月初，我们把订单库做了读写分离：一主两从，写走主库，查走从库。用 ShardingSphere-JDBC 5.0.0-alpha（当时叫 Sharding-JDBC），配置很简单： spring: shardingsphere: datasource:
方案评审上，我们为一个超时场景吵了一小时 5 月初做支付回调的改造，评审会上卡在一个问题上：调用支付网关的查询接口超时了，这笔订单该标记为成功、失败，还是"处理中"？ 一派说标记为失败，让用户重新支付；另一派说标记成成功，反正钱已经扣了；还有人说先挂着，等定时任务去查。三种意见都有道理，谁也说服不了
