Domain的动作产生了事件，事件被sent出到event bus 之类的地方去被持久化，这个顺序没问题吧。
现在假定有一个Domain的两个事件A1与A2要被持久化，A1在A2之前发生。
譬如：
A1 ： 更新person信息。
A2 ： 再次更新person信息。
这两个event通过 event bus 被sent到持久端，这个sent很有可能是走网络，那么如何保证这个两个event还是按照原来的顺序被持久化的呢？
还有一种可能是 虽然是按顺序从event bus里取出，但是server是多CPU的，那么此时也有可能是这两个event被两个cpu同时持久化，这又如何保证其顺序是按照事实的发生顺序而执行的呢？
以前开发都是跟DB打交道的从而能保证这个顺序，因为A1先被持久化了后才是A2。
而现在是 “内存”--》 “event bus” --》“持久化”
比较困惑，希望有人来解惑，thanks
我是这样考虑的， 一个Domain在A点与B点(B在A之后发生，但很近很近)。
又由于多CPU并行的关系，假定这两个event是被并行sent到event bus方，
此时会不会出现 B事件 早于 A事件 被 sent到event bus呢？
如果业务是涉及到money的话，那可就不好了，谁也不想为这小概率事件而付出惨重的代价的。
事件总线或事件系统一个最大特点就是有一个Queue队列，所有事件都按照发生前后关系进入这个队列。
所以，事件消息系统最初大规模应用是在股票交易系统，无论多少人同时交易，总有先来后到，先来先成交。这个模型其实在现实中是普遍的。
to bang
我的意思是指那两个event在进入Queue之前的时候，是否会出现我上面所说的那种可能性呢？
现在都是多CPU并行了，event也是可以并行的，这样CPU的调度就有可能会影响到event被sent到事件总线的顺序。毕竟以前是单核CPU时代
event发生不是CPU发生，而是人为发生，没有绝对时间一样的事件，总是可以精确到毫秒 微妙，甚至几千分之一微妙，只要CPU能够分辨，总是有差别的。
如果不巧的话，两个事件相差只有微妙级别，两个事件被cpu处理时(主要是send到event bus)，此时由于每个cpu的workload不同，是否会造成上述所说的小概率情况呢