AxonFramework命令总线

命令总线是将命令分发给各自的命令Handler的机制。每个命令总是被精确发送到一个命令Handler。如果没有可用的命令Handler为已分发的命令,将会抛出NoHandlerForCommandException异常。对同一命令类型订阅多个命令Handler将导致订阅互相取代。在这种情况下,最后一个订阅获胜。

分发命令

CommandBus提供了两个方法去分发命令到它们各自的Handler:dispatch(commandMessage,callback)和dispatch(commandMessage)。第一个参数是一个包含要发送的实际命令的消息。第二个可选的参数接收一个回调,允许在命令处理完成时通知分发组件。这个回调有两个方法:onSuccess()和onFailure(),分别会在命令处理返回后被调用,或者当它抛出一个异常时调用。

调用组件可能不采取在分发命令的同一线程中调用回调。如果调用线程在继续之前依赖于结果,你可以使用FutureCallback。这是一个Future(在java.concurrent包中定义)和Axon的CommandCallback的组合。或者,考虑使用命令网关。

如果一个应用程序不直接对命令的结果感兴趣,可以使用dispatch(commandMessage) 方法。

SimpleCommandBus

SimpleCommandBus,顾名思义,最简单的实现。它在分发它们的线程中简单的处理命令。命令处理后,修改后的聚合在同一线程被保存和发布生成的事件。在大多数情况下,如web应用程序,该实现将符合你的需求。配置API中SimpleCommandBus是默认使用的实现。

像大多数CommandBus实现一样,SimpleCommandBus允许拦截器进行配置。在命令总线上分发一个命令后调用CommandDispatchInterceptors。在实际的命令handler 方法之前调用CommandHandlerInterceptors,允许你修改或阻塞命令。有关更多信息,请参考命令处理器拦截器。

因为所有命令处理都在同一线程中完成,这个实现仅限于JVM的边界。这个实现的性能是很好的,但不超凡。跨JVM边界,或使你的CPU cycles发挥最大的功效,看看其他CommandBus实现。

AsynchronousCommandBus

顾名思义,AsynchronousCommandBus实现从分发它们的线程异步执行命令。它使用一个Executor在不同的线程来执行实际的处理逻辑。

默认情况下,AsynchronousCommandBus使用一个unbounded缓存的线程池。这意味着分发一个命令时会创建线程。完成处理命令的线程将被重新用于新命令。如果60秒线程没有处理命令,则会停止线程。

或者,Executor实例可以提供不同的线程策略配置。

注意,应用程序停止时应该关闭AsynchronousCommandBus,以确保任何等待线程正确关闭。关闭,调用shutdown()方法。这也将关闭任何Executor实例,如果它实现ExecutorService接口的话。

DisruptorCommandBus

SimpleCommandBus具有合理的性能特性,特别是当你经历了性能调优技巧。事实上,SimpleCommandBus需要锁来防止多个线程并发访问同一聚合,导致处理开销和锁争用。

DisruptorCommandBus采用不同的方法进行多线程处理。不是多个线程每个都执行同样的处理,而是有多个线程,每个负责一件处理。DisruptorCommandBus使用Disruptor,一个小的并发编程框架,通过不同的方法对多线程进行处理来实现更好的性能。任务不是在调用线程中进行处理,而是将任务移交给两组线程进行处理,每组线程负责一部分处理。第一组的线程将执行命令handler,更改一个聚合的状态。第二组将存储并将事件发布到事件存储。

虽然DisruptorCommandBus轻易优于SimpleCommandBus 4倍(!),但有一些限制:

  • DisruptorCommandBus仅支持事件溯源聚合。这个命令总线充当由Disruptor处理聚合的存储库。获取一个存储库的引用,使用createRepository(AggregateFactory)。
  • 一个命令只能导致一个聚合实例状态变化。
  • 当使用缓存时,它只允许给定的标识符为单个聚合。这意味着它是不可能有两个具有相同的标识符的不同类型的聚合。
    命令一般不会引发需要回滚工作单元的故障。当发生回滚时,DisruptorCommandBus不能保证命令按照它们被分发的顺序进行处理。此外,它需要重试其他命令,从而造成不必要的计算。
  • 在创建一个新的聚合实例时,命令更新所创建实例可能并不完全按照所提供的顺序进行。一旦创建了聚合,所有命令将按照它们被分发顺序执行。为了确保顺序,在创建命令上使用回调去等待正在创建的聚合。它不应该耗时超过几毫秒。

构建一个DisruptorCommandBus实例,你需要一个EventStore。该组件在Repositories and Event Stores中有解释。
或者,你可以提供一个DisruptorConfiguration实例,它允许你调整配置优化你的特定环境下的性能:

  • Buffer size:在ringBuffer上注册传入命令的槽数。更高的值可能会增加吞吐量,但也导致更高的延迟。必须是2的次方数,默认为4096。
  • ProducerType: 表示条目是由单线程或多线程生成的。默认为多线程。
  • WaitStrategy:当处理器线程(三个线程负责的实际处理)需要等待对方时使用的策略。最好的WaitStrategy取决于机器上可用的处理器数量,和正在运行的其他进程的数量。如果低延迟是至关重要的,DisruptorCommandBus可以自己认领内核,你可以使用BusySpinWaitStrategy。为了使命令总线索取更少的CPU并且允许其他线程处理,使用YieldingWaitStrategy。最后,你可以使用SleepingWaitStrategy和BlockingWaitStrategy允许其他进程共享CPU。如果命令总线不需要进行专职处理,则后者是合适的。默认为BlockingWaitStrategy。
  • Executor:设置Executor为DisruptorCommandBus提供线程。这个Executor必须能够提供至少4个线程。其中的3个线程,由DisruptorCommandBus的处理组件认领。额外的线程用于调用回调函数,并计划重试以防检测到错误的聚合状态。默认是CachedThreadPool提供线程从一个称为“DisruptorCommandBus”的线程组中。
  • TransactionManager:定义了事务管理器,应该确保存储和事件发布以事务的方式执行。
  • InvokerInterceptors:定义了在调用处理中使用的CommandHandlerInterceptors。这个处理调用实际的命令处理器方法。
  • PublisherInterceptors:定义了在发布处理中使用的CommandHandlerInterceptors。这个发布处理存储和发布生成的事件。
  • RollbackConfiguration:定义工作单元应该回滚的异常。默认配置为回滚未经检查的异常。
  • RescheduleCommandsOnCorruptState:指示已经执行过命令但损坏的聚合(如:因为一个工作单元是回滚)是否应该重新计划。如果为假,回调的onFailure()方法将被调用。如果为的(默认),命令将被重新计划。
  • CoolingDownPeriod:设置等待的秒数,以确保所有命令被处理。在冷却期间,不接受新命令,但是现有的命令仍然处理,并在必要时重新计划。冷却期间确保线程可供重新安排命令和调用回调之用。默认为1000(1秒)。
    缓存:设置缓存存储从Event Store中恢复的聚合实例。缓存用disruptor存储不活跃的聚合实例。
  • InvokerThreadCount:给命令处理器的调用分配线程的数量。一个好的起始点是机器内核数量的一半。
  • PublisherThreadCount:用于发布事件的线程数量。一个好的起始点是一半的内核数量,如果IO上花费大量的时间,可以增加。
  • SerializerThreadCount:使用pre-serialize事件的线程数量。默认为1,但如果没有配置序列化器将被忽略。
  • Serializer:用于执行pre-serialization的序列化器。当配置序列化器时,DisruptorCommandBus将包装所有生成的事件在一个SerializationAware消息上。附加有效负载和元数据的序列化形式,在发布到事件存储之前。

你可能感兴趣的:(AxonFramework命令总线)