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