账号体系——账号合并的历史数据处理

之前对合并/打通这两种账号的交互做了概念区分及处理方式的讲解,接下来会分为两篇分别对账号合并、打通后的历史数据处理方法进行说明。

先回顾账号合并:

概念:一个系统内,一个用户的多个账号合并成一个账号。

场景:一个系统内,相同类型的账号合并/不同类型的账号合并;

要求:一个系统中一个用户身份只有一个账号,且所有登录方式产生的数据都迁移累计在该账号下。

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

开始的开始,举个栗子

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

你负责一个问答社群平台的账号系统,现在接到一个需求:

给用户提供账号合并的功能,用户可以对名下多个账号发起合并请求,实现对多个账号名下收藏关注的文章用户、阅读签到等产生的成就权益等数据进行统一管理。

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

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

技术实现合并后,发现几个问题:

待合并的两个账号,关注了相同的用户。合并后账号产生了重复关注的用户,导致总数统计错误,数据冗余。

待合并的两个账号,成就勋章分别是1级与3级,合并后用户依据勋章级别开放的权限出现了业务冲突。

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

01

数据有哪些类型

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

▋标示类

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

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

▋定义类

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

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

▋关系类

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

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

▋权限类

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

获取方式:

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

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

  • 主动:由用户发起的权限申请,例如申请成为专栏作家;

  • 被动:系统根据用户使用情况授予的权限,例如用户积分对应的权限;系统根据用户在系统中所处的角色授予的权限,例如将某用户配置为管理员、将某用户配置为试用期。

权限一般分为以下类型:

  • 配置类:直接授予、获取的角色权限、操作权限、数据权限;

  • 积累类:根据用户操作经验产生的积分,对应不同的权限。

权限类数据特征:

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

▋业务类

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

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

02

历史数据合并处理方式

▋标示类

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

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

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

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

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

▋定义类

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

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

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

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

▋关系类

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

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

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

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

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

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

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

例如第一例中,需要将C账号收藏夹中的B账号,切换为A账号,实现关联关系的迁移。当然了,处理这类需求时要考虑业务场景。不同的场景可能有不同的处理方法。若为强交互的产品,如社交类产品,需要让其他用户及时准确定位到合并后的账号。因此需要将B账号切换为A账号;若为弱交互的产品,如资讯类产品,只需要让用户知道将来如何继续跟踪B账号。因此,在用户主动查询、点击B账号时,再提醒其已经合并作废,并提供合并后的A账号路径即可。

▋权限类

场景:系统规定,用户成就勋章对于一个账号是唯一且分等级的,不同的等级对应不同的用户权益。用户对A、B两个账号发起合并,两个账号的勋章分别是“笔杆子10级”与“笔杆子3级”。合并处理后仅保留A为代表用户身份的主账号,并将所有数据都迁移累计到A账号下。

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

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

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

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

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

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

系统赋予:

1)配置类:由具体业务限制决定是去重合并or保留一种权限;

2)积累类:虽然积分是用户操作积累的,但考虑到合并的开发难度,也可以结合实际业务场景决定是只保留主账户积分or进行累计。可以换算成现金的积分需要进行累计,例如信用卡积分。

▋业务类

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

总结

由上述全文可知,在处理合并账号的历史数据时,需要保证对所有历史数据的兼容,保留所有原始数据;也要进行相应的限制,避免数据处理错误导致的数据错误等风险。

所以,【兼容】【限制】就是历史数据处理的原则。万变不离其宗,下一篇对系统打通历史数据的处理,也会由这两个原则出发,请大家拭目以待~

↘好文推荐:

王慧文清华产品课

写给未来产品总监的一封信

菜鸟网络 | 寄件业务的产品逻辑

点个“在看”吧

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
图片批量裁剪器(精华版)是 一款功能丰富、实用、应有尽有的图片/视频批量裁剪、水印、转换、更名,以及其他处理的专业工具!批量处理时不低于5万个文件。 以管理员身份和兼容xp3模式下运行,可支持win7,win8,win10,64位。 图片批量裁剪器(精华版)功能 1. 支持常见图片类型如bmp,jpg,tif,gif,png,支持部分非常见图片类型,如PSD,PCX,ICO,Pdf,动态Gif等等;支持对大多数常见的音频/视频文件格式的裁剪、转换、水印、分割、合并等; 2.提供对图片文件的丰富多彩实用的各种批量裁剪模式,如相对、绝对、固定、大小、等分/非等分分切、分隔、同比/非同比缩放、拼接/无缝拼合、贴边等等几百种裁剪处理功能; 支持圆角矩形/椭圆形/圆形/任意角度裁剪,支持自定义圆角矩形半径裁剪; 3.其他更丰富的裁剪功能,请参见主页说明或程序,比如:提取图片上的文字并保存先裁剪后加水印一步到位忽略处理过的文件夹手动指定裁剪区域多裁剪区域裁剪打印二维码图片转Pdf 过滤小图或缩略图 AB文件夹配对拼合 …… 内置其他功能列表: 1.图片烙制水印(文字水印,图片水印,淘宝卖家专用水印,以及其他上百种水印功能模式供选择,特别如以拍摄日期作为文字水印,递增数字水印等等,批量制卡证等) 2.图片旋转及格式转换(特别功能如智能扳正) 3.图片亮度/对比度调整 4.图片压缩(特色功能如保留Exif信息的压缩) 5.定制图片大小/尺寸(特色功能如能按指定的文件大小压缩,比如压缩到120kb左右,仅压缩大图,小图忽略压缩等) 6.图片像素筛查(从海量图片中筛查出满足条件的图片供删除、移动、复制、更名等) 7.(图片)文件时间属性修改(比如更改拍摄日期,没有做不到只有想不到) 8.图像综合处理 9.(图片)文件批量更名(强大丰富的多种文件批量更名功能) 10.文件随机/顺序/定时抽取分发(将海量文件复制或移动到指定的文件夹中) 11.证件照批量更换背景颜色 12.色块/色条魔术棒裁剪,颜色替换 13.音视频裁剪/分割/合并/转换/加水印/录音/录像 14.批量替换图片中的图片或文字 15.图像批量组合排版 16.证件制作排版(广告公司实用) 17.Jpg图片Exif信息编辑器 18.重复或相似图片批量查找 19.相对/绝对/固定裁剪简易兼容备用版 20.Jpg转视频avi或其他(影楼后期制作DV工具) 21.图片批量浏览挑拣器(影楼客户自选照片实用) 22.图片批量叠加/混合 23.视频批量加密(特色功能如用户可自行在线找回播放密码,一机一码,一视频一码) 24.账号、密码批量管理小秘书(管理你各种账号密码,完全安全加密) 25.动态Gif图片裁剪、水印;图片压制成动态Gif(按时间轴裁剪,裁剪后的gif仍然是动画模式) 26.音频片段截取助手 27.广告喷绘大图专用分切器(喷绘行业专用) 图片批量水印裁剪器 v6.0.20161008精华版更新内容: 1.新增动态Gif水印区域批量涂抹模糊,或者图片水印区域批量涂抹功能; 2.修正水印添加模块中,还原或重设DPI功能时失效异常的问题; 3.在水印批量添加模块中,新增还原原图DPI以及转为CMYK印刷颜色模式的新功能; 4.新增批量生成二维码图片的功能; 5.新增图片裁剪/缩放/格式转换/添加水印等单张综合处理功能模块; 6.修正先选择后裁剪功能实现的问题; 7.新增批量对动态Gif文件指定水印区域模糊化处理功能; 8.新增定时对指定的目录中的图片挂机无人值守自动裁剪功能,忽略已处理过的图片文件; 9.新增纯文字水印添加功能模块; 10.新增学生证件照排版和学生胸卡排版制作打印功能模块; 11.改进修正Jpg系列图片转视频功能,并新增同时给转换后的视频叠加音频的功能; 12.修正改进动态Gif裁剪、水印功能模块; 13.改进跟图片OCR文字识别的有关问题和功能; 14.新增备用下载服务器和网络登录版; 15.修正精确去片头片尾功能; 16.修正某些音频视频文件播放时间不足一秒时无法加载入文件列表的异常; 17.修正媒体批量合并功能模块全部失效的问题; 18.新增以文件夹名作为动态文字水印的功能。 图片批量裁剪器(精华版)截图
MJ系统是一款专业的软文、稿件(含视频)系统内置集成软文媒体16000 多家,自媒体50000 多家 ,一键投放平台。该平台采用自助式的在线发布系统,用户可享受全自助式的发稿服务,投放涵盖各大新闻资讯网站、新浪微博、网易、今日头条、央广网、消费日报等多种互联网广告渠道。 MJ1.0(以下简称MJ系统) 熟悉媒介系统手册是使用本程序开发修改的前提,但是还是需要您静下心来好好看看! 后台访问 系统后台默认访问路径:- http://域名/admin.php 默认账号:admin 密码:123456 会员登录- http://域名/member.php 测试账户:13696884534 密码:123456 快速部署 本平台基于Thinkphp5.0+版本开发,系统自带完整后台以及一套响应式前台模板,放入PHP(5.6+)环境即可直接使用。 数据库选择 默认采用mysql数据库,请导入数据库文件(xxx.sql)并修改数据库连接文件信息(/app/database.php) return [ // 数据库类型 'type' => 'mysql',//无需修改 // 服务器地址 'hostname' => '127.0.0.1',//默认127.0.0.1 或 localhost // 数据库名 'database' => 'meitishare',//您创建的数据库名称 // 用户名 'username' => 'root',//数据库账户 // 密码 'password' => 'root',//数据库密码 目录结构 — 参考Thinkphp5.0目录结构,MJ系统支持多级目录绑定开发。 目录结构 Public 主站目录 Public_agency 代理目录 Publicarticle 图片附件目录 App 控制器/模型 extend 扩展 runtime 缓存 相关接口 所涉及接口1、短信接口(用于发布软文,会员注册、找回密码、编辑收稿提醒) 支付接口(支付宝、收款码等) 媒体资源接口(媒体+自媒体资源同步接口) 如有涉及相关侵权,请联系。 我们将及时修正删除 版权声明 特此免费授予获得此软件和相关文档文件(“软件”)副本的任何人无限制使用软件的权利,包括但不限于使用,复制,修改,合并的权利,发布,分发,再许可和/或出售本软件的副本,并允许具备软件的人员这样做,但须满足以下条件: 以上版权声明和本许可声明应包含在本软件的所有副本或大部分内容中。 本软件按“原样”提供,不提供任何形式的明示或暗示担保,包括但不限于对适销性,特定目的的适用性和非侵权性的担保。无论是由于软件,使用或其他方式产生的,与之有关或与之有关的合同,侵权或其他形式的任何索赔,损害或其他责任,作者或版权所有者概不负责。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值