61 lines
3.6 KiB
Markdown
61 lines
3.6 KiB
Markdown
# game 游戏服
|
||
1. 测试gate
|
||
1. 每10分钟新起1000个连接，发送登陆，然后关闭。检查是否有内存及协程泄漏。(已修复)
|
||
2. 启动1000个链接，每小时固定发送登陆消息，一天后查看连接是否还在。检查心跳机制。(已修复)
|
||
3. 修改完后清除调试日志。(已完成)
|
||
4. 客户端stop关闭连接，触发服务端连接崩溃。(已修复)
|
||
5. 偶现网络关闭，服务端此时传来数据，网关会因为conn为nil触发协程崩溃，不影响程序运行。(暂不处理)
|
||
6. 客户端反复关闭重连会触发gate退出，无崩溃日志。
|
||
|
||
2. 编写db服
|
||
1. login服向db服请求数据及向log db服写入日志。测试rpc机制。(已验证)
|
||
2. db创建表时，主键不会自增，而是随机增加。(已修复)
|
||
3. 首次创建帐号，redis没有写入帐号数据。 (已修复)
|
||
4. 第二次登陆，login还会走创建帐号逻辑，导致db服返回重复建号失败。 (已修复)
|
||
5. redis写入数据的字段名有误。(已修复)
|
||
6. struct序列化到redis中时需要处理时间格式。(已修复)
|
||
7. 清理登陆相关调试日志。(已完成)
|
||
8. login服切换到其它地方启动后，gate服会路由失败。(已修复，etcd没有删除失效节点导致。)
|
||
9. login在创建帐号时，还需要创建user。(已验证)
|
||
10. 优化各服务的call,send，将服务节点查询放到call,send方法内部，调用者提供serviceTypeId即可。服务注册时需表明自己是有状态还是无状态或类似于db的有序服务。
|
||
11. 优化各服务的send方法，除gate,login服，其它服不需要传connId。
|
||
|
||
3. 编写color game玩法
|
||
1. 房间配置。(已完成)
|
||
2. 创建房间、加载玩家数据。(已实现，rpc只能拿到user数据，resource数据似乎缺失)
|
||
3. 玩家进出房间及房间信息同步。(已完成)
|
||
4. 玩家向db服请求修改金币等rpc请求。common.rpc层实现，提供接口。(已实现，待测试)
|
||
4. 停服时能及时关闭服务。(已验证)
|
||
6. 定制消息。(已完成)
|
||
7. 具体业务实现。
|
||
1. 开始游戏、通知下注、通知下注结束、开骰子、结算。(已实现，待测试)
|
||
2. 玩家下注、每秒更新投注区域信息。(已实现，待测试)
|
||
8. 机器人实现。(未开始)
|
||
9. 经常从etcd掉出，不会重试etcd。
|
||
|
||
4. 编写大厅lobby服
|
||
1. 玩家上线时通知玩家他所在的玩法。方便玩家重连进入该玩法服。(已实现，待测试)
|
||
|
||
5. 编写match服
|
||
1. 初步实现框架，并转发匹配消息。(已实现，待测试)
|
||
2. color无需匹配，匹配服直接转发给color game。(已完成)
|
||
|
||
6. 编写管理后台
|
||
1. 玩法配置
|
||
2. 金流查询
|
||
3. 牌局日志
|
||
|
||
7. log服
|
||
1. 使用clickhouse做存储。(已实现，待测试)
|
||
|
||
8. 客户端编写 u3d
|
||
1. 网络连接
|
||
2. ui，动画等
|
||
3. 玩法逻辑
|
||
|
||
9. 优化计划
|
||
1. etcd重试机制。(已优化)
|
||
2. 节点注册时加上自己是有状态还是无状态还是有序。每个服务注册时加上自己能接收的消息范围。(节点是否有状态参考service.proto来处理，无需注册到etcd。服务消息范围也没必要加上，类似于EnterRoom消息所有玩法都需要处理。还是交给客户端发消息时自行决定发到哪类节点)
|
||
3. gate根据消息id决定路由给哪类节点，根据节点是否状态服选择节点。（同上）
|
||
4. 通过广播机制，将玩家在哪个状态服里同步给所有服，保存到内存里。(后续优化，暂不考虑)
|
||
5. 优化rpc及send通过serviceTypeId来处理向哪一个节点发送消息。(已优化，避免每次都要查找node) |