idea's blog

春节期间的半个多月, 因为我休假, 所以SSDB没有任何更新. 但是, 我们生产环境中的SSDB实例是一直在跑着的, 数据量每天都增加千万条. 服务器一直运行稳定, 不需要任何维护工作.

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

这个故障说明SSDB的监控工具需要尽早开发了. 当然, 这个问题现在已经解决, 就是实现了Slave的心跳机制. 当Slave在一段时间后没有收到Master的消息, 就会主动断开重连.

目前, SSDB的主从同步机制还需要进一步完善. 虽然Master的同步日志队列已经加大到了1000万条更新操作, 但对于上百G数据的完全同步的成本还是非常大, 所以需要一种diff-patch或者类似rsync的机制.

注: SSDB是一个LevelDB的网络服务器, 用C/C++编写, 支持zset/map/list等数据结构. SSDB是开源的, 项目主页在 https://github.com/ideawu/ssdb.

网络协议可以分为文本协议和二进制协议, 而对于基于报文的协议可分为定长报文协议和变长报文协议. 而现实业务中的网络协议基本都是基于报文的协议.

从应用层网络协议的设计发展来看, 二进制协议和定长报文协议极为罕见. 在变长报文协议中, 有两种实现方式: 结束标记和长度字段. 下面以最流行的 HTTP 来进行举例分析.

HTTP 是文本协议, 变长报文协议, 带长度字段的报文协议. HTTP 带有多个 Key-Value 对组成的首部, 用连续的两个 CRLF 分隔首部和报体, 没有报文结束标记(HTTP 1.0 以连接关闭来标记报文结束), 同时 HTTP 还是文本和二进制混合的协议, 报文首部有长度字段, 所以报体中的二进制数据无需转义.

Continue reading »

最近一段时间以来, SSDB 一直保持的稳定的更新速度, 代码在完善, 功能在丰富和整合. 目前已经有多个国内和国外用户在尝试使用, 相信很快就可以成为 SSDB 的正式用户.

前几个版本, SSDB 增加了 log rotate 功能. 最新的更新版本中增加了 hlist 和 zlist 命令, 用于列出当前的 map 和 zset. KV 结构的数据仍然使用 keys 列出. *list 既不同于 *keys, 也不同于 *scan, 因为 *list 用于列出集合的名字, 而后两者则用于列出集合的内容.

最近 SSDB 在生产环境的使用中, 遇到了多机房的问题. 在机房间网络无法改善的情况下, SSDB 必须能应付这种状况. 这里初步设计了新的同步体系, 欢迎大家一起讨论: https://github.com/ideawu/ssdb/issues/11.

在最近的一个项目中, SSDB 刚一重启便使用了 500M 的虚拟内存(top VIRT), 但这都是 LevelDB 使用的, 并不是 SSDB 内存泄露. 在 64 位的环境, LevelDB 会利用 mmap 来读取 sst 文件, 所以导致了大量虚拟内存, 而实际使用的内存 RES 只有 50M.

在 64 位的环境中, 即使几十 G 的虚拟内存也没有任何影响. 但如果你觉得看起来不好, 可以这样改进:

• 减少 leveldb::Options 的 max_open_files 参数, 这样 LevelDB 用 mmap 打开的文件就减少了
• 提供自己定制的 Env, NewRandomAccessFile() 不使用 mmap
• 改成 32 位环境

SSDB 现在已经支持 Java 语言了! 先看一个例子:

SSDB ssdb = new SSDB("127.0.0.1", 8888);
ssdb.set("a", "123");
byte[] val = ssdb.get("a");

SSDB Java 的 API 和 PHP, Cpy, Python 等动态脚本语言的 API 有很大不同, 首先 SSDB Java 用异常展示出错, 用 null 或者 Double.NaN 表示 not_found. 另外, 对于列表数据的结果, 返回的是 Response 结构.

具体使用的时候就知道了, API Doc 地址: http://www.ideawu.com/ssdb/java-doc/

SSDB(LevelDB 服务器, NoSQL 存储方案)的 zscan 是最强大的一条命令, 因为它操作的是 zset(sorted set) 数据类型, 只需要一条 zscan 命令就能直接地表达业务逻辑, "所写即所想". 例如, 获取用户的未读消息列表, 获取按上架时间排序的商品列表, 获取微博 timeline...

zset 可以理解为关系数据库里具有两个字段的表, 一个字段是 key, UNIQUE 索引, 也即数据的唯一标识; 另一个字段是浮点型 score, 每一个 key 对应的排序权重值. 在关系数据库中, 要分页遍历数据, 就要执行类似的一条 SQL 查询:

select * from table order by score, key limit start, size

Continue reading »