uid.mapping用户唯一设计

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

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

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

用户行为采集。

离线job清洗转化行为数据

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

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

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

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

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

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

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

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

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

uid.mapping服务处理场景：

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

未登录用户

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

登录用户

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

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

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

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

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

未完待续，现在项目比较紧张，可能很长时间才更新一次，写的比较仓促。