1技术原理相通性的应用
使用方法提高效率
如何建立知识体系？
知识体系的不同层次
Know-What(客观的认知)
Know-How(能力的认知)
Know-Why(规律原理的认知)
Mentor(交流传递隐性知识)
Publish(交流传递显性知识)
Innovation(知识创新)
技术知识体系
- 第一层次:知道有哪些技术
作为一名软件开发人员，首先需要明确目前市面上存在的主流技术，包括本课程包含的Spring、Mybatis、Dubbo、spring cloud在内的各种工具、框架、第三方工具库等，这是技术知识体系建设的初级阶段，绝大多数开发人员都要经历这一阶段 - 第二层次:知道技术背后的原理
知道各项技术背后的原理是技术知识体系建设的第二个阶段，我们不仅仅需要知道各种技术体系的具体表现形式，更应该掌握其背后的设计思想、原理和实现机制。这是高级技术人员与普通开发人员之间的本质区别，也是个人知识体系建设所需要的关键阶段 - 第三层次:知道技术在具体场景应用
在知道技术背后的原理之后，我们就能够明白各项技术的应用场景。这-阶段实际上已经是一个非常高级的阶段，涉及到了技术选型和技术创新等工作内容
技术原理学习模型？
理论
- 第一阶段:单点突破
深入分析一两个核心框架并抽象其技术理论，分析和抽象基本途径：源码解读 - 第二阶段:以点概面
广泛了解其它框架和技术体系，尝试使用一阶段中构建自己的技术知识体系剖析这些框架。
如不能，回到一阶段继续沉淀
理论指导实践，一定要从纷繁复杂的技术知识体系和各种层出不穷的工具框架中抓住其背后的原理，然后用自己的语言和方法对这些原理进行阐述，也就是能够构建属于你自己的技术知识体系（用自己的话把技术原理整理出来）
实践
单点突破 、以点概面 需要3~5个循环
对于初始阶段，可以找类似MyBatis、Spring等相对比较独立的主流框架入手，然后逐步过渡到Dubbo、Zookeeper等综合型框架
完成初级阶段之后，可以在不同的循环中针对不同的知识体系做相应的规划，针对分布式、微服务等主题进行专门的学习和训练
相通性案例
技术原理相同性分析-RPC架构
Dubbo
分布式服务框架，实现RPC和服务治理（分布式服务不可缺少的组件）
理解了RPC和服务治理，对同类新框架则一通百通。
理论 理解框架设计原则和思想
实践 灵活应用设计原则和思想解决实际开发中的困难
提升 基于框架高于框架，掌握业界其他主流框架
技术原理相同性分析-分布式协调
解决分布式环境中多进程同步控制问题，让它们有序的去访问某种临界资源，防止系统中出现各种”脏数据”的后果。
分布式协调应用场景
服务治理
分布式锁
配置中心
热备切换
技术想通性
- 提供集群的集中化配置管理功能，不重启新配置即时生效
- 提供简单可靠的集群节点动态发现机制，确保节点上线和宕机能立即通知，实现复杂的故障恢复功能
- 提供简单可靠的节点Leader选举机制，从而解决中心化架构集群中Leader选举问题
- 提供分布式锁，确保集群共享数据不被破坏等
如果掌握了分布式协调相关的知识体系，那么碰到配置中心、分布式锁的具体实现工具和框架同样可以做到触类旁通
分布式协调框架-Zookeeper
客户端Watcher监听ZK结点，结点状态发生变化通过回调函数触发相应操作。详解如下：（核心功能）
会话（Session）：客户端和服务器端的TCP连接短暂(Ephemeral)性和临时节点
监听器（Watcher）：分布式的回调(Callback)任何读操作都能够设置Watcher
Client关注的ZNode发生变化->消息传回到Client->Client的消息处理函数得到调用
服务治理
服务注册
服务发现
分布式锁
- 所有访问Zookeeper的客户端都会注册为临时节点
- 每个节点在创建时都会生成一个唯一的递增序号
- 客户端获取节点列表并排序，如果自己节点的编号最小则获取锁
- 反之监听排在自己前面的节点，如果监听到该节点被删除则重新执行排序
Master可用性
Yarn框架举例
- 创建锁节点
所有RM启动的时候，都会竞争写一个临时Lock子节点。Zookeeper能保证只有一个RM能创建成功;创建成功的RM切换为Active状态，没有成功的切换为Standby状态 - 注册Watcher监听
所有Stendby RM节点都会对Active RM节点注册Watcher;Watcher机制感知Active RM运行情况 - 完成主备切换
Active RM异常时，它的客户端会话就会失效该节点就会被删除;其余Standby RM会接收到Watcher事件通知，再重复步骤1
总结
以Zookeeper例，服务治理、配置中心、分布式锁、主从切换机制的背后其实都是利用了它的Watcher机制。
只要我们掌握了这一机制，对于那些并不熟悉的应用场景同样可以梳理正确的技术方案。
技术原理相通性案例分析-Gossip协议
Gossip(中文就是流言蜚语的意思)协议指的就是在一个有界网络中，每个节点都随机地与其他节点通信。经过一番杂乱无章的通信之后，最终所有节点的状态都会达成一致，本质上也是最终一致性的一种具体体现。
通过Gossip协议所构建的集群从种类上讲属于对等集群(PeerTo Peer Cluster)，节点之间完全对等，不需要任何中心节点，是去中心化思想的一种具体实现。即使有的节点因宕机而重启，有新节点加入，但经过一段时间后，这些节点的状态也会与其他节点达成一致，因此Gossip协议天然具有分布式容错的优点。
应用框架：Redis、Cassandra、Elastic search
效果和优势
去中心化
优势：集群规模增加不会增加单个节点负载(这就允许集群规模能横向扩展到数千个节点)
在所有节点之间运行Gossip协议，服务器节点和普通节点都会加入这个Gossip集群，收发Gossip消息。
每隔一段时间，每个节点都会随机选择几个节点发送Gossip消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。
通信方式
- push
A节点将数据(key,value,version)及对应的版本号推送给B节点
B节点更新A中比自己新的数据 - pull
A仅将数据(key,version)推送给B，B将本地比A新的数据(Key,value,version)推送给A，A更新本地 - push/pull
与pul类似，只是多了一步，A再将本地比B新的数据推送给BB更新本地
Redis实现
Meet消息
用于通知新节点加入。消息发送者通知接收者加入到当前集群，Meet消息通信正常完成后接收节点会加入到集群中并进行周期性的Ping、Pong消息交换Ping消息
集群内交换最频繁的消息，集群内每个节点每秒向多个其它节点发送Ping消息，用于检测节点是否在线和交换彼此状态信息。Ping消息发送封装了自身节点和部分其它节点的状态数据Pong消息
当接收到Ping、Meet消息时，作为响应消息回复给发送方确认消息正常通信。Pong消息内部封装了自身状态数据。节点也可以向集群广播自身的Pong消息来通知整个集群对自身状态进行更新Fail消息
当节点判定集群内另一个节点下线时，会向集群内广播一个Fail消息，其他节点接收到Fail消息之后把对应节点更新为下线状态
思考题
结合日常开发过程和经历，你能列举几个关于技术原理相通性方面的案例吗?