重新启动代理程序崩溃

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>任何时候，当在不同的上下文中有状态共享时（不一定所有方都需要成为增变器，至少有一个）。在你的情况下，有不同代理之间共享的balance。

Q>如果代码在执行过程中崩溃，“记录事务和变量值”有多大帮助？是否有其他方法来解决崩溃代理的问题？
A>它可以帮助，但它有附加成本高。您需要回滚X条目，重播场景等。更好的方法是使其成为全交易或具有effective automatic rollback scenario。

Q>此外，日志不能扩展到大量变量的大型应用程序。在这种情况下我们能做些什么 - 而不是从头开始重新执行？
A>在某些情况下，您可以放松一致性。例如，CopyOnWriteArrayList会执行并发写入操作，并在新读取器变为可用时开启数据。如果写入失败，它可以安全地丢弃该数据。还有compare and swap。另请参阅上一个问题的链接。

Q>一般来说，如果代理一起工作，如何识别这样的原子块。
A>看到你的第一个问题。

Q>如果一个代理失败，其他人必须等待它重新启动？
A>大多数策略/ API为临界区段执行定义maximum timeouts，否则冒着导致系统最终陷入永久死锁的危险。

Q>软件测试如何帮助我们识别潜在病例，其中如果代理崩溃，则会观察到不一致的程序状态。
A>它可以达到相当程度。然而，测试并发代码需要尽可能多的技巧来编写代码本身，如果不是更多。

Q>如何使原子块更加细化，减少性能瓶颈？
A>你已经自己回答了这个问题:)如果一个原子操作需要修改10个不同的共享状态变量，除了尝试推送外部契约，因此需要修改更多内容外，没有什么可以做的了。这就是为什么数据库不像NoSQL存储那样可扩展的原因 - 他们可能需要修改依赖的外键，执行触发器等。或者尝试提升不变性。

如果你是Java程序员，我肯定会推荐阅读this book。我敢肯定，其他语言也有很好的对应物。