这是个很典型的异步分块数据聚合场景，我来分享几个实用的临时存储方案，结合你的需求（凑齐6项就落库删数据）来拆解：

方案1：内存型哈希表（适合低延迟、小数据量场景） #

用线程安全的哈希表来做临时存储，比如Java的ConcurrentHashMap、Python的dict配合锁机制，key存用户ID，value存一个字典/结构体来记录已收集的字段。

• 核心流程：
  • 每收到一条分块数据，先根据用户ID查哈希表：
    • 没找到就初始化一个空的字段集合，把当前字段加进去
    • 已存在就追加当前字段，然后检查是否凑齐了6项
  • 凑齐后直接组装成完整数据写入MySQL，再从哈希表删除该用户的条目
• 注意事项：
  • 必须处理并发写入的问题，要么用线程安全的实现，要么加锁保护
  • 缺点是服务重启会丢失所有未完成的临时数据，如果你的业务能接受这个风险，这是性能最快的方案

方案2：Redis Hash结构（适合高可用、数据不能丢的场景） #

Redis的Hash天生适配这种按用户聚合字段的需求：每个用户ID对应一个Hash，Hash的field是字段名（比如"手机号码"、"家庭地址"），value是对应的值。

• 核心流程：
  • 收到数据后用HSET user:{user_id} {field_name} {field_value}写入Redis
  • 接着用HLEN user:{user_id}获取已收集的字段数，如果等于6：
    • 用HGETALL user:{user_id}取出所有字段，组装后写入MySQL
    • 用DEL user:{user_id}删除这个用户的临时Hash
• 进阶优化：
  • 给每个用户Hash设过期时间（比如EXPIRE user:{user_id} 86400），避免长期未凑齐的垃圾数据占空间
  • 用Redis事务或Lua脚本保证"检查数量→取数据→删数据"的原子性，防止并发下重复写入
• 优势：
  • 开启RDB/AOF后数据可持久化，服务重启也不会丢数据
  • 天然支持分布式场景，如果接收端是多实例部署，Redis可以作为共享存储

方案3：MySQL临时表（适合依赖现有MySQL、不想加新组件的场景） #

建一张专门的临时聚合表来存未完成的用户数据，示例表结构：

CREATE TABLE user_temp_aggregate (
    user_id INT PRIMARY KEY COMMENT '用户ID',
    phone VARCHAR(20) COMMENT '手机号码',
    address VARCHAR(255) COMMENT '家庭地址',
    field3 VARCHAR(255) COMMENT '第3项字段',
    field4 VARCHAR(255) COMMENT '第4项字段',
    field5 VARCHAR(255) COMMENT '第5项字段',
    field6 VARCHAR(255) COMMENT '第6项字段',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

• 核心流程：
  • 收到数据后用INSERT INTO user_temp_aggregate (user_id, {field}) VALUES ({user_id}, {value}) ON DUPLICATE KEY UPDATE {field} = {value}来更新数据
  • 查询该用户的所有字段是否非空，判断是否凑齐6项
  • 凑齐后插入正式用户表，再DELETE FROM user_temp_aggregate WHERE user_id = {user_id}
• 注意事项：
  • 加个定时任务，清理超过24小时（或你设定的阈值）还没凑齐的临时数据
  • 性能不如Redis，但胜在不需要额外引入中间件，适合小型项目

选择建议 #

• 追求极致性能、能容忍数据丢失：选内存哈希表
• 需要高可用、数据不丢、支持分布式：选Redis Hash
• 不想新增组件、依赖现有MySQL：选MySQL临时表

内容的提问来源于stack exchange，提问作者Daniel Iliaguev Harta