面经

除了上面这个，我在儒猿群里面，也经常参与问题的讨论，回答。
（4）结合公司的业务进行深度思考。
比如，我要是用了MQ要怎么用？我们的项目有没有秒杀场景？和老师架构讲的秒杀是不是相似？不相似的话，区别在哪里，这个区别需不需要我在架构上做调整？

Jvm优化思路是不是相似？缓存数据要怎么存，每一级存什么，大概多少key，如何设置过期策略，本地缓存怎么存，存什么合适，多大合适，怎么和redis保持一致，怎么和数据库保持一致，如果不一致了会有什么影响，怎么解决不一致问题，缓存同步怎么保证时效性，怎么监控？

CDN用上是不是合适，可不可以不用？Tomcat怎么优化，我们的机器配置和请求访问特点，和普通的电商是不是类似，如何根据业务的具体情况来做分析，来做Tomcat参数调优？

我的学习方法：

简单粗暴，就是学习+笔记+画图+头脑风暴输出+讨论输出。

主要复习的内容：专栏课内容+架构课内容+公司的项目

专栏课：JVM专栏课+MYSQL专栏课+ROCKETMQ专栏课

架构课：大电商的设计模式+ spring cloud 源码+分布式事务解决方案/源码+分布式锁解决方案/源码+JDK源码

很多人喜欢问学习进度，我其实想说，进度不重要，重要的是，你学到的有没有输出？有没有输出？有没有输出？重要的事情说三遍。
就算你拿到了定海神针，拿在手里不输出，你自己也不知道挥不挥的动，挥动了，能不能打到妖怪，打到了妖怪能不能一击必杀，灭了他的三魂七魄？

我们要思考的从来不是架构班更新到哪里了，专栏又出了多少个了，哪个大佬一天刷了十几章专栏了等等这些没有意义的问题

我们要思考的是，我学完了jvm专栏，现在能够在输出多少，疑问是否解决，公司需要优化参数，我能不能上手做，出现了问题，我能不能根据学到的知识把他解决，这个才是学习过程中最该关注的问题。
用我打辩论的思维，当我们看了十篇论文的时候，我们会觉得自己的知识面宽如大海，但是对手攻击的角度，似乎也宽如大海，哪里都可能是被进攻的角度，哪里都是破绽。
而只有当我和队友沉下心来，把我看到学到的东西和队友来一场激烈的头脑风暴+口头碰撞的之后，才能输出一套牢不可破的逻辑。

4、 简历准备

说实话，经过了大量的知识输入，再加上几个月时间的总结+思考+笔记+讨论输出之后，你的简历简直是手到擒来，无非是需要关注一些模板和格式。我的简历的结构是这样的：

（1）技术点，从八股文到框架，由基础到深入的过程去写。比如，深入阅读JDK集合并发源码，jvm，mysql，框架源码等；

在简历上的体现类似于下列格式：
深入阅读JDK集合源码，JUC并发包源码，深入理解volatile原理，synchronized锁原理。

（2）项目点，项目是我这次简历以及面试准备的重中之重，设计模式怎么用的，spring cloud怎么用的，我是怎么通过源码结合业务来思考拆分微服务的，怎么做优化的？
分布式事务怎么用的，我是怎么通过阅读解决分布式事务问题的？我是怎么用分布式锁的？用的过程中出现了什么问题，我是如何通过思考源码，原理，执行过程来解决的？

在简历上的体现，就可以类似于下面的格式：
技术挑战：spring cloud服务注册、发现时效性问题、资源分配问题

解决方案：通过深入阅读源码，了解各个参数的生效方式，并结合线上监控的服务注册、发现、心跳的时效性，服务器的压力，不同业务的qps，请求响应情况，优化各项参数配置。

实现效果：通过对参数调整，实现了在xxx业务场景下，时效性为秒级，并且实现了冷热资源隔离，实现热业务和冷业务资源配置的优化。

5、技术亮点准备

（1）基于业务领域做了微服务拆分，并引入了分布式事务，分布式锁；

这些内容能够有多细节，就有多细节，比如说，分布式事务，具体在哪个业务上用的？是出于什么考虑要用，时效性？强一致性？能不能有其他的替代方案？

如果出了问题，有没有兜底方案？每天的业务量多少？这个业务量下，你这个分布式事务能不能扛下来这个流量？如果业务量飞快提升，你这个技术方案怎么扩展？

（2）三级缓存架构；我自己总结了一些东西，包括笔记和图，附上链接：https://www.processon.com/view/link/60aa22936376891bafa845dd

6、部分公司面试题

（一）北京银行一面

1.我看你了解spring cloud的几大组件儿，能说一下你对哪个组件儿了解的比较多吗？我说了eureka，ribbon，feign都还算了解。说了eureka的作用还有一些实现机制（有点魔怔，就想硬刚eureka），优化策略等等

2.zuul组件儿用的是什么？你们用的路由器还是过滤器？
这个一时没复习，没想起来。

3.feign调用请求调用和正常的http请求区别在哪儿？能解释一下他的原理吗？其实就是想问，你知不知道feign底层请求调用的机制是什么。

4.我看你对cap的理论基础了解一下，你能说说zookeeper是保证的是啥特性吗？我说的是不太了解zookeeper，只是比较了解它实现的分布式锁，最后思考了一下，说保证了可用性和分区容错性？那eureka呢保证了什么？保证的其实也是ap，可用性和分区容错性，一致性是没有保证的。

5.用过redis的分布式锁吗？能不能说说一个redis分布式锁的加锁流程？
从集群构建redisson+get锁，到锁执行流程的lua脚本，构建一个锁的hash结构，重入的锁的一个hash里面的key，借助incrby来做重入。watchdog的监听机制，后台线程刷新锁生存时间的机制说了一遍。

6.分布式公平锁呢？能讲一下吗？（这个一下子没想起来，面试最后，我说弥补一下，把这个问题回答了）
加锁的核心机制和上述机制相同，只不过，需要通过一个队列去排队，并且会有一个超时时间的set集合，放它的超时时间的毫秒数值。然后也是后台的watchdog来做的自动更新剩余时间，自动排队，并且说了排队机制可能在某个场景下出现重新排序的情况。

7.redis的RDB和AOF的机制能说一下吗？有哪些数据结构？Hash结构式什么样的？和Java的Hash有什么不一样？
从内存快照和日志指令文件，到他们的数据完整性（fsync的这个东西也说到了，一个缺1s数据，一个缺几分钟数据），到他们在重启恢复数据的场景中的作用做了整个的回答。

8.说一下JVM的吧，JVM的内存模型是什么样子的？（几个分区，存的什么东西）

9.新创建一个对象，会进入哪个区？一定会进入新生代，eden区吗？

10.栈内存存的是什么？局部变量表，栈帧，常量池等

11.你为啥要离职？

13.有啥想问我的吗？

（二）北京银行二面

1.介绍一下你做的比较有挑战性的项目？
三级缓存架构详细说了一遍，就是按照我自己画的那个图。

2.我看你这边儿也用过分布式事务是吧，分布式事务的几种模型说一下？你们是从0到1搭建，还是改造？
用过。分布式事务模型，我没太总结过。
不过分布式事务我们这边引入的是ByteTCC框架，模式是try confirm cancel。其他的分布式事务，还包括seata，saga分布式事务，以及最终一致性分布式事务和最大努力通知分布式事务（如果要提到其他的最好有大致了解过，不然容易入坑）
并且把上下游服务放在一个分布式事务，下游服务放在一个分布式事务，中间用消息投递，第三方短信用最大努力通知这整个分布式事务架构讲了一遍。
说的是把spring的事务拆分成分布式事务，bytetcc的调用链+接口一分为3说了一遍。

3.你刚才说ehchache做了降级处理？有没有做过前端的降级或者限流机制？
（1）前端的静态化页面，把大量请求留在nginx层
（2）按钮置灰，也就是1s后可以再次点击；
问：这种方式有没有什么具体的策略？答：前端的不太了解了。（可能是想问，动态URL，或者置灰和恢复的动态方案）
问：也就是说，是牺牲了一些前端体验做的前端限流是吧？答：是的。（这个时候大方承认就好了）
（3）前端遮罩效果等待结果返回；

4.有没有其他的限流机制，或者你做的限流机制？
答：借助sc的hystrix组件儿，做线程池参数的调整，根据服务请求的平均返回时间考虑设置等待时长。根据服务的访问量，设置参数和fallback逻辑，fallback逻辑里面用JVM内存的参数（把前面的三级缓存架构连起来）

5.你这个是借助了组件儿的功能做的，还有没有其他的限流方案？（最开始没想起来，面试官主动说，比如MQ？）
答：可以借助MQ来实现削峰，比如我把上游的分布式事务，解耦开，通过异步消息的方式来削峰（强调了这个属于削峰的范畴了，削弱一下前面没想起来怎么做的不好的影响），这个时候，可以在前端做一个等待确认的页面，等到分布式事务的两步都完成了，让他确认这个申报信息。

也就是说：前端分两步，第一步申报，第二步等待确认，后端分三步，第一步申报，第二步发消息，第三步消费消息扣额度，返回前端结果

6.为什么离职？你的未来的职业规划？

7.有什么想问我的？
（1）用的什么技术栈？
spring cloud dubbo mq都用

（2）如果入职的话，会不会有岗前培训？因为问了好几家公司，他们都说的是，急招，进去就要直接上手。我个人理解，如果没有对业务和技术栈有基本的了解的话，做事儿很容易出问题。所以比较在意有没有岗前培训什么的？
回答：正常的入职流程和公司情况是有的培训的。单纯的技术是没有的，不过我们这边儿不会上来就直接丢一堆活就让干，肯定是慢慢来的。

（三）微盟一面

1.自我介绍，继续刚三级缓存架构。
缓存架构那一套。包括数据同步，具体存了什么数据，怎么监控的，怎么同步的，同步时效性，以及为什么可以容忍这个时效性，讲了一遍。

2.针对缓存集群，你们是怎么选择的？为啥要这么选？中间因为什么要做集群架构改变？redis的数据迁移是怎么搞的？
（1）最开始选择主从+sential，后面用户量上来了，就换成了redis cluster。（讲了redis master-slave架构的空间性能问题）最后做数据迁移，RDB，AOF，的特点，迁移用的RDB，然后重新分片，重新进行主从同步；

3.我看你用过分布式事务和分布式锁？你能讲讲这个reddisson框架你怎么用的，你对他有怎么样的了解？
讲了分布式锁的使用场景，redisson分布式锁，到底是怎么创建锁，锁互斥，延长时间，重入的。

4.我看你也了解zookeeper的锁，它是怎么做的？和redssion的分布式锁有啥优缺点？
这个架构都讲过。

5.看你对mysql也有一定的实战经验，你sql建立索引，是怎么考虑的？
（1）开发的时候不创建，开发过程中，对查询比较多的，按照顺序和频率分析之后建索引；
（2）对一些常用的查询字段做分析，比如日期查询10条，地域查10000条，那么就选择日期做索引；

6.有一个联合索引，a,b,c，我where加了b,c,条件，会走索引吗？
分析原因，索引顺序，索引数据的排序规则，索引怎么查的（二分法）

7.如果a是一个范围查询呢？会不会走？
跟上面是同样的逻辑。

8.对JVM也有所了解是吧？能说说你了解的JVM算法吗？他们对JVM内存分代来说，哪种更适合新生代，哪种更适合老年代？
专栏就有。标记复制算法，标记整理算法。分别针对老年代，新生代的对象特点，存活对象数量来分析。

9.redis缓存穿透缓存雪崩，你们项目里面是怎么解决的？有没有深入分析一下原因？有没有更好的措施去解决这个问题？布隆过滤器具体怎么用的？redis本身的还是框架带的？

10.cas了解吗？说一下逻辑？有什么问题（ABA）怎么解决？实际项目中怎么用的？（用了Atomic原子类对象，说了本来的想法准备用cmap，后来因为xxx原因选择的Atomic对象）

11.有什么想问我的？

评价一下我这次的优劣势？

你们的技术栈以及业务线，还有我的技术匹配度？

@所有人由于面经内容较长，为保证效果，将分为上下两部分进行分享，下半部分的分享包含：【面试内容、面试技巧、面试投递】等精华内容

其中面试内容包含了不少高阶系统设计题和场景题，作者均还原面试现场，给出了自己的分析思考，大家也可以先行讨论。
部分题目如下：

1、三级缓存，你具体是怎么存的数据？这么一套架构解决了什么问题？你是怎么做的同步？同步的时效性多少？怎么监控的？redis的key有多少？命中率多少？没有命中的是什么原因？怎么查的，思路是什么？

你服务本地jvm存的什么数据？数据量有多大？怎么保证多台服务一致的？怎么保证和数据库、redis一致的？如果发生了数据改变，你是怎么保证他们是一致的？同步时效性是多少？这个过程中大量流量进来的话，你是怎么处理的？

2、假如我要你设计一个最终一致性的分布式事务方案，你会怎么设计？需要考虑哪些方面的内容？

3、我现在需要设计一个类似于优惠券的系统。要求是：
1）实时性，达到分钟级秒级；
2）各种优惠券优惠规则可配置，获得优惠券的达成条件可配置；
3）需要保证不能有发失败的情况
你会怎么去设计？

4、我现在需要用redis实现一个限流器，要求是1分钟之内只能由10个请求通过，你会怎么设计？

5、我有这么一个场景，有一个客户下了一个订单，我怎么才能匹配到直径500米范围内的所有骑手？如果我要从中选择一个骑手去接单，应该怎么去设计？

6、假如我有一个任务，可以允许多个线程同时执行，但是一旦有一个线程执行完成后，其他的线程就立马终止这个任务，并且后续的线程都无法执行这个任务，这个功能应该怎么来写？

7、让你来设计一个redis的hash结构，你会怎么来设计？让你来设计一个redis的zset结构你会怎么来设计？

8、说一下你们系统的数据库的数据量，你是怎么去设计索引的？线上的mysql优化你会怎么做？分库分表的方案是什么？

分布式的id你会怎么去生成？如何去设计？你怎么设计这个id生成算法，才能避免跨库查询数据的这种情况？

6、 面试内容

因为前面的很多师兄已经分享了大量的基础知识面试题，我这次就着重附上我遇到的几个场景题和项目细节题，大家可以感受以下。

1、三级缓存，你具体是怎么存的数据？

这么一套架构解决了什么问题？你是怎么做的同步？同步的时效性多少？怎么监控的？redis的key有多少？命中率多少？没有命中的是什么原因？怎么查的，思路是什么？

你服务本地jvm存的什么数据？数据量有多大？怎么保证多台服务一致的？怎么保证和数据库、redis一致的？如果发生了数据改变，你是怎么保证他们是一致的？同步时效性是多少，这个过程中大量流量进来的话，你是怎么处理的？这些问题，大家可以结合自己的业务系统，去思考，假如要这么设计一套缓存架构，这些问题，如何去解决

还记得我个人认为最重要的事情吗？知识学完，有没有输出？有没有输出？有没有输出？也请大家尽情输出！

我是怎么思考回答的？事实上，三级缓存这个问题，最重要的是事先做思考。

你的项目里，哪些数据是适合做静态缓存的？比如我们的系统，有一个分解曲线数据，也有一个分解后的详情数据，这个数据在查询的时候是一定需要加载的，但是却不会出现变化。所以这样的数据就适合做第一级缓存，渲染成静态页面来存放在nginx层。挡下第一层流量。

第二级缓存，说白了，也是需要频繁查询的数据，但是这个数据是存在有效期，存在被修改，存在需要统计的情况的。
比如我的系统里面，电量套餐数据，挂牌电量数据，所有的用户是需要访问电量套餐数据，签订套餐，并且扣减套餐的剩余电量的，既然是套餐，那么电量数据频繁修改，电价有可能也是会被各个发起方修改的。所以这类型的数据需要用redis缓存，访问速度快，即使修改频繁redis也比db快。

JVM本地缓存，在本地缓存这一层，很多人是有点不知道要存什么数据的。这个其实也要根据自己的业务场景去思考。我这边自己的思路是：
第一：JVM缓存需要存的是热点数据，到达服务就可以直接返回，那么我这边存的数据就是，我对昨日的热点挂牌数据的订单（排名1000的），以及热点电量套餐（排名1000的）来做本地热点数据缓存。

第二：JVM缓存需要存的是所有服务需要的共享数据，并且数据量不大，修改不频繁的。这种数据放在JVM层，就不需要再走一遍redis缓存，比如说，用户的一些基础资料信息。

第三：JVM缓存需要存的是降级数据，也就是说，一旦服务出现了大量调用失败的请求，那么一些请求就需要降级处理，防止用户体验出现崩盘的情况。比如说，配和fallback降级使用的数据，只给一些简单的查询结果，或者干脆直接返回一个，系统开小差了，请稍后再试，做到快速返回。

2、假如我要你设计一个最终一致性的分布式事务方案，你会怎么设计？

需要考虑哪些方面的内容？（架构班讲过，那么我们怎么结合自己的思考和语言把它输出出来，最好结合业务输出）
我这里给出一个思路：
首先，如果要考虑分布式事务，一定要考虑是要牺牲吞吐量还是牺牲强一致性。那么结合业务来思考，比如我这边，签订套餐操作，挂牌电量交易操作，现货电量实时交易操作，交易额度锁定，结算额度锁定，结算数据推送，风险额度锁定，调度负荷锁定，调度指令发送等等一系列的操作是需要放在同一个分布式事务的。

但是有些是需要强一致的，比如交易操作与交易额度扣减操作，这个必须要做到强一致，那么他们就要放在同一个分布式事务中，使用TCC，由于我们的系统的这些操作的tps并不是很高，所以可以使用TCC。

后续的结算额度，风险额度，调度负荷锁定，调度指令等操作，实际上不需要强一致，那么就可以考虑最终一致性，比如使用MQ来搞定。到底是选择可靠消息投递方案，还是直接RocketMQ的事务消息机制来做，都可以。
但是分布式事务的场景，一定一定会有性能瓶颈，要想彻底解决性能问题的话，需要采取彻底最终一直性，并且不能用事务消息这种方式，要使用MQ普通的异步消息 + redis扣减 + 对账补偿服务的方式。

3、我现在需要设计一个类似于优惠券的系统

1）实时性，达到分钟级秒级；
2）各种优惠券优惠规则可配置，获得优惠券的达成条件可配置；
3）需要保证不能有发失败的情况
你会怎么去设计？

我当时的思路和说法：首先要做到动态可配置，需要对业务进行分离。
（1）核心交易业务。
（2）订单状态业务。
（3）优惠条件业务。
（4）优惠券触发业务。

前面两个一般比较固定，大多数涉及到交易的公司都有很完善的方案，我就不赘述了。那么优惠条件业务，我会设计这么几个维度。

维度1：时间，可配置规则为小时范围，日范围；
维度2：积分等级，可配置积分登记分段，以及积分分段的分数；
维度3：单笔金额维度，可与时间积分获得组合使用，配置单笔金额下限，以及单笔金额某个范围内对应的积分；

根据以上三个维度，基本上可以实现动态配置优惠券的触发规则，比如7天完成了3笔金额超过30元的订单。比如积分达到了xx分。比如单笔订单达到了50元，会触发返现。

4、我现在需要用redis实现一个限流器，要求是1分钟之内只能由10个请求通过，你会怎么设计？

我当时其实是有点懵的。由于没有刷面试题，所以只是知道有令牌桶算法，不知道令牌桶算法的具体实现。所以，我思考了一下，用redis的话，完全可以参照redisson的信号量锁来实现。

简单来说就是，请求过来以后，先去redis尝试创建一个限流器，然后内部有一个计数器，判断是否小于10，如果小于10，就执行incr，如果大于10，请求要么等待，要么直接返回。这个限流器key的超时时间设置为1分钟。

这个时候实际上就体现了老师所说的，读源码的重要性，很多方案的实现思路都是有相似之处的，完全可以思考之后参照着来，当然，如果没有好好学习，深入思考，输出笔记，头脑风暴一下，即使读了源码，也是要直接挂的
所以还是那句话，是骡子是马拉出来溜溜，金箍棒你摸的再光滑，不挥动两下，也是不知道它到底是不是真听你话的。

5、我有这么一个场景，有一个客户下了一个订单，我怎么才能匹配到直径500米范围内的所有骑手？

如果我要从中选择一个骑手去接单，应该怎么去设计？
这道题，有些人的第一反应是redis geo的数据结构。由于我不喜欢刷面试题，并不知道geo是个什么东西，所以，我就结合我之前刷过的算法题，说了一下我的实现思路，思路如下：

当时思考了一会儿。说，首先针对地域画一个网格。因为我肯定不能直接拿所有骑手的位置坐标，做数据样本去和订单位置比对。
所以第一步，就是去缩小区域。画出的网格维度可以自己根据负载，内存，响应来综合确定（因为网格大小是会影响数据量响应速度的，比如网格过大，那么需要找的骑手就会过多，网格过小，网格数据量会变大，并且找到骑手的概率会变小，可能会有重新查找的开销），找一个性能最好的。

然后找到订单所在的网格。找到网格内的所有骑手，再去比对位置。假如没有在这个格子找到，那么就从这个网格的周围上下左右8个网格里面寻找存在骑手的网格。然后从里面取出骑手位置，和订单位置做比对。找出最近的。

后面的开放题，我就不写这么详细了，只说简单思路：

6、假如我有一个任务，可以允许多个线程同时执行，但是一旦有一个线程执行完成后，其他的线程就立马终止这个任务，并且后续的线程都无法执行这个任务，这个功能应该怎么来写？

思路：设置一个volatile标记位变量，任务执行完毕之后使用interrupt打断，并判断标记位，决定是否需要继续执行，volatile底层的原理老师在面试突击第三季有讲解，大家可以去了解了解。

7、让你来设计一个redis的hash结构，你会怎么来设计？让你来设计一个redis的zset结构你会怎么来设计？

思路：借助Java的hashmap，双层hashmap + 泛型。
思路：List+Node节点+比较器，设置双属性，key的内容已经key对应的score，并采取插入排序算法，做每次新数据的排序。

8、说一下你们系统的数据库的数据量，能不能告诉我，你是怎么去设计索引的，线上的mysql优化你会怎么做

分库分表的方案，以及分布式的id你会怎么去生成，如何去设计，你怎么设计这个id生成算法，才能避免跨库查询数据的这种情况？
分库分表思路：一步到位分库法。2台物理机，8个逻辑库，总计16个逻辑库，每个库16张表。后续需要迁移的时候，只需要添加物理机，迁移逻辑库，修改程序配置即可。

分布式id思路：redis incr+基因分库法。用redis incr生产id，然后在服务中，加入一些根据查询请求的影响因子，把可能出现的跨库查询的数据，尽量用这些影响因子放到同一个库，避免跨库查询。

上面的一系列开放性问题，都是我在面试过程中遇到的真实的问题，说实话，没有标准答案，需要的就是日常要有足够的思考，足够的输出，在遇到这些场景题目的时候，我们能够把学到的知识按照这些场景运用起来，说出一个起码简单可用的方案或者思路来。
当这些问题你回答的得心应手的时候，其他的所谓原理，你对技术的理解绝对已经达到了一定的层次，而不是简简单单的，我学了什么技术，背会了xx八股文。

我个人认为，没有八股文，哪怕是jdk、jvm、mysql的基础知识，里面的设计思路，优化思路也都是无处不在，可借鉴的地方数不胜数！

7、 面试技巧还是我一直强调的东西，输出！

1、广度输出

在面试之前，按照自己准备好的知识面，比如并发，锁，mysql，jvm，项目亮点，做一套完备的输出，输出过程我个人的方式是给自己设置问答，一问一答，尽可能的多问自己问题，写下来，然后自己回答

其实更好的方式是，给志同道合的小伙伴讲解，但是考虑到大家都比较忙，这个条件儿比较苛刻，所以，可以自己拔两根毫毛，变两只猿打打架

这个过程主要是要广度，也就是说，所有的知识点儿，你只要是写在简历上了，就一定要别人问到的时候，立马有所反应，就像肌肉记忆一样。

2、深度输出着重找几个重点的技术点，做深入的提问。

比如mq，你的场景，这个场景为什么要用mq，mq的广播，集群有啥区别，mq的底层存储结构是什么样的，集群/广播的业务区别和底层原理实现到底怎么实现的，事务消息机制怎么实现的，如果让你实现事务消息机制，你会怎么做，事务消息会不会失败等等……

这个过程就是越深入越好，最好深入到专栏，架构都没讲到的地步。但是这个过程因为太过于深入，所以，不适合大面积来做，找准其中几个，比如mysql + mq，jvm + 锁，redis + redis锁 + 数据结构实现原理等等。

3、项目输出我和大家一样，在项目上是没有任何优势的。

但是大家也都明白，不是所有的项目都有高并发，高负载。那么我们怎么运用学到的技术，把我们的项目包装起来？

第一点：不要怂
你的项目就是有上百万用户，上百万日活，高峰期qps就是有好几千，为啥？因为面试官也不知道你到底有没有！只要你技术学的扎实，对业务，项目，技术有深入的思考，对各种问题想好各种解决方案，那你的项目就是高并发，高负载。因为你的解决方案，只要翻译成代码，部署架构，一定能有承载高并发，高流量，高负载的能力。

第二点：深度思考业务比如，我面试的时候是这么说我的项目的，根据不同地市的特点，提炼出用户模型，业务模型，再根据这些不同的用户模型，业务模型拆分了微服务，并且做排列组合适配了各地市的交易业务，为公司带来了2000w/年的合同额。

附上我的图：
https://www.processon.com/view/link/60c167abe0b34d0950ab89d9
只要你把业务模型提取出来，再加上一些思考，结合技术，很容易就知道，怎么去拆分微服务，微服务间又是怎么做排列组合，基于排列组合，又是怎么做的服务间的交互？

第三点：找准某个业务，定制你的技术栈比如，我就找准了一个零售+虚拟电厂的业务模型。零售套餐数据，电力的曲线数据，虚拟电厂的调频调峰的实时指令发送。

首先零售套餐特别适合缓存架构，因为套餐数据多数是查询的请求，并且套餐数据变动情况不大，而曲线数据也都是相对固定的数据，很容易就可以套用nginx静态缓存 + redis缓存 + ehcache本地缓存这一套架构。

只要考虑好细节，比如怎么监控，怎么同步，存什么数据，失效策略等等。这个最好不要直接套用模板，要用一些自己的思路说一些业务特点，你是怎么处理这种业务特点带来的问题的。

例如零售这里，我设计了一个点，我们每天的套餐签订结果第二天会又很多热点套餐被查询，所以我用了一个sortedset存储当天被访问的热点套餐排名，只取前1000的热点数据。原因是，我们经过大量的实际数据分析，发现前1000的套餐，基本上是被95%的用户签订的。并且第二天会有大量的用户去查看套餐，查看套餐签订结果。
其次是结算业务和调度计划业务，因为这两个和零售不是强相关的，但是却需要我这边儿的数据去做结算单，去做调度指令计划，那么我提供接口给他调数据肯定是不合适的，所以引入了MQ，具体怎么发的，什么时间发的，有什么保障机制等等都想的很详细。

并且，交易的时候有一个结算侧风险额度和调度侧的负荷额度需要锁定，这个场景用了分布式事务去保证，但是因为也不是强相关，走的是最终一致性。
下发调度指令是一个实时性要求比较高的操作，所以没有使用mq，而是直接走redis+mysql双写的方式发送的指令。

基本上上面这一套组合拳，就能把技术面试全部刚过去了。技术广度+技术深度+项目。

另外说一下，在面试的时候，有时候难免会遇到无法理解面试官问题的情况，这个时候千万不要自己瞎猜，否则会消耗很多面试官的耐心，也会降低评价，面试是一个沟通的过程，一定要学会提问，不懂的时候，就说，请教一下问题是什么意思。
比如，请问一下，您这个问题是想问哪个角度？我这里可以从xxx、xxx、xxx角度来回答。如果没有命中面试官的方向，他一般会再多说一句，应该往哪个方向，如果命中了，他可能会说，那你都说一下吧

一旦进入到让你都说一下这个程度，就进入了你的节奏了，因为你说出来的几个角度，一定是自己特别擅长的几个方向。。。当然如果有傻猴子，非要说几个自己短板的角度，那当我没说…………