前言
对于单体系统来言写结点和读节点都在同一个节点上，所以不存在数据一致性的总是，为了解决单体结构不能横向扩展的问题，引入了分布式的架构，分布式架构突破了单体架构在内存，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里的节点也是一样的
还有一种情况对于存储的场景，因为存储通常者都会写多个节点，每个节点的数据在其它节点都会有备份，所以这种也认为是无主的架构，可以任意的增加和删除节点