解释多个账户统一登录名
这里的多账户和系统级别的多账户是不一样的，我们说的多账户系统是指在我们的互联网应用中，我们的应用会使用多个第三方的账号来登录，比如现在常用的APP：网易、微信等。
内容
通过本文：
你可以了解：多用户下的技术方案细节，以及对应的表设计和流程设计。
你学不到的东西：和其他文章一样，这里我不会有具体的代码实现细节。如果解决方案正确，那么无论代码怎么写都不会太糟糕。
架构演进 早期创业公司
之所以会这样，是因为此时用户量比较少，甚至连上面提到的其他第三方账号系统都还没接入，只有自建系统才能满足需求，如果使用自建系统的话，常用的有：
用户名 密码 注册 登录
很多网站初建都是用这个方法，先注册，再登录，老版本的CMS里都有这个方法。
流程图：
流程描述：
前端将用户名和密码发送给服务器，服务器进行常规判断，判断用户名和密码长度是否符合要求，用户名是否重复等条件。如果不满足条件，则直接返回相应的错误码给前端。这里密码字段建议在上传前加密，防止传输过程中被拦截。我们的传输密码默认都是用md5加密，然后记录到数据库中再加一层加密，即使出库了也没关系，密码不要明文存储。
验证通过后会将用户名和密码写入数据库，并进行积分分配等后续操作，这里就不再展开了。
现在登录，前端把用户名和密码发给服务器，服务器会先检查登录次数是否超过设定的阈值，如果超过，就只能继续等待被关进小黑屋了。
如果不超过继续登录逻辑，判断用户名和密码是否正确，如果密码不正确，则进行阈值判断，如果超过阈值，则关闭小黑屋，记住小黑屋一定要有过期时间，否则永久关闭，这个可以用过期时间来做。
登录成功之后，进行所有后续逻辑操作，比如加点...等操作。
使用手机号注册并登录
流程图：
流程描述：
首先输入手机号然后发送到服务器，服务器会把手机号记录到我们的数据库中，并生成一个随机的验证码，把手机号和验证码绑定为一体，然后记录过期时间，这个过期时间一般在10分钟左右，也就是我们一般手机验证码的有效期。
手机收到短信后，在接口上填写验证码并发送给服务器，服务器收到验证码后会在其中查询手机号对应的验证码，如果失败则返回错误码。
成功后，登录。
这里看似没有明确的注册和登录操作，其实发送手机号也算是常规的注册，后面输入验证码才是登录操作。
问：如果我需要密码怎么办？
答：后续产品可以增加用手机号重新输入密码的功能，这个是现在很常见的做法，但是在移动互联网爆炸的时代，密码已经没那么重要了，反正我永远也记不住密码，如果一个APP可以用手机号操作，我绝对不会用密码去操作。
数据库设计
表结构：
阐明：
这里只是简单说明一下需要用到的数据，不展开具体的场景，这个表结构可以满足上面两种方案的设计。
引入第三方账户解决方案
下面是QQ-SDK的登录逻辑，我们先看一下序列图。
阐明：
客户端调出登录界面，输入用户名和密码，这里是第三方的用户名和密码，登录成功后返回，这个过程会用到.0，不过是通过SDK内置的回调获取的，后面会讲解我们自己对.0的实现。
客户端获取，，（qq，…），向应用服务器请求，应用服务器获取这些数据之后，会去对应的用户中心进行验证，如果验证失败，会返回对应的错误码
验证通过后会判断本地是否存在，若不存在则获取远程用户名，头像等基本信息作为本地基础数据，并返回code值。
如果已经存在，则登录并返回代码值。
客户端拿到code值之后，就去交换这个值，这个是完全符合.0协议的，后面每个请求都要带上，这个值会长期留在服务器上，因为我们要做那种永不下线的操作，所以我们会把每个请求的过期时间累计起来。
数据库设计
根据一些朋友的建议，我将数据库整理在这里：
用户基表（）
用户认证关联表（）
本地用户表()
第三方用户表（）
阐明
该表只是为了登录我们业务端的，主要是我们自己的业务。
就是用自己的用户名和密码登录，并用手机号码记录登录信息。
这是我们的第三方用户系统的数据记录。
它用于将我们的表与关联起来。
整个设计理念就是区分自建用户和第三方存储，这个从架构演进上来说也是合理的，最开始大部分用户系统都是自建的，然后对外访问。
总结
一般来说，第三方用户的接入技术比较简单，这里多设计一个就可以支持足够的第三方接入了，当然我们通常只需要两三个登录，过多的登录不仅会增加维护成本，还会让界面看起来不好看。
希望通过上面的学习，大家能够对我们的多账号登录有更深入的了解，这里的设计没有分表分库，也没有做任何服务化的设计，就是简单直接的设计，当然用户数量和需求不一样，还需要在这个基础上加很多东西，谢谢阅读！
（超过）