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

1、数据库分片

如果要提升写能力和存储能力，可以通过数据分片的方式。

通常的做法有：

• 硬编码，使用hash将数据存储到不同节点上，读的时候也是hash到同一节点上；

• 映射表，跟hash类似，只是将映射关系存储到外部配置上；

• 中间件，由于上述分片需要在操作端支持，所以会增加操作端的复杂性，而且需要能够伸缩扩容，所以引入中间件，由它代理实现数据hash分片，伸缩扩容的数据迁移等；主要介绍了Cobar中间件，它实现了数据的hash分片读写，还有扩容时的数据迁移；在实践中，往往将数据以hash片为单位存储，迁移时检查hash片即可，不用每条数据都检查，提高了迁移的效率；

• 分库分表，可以采用业务拆分的方式，将数据拆到不同的库和表，即可以完全利用到单库、单表的能力来提升系统的读写能力；



2、CAP

C：Consistency 即一致性，访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。

A：Availability 即可用性，所有的节点保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。

P:Partition tolerance 即分区容忍性，这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

CAP原理说，一个数据分布式系统不可能同时满足C和A和P这3个条件。所以系统架构师在设计系统时，不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。由于网络的不可靠性质，大多数开源的分布式系统都会实现P，也就是分区容忍性，之后在C和A中做抉择。



3、分布式存储系统Doris的高可用架构设计

解决问题：解决扩容迁移复杂，维护困难的问题。海量分布式KV存储。

目标：透明集群管理，存储可替换；线性伸缩，平滑扩容；易管理、可监控

四个核心组件：Client、DataServer、Store、Administration

关键技术点：

• 数据分区 基于虚拟节点的分区算法；

• 可用性关键场景 节点故障，节点状态：临时失效、完全失效；

• 扩容实时数据迁移 节点数据迁移 失效节点数据迁移到新节点，新节点在未完成迁移之前只写不读，完成迁移后正常读写；

感想：要开发一个新系统新架构，先要向我们的相关方，展示我们现在遇到的问题，然后现有的技术不能够解决的原因，然后再提出解决办法，不能讲的很宽泛，要实际指出能达到的实际功能性非功能目标；还有一个深有体会的点就是老师讲得要做一个开拓者不要做一个coder，每天只会CRUD，就是还是要提高自己的核心竞争力当如果有机会在你面前的时候你要有能力去战胜它，如果你的能力不够那可能你连机会都看不到。



4、Zookeeper

• 用来解决分布式的一致性问题；即分布式系统“脑裂”：多主节点的时候，如果主节点间数据不一致，就会出现故障，客户端不知道以哪个为准；

• 解决方式：通过仲裁节点判断哪个是主节点；

• 分布式一致性算法 paxos: proposer发起提案，acceptors确认并投票，投票结果由learner进行存储；但zookeeper使用的是zab协议（paxos的简化版）：leader向folower发起提案，根据投票结果进行commit；