分布式協調服務

A. 打開COM+應用程序時出現8004E00F -COM+ 無法與 Microsoft 分布式事務協調程序交談

IIS出現內部錯誤以及COM+8004e00f錯誤的解決辦法(MSDTC)
主要都是IWAM賬號在ActiveDirectory、IIS metabase資料庫和COM+應用程序三處的密碼無法同步，解決方法也很簡單，大致有一下三個步驟：

1、重新設置IIS的IWAM賬號密碼。[在計算機管理中的用戶管理里]
2、同步IIS metabase中IWAM_MYSERVER的密碼，在CMD中：c:\inetpub\adminscripts>adsutil set w3svc/wamuserpass "yourpassword"
3、同步COM+應用程序所用的IWAM_MYSERVER密碼，在CMD中：c:\inetpub\adminscripts>cscript synciwam.vbs -v，但是在進行第三步操作時總是報8004e00f錯誤。

後來在系統里不斷的亂看，發現MSDTC服務不正常，於是先從這里下手，具體的解決方法如下：
1、首先進入組件服務，查看組件服務/計算機/我的電腦/COM+應用程序，結果報錯"COM+ 無法與 Microsoft 分布式事務協調程序交談"，無法查看裡面的對象。
2、進入事件查看器，發現msdtc服務沒有正常啟動。
3、刪除注冊表中的鍵：
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC
• HKEY_CLASSES_ROOT\CID
4、停止MSDTC服務：net stop msdtc
5、卸載MSDTC服務：msdtc -uninstall
6、重新安裝MSDTC服務：msdtc -install
7、確認在事件查看器中msdtc服務已經正常啟動[這步很關鍵，如果沒有，重新啟動下電腦看看，然後再同步密碼（就是開始的那三步）

其實"COM+ 無法與 Microsoft 分布式事務協調程序交談"在安裝了Windows組件中的消息隊列後，就不會出現這個錯誤了，同時"消息隊列"組件又對服務中的"Distributed Transaction Coordinator"（即msdtc服務）有依存關系，這個服務必須啟用，才可以安裝消息隊列組件！消息隊列裝好後，上圖中的COM＋應用程序菜單就可以打開了，表示其已正常工作！如果在這個時候再裝IIS或者把IIS卸載重裝，就不需要上面的手動密碼同步問題了！就是說按這個步驟安裝好IIS，就已經正常了！實際上，手工同步密碼

B. 分布式系統為什麼要同步，同步所需要的構件有哪些

在Zookeeper的官 網上有這么一句話：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 這大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服務，提供分布式同步以及集群管理。那這些服務又到底是什麼呢？我們為什麼需要這樣的服務？我們又為什麼要使用Zookeeper來實現呢，使用Zookeeper有什麼優勢？接下來我會挨個介紹這些到底是什麼，以及有哪些開源系統中使用了。 配置管理 在我們的應用中除了代碼外，還有一些就是各種配置。比如資料庫連接等。一般我們都是使用配置文件的方式，在代碼中引入這些配置文件。但是當我們只有一種配置，只有一台伺服器，並且不經常修改的時候，使用配置文件是一個很好的做法，但是如果我們配置非常多，有很多伺服器都需要這個配置，而且還可能是動態的話使用配置文件就不是個好主意了。這個時候往往需要尋找一種集中管理配置的方法，我們在這個集中的地方修改了配置，所有對這個配置感興趣的都可以獲得變更。比如我們可以把配置放在資料庫里，然後所有需要配置的服務都去這個資料庫讀取配置。但是，因為很多服務的正常運行都非常依賴這個配置，所以需要這個集中提供配置服務的服務具備很高的可靠性。一般我們可以用一個集群來提供這個配置服務，但是用集群提升可靠性，那如何保證配置在集群中的一致性呢？ 這個時候就需要使用一種實現了一致性協議的服務了。Zookeeper就是這種服務，它使用Zab這種一致性協議來提供一致性。現在有很多開源項目使用Zookeeper來維護配置，比如在HBase中，客戶端就是連接一個Zookeeper，獲得必要的HBase集群的配置信息，然後才可以進一步操作。還有在開源的消息隊列Kafka中，也使用Zookeeper來維護broker的信息。在Alibaba開源的SOA框架Dubbo中也廣泛的使用Zookeeper管理一些配置來實現服務治理。 名字服務 名字服務這個就很好理解了。比如為了通過網路訪問一個系統，我們得知道對方的IP地址，但是IP地址對人非常不友好，這個時候我們就需要使用域名來訪問。但是計算機是不能是別域名的。怎麼辦呢？如果我們每台機器里都備有一份域名到IP地址的映射，這個倒是能解決一部分問題，但是如果域名對應的IP發生變化了又該怎麼辦呢？於是我們有了DNS這個東西。我們只需要訪問一個大家熟知的(known)的點，它就會告訴你這個域名對應的IP是什麼。在我們的應用中也會存在很多這類問題，特別是在我們的服務特別多的時候，如果我們在本地保存服務的地址的時候將非常不方便，但是如果我們只需要訪問一個大家都熟知的訪問點，這里提供統一的入口，那麼維護起來將方便得多了。 分布式鎖 其實在第一篇文章中已經介紹了Zookeeper是一個分布式協調服務。這樣我們就可以利用Zookeeper來協調多個分布式進程之間的活動。比如在一個分布式環境中，為了提高可靠性，我們的集群的每台伺服器上都部署著同樣的服務。但是，一件事情如果集群中的每個伺服器都進行的話，那相互之間就要協調，編程起來將非常復雜。而如果我們只讓一個服務進行操作，那又存在單點。通常還有一種做法就是使用分布式鎖，在某個時刻只讓一個服務去幹活，當這台服務出問題的時候鎖釋放，立即fail over到另外的服務。這在很多分布式系統中都是這么做，這種設計有一個更好聽的名字叫Leader Election(leader選舉)。比如HBase的Master就是採用這種機制。但要注意的是分布式鎖跟同一個進程的鎖還是有區別的，所以使用的時候要比同一個進程里的鎖更謹慎的使用。 集群管理 在分布式的集群中，經常會由於各種原因，比如硬體故障，軟體故障，網路問題，有些節點會進進出出。有新的節點加入進來，也有老的節點退出集群。這個時候，集群中其他機器需要感知到這種變化，然後根據這種變化做出對應的決策。比如我們是一個分布式存儲系統，有一個中央控制節點負責存儲的分配，當有新的存儲進來的時候我們要根據現在集群目前的狀態來分配存儲節點。這個時候我們就需要動態感知到集群目前的狀態。還有，比如一個分布式的SOA架構中，服務是一個集群提供的，當消費者訪問某個服務時，就需要採用某種機制發現現在有哪些節點可以提供該服務(這也稱之為服務發現，比如Alibaba開源的SOA框架Dubbo就採用了Zookeeper作為服務發現的底層機制)。還有開源的Kafka隊列就採用了Zookeeper作為Cosnumer的上下線管理。 後記 在這篇文章中，列出了一些Zookeeper可以提供的服務，並給出了一些開源系統裡面的實例。後面我們從Zookeeper的安裝配置開始，並用示例進一步介紹Zookeeper如何使用。 (轉載）

C. 什麼是分布式系統！作用是什麼、好處是什麼

故名思義，分布式系統就是將系統的應用層，數據層或其它部分構架成分布（物理和邏輯上的都可以）狀（通常是網狀）。分布式系統通常是為了增強系統的可擴展性、穩定性和執行效率。比如在線游戲通常就是分布系統，裡面所謂的「區」就是分布系統里子常式。而分布式資料庫其實也可以稱作分布式系統，數據持久化層是分布的（數據存在不同的資料庫中，可交互，有一套綜管系統來維護數據的完整性和准確性）
所以說分布式系統更准確地說是一種系統構架概念，不是一種技術，
C#對網路的支持挺不錯的，封裝得很好，你主要可能看看網路通信這一塊東西。然後機械工業出版社有一本分布式系統的書，做了全面闡述。你可以看看。~

下面是網路給出的解釋：

分布式軟體系統(Distributed Software Systems)
是支持分布式處理的軟體系統,是在由通信網路互聯的多處理機體系結構上執行任務的系統。它包括分布式操作系統、分布式程序設計語言及其編譯(解釋)系統、分布式文件系統和分布式資料庫系統等。
分布式操作系統負責管理分布式處理系統資源和控制分布式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。
分布式程序設計語言用於編寫運行於分布式計算機系統上的分布式程序。一個分布式程序由若干個可以獨立執行的程序模塊組成,它們分布於一個分布式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分布性、通信性和穩健性。
分布式文件系統具有執行遠程文件存取的能力,並以透明方式對分布在網路上的文件進行管理和存取。
分布式資料庫系統由分布於多個計算機結點上的若干個資料庫系統組成,它提供有效的存取手段來操縱這些結點上的子資料庫。分布式資料庫在使用上可視為一個完整的資料庫,而實際上它是分布在地理分散的各個結點上。當然,分布在各個結點上的子資料庫在邏輯上是相關的。
分布式資料庫系統是由若干個站集合而成。這些站又稱為節點，它們在通訊網路中聯接在一起，每個節點都是一個獨立的資料庫系統，它們都擁有各自的資料庫、中央處理機、終端，以及各自的局部資料庫管理系統。因此分布式資料庫系統可以看作是一系列集中式資料庫系統的聯合。它們在邏輯上屬於同一系統，但在物理結構上是分布式的。
分布式資料庫系統已經成為信息處理學科的重要領域，正在迅速發展之中，原因基於以下幾點：
1、它可以解決組織機構分散而數據需要相互聯系的問題。比如銀行系統，總行與各分行處於不同的城市或城市中的各個地區，在業務上它們需要處理各自的數據，也需要彼此之間的交換和處理，這就需要分布式的系統。
2、如果一個組織機構需要增加新的相對自主的組織單位來擴充機構，則分布式資料庫系統可以在對當前機構影響最小的情況下進行擴充。
3、均衡負載的需要。數據的分解採用使局部應用達到最大，這使得各處理機之間的相互干擾降到最低。負載在各處理機之間分擔，可以避免臨界瓶頸。
4、當現有機構中已存在幾個資料庫系統，而且實現全局應用的必要性增加時，就可以由這些資料庫自下而上構成分布式資料庫系統。
5、相等規模的分布式資料庫系統在出現故障的幾率上不會比集中式資料庫系統低，但由於其故障的影響僅限於局部數據應用，因此就整個系統來講它的可靠性是比較高的。
特點
1、在分布式資料庫系統里不強調集中控制概念，它具有一個以全局資料庫管理員為基礎的分層控制結構，但是每個局部資料庫管理員都具有高度的自主權。
2、在分布式資料庫系統中數據獨立性概念也同樣重要，然而增加了一個新的概念，就是分布式透明性。所謂分布式透明性就是在編寫程序時好像數據沒有被分布一樣，因此把數據進行轉移不會影響程序的正確性。但程序的執行速度會有所降低。
3、集中式資料庫系統不同，數據冗餘在分布式系統中被看作是所需要的特性，其原因在於：首先，如果在需要的節點復制數據，則可以提高局部的應用性。其次，當某節點發生故障時，可以操作其它節點上的復制數據，因此這可以增加系統的有效性。當然，在分布式系統中對最佳冗餘度的評價是很復雜的。
分布式系統的類型，大致可以歸為三類：
1、分布式數據，但只有一個總資料庫，沒有局部資料庫。
2、分層式處理，每一層都有自己的資料庫。
3、充分分散的分布式網路，沒有中央控制部分，各節點之間的聯接方式又可以有多種，如鬆散的聯接，緊密的聯接，動態的聯接，廣播通知式聯接等。
---------------------
什麼是分布式智能?
NI LabVIEW 8的分布式智能結合了相關的技術和工具，解決了分布式系統開發會碰到的一些挑戰。更重要的是，NI LabVIEW 8的分布式智能提供的解決方案不僅令這些挑戰迎刃而解，且易於實施。LabVIEW 8的分布式智能具體包括:
可對分布式系統中的所有結點編程——包括主機和終端。尤為可貴的是，您可以利用LabVIEW圖形化編程方式，對大量不同類型的對象進行編程，如桌面處理器、實時系統、FPGA、PDA、嵌入式微處理器和DSP。
導航所有系統結點的查看系統——LabVIEW Project Explorer。您可使用Project Explorer查看、編輯、運行和調試運行於任何對象上的結點。
經簡化的數據共享編程界面——共享變數。使用共享變數，您可輕松地在系統間(甚至實時系統間)傳輸數據且不影響性能。無通信循環，無RT FIFO，無需低層次TCP函數。您可以利用簡單的對話完成共享變數的配置，從而將數據在各系統間傳輸或將數據連接到不同的數據源。您還可添加記錄、警報、事件等數據服務――一切僅需簡單的對話即可完成。
實現了遠程設備及系統內部或設備及系統之間的同步操作——定時和同步始終是定義高性能測量和控制系統的關鍵問題。利用基於NI技術的系統，探索設備內部並編寫其內部運行機制，從而取得比傳統儀器或PLC方式下更為靈活的解決方案。
--------------------
在分布式計算機操作系統支持下，互連的計算機可以互相協調工作，共同完成一項任務。
也可以這么解釋:
一種計算機硬體的配置方式和相應的功能配置方式。它是一種多處理器的計算機系統，各處理器通過互連網路構成統一的系統。系統採用分布式計算結構，即把原來系統內中央處理器處理的任務分散給相應的處理器，實現不同功能的各個處理器相互協調，共享系統的外設與軟體。這樣就加快了系統的處理速度，簡化了主機的邏輯結構 。

希望對你有所幫助~ ：）

D. msdtc服務是什麼

msdtc.exe是微軟分布式傳輸協調程序。該進程調用系統 Personal Web Server和Microsoft SQL Server。該服務用於管理多個伺服器。
MSDTC設置方法 打開「管理工具――組件服務」，以此打開「組件服務――計算機」，在「我的電腦」上點擊右鍵。在MSDTC選項卡中，點擊「安全配置」按鈕。 在安全配置窗口中做如下設置： 選中「網路DTC訪問」 在客戶端管理中選中「允許遠程客戶端」「允許遠程管理」 在事務管理通訊中選「允許入站」「允許出站」「不要求進行驗證」 保證DTC登陸賬戶為：NT Authority\NetworkService 修復辦法 首先進入組件服務，查看組件服務/計算機/我的電腦/COM+應用程序，結果報錯「COM+ 無法與 Microsoft 分布式事務協調程序交談」，無法查看裡面的對象。 2、進入事件查看器，發現msdtc服務沒有正常啟動。 3、刪除注冊表中的鍵： ? HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC ? HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC ? HKEY_CLASSES_ROOT\CID 這些都會了,但是後面msdtc的停止\卸載＼安裝在哪裡都不知道了，請指點下列步驟的具體操作方式4、停止MSDTC服務：net stop msdtc 5、卸載MSDTC服務：msdtc -uninstall 6、重新安裝MSDTC服務：msdtc -install 7、確認在事件查看器中msdtc服務已經正常啟動[這步很關鍵，如果沒有，重新啟動下電腦看看] 8、重新設置IIS的IWAM賬號密碼。[在計算機管理中的用戶管理里] 9、同步IIS metabase中IWAM_MYSERVER的密碼，在CMD中：c:\inetput\adminscripts>adsutil set w3svc/wamuserpass "yourpassword" 10、同步COM+應用程序所用的IWAM_MYSERVER密碼，在CMD中：c:\inetput\adminscripts>cscript synciwam.vbs -v

E. 分布式事務處理協調器，在服務里是哪個

F. 怎麼啟動分布式事務處理協調器(DTC)

Microsoft分布式事務處理協調器(MS DTC)是一個事務管理器，它允許客戶端應用程專序在一個事務中包含多個不屬同的數據源。MS DTC協調在所有已在事務中登記的伺服器間提交分布式事務。
Microsoft? SQL Server安裝可通過下列方法參與分布式事務：
1，調用運行SQL Server的遠程伺服器上的存儲過程。
2，自動或顯式地將本地事務提升為一個分布式事務並在該事務中登記遠程伺服器。
3，執行分布式更新以更新多個OLE DB數據源上的數據。如果這些OLE DB數據源支持OLE DB分布式事務介面，SQL Server還可以將它們登記在分布式事務中。MS DTC服務協調正確完成分布式事務，以確保所有伺服器上的全部更為永久性的，或在發生錯誤時刪除所有更新。

G. 聯想Y7000 錯誤代碼8004E00F -COM+無法與Microsoft分布式事務協調程序交談

2、在服務界面，找到Distributed Transaction Coordinator服務，查看是否正常運行，右擊該服務，打開屬性，將其啟動類型改為自動並啟動後查看問題能否解決。

H. NET中有沒有類似ZooKeeper這樣的分布式服務框架

本文是JasonWilder對於常見的服務發現項目Zookeeper，Doozer，Etcd所寫的一篇博客，其原文地址如下：Open-SourceServiceDiscovery。服務發現是大多數分布式系統以及面向服務架構（SOA）的一個核心組成部分。這個難題，簡單來說，可以認為是：當一項服務存在於多個主機節點上時，client端如何決策獲取相應正確的IP和port。在傳統情況下，當出現服務存在於多個主機節點上時，都會使用靜態配置的方法來實現服務信息的注冊。但是當大型系統中，需要部署服務的時候，事情就顯得復雜得多。在一個實時的系統中，由於自動或者人工的服務擴展，或者服務的新添加部署，還有主機的宕機或者被替換，服務的location信息可能會很頻繁的變化。在這樣的場景下，為了避免不必要的服務中斷，動態的服務注冊和發現就顯得尤為重要。關於服務發現的話題，已經很多次被人所提及，而且也的確不斷的在發展。現在，筆者介紹一下該領域內一些open-source或者被經常被世人廣泛討論的解決方案，嘗試理解它們到底是如何工作的。特別的是，我們會較為專注於每一個解決方案的一致性演算法，到底是強一致性，還是弱一致性；運行時依賴；client的集成選擇；以後最後這些特性的折中情況。本文首先從幾個強一致性的項目於開始，比如Zookeeper，Doozer，Etcd，這些項目主要用於服務間的協調，同時又可用於服務的注冊。隨後，本文將討論一些在服務注冊以及發現方面比較有意思的項目，比如：Airbnb的SmartStack，Netflix的Eureka，Bitly的NSQ，Serf，SpotifyandDNS，最後是SkyDNS。問題陳述在定位服務的時候，其實會有兩個方面的問題：服務注冊（ServiceRegistration）和服務發現（ServiceDiscovery）。服務注冊——一個服務將其位置信息在中心注冊節點注冊的過程。該服務一般會將它的主機IP地址以及埠號進行注冊，有時也會有服務訪問的認證信息，使用協議，版本號，以及關於環境的一些細節信息。服務發現——client端的應用實例查詢中心注冊節點以獲知服務位置的過程。每一個服務的服務注冊以及服務發現，都需要考慮一些關於開發以及運營方面的問題：監控——當一個已注冊完畢的服務失效的時候，如何處理。一些情況下，在一個設定的超時定時(timeout)後，該服務立即被一個其他的進程在中心注冊節點處注銷。這種情況下，服務通常需要執行一個心跳機制，來確保自身的存活狀態；而客戶端必然需要能夠可靠處理失效的服務。負載均衡——如果多個相同地位的服務都注冊完畢，如何在這些服務之間均衡所有client的請求負載？如果有一個master節點的話，是否可以正確處理client訪問的服務的位置。集成方式——信息注冊節點是否需要提供一些語言綁定的支持，比如說，只支持Java？集成的過程是否需要將注冊過程以及發現過程的代碼嵌入到你的應用程序中，或者使用一個類似於集成助手的進程？運行時依賴——是否需要JVM，ruby或者其他在你的環境中並不兼容的運行時？可用性考慮——如果系統失去一個節點的話，是否還能正常工作？系統是否可以實時更新或升級，而不造成任何系統的癱瘓？既然集群的信息注冊節點是架構中的中心部分，那該模塊是否會存在單點故障問題？強一致性的Registries首先介紹的三個服務注冊系統都採用了強一致性協議，實際上為達到通用的效果，使用了一致性的數據存儲。盡管我們把它們看作服務的注冊系統，其實它們還可以用於協調服務來協助leader選舉，以及在一個分布式clients的集合中做centralizedlocking。ZookeeperZookeeper是一個集中式的服務，該服務可以維護服務配置信息，命名空間，提供分布式的同步，以及提供組化服務。Zookeeper是由Java語言實現，實現了強一致性（CP），並且是使用Zab協議在ensemble集群之間協調服務信息的變化。Zookeeper在ensemble集群中運行3個，5個或者7個成員。眾多client端為了可以訪問ensemble，需要使用綁定特定的語言。這種訪問形式被顯性的嵌入到了client的應用實例以及服務中。服務注冊的實現主要是通過命令空間（namespace）下的ephemeralnodes。ephemeralnodes只有在client建立連接後才存在。當client所在節點啟動之後，該client端會使用一個後台進程獲取client的位置信息，並完成自身的注冊。如果該client失效或者失去連接的時候，該ephemeralnode就從樹中消息。服務發現是通過列舉以及查看具體服務的命名空間來完成的。Client端收到目前所有注冊服務的信息，無論一個服務是否不可用或者系統新添加了一個同類的服務。Client端同時也需要自行處理所有的負載均衡工作，以及服務的失效工作。Zookeeper的API用起來可能並沒有那麼方便，因為語言的綁定之間可能會造成一些細小的差異。如果使用的是基於JVM的語言的話，可能會對你有幫助。由於Zookeeper是一個CP強一致性的系統，因此當網路分區（Partition）出故障的時候，你的部分系統可能將出出現不能注冊的情況，也可能出現不能找到已存在的注冊信息，即使它們可能在Partition出現期間仍然正常工作。特殊的是，在任何一個non-quorum端，任何讀寫都會返回一個錯誤信息。DoozerDoozer是一個一致的分布式數據存儲系統，Go語言實現，通過Paxos演算法來實現共識的強一致性系統。這個項目開展了數年之後，停滯了一段時間，而且現在也關閉了一些fork數，使得fork數降至160。.不幸的是，現在很難知道該項目的實際發展狀態，以及它是否適合使用於生產環境。Doozer在集群中運行3，5或者7個節點。和Zookeeper類似，Client端為了訪問集群，需要在自身的應用或者服務中使用特殊的語言綁定。Doozer的服務注冊就沒有Zookeeper這么直接，因為Doozer沒有那些ephemeralnode的概念。一個服務可以在一條路徑下注冊自己，如果該服務不可用的話，它也不會自動地被移除。現有很多種方式來解決這樣的問題。一個選擇是給注冊進程添加一個時間戳和心跳機制，隨後在服務發現進程中處理那些超時的路徑，也就是注冊的服務信息，當然也可以通過另外一個清理進程來實現。服務發現和Zookeeper很類似，Doozer可以羅列出指定路徑下的所有入口，隨後可以等待該路徑下的任意改動。如果你在注冊期間使用一個時間戳和心跳，你就可以在服務發現期間忽略或者刪除任何過期的入口，也就是服務信息。和Zookeeper一樣，Doozer是一個CP強一致性系統，當發生網路分區故障時，會導致同樣的後果。EtcdEtcd是一個高可用的K-V存儲系統，主要應用於共享配置、服務發現等場景。Etcd可以說是被Zookeeper和Doozer催生而出。整個系統使用Go語言實現，使用Raft演算法來實現選舉一致，同時又具有一個基於HTTP+JSON的API。Etcd，和Doozer和Zookeeper相似，通常在集群中運行3，5或者7個節點。client端可以使用一種特定的語言進行綁定，同時也可以通過使用HTTP客戶端自行實現一種。服務注冊環節主要依賴於使用一個keyTTL來確保key的可用性，該keyTTL會和服務端的心跳捆綁在一起。如果一個服務在更新key的TTL時失敗了，那麼Etcd會對它進行超時處理。如果一個服務變為不可用狀態，client會需要處理這樣的連接失效，然後嘗試另連接一個服務實例。服務發現環節設計到羅列在一個目錄下的所有key值，隨後等待在該目錄上的所有變動信息。由於API介面是基於HTTP的，所以client應用會的Etcd集群保持一個long-polling的連接。由於Etcd使用Raft一致性協議，故它應該是一個強一致性系統。Raft需要一個leader被選舉，然後所有的client請求會被該leader所處理。然而，Etcd似乎也支持從non-leaders中進行讀取信息，使用的方式是在讀情況下提高可用性的未公開的一致性參數。在網路分區故障期間，寫操作還是會被leader處理，而且同樣會出現失效的情況。

I. C# 分布式多任務協調

當初考慮過用資料庫來記錄，因為以下2點放棄了 --- 但你說的這兩點都和資料庫無關
你的問題可以看作是分布式鎖的問題，搜索這個關鍵字就會有很多解決方案

J. 請問DTC服務（全名：Distributed Transaction Coordinator）是否可以正常啟動在哪看呢謝謝了

Distributed Transaction Coordinator
分布式事務協調器，全稱是MSDTC

msdtc.exe
進程文件: msdtc or msdtc.exe
進程名稱: Distributed Transaction Coordinator
描述: Microsoft Distributed Transaction Coordinator控制多個伺服器的傳輸，被安裝在版Microsoft Personal Web Server和Microsoft SQL Server。
是否為系統權進程: 否