Fastadmin后台项目做多了你早晚会遇到一个坎数据量涨上来了后台首页的统计接口从几十毫秒变成一两秒用户列表筛选越用越慢验证码偶尔加载半秒才出来发一个营销通知能把接口卡死。大部分时候第一个想到的是优化SQL、加索引但有些数据本身就该放内存里比如验证码、Token、热榜、计数器、排队任务。这时候往Fastadmin里接一个Redis很多问题会瞬间打开局面。这篇文章我结合自己在Fastadmin项目里接入Redis的实操经验从安装、配置到典型场景缓存、Token、分布式锁、队列逐步展开也把踩过的坑和排查技巧一并整理出来。适合正在做Fastadmin二开、遇到后台性能瓶颈、或只是想在项目里把Redis用对的中高级开发者阅读新手也可以当一份可落地的心得参考。1. 接入前的判断Redis能在Fastadmin里解决哪些问题1.1 为什么单位的瓶颈往往不是SQL而是重复查询先说个现象。Fastadmin的后台列表页、Dashboard、各类报表很多页面的核心查询其实已经写了不错的JOIN和索引但一旦并发上来真正拖垮MySQL的往往是那些高频、重复、结果几乎不变的数据。比如后台首页的统计数据每次打开都重新计算一遍全表SUM比如省市区下拉框每个用户打开都去查一次地区表比如菜单权限每次请求都去数据库拉一遍权限规则。这些数据的特点是读多写少、实时性要求不高完全没必要每次都打到数据库。Redis就是干这个的内存数据库读写性能极高单机QPS可以轻松上万而同样的请求打到MySQL上可能几百就报警了。把这类数据放Redis等于给后台加了一层“热数据缓存层”数据库的压力立刻降一个数量级。1.2 接入前先想清楚不是所有场景都该用Redis我一开始接入Redis时恨不得把所有东西都塞进去。后来发现Redis不是银弹强行上Redis反而会增加复杂度。什么场景真正适合临时性数据验证码、Token、读多写少的业务数据配置、分类、字典、需要跨进程共享的计数和锁、需要异步执行的队列。至于那些强一致、实时性极高、或者低频访问且MySQL本身就不慢的数据放Redis反而浪费内存还多了一遍缓存更新逻辑。所以我的建议是动手配置前把你项目里慢的地方列出来分类看是哪一类数据的问题。是查得慢还是查得多查得慢要优化SQL和索引查得多才适合用缓存。这个判断做对了后面才不会白忙。1.3 Fastadmin与Redis的契合点Fastadmin虽然是基于ThinkPHP的后台框架但它的很多机制天然适合Redis加持。比如后台的“系统配置”走的是缓存读取多语言、菜单、附件配置都有自己的缓存键Fastadmin的验证码插件默认把验证码存Session多端登录时容易串Fastadmin配套的队列指令、定时任务也需要一个可靠的任务存储。把这些点逐个切到Redis后台的响应速度和稳定性会明显好转而且改造成本很低多数情况下只是改个配置代码层面做少量调整。2. 部署与基础接入从安装Redis到Fastadmin跑通Redis驱动2.1 Redis装到哪里Linux、Windows、Docker三种方式的选择先解决环境问题。如果你用的是云服务器或者Linux开发机最简单的是系统包管理工具安装Ubuntu上执行apt install redis-serverCentOS上执行yum install redis装完启动redis-server /etc/redis/redis.conf默认监听6379端口。Windows下开发调试一般用官方提供的Windows移植版zip包解压后直接运行redis-server.exe就能起一个裸实例也可以把Redis注册为Windows服务这样不用每次手动启动命令行执行redis-server --service-install redis.windows.conf即可。如果你的服务器本身已经在跑Docker我反而推荐直接用容器方式好处是版本可控、迁移方便、不污染宿主机环境。一条命令就能拉起来docker run -d --name redis -p 6379:6379 -v /data/redis:/data redis:7.0 redis-server --appendonly yes这里我把持久化开关appendonly打开生产环境建议这么做。即使重启数据也不丢太多。注意本地或测试环境Redis可以随便裸跑生产环境务必设置requirepass密码并且不要用默认端口裸暴露到公网。曾经有项目Redis没设密码被刷了一次数据直接被清空教训深刻。持久化方面简单提一句Redis有两种持久化方式RDB快照和AOF追加日志。RDB文件小、恢复快但可能丢最近一次快照之后的数据AOF更完整但文件会越写越大。一般后台缓存类业务数据丢了也就丢了RDB就够了如果Redis里还存了订单号、队列任务这类重要数据建议AOF和RDB同时开启。启动时加上上面命令里的--appendonly yes开了AOF再用--save 60 1000之类的参数配置RDB快照频率两者互补。2.2 PHP环境检查phpredis扩展必须提前装好Fastadmin要操作Redis底层有两种方式用PHP的redis扩展phpredis或者用纯PHP实现的predis库。我用的是前者性能好、接口全、和ThinkPHP的缓存驱动兼容度最高。判断环境装没装看这个命令php -m | grep redis有输出就说明扩展已启用。如果没装Linux上用pecl install redis装完在php.ini里加上extensionredis.so重启PHP-FPM。Windows下则要下载和你的PHP版本注意是NTS还是TS、VC版本、位数匹配的php_redis.dll放到ext目录并开启扩展。这一步最容易在小版本号上踩坑下载前务必确认自己的PHP版本信息再选文件。2.3 Fastadmin切换Redis驱动的配置写法Fastadmin有多个版本老一点的基于ThinkPHP 5新版本基于ThinkPHP 6/8。配置位置略有差异但核心思路一样。TP5版本打开application/config.php找到cache参数把默认的File改成Rediscache [ type Redis, host 127.0.0.1, port 6379, password , // 如果有密码就填 timeout 5, // 连接超时时间 select 0, // 选择第几个库默认0号库 prefix fa_admin:, // 所有key统一加前缀 ],TP6版本配置写在config/cache.php里结构类似把default驱动的type改成redis同时在stores里添加redis连接参数。这里有两个容易被忽略的细节。第一个是prefix一定要设置生产环境尤其重要。因为你同一个Redis实例可能同时被多个项目使用有前缀能避免key冲突后面清理缓存也不会手抖删掉别人的数据。第二个是select数据库编号我习惯专门给Fastadmin项目指定一个库比如用1号库这样后台缓存和公用业务的redis数据彻底隔离逻辑清晰。2.4 验证连接是否生效从一行代码到可视化客户端配置改完后随便写个测试方法或直接在Fastadmin自带的命令工具里执行$result \think\Cache::set(test_key, hello_redis, 60); $value \think\Cache::get(test_key); var_dump($value);能取出hello_redis说明驱动已生效。如果是老项目记得把application/config.php里的cache.type和cache.prefix都确认一遍有些项目用的是.env环境变量覆盖配置配置改了却一直没生效多半是.env里还有一份cache配置在起作用这也是我后来排查连接问题时先检查的地方。可视化工具这边我平时排查Redis数据用Redis Desktop Manager现在也有很多人用Another Redis Desktop Manager界面类似功能看个人习惯。连接时填上IP、端口、密码即可。很多开发小白第一次连不上90%是Redis实例绑定了本机回环地址默认bind 127.0.0.1远程连接前需要去redis.conf里注释掉bind行或改成内网IP同时设置protected-mode no才能从外部访问。生产环境注意安全不要无条件放开访问。3. 典型业务场景实战把Redis真正用起来3.1 验证码和Token把Session变量改到Redis里Fastadmin后台登录验证码默认存的是Session遇到多终端登录或者会话失效频繁的情况用户体验很差。而且PHP默认文件的Session在高并发下读写效率本来就低。我把验证码存储切到缓存后逻辑变得非常简单生成验证码时用唯一ID做key把验证码值写入Redis设置5分钟过期校验时读取并删除该key一次性使用。这样即使后端有多台服务器验证码也能通过共享Redis统一校验不需要依赖粘性会话。Token同样的道理Fastadmin自带的Token机制用于API接口鉴权默认可能走数据库表或文件缓存。接入Redis后用Cache::set($token, $userInfo, 7200)存两个小时每次接口请求时先去Redis查Token缓存命中就直接返回用户信息避免一次请求连带几次数据库查询。这里有个小技巧手动续期时用Cache::expire($token, 7200)类方法刷新过期时间可以做成“活跃用户Token自动延长不活跃用户自然过期”的效果。3.2 读多写少的业务数据缓存配置、分类、地区表后台项目最常见的优化点其实是下拉框数据。比如“城市列表”“商品分类”“数据字典”这些表数据量不大但每次打开表单、筛选器、导出功能都会查一遍。我用一个自封装的服务方法搞定先查缓存没有再查库回填缓存并设置TTL。以省市区数据为例public function getRegionList() { $key region:list; $list Cache::get($key); if (!$list) { $list Db::name(region)-select()-toArray(); Cache::set($key, $list, 86400); // 缓存24小时 } return $list; }要注意的是更新数据时必须把对应缓存主动删掉或者重新写入而不是等自然过期。最稳妥的写法是写库操作后调用Cache::rm($key)下次读取时自动重新拉取。否则你会看到用户新增了一条分类页面下拉框里死活不显示排查半天才发现是缓存没清。3.3 并发控制分布式锁与计数器Fastadmin后台里跟“数字”相关的场景特别容易出并发问题比如优惠券库存扣减、订单号自增、定时任务重复执行。这些场景用Redis的原子操作就很顺手。扣库存的经典写法是使用Redis的decr/incr命令保证原子性。比如库存key存的是剩余数量用户下单前先做预扣$stock Cache::get(stock:sku_123); if ($stock false) { // 初始化库存可以配合数据库读取 Cache::set(stock:sku_123, $dbStock); } $left Cache::store(redis)-handler()-decr(stock:sku_123); if ($left 0) { // 恢复库存并提示库存不足 Cache::store(redis)-handler()-incr(stock:sku_123); throw new \Exception(库存不足); }这里用到了Cache::store(redis)-handler()拿到的是ThinkPHP包装下的原生Redis对象可以直接调用decr、incr、expire这些底层命令。单纯用Cache::getCache::set两步操作在高并发下会出现竞态两个请求都读到相同库存然后各自写回导致超卖。分布式锁的场景更微妙。比如后台有一个定时报表的生成任务定时任务被设置成每分钟执行一次但上次执行还没结束下一次又开始了最终导致重复生成、表格数据翻倍。用Redis锁就可以避免$lockKey lock:report_generate; $lockAcquired Cache::store(redis)-handler()-set($lockKey, 1, [nx, ex 60]); if (!$lockAcquired) { // 说明任务还在执行中直接跳过本次 return; } try { // 执行报表生成逻辑 } finally { // 任务结束释放锁 Cache::rm($lockKey); }上面的set命令用了nx只在key不存在时生效和ex过期时间60秒两个选项配合起来就是Redis社区标准分布式锁的雏形。注意一定要给锁设置过期时间否则程序异常退出锁永远不会释放后续所有任务都会被卡住。3.4 队列与异步化把耗时任务挪出去Fastadmin做“批量发送邮件”“Excel导出大列表”“推送通知”这类操作时页面会卡很久。我的做法是引入ThinkPHP官方推荐的think-queue队列组件驱动改成Redis。队列本质就是一个List结构生产者把任务用Queue::push()写入Redis的List消费者通过命令php think queue:work从List左侧取出任务执行执行完后用Queue::later()安排延时任务。接入之后后台的发送通知、报表生成、数据导入等全部变成“秒回”。用户点击按钮页面立即返回“任务已加入队列”真正的耗时操作在后台进程里悄悄完成。这在Fastadmin二开里是一个非常提体验的优化尤其适合用在插件开发里。有个细节提醒队列消费端一定要保证Redis里任务的安全性生产环境建议开启AOF持久化否则Redis进程意外重启队列里还没执行的任务会丢失。另外消费端代码里要try/catch任务执行失败时可以用$job-failed()回调记录日志并重试避免一条脏数据卡死整个队列。4. 常见问题与排查技巧实录4.1 错误速查表连接失败、功能异常、数据不一致现象常见原因排查与解决Connection refusedRedis未启动或端口被防火墙拦截本机先redis-cli ping通了再查PHP进程里的网络权限NOAUTH Authentication required服务端设置了密码配置里没填config/cache.php里补password或确认密码是否正确OOM command not allowedRedis内存满了触发了maxmemory限制增大maxmemory或配置合适的淘汰策略maxmemory-policy allkeys-lru缓存一直读不到新数据有多个Redis库或prefix不一致清掉旧前缀key统一prefix和select库编号接口偶发很慢大key或热点key存在导致Redis阻塞用redis-cli --bigkeys找出大key拆分或设置TTL存储的数组取出变成nullPHP序列化问题确认PHP的redis扩展序列化选项或统一用serialize处理4.2 我在项目里踩过的坑清理缓存误爆key设计不合理有一次上线后我发现后台“一键清缓存”按钮用了几次结果用户积分明细全部消失。排查后发现项目里把积分记录暂时也缓存进了Redis而Fastadmin后台的缓存清理工具会按照prefix批量删除所有匹配的key结果把业务数据也删了。打那以后我给自己定了一条规矩业务缓存的key前缀一定要和框架缓存的前缀区分开。比如框架缓存统一用fa_业务缓存单独用biz_并且清缓存的工具只允许处理框架前缀范围内的key。还有一次线上事故是大key问题。我把用户购物车数据整个塞进一个字符串一个key几MB高并发时读写都卡Redis拖慢了所有请求。用--bigkeys扫出来后才逐步改成Hash结构把单个商品条目独立成field读写性能改善非常明显。这个经历让我意识到Redis不是“什么都能往一个key里塞”的存储数据结构选错副作用是全链路级的。4.3 缓存一致性先更新数据库还是先更新缓存做缓存最难受的就是数据库和Redis的数据不一致。这个我吃过好几回亏结论是写操作永远先更新数据库再删除或更新缓存。为什么如果先更新缓存再更新数据库一旦数据库更新失败缓存里已经是新值用户看到的是不存在的数据。反过来先落库成功再删缓存即使删除失败旧缓存也会在TTL到期后自动失效影响范围有限。还有更严格一点的方案叫“延迟双删”先删缓存再更新数据库睡几百毫秒后再次删缓存。这么做是因为并发读请求可能在第一次删除后把旧数据重新写回缓存延迟再删一次能用兜底方式保证最终一致。不过对于大多数Fastadmin后台项目用好“先更库再删缓存 合理的TTL”已经足够稳定过度设计只会增加代码复杂度。4.4 缓存雪崩、击穿、穿透的三个对策这三个词新手容易混。雪崩是大批key同一时间过期Redis里突然空了一大片所有请求瞬间打到数据库击穿是某一个热点key恰好过期同刻大量并发请求穿透到数据库穿透是查询了一个不存在的keyDB里也没有每次请求都会绕开缓存压向数据库。应对雪崩我给key的TTL加入随机抖动比如基础24小时再加0到3600秒的随机值避免集体过期。应对击穿用互斥锁让第一个请求去重建缓存其他请求等待缓存生成后直接读。应对穿透最简单的是把空结果也缓存到Redis设置一个较短的过期时间比如5分钟这样同一个不存在的数据不会反复打库。这套办法在Fastadmin的报表统计、商品详情这类高流量接口上都验证过效果稳定。4.5 Redis日志与监控别等出事了再开工具我在生产环境上会定期用redis-cli info查看内存、连接数、命中率。重点关注hits和misses两个指标计算缓存命中率长期低于60%说明缓存策略有问题要么key设置太短要么根本没缓存到有效数据。再关注connected_clients连接数异常上涨通常意味着代码里有连接泄漏比如每次请求都新建Redis连接而没有关闭复用。Fastadmin如果用了ThinkPHP缓存组件底层连接池由框架管理一般不会出现连接泄漏但用了Cache::store(redis)-handler()直接操作原生Redis时要记得长生命周期进程下归还连接或适当重连。日志方面我习惯把Redis的慢命令日志开起来在redis.conf中设置slowlog-log-slower-than 10000超过10毫秒的命令记录下来定期分析是哪些key产生了热点压力。写到最后一些个人体会如果你正准备在Fastadmin里接入Redis我的建议是从最小的点开始改比如先把验证码和Token切到Redis观察几天稳定了再把高频查询的业务数据加缓存。不要一次把所有模块都改造完毕那样出了问题排查范围会非常大。我第一次改造就想着一步到位结果验证码、队列、缓存全上线上出现一次key冲突后光定位就花了整整一天。另外Redis的配置和运维不能只是“装好了就完”。密码、持久化、淘汰策略、key前缀、监控脚本这些事我建议在接入当天就全部弄好。像maxmemory-policy如果不设置Redis内存满了会直接拒绝写入该报错报错比那种内存耗尽导致整台服务器卡死要好很多。给它设一个合理上限比如物理内存的一半再配上allkeys-lru至少能保证服务不会以最坏的方式挂掉。最后分享一个小技巧后台的“清缓存”功能建议做成可选项区分“清理框架缓存”和“清理业务缓存”并且每次清理后把清理的key数量和耗时记录到日志里。这能帮你快速判断是不是有外部操作引起缓存大面积失效也是我后来维护多个Fastadmin项目时排查效率最高的一个抓手。
Fastadmin接入Redis实战：缓存、分布式锁与队列优化后台性能
Fastadmin后台项目做多了你早晚会遇到一个坎数据量涨上来了后台首页的统计接口从几十毫秒变成一两秒用户列表筛选越用越慢验证码偶尔加载半秒才出来发一个营销通知能把接口卡死。大部分时候第一个想到的是优化SQL、加索引但有些数据本身就该放内存里比如验证码、Token、热榜、计数器、排队任务。这时候往Fastadmin里接一个Redis很多问题会瞬间打开局面。这篇文章我结合自己在Fastadmin项目里接入Redis的实操经验从安装、配置到典型场景缓存、Token、分布式锁、队列逐步展开也把踩过的坑和排查技巧一并整理出来。适合正在做Fastadmin二开、遇到后台性能瓶颈、或只是想在项目里把Redis用对的中高级开发者阅读新手也可以当一份可落地的心得参考。1. 接入前的判断Redis能在Fastadmin里解决哪些问题1.1 为什么单位的瓶颈往往不是SQL而是重复查询先说个现象。Fastadmin的后台列表页、Dashboard、各类报表很多页面的核心查询其实已经写了不错的JOIN和索引但一旦并发上来真正拖垮MySQL的往往是那些高频、重复、结果几乎不变的数据。比如后台首页的统计数据每次打开都重新计算一遍全表SUM比如省市区下拉框每个用户打开都去查一次地区表比如菜单权限每次请求都去数据库拉一遍权限规则。这些数据的特点是读多写少、实时性要求不高完全没必要每次都打到数据库。Redis就是干这个的内存数据库读写性能极高单机QPS可以轻松上万而同样的请求打到MySQL上可能几百就报警了。把这类数据放Redis等于给后台加了一层“热数据缓存层”数据库的压力立刻降一个数量级。1.2 接入前先想清楚不是所有场景都该用Redis我一开始接入Redis时恨不得把所有东西都塞进去。后来发现Redis不是银弹强行上Redis反而会增加复杂度。什么场景真正适合临时性数据验证码、Token、读多写少的业务数据配置、分类、字典、需要跨进程共享的计数和锁、需要异步执行的队列。至于那些强一致、实时性极高、或者低频访问且MySQL本身就不慢的数据放Redis反而浪费内存还多了一遍缓存更新逻辑。所以我的建议是动手配置前把你项目里慢的地方列出来分类看是哪一类数据的问题。是查得慢还是查得多查得慢要优化SQL和索引查得多才适合用缓存。这个判断做对了后面才不会白忙。1.3 Fastadmin与Redis的契合点Fastadmin虽然是基于ThinkPHP的后台框架但它的很多机制天然适合Redis加持。比如后台的“系统配置”走的是缓存读取多语言、菜单、附件配置都有自己的缓存键Fastadmin的验证码插件默认把验证码存Session多端登录时容易串Fastadmin配套的队列指令、定时任务也需要一个可靠的任务存储。把这些点逐个切到Redis后台的响应速度和稳定性会明显好转而且改造成本很低多数情况下只是改个配置代码层面做少量调整。2. 部署与基础接入从安装Redis到Fastadmin跑通Redis驱动2.1 Redis装到哪里Linux、Windows、Docker三种方式的选择先解决环境问题。如果你用的是云服务器或者Linux开发机最简单的是系统包管理工具安装Ubuntu上执行apt install redis-serverCentOS上执行yum install redis装完启动redis-server /etc/redis/redis.conf默认监听6379端口。Windows下开发调试一般用官方提供的Windows移植版zip包解压后直接运行redis-server.exe就能起一个裸实例也可以把Redis注册为Windows服务这样不用每次手动启动命令行执行redis-server --service-install redis.windows.conf即可。如果你的服务器本身已经在跑Docker我反而推荐直接用容器方式好处是版本可控、迁移方便、不污染宿主机环境。一条命令就能拉起来docker run -d --name redis -p 6379:6379 -v /data/redis:/data redis:7.0 redis-server --appendonly yes这里我把持久化开关appendonly打开生产环境建议这么做。即使重启数据也不丢太多。注意本地或测试环境Redis可以随便裸跑生产环境务必设置requirepass密码并且不要用默认端口裸暴露到公网。曾经有项目Redis没设密码被刷了一次数据直接被清空教训深刻。持久化方面简单提一句Redis有两种持久化方式RDB快照和AOF追加日志。RDB文件小、恢复快但可能丢最近一次快照之后的数据AOF更完整但文件会越写越大。一般后台缓存类业务数据丢了也就丢了RDB就够了如果Redis里还存了订单号、队列任务这类重要数据建议AOF和RDB同时开启。启动时加上上面命令里的--appendonly yes开了AOF再用--save 60 1000之类的参数配置RDB快照频率两者互补。2.2 PHP环境检查phpredis扩展必须提前装好Fastadmin要操作Redis底层有两种方式用PHP的redis扩展phpredis或者用纯PHP实现的predis库。我用的是前者性能好、接口全、和ThinkPHP的缓存驱动兼容度最高。判断环境装没装看这个命令php -m | grep redis有输出就说明扩展已启用。如果没装Linux上用pecl install redis装完在php.ini里加上extensionredis.so重启PHP-FPM。Windows下则要下载和你的PHP版本注意是NTS还是TS、VC版本、位数匹配的php_redis.dll放到ext目录并开启扩展。这一步最容易在小版本号上踩坑下载前务必确认自己的PHP版本信息再选文件。2.3 Fastadmin切换Redis驱动的配置写法Fastadmin有多个版本老一点的基于ThinkPHP 5新版本基于ThinkPHP 6/8。配置位置略有差异但核心思路一样。TP5版本打开application/config.php找到cache参数把默认的File改成Rediscache [ type Redis, host 127.0.0.1, port 6379, password , // 如果有密码就填 timeout 5, // 连接超时时间 select 0, // 选择第几个库默认0号库 prefix fa_admin:, // 所有key统一加前缀 ],TP6版本配置写在config/cache.php里结构类似把default驱动的type改成redis同时在stores里添加redis连接参数。这里有两个容易被忽略的细节。第一个是prefix一定要设置生产环境尤其重要。因为你同一个Redis实例可能同时被多个项目使用有前缀能避免key冲突后面清理缓存也不会手抖删掉别人的数据。第二个是select数据库编号我习惯专门给Fastadmin项目指定一个库比如用1号库这样后台缓存和公用业务的redis数据彻底隔离逻辑清晰。2.4 验证连接是否生效从一行代码到可视化客户端配置改完后随便写个测试方法或直接在Fastadmin自带的命令工具里执行$result \think\Cache::set(test_key, hello_redis, 60); $value \think\Cache::get(test_key); var_dump($value);能取出hello_redis说明驱动已生效。如果是老项目记得把application/config.php里的cache.type和cache.prefix都确认一遍有些项目用的是.env环境变量覆盖配置配置改了却一直没生效多半是.env里还有一份cache配置在起作用这也是我后来排查连接问题时先检查的地方。可视化工具这边我平时排查Redis数据用Redis Desktop Manager现在也有很多人用Another Redis Desktop Manager界面类似功能看个人习惯。连接时填上IP、端口、密码即可。很多开发小白第一次连不上90%是Redis实例绑定了本机回环地址默认bind 127.0.0.1远程连接前需要去redis.conf里注释掉bind行或改成内网IP同时设置protected-mode no才能从外部访问。生产环境注意安全不要无条件放开访问。3. 典型业务场景实战把Redis真正用起来3.1 验证码和Token把Session变量改到Redis里Fastadmin后台登录验证码默认存的是Session遇到多终端登录或者会话失效频繁的情况用户体验很差。而且PHP默认文件的Session在高并发下读写效率本来就低。我把验证码存储切到缓存后逻辑变得非常简单生成验证码时用唯一ID做key把验证码值写入Redis设置5分钟过期校验时读取并删除该key一次性使用。这样即使后端有多台服务器验证码也能通过共享Redis统一校验不需要依赖粘性会话。Token同样的道理Fastadmin自带的Token机制用于API接口鉴权默认可能走数据库表或文件缓存。接入Redis后用Cache::set($token, $userInfo, 7200)存两个小时每次接口请求时先去Redis查Token缓存命中就直接返回用户信息避免一次请求连带几次数据库查询。这里有个小技巧手动续期时用Cache::expire($token, 7200)类方法刷新过期时间可以做成“活跃用户Token自动延长不活跃用户自然过期”的效果。3.2 读多写少的业务数据缓存配置、分类、地区表后台项目最常见的优化点其实是下拉框数据。比如“城市列表”“商品分类”“数据字典”这些表数据量不大但每次打开表单、筛选器、导出功能都会查一遍。我用一个自封装的服务方法搞定先查缓存没有再查库回填缓存并设置TTL。以省市区数据为例public function getRegionList() { $key region:list; $list Cache::get($key); if (!$list) { $list Db::name(region)-select()-toArray(); Cache::set($key, $list, 86400); // 缓存24小时 } return $list; }要注意的是更新数据时必须把对应缓存主动删掉或者重新写入而不是等自然过期。最稳妥的写法是写库操作后调用Cache::rm($key)下次读取时自动重新拉取。否则你会看到用户新增了一条分类页面下拉框里死活不显示排查半天才发现是缓存没清。3.3 并发控制分布式锁与计数器Fastadmin后台里跟“数字”相关的场景特别容易出并发问题比如优惠券库存扣减、订单号自增、定时任务重复执行。这些场景用Redis的原子操作就很顺手。扣库存的经典写法是使用Redis的decr/incr命令保证原子性。比如库存key存的是剩余数量用户下单前先做预扣$stock Cache::get(stock:sku_123); if ($stock false) { // 初始化库存可以配合数据库读取 Cache::set(stock:sku_123, $dbStock); } $left Cache::store(redis)-handler()-decr(stock:sku_123); if ($left 0) { // 恢复库存并提示库存不足 Cache::store(redis)-handler()-incr(stock:sku_123); throw new \Exception(库存不足); }这里用到了Cache::store(redis)-handler()拿到的是ThinkPHP包装下的原生Redis对象可以直接调用decr、incr、expire这些底层命令。单纯用Cache::getCache::set两步操作在高并发下会出现竞态两个请求都读到相同库存然后各自写回导致超卖。分布式锁的场景更微妙。比如后台有一个定时报表的生成任务定时任务被设置成每分钟执行一次但上次执行还没结束下一次又开始了最终导致重复生成、表格数据翻倍。用Redis锁就可以避免$lockKey lock:report_generate; $lockAcquired Cache::store(redis)-handler()-set($lockKey, 1, [nx, ex 60]); if (!$lockAcquired) { // 说明任务还在执行中直接跳过本次 return; } try { // 执行报表生成逻辑 } finally { // 任务结束释放锁 Cache::rm($lockKey); }上面的set命令用了nx只在key不存在时生效和ex过期时间60秒两个选项配合起来就是Redis社区标准分布式锁的雏形。注意一定要给锁设置过期时间否则程序异常退出锁永远不会释放后续所有任务都会被卡住。3.4 队列与异步化把耗时任务挪出去Fastadmin做“批量发送邮件”“Excel导出大列表”“推送通知”这类操作时页面会卡很久。我的做法是引入ThinkPHP官方推荐的think-queue队列组件驱动改成Redis。队列本质就是一个List结构生产者把任务用Queue::push()写入Redis的List消费者通过命令php think queue:work从List左侧取出任务执行执行完后用Queue::later()安排延时任务。接入之后后台的发送通知、报表生成、数据导入等全部变成“秒回”。用户点击按钮页面立即返回“任务已加入队列”真正的耗时操作在后台进程里悄悄完成。这在Fastadmin二开里是一个非常提体验的优化尤其适合用在插件开发里。有个细节提醒队列消费端一定要保证Redis里任务的安全性生产环境建议开启AOF持久化否则Redis进程意外重启队列里还没执行的任务会丢失。另外消费端代码里要try/catch任务执行失败时可以用$job-failed()回调记录日志并重试避免一条脏数据卡死整个队列。4. 常见问题与排查技巧实录4.1 错误速查表连接失败、功能异常、数据不一致现象常见原因排查与解决Connection refusedRedis未启动或端口被防火墙拦截本机先redis-cli ping通了再查PHP进程里的网络权限NOAUTH Authentication required服务端设置了密码配置里没填config/cache.php里补password或确认密码是否正确OOM command not allowedRedis内存满了触发了maxmemory限制增大maxmemory或配置合适的淘汰策略maxmemory-policy allkeys-lru缓存一直读不到新数据有多个Redis库或prefix不一致清掉旧前缀key统一prefix和select库编号接口偶发很慢大key或热点key存在导致Redis阻塞用redis-cli --bigkeys找出大key拆分或设置TTL存储的数组取出变成nullPHP序列化问题确认PHP的redis扩展序列化选项或统一用serialize处理4.2 我在项目里踩过的坑清理缓存误爆key设计不合理有一次上线后我发现后台“一键清缓存”按钮用了几次结果用户积分明细全部消失。排查后发现项目里把积分记录暂时也缓存进了Redis而Fastadmin后台的缓存清理工具会按照prefix批量删除所有匹配的key结果把业务数据也删了。打那以后我给自己定了一条规矩业务缓存的key前缀一定要和框架缓存的前缀区分开。比如框架缓存统一用fa_业务缓存单独用biz_并且清缓存的工具只允许处理框架前缀范围内的key。还有一次线上事故是大key问题。我把用户购物车数据整个塞进一个字符串一个key几MB高并发时读写都卡Redis拖慢了所有请求。用--bigkeys扫出来后才逐步改成Hash结构把单个商品条目独立成field读写性能改善非常明显。这个经历让我意识到Redis不是“什么都能往一个key里塞”的存储数据结构选错副作用是全链路级的。4.3 缓存一致性先更新数据库还是先更新缓存做缓存最难受的就是数据库和Redis的数据不一致。这个我吃过好几回亏结论是写操作永远先更新数据库再删除或更新缓存。为什么如果先更新缓存再更新数据库一旦数据库更新失败缓存里已经是新值用户看到的是不存在的数据。反过来先落库成功再删缓存即使删除失败旧缓存也会在TTL到期后自动失效影响范围有限。还有更严格一点的方案叫“延迟双删”先删缓存再更新数据库睡几百毫秒后再次删缓存。这么做是因为并发读请求可能在第一次删除后把旧数据重新写回缓存延迟再删一次能用兜底方式保证最终一致。不过对于大多数Fastadmin后台项目用好“先更库再删缓存 合理的TTL”已经足够稳定过度设计只会增加代码复杂度。4.4 缓存雪崩、击穿、穿透的三个对策这三个词新手容易混。雪崩是大批key同一时间过期Redis里突然空了一大片所有请求瞬间打到数据库击穿是某一个热点key恰好过期同刻大量并发请求穿透到数据库穿透是查询了一个不存在的keyDB里也没有每次请求都会绕开缓存压向数据库。应对雪崩我给key的TTL加入随机抖动比如基础24小时再加0到3600秒的随机值避免集体过期。应对击穿用互斥锁让第一个请求去重建缓存其他请求等待缓存生成后直接读。应对穿透最简单的是把空结果也缓存到Redis设置一个较短的过期时间比如5分钟这样同一个不存在的数据不会反复打库。这套办法在Fastadmin的报表统计、商品详情这类高流量接口上都验证过效果稳定。4.5 Redis日志与监控别等出事了再开工具我在生产环境上会定期用redis-cli info查看内存、连接数、命中率。重点关注hits和misses两个指标计算缓存命中率长期低于60%说明缓存策略有问题要么key设置太短要么根本没缓存到有效数据。再关注connected_clients连接数异常上涨通常意味着代码里有连接泄漏比如每次请求都新建Redis连接而没有关闭复用。Fastadmin如果用了ThinkPHP缓存组件底层连接池由框架管理一般不会出现连接泄漏但用了Cache::store(redis)-handler()直接操作原生Redis时要记得长生命周期进程下归还连接或适当重连。日志方面我习惯把Redis的慢命令日志开起来在redis.conf中设置slowlog-log-slower-than 10000超过10毫秒的命令记录下来定期分析是哪些key产生了热点压力。写到最后一些个人体会如果你正准备在Fastadmin里接入Redis我的建议是从最小的点开始改比如先把验证码和Token切到Redis观察几天稳定了再把高频查询的业务数据加缓存。不要一次把所有模块都改造完毕那样出了问题排查范围会非常大。我第一次改造就想着一步到位结果验证码、队列、缓存全上线上出现一次key冲突后光定位就花了整整一天。另外Redis的配置和运维不能只是“装好了就完”。密码、持久化、淘汰策略、key前缀、监控脚本这些事我建议在接入当天就全部弄好。像maxmemory-policy如果不设置Redis内存满了会直接拒绝写入该报错报错比那种内存耗尽导致整台服务器卡死要好很多。给它设一个合理上限比如物理内存的一半再配上allkeys-lru至少能保证服务不会以最坏的方式挂掉。最后分享一个小技巧后台的“清缓存”功能建议做成可选项区分“清理框架缓存”和“清理业务缓存”并且每次清理后把清理的key数量和耗时记录到日志里。这能帮你快速判断是不是有外部操作引起缓存大面积失效也是我后来维护多个Fastadmin项目时排查效率最高的一个抓手。
