代理程序崩溃后重新启动

Question

考虑一个分布式银行应用程序，其中分布式代理机器修改全局变量的值：说“余额”，

因此，代理的请求排队。请求的形式是代表特定代理将值添加到全局变量。因此，代理的代码的形式如下：

  agent
    {
     look_queue(); // take a look at the leftmost request on queue without dequeuing

     lock_global_variable(balance,agent_machine_id);    
     /////////////////////  **POINT A**
     modify(balance,value);
     unlock_global_variable(balance,agent_machine_id);  
     /////////////////// **POINT B**
     dequeue();      //  once transaction is complete, request can be dequeued
    }

现在，如果代理的代码在 B 点崩溃，那么显然不应再次处理请求，否则对于同一请求，变量将被修改两次。为了避免这种情况，我们可以使代码原子化，因此：

agent
{
 look_queue(); // take a look at the leftmost request on queue without dequeuing

 *atomic*
 {   
  lock_global_variable(balance,agent_machine_id); 
  modify(balance,value);
  unlock_global_variable(balance,agent_machine_id);
  dequeue();      //  once transaction is complete, request can be dequeued
 }
}       

我正在寻找这些问题的答案：

1. 如何识别代码中需要“自动”原子执行的点？
2. 如果代码在执行过程中崩溃，“记录事务和变量值”会有多大帮助？还有其他方法可以解决代理崩溃的问题吗？
3. 同样，日志记录无法扩展到具有大量变量的大型应用程序。在这种情况下我们能做什么——而不是从头开始执行？
4. 一般来说，在代理协同工作的情况下如何识别此类原子块。如果一个代理失败，其他代理必须等待它重新启动？软件测试如何帮助我们识别潜在的情况，其中如果代理崩溃，就会观察到不一致的程序状态。
5. 如何让原子块更细粒度，减少性能瓶颈？

Answer 1

Q> 如何识别代码中需要“自动”原子执行的点？
A> 任何时候，当有任何有状态的东西在不同的上下文之间共享时（不一定所有各方都需要是变异者，至少有一个就足够了）。就您而言，不同代理之间共享余额。

Q> 如果代码在执行过程中崩溃，“记录事务和变量值”会有多大帮助？还有其他方法可以解决代理崩溃的问题吗？
A> 它可以提供帮助，但成本很高。您需要回滚 X 条目、重播场景等。更好的方法是使其成为全事务型或具有 有效的自动回滚场景。

Q> 同样，日志记录无法扩展到具有大量变量的大型应用程序。在这种情况下我们能做什么 - 而不是从头开始执行？
A> 在某些情况下，您可以放宽一致性。例如， CopyOnWriteArrayList 执行以下操作：并发 write-behind 并在数据可用后为新读取器打开数据。如果写入失败，它可以安全地丢弃该数据。还有比较和交换。另请参阅上一个问题的链接。

Q> 一般来说，在代理协同工作的情况下如何识别此类原子块。
A> 查看您的第一个问题。

Q> 如果一个代理失败，其他代理必须等待它重新启动？
A> 大多数策略/API 定义关键部分执行的最大超时，否则系统可能会陷入永久死锁。

Q> 软件测试如何帮助我们识别潜在的情况，其中如果代理崩溃，就会观察到不一致的程序状态。
A> 在某种程度上可以。然而，测试并发代码需要的技能与编写代码本身一样多，甚至更多。

Q> 如何让原子块更细粒度，减少性能瓶颈？
A> 你自己已经回答了这个问题 :) 如果一个原子操作需要修改 10 个不同的共享状态变量，那么除了尝试将外部合约下推以使其需要修改之外，你无能为力更多的。这几乎就是数据库不像 NoSQL 存储那样可扩展的原因——它们可能需要修改依赖的外键、执行触发器等。或者尝试提高不变性。

如果您是 Java 程序员，我绝对建议您阅读这个书。我确信其他语言也有很好的对应物。