84年的矿泉水

博客园 首页 新随笔 联系 订阅 管理

  昨天晚上未加班,回家继续albian。发现了两个问题。

  目前albian已经可以简单的保存数据了,albian提供了2个create的重载:保存一个实体、保存多个实体。在保存一个实体的时候未发生问题,数据能准确的根据路由保存到我们指定的数据库和表。在保存多个实体时,开始测试了保存两种不同的实体:比如一个order、另外一个bizoffer,也不会出问题。但是在保存两个相同类型的实体时(比如两个order)。就发生了问题:后面的一个实体数据会覆盖掉前面的一个实体数据。开始怀疑是不是在分配storagecontext的时候出错了,后来debug未发现;再怀疑是不是sql语句出现了问题,debug后还是未发现问题;只能看代码,发现自己在建模的时候就已经犯下的错误。在我当初的建模中,storagecontext中的cmd和paras是使用IDictionary<string,dbpara[]>结构来存储的,当时的想法是:一个cmdtext对应一个它自己的参数;这样IDictionary结构正好可以满足要求,但是这种情况,如果发生在cmdtext相同的时候就会出问题了,因为我做了替换的操作,所以后面的实体会更新掉前面的实体数据。其实自己傻掉了,但是cmd-paras的结构是有实体类承载的,这边只要改成IList即可。重构代码,test用例一遍走过,没问题了。

  第二个碰到问题的是albian的代码结构问题。开始的时候,我想对DML的操作创建一个接口,然后不同的操作实现这个接口。但是经过create的代码重构,发现除了拼SQL部分的代码不一样之外,别的代码都一模一样。这样的话,这个接口就一个方法(比如叫GetSql),开始感觉还行,但是怎么的越看越不顺眼,后来一想,一个方法的接口不就是委托嘛?全部改成委托,每个实现方法按照委托的签名编写,然后通过参数传递进去不就剩下了很多代码吗?还省下了继承接口这种体力活。这样,这部分也改成了委托。

  问题解释:

  就上一篇文章中提到的“伪分布式事务”问题进行一下解答。albian使用的事务管理是每个数据库一个事务,然后分步操作,等全部操作完成后分步提交的方式。这种方式确实会存在一定的风险性。可能出现问题的地方是如果我们有2(A,B)个操作需要提交。当我们提交了A之后再提交B。如果在这两个操作中间(提交了A,正要提交B)发生了网络的中断或者B机器的down机,那么我们的程序将会rollback事务。但是对于A而言,操作已经被commit了,已经成了永久存储,无法被rollback,这样我们的系统中就出现了脏数据。对于这种情况,我们可以根据情况进行补救,比如在保存之后判断是否操作正确,不正确的话执行一段补救代码。但是对于一般的系统,并不需要这样做。类似于刚刚的操作问题其实只有在分布式系统的情况下才可能发生。对于分布式系统,对于单节点的CAP理论已经不能适用了。你必须放弃CAP中的任何一种特性,满足剩下的两种特性。albian放弃的是一致性,其实你分析事务那段源代码很容易就能得出我们使用了“最后一致性”来保证数据的完整性。在分布式系统中,一般对于数据的完整性要求不那么高,至少不会是100%。高的可能是99。99%,低的可能是95%,甚至还有更低的。当然这些指标数据只是对于一段时间内(比如一个数据库的访问,或者一个用户对于系统的访问)的数据完整性而言,最后我们还是会通过复制、同步等等外在的方法来达到系统内的数据一致性。

  就CAP理论在分布式系统中的使用,请g之!

posted on 2011-06-28 10:07  xvhfeng  阅读(684)  评论(1编辑  收藏  举报