解读分布式系统里，数据一致性的三种典型架构及其应用

前言

对于单体系统来言写结点和读节点都在同一个节点上，所以不存在数据一致性的总是，为了解决单体结构不能横向扩展的问题，引入了分布式的架构，分布式架构突破了单体架构在内存，CPU,硬盘方面的限制，但是也引入了新的数据一致性的问题

常用的分布式架构

架构	说明	代表
多主架构	解决了单点写的问题，多个节点都可以支持同时支持读写	redis cluster （无副本的情况下）
主从架构	只有主节点负责读写，从节点从主节点同步数据，作stand by	zookeeper flink jobmanager hadoop namenode tidb pd
无主架构	每个节点一样的职责，各个节点可以互相作为备份	kafka pulsar broker pulsar br es client 节点 impala tidb storage

 

主从架构

解读

通常用于存放元数据的场景，主节点用来写和读数据，从节点主要用来同步数据，如果主节点挂掉，从节点会选出新的节点， 继续提供服务。

hadoop 里的namenode 用来负责文件的元数据

flink 的jobmanager用来放任务的元数据

tidb pd 用来放表的元素数据

zookeeper 用来存放第三方的元数据

问题

主从架构肯定会 涉及到主节点和从节点同步的问题

1.同步复制

所有的从节点写入，才认为写入

比如kafka producer 的ack 等于-1这种情况就要等到所有节点写入

2.半同步复制

超过2/3的节点写入，就认为写入

3.异步复制

主节点写入，就认为写入

多主架构

从上面主从架构能发现，如果主节点只有一个的话，不能解决效率的问题，所有请求都会打到主节点上，丧失了横向的扩展性，如果是只用于元数据存储的话，问题其实影响大不，但是如果是qps极高的情况下，这种就不合适。

以redis cluster(无副本情况)为例，redis 作为常用的缓存工具，生产环境读qps极高，redis 把整个集群划成16384个hash slot，然后通过虚拟节点的方式，把slot 均匀的分布在多个节点上，使得集群可以横向扩展

无主架构

通常是用于没有节点没有状态的场景，可以任意的扩展规模。比如es 的client 只负责拆分查询，发出查询请求，合并结果，impala里的节点也是一样的

还有一种情况对于存储的场景，因为存储通常者都会写多个节点，每个节点的数据在其它节点都会有备份，所以这种也认为是无主的架构，可以任意的增加和删除节点