1. 为什么 Yii 应用跑着跑着就变慢了——缓存不是“加个开关”而是性能工程的起点你有没有遇到过这样的场景一个刚上线的 Yii 1.1 后台系统首页加载只要 320ms用户反馈“丝滑”三个月后随着订单表涨到 800 万行、商品 SKU 关联字段增加到 17 个、管理员后台开启 5 个实时统计看板同一页面响应时间飙升到 2.4 秒用户开始在工单里写“卡得像在等泡面”。你查数据库慢查询日志发现SELECT * FROM order WHERE status pending这条语句执行了 1.1 秒——但奇怪的是它明明加了status索引EXPLAIN 显示也走了索引。你再查 PHP-FPM 日志发现每次请求平均要执行 47 次 SQL 查询其中 31 次是完全一样的SELECT name, price, stock FROM product WHERE id ?。这时候你才意识到瓶颈不在数据库本身而在重复计算与重复读取。Yii 框架自带的缓存机制就是为解决这类“高频、低变、高开销”的操作而生的——它不是给应用贴金的装饰品而是把“查一次、用十次”的工程逻辑固化进框架生命周期里的基础设施。这和你在热搜里看到的“ubuntu大量内存被cache无法使用”或“flush cache”完全是两回事。Linux 的 page cache 是内核级的 I/O 缓冲属于操作系统资源调度范畴而 Yii 的 CCache、CDbCache、CApcCache是应用层Application Layer的语义化缓存——它缓存的是你明确告诉框架“这个结果在未来 N 分钟内不会变”的业务数据比如用户权限树、地区字典、商品分类导航、甚至是一段渲染完成的 HTML 片段。它不关心内存是否被占满只关心“下次请求来时我能不能跳过数据库查询、跳过对象实例化、跳过模板渲染直接把结果掏出来”。关键词里提到的 CDbCache 和 CApcCache本质是不同存储后端的适配器CDbCache 把缓存数据存在 MySQL 表里适合开发环境快速验证CApcCache 则直连 APCu 扩展的共享内存生产环境首选毫秒级读写。而 CCache 是所有缓存组件的抽象基类定义了set()、get()、delete()、flush()这四个核心契约。真正决定性能上限的从来不是CCache这个名字而是你在什么时机、以什么粒度、用什么键名、存什么内容、设多长有效期——这才是 Yii 缓存的实操核心也是本文要拆解透的全部。2. Yii 缓存组件的底层工作流从 set() 到 get() 的完整链路解析很多开发者以为“调用$cache-set($key, $value, $duration)就完事了”但实际线上出问题时90% 的故障都发生在get()返回 false 或空值之后。要真正掌控缓存必须看清 Yii 在背后做了什么。我们以最典型的CApcCache为例还原一次完整的缓存读写闭环2.1 写入阶段set() 调用背后的三重校验当你执行$cache-set(user_profile_12345, $profileData, 3600);时Yii 并非简单地把$profileData塞进 APCu。它会先做三件事序列化预处理Yii 默认使用serialize()对$profileData进行序列化。如果$profileData是一个包含 PDO 连接、Closure 匿名函数或资源句柄resource的对象serialize()会直接失败并抛出E_NOTICE。这就是为什么你常看到“Serialization of Closure is not allowed”错误——它根本没走到 APCu卡在了序列化环节。解决方案是要么确保缓存对象是纯数组/标量要么重写CCache::setValue()方法改用igbinary_serialize()需安装 igbinary 扩展或 JSON 编码牺牲部分类型信息但更安全。键名标准化Yii 会自动对$key进行前缀拼接。假设你在配置中设置了keyPrefixmyapp_v2_那么实际存入 APCu 的键名是myapp_v2_user_profile_12345。这个设计是为了避免多个 Yii 应用共用同一 APCu 实例时发生键名冲突。但要注意如果你在不同模块里手动拼接了前缀如myapp_v2_user_profile_12345又在配置里再设keyPrefix就会变成myapp_v2_myapp_v2_user_profile_12345导致get()永远找不到数据。有效期转换$duration3600并非直接传给 APCu 的 TTL。Yii 会将其转换为绝对时间戳time() 3600然后作为元数据和序列化值一起存入。这是为了支持“永不过期”0和“负数表示永不过期”的语义。APCu 本身不支持负数 TTL所以 Yii 用0表示“不设 TTL”靠自己在get()时判断时间戳是否过期。提示你可以通过apcu_cache_info()函数在 CLI 下查看 APCu 中真实存储的键名和大小。执行php -r print_r(apcu_cache_info());重点关注cache_list数组中的key字段确认前缀是否正确、键名是否符合预期。2.2 读取阶段get() 失败的七种可能原因$data $cache-get(user_profile_12345);返回false绝不等于“缓存没命中”。它可能是以下任意一种情况的结果故障类型触发条件排查方法键名不匹配set()用user_profile_12345get()用user_profile_12345 末尾空格var_dump($key)打印实际键名检查空格、大小写、特殊字符序列化失败get()取出的数据反序列化时报错如unserialize(): Error at offset查看 PHP 错误日志确认是否因扩展版本升级导致序列化格式不兼容APCu 内存满载APCu 共享内存池耗尽新数据写入时自动淘汰旧数据apcu_sma_info()查看num_seg、seg_size、avail_mem计算剩余空间进程隔离CLI 脚本和 Web 请求使用不同 APCu 实例常见于 PHP-FPM 配置apc.enable_cli0在 Web 页面和 CLI 中分别执行apcu_cache_info()对比cache_list长度时间戳过期系统时间被手动修改如 NTP 同步误差 1 秒导致时间戳判断失准date命令对比服务器时间与 NTP 服务器时间差缓存组件未启用配置中class写成CApcCache但未安装 APCu 扩展Yii 自动降级为CDummyCachephp -m键名哈希冲突极端情况下不同键名经 Yii 哈希算法后生成相同哈希值概率 0.0001%更换hash配置项为sha256替代默认md5注意CDummyCache是 Yii 的“空实现”所有方法都返回false或null。它不是 bug而是框架的兜底策略——当缓存组件不可用时强制走原始逻辑避免功能中断。但如果你在生产环境看到它被启用说明缓存配置或扩展安装出了严重问题。2.3 清除阶段flush() 与 delete() 的语义差异$cache-flush()和$cache-delete($key)看似都是“删缓存”但行为天壤之别delete($key)仅删除指定键名对应的数据。安全、精准适合“更新商品价格后清除该商品缓存”。flush()清空当前缓存组件管理的所有数据。在CApcCache中它调用apcu_clear_cache()会把整个 APCu 内存池刷空在CDbCache中则是DELETE FROM cache_table。这意味着如果你用同一个CApcCache实例缓存了用户数据、商品数据、配置数据执行flush()会让所有数据同时失效引发雪崩式数据库查询。因此Yii 官方文档强烈建议永远不要在业务代码中调用flush()。它的唯一合理使用场景是部署新版本时在yiic命令行脚本中执行一次全局清理。日常业务中必须用delete()精确控制。3. 四种缓存策略的实战选型从页面级到属性级的逐层穿透Yii 支持四种缓存应用层级它们不是并列选项而是按“作用域由大到小、性能增益由高到低、维护成本由低到高”的顺序构成金字塔。选错层级轻则收益打折重则引发数据一致性灾难。3.1 页面缓存Page Caching最高 ROI但适用场景最窄页面缓存通过COutputCache控制器行为直接缓存整个 HTTP 响应体HTML 字符串。它在CController::run()的最外层拦截请求如果缓存命中连控制器actionXXX()都不会执行。适用场景企业官网首页内容月更无用户登录态新闻列表页分页参数固定如/news?page1API 文档静态页Swagger UI 输出致命限制无法处理动态内容用户头像、购物车数量、未读消息数等都会被缓存成“死数据”。无法响应 Cookie/SessionCOutputCache默认忽略所有请求头包括Cookie。即使你手动设置varyByRoutetrue也无法区分“已登录用户”和“游客”。实操配置public function filters() { return array( array( COutputCache index, // 仅对 index action 生效 duration3600, varyByParamarray(page), // URL 参数 page 不同时视为不同缓存 varyByRoutetrue, // 区分 /news/index 和 /news/list ), ); }经验我在一个政府信息公开系统中用过页面缓存把/gov/notice列表页缓存 1 小时QPS 从 800 峰值压到 30数据库 CPU 从 92% 降到 15%。但上线第二天市民投诉“点进去看到的文件发布时间比首页列表还早”——因为首页列表缓存了但详情页没缓存用户点击的是“昨天缓存的列表”进入的是“今天刚发布的详情”。解决方案强制详情页也缓存且duration设为列表页的 1/106 分钟形成缓存梯度。3.2 片段缓存Fragment Caching平衡艺术80% 场景的最优解片段缓存用?php $this-beginCache(sidebar) ?...?php $this-endCache(); ?包裹视图中某一段 HTML是 Yii 最常用、最灵活的缓存方式。它在视图渲染阶段介入不影响控制器逻辑能完美融合动态与静态内容。关键技巧键名必须带业务上下文不要用sidebar而要用sidebar_user_.$userId或product_recommend_.$categoryId。否则所有用户看到的侧边栏都一样。dependency是灵魂dependencynew CDbCacheDependency(SELECT MAX(updated_at) FROM product)让缓存自动失效——只要product表有更新所有依赖它的片段缓存立即作废。这比手动delete()更可靠。duration要保守推荐 300~1800 秒5~30 分钟。太短失去意义太长导致数据陈旧。避坑案例 某电商后台的商品编辑页我在右侧“关联推荐”区块用了片段缓存?php $this-beginCache(related_products_.$model-id, array( duration1800, dependencynew CDbCacheDependency(SELECT MAX(updated_at) FROM product_relation WHERE product_id{$model-id}) )); ? !-- 推荐商品 HTML -- ?php $this-endCache(); ?上线后发现编辑商品 A 时推荐区块显示的是商品 B 的推荐。排查发现CDbCacheDependency的 SQL 查询中{$model-id}是字符串拼接当$model-id为空或非法时SQL 变成WHERE product_id触发全表扫描返回MAX(updated_at)为NULL导致缓存永不更新。修正方案用参数绑定new CDbCacheDependency(SELECT MAX(updated_at) FROM product_relation WHERE product_id:id, array(:id$model-id))。3.3 数据缓存Data Caching精准打击DB 查询的终极减负器数据缓存即直接调用$cache-get()/$cache-set()缓存的是 PHP 变量数组、对象、字符串而非 HTML。它是性能优化的主力战场。黄金实践缓存查询结果而非 SQL 语句不要缓存SELECT * FROM user WHERE id123这个字符串而要缓存User::model()-findByPk(123)返回的CActiveRecord对象。键名遵循domain:entity:id:field格式如user:profile:12345:permissions、product:detail:67890:stock。清晰、可追溯、易清理。批量操作用mget()/mset()Yii 1.1 原生不支持但可通过扩展CMultiCache实现。一次网络往返获取 100 个用户头像 URL比循环 100 次get()快 5 倍以上。性能对比实测MySQL 5.7 APCu 5.1.20操作未缓存平均耗时缓存后平均耗时QPS 提升单条User::model()-findByPk(12345)18.7ms0.3ms62x100 条User::model()-findAllByPk([1,2,...,100])1240ms15.2ms81xCDbCacheDependency检查SELECT MAX(updated_at)8.3ms——注意CDbCacheDependency的查询本身也会走数据库所以它的duration应设为比主缓存短如主缓存 1800s依赖查询缓存 300s避免依赖检查成为新瓶颈。3.4 查询缓存Query Caching框架黑盒慎用Yii 的CDbConnection::queryCache()会在 DAO 层拦截 SQL 执行自动缓存查询结果。它看似“全自动”实则暗藏陷阱只缓存SELECT不缓存INSERT/UPDATE/DELETE但UPDATE product SET stockstock-1 WHERE id67890执行后之前缓存的SELECT * FROM product WHERE id67890依然有效导致库存显示错误。缓存键基于 SQL 字符串哈希SELECT * FROM user WHERE id123和SELECT * FROM user WHERE id 123空格差异被视为不同键造成缓存碎片。无法设置dependency不能像数据缓存那样绑定表更新时间。结论除非你的应用是只读报表系统如 BI 看板否则禁用查询缓存。用显式的数据缓存替代把缓存生命周期控制权牢牢握在自己手中。4. 生产环境缓存配置的七道生死线从 APCu 到 Memcached 的平滑演进本地开发用CDbCache存 MySQL 表很爽但生产环境必须切换到内存型缓存。Yii 支持 APCu、Memcached、Redis 三种主流后端选择不是看谁“新”而是看谁“稳”。4.1 APCuPHP 进程内共享内存单机王者APCu 是 PHP 7 官方推荐的内置缓存扩展无需额外服务性能极致。配置要点cachearray( classCApcCache, keyPrefixmyapp_prod_, useApcutrue, // Yii 1.1.22 强制启用 APCu非 APC ),必须调整的 PHP.ini 参数apc.enabled1启用 APCuapc.shm_size128M共享内存池大小。计算公式平均每条缓存数据大小 × 预估缓存条目数× 1.5。例如缓存 10 万用户资料每条 2KB需100000×2048×1.5≈300MB设为512M更稳妥。apc.ttl7200APCu 自身的 TTL秒应大于 Yii 缓存duration否则 Yii 还没过期APCu 先清空了。apc.slam_defense0关闭“缓存击穿防御”已废弃设为 0 避免干扰致命缺陷APCu 是单机内存无法跨 PHP-FPM worker 进程共享错APCu 的shm_size是所有 PHP 进程共享的同一块内存不存在“进程隔离”。所谓“CLI 和 Web 不共享”是因为apc.enable_cli0配置导致 CLI 进程根本没加载 APCu 扩展。4.2 Memcached分布式首选但 Yii 1.1 集成有坑当应用部署在多台服务器时APCu 失效必须上 Memcached。Yii 1.1 原生支持CMemCache但默认配置有重大隐患原生CMemCache的servers配置是“轮询”而非“一致性哈希”。这意味着你有 3 台 Memcached 服务器A/B/C缓存键user:12345在 A 上某天 B 服务器宕机CMemCache自动剔除 B剩余 A/C此时user:12345的哈希值可能落在 C 上但 C 没有这条数据导致缓存穿透修复方案重写CMemCache::addServer()集成libketama一致性哈希库或直接弃用CMemCache改用社区增强版CMemCachePlusGitHub 可搜。生产配置示例cachearray( classCMemCachePlus, // 非官方需自行引入 serversarray( array(host10.0.1.10,port11211,weight100), array(host10.0.1.11,port11211,weight100), ), keyPrefixmyapp_prod_, useMemcachedtrue, ),4.3 Redis全能选手但 Yii 1.1 原生不支持Yii 1.1 核心包不含 Redis 支持必须用第三方扩展CRedisCacheGitHub 搜索。它比 Memcached 多出两大优势持久化save命令可将内存数据落地机器重启不丢缓存。丰富数据结构用SETNX实现分布式锁用ZSET做排行榜用PUB/SUB做缓存失效通知。典型 Redis 缓存失效模式解决“更新商品后所有相关页面缓存如何同步”商品 A 更新时执行redis-publish(cache:invalidate, product:detail:67890)所有 Web 服务器上的redis-subscribe(cache:invalidate)监听者收到消息监听者执行$cache-delete(product:detail:67890)这比轮询数据库updated_at或定时flush()更实时、更精准。经验我在一个千万级用户 App 中用 Redis 替代 APCu 后缓存命中率从 89% 提升到 99.2%但首次部署时忘了配置redis-setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_PHP)导致 Yii 序列化的数据 Redis 无法识别get()全部返回 false。调试了 6 小时才发现是序列化协议不匹配——PHP 的serialize()和 Redis 默认的字符串协议水火不容。5. 缓存一致性攻防战从“脏读”到“双删”的五层防护体系缓存最大的敌人不是性能而是数据不一致。用户看到的库存是 100下单时却提示“库存不足 1”这种体验比慢十倍更致命。Yii 缓存没有银弹只有分层防御。5.1 第一层读时校验Read-Through——最基础的兜底永远不要假设get()返回的数据一定正确。在业务逻辑中加入二次校验$data $cache-get(product_stock_67890); if ($data false || $data[stock] $orderQuantity) { // 缓存失效或库存不足重新查库 $data Product::model()-findByPk(67890)-attributes; $cache-set(product_stock_67890, $data, 300); } // 后续逻辑用 $data5.2 第二层写时失效Write-Behind——主动出击更新数据库后立即删除对应缓存$product Product::model()-findByPk(67890); $product-stock $product-stock - $orderQuantity; if ($product-save()) { $cache-delete(product_stock_67890); // 关键 $cache-delete(product_detail_67890); }注意必须放在save()成功之后否则数据库回滚了缓存却删了导致“永久性脏数据”。5.3 第三层延迟双删Cache-Aside with Delayed Double Delete——应对并发写极端并发下如秒杀可能出现请求 A 读缓存命中stock100请求 B 更新 DBstock99删缓存请求 A 写 DBstock99删缓存此时缓存已空请求 A 的set()把旧值stock100又写回缓存解决方案更新 DB 后先删缓存休眠 100ms再删一次缓存// 更新 DB $product-stock $product-stock - 1; $product-save(); // 双删 $cache-delete(product_stock_67890); usleep(100000); // 100ms $cache-delete(product_stock_67890);100ms 足够让其他正在读取的请求完成避免它们把旧值写回。5.4 第四层订阅-通知Pub/Sub——跨服务解耦当商品服务、订单服务、推荐服务部署在不同服务器时用 Redis Pub/Sub 解耦商品服务更新后PUBLISH product:update {id:67890,field:stock}订单服务订阅product:update收到后删除本地缓存推荐服务订阅product:update收到后触发推荐模型重算5.5 第五层TTL 保底Time-To-Live——最后的保险丝无论前面几层多严密都设一个合理的duration如 300 秒。它不解决一致性但保证“最坏情况下数据陈旧不会超过 N 分钟”。这是对业务最底线的尊重。最后分享一个小技巧在 Yii 的CApplication::onBeginRequest事件中注入一个全局缓存监控器Yii::app()-onBeginRequest function($event) { $cache Yii::app()-cache; $stats $cache-getStats(); if ($stats[hits] $stats[misses] * 3) { // 命中率低于 25% Yii::log(Low cache hit rate: {$stats[hits]}/{$stats[misses]}, CLogger::LEVEL_WARNING); } };它能在命中率暴跌时自动告警比等用户投诉快得多。
Yii缓存实战：从APCu到Redis的性能优化与一致性保障
1. 为什么 Yii 应用跑着跑着就变慢了——缓存不是“加个开关”而是性能工程的起点你有没有遇到过这样的场景一个刚上线的 Yii 1.1 后台系统首页加载只要 320ms用户反馈“丝滑”三个月后随着订单表涨到 800 万行、商品 SKU 关联字段增加到 17 个、管理员后台开启 5 个实时统计看板同一页面响应时间飙升到 2.4 秒用户开始在工单里写“卡得像在等泡面”。你查数据库慢查询日志发现SELECT * FROM order WHERE status pending这条语句执行了 1.1 秒——但奇怪的是它明明加了status索引EXPLAIN 显示也走了索引。你再查 PHP-FPM 日志发现每次请求平均要执行 47 次 SQL 查询其中 31 次是完全一样的SELECT name, price, stock FROM product WHERE id ?。这时候你才意识到瓶颈不在数据库本身而在重复计算与重复读取。Yii 框架自带的缓存机制就是为解决这类“高频、低变、高开销”的操作而生的——它不是给应用贴金的装饰品而是把“查一次、用十次”的工程逻辑固化进框架生命周期里的基础设施。这和你在热搜里看到的“ubuntu大量内存被cache无法使用”或“flush cache”完全是两回事。Linux 的 page cache 是内核级的 I/O 缓冲属于操作系统资源调度范畴而 Yii 的 CCache、CDbCache、CApcCache是应用层Application Layer的语义化缓存——它缓存的是你明确告诉框架“这个结果在未来 N 分钟内不会变”的业务数据比如用户权限树、地区字典、商品分类导航、甚至是一段渲染完成的 HTML 片段。它不关心内存是否被占满只关心“下次请求来时我能不能跳过数据库查询、跳过对象实例化、跳过模板渲染直接把结果掏出来”。关键词里提到的 CDbCache 和 CApcCache本质是不同存储后端的适配器CDbCache 把缓存数据存在 MySQL 表里适合开发环境快速验证CApcCache 则直连 APCu 扩展的共享内存生产环境首选毫秒级读写。而 CCache 是所有缓存组件的抽象基类定义了set()、get()、delete()、flush()这四个核心契约。真正决定性能上限的从来不是CCache这个名字而是你在什么时机、以什么粒度、用什么键名、存什么内容、设多长有效期——这才是 Yii 缓存的实操核心也是本文要拆解透的全部。2. Yii 缓存组件的底层工作流从 set() 到 get() 的完整链路解析很多开发者以为“调用$cache-set($key, $value, $duration)就完事了”但实际线上出问题时90% 的故障都发生在get()返回 false 或空值之后。要真正掌控缓存必须看清 Yii 在背后做了什么。我们以最典型的CApcCache为例还原一次完整的缓存读写闭环2.1 写入阶段set() 调用背后的三重校验当你执行$cache-set(user_profile_12345, $profileData, 3600);时Yii 并非简单地把$profileData塞进 APCu。它会先做三件事序列化预处理Yii 默认使用serialize()对$profileData进行序列化。如果$profileData是一个包含 PDO 连接、Closure 匿名函数或资源句柄resource的对象serialize()会直接失败并抛出E_NOTICE。这就是为什么你常看到“Serialization of Closure is not allowed”错误——它根本没走到 APCu卡在了序列化环节。解决方案是要么确保缓存对象是纯数组/标量要么重写CCache::setValue()方法改用igbinary_serialize()需安装 igbinary 扩展或 JSON 编码牺牲部分类型信息但更安全。键名标准化Yii 会自动对$key进行前缀拼接。假设你在配置中设置了keyPrefixmyapp_v2_那么实际存入 APCu 的键名是myapp_v2_user_profile_12345。这个设计是为了避免多个 Yii 应用共用同一 APCu 实例时发生键名冲突。但要注意如果你在不同模块里手动拼接了前缀如myapp_v2_user_profile_12345又在配置里再设keyPrefix就会变成myapp_v2_myapp_v2_user_profile_12345导致get()永远找不到数据。有效期转换$duration3600并非直接传给 APCu 的 TTL。Yii 会将其转换为绝对时间戳time() 3600然后作为元数据和序列化值一起存入。这是为了支持“永不过期”0和“负数表示永不过期”的语义。APCu 本身不支持负数 TTL所以 Yii 用0表示“不设 TTL”靠自己在get()时判断时间戳是否过期。提示你可以通过apcu_cache_info()函数在 CLI 下查看 APCu 中真实存储的键名和大小。执行php -r print_r(apcu_cache_info());重点关注cache_list数组中的key字段确认前缀是否正确、键名是否符合预期。2.2 读取阶段get() 失败的七种可能原因$data $cache-get(user_profile_12345);返回false绝不等于“缓存没命中”。它可能是以下任意一种情况的结果故障类型触发条件排查方法键名不匹配set()用user_profile_12345get()用user_profile_12345 末尾空格var_dump($key)打印实际键名检查空格、大小写、特殊字符序列化失败get()取出的数据反序列化时报错如unserialize(): Error at offset查看 PHP 错误日志确认是否因扩展版本升级导致序列化格式不兼容APCu 内存满载APCu 共享内存池耗尽新数据写入时自动淘汰旧数据apcu_sma_info()查看num_seg、seg_size、avail_mem计算剩余空间进程隔离CLI 脚本和 Web 请求使用不同 APCu 实例常见于 PHP-FPM 配置apc.enable_cli0在 Web 页面和 CLI 中分别执行apcu_cache_info()对比cache_list长度时间戳过期系统时间被手动修改如 NTP 同步误差 1 秒导致时间戳判断失准date命令对比服务器时间与 NTP 服务器时间差缓存组件未启用配置中class写成CApcCache但未安装 APCu 扩展Yii 自动降级为CDummyCachephp -m键名哈希冲突极端情况下不同键名经 Yii 哈希算法后生成相同哈希值概率 0.0001%更换hash配置项为sha256替代默认md5注意CDummyCache是 Yii 的“空实现”所有方法都返回false或null。它不是 bug而是框架的兜底策略——当缓存组件不可用时强制走原始逻辑避免功能中断。但如果你在生产环境看到它被启用说明缓存配置或扩展安装出了严重问题。2.3 清除阶段flush() 与 delete() 的语义差异$cache-flush()和$cache-delete($key)看似都是“删缓存”但行为天壤之别delete($key)仅删除指定键名对应的数据。安全、精准适合“更新商品价格后清除该商品缓存”。flush()清空当前缓存组件管理的所有数据。在CApcCache中它调用apcu_clear_cache()会把整个 APCu 内存池刷空在CDbCache中则是DELETE FROM cache_table。这意味着如果你用同一个CApcCache实例缓存了用户数据、商品数据、配置数据执行flush()会让所有数据同时失效引发雪崩式数据库查询。因此Yii 官方文档强烈建议永远不要在业务代码中调用flush()。它的唯一合理使用场景是部署新版本时在yiic命令行脚本中执行一次全局清理。日常业务中必须用delete()精确控制。3. 四种缓存策略的实战选型从页面级到属性级的逐层穿透Yii 支持四种缓存应用层级它们不是并列选项而是按“作用域由大到小、性能增益由高到低、维护成本由低到高”的顺序构成金字塔。选错层级轻则收益打折重则引发数据一致性灾难。3.1 页面缓存Page Caching最高 ROI但适用场景最窄页面缓存通过COutputCache控制器行为直接缓存整个 HTTP 响应体HTML 字符串。它在CController::run()的最外层拦截请求如果缓存命中连控制器actionXXX()都不会执行。适用场景企业官网首页内容月更无用户登录态新闻列表页分页参数固定如/news?page1API 文档静态页Swagger UI 输出致命限制无法处理动态内容用户头像、购物车数量、未读消息数等都会被缓存成“死数据”。无法响应 Cookie/SessionCOutputCache默认忽略所有请求头包括Cookie。即使你手动设置varyByRoutetrue也无法区分“已登录用户”和“游客”。实操配置public function filters() { return array( array( COutputCache index, // 仅对 index action 生效 duration3600, varyByParamarray(page), // URL 参数 page 不同时视为不同缓存 varyByRoutetrue, // 区分 /news/index 和 /news/list ), ); }经验我在一个政府信息公开系统中用过页面缓存把/gov/notice列表页缓存 1 小时QPS 从 800 峰值压到 30数据库 CPU 从 92% 降到 15%。但上线第二天市民投诉“点进去看到的文件发布时间比首页列表还早”——因为首页列表缓存了但详情页没缓存用户点击的是“昨天缓存的列表”进入的是“今天刚发布的详情”。解决方案强制详情页也缓存且duration设为列表页的 1/106 分钟形成缓存梯度。3.2 片段缓存Fragment Caching平衡艺术80% 场景的最优解片段缓存用?php $this-beginCache(sidebar) ?...?php $this-endCache(); ?包裹视图中某一段 HTML是 Yii 最常用、最灵活的缓存方式。它在视图渲染阶段介入不影响控制器逻辑能完美融合动态与静态内容。关键技巧键名必须带业务上下文不要用sidebar而要用sidebar_user_.$userId或product_recommend_.$categoryId。否则所有用户看到的侧边栏都一样。dependency是灵魂dependencynew CDbCacheDependency(SELECT MAX(updated_at) FROM product)让缓存自动失效——只要product表有更新所有依赖它的片段缓存立即作废。这比手动delete()更可靠。duration要保守推荐 300~1800 秒5~30 分钟。太短失去意义太长导致数据陈旧。避坑案例 某电商后台的商品编辑页我在右侧“关联推荐”区块用了片段缓存?php $this-beginCache(related_products_.$model-id, array( duration1800, dependencynew CDbCacheDependency(SELECT MAX(updated_at) FROM product_relation WHERE product_id{$model-id}) )); ? !-- 推荐商品 HTML -- ?php $this-endCache(); ?上线后发现编辑商品 A 时推荐区块显示的是商品 B 的推荐。排查发现CDbCacheDependency的 SQL 查询中{$model-id}是字符串拼接当$model-id为空或非法时SQL 变成WHERE product_id触发全表扫描返回MAX(updated_at)为NULL导致缓存永不更新。修正方案用参数绑定new CDbCacheDependency(SELECT MAX(updated_at) FROM product_relation WHERE product_id:id, array(:id$model-id))。3.3 数据缓存Data Caching精准打击DB 查询的终极减负器数据缓存即直接调用$cache-get()/$cache-set()缓存的是 PHP 变量数组、对象、字符串而非 HTML。它是性能优化的主力战场。黄金实践缓存查询结果而非 SQL 语句不要缓存SELECT * FROM user WHERE id123这个字符串而要缓存User::model()-findByPk(123)返回的CActiveRecord对象。键名遵循domain:entity:id:field格式如user:profile:12345:permissions、product:detail:67890:stock。清晰、可追溯、易清理。批量操作用mget()/mset()Yii 1.1 原生不支持但可通过扩展CMultiCache实现。一次网络往返获取 100 个用户头像 URL比循环 100 次get()快 5 倍以上。性能对比实测MySQL 5.7 APCu 5.1.20操作未缓存平均耗时缓存后平均耗时QPS 提升单条User::model()-findByPk(12345)18.7ms0.3ms62x100 条User::model()-findAllByPk([1,2,...,100])1240ms15.2ms81xCDbCacheDependency检查SELECT MAX(updated_at)8.3ms——注意CDbCacheDependency的查询本身也会走数据库所以它的duration应设为比主缓存短如主缓存 1800s依赖查询缓存 300s避免依赖检查成为新瓶颈。3.4 查询缓存Query Caching框架黑盒慎用Yii 的CDbConnection::queryCache()会在 DAO 层拦截 SQL 执行自动缓存查询结果。它看似“全自动”实则暗藏陷阱只缓存SELECT不缓存INSERT/UPDATE/DELETE但UPDATE product SET stockstock-1 WHERE id67890执行后之前缓存的SELECT * FROM product WHERE id67890依然有效导致库存显示错误。缓存键基于 SQL 字符串哈希SELECT * FROM user WHERE id123和SELECT * FROM user WHERE id 123空格差异被视为不同键造成缓存碎片。无法设置dependency不能像数据缓存那样绑定表更新时间。结论除非你的应用是只读报表系统如 BI 看板否则禁用查询缓存。用显式的数据缓存替代把缓存生命周期控制权牢牢握在自己手中。4. 生产环境缓存配置的七道生死线从 APCu 到 Memcached 的平滑演进本地开发用CDbCache存 MySQL 表很爽但生产环境必须切换到内存型缓存。Yii 支持 APCu、Memcached、Redis 三种主流后端选择不是看谁“新”而是看谁“稳”。4.1 APCuPHP 进程内共享内存单机王者APCu 是 PHP 7 官方推荐的内置缓存扩展无需额外服务性能极致。配置要点cachearray( classCApcCache, keyPrefixmyapp_prod_, useApcutrue, // Yii 1.1.22 强制启用 APCu非 APC ),必须调整的 PHP.ini 参数apc.enabled1启用 APCuapc.shm_size128M共享内存池大小。计算公式平均每条缓存数据大小 × 预估缓存条目数× 1.5。例如缓存 10 万用户资料每条 2KB需100000×2048×1.5≈300MB设为512M更稳妥。apc.ttl7200APCu 自身的 TTL秒应大于 Yii 缓存duration否则 Yii 还没过期APCu 先清空了。apc.slam_defense0关闭“缓存击穿防御”已废弃设为 0 避免干扰致命缺陷APCu 是单机内存无法跨 PHP-FPM worker 进程共享错APCu 的shm_size是所有 PHP 进程共享的同一块内存不存在“进程隔离”。所谓“CLI 和 Web 不共享”是因为apc.enable_cli0配置导致 CLI 进程根本没加载 APCu 扩展。4.2 Memcached分布式首选但 Yii 1.1 集成有坑当应用部署在多台服务器时APCu 失效必须上 Memcached。Yii 1.1 原生支持CMemCache但默认配置有重大隐患原生CMemCache的servers配置是“轮询”而非“一致性哈希”。这意味着你有 3 台 Memcached 服务器A/B/C缓存键user:12345在 A 上某天 B 服务器宕机CMemCache自动剔除 B剩余 A/C此时user:12345的哈希值可能落在 C 上但 C 没有这条数据导致缓存穿透修复方案重写CMemCache::addServer()集成libketama一致性哈希库或直接弃用CMemCache改用社区增强版CMemCachePlusGitHub 可搜。生产配置示例cachearray( classCMemCachePlus, // 非官方需自行引入 serversarray( array(host10.0.1.10,port11211,weight100), array(host10.0.1.11,port11211,weight100), ), keyPrefixmyapp_prod_, useMemcachedtrue, ),4.3 Redis全能选手但 Yii 1.1 原生不支持Yii 1.1 核心包不含 Redis 支持必须用第三方扩展CRedisCacheGitHub 搜索。它比 Memcached 多出两大优势持久化save命令可将内存数据落地机器重启不丢缓存。丰富数据结构用SETNX实现分布式锁用ZSET做排行榜用PUB/SUB做缓存失效通知。典型 Redis 缓存失效模式解决“更新商品后所有相关页面缓存如何同步”商品 A 更新时执行redis-publish(cache:invalidate, product:detail:67890)所有 Web 服务器上的redis-subscribe(cache:invalidate)监听者收到消息监听者执行$cache-delete(product:detail:67890)这比轮询数据库updated_at或定时flush()更实时、更精准。经验我在一个千万级用户 App 中用 Redis 替代 APCu 后缓存命中率从 89% 提升到 99.2%但首次部署时忘了配置redis-setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_PHP)导致 Yii 序列化的数据 Redis 无法识别get()全部返回 false。调试了 6 小时才发现是序列化协议不匹配——PHP 的serialize()和 Redis 默认的字符串协议水火不容。5. 缓存一致性攻防战从“脏读”到“双删”的五层防护体系缓存最大的敌人不是性能而是数据不一致。用户看到的库存是 100下单时却提示“库存不足 1”这种体验比慢十倍更致命。Yii 缓存没有银弹只有分层防御。5.1 第一层读时校验Read-Through——最基础的兜底永远不要假设get()返回的数据一定正确。在业务逻辑中加入二次校验$data $cache-get(product_stock_67890); if ($data false || $data[stock] $orderQuantity) { // 缓存失效或库存不足重新查库 $data Product::model()-findByPk(67890)-attributes; $cache-set(product_stock_67890, $data, 300); } // 后续逻辑用 $data5.2 第二层写时失效Write-Behind——主动出击更新数据库后立即删除对应缓存$product Product::model()-findByPk(67890); $product-stock $product-stock - $orderQuantity; if ($product-save()) { $cache-delete(product_stock_67890); // 关键 $cache-delete(product_detail_67890); }注意必须放在save()成功之后否则数据库回滚了缓存却删了导致“永久性脏数据”。5.3 第三层延迟双删Cache-Aside with Delayed Double Delete——应对并发写极端并发下如秒杀可能出现请求 A 读缓存命中stock100请求 B 更新 DBstock99删缓存请求 A 写 DBstock99删缓存此时缓存已空请求 A 的set()把旧值stock100又写回缓存解决方案更新 DB 后先删缓存休眠 100ms再删一次缓存// 更新 DB $product-stock $product-stock - 1; $product-save(); // 双删 $cache-delete(product_stock_67890); usleep(100000); // 100ms $cache-delete(product_stock_67890);100ms 足够让其他正在读取的请求完成避免它们把旧值写回。5.4 第四层订阅-通知Pub/Sub——跨服务解耦当商品服务、订单服务、推荐服务部署在不同服务器时用 Redis Pub/Sub 解耦商品服务更新后PUBLISH product:update {id:67890,field:stock}订单服务订阅product:update收到后删除本地缓存推荐服务订阅product:update收到后触发推荐模型重算5.5 第五层TTL 保底Time-To-Live——最后的保险丝无论前面几层多严密都设一个合理的duration如 300 秒。它不解决一致性但保证“最坏情况下数据陈旧不会超过 N 分钟”。这是对业务最底线的尊重。最后分享一个小技巧在 Yii 的CApplication::onBeginRequest事件中注入一个全局缓存监控器Yii::app()-onBeginRequest function($event) { $cache Yii::app()-cache; $stats $cache-getStats(); if ($stats[hits] $stats[misses] * 3) { // 命中率低于 25% Yii::log(Low cache hit rate: {$stats[hits]}/{$stats[misses]}, CLogger::LEVEL_WARNING); } };它能在命中率暴跌时自动告警比等用户投诉快得多。
