这是一个创建于 638 天前的主题，其中的信息可能已经有所发展或是发生改变。
每一次逻辑：逻辑服务器处理的单个玩家或内部请求。
主要有以下两个观点：
1 ，panic 直接服务直接挂掉，优点是不会产生扩散性错误，可以回档十几秒内的数据，代价是服务可能会停止一段时间
2 ，panic recover 住，然后确定问题改好之后再起服，修复相关错误数据，优点是停服时间更短，可以先修复了再部署，缺点是可能会产生扩散性错误，后面修复数据比较难。
我个人是倾向于要 recover 的，因为经过 qa 、压测之后，上线的情况 panic 的情况首先已经比较少了，我觉得保证服务器的健壮性是更好的，我们是游戏服务器，单个玩家的小概率错误不应该影响所有玩家的体验，后续进行数据修复和补偿就 ok 了。我们组内也讨论了很久这个问题。是采用的 recover 的方案，但是最近来了个资深又提起了这个问题，他属于是持有第一种观点的。不知道大家怎么看这个问题。
主要有以下两个观点：
1 ，panic 直接服务直接挂掉，优点是不会产生扩散性错误，可以回档十几秒内的数据，代价是服务可能会停止一段时间
2 ，panic recover 住，然后确定问题改好之后再起服，修复相关错误数据，优点是停服时间更短，可以先修复了再部署，缺点是可能会产生扩散性错误，后面修复数据比较难。
我个人是倾向于要 recover 的，因为经过 qa 、压测之后，上线的情况 panic 的情况首先已经比较少了，我觉得保证服务器的健壮性是更好的，我们是游戏服务器，单个玩家的小概率错误不应该影响所有玩家的体验，后续进行数据修复和补偿就 ok 了。我们组内也讨论了很久这个问题。是采用的 recover 的方案，但是最近来了个资深又提起了这个问题，他属于是持有第一种观点的。不知道大家怎么看这个问题。
 |
1
777777 2023-03-07 15:48:58 +08:00
支持第一种，直接挂掉，通常有多个服务器，一个服务器 panic 了其他服务器不受影响。panic 是非常严重的程序必须停止，不能影响后续的数据。第二种方案修复数据耗时耗力，从玩家角度来说，你改我数据比暂时服务器挂了更不能忍受！
|
 |
2
rrfeng 2023-03-07 16:20:47 +08:00
2 recover 里不能自动修复，那就没意义。
『 recover 住，然后确定问题改好之后再起服』不起那不还是等于 panic 了吗？ |
 |
3
tool2d 2023-03-07 16:28:41 +08:00
"单个玩家的小概率错误不应该影响所有玩家的体验"
应该学云风，把每一个用户都用 lua 协程隔离，做到单个用户崩溃不影响全体服务器。 本来已经是玩家逻辑代码了，需要一定容错性，直接停机就挺离谱的。 |
 |
4
clikes OP @rrfeng 因为可能是某一个特殊的操作和特殊的数据产生的这个 panic ，其实不影响其他部分的功能运行，或者本功能如果不是特殊数据的话也不会 panic ，这个时候服务器还是可以继续跑的这样
|
 |
5
ryalu 2023-03-07 16:30:54 +08:00
支持第二种，经过 qa 、压测上线后再 panic 的应该属于比较极端的程序 bug 了，出现这种问题的用户应该不多，事后这些用户再查日志做一些事后补偿就好了，优先保证绝大部分用户的游戏体验优先。另外可以咨询下 op 你们游戏服务器用的什么协议以及框架？最近刚好在调研这个 😊
|
1 |
7
ccagml 2023-03-07 16:48:55 +08:00 via Android
问题相当于，某些玩家数据出问题的时候，应该让进程挂掉吗？
我们应该是第二种，不能挂掉，数据错误靠日志修复，发补偿邮件 |
|
8
clikes OP 其实我当时推第二种方案还有一个原因就是开发阶段是不是会有一些 panic ，然后其他同事用公共服的时候经常会停。虽然都是一些小问题，但是不想服务器给大家建立一个经常会挂的印象，我觉得这点蛮重要的。另外，对我来说其实更多的是体验上的考量，因为我对线上产生的 panic 其实是有一个比较乐观的预期（小错误好修改，不容易产生扩散性），我愿意接受一些小的逻辑不完全和数据错误，来保证大多数情况下的流畅体验。虽然可能会因此带来一些耗时耗力修数据的情况这样。其实如果是说我对问题是一个悲观预期比如（影响玩家的大部分数据，同时还会随时间指数型增长，或者涉及到的功能比较底层影响大部分玩家），的话其实我还是支持第一种的。
|
 |
9
quzard 2023-03-07 21:41:50 +08:00 via iPhone
一般是第二种吧。写一个兜底策略。服务直接挂了影响不好吧。
|
Select Language