在我们公司，我们正在构建一个高需求系统，用于通过 SMPP 以及直接使用调制解调器向不同的客户和提供商发送 SMS。
系统处理不同的请求，并连接到数据库以选择消息并更新它们的状态(发送、接收、错误等)。我们收到的发送短信的需求是按照优先级排队的，不同的 channel 根据请求的内容发布。现在，有必要生成线程来同时处理不同的 channel ，但这会导致系统运行缓慢，因为事务可能很多。
我们有兴趣开发一个新系统，它不应该有太多的并发问题，并且可以最大限度地利用我们的服务器处理器的能力。
根据我们的理解，我们的问题可以通过对请求的不同线程处理重新制作系统来解决， ¿您会推荐哪种体系结构、框架或库来处理此问题，从而提供最佳性能？
我们目前正在考虑:Java 7 Fork/Join、IBIS(MPJ、GMI、Satin)和 AKKA(Actors 库)，但这不是限制。还希望系统不依赖于架构，并且可以扩展并迁移到云服务。
PD:当前系统确实为每条要发送的消息生成一个线程，并以某种方式使用线程池，但根本没有以优化的方式进行。除了改进糟糕的实现之外，我们还希望利用我们所有的资源(核心、处理器)来提高整体性能。
最佳答案
Right now, is necessary to generate threads to handle the different channels concurrently, but this makes the system run slow as the transactions can be numerous.
这句话的含义是使系统变慢的是线程而不是事务带宽。你的证据是什么？
线程可能会产生问题的唯一方法是，如果它们太多以至于您遇到内存问题并且系统由于 GC 开销而变慢。每个线程分配一个大的连续堆栈空间(默认为 512k)，因此 2000 个线程(例如)将消耗 1gb 的核心。
验证线程是问题的一种方法是使用 jconsole 或其他工具观察应用程序的内存使用情况。如果您所有的内存桶都已满并且 GC 按钮几乎没有任何作用，那么您是对的。要尝试的另一件事是使用固定大小的线程池，而不是为您收到的每个请求 fork 一个线程。如果这提高了您的系统性能，但降低了您的交易吞吐量，那么您是对的。
由于 SMPP 协议(protocol)似乎是 TCP/IP，您不希望所有线程都处于等待循环中。如果您了解自己的 NIO 功能，就可以使用 NIO 编写您自己的 SMPP 协议(protocol)。
我也会做一些 searches for java NIO SMPP图书馆。快速搜索将我带到了 JSMPP .但是我没有这方面的经验。
JSMPP is a java implementation (SMPP API) of SMPP protocol (currently support SMPP v3.4). It provides interfaces to communicate with Message Center or ESME (External Short Message Entity) and able to handle traffic 3000-5000 messages per second.
关于java - 推荐用于 SMS 发送器系统的 Java 并发/并行库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12078192/