-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
异常故障恢复 #5
Comments
你这个问题非常专业啊!看来你也面临了这个难题。这个问题的解决方案我想了半天,最后用简单粗暴的方法解决。我的做法是:一旦出现这种情况,直接把整个cache清除掉。因为是cache系统,不保证(承诺)数据持久化,所以万一出现这种bad case,只能把cache清空了。 |
嗯,这个设计某些方案时我也考虑过,但最后没有这么做, 不过我们内部也有一些系统新构建在共享内存上,有点担忧后续他们的故障处理. |
说实话,共享内存这种问题无解,尤其是在共享内存里维护数据结构,一旦某个链断了,难以恢复。 |
这个问题是共享通信首先要考虑的问题,只有这个问题考虑清楚了,你的共享内存功能才可用 |
共享内存的写操纵会存在其他问题,不仅仅是锁,比如下面场景比较棘手,会带来数据一致性不可恢复, 不知道作者是否有考虑过下面的场景:
1: shm.lock();
2: ++ shm.value;
3: 其它逻辑
4: shm.unlock();
shm.lock 这个内部出故障或许还能恢复,但是一致性问题不仅仅在于锁问题,而在于锁中间的逻辑问题.
如果进程在执行代码1成功后,执行了代码2,但这个时候挂了(有可能是被人误杀,比如kill,或者被系统
的oom机制强制杀掉,这种非人为的最可怕), 在没执行完代码4之前挂掉,这个时候代码2所做的更改就无法恢复了!
这种进程可能在任意逻辑未知挂掉,这个时候在共享内存里加锁后,操纵了共享内存,但事情没做完,
这基本上不可恢复. 因为锁共享内存而操纵(写)共享内存的代码逻辑会很多, 这种情况基本上所有使用共享
内存的程序可能都崩溃或使用错误的数据 . 这对上线的程序是灾难性的影响.
The text was updated successfully, but these errors were encountered: