qiye / redis-storage Goto Github PK

[5367] 01 Apr 05:31:05.143 # Warning: no config file specified, using the default config. In order to specify a config file use /usr/local/redis-storage/bin/redis-server /path/to/redis.conf
[5367] 01 Apr 05:31:05.151 # Warning: 32 bit instance detected but no memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now.
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid

问一下这是什么问题呢？？

del在删除字符串类型key的时候没有问题，但是删除hash类型key的时候，无法删除。
原因是：
hash键值存储在leveldb的形式是:

• \xFF\x01[key]\x01 1
• \xFF\x01[key]\x01[field] value
  ds_delete和rl_delet实现中，没有区分key的类型，均是根据key直接删除，对于hash值的删除肯定不成功。
  觉得hash类型key的删除可以借鉴ds_hgetall方法。

期待回复，谢谢

没看到相关说明，可否针对key设置ttl，过期后key和value都会自动清理掉？

1. 修复 ds_exists ds_hexists 结果完全不靠谱的问题
2. 修复 ds_hgetall 调用多次后导致redis-storage崩溃的问题
3. 统一了ds_del / ds_h** 系列函数的返回值，至少类型跟redis一致

坑爹啊，GFM怎么贴patch呢？
整个base64编码了 -_-

cat ds.c.diff |b64encode -
begin-base64 644 -
ZGlmZiAtLWdpdCBhL3NyYy9kcy5jIGIvc3JjL2RzLmMKaW5kZXggYzRjZWRlZi4uODMwMWU2NSAx
MDA2NDQKLS0tIGEvc3JjL2RzLmMKKysrIGIvc3JjL2RzLmMKQEAgLTkxLDE1ICs5MSwyMyBAQCB2
b2lkIGRzX2V4aXN0cyhyZWRpc0NsaWVudCAqYykKICAgICBpbnQgICAgICAgICAgICAgICAgICAg
aTsKICAgICBjaGFyICAgICAgICAgICAgICAgICAgKmVycjsKICAgICBsZXZlbGRiX2l0ZXJhdG9y
X3QgICAgKml0ZXI7CisJY2hhciAqa3A7c2l6ZV90IGtsOwogICAgIAogICAgIGl0ZXIgICAgID0g
bGV2ZWxkYl9jcmVhdGVfaXRlcmF0b3Ioc2VydmVyLmRzX2RiLCBzZXJ2ZXIucm9wdGlvbnMpOwog
ICAgIGFkZFJlcGx5TXVsdGlCdWxrTGVuKGMsIGMtPmFyZ2MtMSk7CiAJZm9yKGk9MTsgaTxjLT5h
cmdjOyBpKyspCiAJewogICAgICAgICBsZXZlbGRiX2l0ZXJfc2VlayhpdGVyLCBjLT5hcmd2W2ld
LT5wdHIsIHNkc2xlbigoc2RzKWMtPmFyZ3ZbaV0tPnB0cikpOwotICAgICAgICBpZihsZXZlbGRi
X2l0ZXJfdmFsaWQoaXRlcikpCi0gICAgICAgICAgICBhZGRSZXBseUxvbmdMb25nKGMsIDEpOwot
ICAgICAgICBlbHNlCisgICAgICAgIGlmKGxldmVsZGJfaXRlcl92YWxpZChpdGVyKSl7CisJCSAg
CisJCSAga3AgPSBsZXZlbGRiX2l0ZXJfa2V5KGl0ZXIsJmtsKTsKKworCQkgIGlmKCBzZHNsZW4o
KHNkcyljLT5hcmd2W2ldLT5wdHIpID09IGtsICYmIDAgPT0gbWVtY21wKGMtPmFyZ3ZbaV0tPnB0
cixrcCxrbCkpCisJCQlhZGRSZXBseUxvbmdMb25nKGMsMSk7CisJCSAgZWxzZQorCQkJYWRkUmVw
bHlMb25nTG9uZyhjLDApOworCQkgIAorICAgICAgICB9ZWxzZQogICAgICAgICAgICAgYWRkUmVw
bHlMb25nTG9uZyhjLCAwKTsKIAl9CiAgICAgCkBAIC0xMjQsNiArMTMyLDcgQEAgdm9pZCBkc19o
ZXhpc3RzKHJlZGlzQ2xpZW50ICpjKQogICAgIHNkcyAgICAgICAgICAgICAgICAgICBrZXk7CiAg
ICAgY2hhciAgICAgICAgICAgICAgICAgICplcnI7CiAgICAgbGV2ZWxkYl9pdGVyYXRvcl90ICAg
ICppdGVyOworCWNoYXIgKmtwO3NpemVfdCBrbDsKICAgICAKICAgICBrZXkgICAgICA9IHNkc2Vt
cHR5KCk7CiAgICAgaXRlciAgICAgPSBsZXZlbGRiX2NyZWF0ZV9pdGVyYXRvcihzZXJ2ZXIuZHNf
ZGIsIHNlcnZlci5yb3B0aW9ucyk7CkBAIC0xMzYsOSArMTQ1LDE1IEBAIHZvaWQgZHNfaGV4aXN0
cyhyZWRpc0NsaWVudCAqYykKICAgICAgICAga2V5ICAgICAgPSBzZHNjYXQoa2V5LCBjLT5hcmd2
W2ldLT5wdHIpOwogICAgICAgICAKICAgICAgICAgbGV2ZWxkYl9pdGVyX3NlZWsoaXRlciwga2V5
LCBzZHNsZW4oa2V5KSk7Ci0gICAgICAgIGlmKGxldmVsZGJfaXRlcl92YWxpZChpdGVyKSkKLSAg
ICAgICAgICAgIGFkZFJlcGx5TG9uZ0xvbmcoYywgMSk7Ci0gICAgICAgIGVsc2UKKyAgICAgICAg
aWYobGV2ZWxkYl9pdGVyX3ZhbGlkKGl0ZXIpKXsKKwkJCWtwID0gbGV2ZWxkYl9pdGVyX2tleShp
dGVyLCZrbCk7CisKKwkJCWlmKCBzZHNsZW4oa2V5KSA9PSBrbCAmJiAwID09IG1lbWNtcChrZXks
a3Asa2wpKQorCQkJICBhZGRSZXBseUxvbmdMb25nKGMsMSk7CisJCQllbHNlCisJCQkgIGFkZFJl
cGx5TG9uZ0xvbmcoYywwKTsKKwkJCQorICAgICAgICB9ZWxzZQogICAgICAgICAgICAgYWRkUmVw
bHlMb25nTG9uZyhjLCAwKTsKIAl9CiAgICAgCkBAIC01MzMsNyArNTQ4LDEwIEBAIHZvaWQgZHNf
aHNldChyZWRpc0NsaWVudCAqYykKIAlsZXZlbGRiX3dyaXRlYmF0Y2hfZGVzdHJveSh3Yik7CiAg
ICAgc2RzZnJlZShzdHIpOwogICAgIAotICAgIGFkZFJlcGx5KGMsc2hhcmVkLm9rKTsKKyAgICAv
L2FkZFJlcGx5KGMsc2hhcmVkLm9rKTsKKwkvLyBrZWVwIHRoZSBzYW1lIHJldHVybiB0eXBlIGFz
IHJlZGlzJ3MgaHNldAorCS8vIFRPRE86IGhvdyB0byBkaXN0aW5ndWlzaCB0aGUgY3JlYXRlKHJl
dHVybiAxKSBhbmQgdXBkYXRlKHJldHVybiAwKSA/CisgICAgYWRkUmVwbHlMb25nTG9uZyhjLDEp
OwogICAgIHJldHVybiA7CiB9CiAKQEAgLTU1NSwyMCArNTczLDQxIEBAIHZvaWQgZHNfaGdldGFs
bChyZWRpc0NsaWVudCAqYykKICAgICBsZW4gICAgID0gc2RzbGVuKHN0cik7CiAgICAga2V5d29y
ZCA9IHptYWxsb2MobGVuKzEpOwogICAgIG1lbWNweShrZXl3b3JkLCBzdHIsIGxlbik7Ci0gICAg
CisKKwlrZXl3b3JkW2xlbl0gPSAnXDAnOworCQogICAgIHNkc2NsZWFyKHN0cik7CiAgICAgaXRl
ciA9IGxldmVsZGJfY3JlYXRlX2l0ZXJhdG9yKHNlcnZlci5kc19kYiwgc2VydmVyLnJvcHRpb25z
KTsKLSAgICBmb3IobGV2ZWxkYl9pdGVyX3NlZWsoaXRlciwga2V5d29yZCwgbGVuKTsgbGV2ZWxk
Yl9pdGVyX3ZhbGlkKGl0ZXIpOyBsZXZlbGRiX2l0ZXJfbmV4dChpdGVyKSkKKyAgICBmb3IobGV2
ZWxkYl9pdGVyX3NlZWsoaXRlciwga2V5d29yZCwgbGVuKTtsZXZlbGRiX2l0ZXJfdmFsaWQoaXRl
cik7IGxldmVsZGJfaXRlcl9uZXh0KGl0ZXIpKQogICAgIHsKICAgICAgICAgCiAgICAgICAgIGtl
eV9sZW4gPSB2YWx1ZV9sZW4gPSAwOwogICAgICAgICBrZXkgICA9IGxldmVsZGJfaXRlcl9rZXko
aXRlciwgJmtleV9sZW4pOwotICAgICAgICB2YWx1ZSA9IGxldmVsZGJfaXRlcl92YWx1ZShpdGVy
LCAmdmFsdWVfbGVuKTsKLSAgICAgICAgCi0gICAgICAgIGlmKGtleV9sZW4gPT0gbGVuKQotICAg
ICAgICAgICAgY29udGludWU7Ci0gICAgICAgIGVsc2UgaWYoc3RybmNtcChrZXl3b3JkLCBrZXks
IGxlbikgIT0gMCkKKwkJCisJCS8vIElNUE9SVEFOVDoKKwkJLy8gbGV2ZWxkYl9pdGVyX3ZhbGlk
KGl0ZXIpIG1lYW5zIHRoZSBjdXJyZW50IGtleSA+PSB3aGF0IHdlIHdhbnQKKwkJLy8gZm9yIGV4
YW1wbGU6ICBzZWVrICJ0aGVrZXkqIiAKKwkJLy8gICAgICAgICAgICAgICB0aGVrZXkqICBpcyB2
YWxpZAorCQkvLyAgICAgICAgICAgICAgIHRoZWtleSoxIGlzIHZhbGlkCisJCS8vICAgICAgICAg
ICAgICAgdGhla2V6KiAgaXMgKkFMU08gVkFMSUQqICd6Jz4neScKKwkJLy8gdGhlIGNvZGU6CisJ
CS8vICAgICAgICAgaWYoa2V5X2xlbiA9PSBsZW4pCisJCS8vICAgICAgICAgICAgIGNvbnRpbnVl
OworCQkvLyAgICAgICAgIGVsc2UgaWYoc3RybmNtcChrZXl3b3JkLCBrZXksIGxlbikgIT0gMCkK
KwkJLy8gICAgICAgICAgICAgYnJlYWs7CisJCS8vICBpcyBvaywgYnV0IHdpbGwgZG8gbG90J3Mg
b2YgdXNlbGVzcyBsb29wIGluIHN1Y2ggY29uZGl0aW9uOgorCQkvLyAgZHNfaGdldGFsbCAiYSIg
LCBhbmQgdGhlcmUncyBubyBhKiBpbiBsZXZlbGRiICxhbmQgbG90J3Mgb2YgYjEgYjIgLi4uIGJO
IGluIGxldmVsZGIgOiggCisKKwkJLy8gbWFrZSBzdXJlIHRoZSBoYXNodGFibGUgaXMgdGhlIHNh
bWUKKyAgICAgICAgaWYoc3RybmNtcChrZXl3b3JkLCBrZXksIGxlbikgIT0gMCkKICAgICAgICAg
ICAgIGJyZWFrOworCisJCS8vIHNraXAgdGhlIGhhc2h0YWJsZSBpdHNlbGYKKwkJaWYoa2V5X2xl
biA9PSBsZW4pCisgICAgICAgICAgICBjb250aW51ZTsKKworCQkvLyBub3csIGtleSBpcyB2YWxp
ZCBhbmQgZ2V0IHZhbHVlIGhlcmUKKyAgICAgICAgdmFsdWUgPSBsZXZlbGRiX2l0ZXJfdmFsdWUo
aXRlciwgJnZhbHVlX2xlbik7CiAgICAgICAgIAogICAgICAgICBzdHIgPSBzZHNjYXRwcmludGYo
c3RyLCAiJCV6dVxyXG4iLCAoa2V5X2xlbi1sZW4pKTsKICAgICAgICAgc3RyID0gc2RzY2F0bGVu
KHN0ciwga2V5K2xlbiwga2V5X2xlbi1sZW4pOwpAQCAtNTk0LDExICs2MzMsMTkgQEAgdm9pZCBk
c19oZ2V0YWxsKHJlZGlzQ2xpZW50ICpjKQogICAgIH0KICAgICBlbHNlCiAgICAgeyAgIAorCSAg
CiAgICAgICAgIGhlYWRlciA9IHNkc2VtcHR5KCk7CiAgICAgICAgIGhlYWRlciA9IHNkc2NhdHBy
aW50ZihoZWFkZXIsICIqJXp1XHJcbiIsIChpKjIpKTsKICAgICAgICAgaGVhZGVyID0gc2RzY2F0
bGVuKGhlYWRlciwgc3RyLCBzZHNsZW4oc3RyKSk7CiAgICAgICAgIGFkZFJlcGx5U2RzKGMsIGhl
YWRlcik7Ci0gICAgICAgIHNkc2ZyZWUoaGVhZGVyKTsKKworICAgICAgICAvL3Nkc2ZyZWUoaGVh
ZGVyKTsKKworCQkvLyBJTVBPUlRBTlQ6CisJCS8vIGFkZFJlcGx5U2RzKGMscHRyKSB3aWxsIGNh
bGwgc2RzZnJlZShwdHIpIGJlZm9yZSByZXR1cm5lZC4KKwkJLy8gRE8gTk9UIGNhbGwgc2RzZnJl
ZShoZWFkZXIpIGhlcmUgISEhIQorCQkvLyDltKnmuoPkuobml6DmlbDmrKHvvIzlnZHniLnnmoRn
ZGLmiorpl67popjlrprkvY3lnKhsZXZlbGRiX2l0ZXJfc2Vlaygp5LiK77yMCisJCS8vIOS4q+mX
rumimOWxheeEtuWcqOi/memHjC4uLi4KICAgICB9CiAgICAgCiAgICAgc2RzZnJlZShzdHIpOwpA
QCAtNjYxLDcgKzcwOCwxMCBAQCB2b2lkIGRzX2hkZWwocmVkaXNDbGllbnQgKmMpCiAgICAgCQlh
ZGRSZXBseUVycm9yKGMsIGVycik7CiAgICAgCQlsZXZlbGRiX2ZyZWUoZXJyKTsKICAgICAgICAg
fQotICAgICAgICAKKyAgICAgCisJCS8vIE5vIHdheSB0byBrZWVwIHRoZSBzYW1lIHJldHVybiB0
eXBlIGFzIHJlZGlzJ3MgSERFTAorCQkvLyBIREVMIG5lZWRzIGF0IGxlYXN0IDIgYXJndW1lbnRz
CisJCS8vIHNvLC4uLiBzZW5kICJPSyIKICAgICAgICAgYWRkUmVwbHkoYyxzaGFyZWQub2spOwog
CX0KIAkKQEAgLTY4Nyw3ICs3MzcsMTIgQEAgdm9pZCBkc19oZGVsKHJlZGlzQ2xpZW50ICpjKQog
CQlsZXZlbGRiX2ZyZWUoZXJyKTsKIAkJcmV0dXJuIDsKIAl9Ci0JYWRkUmVwbHkoYyxzaGFyZWQu
b2spOworCisJLy8ga2VlcCB0aGUgc2FtZSByZXR1cm4gdHlwZSBhcyByZWRpcydzIEhERUwKKwkv
LyBSZXR1cm4gdmFsdWUKKwkvLyAgSW50ZWdlciByZXBseTogdGhlIG51bWJlciBvZiBmaWVsZHMg
dGhhdCB3ZXJlIHJlbW92ZWQgZnJvbSB0aGUgaGFzaCwgbm90IGluY2x1ZGluZyBzcGVjaWZpZWQg
YnV0IG5vbiBleGlzdGluZyBmaWVsZHMuCisJLy8gVE9ETzogY291bnQgdGhlIGRlbGV0ZSBvcGVy
YXRpb24KKwlhZGRSZXBseUxvbmdMb25nKGMsYy0+YXJnYy0yKTsKIAogICAgIHJldHVybiA7CiB9
CkBAIC04NzcsNyArOTMyLDkgQEAgdm9pZCBkc19kZWxldGUocmVkaXNDbGllbnQgKmMpCiAJCQls
ZXZlbGRiX2ZyZWUoZXJyKTsKIAkJCXJldHVybiA7CiAJCX0KLQkJYWRkUmVwbHkoYyxzaGFyZWQu
b2spOworCQkvL2FkZFJlcGx5KGMsc2hhcmVkLm9rKTsKKwkJLy8ga2VlcCB0aGUgc2FtZSByZXR1
cm4gdHlwZSBhcyByZWRpcydzIGRlbAorCQlhZGRSZXBseUxvbmdMb25nKGMsMSk7CiAJCXJldHVy
biA7CiAJfQogCQpAQCAtODk3LDcgKzk1NCwxMSBAQCB2b2lkIGRzX2RlbGV0ZShyZWRpc0NsaWVu
dCAqYykKIAkJbGV2ZWxkYl9mcmVlKGVycik7CiAJCXJldHVybiA7CiAJfQotCWFkZFJlcGx5KGMs
c2hhcmVkLm9rKTsKKwkvL2FkZFJlcGx5KGMsc2hhcmVkLm9rKTsKKwkvLyBrZWVwIHRoZSBzYW1l
IHJldHVybiB0eXBlIGFzIHJlZGlzJ3MgZGVsCisJLy8gVE9ETzogIGNvdW50IHRoZSBkZWxldGUg
b3BlcmF0aW9uCisJLy8gIEkgZG9uJ3Qga25vdyBob3cgdG8gY291bnQgdGhlIGRlbGV0ZSBvcGVy
YXRpb24sIHVzZSBhcmdjLTEgaW5zdGFuZC4KKwlhZGRSZXBseUxvbmdMb25nKGMsYy0+YXJnYy0x
KTsKIAogICAgIHJldHVybiA7CiB9Cg==
====

因为习惯统一安装目录/usr/local/app,最后编译redis-storage出现错误

/usr/bin/ld: cannot find -lleveldb
collect2: ld returned 1 exit status
make[1]: *** [redis-server] Error 1

mkdir -p ~/src; cd ~/src
wget -c http://gperftools.googlecode.com/files/gperftools-2.0.tar.gz -O -|tar xz
cd gperftools-2.0/
./configure --prefix=/usr/local/gperftools
make && make install
echo "/usr/local/gperftools/lib" >> /etc/ld.so.conf.d/usr_local_lib.conf
/sbin/ldconfig
mkdir -p /tmp/tcmalloc
chmod 0777 /tmp/tcmalloc
cd ../

wget -c https://snappy.googlecode.com/files/snappy-1.0.5.tar.gz -O -|tar xz
cd snappy-1.0.5/
./configure --prefix=/usr/local/snappy
make && make install
echo "/usr/local/snappy/lib" >> /etc/ld.so.conf.d/usr_local_lib.conf
/sbin/ldconfig
cd ../

wget -c https://leveldb.googlecode.com/files/leveldb-1.8.0.tar.gz -O -|tar xz
cd leveldb-1.8.0/
make
\cp -rf ../leveldb-1.8.0 /usr/local/leveldb
echo "/usr/local/leveldb" >> /etc/ld.so.conf.d/usr_local_lib.conf
/sbin/ldconfig
cd ../

wget -c --no-check-certificate https://github.com/qiye/redis-storage/tarball/master -O -|tar xz && mv -f qiye-redis-storage* redis-storage
cd redis-storage/
cd deps/; make hiredis lua linenoise
cd ../
make MALLOC=tcmalloc
make install PREFIX=/usr/local/redis

make init时出现错误

make: ldconfig：命令未找到

不是root用户，sudo进行编译时出现，使用root不会出现。

如果我手动去更新 deps 目录下的 leveldb-1.10.0 to leveldb-1.15.0 会不会有问题？
例如我删除 leveldb-1.10.0 目录下的所有文件，再把 1.15.0 的移入.
再编译 leveldb 那么会不会影响到原来的函数调用？

请问这个实现是把redis原来放在内存的数据通过leveldb放在硬盘这样子吗？然后一切操作都跟原生的redis一样？还是说只有加强版的那些命令存取的数据是通过leveldb引擎存放，其他的还是原生redis一样放在内存？

平台为Ubuntu 12.04 x64

严格按说明安装的：

在做到
make MALLOC=tcmalloc_minimal
时，报如下错误：

/usr/bin/ld: ../deps/gperftools-2.0/.libs/libtcmalloc_minimal.a(libtcmalloc_minimal_internal_la-malloc_extension.o): undefined reference to symbol 'std::basic_string<char, std::char_traits, std::allocator >::_Rep::_M_destroy(std::allocator const&)@@GLIBCXX_3.4'
/usr/bin/ld: note: 'std::basic_string<char, std::char_traits, std::allocator >::_Rep::_M_destroy(std::allocator const&)@@GLIBCXX_3.4' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so: could not read symbols: Invalid operation
collect2: ld 返回 1
make[1]: *** [redis-server] 错误 1
make[1]:正在离开目录 `/home/xen/Packages/redis-storage/redis-storage-master/src'
make: *** [all] 错误 2

麻烦检查下是需要在哪里加-fPIC呢？

项目很不错,redis+leveldb仍是强者组合.

不知道写在哪里，只好先写在issue里面了

首先leveldb的核心是
1）key->value，以及
2）基于key的排序

最近在实现key遍历的时候发现之前的ds_h**系列功能key的组织方式不太完善。

目前ds_h* 功能的实现方式是 用key_field 这样的方式存储在leveldb中的，(暂且叫hashkey)
这样在进行普通key遍历的时候，会碰到key_field这样的hashkey，需要跳过，反过来，在进行hashkey遍历的时候也会碰到普通的key，需要跳过。

以后要实现的set(集合)或者zset功能，本质上也只能利用leveldb的2个特性，必然也要设计和维护一组内部存储用的zsetkey

普通key,hashkey,zsetkey,... 在leveldb看来都是同等的，处于一个统一的排序状态下，而zset的某些功能必然少不了key遍历。

我的设想是，能不能在hashkey和以后的zsetkey之前带上特殊前缀，
比如 hashkey前面都带* zsetkey前面都带# ，以便让这几组不同功能的key处于各自连续的排序状态下。

主要目的还是为了在大规模数据下有更好的性能表现。

以上请项目负责人定夺，趁现在ds_h* 相关功能使用人数还不多的时候尽早规划好。

xen@T410s:~/Packages/redis-storage/redis-storage-master/src$ sudo ./redis-server
[25574] 19 Jan 16:39:35.880 # Warning: no config file specified, using the default config. In order to specify a config file use ./redis-server /path/to/redis.conf
[25574] 19 Jan 16:39:35.881 * Max number of open files set to 10032
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
已放弃 (核心已转储)

ds_set mykey "Hello"
ds_append mykey " World"
ds_get mykey

返回的不应该是Hellomykey，而应该是Hello World
另外ds_append返回的不应该是OK，而应该是被append后总长度

差点被坑爹了

升级新版后发现 ds_mget结果格式变了

$ret = phpiredis_command_bs($redis,array('ds_mget','key1','key2'));

原来版本中返回queryString形式的结果 key1=value1&key2=value2

现在变成 array(0=>value1,1=>value2)

不知道是 redis-storage的变化还是 phpiredis的变化，估计是前者

变得好，这样很好，但是最好有个变更说明啥的 :)

大家可能奇怪 没有ds_update这个功能。其实用ds_set也是一样的
ds_set name redis
ds_set name qiye
ds_get name

获取的是 qiye

void ds_mget(redisClient *c) 中
需要把 这行注释掉
// sdsfree(str);

另外linenoise 没有依赖进去，需要先进去make 一下

还有 有些系统上 修改src/Makefile 加上 -lstdc++ -lm

ifeq ($(MALLOC),tcmalloc_minimal)
FINAL_CFLAGS+= -DUSE_TCMALLOC
FINAL_LIBS+= ../deps/gperftools-2.0/.libs/libtcmalloc_minimal.a -ldl -lstdc++ -lm
endif

... 不会用

按如下命令循环测试几次就会发现问题：

rl_set mykey "Hello"
rl_get mykey
get mykey
ds_get mykey
rl_del mykey
get mykey
ds_get mykey

另外ds_del返回的不应该是OK，而应该是被成功删除key数目

https://github.com/shuxiang/redis-py

拿redis-py来稍微改改就有了，虽然没什么技术难度，氮素，勿以善小而不为

RT.

http://198.74.110.195/t2
https://gist.github.com/ed560f14576810718c3d

暂时取消了ds_keys_asc ds_keys_desc 命令测试 :)

目前我们在找个 redis + leveldb一起的 发现楼主的这个 项目
但是我看 很久没更新了 问下 是否还在维护
如果 继续维护 是否能支持 redis3 谢谢！！！