MongoDB高可用
单节点
分析:
- 由于单节点,读写均在一个节点上进行,读写压力可能比较大
- 存在单点故障问题,一旦出现问题,整个服务都不用
- 存储的数据量也会成为一个瓶颈
优点:
- 结构简单,已部署,已维护,客户端使用起来也方便
主从架构
特点:
- 写数据只能在master上进行
- slave之间互相不能感知
分析:
- 存在主从必定存在数据复制的过程,那么逃不了要面临数据同步延迟问题,也就是数据不一致问题
- 如果master宕机后正好数据同步不及时,那么数据就会丢失
- 由于slave之间不能互相感知,并且又没有另外的类似监控角色存在,所以一旦master宕机,是没办法自动故障转移的,必须人为参与,那么SLA(就是指几个9,或者可用性)必定大打折扣
从MongoDB 3.6 开始已经彻底废弃不使用了
副本集架构
- 有三种角色:Primary,Secondary,Arbiter(可选),下面可能会描述为主节点(Primary)、从节点(Secondary)
- Arbiter不储存数据,只负责投票,并且是可选配置
- Primary节点有且仅有一个
- 在某些特定场合(比如网络出现分区),Primary节点可能出现多个,但通常只有最新的primary节点能正常响应写请求
- Primary会把对数据的所有改动都记录在oplog日志中
- 从节点会同步primary节点的oplog,然后根据oplog进行重放,从而保持与Primary数据同步
- 如果某个时候Primary节点不可用,那么从节点会发起选举要求自己成为主节点
- 在某个情况下(比如成本限制)没有条件部署多余的从节点,此时可以选择部署一个Arbiter,Arbiter只复制选举,不负责数据存储。通过这样的方式既能节约成本,又能保证高可用。比如注意观察下面的图
- 当主节点生产oplog的速率大于从节点复制oplog的速率,那么数据延迟会逐渐增长。当超过一个阈值后,主节点会开启流量控制。
- 主节点流量控制:一言蔽之就是主节点会限制应用写入数据的速度。如何限制呢? 当主节点开启流控后,应用写入数据前需先请求一个票据(可以理解为token),主节点通过限制票据的生产速度来达到流控的目的
- 当从节点与主节点断开联系超过一定的时间,那么符合条件的从节点会发起选举要求自己成为主节点
- 副本集群在选主过程中,是不能对外提供写服务的(这是一种不可用的表现),但保留了提供读服务的能力。(用不用取决于客户端,客户端可以配置在主节点脱机时是否在从节点上执行)
- 默认情况下,客户端的读操作由主节点完成。但客户端可以通过配置从而让从节点来完成读操作
- 下面的图全部来自于mongodb官网
本质也是主从架构,只是增加了第三个角色:仲裁者(Arbiter),然后更换了角色名以及职责
扩展阅读:https://www.mongodb.com/docs/manual/replication/
特点:
- primary节点负责读写请求的处理(客户端可以指定把读请求交给副本节点完成)
- 整个集群中,各个节点之间有心跳信息,也就是说从节点间能互相感知
- primary节点宕机后,会从seondary节点中选择一个作为新的primay节点对外提供服务
- arbiter节点不存储数据,只进行选主投票
分析:
- 通过增加仲裁者的角色以及节点间互相感知的功能,可以做到故障自动转移
- 仍然存在数据不一致或丢失的问题
系统推荐
- ShadowsockServer
- PGSQL GIN索引“失效”
- 乱七八糟的笔记
- Spring RetryTemplate
- Paxos算法
- JVM异常处理
- Spring Boot升级到2 6 x踩的坑
- JVM杂项
- 前端axios下载csv文件乱码
- GitHub Workflow突然报错
- vuepress-theme-hope 添加谷歌广告
- intro
- 随机毒鸡汤:别说自己活的像狗一样,看看那些宠物狗,你会发现活的不如狗。