简介即时通讯IM系统是现代Web应用的核心功能之一其核心在于通过WebSocket协议实现客户端与服务器的全双工实时通信。从技术原理上看WebSocket克服了HTTP协议的无状态和单向通信限制允许服务端主动推送数据是实现聊天、通知等实时场景的基石。其技术价值在于能够极大提升用户体验保证消息的即时性与交互的流畅性。在工程实践中高并发场景下的连接管理、消息可靠投递与状态同步是主要挑战。这通常需要结合协程编程、内存数据库与关系型数据库的混合存储架构来解决。应用场景广泛从在线客服、社交应用到协同办公均依赖于此技术栈。本文聚焦于使用高性能PHP协程框架EasySwoole处理WebSocket长连接并利用Redis作为消息队列与在线状态缓存配合MySQL进行数据持久化详细拆解一个轻量级、可落地的客服支持平台从设计到实现的全过程涵盖连接管理、消息流转、会话分配等核心模块。1. 项目概述与核心价值最近在做一个内部客服支持平台核心需求很简单让用户能在网页上直接和客服人员实时沟通消息不能丢响应要快体验要流畅。市面上成熟的客服系统很多但要么太臃肿要么定制化成本高要么就是按坐席收费对于中小团队或者想深入理解即时通讯IM底层逻辑的开发者来说自己动手搭一个轻量级的轮子是性价比和成长性都极高的选择。我这次选择的方案是EasySwoole Redis MySQL LayIM。EasySwoole是一个基于Swoole扩展的高性能PHP协程框架用它来处理WebSocket长连接和并发请求再合适不过Redis作为消息的中转站和在线状态管理保证速度MySQL则负责持久化存储聊天记录和用户数据最后前端用LayIM这个现成的开源IM UI组件快速搭建界面。这套组合拳下来从后端到前端从连接管理到数据存储每个环节都有成熟、高效的开源方案支撑让我们能把精力集中在业务逻辑和系统设计上而不是重复造轮子。这个项目适合两类朋友一是正在寻找一个可落地的、完整的IM项目来练手和深入学习WebSocket、协程编程的PHP开发者二是需要为自家产品如电商、教育、内部OA快速集成一个轻量、可控的客服聊天功能的技术负责人。通过拆解这个项目你不仅能得到一个可运行的源码更能掌握一套高并发实时通讯系统的设计心法。2. 技术栈选型与架构设计思路2.1 为什么是EasySwoole在PHP生态里做实时通讯绕不开Swoole。它让PHP突破了传统FPM模式的瓶颈可以常驻内存轻松处理成千上万的并发TCP/UDP/WebSocket连接。而EasySwoole是在Swoole基础上封装的一个协程框架它提供了更友好的开发体验和一系列开箱即用的组件比如HTTP控制器、ORM、连接池等。选择EasySwoole的核心原因有三点一是性能基于协程的异步非阻塞IO在IO密集型如大量消息推送的场景下优势巨大二是开发效率它保留了MVC的熟悉感降低了从传统PHP开发切换到常驻内存模式的学习成本三是生态其内置的WebSocket控制器和全局事件注册机制让我们能非常清晰地管理连接生命周期和消息路由。相比自己裸写Swoole ServerEasySwoole帮我们处理了很多底层细节比如平滑重启、热重载、连接池管理等让我们能更专注于业务。2.2 数据存储的“黄金搭档”Redis与MySQL的分工在IM系统中数据流大致分两类状态数据和持久化数据。状态数据如用户的在线/离线状态、未读消息数、当前连接FD文件描述符映射这些数据要求极高的读写速度和临时性Redis的内存存储特性完美匹配。持久化数据就是聊天记录、用户信息、客服分组等需要可靠存储和复杂查询这是MySQL的强项。具体分工如下Redis在线状态哈希表以online:user:{uid}为key存储其连接的FD、登录时间等信息。FD到UID的映射以fd:map:{fd}为key快速通过FD反查是哪个用户。消息队列用于异步任务比如将需要持久化的消息先推到Redis的List中由后台进程消费写入MySQL削峰填谷。未读消息计数使用incr/decr命令原子性操作。分布式锁在客服分配、敏感操作时防止并发冲突。MySQL用户表存储客服和普通用户的基本信息、账号密码加密后。会话表记录每一次客服会话的元信息如会话ID、创建时间、参与用户、状态进行中/已结束等。消息表核心表存储每一条消息的发送者、接收者、内容、时间、是否已读、消息类型文本/图片/文件等。这里表结构设计要考虑分表或分区以防单表过大。这种“Redis扛并发MySQL保落地”的架构是经过大量实践验证的经典模式在保证性能的同时确保了数据的可靠性。2.3 前端利器LayIM的定位与集成LayIM是一个由贤心大神开发的前端WebIM组件它提供了聊天界面、好友列表、群组、消息收发、表情发送、图片/文件上传等完整的UI和交互。对于这个项目来说它极大地加速了前端开发。我们不需要从零开始写聊天窗口、处理消息气泡、做复杂的CSS布局只需要关注如何与后端的WebSocket服务进行数据交互以及如何渲染LayIM需要的数据格式。LayIM通过JavaScript SDK暴露了丰富的接口如初始化、连接、监听消息、发送消息等。我们的工作就是搭建一个EasySwoole的WebSocket服务按照LayIM约定的数据格式通常是JSON包含type,data等字段进行通信。例如当后端收到一条消息后将其包装成LayIM能识别的格式推送给前端渲染。这种前后端分离、通过协议对接的方式使得前端可以独立迭代后端也可以服务多种不同的客户端。3. 核心模块设计与实现详解3.1 WebSocket服务搭建与连接管理在EasySwoole中我们通过继承WebSocketController来快速创建一个WebSocket服务器。在onOpen事件中当客户端浏览器通过LayIM SDK成功连接时我们会收到一个$fd。此时我们需要进行用户认证。通常LayIM前端在连接时会携带一个token例如登录后后端颁发的JWT。// 伪代码示例在WebSocketController的onOpen方法中 public function onOpen(Request $request, Response $ws) { $fd $ws-getFd(); $get $request-getQueryParams(); $token $get[token] ?? ; // 1. 验证Token获取用户ID (uid) $uid $this-authToken($token); if (!$uid) { $ws-close(); return; } // 2. 将 uid 和 fd 的关联关系存入Redis $redis \EasySwoole\RedisPool\RedisPool::defer(redis); $redis-set(online:user:{$uid}, $fd); $redis-set(fd:map:{$fd}, $uid); $redis-hSet(user:status, $uid, online); // 存储在线状态 // 3. 通知该用户的好友或客服其状态已变更为在线 $this-broadcastStatusChange($uid, online); }连接管理的核心在于维护fd与uid的双向映射。fd是Swoole底层标识一个TCP连接的唯一ID而uid是我们的业务用户ID。所有消息推送最终都需要通过fd来发送。因此当用户连接时建立映射断开时onClose事件清除映射并更新状态为离线。注意在高并发下fd可能会被复用。务必在onClose事件中先根据当前fd从Redis中取出uid再执行清理逻辑避免误删其他新连接的用户映射。3.2 消息流转的核心逻辑发送、接收与推送消息的完整生命周期是IM系统的核心。我们定义一套简单的通信协议消息体至少包含type消息类型如chat、system、from发送者、to接收者可以是用户ID或客服组ID、content内容、timestamp时间戳。1. 发送消息前端LayIM调用send方法将消息JSON发送到WebSocket服务。服务端在onMessage事件中接收。public function onMessage(Server $server, Frame $frame) { $data json_decode($frame-data, true); switch ($data[type]) { case chat: // 1. 消息预校验发送者是否有权限接收者是否存在等 // 2. 生成全局唯一消息ID如雪花算法 $msgId $this-generateMsgId(); $data[msg_id] $msgId; $data[timestamp] time(); // 3. 异步投递到Redis队列供持久化进程消费 $redis RedisPool::defer(redis); $redis-lPush(msg_queue, json_encode($data)); // 4. 实时推送消息给接收方 $this-pushToReceiver($data); break; // ... 处理其他类型消息如心跳、状态变更等 } }2. 推送消息pushToReceiver方法负责找到接收者并推送。private function pushToReceiver($msgData) { $toUid $msgData[to]; $redis RedisPool::defer(redis); // 查找接收者是否在线 $receiverFd $redis-get(online:user:{$toUid}); if ($receiverFd) { // 在线直接通过WebSocket推送 $this-server()-push($receiverFd, json_encode([ type msg, data $msgData ])); // 可以同时发送一个“消息已送达”的回执 $this-sendReceipt($msgData[msg_id], $toUid, delivered); } else { // 离线存储为未读消息等其上线后拉取 $redis-lPush(offline:msg:{$toUid}, json_encode($msgData)); $redis-incr(unread:count:{$toUid}); } }3. 消息持久化我们启动一个独立的EasySwoole进程或自定义Worker来消费Redis中的msg_queue。// 在自定义进程的run方法中 while(true) { $rawMsg $redis-brPop(msg_queue, 5); // 阻塞弹出 if ($rawMsg) { $msg json_decode($rawMsg[1], true); // 1. 写入MySQL消息表 $this-saveMessageToMySQL($msg); // 2. 如果是客服会话消息可能需要更新会话表的最后消息时间和内容 $this-updateSession($msg); } // 可以加入适当的sleep防止空转消耗CPU }这种异步写库的方式将实时推送和耗时持久化解耦保证了消息发送的及时性避免了因数据库写入慢而阻塞消息响应。3.3 客服侧的特殊逻辑会话分配与负载均衡在客服系统中用户通常不是直接联系某个特定客服而是先进入一个公共队列由系统分配给一个空闲的客服。这里涉及会话分配策略。一个简单的策略是用户在界面点击“联系客服”前端发送一个type为request_service的消息。后端收到后从Redis中查询所有状态为online且busy状态为false空闲的客服ID。使用简单的轮询Round Robin或选择当前接待会话最少的客服进行分配。在Redis中创建一个session:{session_id}的哈希记录客服ID、用户ID、创建时间。将session_id返回给用户和对应的客服双方后续的聊天消息都带上这个session_id以便后端识别和路由。更复杂的策略可以考虑客服的技能组、优先级等。关键在于会话的绑定关系需要存储在Redis中以保证分配和查询的速度。当客服离线时需要将其接待中的会话重新分配给其他在线客服。3.4 前端LayIM的集成与配置前端的工作相对聚焦。首先引入LayIM的JS和CSS文件然后进行初始化。layui.use(layim, function(layim){ // 初始化配置 layim.config({ // 初始化WebSocket连接 init: { url: ws://your-domain.com:9501?token your_token, // 你的EasySwoole WS地址 type: ws }, // 设置客服信息可以从后端接口异步加载 chatList: [{ type: kefu, id: kefu_group, name: 客服组, avatar: //... }], // 其他皮肤、工具栏配置... }); // 监听连接建立 layim.on(ready, function(res){ console.log(WebSocket连接已建立, res); }); // 监听收到消息 layim.on(chatMessage, function(data){ // data 就是后端推送过来的消息格式 console.log(收到消息, data); // LayIM会自动渲染到聊天窗口 }); // 发送消息的接口已被LayIM封装我们只需确保后端能正确处理 });关键在于后端WebSocket服务推送的消息格式必须符合LayIM的chatMessage事件要求。通常LayIM期望的单个消息对象包含username,avatar,id,type,content,timestamp等字段。我们需要在后端的pushToReceiver方法中将我们的业务消息结构转换成LayIM能识别的结构。4. 数据库与缓存设计实战4.1 MySQL表结构设计要点这里给出最核心的三张表设计思路用户表 (user)CREATE TABLE user ( id int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL DEFAULT COMMENT 用户名, password varchar(255) NOT NULL DEFAULT COMMENT 加密密码, avatar varchar(255) NOT NULL DEFAULT COMMENT 头像, role tinyint(1) NOT NULL DEFAULT 1 COMMENT 角色1-普通用户2-客服, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 状态0-禁用1-启用, last_login_time int(11) NOT NULL DEFAULT 0 COMMENT 最后登录时间, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY idx_username (username), KEY idx_role_status (role,status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;会话表 (chat_session)CREATE TABLE chat_session ( session_id varchar(32) NOT NULL COMMENT 会话唯一ID, user_id int(11) NOT NULL COMMENT 用户ID, kefu_id int(11) NOT NULL COMMENT 客服ID, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 状态1-进行中2-已结束, last_msg text COMMENT 最后一条消息内容冗余方便列表展示, last_msg_time int(11) NOT NULL DEFAULT 0 COMMENT 最后消息时间, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (session_id), KEY idx_user_id (user_id), KEY idx_kefu_id (kefu_id), KEY idx_status_time (status,last_msg_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT聊天会话表;心得session_id可以用md5(user_id kefu_id timestamp)或更复杂的算法生成确保唯一。last_msg和last_msg_time是典型的空间换时间设计避免在拉取会话列表时为每个会话都去查最后一条消息极大提升列表查询性能。消息表 (chat_message)CREATE TABLE chat_message ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 自增ID内部使用, msg_id varchar(64) NOT NULL COMMENT 业务消息ID如雪花ID用于去重、索引, session_id varchar(32) NOT NULL COMMENT 所属会话ID, from_uid int(11) NOT NULL COMMENT 发送者ID, to_uid int(11) NOT NULL COMMENT 接收者ID, msg_type varchar(20) NOT NULL DEFAULT text COMMENT 消息类型text, image, file, content text NOT NULL COMMENT 消息内容文本内容或文件URL, is_read tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否已读0-未读1-已读, sent_at int(11) NOT NULL COMMENT 消息发送时间戳, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_msg_id (msg_id), KEY idx_session_id (session_id), KEY idx_from_uid_sent (from_uid,sent_at), KEY idx_to_uid_read (to_uid,is_read,sent_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT聊天消息表;核心要点msg_id必须是全局唯一的业务ID使用雪花算法生成并建立唯一索引防止消息重复入库。索引设计是关键。idx_session_id用于拉取某个会话的历史消息。idx_from_uid_sent和idx_to_uid_read用于查询某个用户的所有消息或未读消息。根据查询模式仔细设计索引。考虑到消息量可能巨大初期可以按session_id哈希或按时间如每月进行分表。可以在业务代码中做路由或者使用MySQL的分区功能。4.2 Redis数据结构设计与应用场景Redis在此系统中扮演着“高速缓存”和“状态中枢”的角色。String类型online:user:{uid}-fd用户在线FD映射。fd:map:{fd}-uidFD到用户的逆向映射。unread:count:{uid}-数字用户未读消息总数。user:token:{token}-uid临时存储Token与UID的映射用于WebSocket连接时的快速认证可设置过期时间。Hash类型user:status- field:{uid}, value:online/offline全局用户在线状态表方便批量查询或客服分配时快速筛选在线客服。session:info:{session_id}- field:kefu_id,user_id,created_at等存储会话的详细信息。List类型msg_queue消息持久化队列。offline:msg:{uid}用户的离线消息队列。用户上线后从此队列中取出所有消息推送并清空队列。Sorted Set类型kefu:busy:level可以用来实现更智能的客服分配。以客服ID为member以当前接待数或空闲时长作为score。分配时直接取score最小最闲的客服。实操技巧为所有业务Key设置一个统一的前缀如im:并在Redis中按业务模块分类im:online:,im:msg_queue:这样既清晰也方便后期通过KEYS im:online:*这样的命令进行模式匹配和批量管理。务必为这些Key设置合理的TTL过期时间防止无效数据长期占用内存比如离线消息队列可以设置7天过期。5. 关键代码实现与避坑指南5.1 EasySwoole事件注册与全局容器使用在EasySwoole的initialize事件EasySwooleEvent.php中我们需要完成一些全局初始化工作比如注册数据库、Redis连接池。// EasySwooleEvent.php 中的 initialize 方法 public static function initialize() { date_default_timezone_set(Asia/Shanghai); // 1. 注册MySQL连接池 $mysqlConfig Config::getInstance()-getConf(MYSQL); DbManager::getInstance()-addConnection(new Connection( new MysqlConfig($mysqlConfig) )); // 2. 注册Redis连接池 (非常重要协程环境下必须用连接池) $redisConfig Config::getInstance()-getConf(REDIS); $redisPoolConfig new RedisPoolConfig(new \EasySwoole\Redis\Config\RedisConfig($redisConfig)); RedisPool::getInstance()-register(redis, $redisPoolConfig)-setMinObjectNum(5)-setMaxObjectNum(20); // 3. 注册自定义进程用于消费消息队列 $processConfig new ProcessConfig(); $processConfig-setProcessName(MsgConsumer); ProcessManager::getInstance()-addProcess(new MsgConsumerProcess($processConfig)); }避坑指南连接池是必须的在协程环境中直接创建连接会导致资源耗尽和性能瓶颈。务必使用连接池来管理MySQL和Redis连接。对象池配置根据服务器内存和并发量合理设置连接池的minObjectNum和maxObjectNum。太小会影响性能太大会浪费内存。自定义进程像消息队列消费者这类后台任务最好封装成自定义进程。这样它们独立于Worker进程运行不会阻塞主业务逻辑并且进程挂掉后Manager进程会自动重启它。5.2 消息唯一ID生成与幂等性保障在分布式或高并发环境下消息重复是必须要考虑的问题。我们使用雪花算法Snowflake来生成全局唯一的msg_id。class SnowflakeIdGenerator { private static $epoch 1609459200000; // 2021-01-01 00:00:00 UTC自定义起始时间戳 private static $machineId 1; // 机器ID单机可固定多机需配置 private static $sequence 0; private static $lastTimestamp -1; public static function generate(): string { $timestamp (int)(microtime(true) * 1000); if ($timestamp self::$lastTimestamp) { // 同一毫秒内序列号自增 self::$sequence (self::$sequence 1) 0xFFF; // 序列号占12位最大值4095 if (self::$sequence 0) { // 当前毫秒序列号用尽等待下一毫秒 while ($timestamp self::$lastTimestamp) { $timestamp (int)(microtime(true) * 1000); } } } else { self::$sequence 0; } self::$lastTimestamp $timestamp; // 组装ID时间戳(41位) | 机器ID(10位) | 序列号(12位) $id (($timestamp - self::$epoch) 22) | (self::$machineId 12) | self::$sequence; return (string)$id; } }在消息处理入口onMessage和消息持久化消费端都需要用这个msg_id做幂等判断。在写入MySQL前可以先查一下msg_id是否存在或者依赖数据库的唯一索引来去重。5.3 心跳检测与断线重连机制WebSocket连接可能因为网络波动、客户端休眠等原因断开。我们需要实现心跳机制来保持连接活跃并及时清理僵尸连接。服务端心跳在EasySwoole的WebSocket控制器中可以定时向客户端发送Ping帧或者由客户端定时发送Pong帧。可以在onMessage中处理心跳包。case ping: // 收到客户端心跳更新其活跃时间 $redis-setex(heartbeat:fd:{$fd}, 60, 1); // 设置60秒过期 // 可以回复一个pong $ws-push($frame-fd, json_encode([type pong])); break;同时在EasySwoole的主服务中可以设置heartbeat_check_interval和heartbeat_idle_time参数让Swoole底层自动检测并关闭不活跃的连接。客户端重连LayIM本身提供了断线重连的机制。我们需要在前端监听onDisconnect事件并在该事件中尝试重新连接。重连时需要重新携带Token进行认证。一个健壮的重连逻辑应包括指数退避策略避免频繁重连对服务器造成压力。5.4 文件上传与多媒体消息处理LayIM支持发送图片和文件。通常的做法是前端通过LayIM的接口或单独的表单上传文件到后端的一个HTTP接口可以是同一个EasySwoole服务内的HTTP控制器。后端接收文件将其保存到对象存储如阿里云OSS、腾讯云COS或本地服务器需考虑带宽和扩容生成一个可访问的URL。后端将这个URL作为contentmsg_type设为image或file构造一条消息后续流程与文本消息完全一致推送、入队列、持久化。前端LayIM在收到image类型的消息时会自动将content中的URL渲染为图片。关键点文件上传接口要做好安全校验文件类型、大小限制、重命名防止文件名冲突、目录权限管理。如果使用本地存储还需要考虑静态资源的访问问题可以通过Nginx配置一个静态资源服务器。6. 部署、优化与常见问题排查6.1 服务部署与进程管理建议使用Docker Docker Compose进行部署将MySQL、Redis、EasySwoole应用分别容器化便于环境统一和扩展。# docker-compose.yml 示例 version: 3 services: mysql: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: your_password MYSQL_DATABASE: im_db volumes: - ./mysql_data:/var/lib/mysql ports: - 3306:3306 redis: image: redis:alpine command: redis-server --appendonly yes volumes: - ./redis_data:/data ports: - 6379:6379 app: build: ./app depends_on: - mysql - redis ports: - 9501:9501 # WebSocket端口 - 9502:9502 # 可能有的HTTP管理端口 volumes: - ./app:/www在宿主机上使用Supervisor来管理EasySwoole的主进程确保服务崩溃后能自动重启。; /etc/supervisor/conf.d/im.conf [program:easyswoole] command/usr/local/bin/php /www/easyswoole start directory/www autostarttrue autorestarttrue userwww numprocs1 redirect_stderrtrue stdout_logfile/var/log/supervisor/easyswoole.log6.2 性能优化要点Swoole参数调优在EasySwoole的dev.php或produce.php配置文件中调整Swoole Server的参数。例如增加worker_numCPU核数的1-4倍、task_worker_num用于处理异步任务、调整max_connection、package_max_length根据消息大小调整等。连接池优化监控MySQL和Redis连接池的使用情况避免连接数不足成为瓶颈。可以适当调大maxObjectNum并确保在代码中使用defer或invoke正确归还连接。Redis持久化策略根据数据重要性配置RDB或AOF。对于在线状态这种可丢失的数据可以牺牲一些持久性换取更高性能。对于消息队列建议开启AOF以保证消息不丢。MySQL优化除了前面提到的索引和分表对于消息历史查询可以考虑使用SELECT ... WHERE session_id? ORDER BY id DESC LIMIT 20这种模式并确保(session_id, id)的联合索引。对于超大规模数据可以引入Elasticsearch专门做消息内容的搜索。6.3 常见问题与排查实录问题1客户端频繁断线重连。排查首先检查服务端和客户端的日志。服务端查看是否有错误日志如连接数超限、心跳超时。客户端查看浏览器Console的WebSocket错误。可能原因Nginx代理超时如果WebSocket通过Nginx代理需要配置proxy_read_timeout为一个较大的值如3600s。防火墙/云安全组检查9501端口是否在服务器防火墙和云服务商的安全组中开放。Swoole心跳配置检查服务端heartbeat_idle_time是否设置过短。客户端网络不稳定移动端网络切换时容易断开。问题2消息发送成功但对方收不到。排查检查发送方服务端onMessage逻辑是否执行到pushToReceiver。在pushToReceiver方法中打印日志查看接收者的uid和从Redis查出的fd是否正确。检查接收者前端LayIM的on(chatMessage)监听是否正常。可能原因Redis映射丢失接收者已下线但状态未及时清除导致查到了一个陈旧的fd。确保onClose事件中的清理逻辑绝对可靠。消息格式错误后端推送的消息格式不符合LayIM要求前端无法解析。用浏览器开发者工具查看WebSocket接收到的原始数据。跨域问题确保WebSocket连接地址ws://与前端页面地址http://在协议、域名、端口上符合同源策略或已正确配置CORS。问题3消息重复入库。排查检查数据库消息表是否存在msg_id重复的记录。解决方案消费端幂等在消费Redis队列消息的进程里在插入数据库前先根据msg_id查询是否存在。数据库唯一索引给msg_id字段加上唯一索引插入重复数据时会报错在代码中捕获这个重复错误记录日志并丢弃该条消息即可。这是最有效的一道防线。问题4客服分配不均有的客服很忙有的很闲。优化将简单的轮询分配改为基于负载的分配。在Redis中用一个有序集合kefu:workload来记录每个客服的当前会话数score。分配时使用ZRANGE kefu:workload 0 0 WITHSCORES获取负载最小的客服。每当客服开始或结束一个会话时就更新这个有序集合中对应客服的score。这样能实现更均衡的分配。这个基于EasySwoole的客服IM系统从架构设计到代码实现覆盖了实时通讯的核心环节。它不是一个玩具项目而是一个具备生产环境基本要素的、可扩展的解决方案。在实际开发中你还会遇到更多细节问题比如消息已读未读的状态同步、消息撤回、客服评价、数据统计等但万变不离其宗只要理解了上述核心流程和数据结构这些功能都可以在此基础上平滑地添加。本文还有配套的精品资源点击获取