游戏中的账号与角色
关系数据库时期的游戏,会有以下字段来定位账号与角色数据:
- 账号
- 账号 ID
- 角色 ID
以至于到现在,程序做游戏时会全部或部分照搬
典型的,至少会有账号与角色ID,并需要维护它们的对应关系
关系数据库特点
关系数据库也可以使用字符串做主键
但是出于性能考虑,程序不约而同的会把整型作为主键
因为关系数据库通常做 where 、 join 等操作,整型键明显性能优于字符串型键
此外关系数据库通常都支持事务,比较方便做原子操作
KEY-VALUE 型数据库特点
目前游戏中,更常见的是使用 KEY-VALUE 型数据库
这类数据库底层实现,通常 KEY 就是字符串
此外一般不支持事务
账号与角色ID对应表带来的问题
问题 | 关系数据库 | KEY-VALUE 型数据库 |
---|---|---|
创建角色时的原子操作 | 支持事务,不易有 BUG | 创建消息连发,极易可能会多创建角色 见过线上运营 5、6 年的海量账号承载的游戏也有这个问题 |
有些逻辑,需要做账号角色ID对应处理 | 额外多余编码 | 额外多余编码 |
账号即角色ID
使用 KEY-VALUE 型数据库的游戏,可以做下优化,让账号即为角色ID
也就是角色ID 也是字符串
如果一个账号有多个角色怎么办,那角色ID为账号-1
、账号-2
、账号-3
…
即通过账号可直接得角色ID,而不是角色ID 需要全局ID生成器去生成,并人为去维护它们的对应关系
这样做主要的好处为:
- 创建角色会变得很简单,且不易出 BUG
- 不需要某些额外的账号与角色ID对应处理
当然也会有些缺点:消息流量会多一丢丢
即涉及广播型消息、 Gateway 转发消息都要带上字符串型的角色ID,流量变大些
通过流量的适当增加来换编码的方便,你会做何种选择呢?
其他问题
本文引出了一个问题,即 KEY-VALUE 型数据库下,如何安全的创建角色
本文给出了一种回避方案,如何正面解决该问题,待后续
以上