点击上方“JAVA”并为公众号加星标
重货，尽快送达
多账户统一登录名说明
这里的多账户和系统层面的多账户是不同的。我们所说的多账户系统是指在我们的互联网应用中，我们的应用程序会使用多个第三方账户来登录，比如常用的APP：网易、微信、QQ等。
内容
通过这篇文章：
您可以了解到：多个用户的技术方案细节，以及相应的表格设计和流程设计。
你不能学到的东西：和其他文章一样，我在这里不会有具体的代码实现细节。如果计划正确的话，无论代码怎么写，都不会太糟糕。
架构演进与创业初期
归根结底还是创业初期，因为这个时候用户数量还比较少，上面提到的其他第三方账户系统甚至还没有接入。只需要一个自建的系统就足够了。如果自建系统的话，目前常用的有
用户名 密码 注册 登录
这种方法在很多早期的网站建设中都有使用。先注册再登录，这个方法在老版的cms里可以找到。
流程图：
流程说明：
前端将用户名和密码发送给服务器，服务器定期判断用户名和密码是否满足长度、用户名是否重复等条件。如果条件不通过，则直接返回相应的错误码给前端。这里是密码字段，为了防止在传输过程中被截获，建议在上传之前加密。默认情况下，我们的传输密码会进行md5加密，然后记录到数据库中再进行加密。即使从数据库中删除也没有问题。不要以纯文本形式存储密码。
验证通过后，用户名和密码将被写入数据库，并进行后续积分发放等操作，此处不再展开。
现在登录，前端会将用户名和密码发送到服务器。服务器首先会验证登录次数是否超过设定的阈值。如果超过设定的阈值，就只能继续等待kaiyun全站网页版登录，被锁在暗室里。
如果没有超出继续登录的逻辑，请判断用户名和密码是否正确。如果密码错误，则判断阈值。如果超过，黑室就会关闭。请记住，黑室必须设置过期时间，否则将永久关闭。这可以使用 redis 的过期功能来完成。
登录成功后，就会进行后续的所有后期逻辑，比如加积分等。 。 。等待操作。
手机号码注册及登录
流程图：
流程说明：
首先输入手机号码，然后发送到服务器。服务器将手机号码记录在我们的数据库中，然后生成随机验证码，将手机号码和验证码绑定到一个redis上，然后记录过期时间。这个过期时间一般需要10分钟左右，也就是我们一般手机验证码的有效期。
手机收到短信后，在界面上填写验证码并发送给服务器。服务器收到验证码后，会在redis中查询手机号对应的验证码。如果失败，将返回错误代码。
成功后kaiyun.ccm，登录。
这里好像没有明确的注册和登录操作。其实发送手机号码就可以看成是常规的注册，然后输入后续的验证码就是登录操作。
问：如果我需要密码怎么办？
答：只需在后续产品中添加重新记录手机号码和密码的功能即可。这也是现在很常见的方法。但在移动互联网爆发的时代，密码不再那么重要。反正我永远记不住密码。如果您的手机号码可以操作该应用程序云开·全站体育app登录，您将永远不需要密码来操作它。
数据库设计
表结构：
自增ID用户名、密码、手机号码错误次数
用户1
7fef6171469e80d32c0559f88b377245
13456789012
用户2
7fef6171469e80d32c0559f88b377245
13456789013
阐明：
这里只是对需要用到的数据进行简单说明，不扩展具体场景。这个表结构可以满足上面两种方案的设计。
引入第三方账户解决方案
下面是QQ-SDK的登录逻辑。我们先看一下时序图。
阐明：
客户端调出登录界面，输入用户名和密码。这是第三方用户名和密码。登录成功后，会返回access_token openid expire_in。这个过程会使用oauth2.0，但是在sdk中内置回调来获取。稍后我们会讲解我们自己的oauth2.0实现
客户端获取access_token、openid、login_type（qq、微信...）并向应用服务器请求。应用服务器拿到数据后，会根据对应的login_type去对应的用户中心验证access_token和openid。如果验证失败，将返回相应的错误码。
验证通过后，会判断本地的login_type和openid是否存在。如果没有，则获取远程用户名、头像等基本信息作为本地基本数据，并返回code值。
如果已经存在，则执行登录操作并返回code值。
客户端获取到code值后，将其换成token值。这完全遵循oauth2.0协议。后续的每个请求都必须携带令牌。令牌值会在服务器上保留很长时间，因为我们要做的是那种操作永远不会离线，所以我们为每个请求累积令牌过期时间。
数据库设计
根据一些朋友的建议，我在这里整理一下数据库：
用户基表（用户）
现场笔记
用户身份
用户身份
代币
用户登录令牌
过期时间
令牌过期时间
尝试次数
登录尝试失败的次数
用户认证关联表（user_auth_rel）
现场笔记
ID
自增id
用户身份
用户身份
授权ID
验证表 ID
授权类型
验证类型（本地、第三种）
本地用户表（user_local_auth）
现场备注
授权ID
认证id，自增id
用户名
用户唯一标识符
密码
用户密码
移动的
用户手机
第三方用户表（user_third_auth）
现场笔记
授权ID
用户身份
开放ID
第三方用户唯一标识符
登录类型
第三方平台识别（QQ、微信...）
访问令牌
使用第三方获取的access_token进行验证。
阐明
users表只是我们业务端的登录用，主要是针对我们自己业务的oauth2.0业务。
user_local_auth就是用自己的用户名、密码、手机号登录信息进行登录。
user_third_auth是我们第三方用户系统的数据记录。
user_auth_rel 用于将用户表与 user_local_auth 和 user_third_auth 关联起来。
整个设计理念就是在存储方面区分自建用户和第三方。这从架构演进的角度来看也是合理的。起初，大多数用户系统都是自建的，然后提供外部访问。
总结
一般来说，第三方用户的接入技术比较简单。这里又设计了一个user_thirds，以支持足够多的第三方访问。当然，一般我们只需要登录两到三次即可。登录次数太多不仅本身需要花钱维护，而且界面布局也不好看。
希望通过以上的学习，您能够对我们的多账户登录有更好的了解。这里的设计方案不包含分表、分库、不包含服务。这是一个简单而直接的设计。当然，用户数量和需求是不同的。在此基础上还有很多补充，感谢您的阅读！ ！ ！
