欢迎光临汤雪华的博客

一个人一辈子能坚持做好一件事情就够了!坚持是一种刻意的练习,不断寻找缺点突破缺点的过程,而不是重复做某件事情。
posts - 141, comments - 2098, trackbacks - 0, articles - 0
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

ENode 2.0 - 介绍一下关于ENode中对Command的调度设计

Posted on 2015-01-26 00:24 netfocus 阅读(...) 评论(...) 编辑 收藏

CQRS架构,C端的职责是处理从上层发送过来的command。对于单台机器来说,我们如何尽快的处理command呢?本文想通过不断提问和回答的方式,把我的思考写出来。

首先,我们最容易想到的是使用多线程。那当我们要处理一个command时,能直接丢到线程池中,直接交给线程池去调度吗?不行。因为假如多个command修改同一个聚合根时,会导致db的并发冲突,从而会导致command的不断重试,大大降低了command的处理速度。

那该怎么解决呢?既然直接多线程处理会有并发冲突的问题,那就对command进行路由。那根据什么进行路由呢?考虑到大部分command都会指定要创建或修改哪个聚合根,也就是说会指定聚合根ID。所以,我们就很容易想到,可以根据聚合根ID进行路由。我们可以根据聚合根ID的hashcode得到一个long;然后我们系统启动时,创建N个ConcurrentQueue。然后路由就很简单了,我们可以对聚合根ID的hashcode对N取模,然后得到余数,然后该余数就是对应的queue的索引,然后我们把该command放入对应的queue即可。然后每个queue的消费者,有一个单线程在不断的按次序逐个消费当前队列里的command。这个方法,解决了并发冲突的问题。但是却带来了另一个问题,就是热点数据的情况。

假如针对某个聚合根的command非常多。那可想而知,某个queue里的command可能都是针对该聚合根的command了。那这样的话这个queue中就基本没机会处理其他聚合根的command,导致其他聚合根的command的处理会被大大延迟。虽然,这种方式遵守了先到先处理的原则,但在这种热点数据的情况下,非热点的数据基本没机会被处理了。设想,现在总共有100个queue可以用来路由,然后现在正好有100个热点修改的聚合根,然后它们的command分别会被路由到对应的queue。这样,我们不难理解,这100个queue中的command就大部分都被这100个聚合根的command占满了。这样导致的结果就是不热点的聚合根的command可能会很晚才会被处理。那怎么样做可以更好呢?

学过akka框架的人应该知道,akka中每个actor都有一个mailbox,mailbox就是一个queue,mailbox中存放所有需要被当前actor处理的消息。如果我们把actor理解为DDD中的聚合根的话,那就是我们可以为每个聚合根设计一个queue,只要是对同一个聚合根的command,都会被先放入queue。然后立即通知任务调度服务,处理当前的聚合根的mailbox。如果当前线程池有可用的线程,那就会立即处理当前的mailbox。如果当前的mailbox正好有command正在被处理中,那本次处理直接结束。然后mailbox中的每个command,在被处理完之后,如果存在下一个command,则会立即请求任务调度服务处理下一个command。

通过这样的设计,我们本质上是为每个聚合根分配一个mailbox,即一个queue;然后,只要是对某个聚合根的command,总是先进入对应的mailbox。然后立即调用任务调度服务去处理当前的mailbox。这个设计,其实也是先到先处理的方式,因为先到的command,会先通知任务调度服务处理。但是不同的是,假如任务调度服务在处理某个mailbox时,如果当前mailbox有command正在被处理,那是会直接结束本次处理的。这样的好处是,任务调度服务可以快速的去处理下一个任务。而原来那种纯粹只设计固定的N个queue的方式,处理command的顺序只能是先进先处理了。

关于mailbox的设计,还有另外一点需要注意的。就是假如mailbox中当前某个command处理完了,然后后面也没有需要处理的command了,我们可以直接将当前mailbox标记为空闲状态吗?不可以。因为我们整个设计是无锁的,也就是说,当我们判断当前mailbox,发现没有后续command需要处理,然后在将mailbox标记为空闲状态前,可能正好又有一个新的command进入了mailbox,且我们可能立即调度了一个任务去处理该mailbox,但是由于当前的mailbox还是在忙的状态,所以就直接结束了。这样导致的后果是,前一个command的处理线程认为当前没有下一个command需要处理;而新进来的command的处理线程认为当前的mailbox还在忙,所以也不处理当前command。所以最后导致这个command一直无法被处理了。直到再下一个command进入mailbox后才正常。虽然这个概率非常低,但在高并发的情况下,完全是很有可能的。

为了解决这个问题,我们可以这样做:在判断是否还有下一个command需要处理后,如果没有,则先将mailbox的状态标记为空闲。然后再判断是否有需要处理的command,如果还是没有,才是真正的没有。如果又有了,则应该立即通知任务调度服务处理当前的mailbox。

下面,我们再回到前面说的N个固定队列的设计思路。其实这个设计还有另一个问题,就是由于每个队列只有一个线程在处理。也就是说,如果我们有100个队列,且队列的消费者是一个个处理command的。那就意味着某一个时刻,最多只能有100个领域事件产生;而对于持久化领域事件,我在之前的文章中有提到,可以通过group commit技术来提高持久化的性能。因为如果每个领域事件的持久化都访问一次DB,那对DB的IO会太频繁。最后会导致我们的架构的瓶颈会被卡在领域事件的持久化上。所以,这种情况下,我们如果用了group commit技术,那一次只能最多持久化100个事件。而且一般是达不到100的,因为当第一批100个事件一次性group commit持久化完成后,这100个线程才能去各自的队列里拿下一个command来处理。假设我们group commit的定时间隔是10ms,那我们是很难在这10ms内又立即产生下一个100个事件的。为什么会这样?估计各位看官是不是看的有点晕了,没关系,其实我也快晕了,呵呵。

因为我们要保证在同一个队列里的command的处理一定是按次序一个个处理的。也就是说,当前一个command没处理完时,是不能处理下一个command的。否则就会出现我文章最开始提到的并发冲突的问题。所以,当当前的command产生事件,并通知事件持久化服务去持久化这个事件时,必须等在那里,直到事件成功持久化为止。

那么有没有办法,既能保证1)对同一个聚合根的修改是串行的(解决并发冲突问题),2)但是聚合根之间是并行的,3)且我们可以完美的配合group commit技术呢?有,就是上面的mailbox的设计。首先,mailbox保证了对同一个聚合根的所有command都是排队的;其次,mailbox能保证它里面的所有的command的处理也是按次序的,也就是前一个command处理完之后才会处理下一个command。第三,对mailbox的处理,完全是交给任务调度服务来完成。也就是mailbox不关系自己被哪个线程处理,它只保证自己内部的command的处理顺序即可。

假如我们的任务调度服务背后是一个最大有200个线程的线程池。那在高并发的情况下,意味着任意时刻,这个线程池中的200个线程都在工作,且每个线程都在处理一个command,且这些线程不需要等待当前自己处理的command产生的事件的持久化。它们只需要负责把事件丢到一个全局唯一的事件队列即可。然后就可以开始处理下一个command handle task了。然后,这个全局唯一的事件队列只有一个消费者线程,它每隔一定时间(比如20ms)持久化一次队列里的事件。一次持久化多少个我们可以自己配置,通过SqlBulkCopy,我们可以达到很好的批量插入事件的效果。注意,这个配置值以及定时持久化的间隔值,不是拍脑袋想出来的,而是需要我们通过实测来得到。

由于,command handle task thread不会等待当前事件的持久化完成,所以它就可以被线程池回收,然后去处理下一个command handle task了。然后,假如某批事件被持久化完成了,则先将这些事件对应的command都标记为完成。比如,调用command的complete方法,complete方法内,可以进一步通知它所属的mailbox去处理下一个可能存在的command。这一批command都通知完成后,就可以立即处理下一批要持久化的事件了。此时,我们知道,在高写入的场景下,一定已经有足够数量的下一批事件了,因为之前的command handle task thread早就已经去处理其他的command了。

所以,通过上面的设计,我们可以在解决command并发冲突的前提下,保证command产生的事件的批量持久化,且能做到每次持久化都有足够多的事件可以被批量持久化。从而整体提高command的处理吞吐量。当然,如果我们的系统写入数据的并发并不高,那是没必要使用group commit技术的。因为group commit毕竟是定时触发的,比如20ms一次。当然,group commit并不是一定要等待20ms才做一次,我们可以在前一次做完后,立即判断接下来是否有事件需要被持久化,如果有,则立即开始下一次批量持久化。

另外一点需要讨论的是,有些command是没有指定聚合根ID的,比如有些新增聚合根的command,可能聚合根ID没有在command上指定,而是在实例化聚合根时才产生。或者,还有一些command不是操作聚合根,而是可能调用外部系统的API。这种command,我们可以直接调用任务调度服务去处理即可。因为这种command不会产生对我们的系统内的聚合根的修改的并发冲突。

说了这么多的思考文字,看起来比较枯燥,下面我们来看看关键部分的代码吧!

public void Process(ProcessingCommand processingCommand)
{
    if (string.IsNullOrEmpty(processingCommand.AggregateRootId))
    {
        _commandScheduler.ScheduleCommand(processingCommand);
    }
    else
    {
        var commandMailbox = _mailboxDict.GetOrAdd(processingCommand.AggregateRootId,
            new CommandMailbox(_commandScheduler, _commandExecutor, _loggerFactory));
        commandMailbox.EnqueueCommand(processingCommand);
        _commandScheduler.ScheduleCommandMailbox(commandMailbox);
    }
}

当一个command被处理时,我们先判断其是否有聚合根ID,如果没有,则直接交给commandScheduler(command处理任务调度服务)进行处理;如果有,则根据聚合根ID找到其mailbox,然后把当前command放入mailbox,然后通知commandScheduler处理该mailbox。接下来我们看看command mailbox的设计:

public class CommandMailbox
{
    private readonly ConcurrentQueue<ProcessingCommand> _commandQueue;
    private readonly ICommandScheduler _commandScheduler;
    private readonly ICommandExecutor _commandExecutor;
    private readonly ILogger _logger;
    private int _isRunning;

    public CommandMailbox(ICommandScheduler commandScheduler, ICommandExecutor commandExecutor, ILoggerFactory loggerFactory)
    {
        _commandQueue = new ConcurrentQueue<ProcessingCommand>();
        _commandScheduler = commandScheduler;
        _commandExecutor = commandExecutor;
        _logger = loggerFactory.Create(GetType().FullName);
    }

    public void EnqueueCommand(ProcessingCommand command)
    {
        command.SetMailbox(this);
        _commandQueue.Enqueue(command);
    }
    public bool MarkAsRunning()
    {
        return Interlocked.CompareExchange(ref _isRunning, 1, 0) == 0;
    }
    public void MarkAsNotRunning()
    {
        Interlocked.Exchange(ref _isRunning, 0);
    }
    public void CompleteCommand(ProcessingCommand processingCommand)
    {
        _logger.DebugFormat("Command execution completed. cmdType:{0}, cmdId:{1}, aggId:{2}",
            processingCommand.Command.GetType().Name,
            processingCommand.Command.Id,
            processingCommand.AggregateRootId);
        MarkAsNotRunning();
        RegisterForExecution();
    }
    public void RegisterForExecution()
    {
        _commandScheduler.ScheduleCommandMailbox(this);
    }
    public void Run()
    {
        ProcessingCommand currentCommand = null;
        try
        {
            if (_commandQueue.TryDequeue(out currentCommand))
            {
                _logger.DebugFormat("Start to execute command. cmdType:{0}, cmdId:{1}, aggId:{2}",
                    currentCommand.Command.GetType().Name,
                    currentCommand.Command.Id,
                    currentCommand.AggregateRootId);
                ExecuteCommand(currentCommand);
            }
        }
        finally
        {
            if (currentCommand == null)
            {
                MarkAsNotRunning();
                if (!_commandQueue.IsEmpty)
                {
                    RegisterForExecution();
                }
            }
        }
    }
    private void ExecuteCommand(ProcessingCommand command)
    {
        try
        {
            _commandExecutor.ExecuteCommand(command);
        }
        catch (Exception ex)
        {
            _logger.Error(string.Format("Unknown exception caught when executing command. commandType:{0}, commandId:{1}",
                command.Command.GetType().Name, command.Command.Id), ex);
        }
    }
}

command mailbox有一个状态标记,表示当前是否正在处理command。这个状态我们会通过原子锁来更改。为了更好的说明问题,我先把commandScheduler的代码也先贴出来:

public class DefaultCommandScheduler : ICommandScheduler
{
    private readonly TaskFactory _taskFactory;
    private readonly ICommandExecutor _commandExecutor;

    public DefaultCommandScheduler(ICommandExecutor commandExecutor)
    {
        var setting = ENodeConfiguration.Instance.Setting;
        _taskFactory = new TaskFactory(new LimitedConcurrencyLevelTaskScheduler(setting.CommandProcessorParallelThreadCount));
        _commandExecutor = commandExecutor;
    }

    public void ScheduleCommand(ProcessingCommand command)
    {
        _taskFactory.StartNew(() => _commandExecutor.ExecuteCommand(command));
    }
    public void ScheduleCommandMailbox(CommandMailbox mailbox)
    {
        _taskFactory.StartNew(() => TryRunMailbox(mailbox));
    }

    private void TryRunMailbox(CommandMailbox mailbox)
    {
        if (mailbox.MarkAsRunning())
        {
            _taskFactory.StartNew(mailbox.Run);
        }
    }
}

从上面的代码可以看到,当command mailbox被commandScheduler处理时,实际上就是创建了一个task,该task是调用TryRunMailbox方法,该方法先尝试将当前的mailbox标记为运行状态,如果当前已经在运行状态,则不做任何处理;如果标记为运行状态成功,则启动一个任务去调用commandMailBox的Run方法。在Run方法内部,mailbox会尝试取出一个需要被处理的command,如果有,就执行该command;如果没有,则先将mailbox当前状态标记为空闲状态,然后再判断一次mailbox中是否有需要处理的command,如果有,则通知commandScheduler处理自己;否则,不做任何处理。

最后,当一个command处理完成后,它会通知自己所属的mailbox。然后mailbox通知commandScheduler处理自己。如下代码所示:

public class ProcessingCommand
{
    private CommandMailbox _mailbox;

    public void SetMailbox(CommandMailbox mailbox)
    {
        _mailbox = mailbox;
    }
    public void Complete(CommandResult commandResult)
    {
        if (_mailbox != null)
        {
            _mailbox.CompleteCommand(this);
        }
    }
}

为了代码的好理解,我去掉了这个类中一些无关的代码。

好了,通过上面的文字介绍和代码,我基本把我想表达的设计写了出来。有点乱,我发现要把自己所想的东西表达清楚,还真不是一件容易的事情。希望通过这篇文章,能让对ENode有兴趣的朋友更好的理解ENode。