Читать книгу From Traditional Fault Tolerance to Blockchain - Wenbing Zhao - Страница 56

Consider the example shown in Figure 2.11. Process P₁ crashes after sending message m₈. Process P₂ crashes after sending message m₉. Upon recovery, P₁ restores its state using the checkpoint C_1,0. Because it will be in the state interval initiated with the receiving of message m₀, messages m₂, m₄, and m₅ will be deterministically regenerated. This should not be a problem because the receiving processes should have mechanism to detect duplicates. Subsequently, the logged message m₆ is replayed, which triggers a new state interval in which m₈ would be deterministically regenerated (and discarded by P₀. Similar, upon recovery, P₂ restores its state using the checkpoint C_2,0. The restored state is in the state interval initiated by the receiving of m₁, and message m₃ will be deterministically regenerated and sent to P₃. Again, P₃ would detect that it is a duplicate and discard it. Furthermore, the logged messages m₄ and m₇ is replayed, causing the sending of messages m₆ and m₉, which will be ignored by P₁ and P₃.

Figure 2.11 An example for pessimistic logging.

Pessimistic logging can cope with concurrent failing and recovery of two or more processes, as illustrated in the example shown in Figure 2.11. Messages received while a process is recovering (i.e., while it is restoring its state using the latest checkpoint and by replaying all the logged messages), can be buffered and examined when the process completes its recovery. It is possible that while a process is engaging in a recovery, another process fails and recovers itself concurrently, as the above example shows. In this case, P₁ would receive a duplicate message (m₆) regenerated by another recovering process P₂ and temporarily buffers it. P₁ then would discard it as soon as it is done recovery. Similarly, P₂ would receive the duplicate message m₄ regenerated by P₁, which will be discarded after the recovery is completed.