java 如何解决面试中的高并发，大数据的问题，都没有经验？

https://www.zhihu.com/question/39250661

回答1:

在面试时被问到高并发经验时不要慌，按照以下过程表达即可体现你的高并发设计能力：优化单请求耗时、提高单机并发能力、提高整体并发能力 。

个人认为，其实我们并不用去追求严格意义上的高并发经验，因为很多时候都没有这样的机会给到你，对于高并发的处理经验主要体现在日常的积累以及对自己的严格要求上。

为什么总在说高并发？

在并发不高的场景下，不区分经验是否丰富的任何人都能完成基本的业务开发，而且不会产生任何性能问题，下游依赖、底层存储依赖都不会对你的系统产生影响，但是在并发很高的时候，一切都变了，可能由于高并发环境时下游抖了几ms、db由于高写入或者备库读压力过大而导致主备延迟了一下，你的系统或者业务都会产生故障。

如何积攒“经验”？

对于这个问题，我总结3点可落地：

1. 系统的设计优化：

首先系统只有无状态的，才能不断横向扩展，才能支撑流量的变化，在业务层的高并发大多都需要不断扩容来支持，但是扩容也不是最根本的方式，如果系统不做优化，一开始扩容大概率是有效的，到一定阶段后就会发现情况开始恶化，因为底层的依赖竞争开始激烈，失败开始增多。优化的尽头往往是对下游依赖和底层数据层的优化，解决方案大多是常见的缓存分层、读写分离、分库分表、异步化等等，但是引入这些技术方案时，会带来一些副作用，接下来你需要解决和屏蔽这些副作用。

2.业务逻辑的优化：

当你只是在负责一个流量不大的系统时，是否就没有高并发的机会了呢？其实不然，你需要不断严格要求自己，让业务跑的更快，例如：将单次请求响应耗时从100ms优化到20ms；单机能力从100qps提高到500qps，同时cpu消耗上涨不明显；优化单次请求对缓存和db的放大系数降低，减少对缓存和db的压力。在这个过程中你将积累大量的实战经验，完成业务开发很简单，但是完成一个高效且具备高扩展性的业务开发却是很难的，往前多想几步，你会收获很多。

3.压测验证：

在业务体量没有高并发的情况下，只有自己人为创造流量来验证（不过前提是你的系统支持全链路压测，否则压测数据会污染线上真实环境，如果暂时不支持，那么恭喜你，你有机会做一次全链路压测改造了），通过验证在目标水位下的系统表现、机器表现，再继续重复前面两个过程，不断迭代，直到无法扣细节，提高性能；

如何展示自己的高并发经验？

只要在日常研发过程中严以律己，做好各项设计和优化，不随意写难易扩展和难易维护的代码，面试的时候就能聊下去。在面试时被问到高并发经验时不要慌，只要按照以下过程表达即可体现你的高并发设计能力：

1. 如何优化单请求耗时：这里你会阐述如何设计和改造系统架构，有可能涉及到jvm的参数优化、各种依赖是如何选型，过程中你积累了哪些选型和优化的方式；
2. 如何提高单机并发能力：这里你会阐述在你的业务中，单机并发能力受限于哪些关键点，这里主要的挑战点是单机的限制条件以及单机资源的竞争，你是如何设计克服的，过程中你积累了哪些设计原则；
3. 如何提高整体并发能力：这里你会阐述在集群环境下最重要的亮点，就是如何处理跨机器的资源竞争以及数据的一致性问题，这里将体现你整体业务架构设计能力；

综上所述，面试时并不是要求你一定要有真实高并发的项目经验，项目经验只是为了验证你真的做过一些设计和优化，如果你能将高并发场景下的设计原则和可能遇到的问题场景和解法都表达清楚，那么我相信面试官也是认可的。

回答2:

如果没相关经验，面试时就坦白说没有！

这并不会影响你在面试官心中的形象。有些压根没有高并发经验的人说不定也能答到点子上，并做的很好；而且有经验的也可能上来就塌了。高并发知识一个结果，一种现象，不是过程。

所以千万不要觉得没经验，学不好高并发是死路一条，这里我把我觉得有用的东西汇集起来，希望对你有帮助。

首先，我认为脚踏实地学好基础很重要

基础知识其实包括很多种，像算法，操作系统，jvm，数据库，缓存，多线程...每一个都是既独立有各自存在关联的知识点，常规的书本上也都有，但学完之后一定要结合实际，落实到具体技术才会有用。

这里提供一份后端基础学习框架，包含数据结构，java基础，设计模式，java虚拟机，操作系统，Linux，网络，并发基础，微服务架构，分布式架构，数据库，工具，安全等。

但千万别迷信某一种技术，某一个框架。在高并发面前没有一个是靠得住的，最靠谱的还是人，能根据不同场景提出不同的解决方法。

面试中爱考哪些高并发？

说实话，很多公司目前根本接触不到高并发，但就是面试爱考，没办法。

既然面试官只想跟你【面试造火箭】，那么我们就来【对症下药】，看看面试中到底爱考哪些高并发：

• 字节后端一面：说说淘宝系统如何处理高并发下的客户请求
• 小米大数据开发二面：高并发中concurrenthashmap和hashmapd的区别
• 阿里java二面：如何设计双11总交易额面板，做到高并发高可用
• shopee后台开发一面：高并发秒杀项目怎么保证不会超卖
• 百度测试开发工程师三面：是否了解jvm调优，是否有在自己的项目中进行jvm调优
• 支付宝java工程师三面：数据库性能调优如何做

因为没有高并发经验，所以一点思路没有是正常的，你可以多去接触一些类似电商秒杀系统这类项目，分享项目经验的大神都是TMD高级架构师出身，可以免费观摩学习一下。

下面跟大家分享几个解决高并发的常见思路，避免在面试中被问懵直接跪

解决思路是还依托于电商秒杀系统这个项目，会系统性的讲解秒杀场景下的高并发解决方案，感兴趣的也可以直接移步免费试听实操。

1、高性能的解决思路

从计算和 IO 两个维度考虑所有可能的优化点，需要配套的监控系统实时了解性能表现，支撑你进行性能瓶颈分析，然后再遵循二八原则，抓主要矛盾进行优化。

①异步（Asynchronnous）化

通过异步化被分割的两部分逻辑处理并没有太多事务性的关系，即一般是前面部分的逻辑处理成功后，后面那部分是否成功执行不会对前一部分的处理结果产生影响。

②锁选择

读多写少的场景用乐观锁，或者考虑通过分段锁的方式减少锁冲突。这里展开讲讲乐观锁

乐观锁

是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样就不需要思考队列问题。

关于乐观锁的详细解决方案，TMD高级架构师欧阳修在电商秒杀系统项目中都讲的很清楚了，感兴趣的小伙伴可以去免费试听一下。

③缓存预热（Cache Warm-up）

网站访问数据的特点大多数呈现为“二八定律”：80%的业务访问集中在20%的数据上。

就是说用户只用到了总数据条目的一小部分，当到一定规模，数据库IO操作成为性能瓶颈的时候，使用缓存将这一小部分的热门数据缓存在内存中是一个很不错的选择，不但可以减轻数据库的压力，还可以提高整体网站的数据访问速度。

举个例子：在秒杀系统活动开始前，提前将设置好秒杀的商品信息、限购数量，库存数量等写入Redis中，同样是减少服务器压力的方式。

2、高可用的解决思路

高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。

①降级处理

保证服务核心可用，即使是有损的。并且降级也需要根据系统的吞吐量、响应时间、可用率等条件进行手工降级或自动降级。

②限流处理

目的是在高访问量，高并发的情况下限制一部分流量对正常业务的访问保证系统能正常运行而不奔溃或者宕机的一种有效的手段之一。

其中令牌桶算法与漏桶算法算是业界比较有名的2种算法。

令牌桶算法

漏桶算法

③监控报警

广义上的网站监控涵盖所有非直接的业务行为的数据采集与管理。

全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。

3、高扩展的实践方案

①分层架构

比如互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。

②存储层的拆分

按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。

③业务层的拆分

最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5 ）。

最后，直接给大家举例几个常见的高并发场景，可用用作项目练习

1、电商秒杀系统

某年双十一，商家以4499的价格上架了某iphone，比官网价格便宜了1000员，库存总数10台，运营设置11/11 00:00活动生效，一人只能购买1台，商品售完为止。

针对这种常见的高并发场景，九章算法的欧阳修老师给出了秒杀系统背后的技术和原理。

详细可移步秒杀系统项目课听欧阳修老师详细拆分讲解。

简单来说，秒杀系统的高并发的核心解决思路包括：

1. 从高纬度出发，从整体上思考问题，抓住问题本质：并发读，并发写
2. 明确核心架构目标：高性能，一致性，高可用
3. 分而治之，逐一击破：拆分服务，逐一完善

除了设计思路，欧阳修老师还将在秒杀系统项目课中提供秒杀系统的源码，其中解决瞬时大流量高并发问题的核心思想为：分层过滤，分而治之。

你需要在不同的层次尽可能地过滤掉无效请求，让“漏斗”最末端的才是有效请求。

具体实现步骤，可参考欧阳修老师的秒杀系统项目课

2、Twitter 后端系统 - Django 项目实战

Facebook资深架构师的Twitter项目，带你从零设计Twitter，最终搭建一个P8（L5）水准的项目。

涉及万行代码，最终成果是一个可上线的工业级别的项目，而不是像市面大多数项目课程简单做个demo。

涉及的面试难点包括：

• 如何分别测试登录用户和未登录用户？
• 如何做反向查询？
• 如何设计数据库表达？
• 如何让部分用户看到某个新功能，其他用户看到的就是功能？（灰度测试）
• comments的API该如何设计？
• ……

回答3:

很多程序员可能都遇到过类似的困惑：

我没有高并发项目经验，但是面试的时候经常被问到高并发、性能调优方面的问题，该怎么办？

这个问题貌似是个死结，怎么解决？和大家说一个程序员的经历吧。

有一个程序员，叫他小张吧。

他毕业之后的第一份工作是参与开发和维护一套电商平台。虽然是电商平台，但是这个平台并没多少访问量，QPS 可能一只手都能数的过来。说句难听话，也就是挂在网上而已。

因为没什么用户量，也没什么需求，每天的工作就是修修补补……就这样持续了一年后，小张发现自己已经无法再有任何提高了。

他想跳槽，但是发现很多高级岗位都是要求高并发经验的，他对此很着急。如果他继续在公司发展，就势必接触不了什么高并发。但是跳槽的话，他又必须有高并发经验才能找到一个不错的岗位去继续提升自己。

这貌似成了一个死结。

在百般无奈之下，他决定自己模拟高并发去获得经验。

第一阶段：小张完成了在高并发条件下，对单机性能优化的学习。

小张用 Docker 容器去运行他维护的电商项目。然后用 jmeter、wrk 等工具去压测。

在压测期间，他敏锐地发现了由于系统每个模块不同，所以性能表现就不一样，这种现象引发了他的思考。他经过网络搜索和查询资料，明白了不同模块、不同产品对并发指标的要求是不一样的。

基于这种情况，他又根据产品的业务逻辑编写了复杂的压测脚本，能自动实现不同模块的压测任务。

就是在这种不断地压测探测下，他明白了如何探测问题，如何通过优化代码、JVM 去解决问题。

比如，解决误用 HashMap 导致死循环的问题。又比如，误用不带缓存的文件 IO 流，去读取文件的问题等等。

在程序和 JVM 优化完毕后，他又发现数据库也存在问题。于是，他又学会了如何优化数据库 SQL，如何对数据库分表等问题。

也是在这个阶段，他认识到了缓存的必要性以及同步缓存数据状态的重要性等重要知识点。

小张在搞了单机优化后，他觉得也没有办法再通过单机的压测学到什么新的东西了。于是，他转向了第二阶段。

第二阶段：小张从阿里云买了两台机器，他开始尝试使用负载均衡去分担高并发的压力。

同样的，也是借助压测工具去模拟了高并发。在压测期间，负载均衡和系统屡屡出现和单机完全不一样的问题。

比如，负载均衡本身的性能问题。比如，在一些时候，负载均衡后面的机器负载是不平衡的，需要对负载算法进行调整。

这个阶段，小张理解了负载均衡中大部分的细节。

但是，高并发中，很多系统的构成会很复杂，以至于需要分布式架构系统的程度。他们需要各种中间件做通信，做存储。

所以，小张根据招聘的一些需求，他做了第三阶段的练习。

第三阶段：为了能熟悉市面上各中间件的使用，小张把他那套电商平台改了又改。

比如，一些本地调用的方法，被他替换成了 Dubbo 远程调用。比如，一些模块间调用，被他替换成了 MQ 中间件传消息。再比如，一些放在关系数据库的被频繁访问的数据，被他改存在了 MongoDB 中……

当然，压测依然继续。就这样，小张又实践了很多中间件和分布式框架的使用。

在模拟高并发练习的同时，小张不忘去读各种高并发高性能的书籍。比如，《大型网站服务器容量规划》、《互联网创业核心技术：构建可伸缩的web应用》等书籍。

在去新公司面试之前，小张如此练习了两年左右。

在面试的时候，面试官问他：

高并发需要参考哪些指标？

小张答到：

高并发由于产品类型不同，所以指标都不一样。以电商系统来说，根据模块的不同，关注的指标不同。商品浏览看得是 QPS，订单模块则是看得 TPS。同时，还需要关注活跃的 用户量等等。

在后面，面试官又追问了集群部署、多级缓存、复杂查询优化等有关性能优化的问题，还附加了系统高可用的各种策略，和如何拆分去保证灵活扩展等问题。

等面试完毕后，时间已经过了一个多小时。小张当时并没有百分百答好面试官问的问题。

从实际回答来看，关于性能优化的细节，比如，系统瓶颈的检测和优化，程序逻辑的优化，JVM 优化甚至数据库的优化，小张都答得不错。

但是，对于高可用的大概策略，比如降级处理，限流处理等，小张只知道大的方向，很多答案一听就知道是从书本上或者互联网上看来的。

而对于系统的扩展性相关问题，他甚至答的非常差，很多都回答不上来。

不过瑕不掩瑜，小张依然拿到了 offer。

以上呢，就是小张自学高并发、面试的整个经历。

你可能会问“为什么你会知道这么清楚？你是小张么？”

不，我不是小张，我是那位面试官。

虽然小张面试的时候表现也存在很多不足，但是我当时看中他的一些优点是:

1. 小张满足具有高并发经验的要求

为什么我们需要找有高并发经验的人？

说白了，我们想找的程序员其实是：

• 不会乱写性能很差的代码
• 能敏锐感知到影响系统的问题
• 能独立的处理由于高并发引发的问题

2. 小张满足熟悉高可用的要求

我们找熟悉高可用的人，其实并不要求这个人一定能给出什么独特的高可用方案。我们要求的是，他能知道高可用的知识后，去意识到高可用的重要性。

比如限流功能出现问题，他要能马上认识到这是个很重要的问题，从而把解决的优先级提到很高。

小张通过学习，明白了高可用的重要性，也知道了高可用的大方向，这就够了，剩下的细节，我们有信心带小张在实际工作中学出来。

3. 小张能参与我们的中间件研发和存储优化

小张主动改造过他们的电商系统，而且使用了很多的中间件，并对这些中间件都进行过优化。对这些中间件的特性比较熟悉，并且在实践中，他也了解了很多原理。

除此之外，小张的主观能动性尤其打动我们。他对技术的主动钻研、主动学习，表明了他是一个喜欢走出舒适区，愿意挑战自己的人。而这样的人，有哪个团队不欢迎呢？

所以，其实没有高并发经验并不可怕。

如果在工作中你接触不到高并发的项目，那么也没必要太纠结。

公司做什么项目你改变不了，你能改变的只有你自己。

看完有收获的话，别忘给我点个赞。