分布式系統中

❶ 如何解決分布式系統中的跨時區問題

從跨時區的角度對DateTime這個我們熟頌唯知的類型進行了深入探討，它們都是為這篇文章作的准備工作。在接下來的兩篇文章中，我們將完整的介紹如果在一個分布式系統中處理時區的問題。
一、場景以及需求
為了讓大家本文介紹的主題有一個比較直觀的認識，我們給出一個具體的應用場景。一個跨國公司開發一套統一的辦公系統，供遍布全球的所有分公司使用。客戶端的UI採用Smart Client （Windows Forms應用），而主要的業務邏輯均通過WCF服務的形式提供。我們將承載業務服務的伺服器成為應用伺服器，應用伺服器部屬於中國境內（東8區）。主要的客戶端（分公司）分布於三個主要的國家和地區：北美、歐州和澳洲。
不論客戶端和伺服器之間，還是不同的客戶端之間所處的時區均不相同，在進行時間處理的時候就會遇到一些麻煩：某個客戶端通過服務調用獲取的時間值應該基於哪個時區？對於這個問題，不同的場景可能有不同的要求。在大部分情況下，我們希望獲取的時間值就是基於客戶端的本地時區。不過也有些場景我們希望獲取的時間值對應的時區是描述對象基於的那個時區。比如說，美國分公司於當地時間9月1號早8點舉行開業典禮，歐洲分公司員工讀取這條信息就沒有必要將時間轉換成基於本地時區的時間。
不過，本文不考慮這種情況，我們的最終要求是：客戶端應用根本不用考慮時區問題，就像是一個單純的本地應用一樣。客戶端調用服務傳入的時間是DateTimeKind.Local時間或者DateTimeKind.Unspecified時間，同理通過服務調用返回的時間也應該是基於客戶端所在時區的時間。
二、解決方案實現原理
現在我們就來談談如何解決上面提出的問題。既然時區的處理不能在客戶端做，換言之就必須在服務端實現。我們的一個前提是：在資料庫中不存儲時區的任何信息。在這樣一個前提下實現上述的目標，野悔培需要解決兩個問題：時間的保存和時間獲取。
在時間的保存方面，既然資料庫中能保存任何時區偏移之類的信息。在這種情況下，我們必須讓所有保存在資料庫中的時間都是基於同一個時區。我們可以選擇應用伺服器所在的時區，也可以直接採用UTC時間。我們的方案採用後者，即資料庫所有時間保存為UTC時間 。
時間在資料庫中的存儲形式確定了，現在又出現一個問題：客戶端傳來的時間為客戶端所在時區的當地時間，服務端接收到客戶端發送的時間後，需要基於客戶端相應時區轉換成UTC時間才能保存到資料庫。那麼，服務端如何獲取客戶端所在的時區信息呢？將其作為服務操作的參數肯定是不可取的。
如果你看過我之前的WCF系列文章，可能會記前游得我有一篇介紹如何通過WCF擴展實現在客戶端和服務端之間傳遞上下文的文章：《通過WCF Extension實現Context信息的傳遞》。在這篇文章中我通過WCF擴展實現了將可戶端的Culture和UICulture自動傳向了服務端，從而確保兩邊保存一樣的語言文化環境上下文。如果我們能夠將基於客戶端本地的TimeZoneInfo作為上下文進行傳遞，就能解決服務端對客戶端的時區識別問題了。
關於保存時間的處理大體可以通過上面的序列圖（點擊看大圖）來描述。客戶端將基於本地時區的DateTimeKind.Local或者DateTimeKind.Unspecified時間作為輸入操作調用某個服務，與此同時，本地的TimeZoneInfo序列化後作為上下文傳遞到服務端。服務端接將接收到的時間，根據接收到TimeZoneInfo上下文轉換成DateTimeKind.Utc時間，並保存到資料庫中。
當客戶端調用服務獲取某個時間的時候，本地的同樣作為上下文信息被傳遞到服務端。藉助於這個TimeZoneInfo，服務端可以將資料庫中以UTC形式保存的時間轉換成基於客戶端時區的DateTimeKind.Local時間。右圖（點擊看大圖）所示的序列圖反映了這個過程。
三、TimeZoneInfo的序列化問題
在《談談你最熟悉的System.DateTime[上篇]》對TimeZoneInfo這個類進行介紹中，我說該類是可以被序列化的，序列化對於解決跨時區問題很重要。就是因為我們需要將TimeZoneInfo作為上下文在客戶端和服務端進行傳遞，換言之，就是將TimeZoneInfo對象進行序列化，將序列化後的內容放入出棧消息（Outgoing Message）的消息報頭（Message Header）中。
不過關於TimeZoneInfo對象序列化，我們一般並不會真正地將整個TimeZoneInfo對象交給序列化器去做序列化，而是利用定義在TimeZoneInfo中的兩個特殊的方法來進行序列化和反序列化的工作。一個是實例方法ToSerializedString，將TimeZoneInfo轉換成序列化後的一個字元串；另一個則靜態方法FromSerializedString，對序列化後的字元轉進行反序列化生成TimeZoneInfo對象。這兩個方法的定義如下：
1: [Serializable]
2: public sealed class TimeZoneInfo
3: {
4: //Others
5: public static TimeZoneInfo FromSerializedString(string source);
6: public string ToSerializedString();
7: }

下面的代碼演示了通過上述的這兩個方法對TimeZoneInfo的序列化和反序列化的實現：
1: string serializedString = TimeZoneInfo.Local.ToSerializedString();
2: Console.WriteLine("SerializedString: {0}\n", serializedString);
3: TimeZoneInfo deserializedTimeZone = TimeZoneInfo.FromSerializedString(serializedString);
4: Console.WriteLine("deserializedTimeZone.Equals(TimeZoneInfo.Local) ? {0}", deserializedTimeZone.Equals(TimeZoneInfo.Local));
5: Console.WriteLine("deserializedTimeZone == TimeZoneInfo.Local ? {0}", deserializedTimeZone == TimeZoneInfo.Local);

下面是輸出結果，從中我們看出最終被序列化後的文本的內容。此外，輸出結果也反映兩個另一個信息：兩個包含時區信息的TimeZoneInfo對象，調用Equals方法和使用==操作符得到不一樣的結果。個人覺得這是微軟作得不太到位的地方。
1: SerializedString: China Standard Time;480;(UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi;China Standard Time;China Daylight Time;;
2:
3: deserializedTimeZone.Equals(TimeZoneInfo.Local) ? True
4: deserializedTimeZone == TimeZoneInfo.Local ? False
關於這個分布式系統中跨時區問題的討論暫時就到這里，在下篇中我將給出一個完整的例子，相信會使你對本文給出的解決方案有一個深刻的認識。轉載，僅供參考。

❷ 分布式系統的基礎設施 是什麼

一個大型、穩健、成熟的分布式系統的背後，往往會涉及眾多的支撐系統，我們將這些支撐系統稱為分布式系統的基礎設施。昌褲高除了前面所介紹的分布式協作及配置管理系統ZooKeeper,我們進行系統架構設計所依賴的基礎設施，還包括分布式緩存系統、持久化存儲、分布式消息系統、搜索引擎，以及CDN系統、負載均衡系統、運維自動化系統等，還有後面章節所要介紹的實時計算系統、離線計算系統、分布式文件系統、日誌收集系統、監控系統、數據倉庫等。
分布式緩存主要用於在高並發環境下，減輕資料庫的壓力，提高系統的響應速度和並發吞吐。當大量的讀、寫請求湧向資料庫時，磁碟的處理速度與內存顯然不在一個量級，因此，在資料庫之前加一層緩存，能夠顯著提高系統的響應速度，並降低資料庫的壓力。作為傳統的關系型資料庫，MySQL提供完整的ACID操作，支持豐富的數據類型、強大的關聯查詢、where語句等，能夠非常客易地建立查詢索引，執行復雜的內連接、外連接、求和、排序、分組等操作，並且支持存儲過程、函數等功能，產品成熟度高，功能強大。但是，對於需要應對高並發訪問並且存儲海量數據的場景來說，出於對性能的考慮，不得不放棄很多傳統關系型資料庫原本強大的功能，犧牲了系統的易用性，並且使得系統的設計和管理變得更為復雜。這也使得在過去幾年中，流行著另一種新的存儲解決方案——NoSQL，它與傳統的關系型資料庫最大的差別在於，它不使用SQL作為查詢語言來查找數據，而採用key-value形式進行查找，提供了更高的查詢效率及吞吐，並且能夠更加方便地進行擴展，存儲海量數據，在數千個節點上進行分區，自動進行數據的復制和備份。在分布式系統中，消息作為應用間通信的一種方式，得到了十分廣泛的應用。消息可以被保存在隊列中，直到被接收者純碼取出，由於消息發送者不需要同步等待消息接收者的響應，消息的非同步接收降低了系統集成的耦合度，提升了分布式系統協作的效率，使得系統能夠更快地響應用戶，提供更高的吞吐。
當系統處於峰值壓力時，分布式消息隊列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個系統被壓垮。垂直化的搜索引擎在分布式系統中是一個非常重要的角耐尺色，它既能夠滿足用戶對於全文檢索、模糊匹配的需求，解決資料庫like查詢效率低下的問題，又能夠解決分布式環境下，由於採用分庫分表，或者使用NoSQL資料庫，導致無法進行多表關聯或者進行復雜查詢的問題。

❸ 分布式系統特點有哪些

分布式系統特點：

1、分布性。分布式系統由多台計算機組成，它們在地域上是分散的，可以散布在一個單位、一個城市、一個國家，甚至全球范圍內。整個系統的功能是分散在各個節點上實現的，因而分布式系統具有數據處理的分布性。

2、自治性。分布式系統中的各個節點都包含自己的處理機和內存，各自具有獨立的處理數據的功能。通常，彼此在地位上是平等的，無主次之分，既能自治地進行工作，又能利用共享的通信線路來傳送信息，協調任務處理。

3、並行性。一個大的任務可以劃分為若干個子任務，分別在不同的主機上執行。

4、全局性。分布式系統中必須存在一個單一的、全局的進程通信機制，使得任何一個進程都能與其他進程通信，並且不區分本地通信與遠程通信。同時，還應當有全局的保護機制。系統中所有機器上有統一的系統調用集合，它們必須適應分布式的環境。在所有CPU上運行同樣的內核，使協調工作更加容易。

5、分布式系統更加的開放，具有相同的介面規范使得集群計算機能夠方便的進行數據操作，系統協同度更高；

對外：體現在統一的介面描述上，用統一的介面描述語言描述一套所有伺服器都知道的規則，這樣各伺服器的交互問題上沒什麼問題了。具體的介面實現根據各個伺服器的情況具體實現，從而把實現和聲明進行了有效的解耦。對內：各台伺服器內部的策略和實現也需要解耦，以免整個伺服器是按照實現和聲明邏輯實現的，但是伺服器內部確實一個整體的，對於分布式的開放性將會大打折扣。

❹ 什麼是分布式系統中的冪等性

冪等性 ：就是用戶對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點擊而產生了副作用。

介面冪等性不只是分布式事務方便回滾的保證，同時也是SOA服務實現中摒殲棚行除重復消息的保證。

那就是支付，用戶購買商品使用約支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，用戶再次點擊按鈕，此時會進行第二次扣款，返回結果成功，用戶查詢余額返發現多扣錢了，流水記錄也變成了兩條。

方法一、 單次支付請求，也就是直接支付了，不需要額外的資料庫操作了，這個時候發起非同步請求創建一個唯一的ticketId，就是門票，這張門票只能使用一次就作廢，具體步驟如下：

如果步驟4通信失敗，用戶再次發起請求，那麼最終結果還是一樣的

方法二、 分布式環境下各個服務相互調用

這邊就要舉例我們氏嘩的系統了，我們支付的時候先要扣款，然後更新訂單，這個地方就涉及到了訂單服務以及支付服務了。

用戶調用支付，扣款成功後，更新對應訂單狀態，然後再保存流水。

而在這個地方就沒必要使用門票ticketId了，因為會比較閑的麻煩

（支付狀態：未支付，已支付）

步驟：

1、查詢訂單支付狀態

2、如果已經支付，直接返回結果

3、如果未支付，則支付扣款並且保存流水

4、返回支付結果

如果步驟4通信失敗，用戶再次發起請求，那麼最終結果還是一樣的

對於做過支付的朋友，冪等，也可以稱之為沖正，保證客戶端與服和拿務端的交易一致性，避免多次扣款。

❺ 什麼是分布式系統

分布來式系統是一個硬體源或軟體組件分布在不同的網路計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。

正是因為軟體的特性，所以分布式系統具有高度的內聚性和透明性。因此，網路和分布式系統之間的區別更多的在於高層軟體（特別是操作系統），而不是硬體。

(5)分布式系統中擴展閱讀

分布式系統系統優點

1、經濟：微處理機提供了比大型主機更好的性能價格比

2、速度：分布式系統總的計算能力比單個大型主機更強

3、固有的分布性：一些應用涉及到空間上分散的機器

4、可靠性：如果一個機器崩潰,整個系統還可以運轉

5、漸增：計算能力可以逐漸有所增加

❻ 分布式系統中常見技術解決的問題是什麼

分布式系統是一個非常廣泛的概念，它最終要落實到解純廳決實際問題上，不同的問題有不同的方法和架構。所有的開源軟體都是以某個應用場景出現，而純粹以「分布式」概念進行劃分的比較少見。舉個栗子！颸拓AInspir就是構建於分布式系統之上，它的特點在於大數據支持，基於Hadoop和Spark技術，支持海量數據挖掘；深度學習支持，支持運行於GPU之上的深度學習演算法，大幅提扒褲陪高預測准確度和降低誤差率；多數據源支持，支持RDBMS、NoSQL、消息隊列和文本數據源；支持私有雲和公有雲部署；MaaS(Model as a Service)支持，模型雲端共享，降低建模成本，支持數據的集成接入；業務模型，建立行業模型，讓客戶更關春蠢注於業務；演算法組件化，提供數據源、數據預處理、特徵工程、統計分析、機器學習、文本處理六大類型的數據挖掘組件；GUI模型編排，採用Drag and Drop體驗式建模過程；

❼ 如何理解分布式系統中的機制與策略

近年來由於計算機網路的快速成長,策略性分布式系統變得越來越重要。在傳統基於分布式系統研究中,代理都被假設為服從性的。這種假設忽略了不同代理之間的利益關系,也即當從屬於不同組織的代理的行為遵循個體利益最大化的策略而非全局演算法時,系統的動因(Incentive)就成為了一個急待解決的重要問題。機制設計(Mechanism Design)從經濟學和博弈論中得到的概念能夠描述策略性的代理,提供代理的動因,能解決這樣的問題,從而達到個體自私的代理的利潤最大化的同時,全局系統的最優化。 然而,在傳統的機制設計問題定義中,人們考慮的通常只有用戶願意支付的價格或者服務商的成本,而不同用戶,不同服務商之間的差異性被忽視了。在實際情況中,不同用戶視同一服務商,基於不同用戶考量的標准和參數不同,對該服務的估值是不一樣的。相應的,不同服務商根據具體的情況,服務同一用戶的服務成本很有可能也是不同的。在這樣的前提下,基於傳統的VCG的機制將不能保證strategyproof的特性,我們將提出Value-based解決方案來替代。 同時,在理性前提假設下,不同場景中的機制是不一樣的。在本文中,我們講分別討論相應場景下的strategyproof機制。我們還將結合實際的分布式策略系統的說明機制的適用性,其中包括了從最早web cache,分布式存儲,計算,到p2p文件共享,adhoc網路以及最近很熱門的認知無線電網路,證明了我們的機制可以很好的解決系統中存在的動因問題,讓博弈方說出真實的類型值,做出理性的判斷。 另外,我們也將引入雙向拍賣的概念來討論最復雜的多服務對多用戶的場景。我們從雙向拍賣的背景開始,逐一介紹雙向拍賣的運行環境和相應的買家賣家報價策略,並在McAfee的機制基礎上提出我們的雙向VCG機制,並證明了在一定條件下的strategyproof特性。最後,我們也以實際的外匯交易系統中的定價策略為例,討論了雙向拍賣中第三方撮合交易的方法以及原理。

❽ 什麼是分布式系統

分布式系統是建立在網路上的軟體系統。 處理協助任務，然後整合結果。在分布式系統中，一組獨立的計算機向用戶呈現一個統一的整體，就像一個系統一樣。系統具有多種通用的物理和邏輯資源，可以動態分配任務，分散的物理和邏輯資源可以通過計算機網路實現信息交換。系統中有一個分布式操作系統，以全局方式管理計算機資源。通常，對於用戶來說，分布式系統只有一個模型或範例。在操作系統之上，一個軟體中間件層負責實現這個模型。分布式系統的一個著名例子是萬維網，在滲亮萬維網中，一切看起來都像一個文檔(網頁)。在計算機網路中，這種統一性、模型和軟體是不存在的。用戶看到的是實際察喊塵的機器，計算機網路並沒有讓這些機器看起來千篇一律。如果這些機器有不同的硬體或不同的操作系統，那麼這些差異對用戶來說是完全可見的。如果用戶想要在遠程機器上運行程序，他必須登錄到遠程機器上並在該機器上運行程序。分布式系統和計算機網路系統的共同點是大部分分布式系統都是建立在計算機網路上的，所以分布式系統和計算機網路的物理結構基本相同。兩者的區別在於分布式操作系統和網路操作系統的設計思想不同，這就決定了它們在結構、工作方式和功能上也是不同的。網路操作系統要求網路用戶在使用網路資源時首先了解網路資源。網路用戶必須了解網路中每台計算機的功能和配置、軟體資源和網路文件結構。如果用戶想要讀取網路中的共享文件，他們必須知道該文件放在哪個計算機和目錄中。分布式操作系統以全局方式管理系統資源，可以隨意為用戶調度網路資源，調度過程「透明」。當用戶提交作業時，分布式操作系統可以根據需要選擇系統中最合適的處理器，將用戶的作業提交給處理程序，在處理程序完成作業後將結果傳遞給用戶。在這個過程中，用戶並沒有意識到多敗禪個處理器的存在，系統就像一個處理器。