<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>定时任务 on PlumePHP</title><link>https://plumephp.com/tags/%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1/</link><description>Recent content in 定时任务 on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Sun, 19 Mar 2023 08:51:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/%E5%AE%9A%E6%97%B6%E4%BB%BB%E5%8A%A1/index.xml" rel="self" type="application/rss+xml"/><item><title>游戏服务器持久化定时器架构设计</title><link>https://plumephp.com/game-server-durable-timer-architecture-design/</link><pubDate>Sun, 19 Mar 2023 08:51:00 +0800</pubDate><guid>https://plumephp.com/game-server-durable-timer-architecture-design/</guid><description>&lt;h2 id="问题背景"&gt;问题背景&lt;/h2&gt;
&lt;p&gt;游戏里的“稍后发生”比想象中多：建筑升级 8 小时后完成，赛季活动 22 点结算，邮件 30 天后过期，玩家离线 10 分钟后释放房间，Boss 复活需要在多个分片同步。最危险的做法是把这些 timer 全放进进程内存。平时它像个小工具，重启时却变成事故源：任务丢失、重复触发、补偿任务集中打爆数据库。持久化定时器架构的目标是让时间成为可管理的业务资源，而不是散落在各个服务里的 setTimeout。&lt;/p&gt;</description></item></channel></rss>