Doris系列（二）doris的整体架构

在上一篇我们介绍doris的时候贴过一张Doris的整体架构图，那么这篇文章我们围绕Doris的整体架构来详细介绍下。首先还是继续上整个Doris的整体架构图：

基于上图，我们可以看到整个Doris架构有如下特点：

1、高度兼容mysql协议

从上图可以看出，我们在使用Doris的时候，可以像使用mysql一样的使用Doris。连接Doris的客户端我们也是用的兼容Mysql协议的客户端，例如：jdbc，mysql-client，navicat等等。

2、主从架构，没有任何其他组件的依赖

从上图的第二层我们可以看出来，整个Fe元数据原理主要是主从结构，有leader角色，也有follower角色。同时图中看不到任何其他的组件，所以这个Doris的主从架构完全是自身内部实现的，不需要依赖任何其他第三方的主键。

3、节点角色

这里的角色主要是两个，一个是Fe，一个是Be。

Fe的作用主要是元数据的管理，同时Fe负责解析/生成/查询计划。

1、fe中主要有三个角色，分别是Leader、Follower、observer这三个角色，主要是用来满足元数据的高可用，保证单节点在宕机的情况下，元数据还能被实时的恢复，从而不影响整个Doris集群服务。
2、Observer只是用来扩展查询节点的，就是说如果在发现集群压力非常大的情况下，需要去扩展整个集群的查询能力，那么可以多添加几个observer节点。
3、Observer节点不参与任何的数据写入，只参与数据的读取

Be的作用主要是负责执行查询计划及数据存储。

数据的可靠性主要由Be进行保证，Be会对整个数据存储多个副本。在实际工作中具体的副本数由实际情况决定。

4、可扩展

以上的Fe节点和Be节点可以无缝扩展。

结合以上整个Doris的结构，我们了解了Doris的特点。那么既然提到大数据，那么就一定会涉及到这种master管理元数据，那么Doris是Fe是如何管理元数据的呢？

Doris 采用 Paxos 协议以及 Memory + Checkpoint + Journal 的机制来确保元数据的高性能及高可靠。
元数据的每次更新，都首先写入到磁盘的日志文件中，然后再写到内存中，最后定期 checkpoint 到本地磁盘上。
我们相当于是一个纯内存的一个结构，也就是说所有的元数据都会缓存在内存之中，从而保证 FE 在宕机后能够快速恢复元数据，而且不丢失元数据。

所以在公司内部部署Doris服务的时候，我们需要考虑Doris的高可用方案如何设计，这里给个建议参考：

1、如果是离线业务，对高可用要求不是那么高可以使用 1 FE（Follower leader） + 1 FE（Observer）
2、如果是实时在线业务，对高可用要求很高，建议使用 3 FE（Follower），会自动选举出一个 leader

说完了Fe的高可用和高可靠，我们再说说Be的高可用和高可靠

1、Doris 数据主要都是存储在 BE 里面，BE 节点上物理数据的可靠性通过多副本来实现，默认是 3 副本，副本数可配置且可随时动态调整,满足不同可用性级别的业务需求。FE 调度 BE 上副本的分布与补齐