分布式数据库

复制（Replication）

主从复制、主主复制

分片（Sharding）

数据分片的路由方案：

硬编码：不利于扩展

映射表：需要编写额外的代码，逻辑复杂

基于数据库中间件:MyCAT、Cobar、Ameoba

分片扩容策略：

预先规划好数据库实例数，前期可将多个数据库实例部署到一台服务器上，后期扩容时，选择实例迁移到新的服务器上，然后修改数据库中间件的路由配置。

关于是实例数的选择，网上有一个推荐方案，一开始数据库实例的数量就设置成2的倍数：4、8、16、32，每次扩容服务器都翻倍，即每次都拿服务器上一半的实例拿出来迁移到新的服务器上，管理上比较方便）

NoSQL

CAP原理

Consistency(一致性)：数据的多个副本能够保持一致，数据操作要么都成功，要么都失败

Availability（可用性）：对系统的每次请求都有响应

Partition Tolerance(分区容错性)：当发生网络分区故障是，系统任然能够提供服务

三个特性只能满足其中两个，而在分布式系统中，分区容错性是必须要满足的。那么只有在一致性和可用性之间做出选择。

Zookeeper

脑裂

分布式系统中，不同服务器获得了相互冲突的数据或指令，导致整个集群陷入互联，造成数据损坏，成为系统脑裂。

分布式一致性算法

Paxos协议：三个阶段

Zab协议：Zookeeper默认协议

选主过程

1.尝试获取节点数据并监听数据变动

2.如果成功则将获取到的数据作为主。

3.如果失败则自己创建该节点的数据，推举自己为主。

失效转移

客户端获取配置节点的数据，并监听数据变化

如果数据有变化，则更新当前配置

读写性能

服务器越多，则写入性能越差（因为要写入所有节点），读取性能越好（因为请求被分摊到多个节点）。

搜索引擎

搜索引擎构成

爬虫系统、倒排索引、分词系统、缓存系统

倒排索引

建立单词和文档号之间的映射关系

关于数据库高可用方案的思考

结合选主和失效转移可以构建一种数据的高可用方案：

1.主主复制，Master1,Master2，两台数据库上分别部署agent用来监控本机MySQL运行状态，agent1、agent2代表Master1和Master2参与选主，假定Master1成为主服务器，Master2成为热备。

当Master1宕机，agent1通知ZooKeeper重新选主，Master2推举自己成为工作服务器，此时Zookeeper中的配置为Master2的数据源配置

应用程序监听Zookeeper中数据源配置节点数据，发现发生了变化，则将数据源配置改为Master2的数据源，同时关闭原有的数据库连接，重新建立与Master2之间的连接。

2.MyCAT结合ZooKeeper也是一种方案，当数据库宕机，MyCAT的配置切换到热备。这里面还考虑到MyCAT存在单点故障的问题。MyCAT也需要借助ZK搭建集群。

3.此外通过keepalived的vip(虚拟IP)实现故障转移也是一种思路。虚拟IP的方案实现起来比较简单，但由于vip是基于arp协议，必须在一个局域网内，如果要通过路由，则还是选择zookeeper方案。