上周内容

上一周和本周主要讲了互联网架构中各种具体技术手段。有：分布式缓存、负载均衡、消息队列、分布式数据库、NoSQL、CAP 理论、分布式一致性、Zookeeper、搜索引擎，Doris。本周主要学习：分布式数据库、NoSQL、CAP 理论、分布式一致性、Zookeeper、搜索引擎、Doris。

缓存提高了读的性能，常见的缓存有 CPU 缓存、操作系统缓存、数据库缓存。常见的分布式系统缓存有 CDN 缓存、反向代理缓存、应用程序缓存、分布式对象缓存（Redis、Memcahed）。可以在所有请求资源的地方使用缓存来提高读的性能。缓存内存管理算法有：LRU（最近最久未用算法）。缓存的关键指标是缓存命中率。缓存集群伸缩才用一致性 Hash 算法有：Hash 取余，基于节点的一致性 Hash 算法，基于桶的 Hash 算法。

缓存的使用注意事项：数据不一致与脏读、缓存雪崩、缓存预热、缓存穿透。

消息队列提高了写的性能。消息队列架构的三个角色：消息队列、消息生产者、消息消费者。两种模型：点对点模型和发布订阅模型。消息队列的好处：异步处理，提升写性能、更好伸缩、削峰填谷、失败隔离，自我修复，解耦。经典软件架构方式：事件驱动架构-EDA。

这里主要说的是 HTTP 请求的负载均衡，对于 Nosql、Grpc 服务，他们的分发方式可能基于某个高可用的分布式中间件来实现或者自身实现了分发方式。负载均衡架构的两个关键点：1.请求如何分发；2.负载均衡路由算法。负载均衡的分发方式：HTTP 重定向负载均衡、DNS 解析负载均衡、反向代理负载均衡、IP 层负载均衡、链路层负载均衡。负载均衡算法：轮询、加权轮询、随机、源地址散列、最少连接。

负载均衡和会话管理，都是关于如何构建集群的一些知识点。

本周内容

分布式关系数据库

分布式关系数据库通过复制来提高读性能、通过分片来提高写性能。Mysql 复制两种有：主从复制、主主复制。数据分片可以采用一些中间件来实现，这样可以将分片的逻辑和应用程序完全隔开。常用的分布式分区中间件有：Mycat、Cobar 等。

分布式关系数据库部署方案

• 单一服务与单一数据库

• 主从复制实现伸缩

• 两个 Web 服务及两个数据库（业务分库）

• 综合部署

CAP 原理

CAP 定理是说：在一个分布式系统（指相互连接并共享数据的节点的集合）中，当设计读写操作时，只能保证一致性（Consistency）、可用性（Avalibility）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲掉。注意：牺牲掉并不等于什么都不做，需要为分区恢复后做准备。



• 一致性（Consistency）是说：每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据。

• 可用性（Avalibility）是说：每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的。

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



CAP 定理是设计高可用的分布式系统的公认的定理，如果是单机的应用则谈不到 CAP 定理，因为数据都放在同一台服务器上，那么就没有分区，没有可用性，没有一致性。而要保证高可用，那么就要讲数据保存在多台服务器上，服务器之间进行数据共享（如 mysql 分片集群，如 Redis 的分片集群），正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA。因为要数据共享，所以就有了分区、就会有分区现象（数据同步延迟，网络故障，服务器故障等等），就要保证一致性或者可用性。



CAP 关注的粒度是数据，而不是整个系统。C 与 A 之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉到特定的数据或用户而有所不同。要根据实际场景来决定是 CP 还是 AP。



另外值得注意的是，CAP 是忽略网络延迟的。在分布式事务执行的过程中，系统其实是处于一个不一致状态的，不同的服务节点的数据并不完全一致，它们是最终一致的。

分布式一致性架构

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

分布式一致性算法-Paxos 解决多个服务器之间，如何达成一致的，保证对外提供的是统一的决策，或者是一个数据状态。三个角色：提案者（Proposer）、Acceptor（接受者）、学习者（Learner）。

Paxos 协议

通过分布式一致性算法，它即实现了高可用，又实现了一致性。状态是一致的，多个服务器之间，它的状态是一致的。这个状态一致，主要是通过投票来进行选择和决定的。

Paxos 协议的三个阶段

• Prepare 阶段。Proposer 想 Acceptors 发出 Prepare 请求，Acceptors 针对收到的 Prepare 请求进行 Promise 承诺。其他的 Prepare 进行排队等待。

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

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

Zab 协议

Zab 协议中的两个角色：Leader、Follower。

Zookeeper

搜索引擎

互联网搜索引擎架构的三个部分：网络爬虫、倒排索引、通过倒排索引的检索。

倒排索引

Lucene

Elasticsearch

总结和思考