是否无法处理非常大的并发？ [英] Is handling very large concurrency not possible?

问题描述

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

Recently I am building a REST api as part of an assignment where I am suppose to increment a counter in the database table, assuming the table has only one column, I am suppose to fire like 1000 requests per second to this REST api to increment the counter and at the end the data should be consistent i.e. if initially the counter value in DB is 0 then after the succesful run of 1000 requests concurrently it should be 1000.

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

No worries so far I achieved it via database row-level locking, other way could be the use of transaction(with highest isolation) around the code which increment the counter, but what I have observed is though this is achievable to maintain consistency but it comes at the cost of high latency for example I run a Jmeter test with 1000 req/sec for 5 seconds and all requests full-filled in around 26 seconds which is really a huge latency.

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

This now created a lot of questions in my mind -

1. 必须在某些实时方案或应用程序中，这种
   高并发级别以低延迟进行处理，不是吗？

1. There must be some real time scenarios or apps where this level of high concurrency is handled with low latency, isn't there ?

是否总是关系数据库的局限性，可能是
以某种方式解决了非关系nosql数据库吗？

Is it always the limitation with Relational database and could be solved non-relational nosql database in some way ?

在此先感谢
任何帮助表示赞赏。

Thanks in advance, any help appreciated.

推荐答案

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

The "limitation" has nothing to do with databases being "relational" (or not).

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

The essence of your scenario is that you can't begin adding 1 (e.g. to obtain 3) before the previous actor has ended adding 1 to obtain 2, and has fully ended and committed that change. If 2+1=3, you can't start the computation unless and until both of the values on the LHS are available and reliable. So if the 2 is the result of some other action, you won't be able to start until that other action has finished completely.

[有时]被称为车队综合症，它实际上可以在任何技术中发生。

That is [sometimes] called "convoy syndrome" and it can occur in really just any technology.

有 / em> 许多店铺，他们在店铺中做 明显相似 的事情，但具有高度一致性，但是他们要么通过避免任何形式的共享中央资源来实现这一目标导致车队综合症（例如您的柜台），否则他们会通过 牺牲 来实现这一目标，您的必须以1000结束保证。

There are lots of shops where they do apparently similar things with "high conurrency", but either they will achieve it by avoiding any form of shared central resource causing convoy syndrome (such as your counter) or they'll achieve it by sacrificing your "must end up with 1000" guarantee.

这篇关于是否无法处理非常大的并发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！