链接：.im/post/

多账户统一登录

名称 解释

这里的多账户和系统级别的多账户是不一样的，我们说的多账户系统是指在我们的互联网应用中，我们的应用会使用多个第三方的账号来登录，比如现在常用的APP：网易、微信、QQ等。

内容

通过本文：

你可以了解：多用户下的技术方案细节，以及对应的表设计和流程设计。

你学不到的东西：和其他文章一样，这里我不会有具体的代码实现细节。如果解决方案正确，那么无论代码怎么写都不会太糟糕。

架构演进 早期创业公司

之所以会这样，是因为此时用户量比较少，甚至连上面提到的其他第三方账号系统都还没接入，只有自建系统才能满足需求，如果使用自建系统的话，常用的有：

用户名 密码 注册 登录

很多网站初建都是用这个方法，先注册，再登录，老版本的CMS里都有这个方法。

流程图：

流程描述：

前端将用户名和密码发送给服务器，服务器进行常规判断，判断用户名和密码长度是否符合要求，用户名是否重复等条件，如果不满足条件，则直接返回相应的错误码给前端。这里密码字段建议在上传前加密，防止传输过程中被拦截。我们的传输密码默认都是用md5加密，然后记录到数据库中再加密一层，就算出库了也没关系，密码不要明文存储。

验证通过后会将用户名和密码写入数据库，并进行积分分配等后续操作，这里就不再展开了。

现在登录，前端把用户名和密码发给服务器，服务器会先检查登录次数是否超过设定的阈值，如果超过，就只能继续等待被关进小黑屋了。

如果不超过继续登录逻辑，判断用户名和密码是否正确，如果密码不正确，则进行阈值判断，如果超过阈值，则关闭小黑屋，记住小黑屋一定要有过期时间，否则永久关闭，这个可以用过期时间来做。

登录成功之后，进行所有后续逻辑操作，比如加点...等操作。

使用手机号注册并登录

流程图：

流程描述：

首先输入手机号，然后发送到服务器，服务器会把手机号记录到我们的数据库中，并生成一个随机的验证码，把手机号和验证码绑定为一体，然后记录过期时间，这个过期时间一般是10分钟左右，这个就是我们一般手机验证码的有效期。

手机收到短信后，在接口上填写验证码并发送给服务器，服务器收到验证码后会在其中查询手机号对应的验证码，如果失败则返回错误码。

成功后，登录。

这里看似没有明确的注册和登录操作，其实发送手机号也算是常规的注册，后面输入验证码才是登录操作。

问：如果我需要密码怎么办？

答：后续产品可以增加用手机号重新输入密码的功能，这个是现在很常见的做法，但是在移动互联网爆炸的时代，密码已经没那么重要了，反正我永远也记不住密码，如果一个APP可以用手机号操作，我绝对不会用密码去操作。

数据库设计

表结构：

ID、用户名、密码、手机号错误次数

阐明：

这里只是简单描述了需要用到的数据，不展开具体的场景，这个表结构可以满足上面两个方案的设计。

引入第三方账户解决方案

下面是QQ-SDK的登录逻辑，我们先看一下序列图。

阐明：

客户端调出登录界面，输入用户名和密码，这里输入的是第三方的用户名和密码，登录成功后会返回，这个过程会用到.0，不过是通过SDK内置回调获取的，后面会讲解我们自己对.0的实现。

客户端获取，，（qq，…），向应用服务器请求，应用服务器获取这些数据之后，会去对应的用户中心进行验证，如果验证失败，会返回对应的错误码

验证通过后会判断本地用户是否存在，若不存在则获取远程用户名、头像等基本信息作为本地基础数据，并返回code值。

如果已经存在，则登录并返回代码值。

客户端拿到code值之后，就去交换这个值，这个是完全符合.0协议的，后面每个请求都要带上，这个值会长期留在服务器上，因为我们要做那种永不下线的操作，所以我们会把每个请求的过期时间累计起来。

数据库设计

根据一些朋友的建议，我将数据库整理在这里：

用户基表（）

现场笔记

用户身份

用户登录

到期时间

登录失败次数

用户认证关联表（）

现场笔记

ID

自增 ID

用户身份

验证表id

验证类型 (,)

本地用户表()

现场笔记

认证id，自增id

用户唯一标识符

用户密码

用户手机

第三方用户表（）

现场笔记

用户身份

第三方用户唯一标识符

第三方平台logo（qq，...）

由第三方获取、验证并使用

阐明

该表只是为了登录我们业务端的，主要是我们自己的业务。

就是用自己的用户名和密码登录，并用手机号码记录登录信息。

这是我们的第三方用户系统的数据记录。

它用于将我们的表与关联起来。

整个设计理念就是区分自建用户和第三方存储，这个从架构演进上来说也是合理的，最开始大部分用户系统都是自建的，然后对外访问。

总结

一般来说，第三方用户的接入技术比较简单，这里多设计一个就可以支持足够的第三方接入了，当然我们通常只需要两三个登录，过多的登录不仅会增加维护成本，还会让界面看起来不好看。

希望通过上面的学习，大家能够对我们的多账号登录有更深入的了解，这里的设计没有分表分库，也没有做任何服务化的设计，就是简单直接的设计，当然用户数量和需求不一样，还需要在这个基础上加很多东西，谢谢阅读！

- 结尾 -