说到并发，期英文单词为Conurrent,如果要彻底理解并发，那么还需知道一个词就是并行，英文单词Parallel。 那么二者有什么关系呢？Erlang 之父 Joe Armstrong用如下图来解释了并发与并行的区别：
并发是两个队列交替使用一台咖啡机，而并行则是两个队列同时使用两台咖啡机。再用一个例子来解释：
从上面的例子可以看出来，并发的关键就是需要能同时处理多个任务的能力，这个不一定是同时进行的。并行则关键是要能同时处理多个任务。二者的关键区别在于是否具备同时性。 这也很好的能在计算机上进行理解，在早期只有单核CPU的计算机上，随着系统CPU的时间片调度，系统可以支持并发和串行。而在目前多处理器的多核系统中，系统除支持并发与串行之外，还支持并行。
高并发（Hight Concurrnet）,从字面上来理解就是让单位时间同时处理任务的能力尽可能的高。对应到我们研发系统中，也就是说： 我们所开发的系统，要在短时间能能支持大量访问请求的情况。这种情况比如双十一活动，或者12306的抢票、以及秒杀等活动。 这要求我们的业务系统，在短时间内，尽可能多的接收来自客户端的请求，并做出准确的响应。
实际上，从另外一个角度考虑，我们所说的高并发，并行已经是其一个子集。毕竟，单个CPU或者单个系统节点的处理能力有限，而且成本昂贵， 我们需要通过多个节点，采用可扩展的方式，来实现支撑尽可能高的并发能力。而水平扩展的能力，实际上从另外一个角度来说，并行是提升系统并发能力的重要手段。
那么，既然是高并发，那么多高才算高呢？为了更好的对系统的高并发性进行评价，需要对如下指标进行了解：
重要参数如下：
QPS(TPS) = 并发数/平均响应时间
此外还有些相关的指标也需要了解：
上述指标内容，主要是反映了高并发系统在高性能上的要求。做为高并发系统，需要实现的目标为：
系统的性能，与系统资源的关系息息相关。如果要提升系统的性能，首先我们就得对系统的资源进行规划和确认，主要考虑如下几个方面：
3.1.1 网络
通常情况下，网络因素是导致用户体验变差的首要因素。我们需要考虑如下性能指标：
通常情况下，带宽与物理设备相关，这也决定了基础网络设施的投入资金。这需要对系统的带宽进行预测，结合资金的投入来综合考虑。
此外，DNS也是一个重要的因素，DNS 是互联网中最基础的一项服务，提供了域名和 IP 地址间映射关系的查询服务。很多应用程序在最初开发时，并没考虑 DNS 解析的问题，后续出现问题后，排查好几天才能发现，其实是 DNS 解析慢导致的。 我们需要考虑对DNS进行优化。比如缓存等。 CDN CDN主要是对于web网页系统资源优化的重要手段，我们可以考虑将静态的图片或者视频之类，存放到CDN系统。
TCP优化，结合业务的场景，设置合适的TCP参数，TIME_WAIT，考虑SYN FLOOD并优化与 SYN 状态相关的内核选项。是否根据长连接需要KeepAlive开启。以及TCP缓冲区的大小设置等。
应用程序中，我们需要考虑的是优化 I/O 模型、工作模型以及应用层的网络协议； Socket中需要考虑socket的缓冲区大小。
3.1.2 CPU
CPU是决定单节点系统并发能力的核心，除了结合资金尽可能的选择匹配业务的高性能CPU之外，我们还要关注如下CPU相关的指标：
3.1.3 内存
内存的性能指标主要关注的是，已用内存、剩余内存、共享内存、可用内存、缓存和缓冲区的用量等。
其次是进程内存使用情况，比如进程的虚拟内存、常驻内存、共享内存以及 Swap 内存等。 内存需要特别关注的是系统的缺页异常：
对于SWAP,重点要关注SWAP空间的使用情况，由于SWAP空间实际上是磁盘空间，最好是避免使用SWAP。
3.1.3.4 IO
文件系统的IO指标： 首先要关注的是存储空间的使用情况，包括容量、使用量以及剩余空间等。
其次要关注的是，索引节点的使用情况，它也包括容量、使用量以及剩余量等三个指标。如果文件系统中存储过多的小文件，就可能碰到索引节点容量已满的问题。
对于IO方面，对于应用程序的优化，主要有：
对于文件系统：
对于物理磁盘的优化：
系统可用性是衡量一个系统正确地对外提供服务（可工作）的能力。我们通常采用 SLA（Service Level Agreement）来衡量系统可用性，也就是我们经常听到的的几个 9。 影响系统可用性的因素有：
影响系统可用性的因素很多，通常有很多因素是我们不可控的，如硬件故障或者基础设施等。 我们主要可以通过提高工程化能力和优化工作流程解决。
在系统上线之前：
在系统上线后的日常运营中：
为了进一步降低故障的产生，我们还需要有针对的做一些预案管理：
最重要的是，需要提升团队的综合素质。重视日常的管理工作。而不仅仅是代码。制定规则并遵守。
为了保障系统的可扩展性，这就要求我们对系统的设计是可扩展的。一开始就需要考虑可扩展的架构。 要做到系统的高可扩展性，架构设计的核心就是 冗余。有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现。这也就是我们常说的load blance 和fail over.
常用的可扩展架构：
通过常用的高可用冗余设计来实现系统的高扩展性。从而应对系统的高并发。让系统具备弹性。可以根据业务需要来扩容或者缩容。
最后需要考虑的是系统的安全性问题，如https协议。系统关键数据的加密算法，关键功能的双因素认证等。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/8305.html