背景

最近禅道bug比较多，自从参加工作以来，很少有写测试类的习惯，为了减少bug率，决定每次开发完之后都先严格自测一遍。

问题

当前项目采用spring cloud 做微服务开发，所以写测试类必须启动上下文，在启动测试类时出现了如图所示的问题。

Netty—–异步和事件驱动

• Netty是什么

Netty是一个Java语言编写的用于创建高性能网络通讯程序的框架

• 为什么不直接使用java语言编写网络程序

我们可以先看下面一段比较经典的网络通讯的流程代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

int port = 8080;
//监听端口
ServerSocket serverSocket = new ServerSocket(port);
Socket clientSocket = serverSocket.accept();
BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
PrintWriter out = new PrintWriter(clientSocket.getOutputStream(), true);
String request, response;
//readLine方法可能会阻塞
while ((request = in.readLine()) != null){
    if("Done".equals(request)){
        break;
    }
    //处理请求
    response = process(request);
    //返回响应
    out.print(response);
}

以上代码只能处理一个客户端连接的情况，如果要多个客户端同时通讯，需要为每个请求单独分配一个线程去处理请求

这种方案存在的问题：

• 处理请求的线程可能会在IO过程中可能会阻塞，大量线程阻塞的话会造成资源浪费
• 创建线程需要分配内存
• 线程切换会占用性能开销，线程数越多，性能开销越大

场景

在常规的web系统中，涉及到写操作的接口请求调用时，前端往往有做防止重复提交的验证，但是从系统的完整性上说，仅仅只在前端做校验实际上是有缺陷的，恶意调用接口者仍可通过其他工具重复调用接口，如果只是涉及读数据的接口可能还没什么问题，一旦重复调用涉及写的接口，则可能会造成无法预估的数据问题。

解决方案

如果只是单机服务，可以直接使用单机线程锁，在接口调用完成之前锁住接口，获取锁失败则快速返回，防止用户重复提交。考虑到系统的扩展性，使用基于redis的分布式锁，使用的spring的切面做前置增强获取锁，后置增强释放锁。

流程图