Redis初窥

Berkeley DB 比,Redis 的优势是它支持复杂的数据类型。Berkeley DB 中key、value都是字节流,实际用的时候都是把对象序列化成二进制然后交给 Berkeley DB,所以Berkeley DB并不理解任何数据类型。而Redis内置了很多种Collection并且可以对Collection做原子操作。

Redis 也对64位技术极为不满,因为需要消耗更多的内存,所以:“If your application is already able to perform application-level sharding, it is very advisable to run N instances of Redis 32bit against a big 64 bit Redis box (with more than 4GB of RAM) instead than a single 64 bit instance, as this is much more memory efficient.”

Redis 在实现中还搞了一件很有趣的事情:它把复制内存的事情交给了操作系统来做。Redis不是一有更新就写硬盘,而是定时刷新。延迟写入这种做法很常见。一般的解决思路是把先加锁,然后把有修改的页找出来,在内存中复制一份,然后释放锁,然后写硬盘。而Redis的实现则是 加锁、fork、父进程释放锁,让子进程慢慢在那写着。利用操作系统对内存的copy-on-write的机制缩短持有锁的时间。但我并不认为这是一个好主意。首先,它依赖于fork的实现而不是规范,这里面有太多不可控不透明的东西。其次,复制内存页并不需要花费太多时间。因为脏页最终都是要写到硬盘上的,而内存的写入速度大概是硬盘的1000倍以上。所以如果往硬盘上flush的间隔不太长,在内存中复制脏页所需的时间完全可忽略。

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥