第十六讲 可靠性会话

Posted 2020-07-09 HulkXu

代码

https://yunpan.cn/cPns5DkGnRGNs   密码：3913

不是特殊的Demo，我们不再贴实例Demo的图片了，直接去网盘找相应的项目看

---

 

可靠性：

分布式、面向服务的系统可能会受到间歇性网络故障的影响，这可能会对系统的整体完整性造成巨大破坏。系统必须为失败提供足够的容错性，它们必须能够以可控和可预测的方式从失败中恢复。 

 

 

WCF提供了3个主要功能来提高整体的可靠性，以及客户端和服务器之间通信的可预测性，这些功能包括：

1.可靠的会话（可靠的会话可以克服发生在TCP，命名管线和HTTP上的暂时性网络中断。当可靠会话被启用的时候，如果服务不可用，那么客户端将试着重新发送消息。这样的好处是，它是可互操作的，因此可以用来提高HTTP消息的可靠性。）

2.对事务的支持（事务编程性允许开发人员保证作业可以作为单一的原子事务完成。）

3.消息队列（当与事务相结合的时候，排队消息为耐用、可靠、单向的通信提供了一个基础，在这种情况下，通信能够在长时间网络中断和机器重新启动情况下保持连接。WCF使用微软消息队列(MSMQ)来提供这种类型的可靠性。）

 

可靠会话：

当你发送消息到一个远程服务的时候，理想状况是你可以确定消息已经到达那里。如果该消息没有到达，你也许会想重新发送，并再次尝试，至少想知道该消息是否从未抵达，以便采取纠正措施。这些交付保证由一些传输协议如TCP或命名管线所提供，但不是通过

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 ]

 

 

 

然后自己测试一下