idea's blog

连接 SSDB

<?php
require_once("SSDB.php");
$ssdb = new SimpleSSDB('127.0.0.1', 8888);

生成测试数据

$zname = 'test';
for($i=0; $i<1000; $i++){
    $key = "k$i";
    $score = mt_rand(0, 100);
    $ssdb->zset($zname, $key, $score);
}
$size = $ssdb->zsize($zname);
echo "total $size items\n";

这段代码生成了一个名为 zname 的 zset 集合, 里面有 1000 个元素, 某些元素的权重(score)是相同的.

Continue reading »

从 1.5.4 版本起, ssdb 提供了 leveldb-import, 用于将已有的 LevelDB 数据导入到 SSDB 中. 这个工具非常简单.

Usage:
    ./tools/leveldb-import ip port input_folder

Options:
    ip - ssdb server ip address
    port - ssdb server port number
    input_folder - local leveldb folder

Example:
    ./tools/leveldb-import 127.0.0.1 8888 ./leveldb/

为什么需要将LevelDB的数据导入到SSDB? 这是因为, LevelDB仅仅是一个存储引擎, 最直接的使用就是用编译器将这个引擎和你的C/C++代码进行链接. 如果你的需求是需要一个集中存储服务器, 可以从不同的机器上使用 PHP, Python, Java, Lua 等语言进行访问, 那么就需要SSDB了.

最新的 SSDB 1.5.0 增加了 Compaction(合并) 限速功能, 避免 LevelDB 在合并的过程中写满磁盘, 导致 SSDB 无法快速的响应请求的情况. 遇到类似问题的 SSDB 用户, 建议你立即升级. 如果你升级之后仍然使用原有的 ssdb.conf 配置文件, 请在 leveldb 一节配置中加入下面一行:

	compaction_speed: 100

注意缩进. 这表示限速为 100MB/s, 你可以根据你的磁盘性能调整这个数值.

事实上, 所有使用了 Log-Structured Merge-Tree(LSM-tree) 类似结构的存储服务器, 都可能出现合并过程写满 IO 的问题, 包括 Redis, LevelDB, Cassandra 等. 我不清楚这些软件为什么不加入合并限速功能, 也许是偷懒. 但是, 如果没有合并限速功能, 这些软件的可用性堪忧, 因为它们会出现不确定的几乎无法响应的情况. 我们就曾经忍受了 Redis 合并带来的业务频繁报警, 最后不得不禁用其自动合并功能, 改为在凌晨手动(crontab)触发合并.

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

SSDB 项目地址: https://github.com/ideawu/ssdb

我写了一个简单的循环程序往 LevelDB 写数据进行测试, 发现偶尔会出现停顿的情况, 单个写操作可能会耗时超过1秒. 这种慢请求是非常致命的, 因为在高并发的 Web 应用中, 1秒钟影响到的用户是成百上千个.

经过分析, 发现 LevelDB 实现了写限速机制, 当 Level-0 的 sst 文件数超过一定数量时开始限速, 再超过一定数量时, 直接主动的阻塞写操作, 直到 Compaction 线程减少了 Level-0 的 sst 文件数量减少到阀值以下.

Continue reading »

经过半个用的开发和测试, SSDB 发布了新版本 1.4.0. 这个版本最大的改进是重新设计了主从同步机制, 数据同步更安全, 另外还支持双主(多主)同步模式. 目前, 单主模式的主从同步功能是稳定的, 而双主(多主)模式从 experiment 升级到 beta 阶段.

此次的更新包括:

• 主从同步机制重新设计, 双主(多主)模式进入 beta 阶段
• info 命令返回更多的统计信息, 包括每个命令的请求次数和消耗时间和等待时间
• 升级为 LevelDB 1.9.0

此次升级还探索了多线程处理模型, 将写操作或者读操作分配到独立的线程池中进行处理. 但经过测试, 性能下降了20%左右, 所以多线程处理模型没有被采用. 多线程处理模型的主要延时发生在 IO 线程将请求分配给工作线程的过程, 为了对处理线程的结果进行 select, 所以采用 pipe 进行消息传递. 但 pipe 延时在 10 us(微秒)左右, 这个成本非常大.

SSDB 双主(多主)模式的使用文档: https://github.com/ideawu/ssdb/wiki/Replication#master-masterbeta

SSDB 目前已经进展到 1.3.x 版本, 在使用过程中, 程序一直非常稳定, 内存占用也很合理, 即使在一个40G数据在应用中, 内存占用也稳定在1G左右.

最近, SSDB 被应用到了一个极端的环境, 这是一个图片相关的应用, 给 SSDB 造成的压力就是:

1. 单条数据较大. 一般的应用也就几K级别的单条数据, 但图片处理一般在1M级别
2. 并发数较多, 达20K+

Continue reading »