在设计系统时，我不知道每个人是否遇到了这个问题，并且大量请求会导致数据库压力过大。这篇文章将在上述问题中引入一个简单的响应想法。
首先，考虑一个场景。在高串联系统中，每秒都有很多请求可以访问数据库。如果您不考虑缓存，如何处理数据库压力。一些学生可能会说出它的简单程度，增加带宽并添加内存改进服务器性能。
如果这些方法不使用？那么您可以使用请求合并的方法，在一段时间内合并请求，然后均匀地提交查询数据库，以在批处理中进行数十个甚至数百个查询。
当然，还有一个前提是这些请求在实际时间内不应太高。在这种情况下，牺牲了一定的处理时间来减少网络连接的数量是一种非常成本效益的方法。
首先，我们模拟一个场景，执行1,000个请求，而无需合并请求，使用Postman进行请求测试，并使用DRUID连接池监视数据库：
可以看出，实际上进行了1,000个数据库访问。在超高流量的情况下，这种方法非常危险，因此减少数据库访问是最重点。
查看对前面提到的请求的合并，在实现中有几个问题要解决：
1.将什么粒径用作合并请求的规则：
建议根据时间粒径合并请求。不建议根据请求达到一定值。之所以合并，是因为请求的数量可能会在一段时间内相对较小。
Java提供了定时调度机制，并实现了接口本身，因此它还支持线程池的所有功能。
2.如何节省一段时间：
还有更多存储请求的方法。我们知道，在高频率系统的设计中，消息队列通常应用于解耦，并且使用消息队列存储请求非常合适。由于我们在这里是一个独立的环境，因此可以确保封锁队列可以确保线程LinkedBlockingqueue的安全性可以简单地达到我们的需求。
3.如何将请求结果归还请求
自Java 1.5以来一直引入该界面以处理异步呼叫和并发事务。可以使用它接收线程的执行结果。
好吧，请求的合并，执行和返回已清楚地解决，让我们看看如何实现它。
使用1000个线程测试请求合并方法：
看看控制台的输出结果：
德鲁伊监视：
最初的1,000个数据库操作减少到7次，并且对数据库的实际访问降至0.7％。当然，在实际业务环境中，时间间隔可能不会增加到200ms。这只是为了证明可以发出请求的巨大潜力。
最后，总结请求合并：
优点是显而易见的，通过请求合并并降低数据库压力来减少数据库网络连接。最大使用系统的IO来改善系统的吞吐量。
当然，它也有一定的局限性，只能用于需要低需求的高含量系统。如果系统的应用程序场景不在高处且合并方案，则根本不需要使用请求合并。
如果您认为这对您有帮助，您的朋友可以喜欢并转发它。非常感谢
公共帐户，加一个朋友，并赞美