4、用户并发数的计算

什么是并发？

如何来描述并发用户数，用 TPS 来承载“并发”这个概念就可以了。并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。这样描述就够了，别纠结。

在线用户数、并发用户数怎么计算

在线用户数，通过缓存计算

并发用户数 – 并发度

通过这个图，我们可以看到一个简单的计算逻辑：

如果有 10000 个在线用户数，同时并发度是 1%，那显然并发用户数就是 100。

如果每个线程的 20TPS，显然只需要 5 个线程就够了（请注意，这里说的线程指的是压力机的线程数）。

这时对 Server 来说，它处理的就是 100TPS，平均响应时间是 50ms。50ms 就是根据 1000ms/20TPS 得来的（请注意，这里说的平均响应时间会在一个区间内浮动，但只要 TPS 不变，这个平均响应时间就不会变）。

如果我们有两个 Server 线程来处理，那么一个线程就是 50TPS，这个很直接吧。

请大家注意，这里我有一个转换的细节，那就是并发用户数到压力机的并发线程数。这一步，我们通常怎么做呢？就是基准测试的第一步。关于这一点，我们在后续的场景中交待。

而我们通常说的“并发”这个词，依赖 TPS 来承载的时候，指的都是 Server 端的处理能力，并不是压力工具上的并发线程数。在上面的例子中，我们说的并发就是指服务器上 100TPS 的处理能力，而不是指 5 个压力机的并发线程数。请你切记这一点，以免沟通障碍。

所以，我一直在强调一点，这是一个基础的知识：不要在意你用的是什么压力工具，只要在意你服务端的处理能力就可以了。

TPS=(1000ms/响应时间(单位ms))​∗压力机线程数

对于压力工具来说，只要不报错，我们就关心 TPS 和响应时间就可以了，因为 TPS 反应出来的是和服务器对应的处理能力，至少压力线程数是多少，并不关键。

你也许会说，这个我理解了，服务端有多少个线程，就可以支持多少个压力机上的并发线程。但是这取决于 TPS 有多少，如果服务端处理的快，那压力机的并发线程就可以更多一些。

这个逻辑看似很合理，但是通常服务端都是有业务逻辑的，既然有业务逻辑，显然不会比压力机快。应该说，服务端需要更多的线程来处理压力机线程发过来的请求。所以我们用几台压力机就可以压几十台服务端的性能了。

如果在一个微服务的系统中，因为每个服务都只做一件事情，拆分得很细，我们要注意整个系统的容量水位，而不是看某一个服务的能力，这就是拉平整个系统的容量。