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

Question

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

现有架构

发送短信

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

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

确认短信

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

数据库设计

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

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

新架构

发送短信

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

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

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

确认短信同上

数据库设计

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

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

Answer 1

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

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

一旦我有机会测试，我将很快用一些性能说明编辑它。

更新

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

这将使您的查询保持快速，避免每天向表中添加新索引，同时您可以获得更小索引的好处。这应该让您在性能方面获得两全其美。

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

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

基本上，它所做的是向服务器发送一个非常轻量级的异步通知(顺便说一句，您可以在触发器中执行此操作)，然后您的应用程序就会知道轮询可能是个好主意。当通知事务提交时发送通知。