NuoDB简介

概述：
NuoDB 是一款新生的面向云的数据库，它支持完整的sql语句，基于MVCC的事务（ACID），同时可以优雅的伸缩性，方便地添加或删除节点。
官网 http://www.nuodb.com/
（在官网可以下载到应用程序和绿皮书，绿皮书在架构方面介绍的很详细） 

基本结构拓扑：
NuoDB的核心是 Transaction Engine(TE) 和 Storage Manager(SM)。 NuoDB集群至少需要有1个TE和1个SM。
TE： 负责 parse, compile, optimize, execute 客户的sql语句 （有点类似NDB里面的sql节点）。
TE是个纯内存的引擎， 它所需要操作的数据一定是位于内存中的。
TE的执行只在本地内存，即一个事务的执行只会在一个TE中（目前版本是这样的）。
TE和TE之间通过复制共享数据，这里的复制是 "partial and on-demand"。 某个TE在执行某个事务过程中如果某些数据本地内存中没有，它就会到其他TE那里去拷贝，需要什么拷贝什么。 如果所有的TE都没有，那么就向SM请求。

SM： 负责数据的持久化，它本身不执行SQL。
当TE向SM请求数据的时候，SM会先查自己的内存，若没有才读硬盘。
SM存储的是Key/Value对， 支持partition。

TE 和SM 的部署没有任何限制， 可以部署多个，在不同的机器上。 一台机器可以只部署TE或SM。

每个部署TE和SM的机器都有个 Agent/Broker 进程。
Agent 负责启动NuoDB集群在该机器的其他进程，如TE/SM， 并且搜集这些进程的统计信息。
Broker 是一个Agent，不同的是它还负责分发客户端的请求到某个TE。

NuoDB的Atom：
Atom是NuoDB的组织架构的基础。 NuoDB中所有的事务管理，数据存储，包括索引等数据库对象都是Atom。
Atom是自治的（不清楚这个自治是怎么弄得，应该不是一个atom一个线程吧，比较可能是有个线程从消息队列中取消息并分发给worker执行这个消息），它通过TE和SM间的消息通信机制与其他Atom交互。
每个Atom都有一个id和1个或多个的copy（自己也是一个copy，所以至少一个）。
Atom的所有copy之间通过异步的消息进行"change replicate"并确保各个copy数据的终一致性（与NOSQL的近一致性不同的事，异步replicate并不影响事务所看到的数据视图一致性，个人认为是通过Atom chairman实现的， Atom chairman后面会介绍）。
Atom的copy中会有一个chairman负责id分配和copy间update的冲突处理（后面会介绍它如何进行多版本控制）。

主要的Atom有：
1. Master Catalog Atom
NuoDB中所有的Catalog Atom都是用来定位其他Atom的， 除了Master Catalog Atom 还有 Table Catalog Atom.
Master Catalog Atom 主要用于追踪那些不太经常新增和删除的Atom，主要有：
Transaction Manager Atom, Schema Atom, Table Atom, Table Catalog Atom, Sequence Atom.
每个TE和SM都会有个Master Catalog Atom 的copy。
<个人觉得Master Catalog Atom有点类似 DNS 服务器>
2. Transaction Manager Atom （TMA）
每个TE和SM都会有一个TMA用于追踪所有的事务活动。 任何一个事务的开启和结束都会通知多有的TMA。
3. Table Atom
主要用于创建Record Atom 和index Atom， 它追踪表的物理定义
<个人觉得有点像mysql的frm>
4. Table Catalog Atom
它主要用于定位这个表的 Record Atom， Blob Atom， Data Atom， 和index Atom。
它保存了每个行的行号与Record Atom的map。
5. Record Atom 和 Blob Atom
Record Atom 追踪行的所有版本, NuoDB的MVCC主要是通过Record Atom来实现的。
每个Record Atom会管理一定数量的行， 大约2000行。
Record Atom会记录行每个版本（该版本关联的事务，表结构，版本号，对应的行数据）
而Blob Atom是没有多版本支持的Record Atom
6. Data Atom
它是用来存储数据的， 每个Data Atom 大约50K的数据
7. Index Atom
它主要记录的是 key的值 和 这个值所对应的 行号
行号= record atom的id + 第几行
<个人觉得有点类似myisam的索引>

NuoDB的事务：
NuoDB是支持 MVCC多版本的，官方说MVCC的实现和PostgreSQL挺像。
在事务的过程中NuoDB不会像INNODB那样在整个事务中持有锁，所有的写冲突都是通过Atom的chairman通过行版本比较来处理。
NuoDB的MVCC实现目前有两个特点：
1. 一个事务只会在一个TE中执行 （据说后面版本会改进）
2. 在一个事务被正式提交的消息广播出去前，该事务的所有变更信息已经发送到相关Atom的所有copy。

下面是一个MVCC中写冲突处理的例子：
假设事务10000 和事务11111想要修改行22222， 行22222所属的Record Atom的chairman为88888.
每个事务首先会修改本地的record atom copy， 然后本地record atom chairman请求修改许可
1. 事务10000所修改的Record Atom向Record Atom 88888发送请求 （我是事务10000，我想修改行22222，我所看到的后一个提交事务号为10001）
2. Record Atom 88888检查行22222的新提交事务号，发现确实是10001，并且没有其他正在修改的事务，于是回复事务10000所修改的Record Atom （ok）
3. 事务11111所修改的Record Atom向Record Atom 88888发送请求 （我是事务111111，我想修改行22222，我所看到的后一个提交事务号为10001）
4. Record Atom 88888检查行22222的新提交事务号，发现事务10000正在修改，于是回复事务11111所修改的Record Atom （你必须等待事务10000）.

如果后事务10000提交成功，它通知所有的TMA， 事务11111所在的TMA会告知事务11111（你的修改失败了）。

涉及到事务就涉及到死锁的问题，NuoDB支持 死锁检测：
当一个事务被告知它需要等待另一个事务的时候， 它会向它所等待的事务以及所有等它的事务的TMA发送消息(我是事务xxx，我在等待事务yyy)。 这样每个TMA都会维护一个事务等待拓扑，如果发现有环，就牺牲掉事务号大的事务，并告知它的用户一个错误消息“dead-lock error”。

数据的持久话策略：
SM保存的数据是key/value对，key是atom的标识，value是atom的序列化。

当Atom的后一个copy从TE中删除前，SM要确保将该Atom的新信息写盘。
SM每次接到commit请求时，会通过实时direct IO直接写日志，而commit的数据则是被放入写队列，一批一批地写。
（个人觉得这个持久话策略，有点像一些主内存的NOSQL数据库，比如HBase的sstable的实现方式）

原文链接：https://blog.csdn.net/gao1738/article/details/42839663