CodeIgniter负载均衡与高可用方案

CodeIgniter作为轻量级PHP框架本身不支持负载均衡，真正的流量分发必须依赖Nginx、HAProxy等外部组件；而要让多个CodeIgniter实例在集群中稳定协同，关键在于三方面深度改造：用Redis集中管理会话杜绝反复登录、采用Redis/Memcached实现分布式缓存确保数据一致、配置数据库failover与超时降级机制提升容错能力——同时切记将日志和上传目录统一至共享存储或对象存储，否则再完善的架构也会因本地路径隔离而失效。

CodeIgniter 本身不内置负载均衡能力，它只是单实例 PHP 应用框架；真正的负载均衡必须由外部组件（如 Nginx、HAProxy、AWS ALB）完成。你能在 CodeIgniter 层面控制的，只有「如何让多个实例协同工作不翻车」——核心就三点：会话共享、缓存一致性、数据库连接健壮性。

会话不能存在文件里，否则用户反复登录

默认的 sess_driver = 'files' 会让每个服务器用自己的磁盘存 session，用户请求被轮到不同机器时，session_id() 还在，但数据找不到了，表现就是刚登录又跳回登录页。

• 强制改用集中式存储：Redis 最稳，配置 $config['sess_driver'] = 'redis'，并确保 $config['sess_save_path'] 指向同一 Redis 实例（如 'tcp://10.0.1.5:6379?database=1'）
• 数据库方案可用但慎选：如果用 'database' 驱动，表 ci_sessions 必须带 PRIMARY KEY(session_id) 和 INDEX(expire)，否则高并发下 SELECT ... WHERE expire 会拖慢整个会话读写
• 别碰 'cookie' 驱动：它把 session 数据加密后塞进 Cookie，大小受限、易被篡改、无法主动销毁，负载均衡场景下等于放弃状态管理

缓存驱动必须支持分布式，否则页面内容错乱

比如你在 A 服务器上执行了 $cache->save('user_123', $data, 300)，用户下次请求落到 B 服务器，$cache->get('user_123') 返回 null，就会重复查库或渲染旧数据。

• 文件缓存（file）完全失效：各服务器文件系统隔离，互不可见
• 推荐 Redis 或 Memcached：配置 $config['cache']['default']['driver'] = 'redis'，且所有服务器指向同一个集群；注意设置合理的 timeout 和 retry_interval，避免单点故障导致全站缓存雪崩
• APCu 只能用于单机：它是进程级共享内存，多 PHP-FPM worker 之间可共享，但跨机器无效，别在负载均衡中误用

数据库连接要容忍节点故障，不能一断就 500

当主库宕机或从库延迟飙升时，CodeIgniter 默认行为是抛出致命异常，整个请求失败。你需要让它“降级”而非“崩溃”。

• 启用读写分离时，务必配置 $db['group_name']['failover'] 数组，列出至少两个备用从库地址，框架会在主从库不可达时自动切换
• 在数据库配置中设 'connect_timeout' => 3 和 'timeout' => 5，防止某台 DB 响应慢拖垮整个 PHP 进程
• 避免在构造函数里直接调用 $this->db->query()：CI4 的控制器构造函数中，数据库服务可能尚未注入（没调 parent::__construct()），应改用方法级初始化或依赖注入

最常被忽略的是日志路径和上传目录——它们若仍指向本地 ./writable，就会出现 A 服务器写的日志 B 服务器看不到，用户上传的图片在另一台机器上 404。这些路径必须统一挂载到共享存储（如 NFS）或改用对象存储（S3/MinIO），不能靠框架本身解决。

今天关于《CodeIgniter负载均衡与高可用方案》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！