ReplicationExecutor的实现原理

最新推荐文章于 2022-10-26 14:31:53 发布

原创最新推荐文章于 2022-10-26 14:31:53 发布 · 841 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#mongodb #副本集

Mongodb 专栏收录该内容

24 篇文章

订阅专栏

本文介绍了MongoDB中副本集的任务调度机制，包括ReplicationExecutor的架构及其内部组件Event、Callback、TaskRunner和OldThreadPool的功能。阐述了不同类型的队列如何协作以确保任务的正确执行。

副本集在维护以及更新结构的过程中，需要执行大量的任务，这些任务的执行需要满足一定的条件，例如，先触发的时间先执行，或者等待一段时间以后执行某个任务，又或者有的任务需要全局锁，有的只需要集合锁等等。 Mongodb 内部通过ReplicationExecutor来实现这些任务的执行。
从功能上面讲，ReplicationExecutor的作用和golang里面的channel是非常类似的，都是一端负责添加任务，另外一端负责处理最先收到的任务。

先来看一下replication executor的整体架构图：
这里写图片描述

ReplicationExecutor 继承自TaskExecutor，它包含了4个主要的类来完成任务： Event， Callback， TaskRunner， OldThreadPool。接下来分别介绍他们，以及他们如何相互协作。

Event

Event 是一个时间生成，通知等功能的类，他的作用跟他的名字一样，通知等待事件发生。在每一个节点中，都有一个event list，记录了所有的event。每当我们要改变接点的状态，就会发出这样的event，并且通过event可以通知其他节点进行相应的更改。
每当收到一个event，就要将所有等待该signal的task放进readyQueue里面。

void ReplicationExecutor::Event::_signal_inlock() {
    invariant(!_isSignaled);
    _isSignaled = true;

    if (!_waiters.empty()) {
        _executor->_readyQueue.splice(_executor->_readyQueue.end(), _waiters);
        _executor->_networkInterface->signalWorkAvailable();
    }

    _isSignaledCondition.notify_all();
}

Callback

每当有一个task被加入到某种类型的队列，都会返回一个该任务的CallbackHandle，通过它，可以得到这个task的执行时的callback 函数，以及这个task结束的event。

StatusWith<ReplicationExecutor::CallbackHandle> ReplicationExecutor::enqueueWork_inlock(
    WorkQueue* queue, const CallbackFn& callbackFn) {
    invariant(callbackFn);
    StatusWith<EventHandle> event = makeEvent_inlock();
    if (!event.isOK())
        return StatusWith<CallbackHandle>(event.getStatus());

    if (_freeQueue.empty())
        _freeQueue.push_front(WorkItem());
    const WorkQueue::iterator iter = _freeQueue.begin();
    WorkItem& work = *iter;

    invariant(!work.callback.isValid());
    setCallbackForHandle(&work.callback,
                         std::shared_ptr<executor::TaskExecutor::CallbackState>(
                             new Callback(this, callbackFn, iter, event.getValue())));

    work.generation++;
    work.finishedEvent = event.getValue();
    work.readyDate = Date_t();
    queue->splice(queue->end(), _freeQueue, iter);
    return StatusWith<CallbackHandle>(work.callback);
}

TaskRunner

这是一个任务的执行器，它主要是处理DB相关的task 和exclusive task。它的工作流程如下：
这里写图片描述

ReplicationExecutor

这个类里面包含了多个对列：
_freeQueue：
已经执行的task，放入该队列；

_readyQueue：
已经ready的任务，通过ReplicationExecutor::scheduleWork 的任务；

_dbWorkInProgressQueue：
通过ReplicationExecutor::scheduleDBWork加入的任务；

_exclusiveLockInProgressQueue：
通过ReplicationExecutor::scheduleWorkWithGlobalExclusiveLock加入的任务；

_networkInProgressQueue：
通过ReplicationExecutor::scheduleRemoteCommand 加入的任务；

_sleepersQueue：
通过 ReplicationExecutor::scheduleWorkAt 加入的任务，这个队列里面的任务是按照时间排序的，新加入的任务也要保证时间的有序性。

每一个节点需要起一个叫做ReplicationExecutor的线程，不停地通过getWork（）得到下一个任务，执行它，并且发出该任务执行的信号。这样的过程重复进行，一直到所有的任务执行。
整个的逻辑大致如下：

void ReplicationExecutor::run() {
    setThreadName("ReplicationExecutor");
    _networkInterface->startup();
    _dblockWorkers.startThreads();
    std::pair<WorkItem, CallbackHandle> work;
    while ((work = getWork()).first.callback.isValid()) {
        {
            stdx::lock_guard<stdx::mutex> lk(_terribleExLockSyncMutex);
            const Callback* callback = _getCallbackFromHandle(work.first.callback);

            makeNoExcept(
                stdx::bind(callback->_callbackFn, CallbackArgs(this, work.second, inStatus)))();
        }
        signalEvent(work.first.finishedEvent);
    }
    finishShutdown();
    _networkInterface->shutdown();
}

这里，比较复杂的是执行远端命令的处理，其流程图如下：
这里写图片描述

这里， ReplicationExecutor 通过NetworkInterface来执行远端命令，其执行的命令通过RemoteCommandRequest来指定，执行之后，通过RemoteCommandCompletionFn 来回调调用方。
NextworkInterface里面主要通过RemoteCommandRunner来处理网络事件，他通过host：port得到来自ConnectionPool里面的一个ConnectPtr, 然后吧RemoteCommandRequest 变成一个Message的对象。
这里，该节点需要调用其他的节点，它自己就相当于一个client 被调用方是一个server，所以他生成一个DBClientReplicasSet对象，来调用目的端。当目的端返回， RemoteCommandCompletionFn被调用，然后逐级返回，到ReplicationExecutor，本次remote command执行完成。