用于高可用性的Event Sourced 架构

13-07-10 banq
                   

Event Sourced Architectures for High Availability

可用性是指用户能够访问系统的能力,并不是开机时间。高可用性意味着,当我们需要时,系统总是能够可用。

99.999%意味高可用性。

MTBF:失败发生时间。

MTTR:恢复时间。

系统暂停:垃圾回收引发的暂停等。

传统事务处理如何实现高可用性?

在正常的状态之间迁移

一旦发生失败替代回滚。

传统事务处理由数据库如Oracle MySQL实现:

>Oracle: SCNs, RAC nodes, replication

> MySQL Cluster: Shards, 2PC, deltas and snapshots

> MySQL: Clustered file systems, replication

其他有Tandem NonStop , IMS TM transaction queue (Apollo Program)

Event Sourced 设计是一种新的思路,

将所有导致状态的改变作为系列事件。

将这些依次发生的系列事件应用于领域模型,从而改变状态。

已经实现的产品:

>Node.js

> Nginx, G-WAN

记录依次发生的事件,恢复时重新播放这些事件,能够重建领域模型状态,测试调试有很好地性能。

快照功能能够加速恢复,不必遍历所有事务日志。


[该贴被banq于2013-07-10 07:28修改过]

                   

bingyang
2013-08-31 21:56

Bang 老师,好;Event Sourced 这种架构对于“单”应用(无依赖关系的操作)比如下订单、修改金额、修改发布单信息,把这些事件依次记录下来都可行,但如果涉及如,转账 这种有A,B对象依赖关系的场景下,如A操作事件已记录下来,但B操作异常(网络,硬件什么的),按照传统的事务机制,B操作失败了这个时候应该回滚A操作,那Event Sourced 是否适应这种“有依赖关系”的场景处理,如果适应 那该怎么处理?望指点下,谢谢

[该贴被bingyang于2013-08-31 21:57修改过]

banq
2013-09-01 08:10

2013-08-31 21:56 "@bingyang

"的内容

如果适应 那该怎么处理 ...

参考这篇文章:http://www.jdon.com/45622/5#23143081

预先检查帐号A,冻结要转帐金额,如果不能完成,解冻,使用业务流程来实现事务,不依靠回滚等技术来实现事务。