在我们公司，我们正在构建一个高需求系统，用于通过 SMPP 以及直接使用调制解调器向不同的客户和提供商发送 SMS。
系统处理不同的请求，并连接到数据库以选择消息并更新它们的状态（发送、接收、错误等）。我们收到发送短信的需求，这些短信按照优先级排队，根据请求通过不同的渠道发布。现在，需要生成线程来同时处理不同的通道，但这会使系统运行缓慢，因为事务可能很多。
我们有兴趣开发一个新系统，它不应该有太多的并发问题，并且可以最大限度地利用我们的服务器处理器。
据我们了解，我们的问题可以通过对请求线程的不同处理来重新构建系统来解决，¿您会推荐哪种架构、框架或库来处理这个问题，这将提供最佳性能？
我们目前正在考虑：Java 7 Fork/Join、IBIS（MPJ、GMI、Satin）和 AKKA（Actors 库），但这不是限制。还希望该系统不依赖于架构，并且可以是可扩展的并迁移到云服务。
PD：当前系统确实会为每个要发送的消息生成一个线程，并以某种方式使用线程池，但根本不是以优化的方式。除了改进糟糕的实现之外，我们还希望利用我们所有的资源（内核、处理器）来提高整体性能。
现在，需要生成线程来同时处理不同的通道，但这会使系统运行缓慢，因为事务可能很多。
这句话的含义是，是线程使系统变慢，而不是事务带宽。你对此有何证据？
线程可能产生问题的唯一方法是线程数量过多以至于您遇到内存问题并且系统由于 GC 开销而运行缓慢。每个线程分配一个大的连续堆栈空间（默认为 512k），因此 2000 个线程（例如）将消耗 1gb 的核心。
验证线程是否存在问题的一种方法是使用 jconsole 或其他方式查看应用程序的内存使用情况。如果您所有的内存桶都已满，而 GC 按钮几乎什么也没做，那么您是正确的。要尝试的另一件事是使用固定大小的线程池，而不是为您收到的每个请求分叉一个线程。如果这提高了您的系统性能，但降低了您的事务吞吐量，那么您是正确的。
由于 SMPP 协议似乎是 TCP/IP，因此您不希望所有线程都处于等待循环中。如果你知道你的 NIO fu，那么使用 NIO 编写你自己的 SMPP 协议是可能的。
我还会搜索 java NIO SMPP库。快速搜索将我带到JSMPP。然而，我没有这方面的经验。
JSMPP 是 SMPP 协议的 Java 实现（SMPP API）（目前支持 SMPP v3.4）。它提供与消息中心或 ESME（外部短消息实体）通信的接口，并且能够处理每秒 3000-5000 条消息的流量。
https://github.com/twitter/cloudhopper-smpp
Twitter 的 NIO SMPP 库基于 Netty 构建。目前用于支持数百家运营商sending/receiving每月绑定数十亿条消息。解决了每个bind/message. 有如何使用它的例子cloudhopper-smpp/src/test/java/com/cloudhopper/smpp/demo/