大数据高并发的话题屡见不鲜，各种应对的方式方法也四处可见。然而笔试面试中一问就懵，简直是高薪拦路虎。为什么呢？究其原因，还是思路不清晰，缺乏实操，所以一问就倒。作为专注.Net领域十几年的老司机，我今天就来给大家好好谈谈这个话题，将两个问题全部解决掉！
任何项目在一开始架构时，都不是冲着大数据高并发去的。然而随着时间的推移，用户量的增加，数据规模上去，请求的并发量高了，就会出现资源不足、请求阻塞、异常报错、甚至服务器崩溃的问题。怎么解决呢？无非两个思路，一曰扬汤止沸，一曰釜底抽薪。
扬汤止沸
所谓扬汤止沸，意思是把锅里开着的水舀起来再倒回去，使它凉下来不沸腾。比喻办法不彻底，不能从根本上解决问题。在遇到大数据高并发问题时，治标不治本也是很重要的。下面给大家罗列一些方法。
1
硬件升级，最直接有效省事儿，然而这招有上限，硬件资源不可能无限制增加，有钱也买不到。不过在很多时候确实很好用。
2
异步化架构，常规做法是用异步队列做为任务转发介质，将即时请求转化成任务信息，写入队列，后端用处理器从队列中获取任务并处理，时间换空间，能有效应对流量高峰。
3
代码优化，启用多线程、资源复用、优秀数据结构与算法、数据库索引、Sql优化、css/js/图片请求合并和启用压缩、减少cookie传输等都是常见手段，能解决客观问题。
4
专项突破，使用特定技术来解决特定问题，比如用EleasicSearch来解决搜索问题，用Redis的原子特性解决超卖问题，用MongoDB解决大量数据写入和复杂查找性能问题等。
釜底抽薪
釜底抽薪——把柴火从锅底抽掉，才能使水止沸。比喻从根本上解决问题。大数据高并发的问题是伴随着数据和并发量而发展的，要根本上解决，目前是做不到的。但是确实有很多方法，是从根基上去解决问题的。
1、集群化
集群化，一个人搬不动大石头，最现实的办法不是换个大力士，而是找更多的人来一起搬。所谓集群，就是用多台服务器共同承载以前一台服务器做的事儿，而且能支持后续增加更多的服务器。从理想化的角度来说，这种水平扩展模式的处理能力是无限的，当然在实施的过程中也会遇到种种问题，文章后面再解决。
2、缓存
缓存，数据结果存储起来重用，用空间换性能。在一个大型Web系统里面，缓存是无处不在的。从客户端缓存，到CDN缓存，到反向代理缓存，到本地缓存，到分布式缓存，甚至数据库自身、操作系统的CPU都是有缓存的。缓存在不同的环节，可以直接拦截掉不同层次的请求，不仅能加快响应速度，也能直接降低压力。
3、读写分离
读写分离，分库分表，能将单一数据库服务器的压力分摊到更多的服务器上，以提升数据库的承载能力。数据库一直是系统的瓶颈，一方面利用数据库自身的主从复制功能，另一方面从程序设计去分库分表，虽然会增加开发和管理的复杂度，但是为了解决压力，还是需要积极应用的。
4、分布式
分布式，这是大型系统演化的终极方案，将一个计算任务，分解到多个计算机协作完成。这种方式处理能力可以持续提升，但也要付出分布式管理的代价。时至今日，分布式架构已经比较成熟，演化出来的微服务架构已成为当下的主流架构模式，后文还有详实案例去解读。
实践为王
无论是扬汤止沸，还是釜底抽薪，方案人尽皆知，更重要的是能落地实操。“面试造航母，工作拧螺丝”已成为当下跳槽季的现状。面试中频频被问到大数据高并发，但是日常开发确实又遇不到，甚是苦恼。网上找一些零碎的帖子看了，却又很难动手实操，面试问起来根本顶不住。下面，容我来为大家推荐一个大数据高并发专题课程，不仅全面覆盖核心处理套路，更重要的全部实操落地，学完能自己动手练习的。
学习计划：
Day1
集群负载均衡，Asp.Net Core3.1搭建集群，通过Nignx完成负载均衡，多均衡策略实操演练，基于Redis完成分布式Session共享，解决持久化问题。
Day2
数据库读写分离实操配置，EntityFrameworkCore读写分离访问封装，解读分库分表表分区，搞定头疼的数据库瓶颈。
Day3
缓存Cache深度应用，Asp.Net Core内置MemoryCache，基于Redis分布式缓存，Nginx反向代理缓存，全部落地实操。
Day4
解读异步化架构设计和优劣，基于RabbitMQ+处理器集群现场演练并发任务分发和异步化削峰效应
Day5
分布式系统架构演化，基于微服务全套环境演练分布式系统，理解分布式系统下的Base理论，从开发走向架构。