coffee多人在线聊天系统产品系统

1. 立项原因
即时通讯（IM）是当下绝大多数互联网产品的基础能力，但自研门槛高——长连接维护、消息可靠投递、多端同步、离线消息补偿、群成员与权限管理、会话未读数等，每一项都需要完整的技术链路；而直接采购第三方 IM SDK 或云服务，又普遍存在接入成本高、数据不在自己手中、定制能力受限、被平台锁定等问题。
本项目立项，旨在解决中小团队与垂直业务场景难以低成本获得"可控、可私有化部署、可自主定制"的即时通讯能力这一产品问题。项目从零构建一套完整可用的即时通讯系统，独立实现 WebSocket 长连接、消息可靠投递、单聊与群聊、会话与未读、群成员权限、微信扫码登录等核心链路，做到数据自持、可自主运维、可按业务二次开发，并在实践中验证分布式场景下的消息投递与水平扩展能力。
2. 行业场景、业务背景
即时通讯已经成为互联网产品的基础设施。在微信、QQ 等头部社交产品之外，企业内部协作与办公沟通、在线教育与课后答疑、社区与兴趣社群运营、政务与校园信息化等大量场景，都需要把"聊天"作为一种能力嵌入到自有系统之中——而不只是注册一个第三方社交账号。
这些场景有着高度一致的诉求：消息要实时可达、要同时支持单聊与群聊、成员与权限要可控可管理、消息与用户数据要留在自己手中。同时，随着数据安全与合规要求不断提高，私有化部署、数据主权、可审计可追溯的需求持续上升。通用社交产品无法满足这类定制与集成诉求，第三方 SDK 又带来成本与平台锁定风险，市场因此需要一套结构清晰、可自主部署、具备分布式消息推送能力的即时通讯系统。本项目正是面向这一背景立项，定位为可私有化部署的轻量级 IM 系统，优先服务企业内部协作、校园社区与兴趣社群等中低并发、强可控性的业务场景。

本项目是一套可自主部署的即时通讯系统，共划分为十个功能模块，覆盖登录、用户、好友、会话、消息、互动与平台支撑的完整业务闭环。
一、功能模块
用户认证与登录、用户资料与个人中心、好友关系管理、单聊会话、群聊与成员管理、消息收发、消息互动、会话列表与未读消息、实时通信与在线状态、平台支撑能力。
二、主要功能描述
1．用户认证与登录：采用微信扫码授权登录，无需账号密码；服务端签发登录令牌并统一缓存管理，支持强制失效与滑动续期。
2．用户资料与个人中心：支持修改昵称、维护头像性别、展示 IP 归属地；内置改名卡、徽章与自定义表情包，徽章可佩戴展示。
3．好友关系管理：支持好友申请、审批与删除，重复申请自动拦截，双方互相申请时自动互加，删除好友后保留聊天记录。
4．单聊会话：面向两位好友的一对一聊天，同一对用户始终复用同一个会话房间，不会产生冗余会话。
5．群聊与成员管理：支持建群、邀请入群、移除成员、退群与解散，设有群主、管理员、普通成员三级权限。
6．消息收发：支持文本、图片、文件、语音、视频、表情包六类消息及系统消息，文本自动敏感词脱敏，多媒体内容直传对象存储。
7．消息互动：支持消息撤回、点赞与点踩、@提醒，以及消息已读未读人数统计。
8．会话列表与未读消息：按活跃时间倒序展示会话，实时计算未读条数，进入会话自动上报已读并清零。
9．实时通信与在线状态：基于 WebSocket 长连接实时推送消息，支持多端同时在线与全量同步，提供上下线通知与在线人数统计。
10．平台支撑能力：提供对象存储直传、敏感词过滤、接口限流、分布式锁与幂等、可靠消息投递及黑名单机制，保障系统稳定与可扩展。

一、我负责的具体任务
我独立完成从设计到部署的全流程：需求分析与功能拆解、多模块工程结构与数据库表设计（十九张表）；后端核心功能全部由我编码实现，包括微信扫码登录与令牌鉴权、用户资料与徽章体系、好友关系、单聊与群聊、群成员权限、消息收发、消息撤回与点赞、会话列表与未读统计、表情包、敏感词过滤、接口限流、分布式锁与幂等、可靠消息投递；基于 Netty 的 WebSocket 实时通信与推送；MySQL、Redis、RocketMQ、MinIO 等中间件集成；以及联调、Nginx 反代配置与服务部署上线。
二、项目使用的技术栈、架构与亮点难点
技术栈上，后端采用 Spring Boot、MyBatis-Plus、MySQL、Redis、Redisson、Caffeine、RocketMQ、Netty、MinIO、JWT 与微信公众号 SDK，前端采用 Vue 3，前后端分离。架构上采用多模块分层设计，自上而下为接入层（HTTP 接口与 Netty 长连接）、切面层（鉴权、限流、分布式锁、日志）、业务层、事件层、消息层与数据层，各层通过接口与消息解耦。
实现亮点主要有四点：一是用策略模式配合泛型反射自注册，新增消息类型无需改动工厂与调用方；二是采用两级消息队列解耦，先做业务扩散再做推送广播，解决了多实例部署下长连接的路由问题；三是对普通群采用写扩散、对万人全员大群采用读扩散，用不同策略应对不同规模；四是引入本地消息表，保证数据落库与消息投递的最终一致。
主要难点包括：长连接分散在多个实例上，需借助广播消费精确定位用户连接；消息发送与事务提交时机必须严格绑定，否则会出现数据与消息不一致；策略对象在容器初始化阶段注册会绕过代理，导致事务静默失效；限流计数需借助 Lua 脚本保证自增与过期的原子性；消息重复消费场景下所有写入必须保证幂等。