是否不可能处理很大的并发性？

Question

最近，我正在构建REST作为赋值的一部分，其中我应该在数据库表中增加一个计数器，假设该表只有一列，我应该像每秒向这个REST发出1000次请求来增加计数器，并且在结束时数据应该是一致的，也就是说，如果最初DB中的计数器值是0，那么在成功运行1000个请求之后，它应该是1000。

到目前为止，我通过数据库行级锁定实现了它，其他方法可能是在增加计数器的代码周围使用事务(具有最高隔离度)，但我观察到的是，虽然这是可以保持一致性的，但代价是高延迟，例如，我以1000 req/s运行一个j抄测试，时间为5秒，所有请求都在26秒左右满满，这实际上是一个巨大的延迟。

这在我脑海里产生了很多问题-

1. 在某些实时场景或应用程序中，这种高并发性必须以较低的延迟来处理，不是吗？
2. 它是否始终是关系数据库的局限，可以在某种程度上解决非关系型的nosql数据库？
3. 我想，就像用某种消息队列来排队这样的并发请求一样，但如果用户正在等待某些响应，这将是非实时行为。

提前谢谢，任何帮助都很感激。

Answer 1

这是对关系数据库和任何具有强并发性保证的数据库的限制。除了升级硬件之外，你真的无法绕开它。

这一切都归结为I/O操作。为了保证您的事务是100%写入的，并且不会丢失，数据库通常会将数据刷新到磁盘。取决于您拥有的磁盘，这需要超长时间，以毫秒为单位。

所以对于你的问题：

1. 并发性高的应用程序通常避免对每个请求进行事务处理、强保证或至少I/O操作。
2. 是的，有很多非关系数据库不会对每个请求进行刷新，或者将数据完全保存在内存中。
3. 排队或其他技巧不能解决io/秒瓶颈的根本问题。

您可以通过切换到SSD作为磁盘来实现您的目标，理论上这些磁盘可以达到1000 s io/秒，在这里，旋转磁盘最多可以达到1000 io/秒。然后，您必须说服您的数据库尽可能少对一个请求执行iops。

Answer 2

“限制”与数据库的“关系”(或非关系)无关。

场景的本质是，在前一个参与者结束添加1以获得2之前，不能开始添加1(例如获得3)，并且已经完全结束并提交了该更改。如果是2+1=3，您就无法开始计算，除非和直到上的值的两个是可用的和可靠的。因此，如果2是其他操作的结果，那么在该其他操作完全完成之前，您将无法启动。

这有时被称为“护航综合症”，它可以发生在任何技术中。

有很多商店，在那里他们用“高度一致”来做明显类似的事情，但要么通过避免任何形式的共享中心资源导致车队综合症(例如计数器)来实现，要么通过牺牲来实现它--您的“最终必须得到1000”保证。

Answer 3

在某些实时场景或应用程序中，这种高并发性必须以较低的延迟来处理，不是吗？

您想回顾一下关于LMAX使用环形缓冲数据结构进行消息传递的文献。

简单的回答是，在某些情况下，批次写入可以节省您的时间，前提是您可以安排问题，以便满足其他约束。