同一列相同内容合并Java逻辑_高并发场景-请求合并（一）SpringCloud中Hystrix请求合并...

背景

在互联网的高并发场景下，请求会非常多，但是数据库连接池比较少，或者说需要减少CPU压力，减少处理逻辑的，需要把单个查询，用某些手段，改为批量查询多个后返回。

如：支付宝中，查询“个人信息”，用户只会触发一次请求，查询自己的信息，但是多个人同时这样做就会产生多次数据库连接。为了减少连接，需要在JAVA服务端进行合并请求，把多个“个人信息”查询接口，合并为批量查询多个“个人信息”接口，然后以个人信息在数据库的id作为Key返回给上游系统或者页面URL等调用方。

目的

减少访问数据库的次数

单位时间内的多个请求，合并为一个请求。让业务逻辑层把单个查询的sql，改为批量查询的sql。或者逻辑里面需要调用redis，那批量逻辑里面就可以用redis的pipeline去实现。

主要解决手段

SpringCloud的Hystrix的自定义HystrixCollapse和HystrixCommand

SpringCloud的Hystrix注解方式。

没有服务治理框架时，利用JDK队列、定时任务线程池处理。

鉴于现在大部分都有SpringCloud，所以先说第种的注解方式，后续再说第3种，不用第1种是因为注解方式比较方便。

交互流程

主思路是接收请求后，从上一次计数开始累计等待200ms

一次过处理200ms内的接口入参

然后以id为key，批量查询多个id的结果

批量查询完后，以id为key，返回给上游系统的单个查询

测试手段

Postman

在本地系统创建单元测试方式，调用自己启动的服务

建立上游系统工程来调用

手动在页面请求多次

Jmeter生成多线程请求

选其一种。建议1、2

开发

本文主要使用Hystrix注解的方式去实现，还有另外一种办法实现的就是编码自定义HystrixCollapser，那种方法是建立两个类，一个继承HystrixCollapser，另一个继承HystrixCommand，这个方法比较显式的编码声明有助于理解，但是不够Hystrix方式便捷。

自定义HystrixCollapser方式和Hystrix注解方式实现请求合并的优劣

虽然Hystrix注解方式比较快，但是不能做到实时更改等待的单位时间，那个超时时间是放在注解