账号体系（2）：账号合并的历史数据处理

橘子 2023-07-26 22:57:42

先回顾账号合并：

概念：一个系统内，一个用户的多个账号合并成一个账号；
场景：一个系统内，相同类型的账号合并/不同类型的账号合并；
要求：一个系统中一个用户身份只有一个账号，且所有登录方式产生的数据都迁移累计在该账号下。

由上可知，不论是哪种合并场景，其本质都是将多个账号的同类型数据进行了合并，将所有数据都合并到一个用户纬度，因此本文将围绕“历史数据的合并处理方法”展开讨论。

以下为本文大纲：

账号体系（2）| 账号合并的历史数据处理

一、开始的开始，举个“栗子”

所有的解决方案是依附具体背景存在的，因此本文依附以下案例展开讨论：

你负责一个问答社群平台的账号系统，现在接到一个需求：给用户提供账号合并的功能，用户可以对名下多个账号发起合并请求，实现对多个账号名下收藏关注的文章用户、阅读签到等产生的成就权益等数据进行统一管理。

在合并完成后，后续该用户所有操作产生的数据都会进入合并后的账号；那么在合并前，几个待合并账号内产生的数据呢？这些数据也属于该用户，也就是本文所指的历史数据；历史数据就是在进行合并之前，系统中已经存在的原始数据。

为了后续该用户可以通过合并后的账号顺利调用历史数据，完成指定的业务操作，我们需要将所有账号的历史数据合并入最终的账号内，即要对历史数据进行合并操作；数据合并就是将同类型的多个入口的输入数据集合并为新的单个输出数据集，为数据消费者提供唯一数据出口的数据集成方式。

技术实现合并后，发现几个问题：

待合并的两个账号，关注了相同的用户；合并后账号产生了重复关注的用户，导致总数统计错误，数据冗余。
待合并的两个账号，成就勋章分别是1级与3级，合并后用户依据勋章级别开放的权限出现了业务冲突。

可见，历史数据的合并不是简单的1+1=2，若是处理不规范，可能会产生类似上述的异常；本文就从合并每种类型历史数据可能产生的异常入手，分析对应的处理方案。

二、数据有哪些类型

从业务角度入手，笔者将数据拆分为以下五种类型：标示类、定义类、关系类、权限类、业务类。

1. 标示类

定义：对身份进行标示定义的唯一数据，例如上例的用户昵称、性别；与userid为同一级别，标示用户身份，一般为存储在数据库user表中的用户数据。

特征：所有账号的标示类数据格式统一，且该类参数在用户纬度内唯一。

2. 定义类

定义：用户自己设置或系统对其配置的定义个人属性的参数。例如上例的用户签名、用户自己配置的系统设置项、电商系统的收货地址；这类数据是对用户本人、及操作习惯等的定义。

特征：此类参数在用户纬度内不唯一，但是不可重复。

3. 关系类

定义：由于用户本人的操作，用户与系统中本人、非本人数据产生的关系；例如上例的文章收藏夹、关注用户即为与非本人数据产生的关系；印象笔记中的笔记本与笔记即为与本人数据产生的关系，关联的数据之间可以产生更多的交互业务。

特征：该类参数在用户纬度内的限制根据业务决定。

4. 权限类

定义：用户付费、申请或系统赋予的用户权限，不同的权限对应用户不同的操作、可视数据，例如上例的用户成就勋章。

获取方式：

权限类数据一般有两种获取方式：付费购买、系统赋予。

系统授予又分为：主动与被动两种获取方式。

主动：由用户发起的权限申请，例如申请成为作者；
被动：系统根据用户使用情况授予的权限，例如用户积分对应的权限；系统根据用户在系统中所处的角色授予的权限，例如将某用户配置为管理员、将某用户配置为试用期。

权限类型：

权限一般分为以下类型：

配置类：直接授予、获取的角色权限、操作权限、数据权限；
积累类：根据用户操作经验产生的积分，对应不同的权限。

权限类数据特征：权限类数据可能不仅是一个最终结果，也可能是一个未完结的申请流程，该类参数在用户纬度内限制根据业务决定。

5. 业务类

定义：由于用户操作或使用生成的业务流水/创造的数据。例如上例中用户发布的文章、用户设置的收藏文章标签、消息、后台的每日使用人数。

特征：该类参数在用户纬度内的限制根据业务决定。

三、历史数据合并处理方式

1. 标示类

场景：用户持有A、B两个账号，两个账号的昵称分别为小王、小李，现对两个账号发起合并，并指定账号A为主账号。

问题：数据合并后用户昵称有两个，不知道使用哪个。

账号体系（2）| 账号合并的历史数据处理

案例中的用户昵称为标示类数据，标示类数据是对用户身份的标示，与userID同一级别，因此在一个账号内有唯一性；在上例没有正确处理该数据，产生了数据冲突的异常，最终无法精准定位。

所以标示类数据的正确合并方式为：由发起合并的用户指定保留数据的账号，覆盖掉其余待合并账号的数据。

注意：最终保留的所有标示类数据需都取自同一个账号，若不同用户的标示数据拼合在一起，可能影响后续业务数据调用。

2. 定义类

场景：用户持有A、B两个账号。分别对某些用户设置了黑名单，屏蔽他们的消息，两个账号设置的内容有重复项，现对两个账号发起合并申请。

问题：数据合并后黑名单出现重复项。

账号体系（2）| 账号合并的历史数据处理

案例中的黑名单设置即为定义类数据，该类参数定义个人属性，因此在个人纬度是不可重复的。在上例中没有正确处理该数据，产生了数据重复的异常，使得最终数据统计错误、数据冗余，严重的话会引发bug，数据失效。

所以定义类数据的正确合并方式为：由于定义类参数定义个人属性，因此合并后的账号需要将所有待合并账号的定义类数据累计起来；为了避免重复，需要进行去重。

3. 关系类

场景：对A、B两个账号发起合并，用户C关注了B账号；合并处理后仅保留A为代表用户身份的主账号，并将所有数据都迁移累计到A账号下，B账号作废。

问题：用户C无法再访问关注名单中的B账号。

账号体系（2）| 账号合并的历史数据处理

案例中的关注关系即为关系类数据，该类数据是用户与系统中非本人数据产生的关系，因此要求合并后的账号与历史其他非本人数据的关系依旧保存；在上例中没有正确处理该数据，产生了数据失位的异常，导致历史的关系无法定位追踪。

场景：一个文章可以打多个不同的标签，用户对A、B两个账号发起合并，两个账号的收藏夹内有相同文章、相同的标签；合并过程中直接将两个账号中这两个参数进行合并去重，未考虑对应关系。

问题：数据是完完整整都合并入最终账号内，但是每个文章的标签是什么呢？

账号体系（2）| 账号合并的历史数据处理

案例中的标签与文章存在关联关系，在合并时没有考虑这部分关系，导致最终的数据错位，数据间的关联关系没办法恢复。

综上，关系类数据的正确合并方式为：待合并账号与系统中本人、非本人数据产生的关系，需要迁移到最终合并后的账号。

例如第一例中，需要将C账号收藏夹中的B账号，切换为A账号，实现关联关系的迁移。

当然了，处理这类需求时要考虑业务场景，不同的场景可能有不同的处理方法：

若为强交互的产品，如社交类产品，需要让其他用户及时准确定位到合并后的账号；因此需要将B账号切换为A账号；
若为弱交互的产品，如资讯类产品，只需要让用户知道将来如何继续跟踪B账号；因此，在用户主动查询、点击B账号时，再提醒其已经合并作废，并提供合并后的A账号路径即可。

4. 权限类

场景：系统规定，用户成就勋章对于一个账号是唯一且分等级的，不同的等级对应不同的用户权益。

用户对A、B两个账号发起合并，两个账号的勋章分别是“笔杆子10级”与“笔杆子3级”；合并处理后仅保留A为代表用户身份的主账号，并将所有数据都迁移累计到A账号下。

问题：A的勋章为“笔杆子10级”与“笔杆子3级”，现在用户到底算是10级还是3级？级别相关的权益如何判定？

账号体系（2）| 账号合并的历史数据处理

案例中的勋章即为权限类数据，此类权限类的数据具有唯一性，在上例没有正确处理该数据，产生了数据冲突的异常，最终无法精准提供后续的服务。

与标示类数据处理方式类似，具有唯一性的权限类数据的合并最终只需保留一个权限，处理方式也是覆盖，但是具体保留哪个账号的数据与具体的业务场景相关。

再举个例子，后台对帐号A的角色配置为编辑，对帐号B的角色配置为运营，现对两个帐号发器合并，合并后用户的角色应该是什么？若系统支持一人多角色，那么合并后用户的权限为运营+编辑，反之就要去抉择保留哪个角色。

由此可见，权限类数据对合并规则与业务息息相关，例如从不同获取方式来看：

付费购买：此类权限是用户付出金钱成本置换到的权限所有权，因此保留最高权限，维护用户的利益；

系统赋予：

配置类：由具体业务限制决定是去重合并or保留一种权限；
积累类：虽然积分是用户操作积累的，但考虑到合并的开发难度，也可以结合实际业务场景决定是只保留主账户积分or进行累计。可以换算成现金的积分需要进行累计，例如信用卡积分。

5. 业务类

业务类数据是由于用户操作或使用生成的业务流水/创造的数据，本着“数据是用户操作产生的，用户有对其的使用权及控制权，非用户本人主观操作数据不可变动，在操作时要避免历史数据的丢失”的原则，对此类业务数据使用累计+重新排序的方式进行合并；一般是按照时间顺序，例如用户消息、订单流水，此处就不对其进行展开描述。