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

时间:2011-09-24 07:24:01

标签: java database

在容器上部署了一个java应用程序名称作为sbs。在其上面部署了3个其他Java应用程序,例如A,B和C.

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

应用sbs的唱歌(id)方法,每秒约200次,并为所有人播放信息。

我的问题:

数据库表:

播放ID:播放ID

计数:此播放ID的请求总数

上次日期时间:播放的最后日期和时间

播放ID:1

数量:总计66

上次日期时间:10/8/2011 231145(某事)

现在更新表格

播放ID:1

数量:总计92

上次日期时间:10/8/2011 231344(某事)

我必须更新此表,正如我之前提到的,此字段每秒更改200次。目的是知道此播放ID已播放了多少次。

我这样做吗?

每秒200次命中数据库是不可能的。所以我可以每4-5秒(周期性地)点击数据库并更新播放ID的计数状态。如何明智地执行该应用程序。需要每秒递增200次计数并在某处存储值并更新数据库......就像这样....最好的方法....

如果您有任何疑惑,请告诉我

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

2 个答案:

答案 0 :(得分:3)

嗯,你可以每秒200次或更多次点击你的数据库,但在你的场景中这是不需要的。而是使内存中的同步计数器(如具有原子整数的单例类)在每次播放歌曲时增加,然后每隔30秒或更新时间更新数据库中的计数值。我实际上做了类似的事情,效果很好。只要确保每个可数实体都有一个计数器类实例(我想这里的歌),并且递增计数器值是线程安全的(原子整数应该处理)

答案 1 :(得分:3)

正如你所说的那样,这个问题有点可疑:

  • 如果只接受每4或5秒更新一次表格,那么您将不可避免地“丢失”更新,countlast_date_time的值将不在如果你查询它的日期。

  • 更糟糕的是(如果你的系统在上次更新后4.9秒崩溃,那么你的系统将完全失去一些计数滴答。

如果这些异常很重要,那么您别无选择,只能同步在每个count请求中保留last_date_timesing(...)的值。

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


顺便说一下,每秒200次更新并不合理,特别是如果表格很小并且你做了一些调整。


  

我可以在更新记录时延迟4-5秒。 ....如果服务器崩溃了应用程序部署的地方,那么我们可以放一些逻辑......如果...如果特定播放ID的计数值为零...从DB获取最后一个计数然后递增它一个。

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

  

我们将这些信息保存在数据库中,因为我们需要获取这些记录,例如为此时间戳(某事)播放了多少播放ID。

你还没有回答的一个重要问题是,如果你偶尔不计算某些“戏剧”,那么是否重要

  • 如果无关紧要,那么每隔几秒缓存并进行更新就可以了。
  • 如果它确实重要,那么该解决方案是不可接受的,因为在某些情况下会失去一些游戏。

替代方案(正如我之前所说)是调整数据库;例如选择最合适的数据库引擎/表类型/索引,并调整用于执行更新的SQL或存储过程。如果正确调整数据库,则每秒200次更新过于昂贵。


  

如果我遇到的解决方案中我的表现没有太大影响,那么显然不会。

如果那是(真的)情况,那么只需使用“每5秒保存一次”的方法。或者如果你想要更好的表现“5分钟”或“5小时”。

实际上并不认为你真的明白我在问什么......因为对于那些不了解你的业务的人来说并不明显,这并不重要,而且表现真的不应该是相关的回答一下。它要么重要,要么不重要。

让我以另一种方式提出问题:

  

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