通过外部网关发送 SMS 的设计评论

Question

我们有一个基于客户端-服务器的应用程序，它使用外部网关发送和接收 SMS。 我正在考虑重新设计/修改现有架构以提高效率和性能。 欢迎您提出相同的想法和建议。请注意高峰期 小时约每小时从客户端-服务器-网关发送 3000 条短信。 每天发送的短信总量可能在 8000 - 10,000 条之间

现有架构

发送短信

1. 客户端向服务器发送一条短信，等待来自服务器的唯一 smsid（由 db 生成）（打开连接）
2. 服务器将短信存储在数据库中，将短信发送到网关。
3. 网关向手机发送短信，向服务器返回唯一的receiptid。
4. 服务器在数据库中存储唯一的receiptid
5. 服务器向客户端返回唯一的 smsid（在步骤 2 中生成）

步骤 1 -5 是一个请求 - 响应周期。

确认短信

1. 网关向服务器发送消息的状态
2. 服务器将数据库中的消息状态从已发送更新为已发送/失败/未知等。
3. 客户端定期轮询服务器以使用之前收到的 smsid 接收消息的状态。
4. 客户端在客户端更新状态。

数据库设计

所有短信都存储在数据库中的 1 个单一短信表中。最初我们有数据，约会 回溯到 2006 年左右，单表大约有 500 万条记录。我们现在已经归档了数据并且只有 表中的当年数据。

缺点 - 客户端的长时间等待有时会导致连接超时错误，从而导致将相同的消息重新发送到服务器。 由于服务器无法检测到这是一条重复消息，它会将消息重新发送到网关， 导致向客户发送重复的短信。 - 每秒对 sms 表执行多次 SELECT、UPDATE 查询，有时会给数据库带来相当大的负载 和系统故障。也没有存档数据的机制。

新架构

发送短信

1. 客户端向服务器发送一条短信，等待来自服务器的唯一 smsid（由 db 生成）（打开连接）
2. 服务器将短信存储在数据库中，向客户端返回唯一的短信标识。

步骤 1-2 是一个请求-响应周期。

1. 使用 cron 的单独进程定期轮询数据库表以检索短信 并发送到网关或可以使用 java 多线程？？？
2. 网关向手机发送短信，向服务器返回唯一的receiptid。
3. 服务器在数据库中存储唯一的receiptid

确认短信同上

数据库设计

1. 使用 Postgresql 时间/范围分区，根据接收日期、继承 OR 对数据进行分区
2. 每天将数据从 table1 移动到 table2 的单独脚本。使用联合查询连接表以报告和检索数据。

基于数据库性能的更好方法是什么？

Answer 1

首先，我不相信有必要将其分解为多个表。您没有正在进行的批量操作可能会使在小表上检查键比在大表上更容易。但是，在您的情况下，更可能有用的是部分索引的概念。在这种情况下，您只索引当前的每日记录。

在这方面，您可以每天只为当前日期的记录创建一个新索引并删除以前的索引。如果您这样做，您可能还想为日期编制索引，以便快速创建此部分索引。

一旦我有机会进行测试，我将很快对其进行编辑，并附上一些性能说明。

更新

经过测试，看起来普通的日期索引是不够的。我认为您需要做的就是添加一个附加的 current_index 布尔值，默认值为 true。然后您可以索引 WHERE current_index = true 并在一天结束时将它们设置为 false，从而将它们从索引中删除。

这将使您的查询保持快速，防止每天向表中添加新索引，同时您可以从更小的索引中受益。这应该可以为您提供两全其美的性能。

另外：使用 cron 的单独进程定期轮询数据库表以检索短信并发送到网关，或者可以使用 java 多线程？？？

查看 Postgres 文档中的 LISTEN 和 NOTIFY。不要轮询数据库表。只需轮询通知。这将为您节省大量开销。不要依赖 NOTIFY 来获取有效负载，因为这不安全。只需将其用作您的应用程序的“触发器”即可知道它应该轮询。

基本上，它的作用是向服务器发送一个非常轻量级的异步通知（您可以在触发器中执行此操作），然后您的应用就会知道轮询可能是个好主意。当更新事务提交时发送通知。