使用PreparedStatement时使用RabbitMQ设计Java OSGi应用程序

Question

我正在设计一个将在OSGi容器(目前为Equinox)中运行的应用程序.它将通过RabbitMQ接收消息并在内部处理它们.应用程序将作为服务器持续运行.我目前的计划是让RabbitMQ侦听器包配置其队列并将侦听器放在它们上,使用QueueingConsumer并运行在自己的线程中.侦听器将调用一个或多个处理服务来处理消息.处理器需要进行JDBC调用才能访问数据库.我希望能够控制处理器的调用顺序.如果能够灵活地在以后添加更多服务而不必重新编码RabbitMQ监听器,那将是很好的.

我面临的问题是消息可能会爆发或缓慢发生.我希望能够用来PreparedStatement加速数据库访问,但我也不想长期保持连接打开而没有任何进展.我已经考虑过DefaultConsumer直接进行子类化并让它在RabbitMQ中的线程上运行Connection,但后来我无法知道什么时候没有发生.我最初的想法是将消息处理器与OSGi服务完全分开,并且每次调用时都从池中获取数据库连接,但这会失去预处理语句的优势.我正在使用Tomcat JDBC池,它似乎没有准备好语句缓存.此外,我不确定为每次通话创建准备好的声明会有多昂贵,但这似乎很浪费.

到目前为止,我想出的最好的想法是让我的听众进行双循环处理.外部循环等待消息,然后调用内部循环建立数据库连接和预准备语句并运行,直到没有更多消息进入指定的超时,然后关闭其连接并返回到外部循环.我让这个工作进行了一点处理,但如果我有多个处理器可能有不同的预处理语句,我无法想象如何管理它.

也许我不得不放弃多种服务的想法,并将处理硬编码到我的听众中.

有什么建议？谢谢!

Answer 1

为什么不使用服务作为侦听器并向它们传递它们应该使用的 JDBC 连接？然后，一段代码将队列分派到您的服务。这个中央调度程序可以轻松地维护一个准备好的 JDBC 连接池。如果您不想在 API 中看到 JDBC 连接，请使用协调器服务来保持连接。然后，“感知”服务可以获得优化的 JDBC 连接。

或者，将数据源注册为侦听器服务的服务并实施您自己的池策略。由于您知道 OSGi 服务调用中的调用者，因此您可以进行各种优化，例如从捆绑包的 jar 中读取准备好的语句并相应地缓存它们。

我不会放弃这里的服务，我从经验中知道，你所获得的解耦非常棒。由于在此模型中，服务侦听器不依赖于 RabbitMQ，因此您可以轻松测试它们和/或切换到另一种队列技术。

话又说回来，在这些情况下，最好的办法就是采取你能想到的最简单的解决方案。如果您遇到性能问题，请测量并修复瓶颈。在不成熟的解决方案上浪费了疯狂的精力……我可以告诉你我浪费了很多时间的愚蠢的过早优化。