微信帐号回收系统

微信帐号回收系统     大家都知道，QQ号即将耗尽根本原因是因为QQ号在前后台的表示方法为32位整型，也就限制QQ用户的整体空间为42亿     对于微信，用户能感知的是用户名id，是以字符串表示似乎不存在空间问题？     然而事与愿违，微信在设计之初就将用户id转换为32位整数进行标识，然后在庞大的后台系统里流动     所以QQ号和微信Uin，存在相同的空间问题：最大42亿 (大家很关心32位的历史，这里稍微补充一下这个确实是历史原因 微信的横空出世，依托的是广研多年来的技术积累（包括各种框架和底层存储等等）一个新兴产品，为了快速迭代功能和业务存活，在机会窗口如此窄小的情况下，沿用现成的技术积累确实是最好的选择如果当初是选择先优化底层，再开发业务，可能微信今天就不存在了，也没有了后面的故事) 2.微信Uin自身特点     第一，微信用户尽管基数已相当庞大，但日注册速度有增无减，消耗速度增加     第二，由于系统和历史原因，历史上有大量Uin浪费     第三，活跃用户增长速度赶不上注册量     第四，微信Uin用户无法感知（QQ号是直接派发给用户的） 3.解决     方案一，升级64位         优点：彻底解决问题，甚至可以支持物联网空间升级为42亿*42亿         困难：后台系统已非常庞大，涉及模块和业务众多，64位修改不可能一蹴而就升级过程非常复杂系统容易崩溃业务无法服务另外客户端公众平台支付游戏等等业务需要全盘修改，工程浩大     方案二，Uin回收重复利用         优点：纯后台操作，收放自如相对简单一些         困难：未能彻底消除空间隐患，对于用户数据梳理工作量巨大外围数据庞大         可行性：已消耗的Uin跟活跃Uin之间，有巨大的差额     综合考虑后，我们决定启动回收系统建设，减缓微信Uin的消耗速度，给64方案预留足够时间 4.回收系统设计 三个问题：     问题一，哪些Uin可以回收如何识别？     问题二，回收执行的具体过程？     问题三，回收后如何管理和重放？ 问题一，哪些Uin可以回收如何识别？         通过分析，我们得出以下几类可以回收的微信Uin         第一类，微信初期为了负载均衡，跳号分配导致的巨大间隙             这部分较简单，确认跳号分配的号段，然后通过工具扫描一遍便出来了         第二类，注册非原子操作，持续产生的零散废弃Uin             通过注册跟踪系统识别         第三类，现网不活跃用户（包含历史注册的僵尸垃圾用户）             通过存量分类系统识别         第四类，持续新注册的垃圾用户             通过注册跟踪系统识别 针对第二类和第四类的实时回收，设计注册跟踪系统： 注册跟踪系统细节内容：       建设通用定时服务（Timer_svr），提供各种各样的定时服务       只要产生一次注册请求（或者说一次分配Uin请求），这个Uin将加入到注册检查队列       注册检查队列通过设定定时，在4个时间点检查Uin的使用情况 通过以上注册检查队列的4个检查时间点，我们输出大批垃圾Uin       另外，注册检查队列可以延伸，例如180360天但由于垃圾帐号在前期活跃度指数级降低，超过90天的情况，将放在存量分类系统中识别 针对第三类的异步回收，设计存量分类系统： 细节内容：               从大数据平台，通过不同方法，筛选不同出候选者群主要是缩小范围提高回收效率降低误伤风险         存量检查队列，通过多个纬度对候选者进行组合筛选，并对不同候选者群实施不同策略         检查队列最后会对所有即将回收的用户进行兜底检查，就是一些在线状态，登录态做最后检查 问题二，回收执行的具体过程？ 问题一中讨论的两条队列，最终输出目标用户，接下来对其执行回收动作 有几个点需要考虑： a在执行过程中，不适合再做各种检查，不仅操作重，而且用户数据可能已经清空，无法检查但同时要防止普通用户误进回收执行 b执行其实是一系列动作的控制，需要有一个序列控制器 c执行的某一些步骤可能是有时间限制的，如封号一个月，重放冷却半年等，需要接入定时服务 d备份数据需要唯一id，所有需要备份数据key全部转城用户id，而非Uin 回收队列设计如下：     注册检查队列和存量检查队列，通过检查后，将授予Uin一个轻量级票据（ticket）     回收执行队列，每次进入都必须确认票据的有效性，票据只要验证通过，就会续期防止过期回收过程完全执行完毕，才会清除票据     回收队列会对被回收的用户进行核心数据的完整备份并可通过恢复工具进行恢复     回收序列：永久封号（特定时长）封号到期开始备份（帐号关系链朋友圈用户属性等核心数据，还有部分附加数据）备份完毕开始删除（核心数据内部业务数据外部数据安全数据大数据平台数据等）存入预备池定时重放     StepControl: 记录Uin的所有步骤控制nextstep使用乐观并发锁防止并发     Backupsvr: 负责转换备份用户数据（例如涉及Uin的地方，全部转化成username进行备份）如下图，因为用户已被删除，username->uin的映射已不存在，backupsvr会将username写入各IDC新的存储，注册或者改名时将在本地IDC检查，保证username依旧唯一性 Deletesvr: 负责删除用户所有数据并且实时通知外部门删除自身数据对底层kv直接穿透，绕开业务前端，并可以平行扩展外部门通知接口由于权限很大，deletesvr要配合stepcontrol进行权限校验，防止误删  Timersvr: 例如不同类型的Uin，封号时间不同，有长有短放入预备池冷却时间也有长有短，通过timersvr来进行定时     恢复工具: 通过backupsvr，获取数据，恢复用户状态 问题三，回收后如何管理和重放？ 通过回收队列出来的都是零散的Uin个体而以前分配系统存在的问题：     号段管理：每次取一批Uin出来放入内存，很容易宕机浪费一批     配置号段后，服务都是有状态的，无法快速横向扩展运维复杂     由于每个IDC的注册是分散的，资源池无法共享，都靠人工预先配置     能管理几十亿级Uin     所有IDC共享整个资源池，无需为每一台机器配置资源     Uin的使用精确到个体，而不是号段 分发设计： 池&分发细节：     中心和本地池，都按Uin模桶数哈希后，打入每个桶内，桶内按Uin作为主键     中心池可以装载几十亿个Uin，全装载，本地池可以装载百万级Uin     本地池初始没有资源，全部从中心池拉去以后根据自己资源的使用情况，向中心池拉取这既保证本地池有资源，也不会提前占用资源     注册分配时，本地池1k个桶随机分发，降低了资源冲突率本地池的分发svr可以随意扩展，无状态     入库中心池时，需要检查本地池中心池和是否已存在用户     每个桶，在微信后台来看，是kv里的一个key     从此Uin池统一，运维简单，分配Uin的svr无状态，使用本地池即可      假如有误删用户的情况，并且此Uin已被重放出去，这并不影响我们的恢复流程后台将为误删用户提供新的Uin，并恢复核心数据，用户不会感知     解封回收终止：即将回收的用户，突然被解封登录，立刻终止回收在进入任何一个备份动作前，会对封号状态和登录时间作最简单的检查     回收登录监控：回收封号无法解封，但登录动作可以监控通过监控封号产生的登录请求，更好地控制后台的回收策略，防止出现大规模波动导致的大量投诉     双校验关键数据为了保证关键数据的有效，通过不同模块不同存储，进行相互校验（如最后登录时间通过 独立登录时间+设备登录成功后信息更新时间，两者合并计算得到）降低了因数据错乱导致误伤的概率 已回收：6亿 存量日回收：200w-400w 新垃圾注册日回收：20w 日千分之二注册的残缺Uin实时回收利用 每次后台故障时产生的十几万的废弃Uin，实时回收利用 对于新注册而言，回收放号已占全局放号的60%