自己工作中一直接触不到高并发、分布式怎么办?

·  阅读 25074

背景

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

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

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

现象

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

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

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

何如?

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

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

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

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

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

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

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

假如?

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

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

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

最后

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

分类:
后端
标签:
分类:
后端
标签: