SSDB使用

最新推荐文章于 2024-02-20 20:07:57 发布

stonehigher125

最新推荐文章于 2024-02-20 20:07:57 发布

阅读量2.6k

点赞数

分类专栏：分布式系统

本文链接：https://blog.csdn.net/stonehigher125/article/details/39202589

版权

分布式系统专栏收录该内容

1 篇文章 0 订阅

订阅专栏

连接池的实现要点总结

http://blog.csdn.net/li5220008/article/details/18401865

http://blog.csdn.net/li5220008/article/details/18227527

使用 Twemproxy 来做 SSDB 负载均衡

http://www.ideawu.net/blog/archives/814.html

2013-03-08

1.主从同步，从读取阻塞。 SSDB的主从同步出现了问题, 同步复制中断了. 在这次故障中, SSDB Master的心跳机制(noop包)检测到了网络故障, 然后关闭了socket. 但是, 由于之前并没有实现Slave的心跳机制, 所以Slave一直阻塞在了socket的read操作上. 再加上socket没有开启keepalive(即使开启了keepalive, TCP也要过2小时才开始发送keepalive包), Slave就一直阻塞住了.

RocksDB介绍：一个比LevelDB更彪悍的引擎

RocksDB支持一次获取多个K-V，还支持Key范围查找。LevelDB只能获取单个Key

RocksDB除了简单的Put、Delete操作，还提供了一个Merge操作，说是为了对多个Put操作进行合并。站在引擎实现者的角度来看，相比其带来的价值，其实现的成本要昂贵很多。个人觉得有时过于追求完美不见得是好事，据笔者所测（包括测试自己编写的引擎），性能的瓶颈其实主要在合并上，多一次少一次Put对性能的影响并无大碍。

RocksDB提供一些方便的工具，这些工具包含解析sst文件中的K-V记录、解析MANIFEST文件的内容等。有了这些工具，就不用再像使用LevelDB那样，只能在程序中才能知道sst文件K-V的具体信息了。

RocksDB支持多线程合并，而LevelDB是单线程合并的。LSM型的数据结构，最大的性能问题就出现在其合并的时间损耗上，在多CPU的环境下，多线程合并那是LevelDB所无法比拟的。不过据其官网上的介绍，似乎多线程合并还只是针对那些与下一层没有Key重叠的文件，只是简单的rename而已，至于在真正数据上的合并方面是否也有用到多线程，就只能看代码了。

RocksDB增加了合并时过滤器，对一些不再符合条件的K-V进行丢弃，如根据K-V的有效期进行过滤。

压缩方面RocksDB可采用多种压缩算法，除了LevelDB用的snappy，还有zlib、bzip2。LevelDB里面按数据的压缩率（压缩后低于75%）判断是否对数据进行压缩存储，而RocksDB典型的做法是Level 0-2不压缩，最后一层使用zlib，而其它各层采用snappy。

在故障方面，RocksDB支持增量备份和全量备份，允许将已删除的数据备份到指定的目录，供后续恢复。

RocksDB支持在单个进程中启用多个实例，而LevelDB只允许单个实例。

RocksDB支持管道式的Memtable，也就说允许根据需要开辟多个Memtable，以解决Put与Compact速度差异的性能瓶颈问题。在LevelDB里面因为只有一个Memtable，如果Memtable满了却还来不及持久化，这个时候LevelDB将会减缓Put操作，导致整体性能下降。笔者目前写的引擎在这方面竟然跟RocksDB不谋而合，这里偷偷乐一下，呵呵。

主从同步：
需要一种diff-patch或者类似rsync的机制.

redis 主从，没有实现HA。
主停了，就没法服务了。

SSDB可以双主架构。
数据存储量达到数百G。

新浪微博使用的Redis 也是他们自己加上了合并限速模块.

10分钟处理186万。

性能，磁盘，IO，
gc 10秒560次GC

快准狠

##############TODO

twitter/facebook 技术解密

ketama算法