think-orm 2.0.62 单独设置数据表字段缓存驱动和数据缓存驱动
think-cache 拥有强大的多通道（Multi-store）管理能力，但问题的根源在于 think-orm 底层的调用机制太死板。即使您在 think-cache 中配置了 file 和 redis 两个完全独立的通道，think-orm 默认也只会向您通过 Db::setCache() 注入
WebSocket Server + 独立 RPC Server
从架构角度来说，它已经接近 think-swoole 能做到的极限了，但是我仍然不建议继续这样维护。 原因不是代码写法，而是 think-swoole 本身的事件模型。 第一处问题：addListener() 仍然共享 Worker 你的代码： $rpcServer = $server->addLi
Redis 的发布/订阅（Pub/Sub） 机制
在 think-swoole 中，如果项目开启了多个 Worker 进程或者部署了多台服务器，直接遍历 server->connections 只能触及当前进程下的连接。 要实现跨进程、跨服务器的广播，最成熟的方案是引入 Redis 的发布/订阅（Pub/Sub） 机制。这类似于 Socket.io
在 think-swoole 框架中融入 Custom Process（自定义进程）
在 think-swoole 框架中融入 Custom Process（自定义进程） 需要特别注意生命周期。因为 think-swoole接管了 Swoole\Server 的创建与启动，我们不能直接 $server->addProcess()，而是必须在 swoole.init 事件中，将自定义进
Swoole 的自定义进程（Process）
你目前是通过 think-swoole 框架提供的沙箱（Sandbox）在 swoole.init 事件中，使用主服务器的 $server->addListener(...) 来动态监听 RPC 端口（9513）。 正如之前分析的，$server->addListener() 产生的子端口，无法通过
为 RPC 端口和 Websocket 端口配置独立的 Worker 进程
在标准的 Swoole 中，子服务器端口（listen 产生的 Swoole\Server\Port）只能单独设置网络协议参数，无法直接通过 set(['worker_num' => X]) 来独立设置 Worker 进程数量。也就是说，默认情况下它们必然会共享主服务器的 Worker 进程。 为了
think-swoole 框架底层的一个“隐藏陷阱”
在 think-swoole 的底层实现中，当你调用 $websocket->to('room')->push($data) 时，由于 push 方法需要向特定的 FD 直接发送原始数据，框架为了保证主 Worker 进程不被网络 I/O 阻塞，在底层确实会自动把发送任务投递给 Task 进程去异步
think-swoole 自带的 Room
改用 think-swoole 自带的 Room（房间） 机制是解决线上高频广播丢包、阻塞的最正确姿势。 因为 Room 的底层完全基于 Swoole Table（内存共享表） 实现。当你要全员广播时，它不需要走传统的 Task进程，也不需要通过复杂的管道（Pipe）跨进程通信，更不需要你在代码里写
Task 队列阻塞与丢弃
在本地测试没问题，但线上在高并发、高频发布消息时出现“丢包”或“收不到信息”的现象，这在 think-swoole / Swoole 开发中非常典型。 虽然你配置了 task_worker_num = 8，但在高频广播消息的场景下，问题通常不是因为 Task 进程不够，而是由于 Swoole 的进程
think-swoole 全局广播
在 think-swoole 中，全局广播（向当前服务器上所有连接的客户端发送消息）通常有两种实现方式。 第一种是利用 think-swoole 内置的 Websocket 门面（Facade）或事件机制，适合单机部署；第二种是结合 Redis 发布/订阅（Pub/Sub），适合分布式/多机部署。