架构师训练营 week6 学习总结

分布式关系数据库

MySQL 复制注意事项：

 • 主主复制的两个数据库不能并发写入。 

 • 复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力。

 • 更新表结构会导致巨大的同步延迟。



CAP原理与NoSQL数据库架构

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

可用性Availability 可用性是说，每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write），也就是说系统需要一直都是可以正常使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的。

分区耐受性Partition tolerance 分区耐受性说，即使因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然应该是可以操作的（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。

CAP 原理 

当网络分区失效发生的时候，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据的一致性就得不到保证。 

对于一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。 

当网络分区失效，也就是网络不可用的时候，如果选择了一致性，系统就可能返回一个 错误码或者干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不能保证这个数据是最新的。 

所以，关于 CAP 原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下， 可用性和一致性无法同时满足。



ZooKeeper与分布式一致性架构

分布式一致性算法 Paxos

Zab 协议

ZooKeeper API 

String create(path, data, acl, flags) 

void delete(path, expectedVersion) 

Stat setData(path, data, expectedVersion) 

(data, Stat) getData(path, watch) 

Stat exists(path, watch) 

String[] getChildren(path, watch) 

void sync(path) 

List multi(ops)



搜索引擎的基本架构

文档与倒排索引

Lucene 架构

Lucene 索引文件准实时更新

索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大 时效率很低，并且由于创建一次索引的成本很高，性能也很差。 Lucene 中引入了段的概念，将一个索引文件拆分为多个子文件，每个子文件叫做段，每 个段都是一个独立的可被搜索的数据集，索引的修改针对段进行操作。 

• 新增：当有新的数据需要创建索引时，原来的段不变，选择新建一个段来存储新增的数据。 

• 删除：当需要删除数据时，在索引文件新增一个 .del 的文件，用来专门存储被删除的数据 ID。当查询时，被删除的数据还是可以被查到的，只是在进行文档链表合并时，才把已经删 除的数据过滤掉。被删除的数据在进行段合并时才会被真正被移除。 

• 更新：更新的操作其实就是删除和新增的组合，先在 .del 文件中记录旧数据，再在新段中添 加一条更新后的数据。 

为了控制索引里段的数量，我们必须定期进行段合并操作。