共计 2463 个字符，预计需要花费 7 分钟才能阅读完成。
多账户的对立登录
名称解释
这里的多账户区别于零碎级别的，咱们讲的多账户零碎是指，在咱们互联网利用当中，咱们的利用会应用多个第三方账号进行登录，比方当初罕用的 APP：网易、微信、QQ 等等。
本文内容
多账户零碎的技术计划细节，以及相应的表设计，流程设计。
架构演进
初期
归结为初期是因为这个时候用户量比拟少，甚至还没有接入下面所说的其余第三方的账户零碎，只是自建的体系就能够满足，自建体系目前罕用的有：
用户名明码注册登陆
这种形式在很多初期网站建设会应用，先注册，再进行登录，在老一点的 cms 中都能找到这个影子。
- 流程图：
- 流程阐明：
1、前端将用户名、密码发送到服务器，服务器进行惯例的判断，判断用户名、明码长度是否满足，用户名是否反复等条件，条件不通过间接返回对应错误码给到前端，这里明码字段，为了避免传输过程中被截胡，倡议加密再上传，咱们的传输明码默认都是会进行一个 md5 加密，而后记录到数据库再进行一层加密，就算是脱库也没事，明码不要明文存储。
2、校验通过后，就将用户名明码写入数据库，并进行前面积分发放等操作，这里不开展。
3、当初进行登录，前端将用户名，密码发送给到服务端，服务端首先会校验登录次数是否超过设置的阈值，如果超过只能持续期待被关小黑屋。
4、如果未超过持续登录逻辑，判断用户名、明码是否正确，不正确明码则进行阈值的判断，如果超过则关小黑屋，记住小黑屋必须设置过期工夫，要不然就会永恒关上了，这个能够用 redis 的过期来做。
5、登录胜利后进行后续的所有后置逻辑，比方加积分 … 等操作。
手机号注册登陆
- 流程图
- 流程阐明：
1、首先输出手机号，而后发送到服务端，服务端将手机号记录在咱们数据库中，而后生成随机验证码，并将手机号和验证码绑定到一个 redis 外面，而后记录过期工夫，这个过期工夫个别是 10 分钟左右，这就是咱们个别手机验证码的有效期。
2、手机接管到手机短信后，那么就在界面填写验证码发送服务端，服务端收到验证码后就会在 redis 外面查问到这个手机号对应的验证码，失败就返回错误码。
胜利后就进行登录操作。
3、这里看起来没有明确的注册登录操作，其实在发送手机号码就能够认为是一个惯例的注册，而后前面的验证码输出就是一个登陆操作。
问：如果要明码怎么办？
答：在后续产品外面减少一个“手机号码明码补录的性能”即可，这也是当初很惯例的手法，然而当初挪动互联网大爆炸时代，明码曾经显得不是那么重要了，如果手机号码能操作的 app，能够不必明码来操作。
数据库设计
表构造：
| 自增 id | 用户名 | 明码 | 手机号 | 谬误次数 |
| 1 | user1 | 7fef6171469e80d32c0559f88b377245 | 13456789012 | 0 |
| 2 | user2 | 7fef6171469e80d32c0559f88b377245 | 13456789013 | 0 |
阐明：
这里只是单纯阐明须要用到的数据，没有扩大具体场景, 这个表构造可能满足下面两个计划的设计。
引入第三方账户计划
这里是以 QQ-SDK 的登录逻辑，咱们先看一下时序图：
- 阐明：
1、客户端本人调起登录的界面，进行输出用户名、明码，这里的是第三方的用户名，明码，登录胜利后，会返回 access_token openid expire_in, 这过程会应用到 oauth2.0，不过在 sdk 外面进行内置回调获取了，前面咱们会阐明咱们本身实现的 oauth2.0
2、客户端拿到 access_token、openid、login_type（qq、wechat…）申请应用服务器，应用服务器拿到这些数据后就会依据对应的 login_type 去对应的用户核心进行 access_token 和 openid 进行校验。校验不通过则返回对应错误码
3、校验通过后就会判断本地是否有这个 login_type 和 openid 是否存在，不存在则进行获取近程的用户名、头像等根底信息来作为本地根底数据，并且返回 code 值
4、如果曾经存在，那就是进行登录操作，返回 code 值。
5、客户端拿到 code 值后进行 token 值的换取，这个齐全遵循 oauth2.0 的协定来走的，后续每次申请必须带上 token，token 值在服务端的工夫比拟久，因为咱们想要做的是那种永不下线的操作，所以每次申请咱们都将 token 过期工夫进行累加。
数据库设计
| 用户根底表（users） | |
|---|---|
| 字段 | 备注 |
| user_id | 用户 id |
| token | 用户登陆的 token |
| expire_in | token 过期工夫 |
| try_times | 登录失败次数 |
| 用户验证关联表（user_auth_rel） | |
|---|---|
| 字段 | 备注 |
| id | 自增 id |
| user_id | 用户 id |
| auth_id | 验证表 id |
| auth_type | 验证类型 (local、third) |
| 本地用户表（user_local_auth） | |
|---|---|
| 字段 | 备注 |
| auth_id | 认证 id，自增 id |
| user_name | 用户惟一标识 |
| password | 用户明码 |
| mobile | 用户手机 |
| 第三方用户表（user_third_auth） | |
|---|---|
| 字段 | 备注 |
| auth_id | 用户 id |
| openid | 第三方用户惟一标识 |
| login_type | 第三方平台标识 (qq、wechat…) |
| access_token | 第三方获取的 access_token, 校验应用 |
- 阐明
1、users 表只是单纯针对咱们业务侧的登录，次要是做本身业务的 oauth2.0 业务，
2、user_local_auth 是做本人用户名、明码登录，手机号码登录信息记录，
3、user_third_auth 是咱们第三方用户体系的数据记录，
4、user_auth_rel 是用来关联咱们 users 表与 user_local_auth、user_third_auth。
5、整个设计理念就是将自建用户与第三方在存储上辨别，这在架构演进上也是合乎情理的，开始用户体系大多自建，而后才是对外接入。
总结
1、总的来讲，第三方用户的接入技术上来讲是比较简单的，这里设计多一个 user_thirds 是能够反对足够多的第三方接入，当然个别咱们也就两三个登录就好，太多登录方不仅减少本身保护老本，界面摆盘也不难看。
2、这里的设计方案不蕴含分表分库、没有服务化，就是简略间接的设计。
正文完