最佳实践

最近更新时间:2019-08-08 14:30:06

表定义的最佳实践

TDR 表定义

  1. primarykey 采用的 key 字段,需要较高的离散度,便于 gameserver 发送请求时分发到多个接入层节点。
  2. splittablekey 采用的 key 字段,需要较高的离散度,取值的范围不能集中在非常有限的集合里。
  3. 表定义时,索引键需和主键不能相同,如果二者相同则浪费网络、磁盘资源。
  4. value 字段定义数组时需要增加 refer 属性(count 是定义大小,refer 是实际使用大小),便于 count 大小以后扩展,并且减少数据在网络上传输和磁盘上占用。
  5. value 字段推荐多采用一级字段,减少字段间嵌套,字段嵌套类型控制在3层以内。
  6. 不推荐 key 字段采用 binary 类型,不利于跟进问题。
  7. 单个表定义的索引最多8个,推荐2 - 3个,按照需要设置索引。

Protocol Buffers 表定义

  1. primarykey 采用的 key 字段,需要较高的离散度,便于 gameserver 发送请求时分发到多个接入层节点。
  2. splittablekey 采用的 key 字段,需要较高的离散度,取值的范围不能集中在非常有限的集合里。
  3. 支持定义嵌套的结构体类型非主键字段,嵌套深度最深支持30层,嵌套深度太深将会影响数据访问性能。

gameserver 的最佳实践

  1. 在部分字段读写的场景下推荐部分字段读取和更新,减少网络传输大小和磁盘读写次数,避免获取无效数据。
  2. 对于写操作时响应包需要返回数据记录的,建议项目组根据实际情况设置 result_flag,例如 update 后需要获取到修改后的数据记录,建议 result_flag 设置为2;如果不需要写操作返回数据记录,则 result_flag 设置为0。
  3. 对于批处理的命令字,例如 batchget、listgetall、getbypartkey 等,建议按照 offset 和 limit 获取数据记录,limit 推荐是 200,gameserver 端开启分包返回。
  4. list 相关的表,listaddafter 时需要注意队列满时配置淘汰规则,推荐采用队头插入、队尾删除或者队头删除、队尾插入的方式。
  5. list 相关的表,例如 listreplace、listdelete、listbatchdelete 时,需要传递正确的 index。
  6. gameserver 在读数据前,需要确保获取的数据记录 value 字段是有值的,例如 value 字段 A、B、C,本次 gameserver 获取的数据记录是A、B,则C字段是没有值的,请谨慎使用。
  7. 推荐 gameserver 本地做超时控制,不推荐采用按照 gameserver 的回包做超时判断,需要 gameserver 本地主动的做超时判断。
  8. gameserver 在遍历时,推荐从存储层从节点上获取数据,避免影响主节点的性能。
  9. 不推荐对大字段进行 memset 操作,耗费更多的 CPU,推荐对大数据结构的部分字段设置为0的方式进行初始化。
  10. gameserver 端在处理发往 Tcaplus 的请求和来自 Tcaplus 的响应时,建议采用分治的方法,处理部分发往 Tcaplus 的请求,再处理来自 Tcaplus 的响应包。

系统设计的最佳实践

  1. 高频字段、需要一次性原子性操作的字段推荐独立成表。
  2. gameserver 在做数据回写时,建议进行流控、按照时间离散化处理。
  3. 可以支持动态修改表结构,提供表的数据转换插件。
  4. 回档支持全区全服、表级别、记录级别的冷备时间点回档、精确时间点回档。
  5. 推荐采用分区分服模型,全区全服和分区分服都可以动态扩展接入层、存储层节点。
  6. 具有业务关联的多个内容需要合并在单个表里,避免出现分布式事务问题。
  7. 推荐开启压缩功能,包括请求包和响应包压缩、记录压缩功能。