双非小厂无分布式经验就不能逆袭去大厂了？

点击上方蓝色字体，选择“设置星标”

优质文章，第一时间送达

背景

面试总会遇到一些关系高并发、分布式的问题，可是自己工作中不接触，自学又不深入，这可怎么办？

分布式架构的知识太庞大了，小匠也是管中窥豹，结合自己的经验阐述一下自己的想法。

结合我自己的一些面试经历，从分布式系统的构建体系说一下可能遇到的问题，涉及的技术和解决方案，这便是分布式系统的重点，也是面试的重点。

现象

我们从业务场景入手，用户越来越多，单个系统的内存、磁盘、CPU无法满足业务的需求的时候，需要把单机变成多机来解决问题，那么就需要引入分布式横向的扩充机器以增加吞吐量。针对不同的业务的需要的硬件、带宽、重要性不同，我们又一次做细粒度的拆分，把每一个模块根据业务的上下文进行拆分，这样就有了微服务。

那么同时也引发了一些问题，一个请求需要协同多个服务来解决，势必会出现数据不一致的问题？那么我们就需要在 CAP 中间做取舍，同时需要在幂等、分布式事务、分布式锁、重试、补偿等方便着重考虑每个服务之间的依赖和数据传输。最后针对不同的业务可以做到熔断、降级等处理。

擦，对于一个工作本就没有机会接触这么多名词的人，如何应对这么“卷”的互联网面试？

何如？

首先推荐两本书，它们并不能解决你遇到的面试问题，而是提供一个通用的思路和解决方案。
《大型网站系统与JAVA中间件实践》
《大型网站技术架构：核心原理与案例分析》
还有一个小册子，这个我快速看了一下还不错，可以快速的了解一些关键概念。
《分布式原理介绍》

那么有人继续追问，截止到现在你其实说了一堆废话，我还是一头雾水，怎么解决自己没有分布式项目的经历，怎么觉得自己面试过程中提及分布式问题的困难的？

答案只有一个就是学以致用，因为你啃书再透彻，自己的练习 demo 写的再完备，对上面罗列的技术和知识点依然是一知半解。

下面说一下我的亲身经历，想办法自己推动现有项目做技术变革，实在不行也可以做“伪变革”。

当时我的项目使用的并不是分布式架构，我接到需求一个，大概评估了一下需要 3 周完成，于是我用自己业余时间调研了一下接入 dubbo 需要多少时间，差不多需要 5 周，于是我就直接和主管说，我想使用 dubbo 来做这个需求，大概需要 5 周时间，但是可以解决我们项目的耦合问题，增加复用度，百利无一害。不过考虑到工期问题，我可能需要每天加加班，一次来保证进度问题，这个您放心。果不其然主管也答应了，那么接下来就是我发挥的时候了，学的东西用到真实的项目里面才能真正的体会其中的奥妙。

这就是我学 dubbo 的经历，还有另一个类似的经历，我加入公司的时候还不是前后端分离的项目，开发成本太高了，当时火的还是 angular，于是我主动请缨，唇枪舌战最终使用spring boot + angular 做了一次重构，虽然当时也加了很多班，但是成长很多，现在想想也挺感谢当时的领导的。

经历这两件事以后我对这些技术的理解又不一样了，如果你和我一样，一样没有大厂的经验傍身，也没有足够的环境让你接触新技术，同样可以一样和我做类似的尝试……

假如？

当然即便是这样你接触的分布式架构也是冰山一角，但是足够入门，后面就需要不断的完善自己的架构了，比如考虑缓存的接入，分布式锁的接入，分布式事务的接入，消息队列的接入，再后面考虑熔断、降级等组件的加入。这样以来假以时日你就渐入佳境了。

那么问题又来了，假如你也和我一样唇枪舌战最后失败了，没有采纳你的意见怎么办？这里我也有一个经历分享给大家，这也算是一个面试技巧吧。

当时我在学习 Redis 的 zset，基本了解了里面的数据结构、原理和经典的使用案例，于是我把现有的一块逻辑生搬硬套到了我们的项目里面，前前后后思考了一下看是否有问题，然后在自己本机搭建 Redis 使用 zset 解决，并完美的解决了所有问题。记得当时这个需求是实现一个每周最热话题，要实时更新的那种。说到这里你是不是又学到了？这就是我上面说的“伪变革”。

最后

最后无论你选择那种思路，都不要放弃自己那份求知的热情，时刻保持自己的竞争力。