游戏用户中心开发

用户中心最主要的功能就是管理用户的注册和登陆，登陆成功之后生成对应的token，并负责token的验证。当一个用户注册或登陆成功之后，它的信息会在用户中心服务中缓存一段时间，方便验证和查看。一般用户中心使用web服务开发，支持restful模式。这样用户中心可以在app和浏览器通用。目前流行的技术是springboot。技术组合为：springboot + mybatis + mysql + redis。

用户中心最简单的也需要使用用户名和密码登录，在登陆过程中首先就是查询，就先说说查询的事吧！当收到用户登录的请求后，最简单的操作就是先根据用户名和密码查询数据库，一条sql语句就可以搞定，皆大欢喜，随着用户量的增加，发现越来越慢，直到有一天，系统开始卡的不行，如果你的用户量增长的快，这一天来的也很快，到时候，登陆一个账号需要几分钟，用户体验变差。这时候开始考虑解决这个问题。

数据量大，解决的惟一办法就是分而治之，可能想到的第一件事就是分库分表。就是把原来所有数据都存一个库一个表改为存到多个库的表中。那应该怎么分呢？

如果你的用户id（userId）是long且是递增的，可以方便的以id段分库。比如100000到999999为一个库，记录为1库，1000000到1900000为2库，当收到需要根据用户id查询用户信息时，就可以根据userId判断，在100000到999999范围内就去1库查，在1000000到1900000范围内就去2库查，依次类推，以后不管用户增加多了，只需要增加相应的库就可以了。这样分库的一个好处是，一个用户的所有的信息都在同一个库中。有时候需要对用户信息进行多表查询，这样可以方便的实现。不用跨库查找了。

回到登陆那里，因为登陆的时候不是根据id查询的，而是根据用户名和密码查询的。如果只是单纯的按上面分库，那怎么根据用户名去查询？总不能遍历所有的库吧，虽然这是一个方法，但是相信没有人会这么干。还有一种方法是缓存用户名与id的对应关系，比如当用户注册成功之后，生成userId，这时把用户名和userId及密码的对应关系存储到redis缓存中。查询的时候，选择查redis，看看用户名对应的id是否存在，如果存在再对比密码信息。如果不存在，再从数据库查找，找到后如果密码正确，存储到缓存中。所以问题又回来了，还是需要根据用户名和密码在数据库中查询。

因为我们是根据userid分库的，所以我们应该想办法把用户名和userId建立一定的关系，可以根据用户名制定一定的规则，确定userId所在的库,那么就不能按上面简单的根据id范围来分库了，需要改变一下策略。在生成用户userId的时候，加入一些因子，使用这些因子来分库，而这些由用户名的一些信息生成。首先我们要确定userId的组成，假如我们的userId有以下几部分组成：

43bit(时间戳（存储2018年1月1日零到现在的毫秒数）) +8bit(机器编号) +8bit(毫秒序列) +5bit（分库因子） =64bit

这个算法每秒可以生成不同的userId个数为：1000 * 2^8=256000，可以使用到2296年，最多可以分32个库，基本满足需要了。（如果二百年后不能满足了，再改造吧）

上面说到的分库因子，是由用户名计算出来的，比如用户名wgs123,转成byte，取最后5bit，10011，转化成十进制为19.所在当使用userId% 32时，这个userId被分到第19个数据库。即分库因子最终确定这个userId在哪个库。

即分库因子 =f(username)，取最后5bit用于生成userId

这样不管是使用用户中还是用户id，使用它们的最后5bit就可以计算出在哪个数据库了。

如果游戏服务器是世界服，不分区，那么所有的数据都共享在一起，这样设计之后可以放心的导入用户，而不用担心用户过多了。天生就分好库了。

对于游戏来说，不管是世界服还是分区分服的，都有一个角色，需要一个角色id（roleId），这个roleId的生成一般有一定的业务规则，比如由7位数组成，唯一且递增等。所在用户的业务数据和用户映射的时候是使用playerId关联，比如物品信息，技能信息，它们属于一个角色。

用户中心最基本的有两张表，用户表和角色表，用户表中存储用户的基本公共信息，比如：

user table

role table

如果是分区分服的，这里面role table的数据一般来自逻辑服务的通知，当游戏逻辑服那里创建角色了，或角色升级了，会发布一个通知，用户中心这里监听，然后处理这个通知。这样在用户登陆成功之后，需要显示用户的角色信息就非常 方便了。