架构师训练营 第六周 学习总结

感悟

机会都是靠自己争取的

不要指望机会会打包好了送到你的面前，机会都是靠自己争取来的



站在更高的角度去学习与思考

光会用别人的框架是不够的，如果想变得卓越，那就要站在设计者的角度去思考如何设计，这样你的思维水平就和设计者的保持一致，甚至超越。



不要害怕被质疑

被质疑说明有人关注你，说明别人已经认可你的江湖地位了。最怕没人关注，没人理。



迎难而上

要迎难而上，做架构师肯定会被人怼，被人喷，不要害怕，要做好心理准备。



以下是一些老师回答的比较有价值的问题

面对众多的备选方案，架构师需要弄清哪些事情？

1. 软件产品与它们适合运行的环境之间的对应关系

2. 将软件产品以恰当的方式组合起来解决复杂的问题



如果有一个很有创新性的想法，如何获得老板、同事的支持？做不挣钱的框架，如何向公司传递信息，如何让公司支持你？如何做出特色？

方案需要有创新性，要能打动人。目标要有吸引力，并且是能达成的。一定要自己争取，而不是等待别人来提需求。



重点知识点

1. CAP原理

2. 分布式数据一致性

3. Doris NoSQL 分布式数据库案例分析

4. 分布式一致性算法（Paxos、Zab）

5. ZooKeeper 介绍



一致性哈希总结：

什么是一致性哈希？

一致性哈希是用来在分布式缓存集群中，当扩容缓存服务器时，解决数据访问不一致的问题。



核心算法：

1. 构建 2^32 的整数哈希环

2. 将服务器节点的虚拟节点放到环上

3. 将缓存数据的 key 的哈希值也放到环上

4. 顺时针查找节点，并根据虚拟节点对应到实际服务器节点



数据库增加服务器扩容如何解决？

1. 根据需求事先评估需要的数据分片，定义好足够多的 schema（数据库）

2. 多个 schema（数据库） 放在同一台服务器上

3. 当扩容服务器的时候，只需要将 schema 的 data 文件复制到新的服务器即可，具体迁移过程如下：

4. 将 schema 的 data 文件复制到新的服务器

5. 随后通过主从复制，逐步让新的服务器追上并和原来的服务器保持一致

6. 数据一致后，修改数据分片的路由（修改数据库uri即可）

7. 最后再销毁原来服务器上的 schema



关系型数据库与nosql的原则差异

ACID(酸) vs BASE(碱)

ACID

1. 原子性（Atomicity）

2. 隔离性（Isolation）

3. 持久性（Durability）

4. 一致性（Consistency）



BASE

1. 基本可用（Basically Available）系统在出现不可预知故障时，允许损失部分可用性，如影响时间上的损失或者功能上的损失。

2. Soft State （弱状态）软状态，指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3. Eventually Consistent（最终一致性）



CAP 原理 - 3 者无法同时满足

Consistency - 一致性

每次读取的数据应该是最近写入的数据或者返回一个错误(Every read receives the most recent write or an error)，而不是过期数据。也就是说，数据是一致的。

Availability - 可用性

数据当一次读写操作请求的时候，一定要有一个返回，不能失去响应或者超时，或者返回错误。

Partition Tolerance - 分区耐受性

当网络分区失效的时候，整个系统还能正常运行。



CAP 原理启示：架构设计中很多东西互相冲突，无法同时满足。

常用的解决数据一致性的方案，牺牲一定的C达到AP。

最终一致性

最终一直写冲突

客户端冲突解决