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项目的安装指引安装即可
3、主要底层机制
3.1主从同步策略
SSDB 的主从同步策略非常简单, 就是把主(Master)上的所有写操作(Binlogs), 在从(Slave)上再执行一遍，和Mysql主从同步的的Stream模式类似。多主可以理解为互为主从。
当然操作记录binlog不是无限记录的，ssdb只记录1000万次操作记录，更早的数据无法提现到binlog中。所以新节点加入会有一个copy的阶段，copy初始数据完成后才会进入sync阶段，通过binlog保持同步。
更为详细的说明可以查看作者的文档（由于文章成文较早，作者的对非SSDB的问题说法不一定对，要注意判断）
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明显优势是海量数据存储和低成本以及有双主模式。但是由于社区和开发者都不活跃，使用者要做好有专人深入研究并看源码解决问题的准备，否则不建议使用。
网友评论