聊聊高并发

高并发,几乎是每个程序员都想拥有的经验。原因很简单:随着流量变大,会遇到各种各样的技术问题,比如接口响应超时、CPU load 升高、GC 频繁、死锁、大数据量存储等等,这些问题能推动我们在技术深度上不断精进。

什么是高并发 ?

高并发 (High Concurrency): 高并发意味着大流量,需要运用技术手段抵抗流量的冲击,这些手段好比操作流量,能让流量更平稳地被系统所处理,带给用户更好的体验。

我们常见的高并发场景有:淘宝的双11、春运时的抢票、微博大V的热点新闻等。除了这些典型事情,每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等,都可以归为高并发。

高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等

那到底多大并发才算高并发呢 ?

  1. 不能只看数字,要看具体的业务场景.不能说 10W QPS 的秒杀是高并发,而 1W QPS 的信息流就不是高并发。信息流场景涉及复杂的推荐模型和各种人工策略,它的业务逻辑可能比秒杀场景复杂 10 倍不止。因此,不在同一个维度,没有任何比较意义。

  2. 业务都是从 0 到 1 做起来的,并发量和 QPS 只是参考指标,最重要的是:在业务量逐渐变成原来的 10 倍、100 倍的过程中,你是否用到了高并发的处理方法去严谨你的系统,从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题?

如何提升系统的并发能力 ?

互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展(Scale Up)与水平扩展(Scale Out)。

垂直扩展

  • 垂直扩展:提升单机处理能力。垂直扩展的方式又有两种:
      1. 增强单机硬件性能,例如:增加CPU核数如32核,升级更好的网卡如万兆,升级更好的硬盘如SSD,扩充硬盘容量如2T,扩充系统内存如128G;
      1. 提升单机架构性能,例如:使用Cache来减少IO次数,使用异步来增加单服务吞吐量,使用无锁数据结构来减少响应时间;

水平扩展

  • 水平扩展:只要增加服务器数量,就能线性扩充系统性能。

实践方案

高性能的实践方案

  1. 集群部署, 通过负载均衡减轻单机压力
  2. 多级缓存, 包括静态数据使用CDN,本地缓存,分布式缓存等, 以及对缓存场景中的热点 key、缓存穿透、缓存并发、数据一致性等问题的处理。
  3. 分库分表和索引优化, 以及借助搜索引擎解决复杂查询问题
  4. 考虑 NoSQL 数据库的使用,比如 HBase、TiDB 等,但是团队必须熟悉这些组件,且有较强的运维能力。
  5. 异步化, 将次要流程通过多线程, MQ, 甚至延迟任务进行异步处理
  6. 限流, 需要先考虑业务是否允许限流,比如秒杀场景是允许的),包括前端限流、Nginx 接入层的限流、服务端的限流。
  7. 对流量进行削峰填谷,通过 MQ 承接流量。
  8. 并发处理,通过多线程将串行逻辑并行化
  9. 预计算,比如抢红包场景,可以提前计算好红包金额缓存起来,发红包时直接使用即可。
  10. 缓存预热,通过异步任务提前预热数据到本地缓存或者分布式缓存中。
  11. 减少 IO 次数,比如数据库和缓存的批量读写、RPC 的批量接口支持、或者通过冗余数据的方式干掉 RPC 调用。
  12. 减少 IO 时的数据包大小,包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存 key 的大小、压缩缓存 value 等。
  13. 程序逻辑优化,比如将大概率阻断执行流程的判断逻辑前置、For 循环的计算逻辑优化,或者采用更高效的算法。
  14. 各种池化技术的使用和池大小的设置,包括 HTTP 请求池、线程池(考虑 CPU 密集型还是 IO 密集型设置核心参数)、数据库和 Redis 连接池等。
  15. JVM 优化,包括新生代和老年代的大小、GC 算法的选择等,尽可能减少 GC 频率和耗时。
  16. 锁选择,读多写少的场景用乐观锁,或者考虑通过分段锁的方式减少锁冲突。

高可用的实践方案

  1. 对等节点的故障转移,Nginx 和服务治理框架均支持一个节点失败后访问另一个节点。
  2. 非对等节点的故障转移,通过心跳检测并实施主备切换(比如 redis 的哨兵模式或者集群模式、MySQL 的主从切换等)。
  3. 接口层面的超时设置、重试策略和幂等设计。
  4. 降级处理:保证核心服务,牺牲非核心服务,必要时进行熔断;或者核心链路出问题时,有备选链路。
  5. 限流处理:对超过系统处理能力的请求直接拒绝或者返回错误码。
  6. MQ 场景的消息可靠性保证,包括 producer 端的重试机制、broker 侧的持久化、consumer 端的 ack 机制等
  7. 灰度发布,能支持按机器维度进行小流量部署,观察系统日志和业务指标,等运行平稳后再推全量。
  8. 监控报警:全方位的监控体系,包括最基础的 CPU、内存、磁盘、网络的监控,以及 Web 服务器、JVM、数据库、各类中间件的监控和业务指标的监控。
  9. 灾备演练:类似当前的“混沌工程”,对系统进行一些破坏性手段,观察局部故障是否会引起可用性问题。

高扩展的实践方案

  1. 合理的分层架构:比如上面谈到的互联网最常见的分层架构,另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层(但是需要评估性能,会存在网络多一跳的情况)。
  2. 存储层的拆分:按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分(分库分表)。
  3. 业务层的拆分:最常见的是按照业务维度拆(比如电商场景的商品服务、订单服务等),也可以按照核心接口和非核心接口拆,还可以按照请求去拆(比如 To C 和 To B,APP 和 H5)。

Powered by Hexo and Hexo-theme-hiker

Copyright © 2017 - 2021 Keep It Simple And Stupid All Rights Reserved.

访客数 : | 访问量 :