sparkliang的专栏

<br />翻译A Digital Signature Based on a Conventional Encryption Function，在本文中，Merkle提出了著名的Merkle hash树，它在其它方面也有不少应用，值得一读。基于常规加密函数的数字签名<br />By Ralph C.Merkle<br />Elxsi<br />2334 Lundy Place<br />San Jose, CA 95131摘要<br />本文描述了一种新的基于常规加密函数（比如DES）的数字签名

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

有时间再仔细讲讲。

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

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

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

<br />Paxos一致性算法——分布式系统中的经典算法，论文本身也有一段有趣的故事。一致性问题是分布式系统的根本问题之一，在论文中，作者一步步的加强最初一致性问题（2.1节提出的问题）的约束条件，最终导出了一个可实现的一致性模型。当前Paxos算法的研究越来越多，相关实现也不少，而原论文依然是最不可少的资料。论文通篇没有一个数学公式，这是大牛的坚持！<br />【】中的是我个人的注释。<br />先解释文中几个关键词的翻译：<br />Proposal译为“议案”，由proposer提出，被

Chord：一个用于网络应用的可扩展的P2P查询服务<br />Ion Stoica*, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan <br />MIT Laboratory for Computer Science chord@lcs.mit.edu<br />http://pdos.lcs.mit.edu/chord/摘要<br />P2P（peer-to-peer）系统面临的一个根本问题就是如何有效的定位到

5 并发操作和失效<br />在实际应用中Chord需要处理节点同时加入系统，以及节点实效或者自行离开的情况。本节描述了对第四节基本Chord算法的修改，以处理这些情况。5.1 稳定性<br />第四节描述的加入算法在网络进化时主动积极的维护所有节点的finger table。因为在大规模网络中，面对节点的并发加入的情况，这些不变性是很难维护的，我们要区分对待正确性和性能的目标。一个基本的“稳定化”（stabilization）协议，可以保持节点的后继指针始终是最新的，这对于保证查询的正确性是足够的。这些后

<br /> <br />这两天回过头来再翻了翻这几篇Google的经典论文，发现网上有个不错的翻译版本，并且很完整，贴出来分享一下：<br />http://blademaster.ixiezi.com/category/google%E8%AE%BA%E6%96%87/<br /> <br />还有一个云计算的blog：http://peopleyun.com/<br />也值得一看。<br /> 

<br />有关使用memcache做分布式缓存的方案，简单写下来，仅供参考。<br /> <br />memcache是优异的缓存解决方案，很多项目都有使用。<br />memcache服务本身并不具备分布式缓存的能力，它提供的就是对{key, value}对的访问能力，分布式的能力则完全来自于客户端。基于consistent hashing算法的分布式缓存<br />现在有不少memcache的客户端lib采用consistent hashing作为分布式算法，采用consistent hashin

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

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

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

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

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

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

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

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

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

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

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

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