in355hz
- 浏览: 230048 次
-
最新评论
-
xugangqiang：
很好很强大，强烈推荐。
漫谈事务与分布式事务（4）- 最终一致性 -
mike79：
有个问题，是关于gtid到底是在什么时候生成的。从refman ...
MySQL 5.6 全局事务 ID（GTID）实现原理（二） -
supernavy：
翻译的非常好
Disruptor 2.0 - 所有的改变 -
in355hz：
检查一下 AttachThreadInput 的返回值? 另外 ...
利用 AttachThreadInput 改变其它进程的输入法状态 -
chengdu1113：
你好：
我正在开发一种npapi的插件，但是在输入框中 ...
利用 AttachThreadInput 改变其它进程的输入法状态
文章列表
在上一篇文章里忽略了一点。
CAP 定理有一个缺陷，这个缺陷可以帮助我们“部分”摆脱 分布式困境。
总的来说，CAP 定理本身是完备的，但它并没有描述一个分布式系统何时产生分区，以及分区会持续多长时间。理论其实只限制：在分区发生的 时间内，系统只能在一致性（C）和可用性（A）之间二选一。
因此，分布式系统完全可以在没有出现分区时保证 C 和 A，而在出现分区后，放弃一些 A 或者 C 然后通过人工操作消除分区，让系统恢复到分区前的状况。
这样说太复杂了。用 说人话 的方式就是：
上一篇介绍了 单机数据库 的 ACID 事务。下面将进入真正的难点：
“分布式环境”
分布式与单机最大的区别在于：单机是一个整体。组成这台机器的零件要么（看上去）都在正常状态，要么都不在状态，很少有例外。
...
回到事务这个话题。上一篇提到：
数据库事务 = ACID
ACID 并不是一个纸面理论。这个世界上有成千上万台满足 ACID 特性的数据库运行在大大小小的机构、政府部门和企业，为各式各样的复杂业务提供服务。其中有银行、电信、统计机构、实验室，以及你正在访问的网站。如果全球的数据库同时崩溃，那也许是一场世界末日，嘭！
让我先烧个香膜拜一下，然后很肤浅的看一下数据库实现 ACID 的方法。
数据库 ACID 的实现
基本上，数据库实现 ACID 最关键的技术是日志和锁。
最近看了一点资料，准备写一个大话题。
事务，是所有数据库讲义中最核心的话题。它本质上是一系列连续的，逻辑相关的数据库操作的组合。随便翻开一本书，都会告诉你，事务必须满足下面四个属性：
ACID（Atomic，Consistency，Isolation，Durability）
按照属性即实体的观点：数据库事务就是 ACID，符合 ACID 的就是数据库事务。因此我们可以得出一个公式：
数据库事务 = ACID
抛开课本上那些苦涩难懂的定义，如何理解 ACID ？
首先，我们不用去读 Jim Gray 的《Transaction Proces ...
Java 的 SoftReference 有很多年都没有被人惦记了。在 Javadoc 里, 它的描述是这样：
”虚拟机在抛出 OutOfMemoryError 之前会保证所有的软引用对象已被清除。此外，没有任何约束保证软引用将在某个特定的时间点被清除，或者确定一组不同的软引用对象被清除的顺序。不过，虚拟机的具体实现会倾向于不清除最近创建或最近使用过的软引用。“
这个类可以直接被用来实现简单的缓存，这个类或派生的子类也可用于较大的数据结构，来实现更加复杂的缓存。只要软引用可以到达该对象，就是说，该对象实际上是在使用，软引用就不会被清除。这样能够实现一个复杂的缓存，例如，使用强 ...
最近业务中需要用 Python 写一些脚本。尽管脚本的交互只是命令行 + 日志输出，但是为了让界面友好些，我还是决定用中文输出日志信息。
很快，我就遇到了异常：
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0- ...
这是 Trisha Gee 发表的 Disruptor 全解析系列博客的后续补充，原文链接是：http://mechanitis.blogspot.com/2011/08/disruptor-20-all-change-please.html
Martin 最近公布了 Disruptor 的 2.0 版本 —— 基本上，2.0 版自我们第一次开源以来有了如此多的改变，是需要把这些改变正式标记出来的时候了。Martin 的文章包含了所有的变化点，而我这一篇文章的目标是试图将之前的博客翻译成“新世界的语言”，因为把每篇博客都重写一遍得花很长时间。现在我知道用手工绘图表示一切的缺点了 ...
原文地址：http://mechanitis.blogspot.com/2011/08/dissecting-disruptor-why-its-so-fast.html， 作者是 Trisha Gee, LMAX 公司的一位女工程师。
我最近写文章的速度变慢了，是因为我一直在尝试写一篇博客解释内存屏障（Memory Barrier）以及它在 Disruptor 的应用。问题是，无论我阅读了多少次，无论我向永远耐心的 Martin 和 Mike 提出多少个问题试图弄明白一些重点，我还是没办法直观的把握主题。我猜我没有完全理解它所需要的深厚背景知识。
这是 MySQL 5.6 全局事务 ID（GTID） 系列的第三篇博客。
在之前的两篇博客中，第一篇 介绍了全局事务 ID 的定义与数据结构。第二篇 介绍了 MySQL 5.6 新增的全局事务状态（Gtid_state）。
这里准备介绍的是全局事务 ID 如何参与 MySQL 的主备复制流程。
MySQL 5.6 引入全局事务 ID 的首要目的，是保证 Slave 在复制的时候不会重复执行相同的事务操作；其次，是用全局事务 IDs 代替由文件名和物理偏移量组成的复制位点，定位 Slave 需要复制的 binlog 内容。
因此，MySQL 必须在写 bin ...
前文 MySQL 5.6 全局事务 ID（GTID）实现原理（一） 介绍了 MySQL 5.6 全局事务 ID 的定义和相关的数据结构 Gtid_set 与 Sid_map。接下来，这一篇的主要目标是深入了解文章最后提到的全局事务状态 Gtid_state。并且，如果可能 —— 顺便介绍下这些 Gtid_state 在主备复制中的功能：
全局事务状态 Gtid_state
Gtid_state 是 MySQL 5.6 内的一个全局对象，它的数据结构如下：
(mysql-5.6.9-rc\sql\rpl_gtid.h，line 2043)
Gtid_sta ...
MySQL 5.6 的新特性之一，是加入了全局事务 ID (GTID) 来强化数据库的主备一致性，故障恢复，以及容错能力。但是，有关 GTID 的作用和原理，在 MySQL 官方网站 的文档库中却很少被提到。
随着 MySQL 5.6 的 rc 版本号原来越高（这意味着 MySQL 5.6 向正式发布越来越近），想要全面了解这个神秘功能的需求也越来越急迫。因此，在这篇博客里，我打算从有限的文档出发，通过分析 MySQL 源码，逐步了解 MySQL GTID 和它在主备复制中的作用。
什么是 GTID?
有关全局事务 ID（GTID），容易找到的是这一篇文档：
...
原文地址：http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-why-its-so-fast_22.html， 作者是 Trisha Gee, LMAX 公司的一位女工程师。
我们多次提到了 Mechanical Sympathy (机器协同？) 这个短语，事实上它甚至是Martin 的博客 标题。它的含义与理解底层计算机硬件的操作原理，然后编程让软件用协同的方式，而不是以违背的方式在硬件上工作有关。
关于
原文地址: http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-why-its-so-fast.html，作者是 Trisha Gee, LMAX 公司的一位女工程师。
Martin Fowler 写了一篇非常不错的 文章，不仅描述了 Disruptor，还展示了它是如何适配到 LMAX 架构 ...
原文地址：http://mechanitis.blogspot.com/2011/07/dissecting-disruptor-wiring-up.html 作者是 Trisha Gee, LMAX 公司的一位女工程师。
现在我已经讲了 RingBuffer 本身，如何从它 读取 以及如何向它 写入。
从逻辑上来说，下一件要做的事情就是把所有的知识拼接到在一起。
原文地址：http://mechanitis.blogspot.com/2011/06/dissecting-disruptor-how-do-i-read-from.html 作者是 Trisha Gee, LMAX 公司的一位女工程师。
这是理解 LMAX 开发的 Disruptor 模式 系列博客的下一篇。
从