经过前段时间的连续奋战, 前两晚的代码清理和收尾, 基于 LevelDB 的 KV(支持数据类型包括 hashmap, zset) 存储服务器 SSDB 终于发布了 1.2.0 版本. 这是一个里程碑式的版本, 因为从此 SSDB 支持了主从同步(master-slave replication), 再加上在线备份功能, SSDB 已经成为一个真正的生产环境的存储服务器!
Google 的 LevelDB 存储引擎保证了 SSDB 至少能存储 T 级别的数据, 并在上面进行快速的查询, 有报告称 100G 级别的数据已经在网站上正常工作. 而 SSDB 本身实现的备份和主从同步特性, 则是对生产环境的必要支持 - 负载均衡.
从实现上, SSDB 利用 LevelDB 来存储数据, 以及数据的更新历史. 由于两者都是 LevelDB 来保证持久化, 所以 SSDB 的主从同步可以容忍不稳定的网络, 包括网络异常中断, 带宽起伏等, 因为 SSDB 能从上一次的同步状态中继续恢复. 相比较, Redis 在这方面做得不好, 经常因为网络不稳定而导致主从之间不断地进行全量数据的复制.
SSDB 1.2.x 是 beta 版, 欢迎在这方面有经验的同学参与进来一起开发, 已经有百度的前同事决定要加入进来了.
SSDB 项目地址: https://code.google.com/p/zdb/
另外, LevelDB 本身还有一些待改进的地方, 例如在磁盘写 IO 上面没有限速, 磁盘写 IO 限速在生产环境中是非常重要, 我们的经验证明了这一点. 一旦磁盘写压力过大, 不仅导致其它进程可能阻塞, 甚至可能对操作系统也有影响.
Loading ...
请教下会不会存在这样的问题：
迭代过程中有更新key，sync请求将这个key同步过去后，copy过程又将这个key刷会老值？
下面这段代码注释：
// WARN: When there are writes behind last_key, we MUST create
// a new iterator, because iterator will not know this key.
// Because iterator ONLY iterates throught keys written before
// iterator is created.
if(this->iter){
delete this->iter;
this->iter = NULL;
}
这里只处理了”behind last_key“，但如果并没有超过last key，仅仅对已有的key做更新，迭代器一样发现不了。 Reply