在进行系统设计的时候，不知道大家是否也遇到过这个问题，大量请求造成数据库压力过大。本文将介绍在高并环境下，上面这个问题的一种简单应对思路。
首先思考一个场景，在高并发的系统中，在每秒内有大量的请求要访问数据库，如果不考虑缓存，怎么才能够处理降低数据库压力。有的同学可能会说这多简单啊，增加带宽，加内存提升服务器性能。
如果不用这些方法呢？那么就可以用到请求合并的方法，将一段时间内的请求进行合并，然后统一提交查询数据库，能够做到将几十个甚至上百个查询进行批量处理。
当然，这么做也有一个前提，就是这些请求对实时性的要求不能太高。在这个条件下，牺牲一定的处理时间，来减少网络连接数，这么处理是一种性价比非常高的方法。
首先我们模拟一个场景，在不进行合并请求的情况下进行1000次请求，使用Postman进行请求测试，并使用Druid连接池进行数据库的监控：
可以看出，实际进行了1000次数据库的访问。在超高流量的情况下，这种访问方式是十分危险的，所以减少数据库的访问就成了当务之急。
再看看之前提到的请求合并，实现起来有这么几个问题需要解决：
1、以什么粒度作为合并请求的规则：
这里推荐按照时间粒度去合并请求，不推荐按照请求数量达到一定值再进行合并是因为有可能一段时间内请求数量比较少，达不到阈值则无法执行，造成早到达的请求等待非常长的时间。
Java中的ScheduledExecutorService提供了定时调度机制，且本身实现了ExecutorService接口，所以本身也支持线程池的所有功能。
2、如何存放一段时间的请求：
存放请求的方式就比较多了，我们知道，在高并发系统的设计中，消息队列被普遍应用于解耦，使用消息队列存放请求是非常合适的做法。由于我们这里是单机环境，能够保证线程安全的阻塞队列LinkedBlockingQueue就能简单实现我们的需求。
3、如何将请求的结果返回给请求
自从JAVA 1.5以后引入了Future接口，用于处理异步调用和并发事务。Future表示一个可能还没有完成的异步任务的结果，针对这个结果可以添加Callback以便在任务执行成功或失败后作出相应的操作。 简单的说，我们可以用它来接收线程的执行结果。
好了，请求的合并、执行、返回三大步骤都梳理清楚了，让我们看看具体怎么实现。
@ServicepublicclassBatchQueryService{//队列用来存放请求privateLinkedBlockingQueue<Request>queue=newLinkedBlockingQueue<>();@AutowiredItemServicequeryItemService;//封装请求classRequest{Stringcode;CompletableFuture<Map<String,Object>>future;publicStringgetCode(){returncode;}publicvoidsetCode(Stringcode){this.code=code;}publicCompletableFuture<Map<String,Object>>getFuture(){returnfuture;}publicvoidsetFuture(CompletableFuture<Map<String,Object>>future){this.future=future;}}@PostConstructpublicvoidinit(){ScheduledExecutorServicescheduledExecutorService=Executors.newScheduledThreadPool(1);scheduledExecutorService.scheduleAtFixedRate(()->{intsize=queue.size();if(size==0)return;List<Request>requests=newArrayList<>(size);for(inti=0;i<size;i++){Requestrequest=queue.poll();requests.add(request);}System.out.println("批量处理了"+size+"条请求");List<String>codes=newArrayList<>();for(Requestrequest:requests){codes.add(request.getCode());}List<Map<String,Object>>responses=queryItemService.queryByCodes(codes);//结果集完成-->把请求分发给每一个具体的RequestMap<String,Map<String,Object>>responseMap=newHashMap<>();for(Map<String,Object>response:responses){Stringcode=response.get("code").toString();responseMap.put(code,response);}//返回请求for(Requestrequest:requests){Map<String,Object>result=responseMap.get(request.getCode());request.future.complete(result);}},0,200,TimeUnit.MILLISECONDS);}//根据code进行单个查询publicMap<String,Object>queryItem(Stringcode){Requestrequest=newRequest();request.setCode(code);CompletableFuture<Map<String,Object>>future=newCompletableFuture<>();request.setFuture(future);queue.add(request);try{returnfuture.get();}catch(InterruptedExceptione){e.printStackTrace();}catch(ExecutionExceptione){e.printStackTrace();}returnnull;}}使用1000个线程对请求合并方法进行测试：
@ResponseBody@RequestMapping("/batchQuery")publicStringbatchQuery(){Threadthread[]=newThread[1000];for(inti=0;i<1000;i++){intj=i;thread[i]=newThread(newRunnable(){@Overridepublicvoidrun(){queryService.queryItem(j+"");}});thread[i].start();try{Thread.sleep(1);}catch(InterruptedExceptione){e.printStackTrace();}}return"ok";}看一下控制台输出结果：
Druid监控：
原本1000次的数据库操作被我们减少到了7次，实际对数据库的访问降到了之前的0.7%。当然，实际业务环境中可能定时调度的时间间隔不会增加到200ms这么大，这里只是为了演示一下请求合并能够发挥的巨大潜能。
最后对请求合并进行一下总结：
优点显而易见，通过请求合并减少了数据库的网络连接，降低数据库压力。最大化的利用的系统的IO，来提升系统的吞吐性能。
当然它也存在一定的局限性，仅能够用于对请求实时性要求不高的高并发系统，如果系统的应用场景不是在高并发场景下，那么根本没有使用请求合并的必要。
最后
如果觉得对您有所帮助，小伙伴们可以点赞、转发一下，非常感谢
公众号
码农参上，加个好友，做个点赞之交啊