Question

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

因此，代理的请求排队。请求具有这样的形式，其中代表特定代理将值添加到全局变量。因此，代理的代码格式为：

  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
    }

现在，如果代理商的代码在POINT 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
 }
}

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

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

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。我确信其他语言也有很好的对应物。

崩溃后重启代理程序

1 个答案: