第六周 - 总结

一、分布式数据库（关系型数据库本身的设计就不是为了分布式场景使用的）

1、MySQL一主多从：

从服务器单开一个线程，同步主服务器的BinLog日志，将数据同步到从服务器中。

优点：分摊负载、专机专用（多个从服务器，不同的系统用不同的从服务器读取数据）、便于冷备、高可用（但主服务器实现不了高可用）。

2、MySQL主主复制：

多个主服务器，住服务器之间的BinLog相互复制同步。

优点：写服务器的高可用。

一般来说，我们应该保证主主服务器之间是不会同时进行操作的。因为两个服务器同时进行操作，数据同步就会有可能出现问题。

缺点：主主服务器之间不能并发写入。

3、注意事项：

复制只是增加了读数据的能力，没有增加写数据的能力和存储的能力，更新表结构会导致巨大的延迟（会导致主服务器的数据没有及时同步到从服务器上，实践中会关闭表结构的同步，而是选择一个合适的时间，手动同时修改这两个数据库的表结构）。

4、数据分片：

将一张数据库的表分成若干片分别存储在不同的数据库上。

实现方法：

1. 硬编码：在代码中，根据某个字段来分派写入到不同的数据库上。

2. 映射表外部存储：在一张表中存储了要分片的表的字段和数据的关系。

优点：提升高并发能力，和写数据的能力。

缺点：需要额外编写处理代码，处理逻辑变得复杂。无法执行多分片的联合查询，无法使用事务。

5、分布式数据库中间件：

1. MyCat：应用程序和Mycat连接，Mycat和分布式数据库连接。

2. Cobar：应用程序使用JDBC程序反访问Cobar服务器集群，通过负载均衡选择一台Cobar服务器再连接一台具体的Mysql服务器。

6、数据库部署方案：

1. 单一服务器，实现主从复制。

2. 按照业务不同，部署不同的数据库，每个业务数据库实现主从复制。

3. 某个业务数据库实现数据分片，每个分片又做主从复制。

二、NoSQL数据库CAP（原生支持分布式数据存储）

1、CAP理论：（在们组P的情况下，一致性和可用性是不可能同时满足的）

1. 一致性Consistency：

每次读取的数据都应该是最近写入的数据或则是一个错误，而不是一个过期的数据，也就是说数据是一致的。

2. 可用性Availability：

每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过不需要保证数据是最近写入的。也就是说系统需要一直是正常可用的。

3. 分区耐受性Partition tolerance：（这个在分布式系统中是必然存在的）

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

当P发生时，也就是网络故障发生时，同时又两个用户修改了数据，如果要保证一致性的话，就要等待其它的系统节点同步这个数据，此时其它系统用户就不能操作这个数据了，可用性A就保证不了了。如果要保证可用性，那就是要单独将数据写入自己的系统但是其他的系统就会同步不到这个数据，也就保证不了一致性C。

4. 最终一致性：当网络发生问题时，为了保证系统可用性，一致性无法保证时。经过一段时间后，网络恢复了，数据同步过来了，此时查询数据就是一致的。这就是数据最终一致性。两个服务器都修改了数据，数据的同步方法：1)根据时间戳，最新的数据覆盖旧的。2)交由客户端判断使用哪些数据。3) Cassandra过半投票，当服务器中的数据有不一致的时候，取多数据服务器存储相同的数据，存储的数据是不一致的，但是返回的数据是一致的。

Hbase，数据时存储在底层的Hadoop分布式文件系统中的。通过Zookeeper来管理HMaster集群，HMaster选择任一的HRegionServer服务器。

2、ACID和BASE：

传统的事务的数据库ACID：

原子性Atomicity，隔离性Isolation，持久性Durability，一致性Consistency。

NoSQL数据库的事务BASE：

基本可用Basically Available，系统出现故障时，允许损失部分的可用性。

软状态Soft State，允许系统中的数据存在中间状态，并认为中间状态的数据不会影响系统的整体可用性，即允许系统在不同节点之间的数据同步过程存在延迟。

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

三、Zookeeper与分布式一致性

1、分布式系统脑裂：

在一个分布式系统中，不同的服务器（写数据）获得了互相冲突的数据信息或者指令（如同时修改一条数据，两个服务器同步的时候就不知道应该是以哪个为准），导致整个集群陷入混乱，数据损坏。

解决，只有一个写服务器能写入数据，其他的写服务器只能是当这台时效的时候，其他的服务器竞争当选master写服务器。

2、分布式一致性算法：

1. Paxos协议：

2. Zab协议

3、Zookeeper应用：

1. 配置管理：将一些重要的配置放在Zookeeper上。

2. 帮助其它系统选举Master：

3. 集群管理

四、分布式搜索引擎

1、倒排索引：

正排索引：是记录文档中有哪些词，以文档搜索词。

倒排索引：是记录词关联的文档有哪些，以词检索文档。是以一个哈希表保存的词与文档id的一个关系。所以根据词搜索就会很快，及时数据有几万亿条。

2、带词频的倒排索引：

1. 一个词在一个文档中出现的次数越多，说明这个此对该这个文档就越重要。

2. 将词在文档中出现的频率次数和文档的id组合起来（1;8），保存在倒排索引中。

3、带词频与位置的倒排索引：

将词在文档中的出现频率和位置，记录在倒排索引中。

4、Lucene（不支持分布式）：

1. 保存数据：将数据源的一些数据，经过分词，建立倒排索引，然后将数据存储起来。

2. 查询数据：将查询的词讲过分词，然后将分词交给查询器，查询器再将数据到搜索模块，搜索模块到数据存储里搜索数据，合并数据，返回结果。

3. Lucene索引文件实时更新：

当有新的文档，或文档修改删除时，索引文件就要更新了，如果重建索引文档，就会耗时很长，成本较高。

Lucene使用分段的办法，将一个索引文件拆分成多个子文件，每个字文件就叫做段。

新增文档时，新建一个段来保存索引数据。

删除文档时，新增一个.del文件，保存被删除的数据，数据查询时要过滤掉这些数据。

更新文档时，就是先删除，再新增。

但是这样时间一长，段就会变得很多，查询就会变得很慢，所以要定期合并段。

5、ElasticSearch：

索引分片，实现分布式。

索引备份，实现高可用。

API更简单、更高级。

注意点：创建索引的时候，需要指定好分片的数目。

五、NoSQL-Doris：