摘要：并发数多少才算高并发经常被问到，下面我就重点详解并发数多少才算高并发，以及高并发解决方案@mikechen
并发数多少才算高并发经常被问到，下面我就重点详解并发数多少才算高并发，以及高并发解决方案@mikechen
本文作者：陈睿|mikechen
文章来源：mikechen.cc
高并发，通常指的是系统能够同时处理大量请求的能力，在现代互联网应用中，尤其是在电商、金融、社交媒体和流媒体服务等场景中。
高并发是常见的挑战，“阿里双11”每秒几十万的订单处理，就是最典型的高并发场景。
多少算高并发
一般来说，可以根据以下几个范围来划分：
低并发：少于 100 并发连接的场景。中等并发：大约 100 到 1000 并发连接。高并发：1000 到 10000 并发连接。超高并发：超过 10000 并发连接。极端高并发：超越 百万级并发（如大规模社交平台、电商平台等）。对于大多数企业和互联网服务平台，上万到数百万的并发，才是他们需要解决的实际问题。
如何来解决这样的高并发场景呢？
这类系统往往依赖于复杂的架构，如：多级缓存、负载均衡、数据库分库分表、消息队列...等来解决。
负载均衡
负载均衡，也是高并发的常见手段，使用分布式负载均衡器，如 ：Nginx、HAProxy、LVS...等等。
将请求分发到多个服务器，以提高系统处理能力、和负载均衡，支持动态扩展、和自动故障转移。
常见的负载均衡算法包括：
轮询： 依次将请求，分配给后端服务器。随机： 随机选择，后端服务器。加权轮询： 根据服务器性能分配权重。最小连接： 将请求，分配给连接数最少的服务器。IP哈希： 根据客户端IP地址进行哈希，将固定客户端的请求分发到同一台服务器。分库分表
在高并发场景下，数据库的读写负载可能导致性能瓶颈，尤其是对 关系型数据库（如 MySQL、PostgreSQL）而言。
将数据库进行拆分，避免单一数据库成为瓶颈，这也是常见的手段。
水平分库分表是最常见的分库分表方式，按数据的某个字段（例如用户 ID、订单 ID 等）进行拆分。
比如：根据 user_id 的哈希值，来决定数据存储在哪个表。
CREATE TABLE orders_0 ( ... );CREATE TABLE orders_1 ( ... );CREATE TABLE orders_2 ( ... );通过 user_id % 3 ，来决定将某个用户的订单存储到哪个表中。
应用层代码实现分库分表时，可以使用 Java 的 Sharding JDBC 。。。等等。
@Configuration@EnableShardingpublic class ShardingConfig {@Beanpublic ShardingDataSource shardingDataSource {// 配置数据源和分库分表规则// 示例：根据用户 ID 对数据进行哈希路由}}这些框架提供了分库分表的路由、分片规则配置、事务支持等功能。
数据库优化
避免使用复杂的 JOIN，尤其是多表联接时，要避免全表扫描，可以通过分解查询或使用合适的索引来优化。
避免子查询，用连接查询替代子查询，因为子查询在执行时会影响性能。
使用 批量插入 和 批量更新，避免频繁的单条记录操作。
以及，使用 Redis 或 Memcached ...等等缓存，将频繁查询的数据，避免数据库的高并发读请求。
消息中间件
在高并发环境下，使用消息队列可以有效地平滑流量，并避免短时间内请求过多导致系统崩溃。
例如，电商网站的支付系统，当高并发请求涌入时，直接将支付请求发送到消息队列，支付系统根据消费的消息来逐步处理支付请求。
使用 消息队列（如 Kafka、RocketMQ。。。等等），来解耦高并发请求，平滑流量高峰。
消息队列作为缓冲区，可以平滑流量高峰，减少系统因为瞬时高并发请求造成的压力。
例如，假设每秒钟需要处理 1000 个请求，但由于瞬时流量激增，系统只能处理 200 个请求。
如果将流量传入消息队列，系统就可以逐步从队列中消费消息，并控制每秒处理的请求数量，避免系统超载。
当系统负载过高时，为了保护系统稳定性，需要采取一些措施来限制请求并发数、或降级非核心功能。
限流
通过算法控制系统处理请求的速率，防止系统被过多的请求压垮。
降级
在系统负载过高时，暂时关闭、或降低非核心功能的优先级，将系统资源集中到核心功能上。
这些都是高并发系统中常用的优化手段，可以有效提高系统的性能、稳定性、和可用性。
本文作者：陈睿|mikechen
文章来源：mikechen.cc
来源：汽车娱乐生活咖
