分类: C/C++
Redis作为一个高性能的内存数据库,在实际应用中可以很好的解决cache,数据共享等问题。但客户端采用hiredis的时候,需要注意几点:
1.对于block方式的操作:在block操作模式下,每个命令都是单独发向Redis的,且也会等待每个的结果返回。即,通过redisCommand调用,即完成了向Redis发送命令,也等待Redis返回结果。换言之,是一个阻塞的过程。如果在是并发量比较高的情况下,此种方式,会使得客户端效率较差。即便是将Redis部署在本地,通过local进行访问,也会有0.02毫秒级别的等待过程。如果客户端有很多次的访问操作,每次都会阻塞一小段时间,会使得客户端本身的处理速度降下来。为了降低这种开销,可以采用pipeline的方式。也即一次向Redis发送多个命令。将这多个命令发送完毕后,再进行统一处理。当然,这样的代价是客户端的发送缓冲区会变大,接收缓冲区也会变大。但处理的吞吐量会增加。
2.对于non-block方式的操作:在这种模式下,默认的调用redisCommand就会立即返回,相当于block模式下显式的调用AppendCommand。不过在这种模式下,要显示的调用获取回应的replay,然后将reply释放掉,以免造成内存泄漏。
上面说的,都是同步的操作过程。操作过程和客户端的程序是在一个进程里完成的。另外还可以采用异步的方式。
---------
hiredis是redis的官方C API,但是不得不说API的使用很坑爹。
void *redisCommand(redisContext *c, const char *format, ...)
貌似很牛逼的样子,提供了类似printf的可变参数机制。但这也正是本次爹被坑的地方。
string cmd = "GET 100%坑爹的redisCommand ";
并调用redisCommand如下:
redisCommand(c, cmd.c_str());
通过查询hiredis的代码发现,redisCommand会调用它自己实现的一个坑爹的redisvFormatCommand函数:
int redisvFormatCommand(char **target, const char *format, va_list ap)
该函数实现中,当发现%的时候,会检查%后一个字符的合法性,如果不合法,就直接报错!
string cmd = "GET 100%坑爹的redisCommand ";
redisCommand(c, "%s", cmd.c_str());
嗯嗯,貌似好使了?错!从redis server 返回的结果为 “unknown command GET 100%坑爹的redisCommand”。。。怎么也看不出来这条命令哪里错误了,好吧,老老实实的按照hiredis的demo代码来写:
string key = "100%坑爹的redisCommand ";
redisCommand(c, "GET %s", key.c_str());