用户请求 —— 网关 —— 微服务 —— db
这样的方式对高并发的请求的线程快速的相应，因为数据库的每秒执行的事务数有限，很容易出现慢查询，此时数据库就成为了第一个瓶颈
为了解决这个问题，有两种策略
1:空间换时间，通俗来讲就是用钱砸，例如集群、负载均衡、可以买TPS（数据库每秒执行的事务数）、 QPS（数据库每秒执行的SQL数）更高的数据库等等。
2:时间换空间，通俗来讲就是以技术的方式解决问题，减少成本支出
第一种方式：用缓存的方式实现
「1」：web端发送查询请求，调用java应用程序
「2」：查询缓存（redis）中是否有数据
「3」：返回结果或者返回空
「4」：判断缓存中是否有数据，有则跳转第六步，无则跳转第五步
「5」：返回查询结果
「6」：查询数据库
第二种方式：批量查询
批量查询的方式就是今日学习的重点：请求合并，在redis缓存机制中有一个参数（pipelining），它的原理是在查询的管道中先堆积查询条件，在通过定时从堆积池中将查询条件组装成批量的集合，在进行查询，不加pipelining的条件下redis的查询可能只有12w次/秒，加上之后就有70+w次/秒，通过redis中的这种方式，可以考虑我们服务端代码是否也可以实现这种思路。这就是请求合并。
思路：收到前端的请求时，先存起来，隔段时间批量请求第三方服务批量接口，然后分别通知存起来的请求，并且响应前端。
弊端：有一定的延迟，因为需要定时获取堆积的请求条件，如果平时需要5ms的执行时间，放在一个10ms做一次批处理的合并场景下。则在最坏的情况下，执行时间可能会变成15ms。所以请求合并的机制只能适用于高并发的场景，如果很少有超过1或者2各的请求会并发在一起，则没必要用。
