推荐用于 SMS 发送系统的 Java 并发/并行库答案

【问题标题】：Recommended Java Concurrency/Parallelism Library for SMS Sender System推荐用于 SMS 发送系统的 Java 并发/并行库
【发布时间】：2012-08-22 17:13:51
【问题描述】：

在我们公司，我们正在构建一个高需求系统，用于通过 SMPP 以及直接使用调制解调器向不同的客户和提供商发送 SMS。

系统处理不同的请求，并连接到数据库以选择消息并更新它们的状态（发送、接收、错误等）。我们收到发送短信的需求，这些短信按照优先级排队，根据请求通过不同的渠道发布。目前，需要生成线程来同时处理不同的通道，但这会使系统运行缓慢，因为事务可能很多。

我们有兴趣开发一个新系统，该系统不应该有太多的并发问题，并且可以最大限度地利用我们的服务器处理器。

据我们了解，我们的问题可以通过对请求的不同线程处理重新构建系统来解决， ¿您会推荐哪种架构、框架或库来处理这个问题，哪个会提供最佳性能？

我们目前正在考虑：Java 7 Fork/Join、IBIS（MPJ、GMI、Satin）和 AKKA（Actors 库），但这不是限制。还希望系统不依赖于架构，并且可以扩展并迁移到云服务。

PD：当前系统确实会为每个要发送的消息生成一个线程，并以某种方式使用线程池，但根本不是以优化的方式。除了改进糟糕的实现之外，我们还希望利用我们所有的资源（内核、处理器）来提高整体性能。

【问题讨论】：

github.com/nathanmarz/storm/wiki Akka 也很完美
我的回答对你有帮助吗？如果是的话，请用复选框接受它，如果可以的话，请投票。
我投了赞成票，它没有解决我的疑问，但它有很好的想法。

标签： java multithreading concurrency parallel-processing sms

【解决方案1】：

现在，需要生成线程来同时处理不同的通道，但这会使系统运行缓慢，因为事务可能很多。

这句话的含义是线程使系统变慢，而不是事务带宽。您对此有何证据？

线程产生问题的唯一方法是线程数量过多以至于您遇到内存问题并且系统由于 GC 开销而运行缓慢。每个线程分配一个大的连续堆栈空间（默认为 512k），因此 2000 个线程（例如）将消耗 1gb 的核心。

验证线程是问题的一种方法是使用 jconsole 或其他东西观察应用程序的内存使用情况。如果您所有的内存桶都已满，而 GC 按钮几乎什么也没做，那么您是正确的。要尝试的另一件事是使用固定大小的线程池，而不是为您收到的每个请求分叉一个线程。如果这提高了您的系统性能，但降低了您的事务吞吐量，那么您是正确的。

由于 SMPP 协议似乎是 TCP/IP，因此您不希望所有线程都处于等待循环中。如果你知道你的 NIO fu，就可以使用 NIO 编写你自己的 SMPP 协议。

我还会做一些searches for java NIO SMPP 库。快速搜索将我带到JSMPP。但是我没有这方面的经验。

JSMPP 是 SMPP 协议的 Java 实现（SMPP API）（目前支持 SMPP v3.4）。它提供了与消息中心或 ESME（外部短消息实体）通信的接口，能够处理每秒 3000-5000 条消息的流量。

【讨论】：

这很有见地，我会检查 Jconsole，尽管我可以在代码中看到线程很可能是问题所在。我们确实在使用 JSMPP，这是迄今为止我们找到的最好的 SMPP 库。您为什么认为如果我们遇到线程问题，Java 7 Fork/Join 不是解决方案？
您说“线程可能产生问题的唯一方法是线程数量过多以至于您遇到内存问题”，但我认为这不是真的。线程不只是使用内存，它们是操作系统中的调度单元；使用大量线程会导致大量上下文切换，这会降低性能。
线程消耗堆栈空间内存@Tom，默认为每个线程 512k，所以很多线程确实加起来。例如，2000 个线程使用 1gb 内存。此外，上下文切换是一个神话。有很多性能数据表明上下文切换成本是最小的。例如，如今很难击败 JVM。现在因为高内存而产生 GC 负载，这才是真正的问题。

【解决方案2】：

https://github.com/twitter/cloudhopper-smpp

基于 Netty 构建的 Twitter 的 NIO SMPP 库。目前用于支持数百个运营商绑定sending/receiving 每月数十亿条消息。解决了每个bind/message 需要一个线程的问题。 cloudhopper-smpp/src/test/java/com/cloudhopper/smpp/demo/中有使用方法的例子@

【讨论】：