mysql服务端放置_放置类游戏后端服务器架构设计与实现

前言：

停更了一段时间。2020年也接近尾声了，调整了一下人生状态，继续前进。

今年完全参与了一款放置类游戏从0到开发上线再到合服。从目前市场上买量游戏的发展线路来看，合服意味着游戏走向压榨玩家的最后一步了。游戏项目也趋于稳定和成熟，最终能不能继续运营下去还是未知数，但是还是想从技术上/业务上做一次总结。

放置类游戏归于休闲游戏类，玩家不需要有太多的操作，只需要点点点即可。因此对于后台服务器来说也不需要太累，虽然不需要后台有太过于酷炫的技术，但是必须要保证不把玩家的数据丢失。不同于竞技类游戏或其他游戏，我觉得对于放置类游戏来说数据是最重要的。竞技类游戏或者MMORPG游戏玩家从操作中、从剧情中得到快感。延迟，同步，数据同样重要。但是对于放置类游戏，玩家通过点点点堆积道具，攒积积分，提升排名本身就是这类玩家的爽点所在，如果这些数据丢失了无异于将玩家的时间付出付之一炬。

对于上述原因，数据传输协议必然就选自传统的TCP可靠传输协议，数据持久化方面也就是传统mysql。当然后台服务器并不是为了完全可靠不顾及速度而直接操作mysql，中间还是会有一层内存的中间层作为过渡。

这篇文章会从技术上和业务上做一个总结，也算是对我项目终的总结吧。

一、MySQL数据库和表结构设计

通用数据库的设计

玩家注册一个账号，后台会为该玩家生成一个独一无二的账户标识UID。

玩家在某个服创建一个角色，后台会为该角色生成一个独一无二的角色标识RID。

因此需要一个数据库(命名为Common数据库)，里面存放一些通用的全局变量。例如上述两个UID、RID是以递增的方式为每个账户、每个角色分配。因此需要有个表(命名为ID_CTRL)，里面记录了两条数据，分别是UID和RID的当前值。

Common数据库的所有表及作用：

1.ID控制表(命名为XXX_ID_CTRL)：初始值可以指定一个比较大的数，记录当前分配到的UID、RID的值。

2.黑名单表(命名为XXX_Black)：该表可以以账户标识UID字段为主键，另一个字段可以为封禁时间。

3.兑换码表(命名为XXX_Exchange_Code)：该表可以以兑换码字符串为主键，其它字段一般需要包含：兑换码的使用者、兑换码的失效时间、兑换码的类型、兑换码的对应的物品掉落ID、兑换码可用渠道等等。

4.账户-角色信息表(命名为XXX_Uid_Info)：一个账户UID下可以在不同服注册角色，因此一个UID就可能对应多个RID。这个表主要用来记录UID对应哪些RID，以及这个RID的基本信息。其中的字段是以UID、SrvId字段为主键，剩余字段包含：RID、创角色时间戳等等。

5.用户名信息表(命名为XXX_Role_Mapping)：该表记录了每个角色的名字和对应的服务器ID。该表的作用可用于玩家起名，一个服不应该有相同的名字就是从这个表里面做的判断。但是不同服可以有相同的名字，因此该表的主键是以角色名字的字符串和服务器ID作为联合主键。剩下的表字段为RID。

6.openID-账户信息表(命名为XXX_User_Mapping)：OpenID是可以管理员用户自己指定的账户标识，每个普通玩家也会随机生成但是普通玩家并没有机会使用。这个表记录了账户的创建信息。以OpenId和Uid为主键，剩余字段记录账户生成的时间戳。

分库分表的设计

除了通用数据库外，其他数据库就是内容数据库用来存放角色信息的。既然上述的设计角色的RID是以递增的形式，那么为了缓解单个内容数据库的压力自然想到的内容数据库的分库方式就是以RID的尾数作为分库的依据。

这样内容数据库就分了10个：XXX_0、XXX_1、XXX_2、XXX_3、XXX_4、XXX_5、XXX_6、XXX_7、XXX_8、XXX_9。依据玩家RID的尾数将它塞入对应的数据库中。这种分库的方式自然是最均衡的。

内容数据库表的设计及作用：

1.角色信息表(命名为：XXX_Basics)：该表的作用主要是记录角色的基本信息，例如：角色名字、等级、性别、职业、充值数量、帮会等等。以角色的独一无二的标识RID作为主键。

2.角色内容表(命名为：XXX_Info)：该表的作用是记录角色在游戏内产生的数据。这个表的内容会是最多的，例如：运营充值活动产生的数据、游戏副本产生的数据、养成的属性数据、甚至道具数量等等。该表的字段以Rid、Type(区分类型)、Id为联合主键。剩余字段可自行设置。我们项目内设置是除主键外还有10个int字段。

3.角色扩展内容表(命名为：XXX_Extend_Info)：有时候上述的角色内容表的10个int字段不够用，这个表的目的就是为扩展用的。主键依然是Rid、Type、Id为联合主键，剩下的一个字段是data字段为252字节的binary。存什么应该都够了。

4.角色装备/道具表等等的特殊表(命名为：XXX_Equip)：该表存有特殊实现的道具或者装备。

5.好友关系表(命名为：XXX_Friend)：放置类游戏必不可少的社交属性系统。该表存好友之间的映射关系。

6.邮件表(命名为：XXX_Mail)：关于邮件和好友系统的实现可以看另一篇博文：游戏好友系统与邮件系统实现

7.帮会表(命名为：XXX_Union)：该表记录每个服的帮会信息，以帮会ID作为主键，其他字段有帮会等级、帮会贡献、帮主RId、帮会人数、帮会创建时间等等信息。

8.帮会成员表(命名为：XXX_Union_Member)：该表记录每个帮会下面每个成员的信息。以帮会ID和角色Rid为联合主键。其他字段有帮会职位、角色基本信息、帮会贡献等等。

潜在的问题

以上生成全局唯一的Uid或者Rid的方法很明显需要加锁或者单进程处理，否则就会出现重复的状况。例如：系统会在业务逻辑进程里面为玩家创建角色，此时分配Rid的时候就需要向数据库取当前的Rid值，然后将该值赋值给角色，最后将该值+1写回数据库。业务逻辑进程不止一个的情况下，在第一个业务逻辑进程还未将值写回数据库时，另一个逻辑业务进程又从数据库取Rid的值