Agenda

架构

Standalone

• loss update异常之- -: 不确认
• loss update异常之二: 无持久化

Replica set

• loss update异常之三:无冗余
• loss update异常之四:无副本确认
• loss update异常之五:不正确的选主
• loss update异常之六:脑裂
• loss update异常之七:使用物理时间
• Dirty read异常
• Stale read异常

架构

• MongoDB由4个组件构成，mongod, mongos, configserver, client。
• 独立(standalone) 模式
• replica set模式

Standalone模式

• loss update异常之- - -:不确认
• loss update异常之二:无持久化

loss update异常之一:不确认

• 异步写入
• 网络故障或者服务器故障(如重启)
• 丢失大量写入(即loss update)，客户端难以处理
• 原因:不确认
• 解决:写入确认(write acknowledgement)
• 选项: write concern: w
• 注意点:
• 在写入确认下，是同步写入
• 当前写入操作失败
• 客户端处理简单-重试

loss update异常之二:未持久化

• 写入操作未落磁盘
• 网络故障或者服务器故障(如重启)
• Loss acknowledged update ( 简称loss ack update)
• 原因:未及时持久化
• 解决:写入日志(journaling)
• 选项: write concern: j

Replica set模式

• loss update异常之三:无冗余
• loss update异常之四:无副本确认
• loss update异常之五:不正确的选主
• loss update异常之六:脑裂
• loss update异常之七:使用物理时间
• Dirty read异常
• Stale read异常

loss update异常之三:无冗余

• 宕机故障
• Loss data (可认为是loss ack update的特例)
• 原因:无冗余
• 解决:
• 复制
• Oplog
• Replicated state machine
• 选项:使用replica set模式

loss update异常之,四:无副本确认

• 异步复制过程
• Primary宕机故障
• Loss ack update
• 解决:副本写入通知
• 选项: write concern: w
• 注意
• 无法彻底解决
• 概率问题
• 影响可用性

loss update异常之五:不正确的选主(1)

• 选主(election)
• 如果错误的选择了- - 个不包含最新数据的secondary成为primary
• Loss ack update
• 原因:不正确的选主

loss update异常之五:不正确的选主(2)

• protocol v0
• Optime时间戳
• 选主的原则:
• 大多数同意.
• 针对- -次选举，只能投票- -次
• 不同意optime比自己小的
• 保证只选出一个主

loss update异常之五:不正确的选主(3)

• 解决:达到大多数的副本写入通知
• 选项: Write concern:W

loss update异常六:脑裂

• 网络分区故障
• 脑裂，stepdown, step down前的短暂时间，回滚( rollback)
• loss ack update
• 原因:脑裂
• 解决:(与异常五相同)达到大多数的副本写入通知
• 选项: Write concern: w

loss update异常七:使用物理时间(1)

• A-B-A场景
• 这种场景发生的概率小
• Clockskew故障加剧异常的出现

loss update异常七:使用物理时间(2)

• loss ack update
• 原因:使用物理时间
• Protocol v1
• term

脏读异常:

• 异步写入或者叫Non-blocking读
• 影响
• 没有故障时，是先知
• 有故障时，会脏读(dirty read)异常或者未提交读(read uncc
• 使用Read preference， 从secondary读也会出现
• 原因:未成功写入大多数，后被rolback
• 解决:大多数读
• 选项:
• Read concern:: majority
• 注意
• 大多数读仍然是non-blocking的

陈旧读异常：脑裂

• 大多数是带来陈旧读问题
• 陈旧读(stale read)异常
• 陈旧读不是因为读取历史版本数据
• 原因:处于网络分区的旧primary仍然可以提供读服务
• 解决:线性读
• 空写入操作，并且blocking等待写入完成
• 选项: Read concern: linearable

一致性分析

• Cassandra NWR(w>majority, r>majority)
• Cassandra的majoriy read是blocking的
• Protocol v1与raft类似，但不是raft
• 可以达 到与etcd、zookeeper类似的一 致性等级，类似于zk的sync达到线性一- 致性
• Raft的index是连续的
• Raft是committed后应用到状态机
• Raft是推送日志
• 达到数据库隔离级别: RC (read committed)
• 可以达到CAP中的CP
• 但默认都不是，Write concern、 read concern要设置成majority。
• 以上内容是拟出版的书中的一部分。

结语：

讲述MongoDB架构，以及该架构下引发MongoDB的多种丢数据的异常、脏读异常、陈旧读异常，MongoDB是如何致力于引入新版本的复制协议逐步消除了所有这些异常，最终让MongoDB达到一个high level的一致性和可靠性，成为一个可信任的数据库。

Java架构师福利

（架构级别资料分享）

准备了一些架构级别的知识点，有高可用、高并发、高性能及分布式、Jvm性能调优、Spring，MyBatis，Netty源码分析,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点视频，文档资料分享！

免费领取方式：一键三联（点赞+收藏+关注）后直接添加微信：mxh5261 即可百分百免费获取！

领取方式：一键三联（点赞+收藏+关注）后直接添加微信：mxh5261 即可百分百免费获取！