重新啓動代理程序崩潰

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。我敢肯定，其他語言也有很好的對應物。