15 个工作日内“删干净“一个会员：婚恋系统的注销链路比想象中难

副标题网信办新规征求意见稿把注销时限写死后我们重新梳理了婚恋系统里删除一条会员数据的完整工程链路9 月 2 日上午一位会员在某婚恋小程序里点了注销。三分钟后负责牵线的红娘打开工作台还能看到她的完整资料以及她和另一位会员的匹配记录。红娘以为是 bug提了工单。不是 bug。那条数据只是还没走到删除环节。今年 1 月国家网信办就《互联网应用程序个人信息收集使用规定》公开征求意见其中一条被很多技术团队忽略了用户注销账号的应当在 15 个工作日内完成注销删除已收集的相关个人信息或者进行匿名化处理。对普通工具类 App 来说删一个账号无非清几张表。婚恋系统把这事的难度放大了好几倍。一个会员的数据从来不是一条数据做婚恋系统的删除功能之前我们先把一个注销会员的数据被谁引用摸了一遍结果比预想的长数据位置内容特殊性会员主表实名信息、择偶条件主体本人直接删红娘端缓存匹配推荐列表定时刷新有滞后期牵线记录谁给谁牵过线、结果如何机构的经营流水含双方信息聊天消息双方对话删一方另一方的上下文还在审计日志谁在何时看过这份资料合规留痕本身不能随便删第三行和第四行是婚恋行业特有的麻烦。普通社交产品里用户数据基本只属于用户自己而在婚恋系统里一份会员资料从录入那天起就被三方使用会员本人、牵线的红娘、以及被推荐给的其他会员。删除请求指向的是一个人但数据关系网挂在多个人身上。删除不是一条 DELETE先建任务表想清楚引用关系后第一步不是写 DELETE而是把注销做成一个可追踪的任务。理由很直接15 个工作日是监管时限你得能回答这条注销请求处理到哪一步了而不是应该已经删了吧。CREATE TABLE deletion_request (id BIGINT PRIMARY KEY,member_id BIGINT NOT NULL,status VARCHAR(16) NOT NULL DEFAULT ‘PENDING’,– PENDING - PROCESSING - VERIFYING - DONE / FAILEDdeadline_at DATETIME NOT NULL, – 申请时间 15 个工作日fail_reason VARCHAR(255),retried_times INT NOT NULL DEFAULT 0,created_at DATETIME NOT NULL,KEY idx_status_deadline (status, deadline_at));每类数据注册一个独立的处理器主表删除器、缓存失效器、牵线记录匿名化器、消息打标器、日志保留器。任务表按 status deadline_at 建索引调度器每小时扫一次 PENDING 和 FAILED 的任务临近 deadline 未完成的优先重试。任何一步失败只标记 FAILED 并记录原因不影响其他处理器继续执行——婚恋系统的注销链路最怕的不是慢是某一步悄悄挂了没人知道。牵线记录删不得但必须匿名化最容易做错的环节在这里。在婚恋系统里牵线记录是婚介机构的经营流水红娘哪天给谁推荐了谁、结果成没成。如果物理删除会员 A把涉及她的牵线记录一并清掉机构的对账和历史业绩就断了——这既不合理也不是新规的本意。征求意见稿给的是删除或者匿名化处理两个选项落到工程上就是按数据类型分路走能反推到个人的字段直接删作为经营事实要留存的做去标识。牵线记录属于后者示例 SQL 长这样– 不删行去标识姓名/手机号/身份证等直接字段置空并打散主键关联UPDATE match_recordSET member_name ‘已注销用户’,member_phone NULL,member_idcard NULL,member_ref NULL, – 断开与会员主表的关联anonymized_at NOW()WHERE member_id 42;判断标准可以归纳成一句话能反推到具体个人的删作为经营事实需要留存的去标识后留。匿名化之后的牵线记录还能回答去年 3 月总共建了多少条线但再也回答不了会员张三参与过哪些。示例数据上我们验证过去标识后的记录对机构报表的完整度没有影响因为报表聚合的维度本来就不含个人标识。聊天记录按人删不按会话删聊天记录在婚恋系统里是另一个坑。会员 A 和会员 B 聊过 200 条消息A 注销了这 200 条怎么办整段会话删掉B 的聊天列表会突然出现空洞某些对话语境直接丢失一条不删A 的个人信息又原封不动躺在服务器上。我们的做法是按主体维度打标而不是按会话删除。A 注销后会话记录保留但所有由 A 发出的消息内容置为占位符B 端看到的是该用户已注销消息内容已按规范处理。这本质上是给消息表加了一层 tombstoneUPDATE chat_messageSET content NULL,is_tombstoned 1WHERE sender_id 42 AND is_tombstoned 0;收到方B不修改。B 看自己这边的聊天记录时A 发出的内容已不可读但这里曾经有过一段对话的事实还在时间线完整。这个取舍不一定是最优解但它同时满足了两个约束A 的个人信息不可恢复B 的使用体验不塌方。15 个工作日的工程解读备份窗口和幂等最后是时限本身。15 个工作日听起来很宽裕有两个容易被忽略的细节藏在里面。先说备份。大部分系统的数据库备份周期是 7 到 30 天今天的删除操作执行完了昨天的全量备份里那份会员资料还在。哪天从备份恢复数据等于把注销悄悄撤销了。所以备份保留策略得纳入注销链路一起设计在删除完成的校验环节除了校验在线库还要记录当时未过期的备份份数和最长过期时间作为注销任务的收尾字段。换个角度看“15 个工作日给的不只是执行时间还隐含了让备份自然滚出保留期的缓冲。再说幂等。调度器会重试处理器就必须幂等匿名化重复执行无害UPDATE 条件里带 anonymized_at IS NULL删除用软删标记加异步物理清理任务状态机保证同一个请求不会被并发执行两次。重试看似简单注释掉重试逻辑的注销系统在第一次网络抖动后就会开始欠账。写在最后注销功能在婚恋系统的需求优先级排序里常年垫底但这次新规把时限写死之后它从体验优化变成了合规必答题”尤其对持有大量敏感个人信息的婚恋系统更是如此。好在整套链路拆开看并没有黑科技摸清引用关系任务化分处理器删除和匿名化分开对待重试写成幂等的都是些朴素的工程手段。文中方案来自我们在婚恋行业 SaaS云中红线的一线实践欢迎交流。