是否无法处理非常大的并发？

Question

最近，我正在构建一个REST api，作为分配的一部分，我假设要在数据库表中增加一个计数器（假设该表只有一列），我想每秒向该REST api发出1000个请求增加计数器，最后数据应该是一致的，即，如果最初DB中的计数器值为0，那么在成功并行运行1000个请求之后，它应该为1000。

到目前为止，我无需担心，它是通过数据库行级锁定来实现的，其他方式可以是在代码周围使用事务（具有最高隔离度）来增加计数器，但是我观察到的是，尽管这可以实现一致性，但这是以高延迟为代价的，例如，我以1000 req / sec的速度对Jmeter测试进行了5秒钟的测试，所有请求都在大约26秒钟内被填满，这确实是一个巨大的延迟。

这现在在我脑海中引发了很多问题-

1. 在某些实时场景或应用中，此级别的 高并发性以低延迟处理，不是吗？

2. 是否始终是关系数据库的限制，并且可能是     以某种方式解决了非关系型nosql数据库？

3. 我想像用一些消息来排队这样的并发请求     排队，但是如果用户是     等待一些回应

预先感谢， 任何帮助表示赞赏。

Answer 1

这是关系数据库和通常具有强并发保证的任何数据库的限制。除了扩大硬件之外，您真的无法解决它。

这一切归结为I / O操作。为了确保您的事务是100％写入的并且不会丢失，数据库通常会将数据刷新到磁盘。根据您所拥有的磁盘，这会花费超长时间（以毫秒为单位）。

对于您的问题：

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

通过将SSD用作磁盘，也许可以实现您的目标，理论上，这些SSD可以达到1000s io /秒，而旋转的磁盘最多可以达到100s io /秒。然后，您必须说服数据库对一个请求进行尽可能少的iops。

Answer 2

“限制”与数据库是否为“关系”无关。

这种情况的本质是，您不能在前一个演员结束添加1以获得2并完全结束并提交更改之前开始添加1（例如获得3）。如果2 + 1 = 3，则除非LHS上的值 两者 可用且可靠，否则您将无法开始计算。因此，如果2是其他操作的结果，则您将无法开始直到其他操作完全完成。

（有时）称为“车队综合症”，它实际上可以在任何技术中发生。

有许多 商店，他们在这些商店中 明显相似 的事情具有“高度一致性”，但是他们可以通过避免任何形式的共享中央资源导致车队综合征（例如您的柜台）来实现目标，或者通过 牺牲 来实现目标， “保证。

Answer 3

  

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

您想回顾有关LMAX将ring buffer data structure用于消息传递的文献。

简短的答案是，在某些情况下，假设您可以安排问题以便满足其他约束，则批量写入可以节省您的时间。