高并发项目Java是标配？.NET Core要将它拉下“神坛”！

电商的秒杀和抢购，对我们来说，都不是一个陌生的东西。然而，从技术的角度来说，这对于Web系统是一个巨大的考验。当一个Web系统，在一秒钟内收到数以万计甚至更多请求时，系统的优化和稳定至关重要。

缓存技术是项目中最常见的一种应用技术。然而，行业里很多朋友对缓存技术的了解与掌握，仅仅停留在掌握redis等缓存技术的基础使用，最多了解一些集群相关的知识，大部分人都可以对缓存技术掌握到这个程度。然而，仅仅对缓存相关的技术掌握到这种程度，无论是对于开发复杂的高并发系统，或者是在往.NET高级工程师、.NET资深工程师、.NET架构师这些高阶的职位发展的过程中，都是完全不够用的。技术成长出现瓶颈，在自己公司的项目中，没有任何高并发与高可用的挑战性项目，自己不知道如何成长，自己也不知道如何让自己的技术更上一层楼。这成为了很多同学的职业发展的困惑。

一

高并发的处理指标

高并发意味着大流量，需要运用技术手段抵抗流量的冲击，这些手段好比操作流量，能让流量更平稳地被系统所处理，带给用户更好的体验。我们常见的高并发场景有：淘宝的双 11、春运时的抢票、微博大 V 的热点新闻等。

除了这些典型事情，每秒几十万请求的秒杀系统、每天千万级的订单系统、每天亿级日活的信息流系统等，都可以归为高并发。很显然，上面谈到的高并发场景，并发量各不相同，那到底多大并发才算高并发呢？

①不能只看数字，要看具体的业务场景。不能说 10W QPS 的秒杀是高并发，而 1W QPS 的信息流就不是高并发。

信息流场景涉及复杂的推荐模型和各种人工策略，它的业务逻辑可能比秒杀场景复杂 10 倍不止。因此，不在同一个维度，没有任何比较意义。

②业务都是从 0 到 1 做起来的，并发量和 QPS 只是参考指标，最重要的是：在业务量逐渐变成原来的 10 倍、100 倍的过程中，你是否用到了高并发的处理方法去演进你的系统。

从架构设计、编码实现、甚至产品方案等维度去预防和解决高并发引起的问题？而不是一味的升级硬件、加机器做水平扩展。

此外，各个高并发场景的业务特点完全不同：有读多写少的信息流场景、有读多写多的交易场景，那是否有通用的技术方案解决不同场景的高并发问题呢？

我觉得大的思路可以借鉴，别人的方案也可以参考，但是真正落地过程中，细节上还会有无数的坑。

另外，由于软硬件环境、技术栈、以及产品逻辑都没法做到完全一致，这些都会导致同样的业务场景，就算用相同的技术方案也会面临不同的问题，这些坑还得一个个趟。

一

如何提升系统的并发能力

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

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

硬件方向，很好理解，花钱升级机器，更多核更高主频更大存储空间更多带宽。
软件方向，包括用各快的数据结构，改进架构，应用多线程、协程，以及上性能优化各种手段，但这玩意儿天花板低，就像提升个人产出一样，996、007、最多24 X 7。

水平扩展：分布式集群

为了解决分布式系统的复杂性问题，一般会用到架构分层和服务拆分，通过分层做隔离，通过微服务解耦。

这个理论上没有上限，只要做好层次和服务划分，加机器扩容就能满足需求，但实际上并非如此，一方面分布式会增加系统复杂性，另一方面集群规模上去之后，也会引入一堆AIOps、服务发现、服务治理的新问题。

因为垂直向的限制，所以，我们通常更关注水平扩展，高并发系统的实施也主要围绕水平方向展开。

一

.NET Core高可用/高并发实战

很多人面试的时候被问到一个让人特别手足无措的问题：你的系统如何支撑高并发？大多数同学被问到这个问题压根儿没什么思路去回答，不知道从什么地方说起，其实本质就是没经历过一些真正有高并发系统的锤炼罢了。

因为没有过相关的项目经历，所以就没法从真实的自身体会和经验中提炼出一套回答，然后系统地阐述出来自己复杂过的系统如何支撑高并发的。下面给大家准备了为期3天的《.NET Core高可用/高并发实战》专题训练营，10月21日至24日，晚上八点到九点半直播授课，扫码免费学习，全网首发，10天匠心打造，让你三天搞定高可用/高并发实战！