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 作为有效载荷，因为那是不安全的。只需将它用作您的应用程序的“触发器”即可知道它应该进行轮询。

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