常见软件并发量与对应架构

指标

网络指标

流量

流量=每s读写数量 = 活跃用户 * 读写比例

带宽

带宽=每s流量 = 流量 * 请求对象大小

压测指标

PV（Page View）页面访问量

页面被浏览的次数，每次用户访问或者刷新页面都会被计算在内。

RT（Response-time）响应时间

直接反应了系统的快慢

一个请求从开始到最后收到响应数据所花费的总体时间
响应时间一般 = CPU执行时间 = 线程等待时间（IO等待，sleep, wait）时间

QPS（Queries Per Second）每秒查询

体现系统在规定时间内所能处理多少流量

• 通过PV 预估 峰值QPS，二八原则
  峰值时间每秒请求数(QPS) = ( 总PV数 * 80% ) / ( 每天秒数 * 20% )

• 通过RT 计算 单线程QPS
  QPS = 1s / RT

RPS（Requests Per Second ）吞吐量

体现系统处理请求的能力

等效于QPS
单位时间内系统能处理的请求数量，单位是 reqs/s

TPS（Transactions Per Second）每秒事务

事物数/秒

并发数（The number of concurrent connections）

系统的负载能力

并发量 = QPS * 平均响应时间

最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量

---

操作系统限制

Windows

每个进程中的线程数不允许超过 2000

Linux

每个进程中的线程数不允许超过 1000

软件限制

注意：

软件并发量，由于具体环境，业务的不同，差异很大

• 以下只是从软件默认配置、官方推荐、官方压测数据 等渠道估算的大概值
• 遇到实际场景还得自己压测

java

1. Java中每开启一个线程需要耗用1MB的JVM内存空间用于作为线程栈之用
2. 分配给 JVM 的内存越多性能也就越高，但也会加重 GC 的负担。

tomcat

• 默认是BIO（默认配置的最大请求数是 150），可配置

• APR 模式（默认值是 8192）

• NIO 模式（默认值是 1w）

• 实际单机并发量在 几百~几千，具体受到硬件配置与应用程序性能的影响

Nginx

• Nginx并发数 2w 官网是5w
• 单机ng并发数 从 几千~数万
  经过优化的话，则可以稳定地达到 10w 次/秒 的处理性能。

Netty

数万到数百万的并发连接。
根据官方文档，Netty 可以支持每秒数百万次的消息传输，具体取决于硬件配置和网络环境等因素

MySQL

单台服务器只能承载2000万数据

主键查询： 千万级别数据 >> 1-10 ms
唯一索引查询： 千万级别数据 >> 10-100 ms
非唯一索引查询： 千万级别数据 >> 100-1000ms
无索引数据： 百万级别数据 >> 1000ms+
插入操作： 1w~10w tps

• 单机mysql读写并发 几十到几百 并发连接【连接池】
• 单独读并发 的能力可以达到几千个并发连接，甚至更高
• 单独写并发 的能力通常在几百个并发连接左右

综上：

• 单机QPS 在 几千左右会到一个小瓶颈，cpu应该已经到80%左右了
• 8核16G在2000左右，16核32G 到 3000 左右。具体考虑sql复杂程度，表设计

redis

单机 QPS 可以达到 8w+

---

单机应用何时进行集群

某个应用拥有250 个以上并发的时候，应考虑应用服务器的集群。
具体能承载多少并发，需要看硬件的配置，CPU 越多性能越高，

---

各个并发量级别的 性能瓶颈 与 架构方案

qps 100

这一步一台正常的电脑，用常见的软件都能支持，没什么可探讨的

单服务器，单应用，单数据库

qps 1000

单机软件性能达到上限（如tomcat一般不超过500）
单机数据库瓶颈

• 搭建tomcat集群，用Nginx 在应用层负载均衡
  tomcat节点超过5个左右的话. 集群的session复制广播导致占用带宽，服务能力先增加后下降

• 本地缓存/分布式缓存
  通过缓存获取查询热点数据，减小数据库压力

• 数据库 读写分离

qps 1w

集群的session共享瓶颈
不同业务直接竞争数据库，相互影响性能
单机的 写库 达到性能瓶颈

• 分布式缓存
  将session服务化，解决session复制问题

• 分布式架构
  按照功能点把系统拆分，拆分成独立子系统，为子系统配置集群（加服务器，不用配置session共享）。

• 数据库
  分布式数据库
  分库分表，大表拆小表

qps 10w

单机Nginx会成为瓶颈

• 搭建Nginx集群，用LVS/F5 传输层负载均衡

qps 1000w

此时用户肯定会分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同
用户与机房的传输距离成为瓶颈

• 通过DNS，实现机房间的负载均衡
  用户 就近/轮询 访问不同的机房，机房间同步信息
  系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决

其他需求

2020年最高能达到亿级并发上限，目前市场好像没有更高的需求，期待接下来的发展，
但是 还有其他的需求未满足

1. 大数据，人工智能等应用 需要检索分析大量数据，会产生特别复杂的查询、海量文件存储、全文检索、可变数据结构等需求， 只用数据库做会很麻烦
   • NoSQL数据库
   • 搜索引擎ElasticSearch
   • 分布式文件系统HDFS
2. 业务做大、做广了之后，一个应用中包含了太多的业务代码，业务的升级迭代变得困难
   • 按照业务板块来划分应用代码，做成独立的微服务
3. 服务准备运行环境，部署，运维复杂
   • 容器化技术 打包应用/服务 Docker，Kubernetes

案例：淘宝从几百到千万级并发的十四次架构演进之路！

https://www.cnblogs.com/xiaobug/p/11039259.html

---

单机的并发上限

http://www.52im.net/thread-561-1-1.html

C10K问题 (单机1w并发)

一台机器无法创建很多进程。如果是C10K就要创建1万个进程，那么单机而言操作系统是无法承受的（往往出现效率低下甚至完全瘫痪）。

如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook、Google、雅虎等巨头才有财力购买如此多的服务器。

• 过去的10年里，高性能网络编程技术领域里经过众多开发者的努力，已很好地解决了C10K问题

C10M问题 (单机1000w并发)

• 目前大佬们正在研究的问题

1千万的并发连接数；
100万个连接/秒：每个连接以这个速率持续约10秒；
10GB/秒的连接：快速连接到互联网；
1千万个数据包/秒：据估计目前的服务器每秒处理50K数据包，以后会更多；
10微秒的延迟：可扩展服务器也许可以处理这个规模（但延迟可能会飙升）；
10微秒的抖动：限制最大延迟；
并发10核技术：软件应支持更多核的服务器（通常情况下，软件能轻松扩展到四核，服务器可以扩展到更多核，因此需要重写软件，以支持更多核的服务器）。