用户系统,主要分为账号体系和用户信息两大类。账号体系包括,登陆验证、注册、第三方授权、以及权限管理。用户信息包括,用户地理位置、用户属性、用户设备信息、还有用户日志信息。本文会介绍用户模块的具体落地方案。
登陆验证
在一般项目账号体系中,一般会要求支持手机、邮箱、账号、QQ、微信、微博实现登陆。后面三种方式都是基于第三方授权后,完成的身份验证。手机、邮箱、账号则是相对传统的登录方式。
用户身份与登录的授权方式是独立开的,即用户uid和登录方式是一对多的关系。举例来说,用户A在使用微博授权登陆后,服务端鉴别身份信息为uid=123。用户A下次使用微信登陆,服务端鉴别身份同样为uid=123。不存在同一用户A拥有多个账号信息的现象。登陆授权表设计如下。
|
|
用户信息
用户信息,为便于扩展,分成两类。用户基础信息和用户拓展信息。基本信息用来保存用户的基本属性,年龄、性别、生日、头像、手机号码等。扩展信息,用来保存用户的设备信息或其他可扩展的内容。另外还有位置信息,这个可独立出来,也可合并到扩展信息中,根据自己的使用场景来定。
|
|
用户日志信息
日志信息,用来保存用户注册或者登陆行为的。另外会有一些修改密码或者修改重要信息的日志记录。
|
|
全局uid
建议不要使用表的主键作为用户ID,而是使用ID生成器(发号器)生成用户的唯一标示guid。当用户量急剧上升时,往往会采取分库分表的方法,然后通过将uid取余写到不同的表中。如果单纯的以某个表主键作为ID。会限制插入性能和增加业务复杂度,其次在分布式数据库中也无法保证ID唯一性。
全局ID生成,是有很多方案的。简单一点,可以采用redis自增属性,因为其具有原子性,在分布式坏境中,能保证ID的唯一性。另外还有其他的一些开源方案,可自行Google。
Access Token
与传统的Session相比,Access Token比较适合做RESTful Api开发。传统Web应用中,用户登陆后会写用户信息到cookie中,服务端通过Session就能得到用户的身份。
Access Token的是OAuth2.0中用户经过授权后,返回调用API的凭证。对于自己的应用来讲,用户在登录后,即返回access_token。在token有效期内可凭借此凭证,调用其他接口。对于access_token的刷新有两种方案,第一种每次用户重启app时,重新refresh。第二种,在调用周期内服务端发现access token可能过期时,返回新的token给客户端。
至于Access Token的生成,这个并没有规定,只要保证其唯一性即可。简单点,对用户uid和当前时间哈希得到新的Access Token,并设置过期时间。另外也可以采用JWT实现。