我有一个向数百万用户发送消息的系统。
我们的集群中有 6 个应用程序节点，具有一个通用的 Oracle 数据库 (RAC)。
在其中一个用例中，我们必须向用户发送消息，消息发送后，我们必须更新数据库表中的计数器，该计数器的详细信息为 no。发送给用户的消息数。 我们还有一个限制，即一天内只能向用户发送“n”条消息。
所以，
1)每次发送消息之前，我们都必须读取数据库以获取计数器值。
2)每次发送消息后，我们都必须更新计数器。
任何节点都可以接收任何用户的消息，并且可以并行读取和更新数据库。
现在，我们面临的问题是每个节点每秒无法处理超过 1K 的消息。在峰值负载期间，所有线程都在读取或更新数据库。
我们正在考虑引入缓存机制来避免数据库调用。但是，由于这里写入数据库的数据也很大，我们认为缓存可能不是正确的解决方案。
您是否有更好的建议或架构来处理数据库上大量读写操作的用例？如果您遇到这种情况，您会建议什么解决方案？
如果您需要更多信息，请告诉我。
最佳答案
一种可能性是从数据库中完全删除应用程序。 相反，让他们将作业发布到队列中。让队列工作人员从队列中获取作业，读/写数据库并将结果发布到某种形式的结果缓存中。然后，应用程序可以轮询结果缓存以获取结果。
虽然这不会减少数据库读/写，但它允许您对整个应用程序进行分层。例如，您可以有一个层来过滤队列上的作业，将多个计数器更新捆绑在一起，并让工作人员一次性将它们全部写入。
另一个明显的可能性是仔细研究您的架构并决定是否需要更改数据库技术。如果您不过度依赖联接、复杂的 SQL 查询等，请查看键值存储或 NoSQL。看看 Cassandra 的性能。
This interview是关于 Reddit 架构的，它可能会给你一些不错的想法。 (它还显示了我提到的工作程序/队列方法)
关于java - Heavy DB 读写操作的设计选项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24310230/