用户唯一化设计

根据现有的能力设计一个模型，如果大家有更优的办法，欢迎指正与交流。

本设计是建立在已有用户中心系统的基础上，各个系统账号统一，并且也是针对hbase数据库的一个设计（若没有统一账号，建议先统一各个系统账号，想一步到位，也不是不可，需要花费的代价……）

 

根据推荐引擎业务来说明。

1. 用户行为采集。

2. 离线job清洗转化行为数据

3. 推荐计算（此处包含较多，不单独介绍，后续有时间会整理出来其架构及实施方案）

4. 实时读取历史推荐数据及与发生行为推荐计算

 

由上述可知，有离线任务，也有实时请求计算。

离线任务一般处理TB级数据，那么uid的生成及唯一性将成为瓶颈。（因为涉及到查询效率，uid不宜过长，又必须在分布式及高并发情况下保证唯一）。在线实时场景主要根据用户的登录情况来获取uid读取推荐数据。

咱们以场景来说明，比较直观。

1. 未登录用户调用推荐接口，此时，需要判断是否已登录过，是否有历史推荐记录。所以，需要调用uid.mapping接口获取uid。

2. 已登录用户请求，根据登录用户获取uid或用户标识获取uid。

3. 不同渠道使用不同账号登录（多渠道数据相通）

 

 

用户唯一标识与uid关系表。用户唯一标识为rowkey,用户唯一标识与uid为多对一关系。

字段	名称	注解
identity	唯一标识	包括已登录账号、cookieId、序列号，此表不可重复
uid	身份标识	用户在本系统唯一的，确定用户身份的标识
channel	渠道信息
islogin	是否为登录账号
crtime	时间戳

 

 

uid.mapping服务处理场景：

进行唯一标识与uid之间的维护。

1. 未登录用户

查询关系表，若没有uid，则生成uid，存储redis，并丢到队列中去。

1. 登录用户

若登录账号与用户标识查询uid，若都有uid，直接返回uid。

若用户标识有uid，登录账号没有uid，则把登录账号-uid丢到队列中，返回uid。

若用户标识没有uid，登录账号有uid，则把用户标识-uid丢到队列中，返回uid。

若都没有uid，生成uid，把用户标识-uid，登录账号-uid丢到队列中，返回uid。

 

当然，上述所有操作需要用到redis或本地缓存。所有调用uid.mapping服务也需要缓存uid信息。