一、名称解释
这里的多帐户与系统级别有所区别。 多帐户系统是指在我们的网络APP应用程序中，我们的APP应用程序使用多个第三方帐户登录。 目前常用的网络音乐(APP )登录方法必须包括互联网、微信和QQ
二、内容
在本文中，您将了解有关多用户下技术方案的详细信息，以及相应的表格设计和流程设计。 不，和其他文章一样，我这里没有具体的代码实现细节。 方案是正确的。 代码怎么写都不差。三、架构演进
3.1创业初期
创业初期回归，是因为此时用户较少，即使没有访问上述其他第三方客户系统，也只有自制系统才能满足。 在自制的系统中，现在常用的是
3.1.1用户名密码注册登录
这种方式被很多早期网站建设会使用，通过注册后注册，即使有点旧的cms也能找到这个影子。
流程图：
流程说明：
前端将用户名、密码发送到服务器。 服务器进行常规判断，判断是否满足用户名、密码长度、用户名是否重复等条件。 条件是不要通过直接返回将相应的错误代码传递给前端。 其中，密码字段建议加密上传，以免在传输过程中被截胡。 默认情况下，我们的传输密码进行md5加密，记录在数据库中，然后进行进一步加密。 拆下磁带库也没关系。 密码请不要用明文保存。
如果检查通过，则将用户名密码写入数据库，稍后进行发放积分等操作，但此处不展开。
现在进行登录，前端将用户名、密码发送到服务端，服务端只能先检查登录次数是否超过了设定的阈值，如果超过了，就等着被关在一个小黑房间里。
如果未超出持续登录逻辑，则判断用户名、密码是否正确，如果不正确，则判断阈值。 超过的情况下关闭小黑屋。 请记住，小黑屋必须设定有效期限。 否则就永远关闭。 这可以在redis到期时完成。
成功登录后，执行所有后续的后置逻辑，如加分。 等待操作。
3.1.2手机号码登录
流程图：
流程说明：
首先输入手机号码发送到服务端。 服务端将手机号码记录在我们的数据库里，生成随机验证码，将手机号码和验证码绑定在一个redis上，记录有效期。 这个有效期通常是10分钟左右。 这是我们普通手机验证码的有效期。
接收到手机短信后，在屏幕上填写验证码发送给服务端，服务端收到验证码后在redis中查询该手机号码对应的验证码，失败后返回错误码。
成功后进行登录操作。
这里看起来没有明确的注册登记操作，但实际上发送手机号码被认为是正常的登记。 然后，之后的验证码输入为登录操作。
问：密码怎么办？
答：在后续产品中添加手机号码密码补写功能即可。 这现在也是一种普通的手法，但在如今的移动互联网大爆炸时代，密码并不那么重要。 总之我记不住密码。 如果是可以操作手机号码的APP，绝对不会用密码操作。
3.1.3数据库设计
3.1.3.1表的结构
3.1.3.2说明
这里只是简单地说明必要的数据，没有扩展具体的场景，但这个表结构可以满足以上两种方案的设计。
3.2引入第三方账户方案
这里是QQ-SDK的登录逻辑，先看看时序图吧
说明：
客户端自行调用登录界面，输入用户名、密码。 这里的是第三方的用户名、密码。 成功登录后，将返回access_token openid expire_in。 此过程最多使用oauth2.0，但通过对sdk进行内置回调获取。 稍后我将介绍我们自己实现的oauth2.0
客户端获取access_token、openid、login_type(QQ、wechat…)并请求APP应用程序服务器，当APP应用程序服务器获取这些数据时，相应的log in _ TTT… 如果验证失败，则返回对应的错误代码
如果验证成功，则确定本地是否存在此login_type和openid，如果不存在，则获取远程用户名、头像等基础信息作为本地基础数据，并返回代码值
如果已经存在，则是进行登录操作并返回代码值。
客户端获取代码值后，进行token值的交换。 这完全遵循oauth2.0协议，每个后续请求都必须携带token。 token值在服务端的时间很长。 因为我们想做的是那样的离线操作，所以每个请求都要加上token的有效期限。
3.2.1数据库设计
3.2.1.1表的结构
3.2.1.2说明
users表格只针对我们的业务端登录，主要进行自己业务的oauth2.0业务。
user_local_auth表示自己的用户名、密码的登录、手机号码的登录信息的记录，
user_third_auth是我们第三方用户体系的数据记录，
user_auth_rel用于将users表与user_local_auth和user_third_auth相关联。
整个设计理念是将自制用户和第三方存储在存储器中
上区分，这在架构演进上也是合乎情理的，开始用户体系大多自建，而后才是对外接入。四、总结
1、总的来讲，第三方用户的接入技术上来讲是比较简单的，这里设计多一个user_thirds是可以支持足够多的第三方接入，当然一般我们也就两三个登录就好，太多登录方不仅自身维护成本，界面摆盘也不好看不是。
2、希望大家能够通过以上学习，能够对于我们多账户登录有一个比较好的认知，这里设计方案不包含分表分库、没有服务化，就是简单直接的设计，当然用户量和需要的不一样，在这个基础上还要加很多东西，谢谢大家阅读！！!