多租户在线客服系统源码是一套把同一份程序卖给多家企业的客服中台：以租户为最高隔离维度，每个租户自带坐席、渠道、话术库与统计口径，数据在库层与缓存层双向隔离。它的难点在租户识别、坐席分配策略与消息通道的稳定性，接入侧通常同时支持网页、App 与 Telegram 等外部渠道。

一个前提判断：多租户不是「加个字段」那么简单。 从单租户改造成多租户，工作量通常超过重写一遍，这是接手这类源码时最该先确认的事。

多租户在线客服系统源码是一套什么系统？

它本质上是一套带租户维度的会话分发型后台。访客从一个渠道发起咨询，系统先生成会话，再按分配策略派给某个坐席，坐席在工作台里回消息，全过程留档并进统计。

四层结构要分清：

租户层：企业账户、套餐、坐席上限、可用渠道。 坐席层：账号、角色、技能组、在线状态、并发上限。 会话层：访客标识、渠道、来源页、分配记录、状态流转。 消息层：文本、图片、文件、卡片，带发送方与时间戳。

租户标识必须从入口就确定。 靠域名、靠接入码、靠 URL 参数都行，但要固定一种，别混着用。混用的结果是某个入口漏了租户判断，数据直接串到别人家。

租户隔离要怎么做才算彻底？

库层加租户字段，缓存加租户前缀。两处任缺一处，都可能串数据。

具体要守住的四条：

所有业务表都带租户字段。 包括看起来「全局」的表，比如话术库、标签、快捷回复——这些在不同企业之间内容完全不同。

查询必须由框架统一注入条件。 靠开发每次手写 where tenant_id = ? 一定会漏。比较稳的做法是在数据访问层做拦截，业务代码不感知。

缓存键带租户前缀。 坐席在线状态、会话未读数这类高频数据都在缓存里，键名不带租户，不同企业的坐席会互相挤掉。

文件存储按租户分目录。 图片与附件尤其要分，否则一个租户的素材会出现在另一个租户的素材库里。

还要防越权。 坐席 A 拿到坐席 B 的会话 ID，能不能打开？这是多租户系统最常见的漏洞点，接口层必须校验「该会话属于当前租户且该坐席有权限」。

坐席分配有哪几种常见策略？

轮询、按负载、按技能组。小团队用轮询就够，大团队要靠技能组。

实际落地通常组合使用：

轮询：按在线坐席顺序派，实现最简单，适合咨询量均匀的场景。缺点是遇到复杂问题会砸在同一个人身上。

按负载：派给当前会话数最少的坐席。要求系统能实时掌握每个坐席的并发数，实现上依赖状态同步。

按技能组：先按问题类型（售前、售后、技术、账单）分组，组内再轮询。这是多数中型企业的实际选择。

按来源分配：把某个渠道或某个页面的咨询固定给一组人，常用于「大客户专线」。

超时转派是必须做的兜底。坐席接了不说话，或者直接关掉页面，会话要有超时机制自动回到队列。没有这个机制，访客的体验是「发出去没人理」，而系统里显示的是「已分配」。

消息通道要处理哪些问题？

核心是三个：长连接维持、消息幂等、离线补偿。

长连接维持：网页侧用长轮询或 WebSocket，移动端要考虑切后台断连。断连后的重连策略要带退避，否则服务端会被重连风暴打穿。

消息幂等：同一条消息可能因为重试被投递两次。每条消息带客户端生成的唯一 ID，服务端按 ID 去重，比靠时间戳可靠。

离线补偿：坐席离线期间的消息要有队列，上线后按顺序补齐并标未读。直接丢弃是最常见的偷懒做法，也是最容易被客户投诉的一点。

顺序不能乱。 同一会话内的消息必须按发送顺序展示，多端同步时尤其容易出错——手机端和网页端同时在线，两边的时间线经常对不上。

接 Telegram 这类外部渠道难在哪？

在长连接维持与消息幂等。断线重连后，重复消息会比丢消息更麻烦。

外部渠道接入的通用套路是一个渠道适配层：把不同渠道的消息统一成内部格式，回复时再转回渠道格式。

需要专门处理的几件事：

身份映射。 外部渠道的用户 ID 与站内访客 ID 要有一张映射表，否则同一个人从两个渠道来会被当成两个人。

媒体文件。 图片、语音、文件要落地到自己的存储，不能只存外部链接——链接会失效。

限流。 外部平台通常有发送频率限制，超限会被暂时封禁。发送侧要有队列与退避。

审核与合规。 部分渠道对消息内容有额外要求，涉及敏感词的要先过一遍过滤。

多租户模式怎么收费比较合理？

按坐席数分档最稳。按会话量计费，客户会为了省钱少开窗口。

几种常见模型的取舍：

按坐席数：最直观，客户能预期成本，也便于销售报价。缺点是客户会共享账号来省坐席。

按会话量：与用量挂钩，看起来公平。缺点是客户会压缩会话数，反而影响服务质量。

按渠道数：适合只做单一渠道的小客户，对多渠道客户不友好。

混合：基础坐席费加超量会话费。实施上最复杂，但覆盖的客户类型最广。

套餐里一定要限制历史数据保留期。 会话与消息是最占空间的数据，不设上限，两年后存储成本会超过收入。

上线前最该自查什么？

三个检查项，都是踩过坑的地方：

租户切换不串数据。 用两个租户各建一个坐席，互相发消息，确认两边都看不到对方的会话、素材、标签、统计。

并发压测。 客服系统的特点是「平时很闲，活动时瞬间爆」。按峰值的三倍做压测，重点看消息投递延迟。

权限矩阵完整。 主管能看全部会话但不能改坐席密码，坐席能改自己状态但不能删会话记录。这类细粒度权限如果没做，运营半年后一定会被要求补。

延伸阅读