重DB读写操作的设计选项

时间:2014-06-19 15:19:49

标签: java scalability

我有一个向数百万用户发送消息的系统。

我们在一个集群中有6个应用程序节点,其中包含一个通用的oracle数据库(RAC)。

在其中一个用例中,我们必须向用户发送消息,一旦交付,我们必须更新db表中具有no的详细信息的计数器。发送给用户的消息 我们还有一个约束,我们必须在一天内向用户发送“n”个消息。

So, 1) Every time before sending the message, we have to read the database to fetch the counter value. 2) Every time after sending the message,we have to update the counter.

任何节点都可以接收任何用户的消息,它可以并行读取和更新数据库。

现在,我们面临的问题是每个节点每秒无法处理超过1K的消息。在峰值负载期间,所有线程都在读取或更新DB。

我们正在考虑引入缓存机制以避免DB调用。但是,由于这里写入DB也很大,我们觉得缓存可能不是修正解决方案。

你有没有更好的建议或架构来处理这个用例,同时对DB进行大量的读写操作?如果你遇到这种情况,你会建议什么解决方案?

如果您需要更多信息,请告诉我。

1 个答案:

答案 0 :(得分:1)

一种可能性是完全从数据库中删除应用程序。 相反,让他们在队列上发布作业。让队列工作者从队列中获取作业,读/写数据库并将结果发布到某种形式的结果缓存。然后,应用程序可以轮询结果缓存以查找结果。

虽然这不会减少您的数据库读/写,但它允许您对整个应用程序进行分层。例如,您可以拥有一个用于过滤队列中作业的图层,将多个计数器更新捆绑在一起,让工作人员一次性写入所有这些内容。

另一个明显的可能性是仔细研究您的架构并决定是否需要更改数据库技术。如果您不过度依赖连接,复杂的SQL查询等可以查看键值存储或NoSQL。看看Cassandra的表现。

This interview是关于Reddit的架构,它可能会给你一些好主意。 (它还显示了我提到的工人/队列方法)