网站版面风格表白网站生成器

网站版面风格,表白网站生成器,wordpress 评论等级,关键词优化公司费用多少前言在真实业务中#xff0c;“延时触发”是一类非常常见但又容易被低估的需求#xff0c;例如#xff1a;机票下单后 15 分钟未支付自动取消订单创建后 30 分钟关闭活动开始前 定时推送通知资源锁定一段时间后 自动释放在单机系统中#xff0c;这类需求实现并不复杂#…前言在真实业务中“延时触发”是一类非常常见但又容易被低估的需求例如机票下单后15 分钟未支付自动取消订单创建后30 分钟关闭活动开始前定时推送通知资源锁定一段时间后自动释放在单机系统中这类需求实现并不复杂但在分布式、高并发、可扩展系统中延时消息的设计就变得非常关键。本文将以「购买机票超时未支付自动取消订单」为例循序渐进讲清楚本地延时是如何实现的本地方案的局限在哪里分布式延时消息的几种主流设计方案业界RocketMQ是如何解决延时消息问题的一个可落地的分布式延时消息设计思路业务场景抽象机票超时未支付典型业务流程用户下单购买机票系统创建订单状态为「待支付」系统需要在15 分钟后检查订单如果已支付 → 不处理如果未支付 → 自动取消订单释放座位这本质上是一个“现在 延迟时间 → 执行一段逻辑”的问题本地延时任务的实现方式单机在进入分布式之前先看最基础的实现方式。Timer已不推荐Timer timer new Timer(); timer.schedule(new TimerTask() { Override public void run() { cancelOrder(orderId); } }, 15 * 60 * 1000);问题单线程执行任务异常会影响整个 Timer无法承载高并发ScheduledThreadPoolExecutor推荐ScheduledExecutorService executor Executors.newScheduledThreadPool(4); executor.schedule(() - { cancelOrder(orderId); }, 15, TimeUnit.MINUTES);优点支持线程池API 简单本地可靠性较好本地延时方案的问题虽然ScheduledThreadPoolExecutor很好用但只能用于单机在真实生产环境会遇到问题说明服务重启延时任务直接丢失集群部署多实例无法协调扩容缩容任务归属混乱高并发内存压力大结论本地延时 ≠ 分布式延时从本地延时中抽象可复用的思想虽然本地方案不可直接用于分布式但它给了我们重要启发延时任务 任务 触发时间换句话说我们只要解决两个问题任务存在哪里什么时候被取出来执行分布式延时消息的核心设计思路核心目标可靠存储服务重启不丢任务可水平扩展时间精度可控高吞吐分布式延时消息方案一外部存储 定时扫描设计思路将延时消息存储在外部系统中(orderId, executeTime, payload, status)然后由后台线程周期性扫描SELECT * FROM delay_task WHERE execute_time now() AND status NEW LIMIT 100;架构示意下单 → 写延时任务表 → 定时扫描 → 执行业务优缺点分析优点实现简单可控性强易于理解缺点扫描数据库压力大时间精度有限秒级高并发下性能瓶颈明显适合中小规模系统分布式延时消息方案二Redis 实现Redis ZSet推荐利用 ZSet 的score表示时间戳key: delay:order score: executeTimestamp value: orderId写入延时任务ZADD delay:order 1700000000 order123消费逻辑ZRANGEBYSCORE delay:order -inf now LIMIT 0 100取到后执行业务ZREM删除任务优缺点优点性能极高实现相对简单天然支持排序缺点Redis 内存成本数据持久性依赖 Redis 配置需要处理重复消费、幂等业界使用非常广泛分布式延时消息方案三时间轮Time Wheel核心思想将时间划分为多个“槽位”| 0 | 1 | 2 | 3 | 4 | 5 | ... |每个槽代表一个时间区间任务被放入对应槽位。特点插入和触发复杂度接近 O(1)非常适合大量延时任务局限实现复杂精度有限通常需要多级时间轮Netty、Kafka、RocketMQ 都采用了时间轮思想业界成熟方案RocketMQ 延时消息RocketMQ 的做法RocketMQ不支持任意时间延时而是采用固定等级延时例如Level延时时间11s25s310s430s51m......实现原理简述延时消息写入特殊 Topic使用时间轮 定时调度到期后转发到真实 Topic优缺点优点高性能高可靠生产级方案缺点延时时间不灵活强依赖 MQ一个完整的分布式延时消息落地方案机票推荐组合方案下单 ↓ 发送延时消息Redis ZSet / RocketMQ ↓ 延时到期 ↓ 消费者校验订单状态 ↓ 未支付 → 取消订单关键设计点业务幂等状态二次校验延时消息 ≠ 定时任务失败重试机制总结方案适用场景本地延时单机、简单系统DB 扫描小规模、低频Redis ZSet高并发、灵活延时时间轮超大规模RocketMQ企业级延时消息的本质不是“等多久”而是“何时可靠地执行一次”