SSDB概要及其双主功能分析

1、概述

谷歌的LevelDB数据库引擎基于文件存储系统，所以它支撑量大的数据而不因为内存的限制受取约束。SSDB封装其API并支持了网络访问功能，相当于SSDB是LevelDB的一层壳。SSDB兼容Redis的大部分客户端指令，对接Redis的代码可以快速移植到SSDB。

SSDB的用户包括百度搜索业务、360游戏中心、京东等多个国内一二线互联网厂商使用，稳定性较有保障。

2、安装部署

2.1、安装

显示用下面两个指令安装基础工具后

yum install -y gcc*
yum install -y unzip zip
yum install -y autoconf

再按照官方的在github项目的安装指引安装即可

https://github.com/ideawu/ssdb

3、主要底层机制

3.1主从同步策略

SSDB 的主从同步策略非常简单, 就是把主(Master)上的所有写操作(Binlogs), 在从(Slave)上再执行一遍，和Mysql主从同步的的Stream模式类似。多主可以理解为互为主从。

当然操作记录binlog不是无限记录的，ssdb只记录1000万次操作记录，更早的数据无法提现到binlog中。所以新节点加入会有一个copy的阶段，copy初始数据完成后才会进入sync阶段，通过binlog保持同步。

更为详细的说明可以查看作者的文档（由于文章成文较早，作者的对非SSDB的问题说法不一定对，要注意判断）

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

3.2 数据库引擎LevelDB

levelDB是一个key->value 的数据存储库，其只能在本地保存数据，支持持久化，并且支持保存非常大的数据，单机redis在保存较大数据的时候数十G的时候会出现响应慢等问题，而单机levelDB数据在150G以内的时候依然可以保持比较好的性能，其随机写入key->value的数据每秒可达到40W条，每秒随机读在6W，写比读还要快，因此适用于写操作大于读操作的场景。

4、对Redis常用指令支持度

SSDB对Redis1的代码支持还是有些缺失，想要完全不改代码不一定做得到

keys、flush 实测不支持，这个对正式环境使用影响较小，正式环境一般不用
set key value EX seconds 不支持，有一定影响，但代码上修改拆成两步操作接口，较快修改
删除整个hash、zset、lilst必须使用SSDB的客户端执行hclear、zclear、qclear命令, 无法使用Redis客户端的del key删除。影响比较大，意味着可能要使用SSDB客户端
不支持set数据结构，set用hash替代勉强可以接受

5、性能表现

官方宣称其性能能达到Redis相当的水平。

我使用redis-benchmark这个工具，用300个连接、随机key、十万次指令在挂载高效云盘并有IO优化的云服务器上进行各种不同情况的压测以对比redis和ssdb的性能，期间仅变动ip、端口、单数据包大小（-d参数）

redis-benchmark -h ip地址  -p 端口 -r 100000 -t get,set,lpush,lpop -n 100000 -c 300 -d 1000 -q

5.1、单机本机压测性能

单数据包大小为1k时ssdb性能get、set指令超过8、9成

redis表现

SET: 82987
GET: 84175

ssdb表现如下，在set指令上差距较大

SET: 60496
GET: 76687

将单元数据调大为10k时，ssdb性能表现下降较大

redis表现

SET: 75187
GET: 83752

ssdb表现如下，在set指令上性能下降较大

SET: 29095
GET: 51229

5.2 单实例非本机性能测试

使用1k大小的单数据包测试ssdb和客户端在同一个阿里云大区的不同服务器时的性能。

比起本机压测，性能下降了10-30%，应该主要是网络延时

SET: 47687
GET: 42337

5.3、双主同步性能

5.3.1、双主配置

配置双主，修改ssdb.conf文件的replication:slaveof 中四个字段即可。其中host和port为另一个实例的ip和por；id字段填写对方的实例id，id自行分配，在集群中唯一即可；双主时type字段用mirror。

双主的配置示例

server1

replication:
    slaveof:
        id: svc_2
        type: mirror
        host: svc_2的ip
        port: 8889

server2

replication:
    slaveof:
        id: svc_1
        type: mirror
        host: svc_1的ip
        port: 8888

配置完毕启动实例后连接ssdb数据库使用info指令获取集群同步状态信息

如果配置主从，主机不配置slaveof下的字段，从机配置即可，type需要设置为sync。

如果是多主，在一组一共包含 n 个实例的 SSDB 实例群中, 每一个实例必须在slaveof配置其余的n-1个实例，示例如下：

replication:
    slaveof:
        id: svc_1
        type: mirror
        host: localhost
        port: 8888
    slaveof:
        id: svc_2
        type: mirror
        host: localhost
        port: 8889
    # ... more slaveof

5.3.2、双主集群下性能

阿里云同一个大区的两个ECS组成双主集群情况下性能和单机没什么区别

SET: 62829.86 
GET: 81314.03

不同大区异地同步性能因为没有足够大的专线带宽，测试时带宽会成为瓶颈，没有进行。

6、评价及优缺点

优点

因为大量使用硬盘存储，成本较低，支持海量数据，这个可能就是很多互联网大厂使用的原因
兼容redis的大部分指令，从redis切换过来成本比较低

缺点

个人项目，社区和持续维护方面和Redis差距非常大。比如项目的issue列表里有一些比较严重的可用性Bug，未见到明确修改的答复和计划。例如这个https://github.com/ideawu/ssdb/issues/1256
性能测试时发现使用10K的数据包性能下跌相较Redis下降较严重。
限制占用带宽的配置 sync_speed 没有效果，设置了也会占满带宽
对Hash、list等集合的del指令不支持带来比较严重的影响
复杂度比Redis高不少，毕竟要了解LevelDb

总的来说，SSDB明显优势是海量数据存储和低成本以及有双主模式。但是由于社区和开发者都不活跃，使用者要做好有专人深入研究并看源码解决问题的准备，否则不建议使用。

7、参考资料

常见问题
SSDB数据同步原理说明，和redis的主从同步、myql的主主同步大同小异
SSDB和Redis指令对照表