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

本周的学习内容围绕着在分布式存储系统如何做到高可用的，分别从关系型数据库、NoSQL这两类存储来进行学习。此外还学习了分布式系统的CAP原理，分布式系统中对服务路由至关重要的路由服务ZooKeeper，现代互联网技术中常用的搜索引擎ES。可以说这周都是围绕的分布式系统来介绍各类技术背后的原理。

分布式数据库

在大规模系统中，为了解决并发读，我们可以使用主从模式，使用binlog进行主从复制。写主服务器，读从服务器，从服务器可以有多台。

在高可用的要求下有演化出多主服务器，进行主主复制，写入可以往任何一台主服务器写入，主服务器之间进行数据同步。当一台主服务器失效时，另一台承担所有写入操作，待失效恢复后，再进行失效期间的数据同步。

在写入高性能和可水平扩展的要求下，又进一步演化出数据分片，通过写入或读取字段的值进行数据的分片，通过一致性算法映射到具体的一台服务器上，这里重点学习了后期服务器扩展时，我们可以通过预先埋点更多的虚拟节点的方式，减少后期对数据迁移方案更多复杂的麻烦。

NoSQL

在分布式关系型数据库对水平伸缩不太友好的情况下，我们提出了使用NoSQL存储进行分布式存储的方法。通过K-V这样的数据结构，在路由算法确定的情况下，把数据存储到对应的存储服务器上。当然这里需要掉关系型数据库的一些ACID保证。

CAP原理

CAP原理告诉我们对分布式系统，应该对一致性、可用性和分区容错性在不同的需求下，进行有优先级的取舍，通常我们会按照P A C这样的顺序进行要求。很多大型系统本身就有各类异地写的延迟，所以一致性基本都是无法满足的，我们要求的最终一致性。

ZooKeeper

在分布式系统中，如何判断集群中哪些服务节点可用，这里就引入了ZooKeeper，也就是通常说的服务网关或服务路由组件，Zookeeper通过保持心跳检测的方式做健康检测，一旦丢失心跳触发策略，Zookeeper作为服务网关就要告诉客户端某些服务节点已经失效，不要再去请求这些服务器。当服务节点恢复后，又会加到服务路由列表中，正常对客户端提供服务。

ZooKeeper自己本身也可以搭建集群，而集群内部通过投票选举的方式选出Master，当Zookeeper本身出现故障时，会通过内部仲裁重新选出新的Master服务器对外提供服务。

搜索引擎

当前互联网存储服务中，存储的关系型和NoSQL存储不能满足全文内容检索，这时候就引入了搜索引擎，而搜索引擎通过倒排索引的方式进行数据检索，利用分词器把关键词和文档进行关联，通过关键词之间的相关性打分，来最终选出匹配的文档和文档匹配度排序。目前使用最多的是ES（ElasticSearch）。



同时我们还以Doris这个分布式存储系统的案例来重新梳理了一遍在分布式系统中故障转移和故障恢复的流程，以及过程中需要的一些注意点，例如如何快速进行失效数据同步，是通过文件拷贝的方式进行数据备份。



总的来说，这一周主要是学习了在分布式这样复杂的环境下，存储服务上面对一致性的需求，我们如何提供合理有效的方案去解决问题，尤其是对后期数据存储扩容的一些细节过程收获很大。