Human-Clone 系统需求调研记录
调研日期
2025-01-04
项目概述
Human-Clone 系统需求分析
第一轮调研
用户回答记录
问题: 这个human-clone系统的主要用途是什么？ 回答: human 和 clone 之间相互协作，且可以和其他 clone、human 之间相互通讯的系统。现阶段首先解决的是通讯问题。
初步需求分析
- 核心功能: 多主体间通讯协作系统
- 主体类型: human, clone
- 通讯模式:
- human ↔ clone
- clone ↔ clone
- human ↔ human (通过系统)
- 当前优先级: 通讯功能
下一步调研方向
需要深入了解通讯的具体需求和技术细节。
第二轮调研记录
问题: 这些主体之间的通讯主要是通过什么形式？文字、语音、还是视频？ 回答: 第一步先解决主体之间文字形式的通讯
需求更新
- 通讯方式: 首先实现文字通讯
- 开发阶段: 第一阶段专注文字通讯功能
- 通讯模式: 实时异步通讯
第三轮调研记录
问题: 系统需要支持实时通讯（如聊天室形式）还是异步通讯（如邮件/留言形式）？ 回答: 基本属于实施通讯，但是是异步的，计划采用 redis 订阅的方式来实现信息传递，每一个主体都会有一个 redis-adapter，负责发送和接收消息
技术架构初步确定
- 消息传递: Redis 订阅/发布模式
- 组件设计: 每个主体配备 redis-adapter
- 消息处理: 发送/接收消息统一处理
第四轮调研记录
问题: 每个主体（human/clone）需要有自己的身份标识吗？比如用户名、ID之类的？ 回答: 需要有 id —— uuid 格式、实体名称（name)、redis-adapter 里和 redis 相关订阅 channel 相关的配置信息
主体身份设计
- 唯一标识: UUID格式ID
- 显示名称: 实体名称(name)
- 配置信息: redis-adapter配置（订阅channel等）
第五轮调研记录
问题: 消息需要有哪些基本字段？比如发送者、接收者、时间戳、消息内容？ 回答: 需要，其中发送者、接收者都使用 id
消息结构设计
- 发送者: UUID格式ID
- 接收者: UUID格式ID
- 时间戳: 消息发送时间
- 消息内容: 文字内容
- 消息类型: 点对点通讯
第六轮调研记录
问题: 是否需要支持群发消息（一个发送者同时发给多个接收者）？ 回答: 此阶段不需要
功能范围明确
- 当前阶段: 仅支持点对点消息
- 群发功能: 后续版本考虑
第七轮调研记录
问题: 系统需要存储历史消息记录吗？ 回答: 需要
数据持久化需求
- 消息存储: 需要保存历史消息记录
- 存储方案: 待确定（数据库选择）
第八轮调研记录
问题: 历史消息需要保存多长时间？ 回答: 先不讨论历史记录的问题，先解决通信问题
开发优先级调整
- 当前重点: 通讯功能实现
- 历史记录: 后续阶段处理
第九轮调研记录
问题: redis-adapter 需要哪些具体的配置信息？比如 Redis 服务器地址、端口、认证信息等？ 回答: redis 服务器地址、端口、db、channel
redis-adapter 配置设计
- 服务器地址: Redis host
- 端口: Redis port
- 数据库: Redis DB number
- 频道: 订阅/发布的 channel
第十轮调研记录
问题: 每个主体是使用相同的 channel 还是各自有独立的 channel？如果是独立的，channel 的命名规则是什么？ 回答: 每个主体都是独立的 channel，channel 的命名就是主体的 id
Channel 设计方案
- Channel 分配: 每个主体独立 channel
- 命名规则: 使用主体的 UUID 作为 channel 名称
- 通讯机制: 目标主体监听自己的 channel 接收消息
第十一轮调研记录
问题: 当一个主体要发送消息给另一个主体时，是如何知道接收者的 channel 名称的？是否需要一个主体注册发现机制？ 回答: 主体注册发现机制可以放到下一个迭代，此次只假设可以通过目标主体的 id 就可以获得目标主体的订阅 redis 参数，包括服务器、端口、db、channel
主体发现机制设计
- 当前版本: 假设可通过 ID 获取目标的 Redis 连接参数
- 后续迭代: 实现主体注册发现机制
- 参数获取: 服务器地址、端口、DB、channel 通过 ID 直接获得
第十二轮调研记录
问题: redis-adapter 是否需要处理连接断开重连、消息发送失败重试等异常情况？ 回答: 目前不需要
异常处理设计
- 当前版本: 不处理连接重连和重试机制
- 设计原则: 专注核心通讯功能，异常处理后续考虑
第十三轮调研记录
问题: 消息的发送和接收是否需要确认机制？比如接收者收到消息后需要回复确认？ 回答: 不需要
消息确认机制
- 确认机制: 不需要消息确认
- 通讯模式: 单向发送，无回复确认
- 简化设计: 降低复杂度，专注基础通讯
第十四轮调研记录
问题: 系统是否需要区分不同类型的消息？比如普通消息、系统消息、命令消息等？ 回答: 不需要
消息类型设计
- 消息分类: 不区分消息类型
- 统一处理: 所有消息均为普通文字消息
- 简化架构: 无需消息类型判断和处理逻辑
第十五轮调研记录
问题: 每个主体的 redis-adapter 是需要同时监听多个 channel（包括自己的和其他主体的）还是只监听自己的 channel？ 回答: 只监听自己的
监听机制设计
- 监听范围: 每个主体只监听自己的 channel
- 消息接收: 通过订阅自己的 ID channel 接收消息
- 消息发送: 向目标主体的 ID channel 发布消息
需求调研总结
基于15轮调研，Human-Clone 系统第一版本的核心需求已明确：
系统架构
- 主体类型: human、clone
- 通讯模式: 点对点文字通讯
- 技术方案: Redis 订阅/发布模式
- 身份标识: UUID + name
核心组件
- redis-adapter: 每个主体一个，负责发送/接收消息
- 配置参数: 服务器地址、端口、DB、channel(=主体ID)
- 监听机制: 只监听自己的 channel
消息格式
- 发送者ID: UUID格式
- 接收者ID: UUID格式
- 时间戳: 发送时间
- 内容: 文字消息
功能边界
- ✅ 点对点文字通讯
- ❌ 群发消息
- ❌ 历史消息存储
- ❌ 连接重连机制
- ❌ 消息确认机制
- ❌ 消息类型区分
- ❌ 主体注册发现
第十六轮调研记录
问题: 发送消息时是否需要引入发送缓存队列来解耦主体发送和Redis发送操作？ 回答: 在发送主体不直接调用发送消息到 redis，而是在 redis-adapter 里设置一个发送缓存 queue，通过线程循环逐个 pop 后发送到 redis，这样主体发送和 redis 发送分开，且有缓存，解耦
第十七轮调研记录
问题: 消息接收部分是否也需要类似的队列解耦设计？ 回答: 消息接收部分，目标主体 B 的redis-adapter 收到 channel 里的消息后，推送到接收队列 receiver-queue，在线程里循环读取 queue，并调用 callback，给到 B 的函数里进行处理
完整架构设计优化
- 发送缓存: redis-adapter内部设置发送队列
- 接收缓存: redis-adapter内部设置接收队列
- 双向异步: 发送和接收均采用队列+线程机制
- 回调机制: 接收线程通过callback将消息传递给主体
- 完全解耦: Redis操作与主体处理完全分离
下一步行动
基于明确的需求和完整的双向异步架构设计，可以开始进行技术设计和开发实现。