IM Server

这是一份历史 IM 技术候选与需求草稿，不代表现网已实现以下服务或规则。先区分连接路由与账号身份，再看好友/群权限、消息确认及断线补拉；原稿语义不明和租约时长冲突列为待确认，不补猜产品约定。

Go IM

实现技术

• Go(WebSocket)
• mysql
• MQ
• Redis
• mongodb

实现思路

身份与连接

• 客户端通过 HTTP Upgrade 建立 WebSocket；成功升级的状态码为 101。连接标识用于路由，不能替代认证身份。
• 原稿设想首次连接提交用户名、可选群组名并取得 token；认证、注册、入群应各自校验。重连必须验证凭据，不能仅凭客户端自报用户名恢复身份。
• 待确认 IM-01：原句“需要在公共的搜索页面添加好友才能卸载对聊名字”语义不明。需产品拥有者明确添加好友后究竟开放什么信息或会话能力。

好友与群权限

• 历史好友流程为搜索用户名、发送申请、对端响应；待确认 IM-02：原句“接受或者同故意”未明确拒绝、同意或其他状态，需确认申请状态和双方列表更新规则。
• 原稿设想一方删除好友后双方列表移除对方，尚需确认是否同时禁止私聊及历史读取；不能把“删除好友”理解成删除账号。
• 原稿设想分享群号入群、退群后停止接收消息，由创建者解散群或移出成员。服务端仍须验证操作者权限、成员资格及群状态；历史消息可见范围需产品另定。
• 文件与音频先上传，再将资源引用发送到会话；下载时仍应按当前身份和会话权限授权，不能把持有 URL 当作可读取证明。

在线租约与离线补拉

• 原稿计划在 Redis 记录在线会话；待确认 IM-03：有效期原文同时出现“两小时”与“3小时”，不能直接选为 TTL。需确认租约时长、心跳续约、断线和多设备规则。
• 在线状态只用于选择推送策略，不保证此刻可达。发送时先校验身份与会话权限，再按消息 ID 去重并持久保存；确认阶段见下文。
• 消息队列驱动投递，不作为用户已收到的唯一证据。断线后按持久会话游标补拉并去重，不能只消费在线时对应的一次队列任务。

消息确认需要区分三个阶段

原稿是技术候选与需求记录，下面是补充设计推演，不确认这些存储均已部署。WebSocket连接标识用于路由，账号身份必须由认证流程确认；连接断开重建时不能仅凭客户端自报用户名恢复身份。在线状态通常用会话租约与心跳表达，租约有效也不证明此刻推送一定成功。

发送消息时，先验证会话身份及好友或群成员权限，再按客户端消息标识去重并保存消息。服务端已接收、对端已收到、用户已读是三个不同确认：只有持久化确认才能支持断线补拉，读回执则是额外业务事件。群成员退出后，实时推送与历史读取都要按约定校验权限；文件URL也不能替代访问授权。

查看图表代码

离线补拉与重投递

消息队列可驱动投递，但不能仅以“消费者取走”代表用户已收到。接收端按会话游标补拉，服务端可能在确认丢失后重发同一消息，客户端按消息ID去重；顺序保证应限定到会话，不能从多个队列推导全局顺序。多设备需要明确各设备游标与账号已读状态是否共享。

例如序号101已推送但确认丢失，重连后从100补拉会再次得到101；去重后界面只显示一次。若消息已经超过保留期，应返回游标失效或缺口提示，而不是伪装成没有新消息。

查看图表代码