date: 2020-04-27 12:59:24
tags: MongoDB:ReplicaSetMonitor
文章目录
sharding实例对后端 shard 会进行状态探测,以发现 shard 是否有节点更新( 选主、节点加入、节点异常)。提供探测能力的核心类为 ReplicaSetMonitor
及相关类。
对于状态探测的基本逻辑应该也比较好构思:定期状态探测、探测结果存储、探测结果查询。MongoDB中也按照这个逻辑来完成的:
-
ReplicaSetMonitor
提供状态查询的接口,以及定期探测触发能力。状态信息存储在_state
(SetState
类型成员变量) 中 -
SetState
存储 ReplicaSet shard 的状态信息。包装 Node 记录各个 Node 的信息,持有一个ScanState
记录该 ReplicaSet 当前正在 scan 的信息 -
Refresher 进行实际的状态探测,提供一个 static 方法
ensureScanInProgress
来初始化一个 Refresher 进行探测。Refresher
与SetState
是一一绑定的,只有SetState
在被探测状态,才会有对应的Refresher
产生
-
ScanState
记录Refresher
探测过程中的状态信息。ScanState
会被SetState::currentScan
及Refresher::_scan
持有,一般情况下这2个 scan 是相同的,但是可能存在并发的场景导致指向的不是同一个 scan, 这时候以SetState::currentScan
为准。
ReplicaSetMonitor / SetState / Refresher / ScanState 具体关系参考下图:
探测目标 shard 要求
**只有以 ReplicaSet 方式启动的 shard(包含 config ),才会持有一个 ReplicaSetMonitor
类的成员。**即只有 ReplicaSet shard 才会被探测,以 Standalong 方式启动的 shard 不会进行探测
探测触发
ReplicaSetMonitor 中会定期进行 shard 状态探测,如果当前维系的状态不能满足其他代码的 ReadPreference 要求,也会下发探测
定期探测
ReplicaSetMonitor
初始化时会调用_scheduleRefresh
,而后通过 _scheduleRefresh
和 _doScheduledRefresh
两个函数相互调用及 TaskExecutor::scheduleWorkAt
完成:
_scheduleRefresh
中通过使用TaskExecutor::scheduleWorkAt
注册定时任务,定时任务负责调用_doScheduledRefresh
_doScheduledRefresh
负责调用Refresher::ensureScanInProgress
进行Refresher
新建与 探测下发。同时根据当前SetState
的状态来决定下次刷新的周期,然后调用_scheduleRefresh
注册新的定时任务
默认情况下,定时任务每隔 kDefaultRefreshPeriod (30s) 执行一次。但是如果 SetState 的 waiters 结构中非空,则会将周期调整为 kExpeditedRefreshPeriod (500ms) 。SetState 的 waiters 结构中 数据添加在下文按需探测时&