游戏中的账号与角色
关系数据库时期的游戏，会有以下字段来定位账号与角色数据：
- 账号
- 账号 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 型数据库下，如何安全的创建角色
本文给出了一种回避方案，如何正面解决该问题，待后续
以上