「架构师训练营 4 期」 第六周 - 001&2

一、问题

1. 请简述 CAP 原理。

2. 针对 Doris 案例，请用 UML 时序图描述 Doris 临时失效的处理过程（包括判断系统进入临时失效状态，临时失效中的读写过程，失效恢复过程）。

1.1 简述 CAP 原理

CAP 原理最基础的来说分成三个：

C 一致性：每次读取数据都应该是最新写入的数据或者是返回一个错误，而不应该是一个因为过期或者更新延时导致的错误数据

A 可用性：每次请求都得到了一个相应而不是直接返回一个错误或者失去响应，但是这个响应的数据不保证是最新的写入的数据

P 分区耐受性：因为网络等原因导致部分节点的服务器发生了异常，导致节点间的通讯失败或者延时，这种情况下，保证系统的可用性。

在当前的分布式架构下，P 是一定要保证的，这样子在 C 和 A 上就有一定的取舍关系，再次之后又对 CAP 进行了新的定义，这里面 引入了“一致性的作用范围”这样一种观念，即在一定的边界内状态是一致的，但超出了边界就无从谈起，这也引出了数据最终一致性的说法。比如在一个主分区内可以保证完备的一致性和可用性，而在分区外服务是不可用的。Paxos 算法和原子性多播（atomic multicast）系统一般符合这样的场景。

在实际上的应用来说，可以再入口的 api 层进行固定策略的路由，保证同一批用户短时间内的请求保证在同一个分区中，这样子其他分区延时同步其他分区的数据能够让整个系统更好的同时满足 CAP，这个理念在双机房或者多活的建设中广泛使用的，进一步来说还会有一些数据无法进行分区处理，那就只能放在同一个机房坐好机房的容灾策略，整理来说的话就跟蚂蚁单元化的思路非常形似了。

1.2  Doris 临时失效

失效状态

从初始化到 dataserver-2 服务失效过程中，判断失效和失效状态下的数据表现

恢复状态

二、总结

当前我们主流的或者常见的一些分布式中间件有哪些？包括但不限于缓存、消息队列、负载均衡、关系数据库、nosql 等，这里面必须要有的一些基础的知识点如下：

• CAP 原理

• ACID 和 BASE 原理

• paxos 算法

ACID 为 Atomicity, Consistency, Isolation, and Durability，其中 ACID 分别表示为：

• 原子性（Atomicity）：事务中的操作要么都做，要么都不做。

• 一致性（Consistency）：系统必须始终处在强一致状态下。

• 隔离性（Isolation）：一个事务的执行不能被其他事务所干扰。

• 持续性（Durability）：一个已提交的事务对数据库中数据的改变是永久性的。



BASE 为 Basically Available, Soft-state, Eventually consistent，其中 BASE 分别代表：

• 基本可用（Basically Available）：系统能够基本运行、一直提供服务。

• 软状态（Soft-state）：系统不要求一直保持强一致状态。

• 最终一致性（Eventual consistency）：系统需要在某一时刻后达到一致性要求。

paxos 算法

分布式关系型数据库

mycat  cobar amoeba tddl，这几种架构和设计非常相似，取 cobar 的设计为例，来看里面的架构如何实现？app 提交 sql 到，cobar 之后，前端通讯模块保持跟 app 的通讯，然后通过 sql 解析模块进行解析，根据既定的规则在路由模块进行路由，路由确定到具体的实例之后，会把命令提交到 sql 执行代理模块，到各个实例上进行 sql 的执行，执行完毕之后，后端的数据库通讯模块命令和执行结果返回给 sql 执行代理模块，最后交还给结果合并模块进行结果和并然后返回给 app。

但是这个方案仍然存在编码引入难度大，管理困难，连接池需要应用控制等各种办法，进而目前很多采用类似于 mycat 这种分布式数据库代理的中间件，通过 sidecar 模式发布可以实现分库分表，连接池控制等各种各样的能力。

分布式 nosql 数据库

mongodb redis cassandra neo4j hbase memcache 等等，这里以 hbase 为例

之前提到了数据的强一致性，为了保障数据强一致的时效性能够控制在 ms 级甚至到 s 级别，从基础设置上的专线、组件本身的高可用和业务上为了保障一致性的对账系统等，都做了大量的努力。

这里对于组件本身的高可用同步：

方案一：分库分表之后，对于商品维度进行路由，每次都路由到单个实例

方案二：按照时间戳的最新作为最新数据进行标识进行写覆盖

方案三：分库分表之后不进行同步和路由，双向同步保障数据的完整性，客户端对冲突数据进行处理

方案四：在分库分表的情况下，在完成路由的情况下，依赖于 globalid 的方案来进行双向同步和数据校验

依赖 zookeeper 实现分布式一致性

paxos 的协议和算法整体看比较复杂，在开发中会进行一些简化和改造，不过本身来说投票和抢主是主要的选主方案，按照 zookeeper 为例，使用的 zab 协议，简化了并且合并了 Proposer、Acceptor 和 Leaner 角色，通过 follower 依赖消息进行 propose 的方式来进行选主。

实际使用：

1. config 配置中心

2. zookeeper 进行选主

3. 进行集群管理，实现负载均衡

搜索引擎的实现

搜索引擎来说最重要的数据收集部分是采用爬虫来实现，另外的搜索部门主要依赖的是倒排索引来实现，Lucene 架构是之前最常用的搜索引擎架构，随着分片和集群的需要 ElasticSearch 愈来越成为主流。