代碼
https://yunpan.cn/cPns5DkGnRGNs 密碼：3913
不是特殊的Demo，我們不再貼實例Demo的圖片了，直接去網盤找相應的項目看
可靠性：
分佈式、面向服務的系統可能會受到間歇性網絡故障的影響，這可能會對系統的整體完整性造成巨大破壞。系統必須爲失敗提供足夠的容錯性，它們必須能夠以可控和可預測的方式從失敗中恢復。
WCF提供了3個主要功能來提高整體的可靠性，以及客戶端和服務器之間通信的可預測性，這些功能包括：
1.可靠的會話（可靠的會話可以克服發生在TCP，命名管線和HTTP上的暫時性網絡中斷。當可靠會話被啓用的時候，如果服務不可用，那麼客戶端將試着重新發送消息。這樣的好處是，它是可互操作的，因此可以用來提高HTTP消息的可靠性。）
2.對事務的支持（事務編程性允許開發人員保證作業可以作爲單一的原子事務完成。）
3.消息隊列（當與事務相結合的時候，排隊消息爲耐用、可靠、單向的通信提供了一個基礎，在這種情況下，通信能夠在長時間網絡中斷和機器重新啓動情況下保持連接。WCF使用微軟消息隊列(MSMQ)來提供這種類型的可靠性。）
一：可靠的會話：
當你發送消息到一個遠程服務的時候，理想狀況是你可以確定消息已經到達那裏。如果該消息沒有到達，你也許會想重新發送，並再次嘗試，至少想知道該消息是否從未抵達，以便採取糾正措施。這些交付保證由一些傳輸協議如TCP或命名管線所提供，但不是通過
HTTP提供的( 但是通過可靠性，我們可以使HTTP也有此項功能 )。即便如此，有了TCP和命名管線，這些保證只有在點對點的情況下才能得到保障。如果在發送和接收應用程序之間存在一箇中間層，如代理服務器或信息路由器，那麼除了保證傳送途中的信息達到第一個網絡節點之外，不存在其他任何保證。
可靠會話以如下方式改善應用程序的可靠性：
1：可以保證信息只被傳送一次，並且是按照順序傳送的，以抵禦網絡連接短暫的中斷。
2：這些傳送保證不是與某一特定協議綁定的，從而可靠性對HTTP協議是可能的。
3：可靠性是基於整個SOAP消息，而不是隻針對個別IP數據包的。
毫無疑問可靠性是非常必要的，但使用可靠會話的決定通常是由添加可靠性的需要所驅動的，這種可靠性是傳輸協議所不能提供的。由於這些驅動，你可能會選擇性地考慮提高你的TCP端點的可靠性，但是一定要努力實現HTTP端點的可靠會話，這些端點沒有內置傳輸保證。總體上看來，可靠會話是提高單向信息傳送保證的一種很好的方式，因爲它們不提供一個明確的響應來表明成功或失敗。
配置可靠性會話：
1:承認區間
這是一個TimeSpan屬性，用來表明接收方在發送接收消息確認之前需要等待的時間，默認值是0.2秒。這一特性隻影響支持全雙工通信的綁定。（用作雙工通信的）
2：流量控制
這個boolean型屬性默認是啓用的。啓用後，當接收端的傳輸窗口緩衝區已滿時，發送端將推遲發送消息。這就降低了接收緩衝區已滿而無法處理一個到來的消息時，必要的重試操作的數量。
3：閒置超時
這是一個TimeSpan屬性，它控制可靠會話的期限。如果在此時間內沒有信息傳遞，這個會話就會出現故障。默認值是00:10:00(或10分鐘)。
4:最大等候信道
這個int屬性能夠在拒絕新的請求之前控制一個可靠會話的排隊的併發請求的數量。默認值是4。
5：最大重試次數
這個int屬性控制當一個消息沒有被承認時，發送端的重試次數。默認值是8，最大可被配置爲20。當一個消息的重試次數被用盡了之後，這個會話就會出現故障。
6：最大傳輸規模窗口
這個int屬性控制發送端或接收端緩衝區的消息數量。在發送端，消息被緩衝等待確認。在接收端，消息被緩衝傳送，有選擇地保證順序。其默認值是8。
7：有序的
這個boolean屬性默認是啓用的，這意味着，如果可靠會話被啓用，消息會按順序傳送。
在大多數情況下，以上這些選項的默認值應該足夠用了。最常見的變化，是提高閒置超時，以更好地配合會話過期規則。
標準綁定:
一些標準的綁定支持可靠會話，特別是NetTcpBinding,WSHttpBinding及WSDualHttpBinding。
WSDualHttpBinding可靠會話始終可用，而且你無法將其關閉。
NetTcpBinding,WSHttpBinding2個綁定可被聲明配置支持可靠會話，此時需要加入<reliableSession>節點到綁定的配置中 。
如下所示：
1 <wsHttpBinding> 2 <binding name="wsHttpRM"> 3 <reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00"/> 4 </binding> 5 </wsHttpBinding>
定製綁定：
爲了覆蓋其它可靠會話方案的默認方法，你必須創建一個定製綁定。下面的配置說明如何創建一個可靠的HTTP會話。在這種情況下，<reliableSession>元素使你能夠配置所有選項:
1 <customBinding> 2 <binding name="wsHttpCustomRm"> 3 <reliableSession acknowledgementInterval="00:00:00.2000000" flowControlEnabled="true" inactivityTimeout="00:10:00" maxPendingChannels="4" maxRetryCount="8" maxTransferWindowSize="8" ordered="true/>" 4 <textMessageEncoding/> 5 <httpTransport/> 6 </binding> 7 </customBinding>
你可能在服務中使用一個定製綁定，以根據不斷增長的系統負荷增加傳輸窗口規模或等待信道的緩衝。另一個原因可能是要爲一個命名管線信道添加可靠會話。
可靠會話的生命週期:
可靠會話的生命週期與初始化信道和接收信道的生命週期緊密相關。例如，當一個客戶端代理被用來調用服務時，客戶端信道是在服務被第一次調用時創建的。同樣，在第一次調用時，會創建服務信道，併發布可靠會話。
而在發生下列任何一種情況時，可靠會話就會結束：
1：發起程序銷燬了它的信道，例如，客戶端銷燬了代理。
2：接收信道達到配置的超時時間。
3：發起或接收信道進入出錯狀態。
當發起程序銷燬信道的時候，一系列的信息會被髮送到接收端，以正式終止可靠會話。這是終止可靠會話最優雅的方式，因爲雙方都充分知情，並能自如關閉，以清除剩餘的任何緩衝信息。
在傳統情況下，任何形式的會話超時都是由綁定的接收超時設置所控制的，這個值在創建之後就會被傳送給可靠信道，所以，以下配置會造成可靠會話在5秒鐘後超時，而不是默認的10分鐘。
1 <wsHttpBinding> 2 <binding name="wsHttpRM"> 3 <reliableSession enabled="true" ordered="true" inactivityTimeout="00:00:05"> 4 </wsHttpBinding>
你也可以明確設定綁定的可靠會話功能的空閒超時時間。在這種情況下，兩個超時配置中較短的一個將會起作用。
例如，以下配置的結果會導致可靠會話在5秒後超時:
1 <wsHttpBinding> 2 <binding name="wsHttpRM" receiveTimeout="00:00:05"> 3 <reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00"/> 4 </binding> 5 </wsHttpBinding>
重新嘗試
重新嘗試是可靠會話的一個重要特點。例如，如果網路連接暫時中斷，發起程序將試圖重新發送每個沒有被承認的信息，直到達到配置的重新次數的限制爲止。這包括在第一次調用時，創造可靠會話的重新嘗試。如果對某一特定的信息的重試嘗試達到了重試限制
，可靠會話就會被啓動信道終止。所以，爲了控制重試的次數，需要一個定製綁定，因爲標準綁定不提供對這個選項的訪問。
會話分流：
在前面我們討論過分流技術，使你能夠方便地控制服務的負載。我們解釋了ServiceThrottle行爲的MaxConcurrentSessions屬性如何控制在服務中可以分配的併發會話的數量。這個屬性可以限制任何類型的會話，包括可靠性會話。
舉例來說，對於一個支持可靠會話的PerCall服務，以下設置將只允許1000個可靠會話同時處於活動狀態:
1 <serviceThrottling maxConcurrentCalls="30" maxConcurrentInstances="1000" maxConcurrentSessions="1000"/>
到這裏 我們再看一個 Demo 本節課的 Demo ( 1.可靠性會話 ) 雲盤中
仔細觀察 Appconfig中的配置
[ 16-01 ]
然後自己測試一下