高并发的那些事

640

题图:by thefolkpr0ject from Instagram

阅读文本大概需要 6 分钟。

"高并发"对后台开发同学来说,既熟悉又陌生。熟悉是因为面试和工作经常会提及它。陌生的原由是服务器因高并发导致出现各位问题的情况少之又少。同时,想收获这方面的经验也是"摸着石头过河", 需要大量学习理论知识,再去探索。

如果是客户端开发的同学,字典中是没有“高并发”这个名词。这验证一句老话,"隔行如隔山"。客户端开发,特别是手机应用开发,更多地是考虑如何优化应用的性能,降低 App 的卡顿率等。

本文是一篇科普文,分享自己近来学到的知识。

640

什么是高并发?

由于分布式系统的问世,高并发(High Concurrency)通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲,高并发是指在同一个时间点,有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量,用户高聚集的业务场景中。

其实,高并发也离我们的生活并不遥远,例如大学学校的选课系统。一到选课的时候,一大批学生同时选课,导致系统出现“不良反应”;再如淘宝的 618 和 双 11 的购物活动;遇到节假日,12306 上演的“抢票大战”。另外,DDos 攻击也能算高并发的场景。

640

高并发会来带的后果

  • 服务端:

  • 用户端:

640

提高系统并发能力的方式

在这个“云”的时代,提高分布式系统并发能力的方式,方法论上主要有两种:垂直扩展(Scale Up)水平扩展(Scale Out)

1) 垂直扩展

  • 增强单机硬件性能,例如:增加 CPU 核数如 32 核,升级更好的网卡如万兆,升级更好的硬盘如 SSD,扩充硬盘容量如 2T,扩充系统内存如 128G;

  • 提升单机架构性能,例如:使用 Cache 来减少 I/O 次数,使用异步来增加单服务吞吐量,使用无锁数据结构来减少响应时间;

2) 水平扩展

640

高并发的三个经典问题

  • 单台服务器最大并发

    单台服务器最大并发问题,一般是指一台服务器能够支持多少TCP并发连接.

    一种理论说法是受到端口号范围限制。操作系统上端口号 1024 以下是系统保留的,从 1024-65535 是用户使用的。由于每个TCP连接都要占一个端口号,所以我们最多可以有 60000 多个并发连接。

    但实际上单机并发连接数肯定要受硬件资源(内存、网卡)、网络资源(带宽)的限制。特别是网卡处理数据的能力,它是最大并发的瓶颈。

  • C10K并发连接问题

    C10K并发连接问题是指单机 1 万个并发连接问题。如何突破单机性能局限,是高性能网络编程所必须要直面的问题。这些局限和问题最早被 Dan Kegel 进行了归纳和总结,并首次成系统地分析和提出解决方案,后来这种普遍的网络现象和技术局限都被大家称为 C10K 问题 。

    C10K问题本质上是操作系统的问题。对于 Web1.0/2.0 时代的操作系统而言, 传统的同步阻塞 I/O 模型都是一样的,处理的方式都是 requests per second,并发 10K 和 100 的区别关键在于CPU。

    创建的进程线程多了,数据拷贝频繁(缓存I/O、内核将数据拷贝到用户进程空间、阻塞), 进程/线程上下文切换消耗大, 导致操作系统崩溃,这就是C10K问题的本质!

  • C10M并发连接问题

    回顾了过去的10年里,我们面临高性能网络编程领域著名的C10K问题,最终也成功提出解决方案。下一个10年,是时候考虑C10M并发问题了。

640

Django 与高并发的联系

想弄清楚这个问题,首先要了解下 Django 在服务器中所处的位置。

640

上图中讲到 Django 应用服务器可以分为三层:

  • Web 框架层

  • WSGI 层

  • Web 服务器层

    特别是 Nginx, 它的出现是为了解决 C10K 问题。Nginx 依靠异步事件驱动架构来帮助其处理大量的并发会话,由于其对资源的轻量利用和伸缩自如的特性,它成为了广受欢迎的 web 服务器。

Django 框架注重的数据交互。所以考虑的问题是 Django 适不适合于高并发的场景。

推荐阅读:

Django 学习笔记之初识

中秋佳节,不妨读一本好书

这个 Github 仓库因你而精彩

Python 面试宝典

不积跬步,无以至千里


640

### 百万级高并发系统架构设计与实现方案 #### 高并发系统的必要条件和衡量标准 构建百万级别的高并发系统首先要理解其形成的必要条件。这包括但不限于高效的资源利用、快速响应时间和服务稳定性[^1]。 #### 架构分层策略 对于此类大型项目的架构设计,采用合理的层次结构至关重要。具体来说,在传统的三层架构基础上引入了Manager层,这一新增加的管理层提供了原子性的服务接口;而Service层则专注于根据具体的业务逻辑来组合调用这些基础接口[^2]。 #### 技术选型考量 针对需要部署至特定环境下的应用(如资金管理系统),考虑到兼容性和灵活性的要求,微服务架构成为首选。相较于其他两种主流模式——SOA和服务网格而言,微服务不仅具备高度模块化的特性,而且更易于维护和发展,特别适合那些追求敏捷开发和支持持续交付的企业或机构[^3]。 #### 实践案例分享 以某秒杀平台为例,该项目基于Spring Cloud框架搭建而成,并实现了良好的水平伸缩能力。源码托管于GitHub平台上供开发者参考学习[^4]。 ```java // 示例代码片段展示了一个简单的分布式锁机制用于控制访问频率 public class DistributedLock { private RedisTemplate<String, String> redisTemplate; public boolean tryLock(String lockKey){ return this.redisTemplate.opsForValue().setIfAbsent(lockKey,"locked",10, TimeUnit.SECONDS); } public void unlock(String lockKey){ this.redisTemplate.delete(lockKey); } } ``` #### 性能优化措施 为了确保系统能够在高峰期稳定运行并有效应对突发流量冲击,建议采取如下几项关键技术手段: - **缓存预热**:提前加载热点数据到内存中减少数据库查询压力; - **异步处理**:将耗时操作放入后台队列执行从而加快前端页面渲染速度; - **读写分离**:通过主从复制的方式提高数据库吞吐量; - **CDN加速**:借助内容分发网络降低静态文件传输延迟。 综上所述,成功打造一个可支撑海量用户的在线服务平台并非易,除了科学严谨的整体规划外还需要不断探索创新实践路径。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值