2

我们有一个基于客户端-服务器的应用程序，它使用外部网关发送和接收 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 时间/范围分区根据接收日期、基于继承或
  2. 每天将数据从 table1 移动到 table2 的单独脚本。使用联合查询连接表以报告和检索数据。

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

4

1 回答 1

0

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

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

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

更新

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

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

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

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

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

于 2012-09-08T05:43:43.400 回答