CAP 原理

一致性 Consistency

可用性 Availability

分区耐受性 Partition tolerance

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

最终一致写冲突

简单冲突处理策略：根据时间戳，最后写入覆盖。

客户端冲突解决：在客户端查询到不同的结果时进行合并。

投票解决冲突（Cassandra ）：写入时写入到多个节点，读取时读取多个节点的数据，取最新数据

ACID 与 BASE

ACID：原子性（Atomicity）、隔离性（Isolation）、持久性（Durability）、一致性（Consistency）

BASE：

基本可用（BasicallyAvailable）系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。

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

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

分布式一致 ZooKeeper

分布式系统脑裂：在一个分布式系统中，不同服务器获得了互相冲突的数据信息或者执行指令，导致整个集群陷入混乱，数据损坏，本称作分布式系统脑裂。

分布式一致性算法 Paxos

三个角色：Proposer、Acceptor、Learner

第一阶段：Prepare 阶段。

Proposer 向 Acceptors 发出 Prepare 请求，Acceptors 针对收到的 Prepare 请求进行 Promise 承诺。

第二阶段：Accept 阶段。

Proposer 收到多数 Acceptors 承诺的 Promise 后，向 Acceptors 发出 Propose 请求，Acceptors 针对收到的 Propose 请求进行 Accept 处理。

第三阶段：Learn 阶段。

Proposer 在收到多数 Acceptors 的 Accept 之后，标志着本次 Accept 成功，决议形成，将形成的决议发送给所有 Learners。

Proposer 生成全局唯一且递增的 Proposal ID (可使用时间戳加 Server ID)，向所有 Acceptors 发送 Prepare 请求，这里无需携带提案内容，只携带 Proposal ID 即可。Acceptors 收到 Prepare 和 Propose 请求后

1.不再接受 Proposal ID 小于等于当前请求的 Prepare 请求。

2.不再接受 Proposal ID 小于当前请求的 Propose 请求。

Zab 协议

Zab 协议分为以下三个阶段：

1）选举：在 Leader 服务器宕机出现问题时，需要从 Follower 中选举一个 Leader

2）恢复：这是 Leader 与 Follower 进行一个数据同步的过程，确保 Follower 与 Leader 保持一致

3）广播：此时表示 Zookeeper 集群可以对外提供服务了

Zookeeper 的使用场景

配置管理

选 master

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

互联网搜索引擎整体架构

爬虫系统架构

爬虫禁爬协议

文档矩阵与倒排索引

文档与倒排索引

带词频的倒排索引

带词频与位置的倒排索引

Lucene 索引文件准实时更新

Lucene 中引入了段的概念，将一个索引文件拆分为多个子文件，每个子文件叫做段，每个段都是一个独立的可被搜索的数据集，索引的修改针对段进行操作。为了控制索引里段的数量，我们必须定期进行段合并操作。

ElasticSearch 架构

索引分片，实现分布式

索引备份，实现高可用

API 更简单、更高级

ElasticSearch 使用技术

倒排索引文件

加权词频排序算法