Hyperf如何保证缓存与数据库的双写一致性_采用延迟双删或Canal解析-php教程-PHP中文网

延迟双删不能简单用sleep实现，须用异步任务+延迟执行，携带版本标识并确保幂等；canal需独立消费服务、生成幂等id、校验数据有效性，二者协同可实现毫秒级准强一致性。

hyperf如何保证缓存与数据库的双写一致性_采用延迟双删或canal解析

Hyperf 本身不内置双写一致性保障机制，它只提供 hyperf/redis 和 hyperf/database 这两个基础能力。一致性必须由业务层显式设计，不能依赖框架自动兜底。延迟双删和 Canal 是两种不同层级的解法：前者是应用内同步控制，后者是脱离应用的异步解耦方案。选哪个，取决于你对实时性、运维复杂度和系统侵入性的容忍边界。

延迟双删在 Hyperf 中怎么写才真正生效

延迟双删不是“删→等→再删”三行代码就完事，关键在“等”的时机是否覆盖了读请求回填缓存的窗口期。

sleep(0.2) 或 usleep(200000) 是错的：阻塞当前协程，影响吞吐，且无法应对跨进程/多实例场景
正确做法是用异步任务 + 延迟执行，例如通过 hyperf/task 或消息队列（如 hyperf/amqp）投递一个带延迟的删除任务
删除动作必须携带原始 key 和版本标识（比如 user:123:v2），避免旧任务误删新数据
如果使用 Redis 的 EXPIRE 配合，建议设置比业务平均读耗时长 200ms 以上的过期时间，再辅以二次删除

示例伪代码（基于 hyperf/task）：

Hyperframes Creative

HyperFrames视频非动画创意指导，包括设计规范（frame.md/design.md）处理、配色、字体设计、旁白及节奏规划等。

下载

use Hyperf\Task\TaskExecutor;
<p>// 更新数据库后
Db::table('users')->where('id', $id)->update(['name' => $newName]);</p><p>// 异步触发第一次删除
TaskExecutor::async(function () use ($key) {
Redis::del($key);
});</p><p>// 异步触发延迟第二次删除（500ms 后）
TaskExecutor::async(function () use ($key) {
\co::sleep(0.5);
Redis::del($key);
});</p>

Canal 在 Hyperf 项目中不是“接入就行”，而是要重写消费逻辑

Canal 解析 MySQL binlog 是旁路方案，Hyperf 应用只是消费者之一。它不解决“谁来保证 Canal 消费不丢、不重、不乱序”。

不要直接在 Canal 消费端调 Redis::del($key)：如果消费失败或重复，会导致缓存被误删或漏删
必须为每条 binlog 事件生成幂等 ID（如 db:user:123:update:20260519210512345），并记录到本地表或 Redis 中做去重
删除缓存前，先查一次数据库确认该记录是否仍有效（防止逻辑删除被当成物理删除）
推荐把 Canal 消费封装成独立服务（非 Hyperf），用 HTTP 或 RPC 通知 Hyperf 实例执行缓存操作，避免 binlog 消费与业务逻辑强耦合