不一定每个场景都会产生高并发，不要为了高并发而盲目的设计，过度设计带来 的问题远比猜想之外的高并发要多很多，依赖于详细场景和行为进行剖析，一个 购物类网站，抢购场景，会触发很多的读取商品详情，打算库存等操作，而且不 须要每个要求都到达支付页面，也不会在网站主页带来很多的要求，以是须要针 对抢购场景进行优化，而不是巨大的支付流程进行优化，当然商品数量多和用户 多的情形，才须要也优化一下支付流程。
抛开场景，不谈流量的盲目高并发设计，一样平常是过度设计，未来掩护臃肿而复 杂的代码会惩罚你当初的过度设计。
突如其来的高并发
基本是被人刷了，或者比预估的情形要多了几倍，才有这种情形，前者可能性很 大，最近这两年的金融网站，区块链，xx 币网站，基本会被羊毛党盯上，没做 好访问防作弊，或者被对手 ddos 攻击，都会造成高并发中网站瘫痪，洗濯流 量一样平常就可以的，不要让辣鸡流量贯穿全体业务。高并发会带来网站要求慢，但 网站要求慢不一定是高并发了，对症下药。
如果是网红带货什么的，给网站带来高并发了，这种情形下可以在提前流量上做 些手脚，例如：1. 用行列步队排队流量，例如猴王网站的抢购 2. 采取一些高 端点的验证码，让一些秒杀抢购的机器号被过滤出去，只管即便不影响真实用户的 抢购结果 3. 分层过滤，例如静态资源放在 CDN 上，NGINX 层面利用自身的 缓存，根据路由缓存根本数据，其他动态数据再读写数据库，而不是每个要求 都经由整体的业务，这样带来的压力太大了，而且也不值得。
并发中的整体项目稳定性
可以将高并发的业务部分分离到单独的做事器。这种情形下能够避免这部分业务 带来机器性能的花费，从而影响全体项目的稳定性，这样的结果不太好的。也可 以预先将热数据放到缓存中，提高读写效率，也能让 MySQL 比较稳定，一样平常 情形下能有高并发的网站，数据量也不少，举例某个电商网站，可能有 100w 商 品数据，但大家抢购的是本日热推的 10 个商品，将这十个数据提取放到缓存 中，而不是每次去数据库中查询，当然 MySQL 设置合理的话，自身的 buffer pool 也能搞定这些热数据缓存。这样相称于将这 10 条数据隔离出来，而不是影响到整体数据。关于热点数据的创造，还有一些高真个是从 NGINX 访问日 志层面实时剖析，听说淘宝这种是这样的，实时创造访问很多的路由，剖析路由 获取到对应的商品数据，放到缓存中，减轻做事器压力。
稳定性不只存在于业务机器层面，也可能是网络宽带不足，或者程序在磁盘写日 志的时候碰着瓶颈，或者内存不足，导致可用缓存空间很小。这些在测试和打算 层面须要把稳的问题，也会影响整体稳定性和性能的，该当提前办理。例如秒杀 系统须要关注 CPU，并发读须要关注缓存，静态资源多的也须要考虑宽带。
预先测试
大略可以是压测关键业务部分，大略的查询一样平常不会带来问题，这个页面的静态 资源太多，同时都在统一个域名下的话，相称于在现有并发的数量上加了更多， 这非常不利，对付浏览器的加载也是不利的，大略业务也会体验很差。压力测试 应该遵照逐步提升流量的办法，并发量和相应韶光并不是等比例上涨的，逐步 提升并发量的测试，会展示代码的瓶颈部分在哪，然后在去办理和提升。测试也 可以
在根本的并发测试之外，还有在正是做事器上的全链路压力测试，为了防止和真 实数据冲突，可以将要求中加上额外的标记，或者针对特定的用户帐号测试，在 数据中表示这部分额外标记，测试完毕之后将数据删除。
同时，不要高并发的紧张业务一贯占用机器的 100% 的运算能力，这样整体逻 辑和要求支持已经到了极限，基本再高一点就会造成问题，该当只管即便让业务只占 用机器 60-70% 的运算能力，留出一部分的余地，防止意外。
安全及备用方案
1. 从 NGINX 层面限定单个 IP 单位韶光内要求频率和次数，屏蔽掉机器刷 的可能性，从而不影响正常访问。 2. 牢记高并发 + 高可用不可以用单 点系统，例如不能由于热数据少而就用一台 Redis 做事器，或者更狠的 直接本机缓存，一旦系统崩溃，相称于触发连锁反应，连保存现场和规复 都很难。 3. 提前设计兜底方案 ① 降级，例如商品详情页面不展示推举 商品，或者减少推举商品展示数量等， ② 限流，不让更多流量涌入，能 减少很多压力 ③ 过载临界点谢绝做事，这个是最坏的情形，直接阻断压 垮系统的末了一个流量。
2.口试官为什么会问你，如何设计一个高并发系统？口试官生理剖析
说实话，如果口试官问你这个题目，那么你必须要使出全身吃奶劲了。为啥？因 为你没看到现在很多公司招聘的 JD 里都是说啥，有高并发就履历者优先。
如果你确实有真才实学，在互联网公司里干过高并发系统，那你确实拿 offer 基 本如探囊取物，没啥问题。口试官也绝对不会这样来问你，否则他便是蠢。
假设你在某有名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期 并发量上万，乃至是十万。那么人家一定会仔细盘考你的系统架构，你们系统啥 架构？怎么支配的？支配了多少台机器？缓存咋用的？MQ 咋用的？数据库咋 用的？便是深挖你到底是如何扛住高并发的。
由于真正干过高并发的人一定知道，分开了业务的系统架构都是在纸上谈兵，真 正在繁芜业务场景而且还高并发的时候，那系统架构一定不是那么大略的，用个 redis，用 mq 就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这 种大略的所谓“高并发架构”要繁芜很多倍。
如果有口试官问你个问题说，如何设计一个高并发系统？那么不好意思，一定是 由于你实际上没干过高并发系统。口试官看你简历就没啥出彩的，觉得就不咋地， 以是就会问问你，如何设计一个高并发系统？实在说白了实质便是看看你有没有 自己研究过，有没有一定的知识积累。
最好确当然是招聘个真正干过高并发的哥儿们咯，但是这种哥儿们人数稀缺，不 好招。以是可能次一点的便是招一个自己研究过的哥儿们，总比招一个啥也不会 的哥儿们好吧！
以是这个时候你必须得做一把个人秀了，秀出你所有关于高并发的知识！
口试题阐发
实在所谓的高并发，如果你要理解这个问题呢，实在就得从高并发的根源出发， 为啥会有高并发？为啥高并发就很牛逼？
我说的浅近一点，很大略，便是由于刚开始系统都是连接数据库的，但是要知道 数据库支撑到每秒并发两三千的时候，基本就快完了。以是才有说，很多公司， 刚开始干的时候，技能比较 low，结果业务发展太快，有的时候系统扛不住压力 就挂了。
当然会挂了，凭什么不挂？你数据库如果瞬间承载每秒 5000/8000，乃至上万 的并发，一定会宕机，由于比如 mysql 就压根儿扛不住这么高的并发量。
所以为啥高并发牛逼？便是由于现在用互联网的人越来越多，很多 app、网站、 系统承载的都是高并发要求，可能高峰期每秒并发量几千，很正常的。如果是什 么双十一之类的，每秒并发几万几十万都有可能。
那么如此之高的并发量，加上原来就如此之繁芜的业务，咋玩儿？真正厉害的， 一定是在繁芜业务系统里玩儿过高并发架构的人，但是你没有，那么我给你说一 下你该怎么回答这个问题：
可以分为以下 6 点：
系统拆分 缓存MQ分库分表读写分离ElasticSearch
系统拆分
将一个别系拆分为多个子系统，用 dubbo 来搞。然后每个别系连一个数据库， 这样本来就一个库，现在多个数据库，不也可以扛高并发么。
缓存
缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完备可以在数 据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家 redis 轻 轻松松单机几万的并发。以是你可以考虑考虑你的项目里，那些承载紧张要求的 读场景，怎么用缓存来抗高并发。
MQ
MQ，必须得用 MQ。可能你还是会涌现高并发写的场景，比如说一个业务操作 里要频繁搞数据库几十次，增编削增编削，疯了。那高并发绝对搞挂你的系统， 你假如用 redis 来承载写那肯定弗成，人家是缓存，数据随时就被 LRU 了，数 据格式还无比大略，没有事务支持。以是该用 mysql 还得用 mysql 啊。那你 咋办？用 MQ 吧，大量的写要求注意灌输 MQ 里，排队逐步玩儿，后边系统消费 后逐步写，掌握在 mysql 承载范围之内。以是你得考虑考虑你的项目里，那些 承载繁芜写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。MQ 单机 抗几万并发也是 ok 的，这个之前还特意说过。
分库分表
分库分表，可能到了末了数据库层面还是免不了抗高并发的哀求，好吧，那么就 将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个 表，每个表的数据量保持少一点，提高 sql 跑的性能。
读写分离
读写分离，这个便是说大部分时候数据库可能也是读多写少，没必要所有要求都 集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。 读流量太多的时候，还可以加更多的从库。
ElasticSearch
Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支 撑高并发，由于动不动就可以扩容加机器来扛更高的并发。那么一些比较大略的 查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也 可以考虑用 es 来承载。
上面的 几点点，基本便是高并发系统肯定要干的一些事儿，大家可以仔细结合之 前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要 把稳哪些问题，之前都讲过了，你都可以阐述阐述，表明你对这块是有点积累的。
说句实话，毕竟你真正厉害的一点，不是在于弄明白一些技能，或者大概知道一 个高并发系统该当长什么样？实在实际上在真正的繁芜的业务系统里，做高并发 要远远比上面提到的点要繁芜几十倍到上百倍。你须要考虑：哪些须要分库分表， 哪些不须要分库分表，单库单表跟分库分表如何 join，哪些数据要放到缓存里 去，放哪些数据才可以扛住高并发的要求，你须要完成对一个繁芜业务系统的分 析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比繁芜的， 一旦做过一次，并且做好了，你在这个市场上就会非常的吃喷鼻香。
实在大部分公司，真正看重的，不是说你节制高并发干系的一些基本的架构知识， 架构中的一些技能，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块， 你理解了，也只能是次一等的人才。对一个有几十万行代码的繁芜的分布式系统， 一步一步架构、设计以及实践过高并发架构的人，这个履历是难能名贵的。
