前言
没读过SSDB的源码，也没读过LevelDB，但好歹也是用了很久的工具，就算没用好没用到位也有必要总结一下，说不定以后用不到了。。。
先了解一下leveldb的原理别人整理的blog，记得当时我还看过郎格科技的原文，如今已无法访问，世事无常啊。
SSDB在LevelDB的基础上提供了网络支持，各种语言客户端api，封装了一些数据结构。
以下只谈使用不谈原理。
特点
- 耗CPU不耗内存
- 天生单节点，说实话主从同步之类的感觉不好用，分布式要自己实现
- 读写速度和redis一个数量级的
- 写单线程，读多线程
- 删除有点蛋疼
- 单单从api角度来看，功能对比redis单薄很多
- 单节点的写操作只会影响CPU一个核的使用
使用场景
举两个例子，公司生产中用到的，都是当持久化数据库而非缓存使用。
使用的数据结构为kv（只有kv支持过期机制），配置了双主（为了容错），数据量不大，用得还行。但项目开始时由于没有控制数据量，因为删除动作（过期）相当于写入，影响到了实际数据写入效率。得出结论：得分多个节点，充分利用cpu；慎用过期/删除。
另个项目用hashmap，示意一下：’城市_版本号’,’key’,’value’。每周批量写一个版本的数据（共数十G），而老版本只需保留一个已防万一，之前的就没用了。由于前文提到的原因万万不能做删除动作，目前采用了临时的解决方案：切换节点，老节点数据手动删除。
遇到的大坑
- 删除/过期算一个
- 主从同步，主节点使用multihset批量插入，从节点同步。实际从节点数据是一条条插入的，延时严重，log日志量爆表。还必须注意binlog_capacity这个参数，当主从差距超过这个参数会触发OUT_OF_SYNC，slave节点会由sync状态改用copy同步全量数据，简直爆炸。