寻找实时解决方案：高效的数据库交互

Question

在容器上部署了一个名为 sbs 的 java 应用程序。在它的顶部部署了 3 个其他 java 应用程序，比如说 A、B 和 C。

现在应用程序 A、B 和 C 命中一个方法名称为应用程序 sbs 的 Sing(id)，用于播放消息。

应用sbs的sing(id)方法，每秒点击200次左右，为所有人播放一条消息。

我的问题：

数据库表：

播放 ID：播放 ID

Count : 请求此播放 id 的总数

Last Date Time : 上次播放的日期和时间

播放 ID：1

计数：总共 66 个

最后日期时间：10/8/2011 231145（某事）

现在更新表格

播放 ID：1

计数：总共 92 个

最后日期时间：10/8/2011 231344（某事）

我必须更新这个表，正如我之前提到的，这个字段每秒改变 200 次。目的是知道这个播放 id 已经播放了多少次。

我该怎么做？

每秒访问数据库 200 次是不可能的。所以我可以每 4-5 秒（定期）访问数据库并更新播放 ID 的计数状态。我如何明智地执行该应用程序。需要每秒将计数增加 200 次，并将值存储在某处并更新数据库......像这样......什么是最有效的方法......

如果您有任何困惑，请告诉我

寻找您的宝贵意见。提前致谢。

Answer 1

正如你所说，这个问题有些可疑：

• 如果可以接受每 4 或 5 秒只更新一次表，那么您将不可避免地“丢失”更新，如果您查询，count 和 last_date_time 的值将过期它。

• 更糟糕的是（也许）如果您的系统在上次更新后 4.9 秒崩溃，那么您的系统将完全丢失几个计数滴答。

如果这些异常情况很重要，那么您别无选择，只能同步在每个 sing(...) 请求上保持 count 和 last_date_time 的值。

但如果它们无关紧要，为什么还要将这些信息保存在数据库中呢？为什么不把它全部保存在内存中并接受当服务器崩溃和重新启动时计数会重置？或者，如果您出于记账目的需要保留计数，为什么不将“play(id)”事件写入一个特殊的日志文件并通过离线扫描日志来生成帐户。

---

顺便说一句，每秒 200 次更新并不是不合理的，尤其是在表很小并且您进行一些调整的情况下。

---

我可以承受 4-5 秒的记录更新延迟。 .... 如果服务器崩溃，那么应用程序部署在哪里，我们可以放置一些逻辑......类似......如果特定播放 ID 的计数值为零......从数据库中获取最后一个计数，然后增加它到一个。

这种方法存在一个重大缺陷。在最后一次更新和应用程序崩溃之间的时间间隔内，对于任何给定的歌曲，可能有零个“播放”、一个“播放”或多个“播放”。当应用程序返回时，它根本不知道那些“播放”是什么......而且它无法知道它们，除非它们被记录在某个地方。

我们将这些信息保存在数据库中，因为通过这些记录，我们需要获取记录，例如为这个时间戳播放了多少播放 id（一些东西）。

大问题......你还没有回答......如果你偶尔不计算一些“游戏”是否重要。

• 如果没关系，那么缓存并每隔几秒进行一次更新就可以了。
• 如果它真的很重要，那么该解决方案是不可接受的，因为它会在某些情况下失去一些发挥。

另一种选择是（如我之前所说）是调整数据库；例如选择最合适的数据库引擎/表类型/索引，并调整用于进行更新的 SQL 或存储过程。如果您正确调整数据库，每秒 200 次更新不会过于昂贵。

---

如果我遇到的解决方案对我的性能影响不大，那么显然不会。

如果情况确实如此，那么只需采用“每 5 秒保存一次”的方法。或者，如果您想要更好的性能“5 分钟”或“5 小时”。

实际上，您并没有真正理解我在问什么......因为（对于不了解您业务的人）并不明显（对于不了解您的业务的人）这并不重要，并且性能确实不应该相关完全没有答案。要么重要，要么不重要。

让我换个方式问这个问题：

“如果计数不准确会损害您的业务”？

Answer 2

好吧，您可以每秒访问您的数据库 200 次或更多，但在您的场景中，这不是必需的。而是在内存中创建一个同步计数器（就像一个带有原子整数的单例类），每次播放歌曲时都会递增，然后每隔 30 秒左右更新一次数据库中的计数值。我实际上做过类似的事情，效果很好。只需确保每个可数实体都有一个计数器类实例（我猜这里是歌曲），并且递增计数器值是线程安全的（原子整数应该解决这个问题）