【发布时间】:2015-03-25 14:07:07
【问题描述】:
我正在尝试为我的应用推出自己的短信验证系统。我不想开始为服务付费,然后让他们抬高我的价格(Urban Airship 对我这样做是为了推送通知:经验教训)。在开发和 Beta 测试期间,我一直在使用具有非常基本设置的 Twilio:1 个电话号码。它运行了一年多,但现在无论出于何种原因,消息并不总是被传递。无论如何,我需要为生产创建一个更好的系统。所以我有以下规格:
- 每分钟发送 600 条短信
- 零失误
- 省钱
现在my Twilio phone number can send one SMS per second;这意味着我能处理的最好的事情是每分钟 60 个快乐的用户。那么如何每分钟获得 600 个快乐用户呢?
因此,显而易见的解决方案是使用 10 个电话号码。但是我将如何实施该系统?我的服务器是 App Engine、DataStore、Java。假设我从 Twilio 购买了 10 个电话号码(当然越少越好)。如何实现数组以便它可以处理来自用户的并发调用?以下就足够了吗?
public static final String[] phoneBank = {“1234567890”,”2345678901”,”3456789012”,”4567890123”,…};
public static volatile nextIndex;
public void sendSMSUsingTwilio(String message, String userPhone){
nextIndex = (nextIndex+1)%phoneBank.length;
String toPhone = phoneBank[nextIndex];
// boilerplate for sending sms with twilio goes here
//…
}
现在假设有 1000 个用户同时调用此函数。 nextIndex 会从 0,1,2…9,0,1…9,0,… 连续运行,直到所有请求都发送完毕?
所以这确实是一个并发问题。这个并发问题将如何在 Java AppEngine 上运行?会有交错吗?瓶颈?我希望这在低预算的情况下速度很快:每分钟至少 600 个。所以我绝对不希望代码本身的同步浪费宝贵的时间。那么我如何最好地同步调用以增加nextIndex,以便电话号码都被平等地和定期地调用?同样,这是针对 Google App Engine 的。
【问题讨论】:
-
您能改用某种散列算法(例如基于用户 ID)从银行中选择一个号码吗?
-
@tx802 我认为这将是最简单的,因为它可以保证均匀分布,而您建议的散列可能不会。但我可以看到散列如何消除对并发性的需求。谢谢。这是一个我没有考虑过的好建议。
标签: java multithreading google-app-engine concurrency twilio