项目复盘和面试总结

项目复盘

到底什么是高并发

5000QPS是高并发吗？50000QPS是高并发吗？我觉得高并发不是以某个指标就可以进行衡量的。我的理解是用有限的资源去处理过载的请求就是高并发。对于64G8核双节点的应用来说，5000QPS/s就能把10兆的带宽瞬间打满了，那如果我有10台这样的机器，那就算不上高并发了。

怎么解决高并发

业务的解耦

业内成熟的解决方案很多，但思路基本是一样的。首先根据业务模型进行业务流程的拆分，是否能将并发点从一个接口拆分成多个接口即业务的解耦。举个例子，就抢购活动来说，之前的公司是做卡券业务的，如果抢购的是卡券，那么从下单到卡券的出库，一整个流程都是同步处理，单个接口的压力可想而知。我的想法是拆分为抢购资格（兑换码）和兑换卡券两个接口。这样的话，抢购接口不需要处理完整的业务流程。同时并不是每个人都会在抢购到资格后马上去做兑换，这也极大的减少了兑换卡券接口的压力。

预处理

然后是对抢购活动的预处理，既然是定时抢购，可以在抢购开始前就先把抢购资格（兑换码）和对应的卡券都生成好并放入缓存中，甚至可以把订单的保存都进行异步的处理，总的来说就是尽量少的直接操作数据库，接口的吞吐量的瓶颈往往是在数据库的IO上。当然，选择异步处理自然就要有重试机制以及失败的预警通知来为最后的人工补偿进行兜底，这里使用RocketMQ加钉钉通知即可。

延后处理

业务的核心是抢购卡券，那么和主流程无关的操作，通通可以去做延后处理。比如，生成订单的对账明细、执行客户账户的扣款等等。尽量的缩短核心的业务流程，保证同步接口的快速响应。

压测与监控

没有最完美的参数配置，只有最合适的。通过充分的压测才能得出接口性能的最佳配置。可调参数包括，数据库连接池的配置、redis连接池的配置、nginx的限流策略（暂不推荐）、服务器的带宽等等。

微服务边界的划分

我接触的大多数微服务，都是以业务场景进行服务的划分，也就存在某个业务到底属于哪个微服务的问题。举个例子，现有供应商服务和财务服务，那么供应商账户发生的流水，应该存在哪个服务呢？照理来说，存在财务服务会比较合理。但是从实际的业务场景考虑，向供应商发起采购时，这里先不考虑缓存，首先需要向供应商服务查询供应商的账户信息保证余额充足，然后采购完成后调用供应商服务扣减账户余额，最后再去财务服务生成流水。期间一共发生了4次远程服务的调用，并且一个采购的业务，在两个服务都生成了数据，是不是又要去考虑分布式事务的问题了？我觉得微服务的划分，不应该去过分的增加系统的复杂性。完全可以把供应商的账户流水，也划分到供应商服务来。仁者见仁智者见智吧，这个问题没有最优解，还是需要根据业务场景和未来的业务形态进行设计。阿里云栖社区大神提出的核心服务的概念，有兴趣的可以去看一下，我挺赞成这种架构设计的，能很好的解决分布式事务的问题，降低系统的复杂性。

关于重构

横切做项目，纵切做产品。虽然不能以偏概全，但也能算上百分之八九十了。经手的项目，有十几二十个微服务也算正常，网状般的交互确实让人头疼。在抱怨之前，可以先想想为什么要这样设计，当时的业务场景是什么样的。我觉得往往被埋怨、被淘汰的设计，大多数在设计当初都是合理的，只是没有考虑到未来的业务市场，没能通过时间的考验。微服务微服务，讲究的是一个敏捷开发，我认为出现不合理的架构设计，就应该马上重构，而不是打上补丁，将错就错，最后的结果无非重构不动了系统被弃用，或者天降猛男完成重构。前人种树，后人乘凉，前人挖坑，后人填坑。程序员要为自己写下的每一行代码负责。

面试总结

印象深刻的面试题

缓存和缓冲

缓存简单来说就是用空间换时间的一种方式，优化了读的性能。
缓冲是对写性能的优化，从单个字节写，到先把数据放入缓冲区，然后再一起向硬盘写入。

redis为什么快

仅仅回答基于内存操作和单进程单线程模型是不够的，面试官想考察的是你对redis数据结构有没有更深层次的理解，什么样的业务场景用什么样的数据结构等等。

为什么处理高并发不用redis单进程单线程模型

这个问题挺新颖的，当时我只想到了多线程锁和资源争抢排队以及线程切换带来的cpu性能损耗的问题。但面试官鬼魅一笑，就此带过。回去想了挺久的也没什么思路，后来去问了架构师，他说因为现在提供的主流框架和中间件，都是多线程的适配模型，总不能你自己去开发一个单进程单线程的框架来使用吧，我觉得还是有点道理的，但还不是最好的答案，还需要在日后的工作中好好思考了。

16G的笔记本怎么跑20个微服务

回答完设置启动参数的大小我就觉得自己想的太天真了。果然面试官又是鬼魅一笑。有兴趣的自行百度一下虚拟机技术和tomcat的共享。

未知nacos地址时，配置文件怎么处理

场景是这样的，有20个微服务需要部署在客户的私有云，客户提供了4台服务器，但是到了现场才会知道具体的ip信息，总不能到了现场再去重新改20个微服务的配置文件然后打包编译吧？我当时的回答是用启动参数的方法去动态配置nacos的地址，这样的话只需要改启动脚本。面试官终于没有鬼魅一笑了。后来我去问了架构师，有一个更好的解决方案，就是所有的配置文件里面nacos的地址都使用域名的方式配置，然后去修改四台服务器的host文件做个映射即可，秒啊。

如何保证相同的用户请求访问的是同一个服务器

解决方案挺多的，说几种。1，没有网关的话用nginx做个哈希即可。2、在网关去重写ribbon的负载均衡策略，根据用户的标识做哈希或者其他的一致性算法。3、利用redis去做session的记录。

写在最后

虽然身处三线小渔村厦门，但也越能越感受到it行业的内卷。面试造火箭，工作拧螺丝也是普遍的现象了。面试的八股文该背的就去背吧，什么线程池啊、hashMap啊、Spring三级缓存原理啊等等。反而对于项目经验以及业务设计的能力没那么重视了，反而出现了劣币淘汰良币的现象。大部门公司的面试题都如出一辙吧，对于中间件原理和源码的考察部分占比偏小，对于数据结构和Spring全家桶的占比较高。个人还是比较心怡在面试中对于业务场景设计和构架设计比较看重以及对于个人学习和日后发展方向考核较多的公司。在老东家的时候也面过不少人，三五年甚至十年工作经验的，对于技术仍然保持激情持续学习的人少之又少，更多的都是在啃老本做重复的crud，不去思考如何造轮子。当然，选择IT这行每个人都有自己的理由，不可能全是因为对技术的热爱。但哪怕是crud，设计模式也能玩出花来不是吗？所以，在负重前行时，也需要多多思考，为什么要这样做，有没有更合适的解法。