重放攻击，类似WEB表单的重复提交，接口的访问者使用同样的消息体不断访问接口提供者的过程，从而导致接口提供者压力变大甚至服务器故障、数据丢失等。
防止重放攻击的一般做法是请求方和提供方约定一个唯一的TID，请求方携带此ID，提供方校验ID。常见的几种做法：
1、请求方每次从提供方申请一个唯一的TID
工作过程：
- 请求方申请TID
- 请求服务器时携带此TID
- 提供方对TID进行鉴权，通过则继续
这种方法简单，但是交互次数需要翻倍，而且TID量会很大，管理TID存在问题。
2、由客户端生成唯一的TID，如使用UUID生成方法
提供方判断UUID是否使用过，没有使用过则判定可以继续，否则中断处理
这种方法更简单，但是服务提供方如何保存如此多的UUID是一个严重的挑战。
中国移动的M币系统就是采用这种方法构建，那个处理能力只能呵呵了。
3、申请密钥KEY并加上唯一的Sequence解决
原理
- 请求方的每台机器甚至每个进程分发一个唯一的ClientCode
- 请求方向服务提供方申请一个KEY，服务提供方保留ClientCode、Key的对应关系，并默认对应的ServerSeq=1
- 请求方访问接口的HTTP头中增加AuthCode=AES（ClientCode+ClientSeq, KEY）和ClientCode两个HTTP Header
- 服务提供方收到请求，根据ClientCode找到服务端存储的ClientCode、Key和ServerSeq组合，使用Key对AuthCode解密，比对ClientSeq=ServerSeq+1，如满足，则校验成功，继续处理，否则中断
优势，一次请求，多次访问，安全有效。
请求方多线程/线程池的处理：
创建一个简单ClientCodePool，缓存所有的ClientCode和状态，伪码如下：
Class ClientCodePool {
Set<ClientCode> clientCodes;
ClientCode getFreeClientCode();
Void releaseClientCode(ClientCode)
Void applyNewClientCode()
Class ClientCode{
String clientCode;
String key
Long clientSeq
Boolean isFree
}
}
无论哪个线程，需要clientcode就从pool中获取，服务端返回后，release这个ClientCode即可，在申请后返回前，ClientCode.isFree=false的，release后ClientCode.isFree=true
提供方也存在一些公共数据的问题，最好是采用Zookeeper统一存储，当然如果要求不高，使用redis也行，毕竟既是校验失败了，客户端重新申请一次ClientCode的key即可。