如何防止WCF处理携带相同数据的重复并发请求？

现有服务实现 #

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    [WebInvoke(UriTemplate = "UpdateMyData", Method = "POST", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped)]
    [return: MessageParameter(Name = "updateMyDataResponse")]
    UpdateMyDataResponse UpdateMyData(UpdateMyDataRequest updateMyDataRequest);
}

public class MyService : IMyService
{
    //1. 禁止相同请求数据重复调用该方法
    //2. 同一客户端同一时间仅能调用该方法1次，需等前一次请求结束才能发第二次
    //3. 客户端对整个服务的调用需串行执行，按请求顺序逐个处理
    public UpdateMyDataResponse UpdateMyData(UpdateMyDataRequest updateMyDataRequest)
    {
        var fileName = updateMyDataRequest.fileName;

        //核心管控要求：全局所有服务实例不能同时处理相同fileName的请求；同一客户端不能并发进入该方法逻辑
        //此处为耗时较长的重负载业务逻辑
        //...

        return new UpdateMyDataResponse(true);
    }
}

预期管控目标 #

满足以下任意一种效果即可：

• 禁止携带相同请求数据的请求调用UpdateMyData方法
• 同一客户端同一时间仅能调用该方法一次，客户端必须等待前一次请求处理完成后才能发起第二次请求
• 客户端仅能串行调用服务的所有接口，按请求顺序逐个处理

核心约束：全局所有服务实例都不会处理携带相同fileName参数的重复请求，或是同一客户端不会并发进入该方法的执行逻辑（方法内部包含耗时较长的重负载业务处理）。

已调研方案及缺陷 #

方案1：采用单会话服务实例模式，限制单客户端最大连接数为1 #

该方案存在安全层面的问题：同一客户端的调用请求可能来自多个不同IP，方案可行性难以通过团队审批。

方案2：在服务类中使用静态列表，在进程内存中存储正在处理的文件名 #

该方案属于公认的不良实践，同样难以说服团队采纳。

可行实现建议 #

针对「相同fileName全局防重入」需求 #

不要直接使用裸静态列表，改用基于并发字典+分布式锁的分层管控方案：

1. 单服务节点内用ConcurrentDictionary<string, SemaphoreSlim>做进程内锁，key为fileName，每个fileName对应一个独立的信号量，既避免全局锁带来的性能损耗，也能保证同节点内相同文件名的请求不会并发执行；处理完成后及时清理字典中无等待队列的key，避免内存泄漏。
2. 如果是多节点部署的服务，在进程内锁的基础上叠加分布式锁（可基于Redis、数据库行锁实现），锁key按wcf:update:filename:{fileName}规则生成，锁超时时间设置为重负载业务的最大允许执行时长，避免异常场景下锁永久不释放。
   这种实现是工业界标准的幂等/防重入实现方案，比裸静态列表的可靠性、可维护性高很多，不属于不良实践。

针对「同客户端串行调用」需求 #

不要依赖WCF会话+IP识别的方案，改为客户端身份标识+粒度可控的并发管控：

1. 要求客户端所有请求携带唯一的客户端标识（比如登录后下发的ClientId、用户Id，不依赖来源IP做身份识别，解决多出口IP的问题）。
2. 单节点内用ConcurrentDictionary<string, SemaphoreSlim>按客户端标识做信号量管控，每个客户端对应的信号量初始计数为1，请求进入时先等待获取信号量，处理完成（包括异常场景）后必须释放信号量。多节点部署场景同样叠加对应key的分布式锁即可。
3. 如果需要实现整个服务全接口串行，只需要把锁的粒度从单个方法放大到客户端维度的全局信号量即可，不需要修改WCF的实例模式、会话配置，对现有业务侵入性极低。

兜底校验逻辑 #

可以给接口增加幂等校验规则：每个请求携带唯一请求Id，服务端缓存已处理完成的请求Id+请求核心参数（比如fileName）的哈希值，缓存有效期设置为重负载业务的最大执行时长加合理冗余时间，匹配到重复请求直接返回重复请求提示，从入口层拦截重复调用。

内容的提问来源于stack exchange，提问作者Ligne Atlas