Trafodion这个词的本意是“事务”，可见项目组对事务处理的重视程度。

事务主要用来防止和处理数据出现不一致的错误。首先理解什么是数据一致性，给出具体的定义实在太为难笔者。还是举个例子吧。笔者年轻时大家都知道“香港四大天王”，他们是刘德华，张学友，黎明和郭富城。我定义这四个名字是“一致的”，而“刘学友”或者“张德华”就不是一致性的数据。或者在介绍的时候不全：比如“香港四大天王是：刘德华,”，其他天王要不高兴了。另外，刘德华唱过《忘情水》，如果数据库查询得到刘德华唱了《吻别》，也是不一致的数据。

造成数据不一致主要有两种因素，分别用两种事务技术解决。在Trafodion中，一个技术是日志；另一个技术是多版本并发控制MVCC。

日志

第一种造成数据不一致的因素是不可预知的故障。故障会导致正在处理数据的过程异常中断，比如数据正在往磁盘中写入的时候系统断电，那么结果就是未知的，有可能写入了不完整的数据。比如应该写入”张学友”覆盖原本的”刘德华”，却只写了”张”，剩下两个字节没来得及写入，所以还是老数据，于是磁盘数据变成“张德华”，造成数据了不一致，从来没有这个天王；或者说正在顺序写入四个人的名字，断电了，只写了刘德华，其他人都没写，也是不一致，要么4位全写，要么全都不写，写一个漏掉其他算是什么意思，看不起其他天王么？

处理这类错误的方法是WAL日志，write ahead log。即每次写入数据之前，先将变化写入日志，再写数据。这样，如果有错误发生，通过查询日志，就可以进行恢复。比如前面的例子，在将“张学友”写入数据文件之前，先写入日志。这样即便发生了故障，也不会有问题，如果故障发生在写日志的过程中，那么数据文件中依然是“刘德华”。如果故障发生在写数据文件的过程中，那么虽然数据文件中是“张德华”，但是WAL日志中却是正确的数据“张学友”，我们将日志replay一下，用“张学友”覆盖“张德华”即可。
如果遇到写中断错误，则可以利用日志将做过的操作全部撤销，比如写入了刘德华，然后出错了，查询日志，发现已经写了刘德华，那么rollback就是把“刘德华”删除掉。
通过日志，保证了在任何错误情况下，事务的一致性，即ACID中的A和D。

传统的日志技术包括Redo，undo, redo/undo等。和所有其他数据库一样，Trafodion采用redo/undo日志。

Trafodion采用HBase的WAL做Redo日志，当region恢复时，HBase负责回放WAL进行恢复。

在R1.0版本中，Trafodion将写入数据缓存在内存中，提交的时候才将内存中的数据写入磁盘，因此不需要undo日志。如果事务需要回滚，只需要将内存中的数据丢弃即可。

目前计划在R1.2版本中，Trafodion将使用一种被称为SSCC的最新技术，SSCC利用HBase的多版本支持存储数据的变化历史，以便提供repeated read隔离级别，这些数据历史同时作为undo日志。

关于SSCC的原理，读者可以进一步参考开源项目Domino: https://github.com/domino-succ/domino

MVCC的并发控制方法

还有一种错误，靠日志也不管用，就是多个事务并发写同一个数据，这类错误和我们在多线程程序中修改共享变量时发生的race condition是同一类问题。比如我们有两个线程写数据库，都要更新歌曲排行榜的第一名。线程A写入一行数据：[ singer=>刘德华, song=>忘情水]；线程B写入另一行数据[ singer=>张学友，song=>吻别]。A和B一起写，一种可能的写法为A写了歌手后被B打断，B写了歌手和歌曲，A恢复执行，写入歌曲。最后变成了[ singer=>张学友, song=>忘情水]。可是张学友没有唱过《忘情水》。

处理第二类错误的方法被称为并发控制。通常有两种解决方案，第一种是传统的数据库通常使用的方法，即锁管理器；第二种是MVCC（多版本并发控制）。Trafodion采用MVCC的方法，没有使用锁管理器。因此在Trafodion中没有因为锁而引起的读写阻塞和死锁问题。
MVCC的基本思想和人们使用SVN版本控制系统是一样的，每个程序员都是一个事务，而修改的代码就是数据库中的表。如果用sourcesafe，那么就类似锁管理，张三修改写文件A的时候别人谁都不能读写，等张三修改完check in才行。用SVN后，如果张三正在写文件A，他写的是本地的一个版本，另外的人想读，可以随时读；别的程序员也可以修改文件A。但是两个人不能都commit。先commit的人成功，后commit的人需要做merge，如果两个人修改了不同的行（类似两个事务修改不同数据行），则一般都可以commit，SVN可以自动merge。否则就有冲突，需要第二个commit的人手动merge，或者干脆放弃(Abort)。Trafodion的MVCC方法和这个过程完全一样。

HBase本身提供多版本服务，因此非常适合采用MVCC技术。每个写操作都会产生一个新的数据版本，而不会覆盖老版本数据。读操作根据事务开始时间，读取正确的数据版本，即数据的一个历史快照。这避免了幻读，提供了repeated read隔离级别的保证。笔者孤陋寡闻，窃以为MVCC是Oracle最先采用的，Oracle工程师经常对此非常自豪，因为读不会被写阻塞，提供了很高的并行度。后来innodb山寨了Oracle的所有实现细节，使得MySQL也拥有了类似的能力；PostgreSql则采用了和Oracle/innoDb不同的MVCC实现方法，Trafodion的实现更加类似于Postgresql，即保存多版本数据用来提供快照读取，而非用作undo日志，然后定期进行垃圾收集，删除过期的快照。而Oracle则利用了undo日志来作为历史快照；前者读取历史版本的速度很快，因为数据和快照都在一起，但需要处理每条历史数据，检查它们的可见性，比较低效；Oracle则需要到undo segment中读取历史数据，应用undo日志对数据进行回滚，貌似会比较慢；但是不需要考虑GC的问题，而且节约了空间，因为undo空间一举两得。所以笔者认为Oracle/InnoDB的模式好些，但也主要还是取决于具体的应用场景，假如并发很高，读取历史版本的比例比读取最近数据的频率还要高，则PostgreSQL/Trafodion的模式应该更好，因为它们读取快照的效率更好。
不过作者水平经验都很有限，在这里议论其他产品有点儿心中坎坷，各位如果不以为然还请不吝赐教。

在Commit的时候，进行write-write冲突检测。如果发现两个并发事务同时写一行数据，就依据”first committer win”的原则处理，第一个提交的事务成功，而其他的事务则失败回滚。如前所述的线程A和B，A写入歌手信息刘德华之后，被打断，B写入张学友唱《吻别》，这条数据不会覆盖原始数据，而是新生成一条记录，(有些人喜欢称为COW)，这条记录用线程B的事务ID标记它。这时线程A被调度回来，继续写入，同样A写的刘德华唱《忘情水》也不会覆盖原始数据，而是新生成一条新的记录，用A的事务ID标记。在commit的时候，Trafodion发现，这同一行数据有两条新纪录，根据first commit win的原则，A获胜。所以如果线程A提交，会成功；而线程B提交的时候会报错，回滚。最终数据库的记录为刘德华唱的《忘情水》。是一致的。

Trafodion目前的版本为R1.0，在今后的版本中(计划在R1.2版本中)使能一种新的并发控制算法SSCC。SSCC是中科院的研究成果，Trafodion团队和中科院紧密合作，即将推出这一全新的并发控制机制，SSCC提供比SnapShot Isolation更高级的隔离级别，同时对无状态写操作有很高效的支持。
SSCC认为SQL的写操作有两种：stateful的写比如a=a+1，是有状态的；stateless的写，比如delete，或者覆盖旧数据，这类写操作和历史状态无关。
无状态写在web应用中非常普遍，比如Google的index generating。采用这一机制，Trafodion可以高效地为相关的web应用提供强大的支持。读者可以参阅https://github.com/domino-succ/domino进一步了解SSCC。

笔者也会尝试在后续的博客中介绍SSCC这一创新的并发控制算法。

并发控制保证了ACID中的I。
最后还有ACID的C没有提到，是"一致"的意思，然而这个C却不是靠事务处理器来保证的。ACID的Consistency靠数据库的约束保证。因此笔者不喜欢用ACID来描述事务。但是这个是经典，也不得不提。

两阶段提交

对于单机的数据库，比如MySQL，Oracle (not RAC)，SQL Server，PostgreSql (not xl版)等，以上两个技术就完全可以实现ACID事务了。但是Trafodion是一个分布式数据库，操作分布在集群的不同节点执行，比如两条写操作可能由两个不同的ESP在不同节点运行，所以Trafodion还需要处理分布式事务。

Trafodion的事务处理器将并发控制的职责分成两部分，TM(Transaction Manager)负责整个事务的分布式并发控制，保证事务本身的一致性；RM(Resource Manager)负责数据访问的并发控制，保证数据的一致性。

具体来说，RM采用前面所说的MVCC技术，提供Snapshot Isolation级别的数据一致性。

在Trafodion中，每个HBase的Region都是一个RM。一个事务很可能会在多个Region上操作，比如事务需要更新两行数据，而它们分别属于两个不同的Region。在这种情况下，一个事务会有多个RM参与。而HBase的Region很可能运行在不同的物理节点上，因此这是一种分布式事务。分布式事务由TM保证整个事务的一致性。

TM使用两阶段提交协议来保证分布式事务的一致性。两阶段提交是一个非常简单直观的协议，类似公司的秘书安排几个人都必须参加的会议。第一阶段：秘书发信给所有参与者：“周一下午3点开会，OK?”，如果所有有人都回复“OK”，则最终决定开会进入第二阶段；如果有人回答no，或者有人不回答，则不开会进入第二阶段；第二阶段根据第一阶段的结果进行不同处理，如果是开会，秘书给每个人发信: '确定周一下午3点开会'；如果不开会，秘书给每个人发信：‘不开会’。

每个事务都由一个TM发起，事务开始的时候，TM会给事务创建一个ID。此后，事务中的每一个DML操作都带有该ID，用来在RM内部确定该读取的数据版本。

在提交的时候，TM先进行第一阶段的prepare commit，向每个RM发送prepare消息。RM在收到prepare消息时，进行write-write冲突检测，如果有冲突则返回冲突，否则返回提交成功。TM得到所有RM的回复后进行判断，如果所有的RM都提交成功，则该事务成功，否则事务失败；进入第二阶段，如果事务成功，TM向所有RM发送commit消息，每一个RM收到commit消息后将事务的所有操作都写入物理磁盘，完成事务处理；如果有任何一个RM返回冲突，或者任何一个RM超时没有反应，TM认为事务失败，在第二阶段向所有的RM发送abort消息；每个RM在收到abort消息后进行事务回滚操作。

DDL事务

从R1.1版本开始，Trafodion还支持DDL的事务处理，比如创建2个表，第一个成功，第二个失败，回滚后，两个表都不存在。

小结

支持Transaction On HBase的方案有很多。最著名的是源自Yahoo的Omid, omid的原始开源版本有一些问题，omid开发人员在修正了问题后却决定不再开源，而成立了一个商业公司开始卖产品了（LeanXscale)，所以大家也无法获得最新的omid代码；另外比较好的算法还有Tephra，目前由CASK公司进行商业运作，作为其中间件的一个关键组成部分，不过还是开源；还有小米公司的Themis，但是还未见在其他系统中有所应用，小米公司在HBase方面有很多的贡献，值得尊敬。这些方案都可以看作基于Google Percolator的开源实现。

这些方案都有一个共同的被称为Status Oracle的中央元数据管理单元。而Trafodion则是一个完全分布式的实现，是一个去中心化的设计，不存在任何一个中央处理器，避免了Single point of failure和扩展瓶颈。

当然，一个类似Master的单点设计并不一定意味着扩展性受限。分布式理论界有很多避免单点的算法。然而，笔者听说过的最大集群却是Hadoop，采用的是最简单的Master/Slave设计。在Facebook据说有3000节点的cluster；在Yahoo更有报道说有10,000节点的Hadoop集群。
而采用Paxos或者Totem的集群有大于100节点的么？估计有，不过笔者从来没有听到类似的广告，如果有应该大力宣传才是。

有鉴于此，Trafodion DTM团队会认真研究并评估其他的解决方案，会不断改进，争取更好。