sparkliang-CSDN博客

翻译 Acquire and Release Semantics

SEP 13, 2012http://preshing.com/20120913/acquire-and-release-semantics/通常说来，在lock-free编程中，线程之间有两种方式可以操作共享内存：它们可以竞争同一个资源，或者相互协作的从一个向另一个传递信息。Acquire and Release语义对后者是至关重要的：在线程之间可靠的传输信息。事实上，我冒昧

2016-11-21 15:34:56 7060

翻译 The Happens-Before Relation

JUL 02, 2013http://preshing.com/20130702/the-happens-before-relation/Happens-before是一个现代计算机科学术语，对于描述C++11，Java，Go甚至LLVM之后的software memory model是有帮助的。你可以在上面的每一种语言规范中找到happens-before关系的定义。这些

2016-11-21 15:33:45 3812

翻译 This Is Why They Call It a Weakly-Ordered CPU

OCT 19, 2012http://preshing.com/20121019/this-is-why-they-call-it-a-weakly-ordered-cpu/注：对于理解weak cpu下的reordering而言，这真是一篇相当好的文章。拿起你的xcode和4s，可以直接测试运行作者的例子。没什么比鲜活的例子更令人印象深刻。还有就是，除了在iphone 3GS

2016-11-14 15:31:06 3682

翻译 Weak vs. Strong Memory Models

SEP 30, 2012http://preshing.com/20120930/weak-vs-strong-memory-models/

2016-11-14 15:29:35 6165

翻译 Memory Barriers Are Like Source Control Operations

前言：第三篇，老外想象力挺丰富，和代码版本控制联系起来，确实可以帮助人比较直观的理解Memory Barrier。 JUL 10, 2012 http://preshing.com/20120710/memory-barriers-are-like-source-control-operations/正文开始——> 如果你使用过版本控制工具，你就向着理解memory ordering又

2016-11-14 15:28:23 4009 1

翻译 Memory Ordering at Compile Time

JUN 25, 2012 原文在这：http://preshing.com/20120625/memory-ordering-at-compile-time/ 前言：这是译自preshing博客的第二篇文章，本文讨论的是编译优化导致的重排序问题。从你写C/C++源代码到它在CPU里执行，这段代码的内存交互可能会根据特定的规则被重新排序了。编译器（编译期）和processor（运行期）都有可能导致

2016-10-19 20:25:20 3721

翻译 Memory Ordering in Intel Family

前言：这篇文章是翻译自的Intel x86/64的规范文档，其中第8.2节中有关Memory Ordering的几段。整个文档是一本巨书，这里可以download：http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-pr

2016-10-19 16:42:30 4024

翻译 Memory Reordering Caught in Act

前言：首先是翻译的几篇文章，作者是一个老外，虽然文章是几年前的，但是很值得一读。最近不知道写些什么东西，拿这个先凑几篇其次有关什么memory ordering，memory reordering，memory model这些名词，可能很多时候直接e文，没有翻译，个人习惯。Memory Reording Caught in Act原文在这里：http://preshing.com/20120

2016-10-19 15:13:17 3733

原创初见Raft

这几天研究了一下Raft协议，继Paxos之后出来的第二个可以理论证明自己正确性的分布式一致性协议（可以这么说吧，没仔细了解过其它协议）。其实看过paxos，初看Raft，感觉还是有很多熟悉的面孔，仔细看作者的描述，确实两者也有不少差别。我觉得basic paxos好像也没有Ongaro说的那么难以理解吧，不过有一点是肯定的，paxos给出了理论，但是距离一个基本可用的工程实践确实还有很远

2015-01-07 15:20:09 6323 2

原创个人数据搜索

有时间再仔细讲讲。

2014-10-24 14:11:48 6017

转载从MySQL Bug#67718浅谈B+树索引的分裂优化

原文链接：http://hedengcheng.com/?p=525

2014-06-11 10:41:00 10078 7

原创 Leveldb源码分析--22

14 DB的查询与遍历之214.4 DBIterLeveldb数据库的MemTable和sstable文件的存储格式都是(user key, seq, type) => uservalue。DBIter把同一个userkey在DB中的多条记录合并为一条，综合考虑了userkey的序号、删除标记、和写覆盖等等因素。从前面函数NewIterator的代码还能看到，DBIter内部使用了MergingI

2013-11-26 18:01:53 12480 7

原创 Leveldb源码分析--21

最近工作上事情太多，更新的也比较慢了。14 DB的查询与遍历分析完如何打开和关闭db，本章就继续分析如何从db中根据key查询value，以及遍历整个db。14.1 Get()函数声明：StatusGet(const ReadOptions& options, const Slice& key, std::string* value)从DB中查询key 对应的value，参数@options指定读

2013-09-05 13:22:58 11050 7

原创 Leveldb源码分析--20

12 DB的打开先分析LevelDB是如何打开db的，万物始于创建。在打开流程中有几个辅助函数：DBImpl()，DBImpl::Recover, DBImpl::DeleteObsoleteFiles, DBImpl::RecoverLogFile, DBImpl::MaybeScheduleCompaction。12.1 DB::Open()打开一个db，进行PUT、GET操作，就是前面的静态

2013-07-12 15:03:32 11542 2

原创 Leveldb源码分析--19

11 VersionSet分析之211.4 LogAndApply()函数声明：Status LogAndApply(VersionEdit*edit, port::Mutex* mu)前面接口小节中讲过其功能：在currentversion上应用指定的VersionEdit，生成新的MANIFEST信息，保存到磁盘上，并用作current version，故为Log And Apply。参数ed

2013-06-03 11:11:09 9253

原创 Leveldb源码分析--18

11 VersionSet分析之1Version之后就是VersionSet，它并不是Version的简单集合，还肩负了不少的处理逻辑。这里的分析不涉及到compaction相关的部分，这部分会单独分析。包括log等各种编号计数器，compaction点的管理等等。11.1 VersionSet接口1 首先是构造函数，VersionSet会使用到TableCache，这个是调用者传入的。Table

2013-06-03 10:52:20 9555

原创 Leveldb源码分析--17

10 Version分析之210.5 Version::UpdateStats()当Get操作直接搜寻memtable没有命中时，就需要调用Version::Get()函数从磁盘load数据文件并查找。如果此次Get不止seek了一个文件，就记录第一个文件到stat并返回。其后leveldb就会调用UpdateStats(stat)。Stat表明在指定key range查找key时，都要先seek

2013-05-11 20:27:41 10068 8

原创 Leveldb源码分析--16

10 Version分析之1先来分析leveldb对单版本的sstable文件管理，主要集中在Version类中。前面的10.4节已经说明了Version类的功能和成员，这里分析其函数接口和代码实现。Version不会修改其管理的sstable文件，只有读取操作。10.1 Version接口先来看看Version类的接口函数，接下来再一一分析。 // 追加一系列iterator到 @*ite

2013-04-19 13:46:21 10145

原创 Leveldb源码分析--15

9 LevelDB框架之29.4 版本控制当执行一次compaction后，Leveldb将在当前版本基础上创建一个新版本，当前版本就变成了历史版本。还有，如果你创建了一个Iterator，那么该Iterator所依附的版本将不会被leveldb删除。在leveldb中，Version就代表了一个版本，它包括当前磁盘及内存中的所有文件信息。在所有的version中，只有一个是CURRENT。Ver

2013-04-15 09:29:38 14569

原创 Leveldb源码分析--14

9 LevelDB框架之1到此为止，基本上Leveldb的主要功能组件都已经分析完了，下面就是把它们组合在一起，形成一个高性能的k/v存储系统。这就是leveldb::DB类。这里先看一下LevelDB的导出接口和涉及的类，后面将依次以接口分析的方式展开。而实际上leveldb::DB只是一个接口类，真正的实现和框架类是DBImpl这个类，正是它集合了上面的各种组件。此外，还有Leveldb对版本

2013-04-10 17:55:44 12254

原创 Leveldb源码分析--13

8 FilterPolicy&Bloom之28.5 构建FilterBlock8.5.1 FilterBlockBuilder了解了filter机制，现在来看看filter block的构建，这就是类FilterBlockBuilder。它为指定的table构建所有的filter，结果是一个string字符串，并作为一个block存放在table中。它有三个函数接口： // 开始构建新的filt

2013-04-05 14:12:18 8311 1

原创 Leveldb源码分析--12

8 FilterPolicy&Bloom之18.1 FilterPolicy因名知意，FilterPolicy是用于key过滤的，可以快速的排除不存在的key。前面介绍Table的时候，在Table::InternalGet函数中有过一面之缘。FilterPolicy有3个接口：virtual const char* Name() const = 0; // 返回filter的名字virtual

2013-04-01 12:53:18 9605 2

原创 Leveldb源码分析--11

7 TableCache这章的内容比较简单，篇幅也不长。7.1 TableCache简介TableCache缓存的是Table对象，每个DB一个，它内部使用一个LRUCache缓存所有的table对象，实际上其内容是文件编号{file number, TableAndFile*}。TableAndFile是一个拥有2个变量的结构体：RandomAccessFile*和Table*；TableCac

2013-03-30 18:50:33 8171

原创 Leveldb源码分析--10

6 SSTable之46.6 遍历Table6.6.1 遍历接口Table导出了一个返回Iterator的接口，通过Iterator对象，调用者就可以遍历Table的内容，它简单的返回了一个TwoLevelIterator对象。见函数实现：Iterator* NewIterator(const ReadOptions&options) const;{ return NewTwoLevel

2013-03-23 09:28:33 8534

原创 Leveldb源码分析--9

6 SSTable之36.5 读取sstable文件6.5.1 类层次Sstable文件的读取逻辑在类Table中，其中涉及到的类还是比较多的，如图6.5-1所示。图6.5-1Table类导出的函数只有3个，先从这三个导出函数开始分析。其中涉及到的类（包括上图中为画出的）都会一一遇到，然后再一一拆解。本节分析sstable的打开逻辑，后面

2013-03-16 18:21:44 9132

原创 Leveldb源码分析--8

6 SSTable之26.4 创建sstable文件了解了sstable文件的存储格式，以及Data Block的组织，下面就可以分析如何创建sstable文件了。相关代码在table_builder.h/.cc以及block_builder.h/.cc（构建Block）中。6.4.1 TableBuilder类构建sstable文件的类是TableBuil

2013-03-09 11:48:36 10047 2

原创 Leveldb源码分析--7

6 SSTable之1SSTable是Leveldb的核心之一，是表数据最终在磁盘上的物理存储。也是体量比较大的模块。6.1 SSTable的文件组织作者在文档doc/table_format.txt中描述了表的逻辑结构，如图6.1-1所示。逻辑上可分为两大块，数据存储区Data Block，以及各种Meta信息。1）文件中的k/v对是有序存储的，并且被划分到连续排列的

2013-03-06 22:14:52 14617 4

原创 Leveldb源码分析--6

5 操作Log 2 5.3 读日志日志读取显然比写入要复杂，要检查checksum，检查是否有损坏等等，处理各种错误。5.3.1 类层次先来看看读取涉及到的类图，如图5.3-1。Reader主要用到了两个接口，一个是汇报错误的Reporter，另一个是log文件读取类SequentialFile。> Reporter的接口只有一个：void Co

2013-03-01 22:38:22 10970 2

原创 Leveldb源码分析--5

5 操作Log 1分析完KV在内存中的存储，接下来就是操作日志。所有的写操作都必须先成功的append到操作日志中，然后再更新内存memtable。这样做有两个有点：1可以将随机的写IO变成append，极大的提高写磁盘速度；2防止在节点down机导致内存数据丢失，造成数据丢失，这对系统来说是个灾难。在各种高效的存储系统中，这已经是口水技术了。5.1 格式在源码下的

2013-02-28 20:56:04 11609 3

原创 Leveldb源码分析--4

4 Memtable之24.6 Comparator弄清楚了key，接下来就要看看key的使用了，先从Comparator开始分析。首先Comparator是一个抽象类，导出了几个接口。其中Name()和Compare()接口都很明了，另外的两个Find xxx接口都有什么功能呢，直接看程序注释： // Advanced functions: these are used to reduce t

2013-02-23 00:24:12 13990 7

原创 Leveldb源码分析--3

4 Memtable之1Memtable是leveldb很重要的一块，leveldb的核心之一。我们肯定关注KV数据在Memtable中是如何组织的，秘密在Skip list中。4.1 用途在Leveldb中，所有内存中的KV数据都存储在Memtable中，物理disk则存储在SSTable中。在系统运行过程中，如果Memtable中的数据占用内存到达指定值(Optio

2013-02-23 00:06:07 19901 10

原创 Leveldb源码分析--2

3 Int Coding轻松一刻，前面约定中讲过Leveldb使用了很多VarInt型编码，典型的如后面将涉及到的各种key。其中的编码、解码函数分为VarInt和FixedInt两种。int32和int64操作都是类似的。3.1 Decode首先是FixedInt编码，直接上代码，很简单明了。void EncodeFixed32(char* buf, uint32_t

2013-02-06 11:32:46 17521 2

原创 Leveldb源码分析--1

【前言：看了一点oceanbase，没有意志力继续坚持下去了，暂时就此中断，基本上算把master看完了，比较重要的update server和merge server代码却没有细看。中间又陆续研究了hadoop的源码，主要是name node和写入pipeline。主要的目的是想看看name node对namespace的管理，以及hadoop在写入操作时，client、data nod

2013-02-05 22:58:28 58862 15

原创 oceanbase之RootServer（三）

琐事太多，又太懒了，好久不想动笔，进展也比较慢。5 日志系统有伟大的GFS作指引，OceanBase的master也是采用redo log加checkpoint机制，以保证master的响应速度。此外root server采取了主备机制，因此redo log一写两份，在flush redolog时先写slave，成功了才写master并重置log的内存缓存区。日志系统

2012-11-26 11:39:14 4026

原创 oceanbase之RootServer（二）

4 类ObRootWorker这是个大家伙，它继承自前面讲过的ObBaseServer这个简单框架类。自此已经很接近底层了。4.1 成员变量ObRootWorker本身引用了很多类，有关于log系统的，有关于Packet的，有关于client manage的，还有关于rpc的，等等；ObRootWorker正是集合了这些资源，完成了Root Server的功能。其成员变量如

2012-10-28 12:10:45 2214

原创 oceanbase之RootServer（一）

1 概述我们从Root Server开始分析。Root Server主要是提供命名服务，管理数据库系统的meta信息，管理ChunkServer，Root Server对集群的管理主要基于lease租约机制。Root Server使用HA主备机制来提高可用性。由HA检测master/slave节点的状态，如果master节点不可用，则虚拟IP会自动漂移到slave节点，slave节点接着提

2012-10-19 16:18:53 4431

原创看看oceanbase-序

oceanbase是淘宝开源的相当优秀的高性能分布式数据库项目，很值得一看。它采取了集中式的事务处理模型，因此对事务的支持非常好。准备仔细看看代码，顺便写些分析文章，由于写出来的是看代码的过程，因此不像一口气看完，心有大纲那样比较有逻辑性，可能很多地方还会相当罗嗦。但是基于偶对分布式系统的理解功底，逻辑性应该不会太差。了解oceanbase可以到它的主页http://oceanbase

2012-10-16 11:41:59 2219

转载 moosefs分布式文件系统实施配置方案

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。http://zyw1209.blog.51cto.com/1266169/580272 基于linux下分布式文件系统方案前言：现在有大量的企业采用共享存储服务器NFS的方式，来对应用数据进行网络存储，但这存在性能瓶颈和单点故障的问题，于是分布式文件存储管理系

2012-05-23 16:48:40 4725 1

原创规模是个大问题

一旦系统达到了一定的规模，很多看起来本该不是问题的问题也会一个一个接连跳出来。而更麻烦的是这些问题在刚开始可能根本就没有被考虑过。特别是分布式集群系统。前面提到过系统透明度的问题，这是其中一个，另一个密切相关的就是系统日志的存储与查询问题。小规模集群的情况下，使用一个单主机可能就够了。大规模用户的情况下，系统产生的日志可能会把系统淹没掉。仅仅是那些必须记录的重要性日志，其产

2012-02-15 10:26:23 2784 2

原创告别平台云的时代，迎来私有云

云这个东西，忽悠了不少人。估计不少追捧者忽悠大众的同时也把给忽悠进去了。妄图搞一个私有云，让大家把东西都放到自己的平台上。放在你这个外人的平台上，机密数据会不会泄漏，安全怎么保证？你自己能保证不搞我的数据？未来，存储硬件越来越便宜、容量越来越大，速度越来越快。未来，存储系统越来越可靠，维护成本越来越低。未来，将迎来私有云的时代。大一统的存储平台，基本是做

2011-12-30 09:57:16 2334 1