关于EDA这种架构模式具体实现问题
大家好,
关于,关于EDA这种架构模式,有些问题,不明白,发个贴,望大家发表下意见::)
1、EDA这种架构记录了一系列的过去事件(比如,用户账户,创建,修改,支付,转账等等),那么该如何获取这个事件(账户)的当前信息呢?
我自己思考认为,既然EDA要记录过去一连串的事件,那么,创建,修改,支付等等本来也就是一个个事件,所以在数据落地时,至少有两张记录,A,用户实际发出的动作的内容(支付事件,创建事件),B,用户实际发出的动作的分类(创建,支付),那么在获取用户账户当前信息时,先获取用户最后一个动作(创建,支付)再到(创建,支付)事件列表中,获取最后一个事件记录,而最后一个记录的话是某种规则排序(事件ID,事件记录时间),是这样的吗?
2、论坛里有个例子(具体页面UIL我记不起来了),是用户转账(A,B账户)有个关键点,“冻结账户”,那个”冻结“实际操作起来是怎样的?给这个A账户加个状态吗?符合转账业务要求,就修改这个“状态”是这样的吗?如果修改的话那这里又可能涉及到并发了是吧?zookeeper是可以实现集群协调管理,如果“冻结”某个对象,放到zookeeper注册个节点,其他操作去读取这个节点,应该也可以的吧?
3、EDA以记录事件的方式避免了随机写,那么该如何避免随机读呢(当然我个人认为解决了随机写,那么程序的性能应该提升很多的,对于读找个NoSQL应该可以的,呵呵)?一个用户或者一个事件类别一个存储吗?这系列事件以何种方式存储,该怎么考究呢?
4、对于两个有前后依赖的事件,常规的做法是用SQL事务机制保证一致,但这可能又成为性能的杀手了,我们是否可以用某种其他机制来实现“伪事务”?,具体到EDA事件架构该如何实现呢?
希望得到大家的经验啊
[该贴被bingyang于2013-10-25 13:58修改过]
[该贴被bingyang于2013-10-25 14:08修改过]
[该贴被bingyang于2013-10-25 14:09修改过]
[该贴被bingyang于2013-10-25 14:10修改过]