我们知道，MySQL里可以动态修改事务隔离级别，既可以加 GLOBAL 关键字直接修改全局的设置，也可以加 SESSION 关键字只修改当前会话的设置。那么，如果两个关键字都不加，会出现什么情况呢？

    当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题： 1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。 2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。 于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。

    MULTI，EXEC，DISCARD，WATCH 四个命令是 redis 事务的四个基础命令。其中：MULTI，告诉 redis 服务器开启一个事务。注意，只是开启，而不是执行；EXEC，告诉 redis 开始执行事务；DISCARD，告诉 redis 取消事务；WATCH，监视某一个键值对，它的作用是在事务执行之前如果监视的键值被修改，事务会被取消。在介绍 redis 事务之前，先来展开 redis 命令队列的内部实现。

     sqlite是一个非常优秀的嵌入式数据库，读取性能非常好，写入性能就比较差一些，为什么写入性能差呢？下面做了一个测试。 下面是对500+条记录些操作的系统调用的观察，发现时间基本花费在了fdatasync系统调用上，调用2064次；write系统调用虽然8049次，但是write并不保证逻辑，所以速度很快。

     Storm是一个分布式的流处理系统，利用anchor和ack机制保证所有tuple都被成功处理。如果tuple出错，则可以被重传，但是如何保证出错的tuple只被处理一次呢？Storm提供了一套事务性组件Transaction Topology，用来解决这个问题。 Transactional Topology目前已经不再维护，由Trident来实现事务性topology，但是原理相同。

     MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：ameoba[4]，网易的DDB，淘宝的TDDL，B2B的Cobar等等。

     MySQL XA分为两类，内部XA与外部XA；内部XA用于同一实例下跨多个引擎的事务，由大家熟悉的Binlog作为协调者；外部XA用于跨多MySQL实例的分布式事务，需要应用层介入作为协调者(崩溃时的悬挂事务，全局提交还是回滚，需要由应用层决定，对应用层的实现要求较高).

    最近CSDN头条有一篇介绍Google Megastore的文章，讲得挺好，本文主要针对Google Megastore的事务实现做一个更详细的探讨。Google Megastore的底层是GFS + Bigtable系统，GFS + Bigtable解决可扩展性问题，但提供的用户接口简单：读接口只提供Get随机读取和Scan连续扫描，写接口也只能够支持单行事务。Google Megastore构建在Bigtable系统之上，通过客户端封装复杂的特性，包括事务支持，基于Entity Group的数据模型，多机房同步等...

    这两年来，随着NoSQL系统、CAP理论和Eventual Consistency的大热，关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝。双方各执一词，倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要，倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受。弱一致性能否满足应用开发的需求这一点由应用特征决定，难以一概而论，但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的。奇怪的...