背景:前端
最近在作B端系统的帐户系统，数据量大概在2亿左右，表设计以下，其中分了8张表，其中分了帐户信息主表，帐户绑定手机表，帐户绑定邮箱表，帐户绑定c端帐号表，帐号绑定用户名表，以及帐户的扩展信息表，其中以上都是分了8片，其中分片字段以下:mysql
| 表 | 分片字段 |
| 帐户信息主表 | uid |
| 帐户绑定手机表 | 手机号 |
| 帐户绑定邮箱表 | 邮箱 |
| 帐号绑定c端帐号表 | c端帐号uid |
| 帐号绑定用户名表 | 用户名 |
| 帐户我的扩展信息表 | uid |
设计:redis
1.其中手机号时国家码和手机号是分开的算法
帐户信息主表包括帐户的企业系统等标识，帐户名，密码，帐户状态，密码标识(用于首次注册是否须要强制改密码的标识)，用户绑定信息的jsonsql
帐户绑定手机号表，帐户绑定邮箱表，帐户绑定用户名表 ，这三张表是为了登陆，可经过手机，邮箱，用户名登陆，获取uidjson
帐户我的扩展信息表，包含用户的手机号，邮箱，性别，昵称，头像，微信号，身份证号，身份证有效期等信息安全
手机分红三种，绑定手机，安全手机，扩展手机。(安全手机用于注册，重置密码，一个用户可对应多个安全手机，相似于iphone的官网)微信
2.其中uid的生成:cookie
使用mysql的主键生成策略加上前缀来标识，单独的建张表用于uid生成，由于数据量很大，就不必都新增，都是先删除后新增，添加事务session
3.服务分红三块，注册一个服务，登陆一个服务，用户session是一个服务，帐户管理功能在注册服务中。包含如下业务场景
注册及帐户管理相关接口:
预注册: 发送注册连接到手机或者邮箱(生成短连接，连接有过时时间，存在redis中)
注册:手机、邮箱，帐户名注册方式
改绑手机:绑定手机，改绑手机，解绑手机
改绑邮箱:绑定邮箱，改绑邮箱，解绑邮箱
改绑安全手机:新增、删除(帐户安全手机表是uid来分区的，并且是多对多的关系，因此不存在改绑逻辑)
改绑C端帐号:绑定，改绑和解绑(前端控制是否须要绑定C端帐号，灵活配置)
修改密码:登陆状态下修改(从登录的cookie中获取用户id进行修改)
重置密码:首次注册可配置成是否须要重置密码
发送手机验证码：向手机发送验证码
验证手机验证码: 根据返回的手机验证码获取到token(该token可换取手机号)
注销帐户:删除帐户绑定信息，扩展信息，而且存入到注销备份表中，便于之后查看数据
修改我的扩展信息:包含用户头像昵称等等我的信息
带安全手机的注册:安全手机的方式注册
根据uid获取帐户信息:帐户信息
手机号查询用户信息:
邮箱查询用户信息:
uid查询用户扩展信息:
登陆相关接口:
帐户登陆:手机验证码登陆，邮箱验证码登陆，密码登陆,返回token
登陆:根据返回的token进行登陆
校验帐户密码:密码校验
帐户session相关:
建立session:session和uid直接关系
获取session:获取session
获取session列表:
登出session：登出的清除session
4.在对接不一样系统的时候，作到不一样系统之间的数据隔离，所以在每一个分表中添加对应的系统id标识，作到好比帐户名是区分系统的，手机号也是区分系统的，邮箱也是区分系统的，这样保证了不一样系统对接进来的时候，就不会出现帐户名重复的状况，也符合实际状况(不一样系统存在帐户名重复的帐户状况)。
5.帐户名大小写问题:默认mysql是不区分大小写的，用的是mysql 5.6版本的
6.涉及到迁移其余帐户到该帐户系统时，如遇到密码算法不一样的，可添加新的密码存储表，将密码算法转换成本身的密码算法,作法是登陆到本系统时，校验老密码算法，若是知足，则去用新的加密算法加密密码存储到新的帐户系统密码中便可
7.帐户系统导入时，可能会遇到各类问题，好比数据不一样步(密码不一样步，更新了密码没有及时两边帐户系统都更新)，清理帐户数据的job也颇有必要，根据时间段和具体的系统id来清理帐户数据。