独立开发在线客服系统 3 年终于稳如老狗了记录我踩过的坑一从 2021 年初开始我独立开发了一套在线客服系统。起初它只是我为了应付一个客户小项目的临时方案没想到后来竟然演变成了一款运行三年的稳定产品。这三年里我踩过的坑比走过的路还多——从数据库设计到并发处理从消息实时性到系统瓶颈每一个环节几乎都经过血泪教训。今天我想从最基础的编程概念讲起一步步记录下这些坑希望能帮到正在或即将开发类似系统的你。### 基础概念别小看“会话”与“消息”的模型设计刚开始开发在线客服系统时我犯的第一个低级错误就是把会话和消息混为一谈。我以为只要有一个message表记录聊天内容就够了。结果上线不到一周就发现客户查历史记录时页面加载要好几秒——因为每次都要扫描整个消息表。正确的做法是会话Session和消息Message是独立的概念。会话代表一次客服与用户的对话周期它包含多条消息。会话在生命周期结束时关闭但消息是流式追加的。以下是我最初踩坑时重构的模型代码示例使用 Python 和 SQLAlchemypython# models.py - 正确分离会话与消息模型from datetime import datetimefrom sqlalchemy import Column, Integer, String, DateTime, ForeignKey, Textfrom sqlalchemy.orm import relationshipfrom database import Baseclass Session(Base): 会话模型代表一次完整的对话 __tablename__ sessions id Column(Integer, primary_keyTrue) user_id Column(String(64), nullableFalse, indexTrue) # 用户标识 agent_id Column(String(64), nullableTrue) # 客服标识 status Column(String(16), defaultactive) # active, closed created_at Column(DateTime, defaultdatetime.utcnow) closed_at Column(DateTime, nullableTrue) # 关联消息一对多关系 messages relationship(Message, back_populatessession, order_byMessage.timestamp)class Message(Base): 消息模型属于某个会话的单独记录 __tablename__ messages id Column(Integer, primary_keyTrue) session_id Column(Integer, ForeignKey(sessions.id), nullableFalse, indexTrue) sender_type Column(String(8)) # user 或 agent content Column(Text, nullableFalse) timestamp Column(DateTime, defaultdatetime.utcnow) # 反向关联到会话 session relationship(Session, back_populatesmessages)这个简单分离的好处是查询某个会话的历史消息时只需要session.messages就能拿到所有数据而不用全表扫描。查询性能从 O(n) 降到了 O(1)通过外键索引。后来系统运行一年后消息表超过 500 万条这个设计依然撑住了。### 进阶坑并发下的消息排序与丢失基础模型搞定了但上线后没两天就遇到第二个坑多个客服同时处理同一个会话时消息顺序混乱甚至偶尔丢失。问题出在数据库的事务隔离级别上。默认的 MySQL InnoDB 级别是READ COMMITTED但我的代码用了autocommitTrue导致两个并发插入的Message可能被当成不同事务顺序和实际发送时间不一致。更糟的是如果用户和客服同时发消息没有锁机制可能会覆盖同一行。修复方案很简单在插入消息时使用session级别的锁或者至少用SELECT ... FOR UPDATE来确保顺序。更优雅的方式是引入一个“消息序列号”字段。下面是改进后的代码演示了如何使用乐观锁来保证消息顺序python# message_service.py - 处理并发消息插入from sqlalchemy import func, and_from sqlalchemy.orm import Session as DBSessionfrom models import Session, Messagedef add_message(db: DBSession, session_id: int, sender_type: str, content: str) - Message: 安全添加消息使用乐观锁保证顺序 - 先获取当前会话的最大序号 - 插入新消息序号自增 - 如果冲突则重试最多3次 max_retries 3 for attempt in range(max_retries): try: # 步骤1锁定会话行防止并发修改 db.query(Session).filter(Session.id session_id).with_for_update().first() # 步骤2查询当前最大序号 max_seq db.query(func.max(Message.seq_number)).filter( Message.session_id session_id ).scalar() or 0 # 步骤3创建新消息序号1 new_message Message( session_idsession_id, sender_typesender_type, contentcontent, seq_numbermax_seq 1, # 手动分配序号 timestampdatetime.utcnow() ) db.add(new_message) db.commit() return new_message except IntegrityError as e: # 如果序号冲突罕见情况 db.rollback() if attempt max_retries - 1: raise RuntimeError(消息插入失败重试耗尽) from e continue # 重试这段代码的关键是with_for_update()和手动分配的seq_number。它保证了即使两个客服同时发消息也不会出现乱序。运行一年后系统处理了上百万次消息没有一次乱序或丢失——稳如老狗。### 总结从基础模型设计到并发处理独立开发一个在线客服系统每一步都可能踩坑。第一年我花了很多时间在数据库设计上后来才明白会话和消息要分开并发下必须用锁或序号保证顺序。这些看似简单的概念背后是无数次线上事故换来的经验。如果你也在开发类似系统记住永远不要相信默认行为特别是并发场景。下一篇文章我会分享 WebSocket 实时推送和消息队列的踩坑经历。希望这些记录能让你少走弯路。