【第六周】技术选型（二）

分布式数据库

• mysql 主从复制

• 流程图

• 
  

• 一主多从复制

• 流程图

• 
  

• 优点

• 分摊负载

• 专机专用

• 便于冷备

• 高可用

• 主主复制

• 流程图

• 
  

• 失效恢复

• 
  

• 失效恢复维护过程

• 
  

• 注意事项

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

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

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

• 数据分片

• 挑战：

• 需要大量的格外代码， 处理逻辑变得更加复杂

• 无法执行多分片的联合查询

• 无法使用数据库的事务

• 随着数据的增长，如何增加更多的服务器

• 分布式数据库中间件 Cobar

• 
  

• 实践中的扩容策略

• 关键点在于开始分片时就算好最多需要多少片，开始时将多片放到一个实例上， 扩容时从各个实例上各拿出一些分片组成新的实例

• 数据库部署方案演进

• 单一服务与单一数据库

• 
  

• 主从复制实现伸缩

• 
  

• 两个 web 服务及两个数据库（服务业务分离，数据库也按业务分离）

• 
  

• 综合部署（不同服务的数据库按照规模使用各自的部署策略）

• 
  

NoSQL

• cap 原理

• 一致性 Consistency：每次读取的数据一定是最近写入的，或者返回错误，而不是过期数据

• 可用性 Availability: 每次请求都有响应，但是不保证数据是最新的

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

• 在实践中可以解释为：在分布式系统中必须要满足分区耐受性的前提下，可用性和一致性无法同时满足

• Hbase 架构

• 
  

• Log Structed Merge Tree

• 
  

• BASE

• 基本可用 Basically Available 系统在出现不可预知故障时，允许损失部分可用性

• 软状态 Soft state 允许系统中的数据存在中间状态，并认为该中间状态的存在不影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

• 最终一致性 Eventually consistent 指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时保证系统数据的强一致性

ZooKeeper

• 分布式一致性算法 Paxos

• 
  

• Zab 协议

• 
  

• 架构

• 
  

• 树状结构

• 
  

• 应用：

• 配置管理

• 
  

• 选主

• 
  

• 集群管理（负载均衡与失效转移）

• 
  

• 性能

• 
  

搜索引擎

• 整体架构

• 
  

• 爬虫系统架构

• 
  

• 爬虫禁爬协议

• 
  

• 文档矩阵与倒排索引

• 带词频与位置的倒排索引

• 
  

• Lucene

• 架构

• 索引文件准实时更新

• 
  

• ElasticSearch

• 架构

• 
  

• 分片预分配与集群扩容

•