这部分将介绍一些相对深入的知识点，包括通过并发限流来保证服务的可用性，通过可靠会话机制保证会话信息的可靠性，通过队列服务来解耦客户端和服务端，提高系统的可服务数量并可以起到削峰的作用，最后还会对之前的事务知识做一定补充。
对于WCF服务来说，其寄宿在一个资源有限的环境中，为了实现服务性能最大化，需要提高其吞吐量即服务的并发性。然而在不进行流量控制的情况下，并发量过多，会使整个服务由于资源耗尽而崩溃。因此为相对平衡的并发数和系统可用性，需要设计一个闸门(Throttling)控制并发的数量。
由于WCF的并发出来属于服务自身的行为，因此通过服务行为对其进行控制，ServiceBehaviorAttribute（之后回调的CallbackBehaviorAttribute与此类似）中的ConcurrencyModel属性定义了Single、Reentrant和Multiple三种典型的并发模式，Single表示一个实例上下文InstanceContext只能用于单一请求的处理，Reentrant也表示一个实力上下文某一时刻只能用于对单一请求的处理，但若涉及回调，也可以用于其他服务调用请求的处理，Multiple表示一个实力上下文可以同时处理多个服务请求。此外，当将服务行为的ReleaseServiceInstanceOnTransactionComplete属性设置为true，其同步模式必须是Single，因为不能在其他请求还在处理中时释放实例。此外，可以通过设置UserSynchronizationContext属性为false来禁止并发操作。
可以通过设置System.ServiceModel.Description.ServiceThrottlingBehavior的相关属性来限流，包括：
MaxConcurrentCalls:当前ServiceHost能够处理的最大并发消息数量，默认为单核16。
MaxConcurrentInstances：当前ServiceHost允许存在的服务实例上下文的数量，默认为116。
MaxConcurrentSessions：当亲ServiceHost允许的最大并发会话数量，默认为100。
实际上WCF在其内部构建一个专门的内部组件FlowThrottle，其包含一个Capacity属性，表示最大流量，以及一个队列和计数器。ServiceThrottle三个流量限制器就像是设置在信道分发器中的三道闸门，第一道限制并发会话的流量，第二道限制并发请求的数量，第三道限制并发实例上下文的数量。为什么是这样的判断顺序，仍然有疑问？
作为一个通信基础平台，需要保持消息的可靠性，由于网络环境限制，网络层往往不能保证消息的有效交付，因此需要在应用层通过可靠会话机制来实现端到端的可靠信息传输。对于可能传输来说，常见的问题包括重复消息和无序消息的问题。说到这，不得不提TCP协议，其就是用在解决IP层消息传输不可能和无连接问题的，其通过3此握手建立长连接，通过消息确认和超时重传机制来保证消息的可靠性。那么它与现在要提及的WCF中RM有什么区别呢？主要包含以下4点：WCF可靠消息是基于SOAP的，而TCP是基于报文段的；其与传输协议无关，并不限于TCP协议；并没有具体传输会话限制，可以跨越多个传输连接或会话；TCP在当前连接内提供端到端可靠传输，而WS-RM提供两个SOAP终结点见的可靠传输，不受传输连接限制。
在实质上，WS-RM可靠传输的原理与TCP的活动窗口机制相似，其首先也会创建连接（CreateSequence），服务端会返回去一个Identifier，之后开始数据传输，Sequence的头部包含Identifier和MessageNo，后者用于识别顺序，此外还包含AcksTo、Expires、Offer等参数，最后会TerminateSequence。主要注意的是，在请求-回复模式的通信中，为了减少通信量，消息将包含2部分，一部分是对上条消息的回复（SequenceAcknowledgement），一部分是新的消息，常见的可靠会话配置如下所示。
1 <system.serviceModel> 2 <bindings> 3 <customBinding> 4 <binding name="orderedDelivery"> 5 <reliableSession ordered="true"/> 6 <binaryMessageEncoding> 7 <readerQuotas maxArrayLength="2147483647"/> 8 </binaryMessageEncoding> 9 <tcpTransport maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"></tcpTransport> 10 </binding> 11 </customBinding> 12 </bindings> 13 </system.serviceModel>