尧图网站建设 
简介这份资源是面向计算机专业毕业生与全栈开发学习者的微服务在线协同编辑系统完整源码可作为毕业设计、课程设计或微服务入门实战的参考方案。项目采用微服务架构前端基于 Vue 与 TypeScript 构建交互界面后端以 Java 实现核心业务逻辑并配套 Dockerfile、yml 与 conf 等部署配置便于理解服务拆分、接口协作与容器化部署的整体思路。压缩包共 253 个文件涵盖 82 个 Java 源文件、32 个 Vue 组件、22 个 TypeScript 与 17 个 JavaScript 脚本另有 xml、json、sql 及图片样式资源整体约 2.9MB目录结构清晰按模块划分便于检索。源码经过本地编译验证按文档配置环境后即可运行难度适中适合需要完整项目案例、排错思路与工程结构参考的读者。目前已有 195 人学习关注。1. 微服务架构下的在线协同编辑系统一个毕设项目为什么值得认真做如果你正在找一份能撑起毕设答辩、又能写进简历的完整项目基于微服务架构的在线协同编辑系统源码是一个被低估的方向。它不像电商秒杀那样烂大街也不像纯 CRUD 管理系统那样一眼看穿技术含量。协同编辑背后涉及实时通信、操作冲突消解、服务拆分与数据一致性这几个点随便拎一个出来都能在答辩时讲十分钟。我见过太多毕设项目把微服务三个字贴在单体应用上拆了两三个模块就敢叫微服务架构答辩老师一问服务间怎么通信、数据怎么同步就露馅。这个标题里的在线协同编辑系统核心难点在于多人同时编辑同一份文档时如何保证每个人的操作不丢失、不乱序、不覆盖。适合有一定 Java 或 Python 基础、想通过一个完整项目把微服务架构和实时协同两个方向串起来的同学。接下来我会从架构拆分、协同算法选型、源码落地步骤到踩坑排查把这条路走通。2. 微服务拆分与协同编辑的技术选型为什么不能只拆三个服务2.1 协同编辑系统的服务边界怎么划很多人拿到这个题目第一反应是拆成用户服务、文档服务、编辑服务三个模块就完事。这种拆法在答辩时会被追问编辑服务挂了用户的编辑操作丢不丢文档服务的数据和编辑服务的操作日志怎么对齐我一般会按职责边界拆成五个服务用户认证服务、文档管理服务、协同编辑服务、操作日志服务、通知服务。用户认证服务负责登录注册和 token 签发文档管理服务负责文档的增删改查和权限控制协同编辑服务是核心负责接收编辑操作、做冲突消解、广播给其他在线用户操作日志服务负责持久化每一次编辑操作用于回溯和版本恢复通知服务负责在线状态和消息推送。这样拆的好处是每个服务的职责单一协同编辑服务可以独立扩容操作日志服务可以用顺序写入优化性能。坏处是服务间通信变多需要引入消息队列来解耦。常见做法是用 WebSocket 维持客户端和协同编辑服务的长连接编辑操作通过消息队列异步写入操作日志服务文档管理服务通过 RPC 调用协同编辑服务获取最新文档状态。服务拆分的粒度没有标准答案但有一条原则如果两个模块的数据一致性要求极高、事务边界重叠就不要拆开。协同编辑服务和操作日志服务之间就是这种关系所以操作日志的写入要用最终一致性方案不能强求实时同步。2.2 协同算法选型OT 还是 CRDT这是整个项目最核心的技术决策。OTOperational Transformation和 CRDTConflict-free Replicated Data Type是两种主流方案。OT 的思路是每个编辑操作在应用到本地之前先根据并发操作做变换保证最终一致。CRDT 的思路是设计一种数据结构使得任意顺序应用操作都能得到相同结果。OT 的优点是成熟、有大量开源实现参考缺点是变换函数的正确性很难保证尤其是多用户多操作并发时变换矩阵会变得极其复杂。CRDT 的优点是天然支持分布式、不需要中心服务器做变换缺点是数据结构复杂、内存占用高、实现门槛不低。对于毕设项目我建议选 OT。原因很实际OT 有成熟的参考实现可以对照调试时能一步步跟踪变换过程答辩时也容易讲清楚。CRDT 虽然理论上更优雅但自己从零实现一个正确的 CRDT 数据结构工作量远超毕设周期。选 OT 之后具体用哪种变换策略常见的有 OT 的 Jupiter 模型和 COT 模型。Jupiter 模型是中心化的所有操作经过服务器排序后再广播实现简单适合毕设。COT 模型是去中心化的适合 P2P 场景但实现复杂度高。我一般会选 Jupiter 模型服务器作为唯一的操作排序中心客户端只负责发送操作和接收变换后的操作。2.3 技术栈组合与版本选择后端用 Spring Boot Spring Cloud 做微服务基础框架服务注册和发现用 Nacos消息队列用 RabbitMQ 或 RocketMQ缓存用 Redis 存在线用户状态和文档锁数据库用 MySQL 存文档元数据和操作日志。实时通信层用 Netty 或 Spring WebSocket如果团队 Java 基础一般直接用 Spring WebSocket 更快出活。前端用 Vue 或 React 都行编辑器组件选 Quill 或 ProseMirror。Quill 的 API 更友好文档全适合快速集成。ProseMirror 更灵活但学习曲线陡。毕设项目建议用 Quill把精力放在协同逻辑上而不是编辑器本身的定制上。这里有一个容易翻车的点Spring Cloud 的版本和 Spring Boot 版本必须严格对应。比如 Spring Cloud 2022.0.x 对应 Spring Boot 3.0.xSpring Cloud 2021.0.x 对应 Spring Boot 2.6.x。版本不匹配会在启动时直接报错而且报错信息往往指向不相关的类排查起来很痛苦。我一般会在 pom.xml 里用 dependencyManagement 统一管理版本避免子模块各自引入不同版本。3. 从零跑通协同编辑核心链路操作变换与 WebSocket 广播3.1 操作定义与变换函数实现协同编辑的核心是定义操作的数据结构和变换函数。一个编辑操作至少包含操作类型插入或删除、位置索引、内容、客户端 ID、版本号。下面是一个简化的 Python 实现用来演示 OT 变换的核心逻辑。class Operation: def __init__(self, op_type, position, content, client_id, version): self.op_type op_type # insert or delete self.position position self.content content self.client_id client_id self.version version def transform(op_a, op_b): 将 op_a 针对 op_b 做变换返回变换后的 op_a 假设 op_b 已经先于 op_a 应用 if op_a.op_type insert and op_b.op_type insert: if op_b.position op_a.position: op_a.position len(op_b.content) elif op_b.position op_a.position: # 位置相同按 client_id 排序保证一致性 if op_b.client_id op_a.client_id: op_a.position len(op_b.content) elif op_a.op_type insert and op_b.op_type delete: if op_b.position op_a.position: op_a.position - len(op_b.content) elif op_a.op_type delete and op_b.op_type insert: if op_b.position op_a.position: op_a.position len(op_b.content) elif op_a.op_type delete and op_b.op_type delete: if op_b.position op_a.position: op_a.position - len(op_b.content) return op_a这段代码的逻辑是当两个操作并发时根据操作类型和位置关系调整 op_a 的位置索引。插入操作遇到插入操作时如果位置相同用 client_id 做确定性排序保证所有客户端变换结果一致。删除操作遇到插入操作时如果插入位置在删除位置之前删除位置要后移。参数说明position 是字符索引content 是插入的文本或删除的文本长度client_id 是客户端唯一标识version 是操作基于的文档版本号。实际项目中变换函数会比这复杂得多需要处理操作嵌套、批量操作、撤销重做等场景。但毕设项目把基础变换逻辑跑通再在此基础上扩展就足够撑起技术深度了。3.2 WebSocket 服务端与客户端的最小实现服务端用 Spring WebSocket 接收编辑操作做变换后广播给同一文档的其他在线用户。下面是一个简化的服务端处理逻辑。ServerEndpoint(/ws/editor/{docId}/{clientId}) public class EditorEndpoint { private static MapString, SetSession docSessions new ConcurrentHashMap(); private static MapString, ListOperation docHistory new ConcurrentHashMap(); OnOpen public void onOpen(Session session, PathParam(docId) String docId, PathParam(clientId) String clientId) { docSessions.computeIfAbsent(docId, k - ConcurrentHashMap.newKeySet()).add(session); // 发送当前文档历史操作让新客户端追平状态 ListOperation history docHistory.getOrDefault(docId, new ArrayList()); session.getAsyncRemote().sendText(JSON.toJSONString(history)); } OnMessage public void onMessage(String message, PathParam(docId) String docId, PathParam(clientId) String clientId) { Operation incoming JSON.parseObject(message, Operation.class); ListOperation history docHistory.computeIfAbsent(docId, k - new ArrayList()); // 对历史操作做变换 Operation transformed incoming; for (Operation op : history) { if (op.clientId.equals(clientId)) continue; transformed transform(transformed, op); } history.add(transformed); // 广播给所有客户端 String broadcast JSON.toJSONString(transformed); for (Session s : docSessions.getOrDefault(docId, Collections.emptySet())) { s.getAsyncRemote().sendText(broadcast); } } }这段代码的关键点是新客户端加入时先拉取历史操作追平状态收到编辑操作后对历史操作做变换变换后的操作加入历史并广播。参数说明docId 是文档唯一标识clientId 是客户端标识history 是该文档的所有操作序列。注意这里用 ConcurrentHashMap 保证并发安全实际项目中还需要加锁或使用消息队列来保证操作顺序。客户端收到广播后需要判断这个操作是否是自己发出的。如果是自己发出的跳过如果不是对本地待发送的操作做变换后再应用。这个逻辑在客户端 SDK 里实现前端只需要调用 applyOperation 方法更新编辑器内容。3.3 服务间通信与操作日志持久化协同编辑服务处理完操作后需要异步写入操作日志服务。用 RabbitMQ 做解耦协同编辑服务作为生产者发送操作消息操作日志服务作为消费者批量写入数据库。# application.yml 中 RabbitMQ 配置 spring: rabbitmq: host: localhost port: 5672 username: guest password: guest publisher-confirm-type: correlated publisher-returns: true listener: simple: acknowledge-mode: manual prefetch: 50配置说明publisher-confirm-type 设为 correlated 开启发布确认确保消息到达 Brokeracknowledge-mode 设为 manual 手动确认防止消息丢失prefetch 设为 50 控制每次拉取的消息数量避免消费者过载。操作日志服务消费消息后批量插入 MySQL用 INSERT INTO operation_log (doc_id, client_id, op_type, position, content, version, create_time) VALUES (...) 批量写入每 100 条或每 500 毫秒刷一次盘。这里有一个血泪经验操作日志表一定要建联合索引 (doc_id, version)否则文档操作多了之后查询历史操作会全表扫描接口响应时间从毫秒级涨到秒级。我见过一个项目因为没建这个索引文档编辑到几千次操作后新用户加入时拉取历史操作直接超时。4. 避坑与排查协同编辑系统最容易翻车的五个地方4.1 操作乱序导致文档内容错乱现象多个用户同时编辑时偶尔出现某段文字重复或丢失刷新后恢复正常。原因WebSocket 消息到达顺序和发送顺序不一致服务端没有做全局排序。解决在协同编辑服务中引入版本号机制每个操作必须携带基于的文档版本号服务端按版本号排序后再做变换。如果收到的操作版本号小于当前版本说明是延迟消息需要重新变换后再应用。4.2 服务注册失败导致 RPC 调用超时现象启动时 Nacos 注册成功但运行一段时间后服务列表为空RPC 调用报 No provider available。原因服务实例的心跳续约失败常见于服务器时间不同步或网络抖动。解决检查服务器 NTP 时间同步在 Nacos 配置中适当调大心跳超时时间同时在 RPC 调用端配置重试和熔断策略。我一般会在 Sentinel 或 Resilience4j 里配置失败重试三次、熔断时间窗口 10 秒。4.3 编辑器光标位置在远程操作后跳变现象用户 A 正在输入时用户 B 的编辑操作同步过来A 的光标位置突然跳到文档开头或末尾。原因远程操作应用后没有重新计算本地光标位置。解决在应用远程操作前记录光标位置应用后根据操作类型和位置偏移量重新计算光标位置。Quill 编辑器可以用 quill.setSelection(index, length) 恢复光标ProseMirror 需要用其 Transaction 机制处理。4.4 操作日志表数据量膨胀导致查询变慢现象项目运行几周后操作日志表达到千万行级别查询历史操作越来越慢。原因没有做冷热数据分离所有操作日志都存在一张表里。解决按时间分表最近 7 天的操作存热表超过 7 天的归档到冷表。查询时先查热表查不到再查冷表。另一个方案是用 Redis 缓存最近的操作序列只把超过一定数量的旧操作持久化到 MySQL。4.5 微服务间循环依赖导致启动失败现象项目启动时报 BeanCurrentlyInCreationException 或循环依赖错误。原因文档管理服务调用了协同编辑服务协同编辑服务又回调了文档管理服务。解决引入事件驱动架构用消息队列解耦。文档管理服务发布文档创建事件协同编辑服务订阅事件后初始化文档状态避免直接 RPC 调用。如果必须同步调用把公共逻辑抽到第三个服务或公共模块中。5. 进阶技巧用操作日志做版本回滚与协同性能验证5.1 基于操作日志的版本回滚实现操作日志不只是用来追溯还可以用来做版本回滚。思路是每个操作都有版本号回滚到某个版本时从操作日志中查出该版本之后的所有操作生成反向操作依次应用。反向操作的生成规则插入操作的反向是删除删除操作的反向是插入位置和内容从原操作中提取。def generate_reverse_operations(operations, target_version): 生成从当前版本回滚到 target_version 的反向操作序列 reverse_ops [] for op in reversed(operations): if op.version target_version: break if op.op_type insert: reverse_ops.append(Operation(delete, op.position, op.content, op.client_id, op.version)) elif op.op_type delete: reverse_ops.append(Operation(insert, op.position, op.content, op.client_id, op.version)) return reverse_ops这段代码的逻辑是倒序遍历操作日志遇到版本号小于等于目标版本的操作就停止对每个操作生成反向操作。参数说明operations 是按版本号排序的操作列表target_version 是回滚目标版本。实际使用时反向操作生成后需要依次应用并广播给所有在线客户端同时更新文档版本号。这个功能在答辩时是一个很好的加分项因为它展示了操作日志的完整价值闭环记录、追溯、回滚。而且实现难度不高在已有操作日志基础上加一个接口就能跑通。5.2 协同性能的验证方法与关键指标做完功能之后怎么验证协同性能我一般会从三个维度测并发用户数、操作延迟、操作丢失率。并发用户数用 JMeter 或 Locust 模拟每个虚拟用户建立 WebSocket 连接并随机发送编辑操作。操作延迟从客户端发送操作到收到广播的时间差计算P99 延迟控制在 200 毫秒以内算合格。操作丢失率通过对比客户端发送的操作总数和服务端记录的操作总数来计算正常情况应该为 0。指标合格线测试方法并发用户数50 人同时编辑Locust 模拟 WebSocket 连接操作延迟 P99 200ms客户端打时间戳服务端广播后计算差值操作丢失率0%对比客户端发送数和服务端记录数服务恢复时间 5s手动 kill 协同编辑服务观察客户端重连测试时注意一点并发用户数不是越高越好要结合服务器配置看。单台 4 核 8G 的服务器协同编辑服务跑 50 个并发 WebSocket 连接是合理的超过这个数需要加实例做水平扩展。水平扩展时要注意 WebSocket 的会话粘性问题用 Nginx 的 ip_hash 或 Redis 做会话共享。5.3 一个容易被忽略的细节客户端重连后的状态同步WebSocket 断线重连是必现场景但很多毕设项目只做了重连没做重连后的状态同步。客户端重连后本地文档内容可能已经落后于服务端需要先拉取断线期间的操作日志应用后再继续编辑。实现方式是在客户端维护一个 lastVersion 字段重连时带上这个版本号服务端返回该版本之后的所有操作。// 客户端重连逻辑 function reconnect() { const ws new WebSocket(/ws/editor/${docId}/${clientId}?lastVersion${lastVersion}); ws.onmessage (event) { const data JSON.parse(event.data); if (data.type history) { // 应用断线期间的操作 data.operations.forEach(op applyOperation(op)); lastVersion data.currentVersion; } else { applyOperation(data); lastVersion data.version; } }; }这段代码的关键是重连时带上 lastVersion 参数服务端根据这个参数返回缺失的操作。参数说明lastVersion 是客户端最后应用的版本号服务端返回该版本之后的所有操作和当前版本号。这个细节在答辩时如果被问到断线重连怎么处理能答上来就是加分项。我自己做这类项目最大的教训是不要一上来就追求功能大而全先把协同编辑的核心链路跑通两个人能同时编辑一份文档且内容不乱再往上加用户认证、权限控制、版本回滚。核心链路跑通了后面都是锦上添花核心链路有问题功能再多也撑不住答辩时的追问。希望帮到你。本文还有配套的精品资源点击获取 基于微服务架构的在线协同编辑系统：OT算法与WebSocket实战
简介这份资源是面向计算机专业毕业生与全栈开发学习者的微服务在线协同编辑系统完整源码可作为毕业设计、课程设计或微服务入门实战的参考方案。项目采用微服务架构前端基于 Vue 与 TypeScript 构建交互界面后端以 Java 实现核心业务逻辑并配套 Dockerfile、yml 与 conf 等部署配置便于理解服务拆分、接口协作与容器化部署的整体思路。压缩包共 253 个文件涵盖 82 个 Java 源文件、32 个 Vue 组件、22 个 TypeScript 与 17 个 JavaScript 脚本另有 xml、json、sql 及图片样式资源整体约 2.9MB目录结构清晰按模块划分便于检索。源码经过本地编译验证按文档配置环境后即可运行难度适中适合需要完整项目案例、排错思路与工程结构参考的读者。目前已有 195 人学习关注。1. 微服务架构下的在线协同编辑系统一个毕设项目为什么值得认真做如果你正在找一份能撑起毕设答辩、又能写进简历的完整项目基于微服务架构的在线协同编辑系统源码是一个被低估的方向。它不像电商秒杀那样烂大街也不像纯 CRUD 管理系统那样一眼看穿技术含量。协同编辑背后涉及实时通信、操作冲突消解、服务拆分与数据一致性这几个点随便拎一个出来都能在答辩时讲十分钟。我见过太多毕设项目把微服务三个字贴在单体应用上拆了两三个模块就敢叫微服务架构答辩老师一问服务间怎么通信、数据怎么同步就露馅。这个标题里的在线协同编辑系统核心难点在于多人同时编辑同一份文档时如何保证每个人的操作不丢失、不乱序、不覆盖。适合有一定 Java 或 Python 基础、想通过一个完整项目把微服务架构和实时协同两个方向串起来的同学。接下来我会从架构拆分、协同算法选型、源码落地步骤到踩坑排查把这条路走通。2. 微服务拆分与协同编辑的技术选型为什么不能只拆三个服务2.1 协同编辑系统的服务边界怎么划很多人拿到这个题目第一反应是拆成用户服务、文档服务、编辑服务三个模块就完事。这种拆法在答辩时会被追问编辑服务挂了用户的编辑操作丢不丢文档服务的数据和编辑服务的操作日志怎么对齐我一般会按职责边界拆成五个服务用户认证服务、文档管理服务、协同编辑服务、操作日志服务、通知服务。用户认证服务负责登录注册和 token 签发文档管理服务负责文档的增删改查和权限控制协同编辑服务是核心负责接收编辑操作、做冲突消解、广播给其他在线用户操作日志服务负责持久化每一次编辑操作用于回溯和版本恢复通知服务负责在线状态和消息推送。这样拆的好处是每个服务的职责单一协同编辑服务可以独立扩容操作日志服务可以用顺序写入优化性能。坏处是服务间通信变多需要引入消息队列来解耦。常见做法是用 WebSocket 维持客户端和协同编辑服务的长连接编辑操作通过消息队列异步写入操作日志服务文档管理服务通过 RPC 调用协同编辑服务获取最新文档状态。服务拆分的粒度没有标准答案但有一条原则如果两个模块的数据一致性要求极高、事务边界重叠就不要拆开。协同编辑服务和操作日志服务之间就是这种关系所以操作日志的写入要用最终一致性方案不能强求实时同步。2.2 协同算法选型OT 还是 CRDT这是整个项目最核心的技术决策。OTOperational Transformation和 CRDTConflict-free Replicated Data Type是两种主流方案。OT 的思路是每个编辑操作在应用到本地之前先根据并发操作做变换保证最终一致。CRDT 的思路是设计一种数据结构使得任意顺序应用操作都能得到相同结果。OT 的优点是成熟、有大量开源实现参考缺点是变换函数的正确性很难保证尤其是多用户多操作并发时变换矩阵会变得极其复杂。CRDT 的优点是天然支持分布式、不需要中心服务器做变换缺点是数据结构复杂、内存占用高、实现门槛不低。对于毕设项目我建议选 OT。原因很实际OT 有成熟的参考实现可以对照调试时能一步步跟踪变换过程答辩时也容易讲清楚。CRDT 虽然理论上更优雅但自己从零实现一个正确的 CRDT 数据结构工作量远超毕设周期。选 OT 之后具体用哪种变换策略常见的有 OT 的 Jupiter 模型和 COT 模型。Jupiter 模型是中心化的所有操作经过服务器排序后再广播实现简单适合毕设。COT 模型是去中心化的适合 P2P 场景但实现复杂度高。我一般会选 Jupiter 模型服务器作为唯一的操作排序中心客户端只负责发送操作和接收变换后的操作。2.3 技术栈组合与版本选择后端用 Spring Boot Spring Cloud 做微服务基础框架服务注册和发现用 Nacos消息队列用 RabbitMQ 或 RocketMQ缓存用 Redis 存在线用户状态和文档锁数据库用 MySQL 存文档元数据和操作日志。实时通信层用 Netty 或 Spring WebSocket如果团队 Java 基础一般直接用 Spring WebSocket 更快出活。前端用 Vue 或 React 都行编辑器组件选 Quill 或 ProseMirror。Quill 的 API 更友好文档全适合快速集成。ProseMirror 更灵活但学习曲线陡。毕设项目建议用 Quill把精力放在协同逻辑上而不是编辑器本身的定制上。这里有一个容易翻车的点Spring Cloud 的版本和 Spring Boot 版本必须严格对应。比如 Spring Cloud 2022.0.x 对应 Spring Boot 3.0.xSpring Cloud 2021.0.x 对应 Spring Boot 2.6.x。版本不匹配会在启动时直接报错而且报错信息往往指向不相关的类排查起来很痛苦。我一般会在 pom.xml 里用 dependencyManagement 统一管理版本避免子模块各自引入不同版本。3. 从零跑通协同编辑核心链路操作变换与 WebSocket 广播3.1 操作定义与变换函数实现协同编辑的核心是定义操作的数据结构和变换函数。一个编辑操作至少包含操作类型插入或删除、位置索引、内容、客户端 ID、版本号。下面是一个简化的 Python 实现用来演示 OT 变换的核心逻辑。class Operation: def __init__(self, op_type, position, content, client_id, version): self.op_type op_type # insert or delete self.position position self.content content self.client_id client_id self.version version def transform(op_a, op_b): 将 op_a 针对 op_b 做变换返回变换后的 op_a 假设 op_b 已经先于 op_a 应用 if op_a.op_type insert and op_b.op_type insert: if op_b.position op_a.position: op_a.position len(op_b.content) elif op_b.position op_a.position: # 位置相同按 client_id 排序保证一致性 if op_b.client_id op_a.client_id: op_a.position len(op_b.content) elif op_a.op_type insert and op_b.op_type delete: if op_b.position op_a.position: op_a.position - len(op_b.content) elif op_a.op_type delete and op_b.op_type insert: if op_b.position op_a.position: op_a.position len(op_b.content) elif op_a.op_type delete and op_b.op_type delete: if op_b.position op_a.position: op_a.position - len(op_b.content) return op_a这段代码的逻辑是当两个操作并发时根据操作类型和位置关系调整 op_a 的位置索引。插入操作遇到插入操作时如果位置相同用 client_id 做确定性排序保证所有客户端变换结果一致。删除操作遇到插入操作时如果插入位置在删除位置之前删除位置要后移。参数说明position 是字符索引content 是插入的文本或删除的文本长度client_id 是客户端唯一标识version 是操作基于的文档版本号。实际项目中变换函数会比这复杂得多需要处理操作嵌套、批量操作、撤销重做等场景。但毕设项目把基础变换逻辑跑通再在此基础上扩展就足够撑起技术深度了。3.2 WebSocket 服务端与客户端的最小实现服务端用 Spring WebSocket 接收编辑操作做变换后广播给同一文档的其他在线用户。下面是一个简化的服务端处理逻辑。ServerEndpoint(/ws/editor/{docId}/{clientId}) public class EditorEndpoint { private static MapString, SetSession docSessions new ConcurrentHashMap(); private static MapString, ListOperation docHistory new ConcurrentHashMap(); OnOpen public void onOpen(Session session, PathParam(docId) String docId, PathParam(clientId) String clientId) { docSessions.computeIfAbsent(docId, k - ConcurrentHashMap.newKeySet()).add(session); // 发送当前文档历史操作让新客户端追平状态 ListOperation history docHistory.getOrDefault(docId, new ArrayList()); session.getAsyncRemote().sendText(JSON.toJSONString(history)); } OnMessage public void onMessage(String message, PathParam(docId) String docId, PathParam(clientId) String clientId) { Operation incoming JSON.parseObject(message, Operation.class); ListOperation history docHistory.computeIfAbsent(docId, k - new ArrayList()); // 对历史操作做变换 Operation transformed incoming; for (Operation op : history) { if (op.clientId.equals(clientId)) continue; transformed transform(transformed, op); } history.add(transformed); // 广播给所有客户端 String broadcast JSON.toJSONString(transformed); for (Session s : docSessions.getOrDefault(docId, Collections.emptySet())) { s.getAsyncRemote().sendText(broadcast); } } }这段代码的关键点是新客户端加入时先拉取历史操作追平状态收到编辑操作后对历史操作做变换变换后的操作加入历史并广播。参数说明docId 是文档唯一标识clientId 是客户端标识history 是该文档的所有操作序列。注意这里用 ConcurrentHashMap 保证并发安全实际项目中还需要加锁或使用消息队列来保证操作顺序。客户端收到广播后需要判断这个操作是否是自己发出的。如果是自己发出的跳过如果不是对本地待发送的操作做变换后再应用。这个逻辑在客户端 SDK 里实现前端只需要调用 applyOperation 方法更新编辑器内容。3.3 服务间通信与操作日志持久化协同编辑服务处理完操作后需要异步写入操作日志服务。用 RabbitMQ 做解耦协同编辑服务作为生产者发送操作消息操作日志服务作为消费者批量写入数据库。# application.yml 中 RabbitMQ 配置 spring: rabbitmq: host: localhost port: 5672 username: guest password: guest publisher-confirm-type: correlated publisher-returns: true listener: simple: acknowledge-mode: manual prefetch: 50配置说明publisher-confirm-type 设为 correlated 开启发布确认确保消息到达 Brokeracknowledge-mode 设为 manual 手动确认防止消息丢失prefetch 设为 50 控制每次拉取的消息数量避免消费者过载。操作日志服务消费消息后批量插入 MySQL用 INSERT INTO operation_log (doc_id, client_id, op_type, position, content, version, create_time) VALUES (...) 批量写入每 100 条或每 500 毫秒刷一次盘。这里有一个血泪经验操作日志表一定要建联合索引 (doc_id, version)否则文档操作多了之后查询历史操作会全表扫描接口响应时间从毫秒级涨到秒级。我见过一个项目因为没建这个索引文档编辑到几千次操作后新用户加入时拉取历史操作直接超时。4. 避坑与排查协同编辑系统最容易翻车的五个地方4.1 操作乱序导致文档内容错乱现象多个用户同时编辑时偶尔出现某段文字重复或丢失刷新后恢复正常。原因WebSocket 消息到达顺序和发送顺序不一致服务端没有做全局排序。解决在协同编辑服务中引入版本号机制每个操作必须携带基于的文档版本号服务端按版本号排序后再做变换。如果收到的操作版本号小于当前版本说明是延迟消息需要重新变换后再应用。4.2 服务注册失败导致 RPC 调用超时现象启动时 Nacos 注册成功但运行一段时间后服务列表为空RPC 调用报 No provider available。原因服务实例的心跳续约失败常见于服务器时间不同步或网络抖动。解决检查服务器 NTP 时间同步在 Nacos 配置中适当调大心跳超时时间同时在 RPC 调用端配置重试和熔断策略。我一般会在 Sentinel 或 Resilience4j 里配置失败重试三次、熔断时间窗口 10 秒。4.3 编辑器光标位置在远程操作后跳变现象用户 A 正在输入时用户 B 的编辑操作同步过来A 的光标位置突然跳到文档开头或末尾。原因远程操作应用后没有重新计算本地光标位置。解决在应用远程操作前记录光标位置应用后根据操作类型和位置偏移量重新计算光标位置。Quill 编辑器可以用 quill.setSelection(index, length) 恢复光标ProseMirror 需要用其 Transaction 机制处理。4.4 操作日志表数据量膨胀导致查询变慢现象项目运行几周后操作日志表达到千万行级别查询历史操作越来越慢。原因没有做冷热数据分离所有操作日志都存在一张表里。解决按时间分表最近 7 天的操作存热表超过 7 天的归档到冷表。查询时先查热表查不到再查冷表。另一个方案是用 Redis 缓存最近的操作序列只把超过一定数量的旧操作持久化到 MySQL。4.5 微服务间循环依赖导致启动失败现象项目启动时报 BeanCurrentlyInCreationException 或循环依赖错误。原因文档管理服务调用了协同编辑服务协同编辑服务又回调了文档管理服务。解决引入事件驱动架构用消息队列解耦。文档管理服务发布文档创建事件协同编辑服务订阅事件后初始化文档状态避免直接 RPC 调用。如果必须同步调用把公共逻辑抽到第三个服务或公共模块中。5. 进阶技巧用操作日志做版本回滚与协同性能验证5.1 基于操作日志的版本回滚实现操作日志不只是用来追溯还可以用来做版本回滚。思路是每个操作都有版本号回滚到某个版本时从操作日志中查出该版本之后的所有操作生成反向操作依次应用。反向操作的生成规则插入操作的反向是删除删除操作的反向是插入位置和内容从原操作中提取。def generate_reverse_operations(operations, target_version): 生成从当前版本回滚到 target_version 的反向操作序列 reverse_ops [] for op in reversed(operations): if op.version target_version: break if op.op_type insert: reverse_ops.append(Operation(delete, op.position, op.content, op.client_id, op.version)) elif op.op_type delete: reverse_ops.append(Operation(insert, op.position, op.content, op.client_id, op.version)) return reverse_ops这段代码的逻辑是倒序遍历操作日志遇到版本号小于等于目标版本的操作就停止对每个操作生成反向操作。参数说明operations 是按版本号排序的操作列表target_version 是回滚目标版本。实际使用时反向操作生成后需要依次应用并广播给所有在线客户端同时更新文档版本号。这个功能在答辩时是一个很好的加分项因为它展示了操作日志的完整价值闭环记录、追溯、回滚。而且实现难度不高在已有操作日志基础上加一个接口就能跑通。5.2 协同性能的验证方法与关键指标做完功能之后怎么验证协同性能我一般会从三个维度测并发用户数、操作延迟、操作丢失率。并发用户数用 JMeter 或 Locust 模拟每个虚拟用户建立 WebSocket 连接并随机发送编辑操作。操作延迟从客户端发送操作到收到广播的时间差计算P99 延迟控制在 200 毫秒以内算合格。操作丢失率通过对比客户端发送的操作总数和服务端记录的操作总数来计算正常情况应该为 0。指标合格线测试方法并发用户数50 人同时编辑Locust 模拟 WebSocket 连接操作延迟 P99 200ms客户端打时间戳服务端广播后计算差值操作丢失率0%对比客户端发送数和服务端记录数服务恢复时间 5s手动 kill 协同编辑服务观察客户端重连测试时注意一点并发用户数不是越高越好要结合服务器配置看。单台 4 核 8G 的服务器协同编辑服务跑 50 个并发 WebSocket 连接是合理的超过这个数需要加实例做水平扩展。水平扩展时要注意 WebSocket 的会话粘性问题用 Nginx 的 ip_hash 或 Redis 做会话共享。5.3 一个容易被忽略的细节客户端重连后的状态同步WebSocket 断线重连是必现场景但很多毕设项目只做了重连没做重连后的状态同步。客户端重连后本地文档内容可能已经落后于服务端需要先拉取断线期间的操作日志应用后再继续编辑。实现方式是在客户端维护一个 lastVersion 字段重连时带上这个版本号服务端返回该版本之后的所有操作。// 客户端重连逻辑 function reconnect() { const ws new WebSocket(/ws/editor/${docId}/${clientId}?lastVersion${lastVersion}); ws.onmessage (event) { const data JSON.parse(event.data); if (data.type history) { // 应用断线期间的操作 data.operations.forEach(op applyOperation(op)); lastVersion data.currentVersion; } else { applyOperation(data); lastVersion data.version; } }; }这段代码的关键是重连时带上 lastVersion 参数服务端根据这个参数返回缺失的操作。参数说明lastVersion 是客户端最后应用的版本号服务端返回该版本之后的所有操作和当前版本号。这个细节在答辩时如果被问到断线重连怎么处理能答上来就是加分项。我自己做这类项目最大的教训是不要一上来就追求功能大而全先把协同编辑的核心链路跑通两个人能同时编辑一份文档且内容不乱再往上加用户认证、权限控制、版本回滚。核心链路跑通了后面都是锦上添花核心链路有问题功能再多也撑不住答辩时的追问。希望帮到你。本文还有配套的精品资源点击获取