面试总会遇到一些关系高并发、分布式的问题，可是自己工作中不接触，自学又不深入，这可怎么办？
分布式架构的知识太庞大了，我也是管中窥豹，结合自己的经验阐述一下自己的想法。
结合我自己的一些面试经历，从分布式系统的构建体系说一下可能遇到的问题，涉及的技术和解决方案，这便是分布式系统的重点，也是面试的重点。
我们从业务场景入手，用户越来越多，单个系统的内存、磁盘、CPU无法满足业务的需求的时候，需要把单机变成多机来解决问题，那么就需要引入分布式横向的扩充机器以增加吞吐量。针对不同的业务的需要的硬件、带宽、重要性不同，我们又一次做细粒度的拆分，把每一个模块根据业务的上下文进行拆分，这样就有了微服务。那么同时也引发了一些问题，一个请求需要协同多个服务来解决，势必会出现数据不一致的问题？那么我们就需要在 CAP 中间做一个取舍，同时需要在幂等、分布式事务、分布式锁、重试、补偿等方便着重考虑每个服务之间的依赖和数据传输。同时针对不同的业务可以做到熔断、降级等处理。那么这么多名词对于陌生的我们应该怎么办呢？
首先推荐两本书，它们并不能解决你遇到的面试问题，而是提供一个通用的思路和解决方案。
《大型网站系统与JAVA中间件实践》
《大型网站技术架构：核心原理与案例分析》
还有一个小册子，这个我快速看了一下还不错，可以快速的了解一些关键概念。
《分布式原理介绍》
那么有人继续追问，你说了这么多理论依据，我还是一头雾水，怎么解决自己没有分布式项目的经历，怎么觉得自己面试过程中提及分布式问题的困难的？
答案只有一个就是学以致用，我的亲身经历，你啃书再透彻，自己的练习 demo 写的再完备，对上面罗列的技术和知识点依然是一知半解。所以你能做的就是推动当前项目做技术变革。
这并不是天方夜谭，当你接到一个需求后评估时间，发现自己可以用 3 周完成，那么这时间足够了啊。首先快速分析一下当前的业务是否使用什么分布式架构？ dubbo 或者 spring-cloud，接下来尝试通过自己的分布式架构的理解，配合上文中提到的知识点，书籍设计一个架构图。然后快速评估一下接入这个架构需要的时间，如果是5周，那么每天多干 3 小时，周末加加班，是不是就够了呢？然后就是最重要的时候了，拿着自己的架构图和评估时间去找大佬沟通并且给一个 commitment，自己肯定能搞定。如果老大比较开明那么这件事情就简单了，接下来就看你自己的了。
我确实也是这么做的，说两个我自己的实际经历。
加入公司的时候公司不是前后端分离的项目，我于是使用了当时的最新前端技术 angularjs 和 spring mvc 做了一次重构，当然自己也经常加班，不过最感谢的是当时领导的支持。
另一件事就是我们做的系统本身不复杂，然而我个人比较想尝试一下 RabbitMQ，就把系统重构了一下。从 RabbitMQ 的搭建、配置、集成 Spring，最后到监控、优化。
经历这两件事以后我对这些技术的理解又不一样了，如果你和我一样，同样可以做类似的尝试。接下来我就通过这种方式学习了 Dubbo、Spring Boot ……
当然即便是这样你接触的分布式架构也是冰山一角，但是足够入门，后面就需要自己不断的完善自己的架构了，比如考虑缓存的接入，分布式锁的接入，分布式事务的接入，消息队列的接入，再后面考虑熔断、降级等组件的加入。这样以来假以时日你就渐入佳境了。
那么问题又来了，遇到的公司没技术可以学习，也没有领导支持自己技术变革，那么路也有一条就是换一个要么可以学技术的，要么可以支持技术变革的。这个就需要你在面试的时候深入了解下公司的情况了。
作者
更多精彩文章可以扫码关注作者微信订阅号「码匠笔记」，每天接收精彩推文。
