架构师训练营 第五周 个人感想

0 期 3 班 4 组 杨娴艳



课程已经进行得到了第五周，本周智慧老师的课程内容涉及分布式缓存架构、消息队列与异步架构、负载均衡架构和分布式数据库，每一个知识点都是架构领域的硬菜，所以课后还是抽出时间再听了一遍，听完以后的感受是，还需要再听几遍。缓存、消息队列、负载均衡、分布式数据库，特别是后面两个知识点，需要有一定成熟的运维经验的人才可以全面的掌握，这对我来说的确是不小的挑战，但就像智慧老师讲的，很多细节上的东西我们未必需要现在就去深入了解，譬如负载均衡的路由到底是怎么转发的，但是方案上我们必须要了解，这就明确了架构师的职责，需要针对一个业务（技术）场景给出合理的技术解决方案，这个方案可能是有一定的弊端的，但肯定是在当前的场景下权衡过后较为合理的。我们想要作为架构师，必须掌握这些能力，方法包括：阅读和学习相关的书籍和课程、通过公有云相关产品的学习和实验进行实践、在工作中尽可能参与这方面的实操。



本周学习到的内容很多，以下就几个方面谈一下自己的收获和感想。

1、（基于虚拟节点的）分布式对象缓存一致性算法的学习感受

智慧老师很善于推演解决方案，并且注重一个技术背后的实现原理，所以也是这周课程的难度提高的原因。在缓存章节，当了解了缓存的基本概念后我们学习了缓存的存储数据结构，推导出基于余数的Hash算法；第二步，通过业务需求的变更，需要加缓存节点后推导出基于余数的Hash算法不能满足当前的业务场景，为解决该问题，介绍了环形的分布式对象缓存的一致性算法；第三步，基于上述算法，即便保证了先前的节点缓存的可用，但是新增的节点并没有分摊其他节点的压力，甚至在极端情况下只有极少的缓存数据会到新的节点上，没有达到新增节点的目的，继续推演出基于虚拟节点的分布式对象缓存的一致性算法。

这是一个特别有趣的过程，同时要注意的是在老师的算法讲解中需要特别注意一些细节，譬如虚拟节点的hashcode在虚拟节点数变化的过程中需要保持不变，这就要求我们在初始化虚拟节点的时候可以通过生成有规则的字符串生成hashcode，这些细节在本次略有“难度”的作业的编写过程中我深有体会，很多时候，大致了解了一个概念，也能清楚的说出来，但是涉及到实操的时候会发现有很多细节未必是自己掌握的，需要真正掌握全面就是要严格要求自己知其然知其所以然，这也就能过够理解为什么大厂面试的时候喜欢问JVM、线程池、并发等基础知识了，只有了解了原理才能说真的掌握了技术本身。

2、技术的纯粹

智慧老师在谈到缓存技术的使用时一再强调，缓存的作用就是为了能够在访问重复的数据的时候提高访问的性能，这就要求我们在用缓存这个技术的时候，非常的清楚目前想要缓存的数据是什么？是否是热点数据？是否会被频繁修改？而不是为了想要用缓存技术而用缓存。在使用过程中，特别是使用集群的时候也要非常清楚譬如一致性算法的原理，才能避免一些随意的操作导致的缓存穿透和缓存雪崩等恶性的后果。

回想起来，之前在做某电商业务的订单定时取消环节过程中，当时和一位前辈在讨论技术方案的时候，我当时了解到Redis有一个特殊功能就是可以在缓存TTL失效的时候发事件，那应用程序可以监听缓存失效事件进行订单的取消，当时的前辈一下就否定我的方案，直接就说，这个就是应该用纯粹的消息队列的技术方案去实现，后续证明通过Rabbit MQ消息队列去做延时业务非常的合适和顺利。这个例子未必能说明一切，但给我的启发就是，做任何事情都要走“正道”，用最合适的方案解决业务场景下的技术问题会让解决发难变得更加存粹、有效。

3、了解技术背后的架构思想

代码千千万、技术千千万，就像在学习面向对象分析和设计思想以及设计模式一样，只有了解了本质才有机会去掌握解决问题的能力，老师课上提了一句集群和分布式的区别是什么，后来又思考了一下说了一句“未必特别重要”，但是在我看来，清楚的了解分布式和集群的概念其实是很重要的，这在我们解决问题的时候，决定了我们当前是要解决高可用的问题、还是解决性能问题、可扩展性的问题而采取何种方案。就如智慧老师说的，架构师不能只关注技术，更要了解技术背后的思想，有一种敏锐和洞察力，在问题出现的时候能够像肌肉反应一样脑袋就跳出一系列可筛选的方案。这个能力需要的是特别扎实的理论基础、有一定的实践实操经验、在实操过后的思考这一系列的过程后才能掌握的。



路漫漫兮，前路很难，但选择了这个职业就要做到极致，唯有不断加油！