分布式架构理论篇
大型分布式系统原理概述
分布式系统三要素
CPU:处理器
Memory:内存
IO:外存
MultiCore:多核心
LocalDisk:本地磁盘
Networker:网络，网络存储
RDMA:远程内存直接访问
NUMA:分布式系统CPU和内存进行整合，对内存进行捆绑，是硬件层级的，（相似与ThreadLocal,将数据和实时运行线程绑定到一起），网卡直接绕过CPU共享内存，速度非常快
分布式系统三要素的进化
桌面级八核心十六线程CPU于2014年诞生，2015年Intel预计发布18核心桌面级CPU
NUMA在大中型系统上一直非常盛行，NUMA能很好提升系统吞吐能力，特别对于Java以及数据这样占用大内存的系统，但一直以来没有得到 DBA 们足够的重视、 Java领域也很少有人研究
RDMA（远程内存直接访问，网络传输协议，类似TCP,更低延迟）是超高性能计算UHPC的重要基础之一，而Direct Socket Protocol （SDP）作为RDMA的传输协议已经在很多关键领域取代了TCP，Java7也正式开始支持SDP，跨入了UHPC的领地。
IO方面，万兆网正在崛起，万兆网的ISCSI存储， 单通道可达到500MB/s， 每秒500,000个IO能力，而目前主流的SSD硬盘的速度是400-550MB/s。
===>虚拟化，大势所趋
NUMA与RMDA（Java）
两个核心的CPU，里面有自己的本地线程，内存块整个分为两块，Memory1和Memory2,每个内存核心绑定它的内存和IO的PC卡划成两个Domain域，这两个通过总线通信，这是一个典型的分布式系统，将计算能力和内存进行了分布，BUS相当于总线，这是一个经典的分布式架构，它把软件架构思想用到了硬件中
RMDA可以用InfiniBand也可以用专用网卡，SDP通信的时候应用端程序把数据写到缓冲区，缓冲区直接到网卡传输出去，OS旁路，CPU就是旁路，CPU不涉及到数据的传输，比如说现在要传输一个流量，OS不会产生传输的中断，应用缓冲区放到OS中，这是一个零拷贝的技术，所以它延迟非常低， 它把OS、CPU旁路了，所以响应性能是非常高的
这个技术会在大数据时代发挥非常重要的作用，这种情况下，如果有硬件大的要求，那么实际网络传输会很快从一个节点到另一个节点，那么它的计算会加快很多
硬盘成了主角？
这种硬盘把CPU、内存、网卡绑定在自身上，这种硬盘已经构成了一个小型的计算机，而且直接提供了因特网的传输节点，这样就可以在1U和2U的机架里面放很多块硬盘，很多小块密集在一起就构成了一个大的密集存储，它是一个嵌入的定制系统，它的IO传输效率非常高，它是TCP的网络节点，如果在之上放一个万兆交换机就直接构成了存储模块，而且价格低廉性能高，拓展性高，专供云计算
最成功的企业级分布式系统架构——J2EE
Java在很多人看来等同于J2EE（企业级的应用开发框架），这是其他任何语言都没有过的奇迹
1999年J2EE诞生，J2EE一出台就能够为人们提供一幅完整、直观而不失深邃的图景
到2000年底为止，共有15家厂商能够提供完整的J2EE解决方案，这些中的大多数都是IT界的大佬
2008年J2EE里的实力派BEA公司被Oracle 85亿收购， 对比2009年74亿收购了SUN
J2EE规范是一系列符合工业级技术和质量标准的规范，学术机构、业内厂商都广泛参与讨论和规划，拥有一个庞大的社区
直到今天，J2EE里的JDBC、 Servlet/JSP等技术仍然是企业级应用开发必不可缺少的关键技术
奠定分布式系统架构基础的那些组件
三层结构，客户端、中间层（WEB(servlet)/EJB）,
JNDI:提供查询服务，服务定位，技术中间件，比如说协议+IP+端口，基础设施
JMS:消息中间件
RMI:RPC远程服务调用，两者通信，相当于访问本地方法一样访问远程方法，基础设施
大数据和移动互联网引发的革新
移动互联网=用户数据，特点就是随时接纳用户数据，所有互联网公司竞争烧钱就是为了攒用户，用户会产生很多数据，这些数据非常有价值，这种价值挖掘经过大数据处理，这种数据处理规模非常大，跟传统的企业级开发不一样，它需要专用的软件和算法来处理这些数据，这些数据处理的目的就是预测机会商机，这些机会商机意为着更早的转化更多的金钱，这些围绕着大数据， 这里面有一个很重要的因素叫做时间，如果一个人 一周后得到结果和另一个人一周后得到结果，这种数据就丧失更多的价值， 因此时间是非常关键制约点，导致大数据发生了很多变动，就是实时，像Hadoop这种批处理的离线数据处理更多了转向了Spark和Storm这种实时性，数据上往往加上时间的纬度，可以把不同的数据根据不同的数据进行处理，快速高效的进行处理，可以做行为轨迹分析
云计算所引导的软件定义世界，意味着什么
云计算的三个突出特点，硬件虚拟化、软件定义网络、软件定义存储，这意味一个软件架构师可以从软件角度架构整个项目，从部署到上线
一切都在悄然进化着，一个我们熟悉而又陌生的新世界
开源、分布式系统中重要的中间件或基础设施
分布式系统之网络篇
80%的程序员所欠缺的网络知识
服务器网卡的一些秘密
硬件不同
传统的PC机器的PCI接口66MHz 133Mb/s而服务器的主板支持PCI-E X16 8bit 2.5GHz 8Gb/sTCP/IP卸载引擎(TOE)技术
价格昂贵
性能出众
Intel x520-t2 10Gbase-t万兆网卡（4800元报价）测试，单端口单向实际测试结果是1248MB/s(9984Mbps)， 达到理论峰值的99.84%
技术门槛高
intel、BROADCOM、H3C(新IT基础架构领导者)
MAC地址、 IP、子网掩码、网关及路由
VLAN的原理
管理网络、业务网络、存储网络
网络的最前沿技术之网络虚拟化
服务器虚拟化技术与网络虚拟化技术相辅相成
Open vswitch
SDN&网络虚拟化
关于NIO与AIO的那些小秘密
Linux AIO的奇葩十年路
Java NIO VS AIO
AIO带来了编程的大幅简化和优化
AIO性能目前不如NIO
AIO当前比较适合大文件的读写
现阶段网络编程主要还是NIO
NIO最佳实践
Reactor线程的数量
Direct Buffer Pool的使用
Reactor线程与异步线程池的合理使用
国内最好的NIO实践，就在开源项目Mycat里
Java AIO编程框架
网络编程中的一朵金花之Netty
为什么选择Netty
NIO入门门槛高，精通很困难
除了NIO本身，企业级的Socket Server还需要大量外围代码开发
Netty是业界最流行的NIO框架之一，几乎没有对手
Netty的作者也是开发了大名鼎鼎的Apache Mina的作者
Netty的优势
多种Reactor线程池模式
网络数据串行处理，减少线程切换
强大的Buffer池
娴熟的高并发编程技巧（Volatile、CAS、 ThreadLocal等的使用）
作者很多年网络编程经验的积累与提升
Netty默认提供了对Google Protobuf的支持，通过扩展Netty的编解码接口，用户可以实现其它的高性能序列化框架，例如Thrift的压缩二进制编解码框架
Vert.x—— JVM上的Node.js
网络编程中的瑞士军刀之Zookeeper
Zookpeer能做什么
类似JNDI的命名服务
实现分布式系统中的配置服务
提供简单好用的分布式同步服务
提供简单好用的分布式协调框架
可以作为一个简单的可靠的消息队列
Zookpeer的原理
ZK提供类似文件目录树的数据结构，每个节点可以设置byte[]数据
节点类型可以是持久化保存的，也可以是临时的(EPHEMERAL)
Zookeeper 特点
原子性：更新要么成功，要么失败，不会出现部分更新
可靠性：一旦数据更新成功，将一直保持，直到新的更新
单一性 ：无论客户端连接哪个server，都会看到同一个视图
及时性：客户端会在一个确定的时间内得到最新的数据。
等待无关：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待
顺序一致性：按照客户端发送请求的顺序更新数据，包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面
ZK应用场景之命名服务
ZK创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用
ZK应用场景之分布式配置管理
ZK应用场景之分布式集群管理
每个节点（进程）启动的时候在ZK路径GroupMembers下建立子路径（节点ID为路径名），通信地址Endpoint则写到路径的Data中
每个节点监听ZK路径GroupMembers，当集群中增加新节点或故障节点下线，每个节点都会获得通知
ZK应用场景之消息队列
消息发送方在ZK上创建一个Path，发送消息时，将消息信息设置为该Path的内容，而消息接收方则监听此Path，实现了简单可靠的发布订阅模式的消息队列
ZK应用场景之分布式锁
Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁
Zookeeper的性能调优和规模
ZK的日志文件和snapshort文件分别放在两块硬盘上
Leader节点不允许Client连接
网上所能见到的信息，最大为1万个连接（客户端），
5节点的ZK集群
Zookeeper客户端Curator
“Guava is to Java what Curator is to Zookeeper Patrick Hunt,Zookeeper committer”
Fluent Style风格
NetFlix出品
极大程度上减少了程序猿的负担
接管了Client与Server的连接重连问题
提供了各种常用ZK应用场景的抽象封装（如共享锁服务、 Leader选举）
Curator的关键用法
列出子目录： CuratorFramework.getChildren().forPath(path)
public boolean exists(String parentPath,String path) throws Exception{
Stat stat = zk.checkExists().forPath(parentPath+"/"+path);
return (stat != null );
} 创建目录
result = zk.create().withMode(createMode).forPath(path,nodeData);
监听ZK节点的变化并做出相应的处理
Curator的几个问题
若ZK Server还未启动，用户程序先启动了，则虽然Curator能够后来自动重连上，但之前的创建节点和监听事件将不会起效.
List<PathChildrenCache> allZKWathers = new LinkedList<PathChildrenCache>();
PathChildrenCache cache = new PathChildrenCache(zk, path, false);
cache.getListenable().addListener(plis);
cache.start();
allZKWathers.add(cache);方法一：
org.apache.zookeeper.Watcher来监听Connection的状态，CuratorZookeeperClient(connectString,TimeoutMs, int connectionTimeoutMs,watcher, retryPolicy)
当连接建立后触发PathChildrenCache的rebuild方法，重新监听路径
方法二：定时线程，每隔几分钟调用PathChildrenCache的rebuild方法
Netty+Zookeeper实践项目分析
分布式系统之文件
Linux文件系统的进化
两种文件系统
日志型的与非日志型的
非日志型文件系统
ext2、 FAT、 VFAT、 HPFS（OS/2）、 NTFS、 Sun的UFS等
日志型文件系统
ext3 许多流行的Linux发行版默认的文件系统
ext4 由ext3增加许多显著特性和扩展进化而来的文件系统
ReiserFS 全新设计的文件系统
JFS IBM移植的UNIX文件系统
XFS 为高性能和大文件设计的文件系统
Btrfs 校检copy-on-write(写入时复制)文件系统
ext4(6) —–> XFS(7)
当前文件系统中的几个强者
Facebook已经开始全线换用btrfs
红帽的Red 6使用ext4， 7则使用了XFS
浙江省十二五重大科技专项资助项目研究了ZFS在基于Hadoop的视频存储系统中的应用
经典的第一代分布式文件系统NFS
传统的分布式文件系统
经典的第一代分布式文件系统NFS
一个分布式文件系统中有两种不同的软件：客户端文件系统
和文件服务器。它们的行为共同决定分布式文件系统的行为
对后来的分布式文件系统有重要影响的AFS
新型分布式文件系统
PVFS， Linux开源的并行虚拟文件系统
管理节点： 即元数据服务器，负责管理所有的文件元数
据信息；
I/O节点： 运行I/O服务器，负责分布式文件系统中数据
的存储和检索；
计算节点： 处理应用访问，通过PVFS专有的libpvfs接口
库，从底层访问PVFS服务器。
Lustre ，专门针对高性能计算的基于对象存储的分布式文件系统
条带化
gluster fs:代替Lustre的开源的分布式文件系统
Google文件系统（GoogleFS）
HDFS（Hadoop）
ceph：新一代的复合型分布式文件系统
Ceph是统一存储系统，支持三种接口。
Object： 有原生的API， 而且也兼容Swift和S3的API
Block： 支持精简配置、快照、克隆
File： Posix接口，支持快照
互联网领域中的小文件系统
MogileFS——影响最大的互联网小文件系统
FastDFS——穷人的解决方案（国产小有名气）
TFS——淘宝的HDFS Copy版本
GridFS——
MogileFS架构和原理
在MogileFS分布式文件存储系统中，文件通过 KEY 来引用， KEY 在同一个domain（存储域）下是唯一的，每个存储域可以定义不同的文件类别Class，可以针对不同的存储类别设置存储不同份数的文件副本
MogileFS的特性
应用层 — 不需要特殊的核心组件
无单点失败 — MogileFS分布式文件存储系统安装的三个组件（存储节点、跟踪器、跟踪用的数据库）,均可运行在多个 机器上,因此没有单点失败， 推荐至少两台机器。
自动的文件复制 — 基于不同的文件“分类” ,文件可以被自动的复制到多个有足够存储空间的存储节点上,这样可以满足这个“类别”的最少复制要求.比如你有一个图片网站,你可以设置原始的JPEG图片需要复制 至少三份,但实际只有1or2份拷贝,如果丢失了数据,那么MogileFS分布式文件存储系统可以重新建立遗失的拷贝数
“比RAID好多了” —RAID磁盘是冗余的,但主机不是,如果你整个机器坏了,那么文件也将不能访问. MogileFS分布式文件存储系统在不同的机器之间进行文件复制,因此文件始终是可用的
不需要RAID — 在MogileFS中的磁盘可以是做了RAID的也可以是没有,如果是为了安全性着想的话RAID没有必要买了,因为MogileFS分布式文件存储系统已经提供了.
简单的命名空间 –文件通过一个给定的key来确定,是一个全局的命名空间
不用共享任何东西 — MogileFS分布式文件存储系统不需要依靠昂贵的SAN来共享磁盘,每个机器只用维护好自己的磁盘.
传输中立,无特殊协议 — MogileFS分布式文件存储系统客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信,但首先需要告知跟踪器一下
MogileFS+Nginx的负载均衡部署方案
FastDFS架构和原理
每个存储服务器都需要定时将自身的信息上报给tracker，这些信息就包括了本地同步时间（即，同步
到的最新文件的时间戳）。而tracker根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步
FastDFS的FID
精巧的FID：
FastDFS的特性
FastDFS和MogileFS相比，没有文件索引数据库，C语义开发，TCP Socket方式，整体性能更高
相对于MogileFS更为简单
FastDFS的日志记录非常详细，便于排除问题
安装配置相对简单
目前只有一个人维护，是潜在的风险
TFS原理和架构
TFS文件名的结构
TFS的特性
总体参考HDFS架构和原理，细节方面则考虑的是小文件(<1M)的优化访问
在TFS的设计里面对应着是一个block同时只能有一个写或者更新操作。
随着写压力的增加，读文件的TPS会大幅下滑。
TFS的淘宝部署案例
淘宝网图片存储与处理系统全局拓扑
图片服务器前端还有一级和二级缓存服务器，尽量让图片在缓存中命中，最大程度的避免图片热点，实际上后端到达TFS的流量已经非常离散和平均。
分布式系统之内存
内存计算
服务器内存究竟能多大、能多贵、能多快
预计未来5到10年，关系数据库将彻底消失，届时所有的SAP产品都将使用HANA——2011年
内存计算的模式将能帮助企业分析数据的速度提升10万倍（相比传统关系数据库）。这也就意味着以前需要数小时的分析现在几秒钟内就可以完成。”
Bussmann所在的团队在2010年10月份的时候，通过概念证明SAP数据分析速度有望提升14000倍，以前需要花费5小时分析处理完数据，现在仅需要1秒钟则可以迅速完成。
SAP HANA超级内存数据库
分布式内存整合计算的典型代表Pivotal GemFire
Gemfire+12306让中国人回家过年更方便？
部署数百个Pivotal Gemfire节点
在2015年春运购票高峰之前，考虑到超大并发会造成网络流量大以及阻塞的问题，今年特别在阿里云建立一个数据中心，由阿里云提供“虚拟机”
的租赁服务，将基于Gemfire实现余票查询功能的系统以及Web服务部署在这些虚拟机上，以分流“余票查询”请求Gemfire+12306让中国人回家过年更方便？部署数百个Pivotal Gemfire节点技术改造之后，在只采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力，单次
查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。 2012年春运的极端高流量并发情况下，系统几近瘫痪。而在改造之后，支持每秒上万次的并发查询，高峰期间达到2.6万个查询/秒吞吐量，整个系统效率显著提高。旧系统每秒只能支持300-400个查询/秒的吞吐量
内存计算为什么这么快
当前计算架构的瓶颈在存储，处理器的速度按照摩尔定律翻番增长，而磁盘存储的速度增长很缓慢，由此造成巨大高达10万倍的差距
IMDG
In Memory Data Grid（“内存数据网格”）
首先自然是网格式分布式存储
所有数据存于内存（RAM）
存储服务器数量可随时增减
数据模型是非关系模型， 而是基于对象模型
在网格内的某一台存储服务器的启动和关闭不会影响到网格内的其他服务器
IMDG产品
Hazelcast & GridGain
Hazelcast是什么
2008年开源项目，目标是一个简单的分布式Java Map
目前的定位是Java分布式内存网格
Hazelcast架构
Hazelcast企业版的最强特性之堆外缓存
默认512M OS的内存池，分为默认4M大小的管理单元，默认采用ThreadLocal方式管理内存单元。
存在用来存放Index、偏移量等Metadata信息的内存单元， MetaData的占用空间默认是12%
GridGain
作为另一款主流的开源数据网格产品，GridGain是Hazelcast的强有力竞争者。同样提供了社区版和商业版，近日GridGain的开源版本已经进入Apache孵化器项目Ignite(一款开源的内存计算(In-MemoryComputing)IMC中间件)，目前Apache正在迁移GridGain开源版本的代码到Ignite项目
GridGain在开源版本中就提供了堆外存储功能， 当堆和非堆内存都不足时，还可以开启SWAP，将数据溢出到磁盘
GridGain使用2PC(两阶段提交)协议实现分布式事务，事务级别支持三种事务隔离级别
GGFS(GridGain In-Memory File System)， 类似Spark生态圈中的Tachyon， 能够加速MapReduce任务的执行
流式数据/事件处理，可以作为CEP事件处理器
Apache Ignite项目凭借其业界领先的事务处理能力在新兴的混合型的OLTP/ OLAP用例方面更胜一筹。特别是针对Hadoop， Apache Ignite将为现有的Map/Reduce， Pig或Hive作业提供即插即用式的加速，避免了推倒重来的做法
Apache Ignite成为未来的快速数据世界（Fast Data world），如同Hadoop是今天的大数据。
GridGain是一个融合了各种实时/内存计算技术的平台
Memcached
Web系统中使用最为广泛的分布式Key/value缓存中间件
Memcached最佳实践
最适合存储小数据，并且存储的数据是大小一致的
Memcached在很多时候都是作为数据库前端cache使用
虚机上不适合部署Memcached
确保Memcached的内存不会被Swap出去
不能便利所有数据，这将导致严重性能问题
Local Cache+ Memcached这种分层Cache还是很有价值
Memcached启动预热是一个好办法
Redis
是Memcached的一个强有力的补充，同时也是一个有显著
不同的新产品
Redis扩展了key-Value的范围， Value可以是List， Set，Hashes， Sorted Set等数据结构，同时增加了新指令针对这些数据结构：如Set的union， List的pop等操作指令
比如Subscribe/publish命令，以支持发布/订阅模式这样的通知机制等等
Redis通过Multi / Watch /Exec等命令可以支持事务的概念，原子性的执行一批命令。
Redis 3.0开始实现Cluster方案，但没有采用一致性Hash
Redis事务问题
redis 数据集结构体 redisDB 和客户端结构体 redisClient
都会保存键值监视的相关数据
一个Redis集群包含16384个哈希槽(hash slot)，数据库中的每个键都属于这个16384个哈希槽的其中一个，集群使用公式CRC16(key) % 16384来计算键key属于哪个槽，其中CRC16(key)语句用于计算键key的CRC16校验和。
Redis vs Memcache
简单数据结构下Memcache的多线程架构有优势
仅仅从用做缓存的角度， Memcache还是无法被替代
Redis具备向数据库考虑的能力，但这些方面并没有特别强的优势
不要求关系数据库质量级别的交易时， Redis可以取代一些特定场合的数据库操作，比如秒杀这样的系统
分布式系统存储之基于内存的两表Join
A表为Person { id、 name }
B表为Order{id,orderId,amount（金额） }
关联关系为order.orderid=person.id
求计算结果 select p.id,sum(o.amount),count(*) from person p ,order o where
order.orderid=person.id order by sum limit 1000
Person、 Order的数据分别存在CSV文件中 ，数量各自是1亿、 10亿，数据随机制造，保证基本都有关联
采用Hazelcast或GridGain的API完成，需要找出这两个产品中最合适的API来完成Join、 Group、 Order等操作
分布式系统之分布式数据库篇
分布式数据库那点事
Oracle怎么实现分布式——Oracle Rac
1.多节点负载均衡;
2.通过并行执行技术提高事务响应时间—-通常用于数据分
析系统;
3.通过横向扩展提高每秒交易数和连接数 ;—-通常对于联
机事务系统;
4.节约硬件成本，可以用多个廉价PC服务器代替昂贵的小
型机或大型机，同时节约相应维护成本;
5.可扩展性好，可以方便添加删除节点，扩展硬件资源;
往往人们会认为RAC有2个节点性能就会提升2倍，这是一个误区，由于要保证数据的一致性往往性能会消耗在内存间的数据块相互拷贝和交叉上，因此不一定性能会好于单
节点，而且节点越多性能曲线就会下降越快
Oracle Rac的缓存融合技术（Cache fusion）
1.保证缓存的一致性
2.减少共享磁盘IO的消耗
3.在RAC环境中多个节点保留了同一份的DB CACHE
Oracle Rac双节点HA的原理和流程
在生产使用中，突然instance1 shutdown，那么在其上面没有完成的事物如何处理呢。
1）当实例1 crash后，实例2通过VIP就可以知道实例1已经down了。
2）此时需要处理的有2部分数据，一部分是commit的数据，一部分非commit数据
3）对于已经commit写入redo日志但是还没有来得及写入数据文件的记录，实例2可以访问实例1的redo log并从最后一次check point之后的信息开始实例恢复。把数据同步到最新状态。
4）对于没有commit的数据利用undo旧映像进行回滚事物。
MySQL Cluster
MySQL集群是一种在无共享架构（SNA， Share NothingArchitecture）系统里应用内存数据库集群的技术。这种无共享的架构可以使得系统使用低廉的硬件获取高的可扩
展性。 MySQL集群是一种分布式设计，目标是要达到没有任何单点故障点。因此，任何组成部分都应该拥有自己的内存和磁盘。
优点：
1) 99.999 ％的高可用性
2) 快速的自动失效切换
3) 灵活的分布式体系结构，没有单点故障
4) 高吞吐量和低延迟
5) 可扩展性强，支持在线扩容
VoltDB
VoltDB Streaming Data Pipeline
分布式数据库热点技术
数据分片与扩容
CAP理论
CA，没有扩展性，如MySQL、 Oracle等
CP ，不能忍受节点宕机，有Oracle RAC、 Sybase集群等
AP，牺牲数据一致性，多数NoSQL系统采用
ACID vs BASE
BASE, 最终一致性这个理论由 B asically A vailable, S oftstate, E ventual consistency 组成。核心的概念是Eventual consistency ——最终一致性。它局部的放弃了 CAP 理论中的“完全”一致性，提供了更好的可用性和分区容忍度。RYW ( Read-Your-Writes ) consistencyRYW consistency 是最终一致性的补充，它保证业务在会话中一定能读到上一次写入的数据
分布式事务——跨多个资源保证事务一致性
X/Open DTP模型
淘宝XA案例分析
事务补偿机制——避免XA的低性能
跨节点查询和Join
当两个表的数据分布在多个节点上时，这两个表之间的Join就是一个困难的事情
Mycat入门
分布式数据库中间件
基于阿里开源的Cobar
被用于众多互联网项目
中国最活跃的Mycat社区
Mycat原理
Mycat全局表
Mycat ER分片
