redis-faina 是通过Redis的MONITOR命令来实现的，通过对在Redis上执行的query进行监控，统计出一段时间的query特性。

下面就是其使用方法简介：

# 可以通过管道从stdin读取N条命令
redis-cli -p 6490 MONITOR | head -n <NUMBER OF LINES TO ANALYZE> | ./redis-faina.py

# 也可以从一个文件中读取N条命令
redis-cli -p 6490 MONITOR | head -n <...> > /tmp/outfile.txt
./redis-faina.py /tmp/outfile.txt

其输出结果如下：

Overall Stats
========================================
Lines Processed     117773
Commands/Sec        11483.44

Top Prefixes（按key前缀统计）
========================================
friendlist          69945
followedbycounter   25419
followingcounter    10139
recentcomments      3276
queued              7

Top Keys（操作最频繁的key）
========================================
friendlist:zzz:1:2     534
followingcount:zzz     227
friendlist:zxz:1:2     167
friendlist:xzz:1:2     165
friendlist:yzz:1:2     160
friendlist:gzz:1:2     160
friendlist:zdz:1:2     160
friendlist:zpz:1:2     156

Top Commands（执行最多的命令）
========================================
SISMEMBER   59545
HGET        27681
HINCRBY     9413
SMEMBERS    9254
MULTI       3520
EXEC        3520
LPUSH       1620
EXPIRE      1598

Command Time (microsecs)（命令执行时长）
========================================
Median      78.25
75%         105.0
90%         187.25
99%         411.0

Heaviest Commands (microsecs)（耗时最多的命令）
========================================
SISMEMBER   5331651.0
HGET        2618868.0
HINCRBY     961192.5
SMEMBERS    856817.5
MULTI       311339.5
SADD        54900.75
SREM        40771.25
EXEC        28678.5

Slowest Calls（最慢的命令）
========================================
3490.75     "SMEMBERS" "friendlist:zzz:1:2"
2362.0      "SMEMBERS" "friendlist:xzz:1:3"
2061.0      "SMEMBERS" "friendlist:zpz:1:2"
1961.0      "SMEMBERS" "friendlist:yzz:1:2"
1947.5      "SMEMBERS" "friendlist:zpz:1:2"
1459.0      "SISMEMBER" "friendlist:hzz:1:2" "zzz"
1416.25     "SMEMBERS" "friendlist:zhz:1:2"
1389.75     "SISMEMBER" "friendlist:zzx:1:2" "zzz"

从上面结果我们可以看到对Redis的操作规律，比如针对哪些key在进行操作，进行了什么操作，这些操作的效率如何等相关有用信息。

由于Redis的MONITOR 也对性能有所影响，所以建议在使用时不要一直开启MONITOR来分析。可以采用定时抽样一段时间来做样本分析。

来源：instagram-engineering.tumblr.com

相关文章：

Redis Logo 你喜欢哪一个？

PyCon2011 PPT分享：Redis与Python

REDIS TO GO：一个Redis存储服务

Bump的Redis应用经验

Redis.io-Redis的新家

无觅

Variety就是一个js脚本，直接使用mongo客户端执行。

下面是官方例子：

用下面语句插入四条结构不同一数据：

db.users.insert({name: "Tom", bio: "A nice guy.", pets: ["monkey", "fish"], someWeirdLegacyKey: "I like Ike!"});
db.users.insert({name: "Dick", bio: "I swordfight."});
db.users.insert({name: "Harry", pets: "egret"});
db.users.insert({name: "Geneviève", bio: "Ça va?"});

然后用mongo官户端对users这个collection中的内容进行分析：

$ mongo test --eval "var collection = 'users'" variety.js

{ "_id" : { "key" : "_id" }, "value" : { "types" : [ "object" ] }, "totalOccurrences" : 4, "percentContaining" : 100 }
{ "_id" : { "key" : "name" }, "value" : { "types" : [ "string" ] }, "totalOccurrences" : 4, "percentContaining" : 100 }
{ "_id" : { "key" : "bio" }, "value" : { "types" : [ "string" ] }, "totalOccurrences" : 3, "percentContaining" : 75 }
{ "_id" : { "key" : "pets" }, "value" : { "types" : [ "string", "array" ] }, "totalOccurrences" : 2, "percentContaining" : 50 }
{ "_id" : { "key" : "someWeirdLegacyKey" }, "value" : { "type" : "string" }, "totalOccurrences" : 1, "percentContaining" : 25 }

上面命令就是在test加的users这个collection上进行数据结构分析。

从上面结果我们能够看出，Variety将所有在users中出现过的字段都进行了统计，包括其类型和数量，以及出现在记录中的频率。这对于我们了解一个collection中的数据是很有用的。比如我们可以很容易看到是否在应该是数字的字段上还出现了一些string类型的值。如果是的话，可能要检查一下代码中是否有类型问题。

需要注意的是，Variety在对数据结构进行分析的时候，实际是用MapReduce来做的，会进行全表扫描操作，所以如果是对线上库进行分析，那么建议最好使用一个不提供服务的备份库或者在业务低峰来做。避免给线上业务造成压力。

获取更多Variety的信息，请移步其开源主页：github.com

相关文章：

MongoDB构架图分享

三招解决MongoDB的磁盘IO问题

MongoDB paddingFactor的含义

mongodb GridFS 介绍

五步优化你的MongoDB

无觅

目前NoSQLFan已经迁移到42区VPS的北京机房，访问速度也上了一个台阶。

感谢42区对NoSQLFan的支持。

猛击：http://vps.42qu.com/

相关文章：

bbs.nosqlfan.com 开通！欢迎举手发言！

NoSQLFan开放书籍频道

Redis系统性介绍 - NoSQLFan - 关注NoSQL相关技术、新闻

欢迎颜开同学入驻NoSQLfan

10GT：NoSQLFan实验室的作品

无觅

• Elections（选举）
• Creating a set（创建一个replica sets）
• Reconfiguring（重新配置）
• Syncing（同步）
• Initial Sync（初始化同步）
• Rollback（数据回滚）
• Authentication（权限控制）
• Debugging（故障排除）

本文主要对Replica Sets节点间的同步机制和同步协议进行了深入讲解。

同步过程

一个健康的secondary在运行时，会选择一个离自己最近的，数据比自己新的节点进行数据同步。选定节点后，它会从这个节点拉取oplog同步日志，具体流程是这样的：

1. 执行这个op日志
2. 将这个op日志写入到自己的oplog中(local.oplog.rs)
3. 再请求下一个op日志

如果同步操作在第1步和第2步之间出现问题宕机，那么secondary再重新恢复后，会检查自己这边最新的oplog，由于第2步还没有执行，所以自己这边还没有这条写操作的日志。这时候他会再把刚才执行过的那个操作执行一次。那对同一个写操作执行两次会不会有问题呢？MongoDB在设计oplog时就考虑到了这一点，所以所有的oplog都是可以重复执行的，比如你执行 {$inc:{counter:1}} 对counter字段加1，counter字段在加1 后值为2，那么在oplog里并不会记录 {$inc:{counter:1}} 这个操作，而是记录 {$set:{counter:2}}这个操作。所以无论多少次执行同一个写操作，都不会出现问题。

w参数

当我们在MongoDB时执行一个写操作时，默认会直接返回成功，同时也可以通过设置w参数，指定这个写操作同步到几个节点后才返回成功。如下：

db.foo.runCommand({getLastError:1, w:2})

上面例子就是执行getLastError命令，使其在上一个写操作同步到两个节点上后再返回。不同的客户端可能在写法上不太一样，不过这个功能应该都是有的。对于重要数据，可以考虑采用这样的方式，通过牺牲一部分写性能来提升数据的安全性。

这个功能是如何实现的呢，primary节点是如何知道数据同步了几份呢？

在调用上面命令时，实际上MongoDB内部执行了如下的一些流程：

1. 在primary上完成写操作
2. 在primary上记录一条oplog日志，日志中包含一个ts字段，值为写操作执行的时间，比如本例中记为t
3. 客户端调用{getLastError:1, w:2}命令等待primary返回结果
4. secondary从primary拉取oplog，获取到刚才那一次写操作的日志
5. secondary按获取到的日志执行相应的写操作
6. 执行完成后，secondary再获取新的日志，其向primary上拉取oplog的条件为{ts:{$gt:t}}
7. primary此时收到secondary的请求，了解到secondary在请求时间大于t的写操作日志，所以他知道操作在t之前的日志都已经成功执行了
8. 这时候getLastError命令检测到primary与secondary都完成了这次写操作，于是 w:2 的条件满足了，返回给客户端成功

启动初始化

当一个新节点启动并加入到现在的Replica Sets中时，这时候新启动的节点会查看自己的oplog，通过一个叫 lastOpTimeWritten 的命令查找到它最近的一条写操作。这个命令你也可以随便在命令行执行：

> rs.debug.getLastOpWritten()

这个命令会返回一条oplog记录，其中的ts字段就是最近一次写操作的时间了。

如果你这个节点是全新的，没有数据，那么oplog里也没有数据，这时候节点会选择执行一次全量的同步。本文暂时不对全量同步的方法进行描述。

选择同步源节点

Replica Sets中的节点之间总在同步数据，但是他们不是通过传统的一主多从的方式来同步的。MongoDB的策略是选择一个合适的节点作为数据源。

首先secondary节点会通过ping的时间来确定其它节点与它的距离。时间越长的识为距离越远。然后通过下面方法确定其源节点：

for each member that is healthy:
    if member[state] == PRIMARY
        add to set of possible sync targets

    if member[lastOpTimeWritten] > our[lastOpTimeWritten]
        add to set of possible sync targets

sync target = member with the min ping time from the possible sync targets

对于节点是否healthy的判断，各个版本不同，但是其目的都是找出正常运转的节点。在2.0版本中，它的判断还包括了salve delay这个因素。

你可以通过运行db.adminCommand({replSetGetStatus:1})命令来查看当前的节点状况，在secondary上运行这个命令，你能看到syncingTo这个字段，这个字段的值就是这个secondary的同步源。（其实名字应该是叫syncingFrom，但是由于版本兼容的原因，沿用了这个错误的名字）

链式同步结构

上面对w参数的实现，讲解上比较简单，只讲了w为2的情况，但是当w更大时，由于我们并不是采用一主多从的方式进行同步。所以情况会复杂一些。

比如我们有节点A，为primary节点，然后B节点为secondary节点，它从A节点同步数据，同时又有secondary节点C，它从同是secondary的B节点同步数据。这样A->B->C之间就形成了一个链式的同步结构。如果我们设定w为3，那么A节点如何能知道C节点已经从B节点同步成功了呢？

这是通过oplog同步协议来实现的，我们用通俗的语言来解释一下oplog的同步协议。

• 当C从B同步数据时，C会在协议中对B说：我要从你这同步数据了，如果写操作有w参数的话，我的同步也算上吧。
• 然后B会回答说：我不是一个primary节点，我会把你的这个计数转到我的同步源上去。
• 然后B再对A打开一个新的连接，并且对A说：这个连接你就当成是C的吧，也算一个计数在w里。
• 这时候在A看来，就有两个连接连到他上面，一个是B，一个是虚拟的C，这两个连接都能报告他说完成了同步操作。

当一个写操作在A上执行后，B首先同步到这个操作的oplog，执行完后会告诉A，我执行完了。然后C同样从B上获取到B的oplog，也执行了这一条写操作，然后他告诉B，我执行完了，B在收到这个响应后，会通过刚才开通的虚拟通道跟A说，我是虚拟的C节点，我也完成写操作了。这时候A就知道，A、B、C三个节点都完成写操作了。w：3的条件满足，然后返回给调用getLastError的客户端，完成这次操作。

具体三个节点间的连接如下图：

C        B        A
           <====>
  <====>   <---->

B和A之间有两条通道，双线那条是真正的同步连接，单线那条是一个虚拟连接。

新功能展望

上面就是当前的Replica Sets同步的内部实现，在后续这一块还会进行一些新特性的开发。在2.2版本中，我们会提供replSetSyncFrom命令，让用户可以手动设置一个secondary的同步源。使用方法大概是这样：

> db.adminCommand({replSetSyncFrom:"otherHost:27017"})

敬请期待，thx

来源：www.snailinaturtleneck.com

相关文章：

Warning:MongoDB Replica Sets配置注意事项

Replica Sets系列文章之：选举

Foursquare：使用MongoDB Replica Sets的三种架构

MongoDB Replica Sets-让你的数据荡然无存？

MongoDB 1.7.x版本中的5个Replica Sets新特性

无觅

为什么要将缓存集成到数据库内部？

实际上，缓存既可以储存到数据库内部，也可以是外部的独立缓存层。将缓存集成到数据库内部，有下面一些好处：

• 天然具备分布式特性：Cassandra本身就是一个分布式的数据存储系统，所以在其中加入缓存功能也自然而然的成为分布式缓存。你不需要使用像 ketema 这种一致性hash库去实现自己的分布式缓存系统。
• 简化架构：在一个技术架构中，活动组件越多，通常复杂度也越高，出问题的几率也更大。像排查一个分布式缓存系统问题这种事，即使是对经验丰富的运营工程师也是件费劲的活。
• 保持缓存与数据库一致性：如果你采用了外部缓存系统，那么你的客户端在操作数据时，必然会涉及到先后对数据库和缓存进行两次更新操作。这期间无论是你先更新缓存还是数据库，后更新那一个一旦失败，就必然会出现缓存中的数据与数据库中的不一致的问题（更新或者更老）。而这个问题实际上很好解决，通过将缓存集成到数据库中，我们在客户端只需要进行一次对数据库的更新操作，至于缓存和数据的一致性，交给数据库来解决就行了。
• 自动的数据冗余：如果你用Memcached作为独立到数据库的缓存层，那么在Memcached出现故障时，可能读请求就会直接落到数据库上，因为Memcached本身没有缓存冗余存储的功能，导致一个点倒掉缓存就失效了。而如果把缓存集成到数据库中，由于Cassandra本身的分布式特点，其缓存也是分布式冗余到多个节点的，所以节点故障不会导致缓存系统失效。
• 解决数据预热的问题：数据预热是指的在缓存故障重启后，由于缓存中此时空无一物，所以所有请求都会直接落到数据库上，为了防止数据库直接被压崩溃，运营人员通常会人为的控制流量，而结果就是导致大部分的用户故障，需要一段时间等缓存慢慢充满后才能恢复正常服务。这是传统缓存的一个典型问题。而Cassandra的集成缓存会进行定期的落地操作，Cassandra会定期将内部缓存定到磁盘上，这样当故障重启后，我们只需要一次性把原来的缓存镜像加载到内存中就行了，不需要通过用户访问一点点预热缓存。

主键缓存和行缓存

主键缓存就是对Cassandra表的主键的缓存，主键缓存能够节约内存和CPU时间。但是，如果仅仅是开启主键缓存的话，我们在取具体每一行数据时还是可能会导致磁盘操作。

行缓存类似于传统的Memcached缓存，其机制是，当某一行数据被访问时，将其加载到内存中，这样后续的访问只需要通过内存访问就能拿到这一行数据。

在一般的场景下，你可能会选择开启主键缓存或者行缓存，这样会提高读性能。但是对那种不经常读的表，就可以完全不开启缓存了。

Cassandra1.1中缓存的配置

最主要的缓存设置参数有两个：key_cache_size_in_mb 和 row_cache_size_in_mb，都通过在 cassandra.yaml中进行设置。

与之前版本不同的是，1.1版本中不再需要对每个表单独进行缓存大小的设置，所有缓存都在一个池子里共享内存，Cassandra内部会自动地按使用情况合理分配内存。

而对于行缓存，还有一个 row_cache_provider 参数可以对其具体实现进行控制，当设置其值为 SerializingCacheProvider 时，缓存对内存的使用非常高效（在非blob密集的情况下，有5到10倍的内存使用率提升），但是如果是更新频繁的应用场景下，其性能会比较糟糕。因为更新操作会导致其将缓存置为失效。而这时候如果使用 ConcurrentLinkedHashCacheProvider 的话会更好，因为它是直接更新缓存的值。

OpsCenter 通过查看缓存的效率，通过来说，缓存达到90％以上的命中率是比较正常的。如果你某个表的行缓存达不到这个数，那么建议你将这个表的行缓存去掉，仅保留主键缓存。这样它原本用在行缓存上的内存就可以被其它命中率更高的表更高效地使用了。

现有问题与未来规划

相关文章：

Cassandra SF 会议精华集锦

cassandra观止

Cassandra运维之道

Cassandra入门

Cassandra新特性：分层压缩

无觅

申请：下面几点并非放四海皆准的法则，具体是否能够使用，还需要根据自己的应用场景和数据特点来决定。

1.使用组合式的大文档

我们知道MongoDB是一个文档数据库，其每一条记录都是一个JSON格式的文档。比如像下面的例子，每一天会生成一条这样的统计数据：

{ metric: "content_count", client: 5, value: 51, date: ISODate("2012-04-01 13:00") }
{ metric: "content_count", client: 5, value: 49, date: ISODate("2012-04-02 13:00") }

而如果采用组合式大文档的话，就可以这样将一个月的数据全部存到一条记录里：

{ metric: "content_count", client: 5, month: "2012-04", 1: 51, 2: 49, ... }

通过上面两种方式存储，预先一共存储大约7GB的数据（机器只有1.7GB的内存），测试读取一年信息，这二者的读性能差别很明显：

• 第一种: 1.6秒
• 第二种: 0.3秒

那么问题在哪里呢？

实际上原因是组合式的存储在读取数据的时候，可以读取更少的文档数量。而读取文档如果不能完全在内存中的话，其代价主要是被花在磁盘seek上，第一种存储方式在获取一年数据时，需要读取的文档数更多，所以磁盘seek的数量也越多。所以更慢。

实际上MongoDB的知名使用者foursquare就大量采用这种方式来提升读性能。见此

2.采用特殊的索引结构

我们知道，MongoDB和传统数据库一样，都是采用B树作为索引的数据结构。对于树形的索引来说，保存热数据使用到的索引在存储上越集中，索引浪费掉的内存也越小。所以我们对比下面两种索引结构：

db.metrics.ensureIndex({ metric: 1, client: 1, date: 1})

与

db.metrics.ensureIndex({ date: 1, metric: 1, client: 1 })

采用这两种不同的结构，在插入性能上的差别也很明显。

当采用第一种结构时，数据量在2千万以下时，能够基本保持10k/s 的插入速度，而当数据量再增大，其插入速度就会慢慢降低到2.5k/s，当数据量再增大时，其性能可能会更低。

而采用第二种结构时，插入速度能够基本稳定在10k/s。

其原因是第二种结构将date字段放在了索引的第一位，这样在构建索引时，新数据更新索引时，不是在中间去更新的，只是在索引的尾巴处进行修改。那些插入时间过早的索引在后续的插入操作中几乎不需要进行修改。而第一种情况下，由于date字段不在最前面，所以其索引更新经常是发生在树结构的中间，导致索引结构会经常进行大规模的变化。

3.预留空间

与第1点相同，这一点同样是考虑到传统机械硬盘的主要操作时间是花在磁盘seek操作上。

比如还是拿第1点中的例子来说，我们在插入数据的时候，预先将这一年的数据需要的空间都一次性插入。这能保证我们这一年12个月的数据是在一条记录中，是顺序存储在磁盘上的，那么在读取的时候，我们可能只需要一次对磁盘的顺序读操作就能够读到一年的数据，相比前面的12次读取来说，磁盘seek也只有一次。

db.metrics.insert([
    { metric: 'content_count', client: 3, date: '2012-01', 0: 0, 1: 0, 2: 0, ... }
    { .................................., date: '2012-02', ... })
    { .................................., date: '2012-03', ... })
    { .................................., date: '2012-04', ... })
    { .................................., date: '2012-05', ... })
    { .................................., date: '2012-06', ... })
    { .................................., date: '2012-07', ... })
    { .................................., date: '2012-08', ... })
    { .................................., date: '2012-09', ... })
    { .................................., date: '2012-10', ... })
    { .................................., date: '2012-11', ... })
    { .................................., date: '2012-12', ... })
])

结果：

• 如果不采用预留空间的方式，读取一年的记录需要62ms
• 如果采用预留空间的方式，读取一年的记录只需要6.6ms

来源：www.colinhowe.co.uk

相关文章：

Variety：MongoDB schema分析工具

MongoDB Auto-Sharding 的问题

MongoDB构架图分享

Mongodb Mapreduce 初窥

简单的MongoDB

无觅

ziplist是用一个字符串来实现的双向链表结构，顾名思义，使用ziplist可以减少双向链表的存储空间，主要是节省了链表指针的存储，如果存储指向上一个链表结点和指向下一个链表结点的指针需要8个字节，而转化成存储上一个结点长度和当前结点长度在大多数情况下可以节省很多空间（最好的情况下只需2个字节）。但是每次向链表增加元素都需要重新分配内存。

ziplist中的结构体

typedef struct zlentry {
unsigned int prevrawlensize, prevrawlen;
unsigned int lensize, len;
unsigned int headersize;
    unsigned char encoding;
    unsigned char *p;
} zlentry;

• Prevrawlen：上个链表结点占用的长度
• Prevrawlensize：上个链表结点长度的存储占用的字节数
• Len：当前链表结点占用的长度
• Lensize：当前链表结点长度的存储占用的字节数
• Headersize：当前链表结点的头部大小， headersize = prevrawlensize + lensize
• Encoding：当前链表结点长度（即字段len）使用的编码类型
• P：指向当前结点起始位置的指针

Ziplist的存储结构

链表存储结构

<zlbytes><zltail><zllen><entry><entry><zlend>

• Zlbytes：一个4字节的无符号整型，存储的是整个ziplist占用的字节数，用于重分配内存时使用。
• Zltail：一个4字节的无符号整型，存储的是链表最后一个结点的偏移值，即链表开头地址+zltail即为最后一个结点的起始地址
• Zllen：一个2字节的无符号整型，存储的是链表中存储的结点数，当这个值存储的是2字节无符号整型的最大值时，需要遍历链表获取链表的结点数
• Entry：链表结点，链表结点的存储格式见结点存储结构
• Zlend：占用1字节的链表的结尾符，值为255

相关的宏定义

Ziplist.c: 89

/* Utility macros */
#define ZIPLIST_BYTES(zl)       (*((uint32_t*)(zl)))
#define ZIPLIST_TAIL_OFFSET(zl) (*((uint32_t*)((zl)+sizeof(uint32_t))))
#define ZIPLIST_LENGTH(zl)      (*((uint16_t*)((zl)+sizeof(uint32_t)*2)))
#define ZIPLIST_HEADER_SIZE     (sizeof(uint32_t)*2+sizeof(uint16_t))
#define ZIPLIST_ENTRY_HEAD(zl)  ((zl)+ZIPLIST_HEADER_SIZE)
#define ZIPLIST_ENTRY_TAIL(zl)  ((zl)+ZIPLIST_TAIL_OFFSET(zl))
#define ZIPLIST_ENTRY_END(zl)   ((zl)+ZIPLIST_BYTES(zl)-1)

结点存储结构

<上一个链表结点占用的长度><当前链表结点占用的长度><当前结点数据>

上一个链表结点占用的长度

上一个链表结点占用的长度占用的字节数根据编码类型而定

• 当长度数据小于254使用一个字节存储，该字节存储的数值就是该长度，
• 当长度数据大于等于254时，使用5个字节存储，第一个字节的数值为254，表示接下来的4个字节才真正表示长度

当前链表结点用的长度存储和数据存储

第一个字节的前两位用于区分长度存储编码类型和数据编码类型，具体如下

字符串类型编码

|00pppppp|

长度小于等于63（2^6-1）字节的字符串，后6位用于存储字符串长度，长度与类型总共占用了1个字节

|01pppppp|qqqqqqqq|

长度小于等于16383（2^14-1）字节的字符串，后14位用于存储字符串长度，长度与类型总共占用了2个字节

|10______|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt|

长度大于等于16384字节的字符串，后4个字节用于存储字符串长度，长度与类型总共占用了5个字节

整型编码

|1100____|

整型类型，后2个字节存储的值就是该整数

|1101____|

整型类型，后4个字节存储的值就是该整数

|1110____|

整型类型，后8个字节存储的值就是该整数

相关的宏定义

Ziplist.c：77

/* Different encoding/length possibilities */
#define ZIP_STR_06B (0 << 6)
#define ZIP_STR_14B (1 << 6)
#define ZIP_STR_32B (2 << 6)
#define ZIP_INT_16B (0xc0 | 0<<4)
#define ZIP_INT_32B (0xc0 | 1<<4)
#define ZIP_INT_64B (0xc0 | 2<<4)

/* Macro's to determine type */
#define ZIP_IS_STR(enc) (((enc) & 0xc0) < 0xc0)
#define ZIP_IS_INT(enc) (!ZIP_IS_STR(enc) && ((enc) & 0x30) < 0x30)

Ziplist提供的接口

unsigned char *ziplistNew(void);

创建一个ziplist

• 返回创建的ziplist的指针

unsigned char *ziplistPush(unsigned char *zl, unsigned char *s, unsigned int slen, int where);

在ziplist的尾端或头部添加一个结点

• zl是ziplist的指针
• s是待添加结点的值
• slen是待添加结点的值长度
• 返回最新的ziplist的指针

unsigned char *ziplistIndex(unsigned char *zl, int index);

根据索引获取ziplist的结点，封装类似数组接口

• zl是ziplist的指针
• index是索引，从0开始，0即取链表的第一个结点，index可以是负数，负数表从后往前算，-1就是取链表的最后一个元素
• 如果index处有结点，则返回指向改结点的指针，否则返回NULL

unsigned char *ziplistNext(unsigned char *zl, unsigned char *p);

获取ziplist的下一个结点

• zl是无用参数
• p是当前结点指针
• 如果还有下一个结点，则返回下一个结点的指针，否则返回NULL

unsigned char *ziplistPrev(unsigned char *zl, unsigned char *p);

获取ziplist的上一个结点

• zl是ziplist的指针
• p是当前结点指针
• 如果还有上一个结点，则返回上一个结点的指针，否则返回NULL

unsigned int ziplistGet(unsigned char *p, unsigned char **sval, unsigned int *slen, long long *lval);

获取p指向的当前结点的值

• p是指向当前结点的指针
• sval保存获取到的当前结点的值的指针
• slen是获取到的当前结点的值的长度
• lval是当值是整型时保存返回的数值
• 如果p指向的结点是合法结点返回1，否则返回0

unsigned char *ziplistInsert(unsigned char *zl, unsigned char *p, unsigned char *s, unsigned int slen);

在指针p指向的位置插入一个结点

• zl是ziplist的指针
• p是待插入结点的位置
• s是待插入结点的值
• slen是待插入结点的值的长度
• 返回最新的ziplist的指针

unsigned char *ziplistDelete(unsigned char *zl, unsigned char **p);

删掉*p指向的结点

• zl是ziplist的指针
• p是一个value-result参数，传入需删除的结点，返回被删除结点下一个结点的指针
• 返回最新的ziplist的指针

unsigned char *ziplistDeleteRange(unsigned char *zl, unsigned int index, unsigned int num);

删除连续的一批结点

• zl是ziplist的指针
• index是开始删除的索引
• num是删除的个数
• 返回最新的ziplist的指针

unsigned int ziplistCompare(unsigned char *p, unsigned char *s, unsigned int slen);

p指向的结点的值和s对应的值做比较

• p是ziplist结点的指针
• s是呆比较的值
• slen是s的长度
• 相等返回1，否则返回0

unsigned int ziplistLen(unsigned char *zl);

取ziplist链表中元素的个数

• zl是ziplist的指针
• 返回ziplist链表中元素的个数

size_t ziplistBlobLen(unsigned char *zl);

取ziplist链表占用的字节数

• zl是ziplist的指针
• 返回ziplist链表占用的字节数

相关文章：

深入Redis内部-Redis 源码讲解

Redis源码分析系列文章

redis-faina：一个Redis的query分析小工具

Redis 源码分析：dict.c 和 dict.h

Redis内存存储结构分析

无觅

MongoDB Hadoop Connector的主要流程是让Hadoop从MongoDB中读取原始数据，在通过Hadoop计算完成后，再将结果导入到MongoDB中。原始数据的读取和结果写入可以对同一个MongoDB，也可以是不同的。其主要目的是让使用MongoDB的用户能够更方便地直接使用Hadoop功能。

目前MongoDB Hadoop Connector已经与Hadoop生态系统中的一些组件进行了整合，后续还会根据反馈进行更全方便的整合。具体如下：

• 可以通过 Pig 向 MongoDB 中写入数据。
• 可以通过分布式日志系统 Flume 往MongoDB中导入日志原始数据。
• 通过使用Hadoop Streaming，可以用 Python来写 MapReduce函数。

MongoDB Hadoop Connector目前支持2.0以上的版本（1.8.x版本也基本上能够支持）。

当然项目是开源的，项目地址：mongo-hadoop

消息来源：blog.10gen.com

相关文章：

foursquare 的数据分析系统（Hadoop+Hive+Redis+MongoDB）

Variety：MongoDB schema分析工具

MongoDB＋Hadoop构建MapReduce运算系统

Wordnik 的 MongoDB 使用经历

Hadoop生态图谱

无觅

• Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
• Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
• Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 millisecodns (9 milliseconds per GB).
• Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
• Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
• Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).

说明：Redis的fork操作主要发生在写RDB文件和AOF rewrite的过程中，Redis通过fork出一个子进程来完成上面的工作，通过利用fork操作的COW（copy on write）功能，使得系统能够仅仅复制内存页面引用来实现数据快照的功能。

相关文章：

redis-faina：一个Redis的query分析小工具

Redis与CouchDB的对比

REDIS TO GO：一个Redis存储服务

Redis教程一篇

Redis.io-Redis的新家

无觅