通過重新啓動計算機，路由器，程序和瀏覽器，您可以多久解決問題？或甚至通過重新安裝操作系統或軟件組件？快速重新啓動技術，而不是保持良好狀態（可用性和一致性）
當懷疑軟件組件沒有以正確的方式保持其狀態時，這似乎是一種常見模式，那麼通過重新啓動組件就可以獲得初始狀態。
我聽說亞馬遜/谷歌有許多節點集羣。每個節點的一個重要屬性是它可以在幾秒鐘內重啓。所以，如果其中一個失敗了，那麼將它返回到初始狀態只是重新啓動它的問題。
是否有任何語言/框架/設計模式在那裏利用這種技術作爲一流的公民？
編輯描述亞馬遜背後的一些原則以及可用性總體原則和一致性的鏈接： http://www.infoq.com/presentations/availability-consistency
這在嵌入式系統世界和電信行業中很常見。它在基於服務器的世界中不太常見。
有你可能感興趣的一個研究小組，他們一直都在Recovery-Oriented Computing或「ROC」。 ROC的關鍵原則是任何程序都可以在啓動後立即執行最清潔，最好，最可靠的狀態。因此，在檢測到故障時，他們寧願重新啓動軟件，而不嘗試從故障中恢復。
聽起來很簡單吧？那麼，大部分的研究已經落實到了這個想法中。原因正是你和其他評論者指出的：操作系統重啓太慢，無法成爲可行的恢復方法。
ROC依賴於三個主要部分組成：
ROC和典型的「夜間重啓」方法之間真正的關鍵區別在於ROC是重啓是反應的策略。我的意思是，大多數軟件與一定程度的錯誤處理和恢復（投擲和捕捉，記錄，重試循環等）ROC程序會檢測出故障（異常）和立即退出寫入。混合使用這兩種模式只會讓你陷入兩個世界中最糟糕的境地 - 低可靠性和錯誤。
嵌入式系統可能有一個檢查站的功能，使每n毫秒，當前堆棧被保存。 內存在重新啓動時（例如電池備份）是非易失性的，所以在開機時，會測試代碼是否需要跳到舊的檢查點，或者是否是新系統。
我會猜測亞馬遜/谷歌使用了類似的技術（但更復雜）。
嵌入式系統通常有相當長的時間來重啓它們嗎？ （我想在這裏或我的iPhone和黑莓） – ennuikiller 2009-09-16 20:15:13
取決於他們如何編程。我寫了一個系統，一直保持暢通 - 只要電池是好的，系統沒有注意到故障。儘管如此，這與iPhone/Blackberry等應用程序/流程驅動系統通常是非常不同的方法。我懷疑ip/bb不會執行檢查點功能......這是完全重新啓動。是？沒有/ – 2009-09-16 20:35:12
這實際上在Unix/Linux世界非常罕見。這些軟件的設計（以及窗口）是爲了保護自己免受惡劣行爲的影響。我相信谷歌並不依靠硬重啓來糾正不當行爲的軟件。我會說這種技術不應該被使用，如果有人說他們的軟件恢復的最快途徑，你應該尋找其他的東西！
這是一個很好的觀點，但也許我在我的問題中錯誤地加了口音。我acutaly有興趣知道這個技術是否在其他層面上使用（不僅是操作系統），如果它被識別爲設計模式。 – 2009-09-16 20:23:01
+1。對我而言，重新啓動並不是一種真正的模式，對於那些對真正發生的事情，真正的問題是什麼以及如何解決這些問題毫無頭緒的人來說，這是一種最後的嘗試。實際上，重新啓動並不是很常見的IMO（我已經看到許多重新啓動只是因爲操作系統補丁，這並不常見）。 – 2009-09-16 21:12:21
如果我們談論的是在單個（或少數）服務器上運行的系統，那麼重新啓動它當然不是一種模式，因爲您需要停止所有操作。我聽說過多年未重啓的UNIX機器。 但是，如果您有一個由100個節點組成的集羣，並且其中一些節點開始表現不佳，那麼如果節點重新啓動需要很長時間，那麼您有可能在高負載下終止整個系統。 所以，我的實際問題是如果這種模式被識別並用於軟件開發的其他領域，而不僅僅是在服務器/集羣中。 – 2009-09-17 10:11:16
微控制器通常有一個看門狗定時器，必須每隔一段時間纔會復位（通過一行代碼），否則微控制器將復位。這使得固件不會陷入無限循環，等待輸入等等。
未使用的內存有時會設置爲導致復位或跳轉到微控制器在啓動時的相同位置的指令它被重置。如果以某種方式跳轉到程序存儲器外部的某個位置，這將重置微控制器。
雖然我無法想象設計模式本身，但以我的經驗來看，這是開發人員「選擇被打破」的結果。
我已經看到一個50用戶的站點因爲連接管理不佳而導致過度調用並且沒有緩存，導致SQL Server企業版（750 MB數據庫）和Novell服務器癱瘓。 Novell是總是根據開發人員的罪魁禍首，直到我們發現一個核心庫中缺少「CloseConnection」調用。到那時，數千人在升級中花費了不成功的代價，以解決這一個缺失的代碼行。
（爲什麼他們有企業版是超越我，所以不要問！）
如果你看一下腳本語言一樣在Apache上運行PHP，每次調用開始一個新的進程。在基本情況下，進程之間沒有共享狀態，一旦調用完成，進程終止。
資源管理方面的優勢不大，因爲當進程完成時它們將被釋放，並且對錯誤處理的需求減少，因爲該進程被設計爲快速失敗並且不會處於不一致狀態。
+1好點，parkr :)！ – 2009-09-24 11:37:54
我已經看到了它在應用層面的幾個地方（一個應用程序重新啓動本身，如果它的炸彈）。
我在應用級，其中服務從dBASE文件閱讀開始讀的時候X量後出錯實施的模式。它會查找引發的特定錯誤，如果發現錯誤，則該服務會調用一個控制檯應用程序來終止進程並重新啓動該服務。這很糟糕，我討厭它，但對於這種特殊情況，我找不到更好的答案。
，並承擔記住，IIS有一個內置的功能，重新啓動在一定條件下的應用程序池。
對於這個問題，重新啓動服務是Windows上的任何服務作爲服務時未採取行動的一個選項。
@mtnygard。感謝鏈接:)。我不瞭解ROC的概念。 – 2009-09-25 05:54:09