异常故障恢复

[piggy-xrh]

共享内存的写操纵会存在其他问题,不仅仅是锁,比如下面场景比较棘手，会带来数据一致性不可恢复， 不知道作者是否有考虑过下面的场景:

1: shm.lock();
2: ++ shm.value;
3: 其它逻辑
4: shm.unlock();

shm.lock 这个内部出故障或许还能恢复，但是一致性问题不仅仅在于锁问题,而在于锁中间的逻辑问题.
如果进程在执行代码1成功后，执行了代码2，但这个时候挂了（有可能是被人误杀，比如kill，或者被系统
的oom机制强制杀掉，这种非人为的最可怕), 在没执行完代码4之前挂掉，这个时候代码2所做的更改就无法恢复了！

这种进程可能在任意逻辑未知挂掉，这个时候在共享内存里加锁后，操纵了共享内存，但事情没做完，
这基本上不可恢复. 因为锁共享内存而操纵(写)共享内存的代码逻辑会很多, 这种情况基本上所有使用共享
内存的程序可能都崩溃或使用错误的数据 . 这对上线的程序是灾难性的影响.

[happyfish100]

你这个问题非常专业啊！看来你也面临了这个难题。这个问题的解决方案我想了半天，最后用简单粗暴的方法解决。我的做法是：一旦出现这种情况，直接把整个cache清除掉。因为是cache系统，不保证（承诺）数据持久化，所以万一出现这种bad case，只能把cache清空了。

[piggy-xrh]

嗯，这个设计某些方案时我也考虑过，但最后没有这么做, 不过我们内部也有一些系统新构建在共享内存上，有点担忧后续他们的故障处理.
库构建在共享内存后，会被很多系统给集成，集成的程序越多，故障率越高， 这是因为程序集成后，开发者良莠不齐，程序的故障率会被放大很多，程序core_dump，程序升级不平滑强制kill, 程序oom, ... 这回导致cache失效被清空，如果这个cache数据量大，或做了数据库的cache，恢复时间会很长，后端的db系统随时可能被洞穿. 所以这个生产环境的风险还是很高的，因为故障率会随着程序的集成变高而放大.

[owenliang]

说实话，共享内存这种问题无解，尤其是在共享内存里维护数据结构，一旦某个链断了，难以恢复。

[mosquitoding]

这个问题是共享通信首先要考虑的问题，只有这个问题考虑清楚了，你的共享内存功能才可用