关于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修改过]

我初步看了你的问题，感觉比较难以回答，有点无从下手。

首先，你问的问题是关于Event Sourcing事件溯源方面的具体问题，和EDA这个大架构本身无关。

EDA是事件驱动架构，但是不是一定要对事件进行保存溯源，比如SOA+EDA还能保持原来的数据库方式不变，而CQRS+EventSourcing则是可能对事件进行存储然后进行回放。

挑我能回答的试图回答一下：
第三个问题，记录事件本身是一种append追加到文件的方式，这种方式对于文件的写操作效率性能最好，但是不是说避免了随机写的问题，随机读更不能避免，随机读随机写如果是业务特点，那么可以初步判断该业务数据多为非结构数据。

2013-10-25 14:58 "@banq"的内容

首先，你问的问题是关于Event Sourcing事件溯源方面的具体问题，和EDA这个大架构本身无关。 ...

多谢提点，下来我再琢磨下。对于CQRS，EDA，EeventSource 你是否考虑出书之类的，把这方面的技术系统化下。我也在关注这么方面的技术，发觉大多是谈理论如果能结合实际项目来阐述，伦理落地，就更好了，呵呵。
我梳理下这几个问题，以表达清楚些。
CQRS，EDA，EeventSource 这样理解你看对不对：
CQRS是整个业务的高度抽象（抽象出读写，就像storm的spout，和bolt）而对Command操作使用EDA驱动来处理，最终结果形成一个个事件Event，最终成为EventSource事件源
,而再次获取某个点的事件，则通过CQRS回放（EventSource作为数据源），回放就如电影一样，可以指定回放到某个点，那么这点可以是任意的。
这样理解对不？
第 1 个问题，比如我是用户，打个某个网站页面查下账号当前信息（这之前可能涉及到很多操作，诸如，创建，支付，充值，冻结啊什么的），CRQS+EventSource回放事件，我们是不是要指定某个点？那CRQS，EventSource，EDA内存怎么处理的？
第 2 个问题，我就想知道“转账”这个典型的例子中，很多资料都说，先“冻结”账户再转账，那么这个“冻结”具体该怎么实现，我想应该不会是往存储中插个字段，去修改吧，只是我的想法，希望有具体的回答
第 4 个问题，锁，事务确实是性能的瓶颈（数据量到达某个级别），之前我看到有个帖子（具体的样子不清楚了）
说可以是队列实现事务的，具体怎么实现，通篇看完感觉也没说清楚，我很赞成你之前帖子说的“弱一致”的观点，“弱一致”也是一致只是不是
事务那样强一致，是吧？队列实现事务是条具体实现“事务”的途径而已，那么咋实现呢，或者其他途径是什么？