Overview
- 数据库的事务处理。
- 如何解决Web Server和DB之间的操作失误问题？
Possible1:将这种transaction保证成原子的。(atomic) - 毕竟Browser和Web Server之间交互失误可以用timeout解决。
- 为什么说将多个transaction捆绑成一个是很暴力的操作?
无法可控事务的执行周期，如持有锁的时间过短/过长。
那我们当然要避免暴力，来使用“事务“解决一些问题，“事务“所针对的问题，即”数据一致性的问题“。
毕竟咱不能只买一个东西，却在DB记录上扣了两笔钱嘛。:D
文档数据库如何解决数据一致性的问题?
案例
Case1:评论一篇博客：需要添加一条评论，并且将评论总数加1–利用Embedding解决
回想上节DBdesign，我们在时是将comment嵌入在blog中，即blog{commentCount，comment[content,OID]}.
我们这样设计，就不会出现这种问题。所以数据库设计时，我们 把同时更新的东西放在一起，同时 被更新的东西，往往被同时访问。
Case2:博客用户更新自己的名字–利用标记flag解决
虽然改名字很少，但是改名字要对我写的博客做一系列更新。需要100/1000次CRUD.
假设我在这么多次CRUD中宕掉了，如何让其他Server接着改?
改名时，记录属性flag_update_name，将这个字段取两个值{‘incomplete’/‘complete’}。开始改名的时候set flag_update_name incomplete，对立的那个以此类推嘛。
这种方式，叫标记。下面这个例子中，flag就是namesync。
改名也要满足幂等。
1 |
|
Case3:新增粉丝/关注–利用消息队列解决
回想上节DBdesign，我们在user中有，user{follower:[],followee:[]}，用这种记录方式需要两次更新。
解决方法：新开一个文档集叫Job(作业)
Job:{op:add_follow,follow_id,followee_id,flage:{}}。
每次新增的时候就往里面新插入一个文档集。
改User时，follower/followee的添加变成了4个CRUD操作。如果此时中间故障，我们始终有一个server在监控Job中incomplete的flag,这样我只要做我没做完的就可以了。
做Job时要满足幂等，不满足，做不了。
幂等
$$
F^n(X)=F(X)
$$
即一个操作我无论改多少次，我得到的结果都是一样的。
如：改名为Tom;加一个粉丝叫Jerry。这种例子都符合幂等。
为什么要求是幂等的？
对于montior,不管什么重做的次数，效果都是一样的。
但有很多操作不是幂等的，如对同一个变量修改。在真实应用中的例子是，转账。
不幂等的时候如何解决数据一致性的问题呢?
案例4:转账(了解)
UserAccount{name:Tom; balance:500;op_count:20}
UserAccount{name:John; balance:300;op_count:18}
新增日志Log:R1，R2，R3；
当我出问题的时候，我就回溯的日志的时间点上。
日志将以什么形式记录呢？
{Tom_balance:500,John_balance:300,John_op:+100,Tom_op:-100,Tom_op_count:20,John_op_count:18,Flag:incomplete}；
find_and_modify：不单单是update操作:1.op_count++ 2. 同时返回balance和op_count.//任何一个人改，op_count都要变化。
转账操作时：先在日志文档集中添加某些记录信息(如上形式)
find_and_modify在写记录前调用。
那我出问题的：
UserAccount{name:Tom; balance:400;op_count:20}；
我该如何复原呢？
此时，我肯定知道flag:incomplete.然后，我再去对照op_count.若op_count从20->21：说明有其他对balance修改过。若op_count没变，那我对比日志复原再做即可。
Op_count check去判断有🈚️其他的转账动过这个值。
如果有其他的转账动过这个值，就只能回归，设置起点，重放。
感觉幂等和不幂等核心区别在于，我这个数据修改操作被修改了几次。
Op_count:time_stamp;
Compensation:补救方式。
总结
掌握标记/消息队列；转账这种了解。
NoSQL数据库通常不支持事务！
只保证单个操作的原子性。
虽然MongoDB支持Multi-document Transaction，但不鼓励使用。
原因：事务的性能得不到保证。
通常把数据一致性的问题交给应用来解决。
