架构师训练营第六周总结

分布式数据库



主从复制

MySQL主从复制使用一台Master一台Salve两台数据库服务器组成主从复制，主库负责写，从库负责读，有效降低了主库的读写压力。主库上所有数据更新都记录在binlog之中，从库会定时从主库读取binlog然后保存为relaylog，并由从库的sql执行线程执行重放以达到数据同步的目的，从库可以有多台，以分散读请求压力。MySQL主主复制，实际上客户端还是只会写入一个主库，另一个主库平时会自动同步数据，每个台主库又可以有多台从库用于处理读取请求，一旦写主库发生故障，会自动转移到备用的主库继续写，同时读请求也会转为发送给备用的从库，至此备用主从就转变为了主主从，等到故障的主库恢复后，会从备用主库同步数据成为备份主从，主主复制主要是提高了数据库的可用性。



数据分片

分片即将不同的数据记录分散存储在不同的数据库中。常用的分片方式有：硬编码分片，应用代码将分片Key映射成服务器编号；映射表外部存储分片，即查表法，在外部存储Key和服务器编号的对应管理，请求时通过查找该表的方式查出目标服务器；分片会大幅降低数据库的查询能力，需要大量额外代码来访问数据，无法执行跨分片的联合查询，无法使用数据库事务。分片的编码方式又可以分为客户端SDK和分片中间件两种方式：客户端方式即应用引入分片SDK，通过SDK解析SQL语句，然后根据预设的路由规则由执行代理路由到指定的服务器，然后将返回的结果进行合并后返回给应用；中间件的方式，核心模块和SDK方式一样工作，但是在前后端增加了用于远程调用的通讯模块。现在主流采用的是中间件模式。分片之后面临的一个问题就是如果数据继续增长，需要配置新的服务器扩容，如何以最小代价达成，如何迁移数据。数据库分片并不会采用一致性哈希算法，这个算法的问题在于当插入新的服务器节点（或虚拟节点）时，需要计算所有的Key从而决定数据的迁移方向，这个代价非常大。因此，现实中数据库分片多采用预定义数据库schema总数，然后使用Key对schema总数取余来得出Key要保存的schema，每个物理数据库服务器上均匀的存储多个schema，新添加服务器之后只需要将部分schema整体搬迁到新服务器上即可，这个有点类似Redis的存储桶，其实是一个逻辑单元到物理服务器的映射，Key只需要关心分片存储在哪个逻辑单元即可，物理服务器分摊逻辑单元。



NoSQL



CAP原理

一致性C：每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据，也就是说，数据是一致的。即要么拿到最新数据，要么返回一个错误。



可用性A：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的，也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。



分区耐受性P：即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的。



当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性就得不到保证。对于一个分布式系统来说，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不能保证这个数据是最新的。在分布式系统必须满足分区耐受性的前提下，可用性和一致性无法同时满足。



Zookeeper



分布式系统中，不同服务器获得了相互冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，便成为分布式系统脑裂。比如说MySQL的数据主主复制，同一时间只能由一台主库对外提供写服务，客户端如何知道哪台服务器是写主库？当故障发生，服务器迁移的时候，客户端又如何知道这件事？这就需要一个服务器来仲裁，但是提供仲裁的服务器自身也需要高可用，也会有多台服务器，他们的一致性又需要更高一级的仲裁，这就无穷无尽了。因此解决分布式系统的一致性算法闪亮登场，通过Paxos，Zab等协议，类似于投票选举的方式将多数节点承认的共识记录为最终结果。zk最早是为了解决分布式锁，即为了协调资源访问而诞生的，它提供了一些简单易用的API接口，可以实现分布式配置管理，Master选举等场景功能。