打造高并发系统常用的技术

第一章 打造高并发系统常用的技术

---

高并发定义

维基百科对并发的解释

并发性（英语：Concurrency）是在计算机科学中，同一个系统拥有多个计算进程，这些进程有同时执行与的潜在交互特性，因此系统会有相当多个执行路径且结果可能具有不确定性。并发计算可能会在具备多核心的同一个芯片中交错运行，以优先分时线程在同一个处理器中执行，或在不同的处理器执行。

简单讲：许多人干同一件事情，每个人的方法不一样，很可能导致了不同的结果。

举个例子吧，比如张三用干净的抹布擦了一遍桌子，李四也用抹布擦了一遍桌子，我们期望的结果是桌子更干净了，如果李四用的是脏抹布，结果桌子更脏了，这就导致了和期望的不一样。

高性能定义

用两个指标衡量高性能：吞吐量和时延

维基百科对吞吐量的定义

系统吞吐量或汇集吞吐量是指于一网络内单位时间所有终端传递的资料量的总和。

翻译一下就是：每秒钟系统能处理的请求数上限

关于时延：请求从发起计时，记为startTime，到收到请求的响应结束 endTime，enTime-startTime 就是时延。通常单位为ms

一般吞吐量和延时综合起来评估一个系统的能力，如果一味追求吞吐量，会导致用户等待时间较长，用户体验不好，如果一味追求低延时，可能会忽略了系统处理数据量的能力，造成资源浪费。

遇到的挑战

我们遇到的挑战主要来自于我们过去的经验，在过去的经验中我们并没有做过太多高并发的场景，所以在信心方面并不是十足的把握。

还有一个技术难题，如何才能保持数据的一致性？ 我们用强一致性，还是最终一致？
什么场景下该用强一致，什么场景下用最终一致呢？

好在我们通过调研业内的一些方案帮助我们在完成这件事情上有了足够的信心。

支撑高并发常用的技术手段

分布式架构

让流量和任务有多个节点完成，分担流量压力。我们现在企业基本上都是分布式架构，其中微服务盛行。

微服务相比之前的单体，从系统的吞吐能力来说要强大很多，毕竟一个人干活不如一群人干活嘛，但分布式架构也有自己的一些问题，比如运维难度大，以前管一台机器，现在要管一堆机器。
除此之外技术栈也复杂，可能有不同异构组件，那就需要不同的人才。

目前springCloud的全家桶大家普遍用的比较多，能快速搭建出分布式体系，有更好的实践。

Spring Cloud

缓存

缓存主要用于提高性能，降低时延，缓存最大的作用就是提升性能，应用上像秒杀场景。目前最具影响力的缓存当属Redis。

Redis

目前有两大redis客户端，Jedis和Redisson，我推荐用Redisson，性能和功强大很多。

异步

异步将耗时的任务移除主流程，提高系统的并发能力，异步技术中最具代表性的是MQ，常用的MQ 是RocketMq，Kafka，RabbitMq，其中前两个用的最多。
MQ解决了两个问题：一个是流量削峰，另外一个是解耦。

最典型的例子是：
用户想在电商网站购买一部手机，浏览查找自己喜欢的手机，加入购物车，下单支付，填好物流地址，然后配送完成上门送货。
在这个过程中是如何使用异步技术的？
用户下单生成订单数据完成支付，给了物流系统发个消息说，我已经下好订单了，你可以安排物流了。订单系统告诉物流系统这就是一个异步操作。当然你也可以用同步的方式调用。

水平扩展

增加节点数量，分担流量。最常见的方式就是扩容，有自动扩容和手动扩容两种方式。

自动扩容是当流量触发到某个阈值的时候，资源调度系统完成扩容，比如当CPU的使用率超过80%的时候，进行扩容。

手动扩容顾名思义就是人工操作，比如通过告警提示容量不足，这个时候运维同学回去手动扩容。

现在最流行的扩容技术就是k8s，非常方便，各大云厂商都提供该功能。

顺便说一下K8s还是值得研究的，因为非常方便解决了服务调度问题和编排问题，让服务部署效率提升了一个量级。这样的技术值得人尊重，致敬一下google。

Kubernetes

限流

限流是对系统保护，防止系统被打垮。

为什么要进行限流呢？

肯定是不希望流量把系统打垮呀，这是一种自我保护机制。这就像我今天只工作8个小时，超过8个小时了，我就不干了。
老板非让我工作10个小时，工作到第9个小时的时候，我只慢慢干了，要不我就会被压垮的。

常用的限流组件有：Redis limiter，sentinel
在我们的项目中我们使用的是alibaba 的sentinel

GitHub - alibaba/Sentinel: A powerful flow control component enabling reliability, resilience and monitoring for microservices. (面向云原生微服务的高可用流控防护组件)

总结

我们该如何使用这些技，这就要根据我们的业务场景了，不是有一句话说了嘛，脱离业务场景做技术选择都是耍流氓，你还真别说，现在耍流氓的人很多。