redis-storage介绍[转]

时间:2023-12-31 18:56:38

背景

当时我们正在做一个游戏项目,游戏项目相比于web项目,更追求的是单机的性能,而我们对单个请求的处理时间有着bt级的需求(一个完整的api请求控制在10ms以内)。当时我们的数据层用的是ttserver,但他在我们之前项目中有一些比较不好处理的问题,所以我一直在寻找的替代方向,而这时redis的横空出世,给nosql世界带来了不小的震动,相比于memcache, 丰富的数据结构,给了很多人更换cache层的理由,而数据能落地,使之有成为数据库的可能。后来新浪的大面积使用,稳定性得到保障,我果断在新项目中使用了redis。

问题

redis的一些丰富结构,特别适合游戏,我们当时用的非常爽。后来游戏也顺利上线了。性能也是非常好,但运营了将近一年后,我们发现了一个致命的问题,由于我们是偏社交游戏,没有分服,所有的用户都在一个服务器上,这里面有一个矛盾了:

1)  数据在无止境的增长    (对内存的需求越来越多)

2)  活跃用户( dau )基本稳定了  (热数据占比较小20%以内)

思考:

问题的根源在于redis提供的两种持久化机制,都只是起到备份作用,所有的数据都必需在内存中:
     1)  数据落地只是备份

2)  redis服务在重启之后,需要把备份数据一次性load回内存(数据量很大需要load时间很长)

思路:

用一个成熟的持久化的存储引擎来替代。落地的数据能直接对外提供服务。而只要保证把热数据留在内存中,冷数据在持久化的存储引擎中。这样就可以解决几个问题:

1 ) 对内存的需求基本只是热数据的需求

2 ) redis服务重启,不需要再load回内存,可以空重启

方案:

最后经过一翻寻找对比,确定了用leveldb (关于leveldb的介绍自行google), 理由:
   1) 由google开源,而且有很多成熟应用,质量可靠。

2) leveldb性能好,特别写性能,几乎和读性能一致。

3) 提供c的api,方便直接嵌入到redis中

实现 :

1) leveldb的嵌入

封装一个方法,以便redis服务初始化的时候,把leveldb引擎载入

void ds_init() {    if(!server.ds_open) {        return ;    }    char *err = NULL;
   server.ds_cache = leveldb_cache_create_lru(server.ds_lru_cache * 1048576);    server.ds_options = leveldb_options_create();
   server.policy = leveldb_filterpolicy_create_bloom(10);
   //leveldb_options_set_comparator(server.ds_options, cmp);    leveldb_options_set_filter_policy(server.ds_options, server.policy);    leveldb_options_set_create_if_missing(server.ds_options, server.ds_create_if_missing);    leveldb_options_set_error_if_exists(server.ds_options, server.ds_error_if_exists);    leveldb_options_set_cache(server.ds_options, server.ds_cache);    leveldb_options_set_info_log(server.ds_options, NULL);    leveldb_options_set_write_buffer_size(server.ds_options, server.ds_write_buffer_size * 1048576);    leveldb_options_set_paranoid_checks(server.ds_options, server.ds_paranoid_checks);    leveldb_options_set_max_open_files(server.ds_options, server.ds_max_open_files);    leveldb_options_set_block_size(server.ds_options, server.ds_block_size * 1024);    leveldb_options_set_block_restart_interval(server.ds_options, server.ds_block_restart_interval);    leveldb_options_set_compression(server.ds_options, leveldb_snappy_compression);
   server.ds_db = leveldb_open(server.ds_options, server.ds_path, &err);    if (err != NULL) {        fprintf(stderr, "%s:%d: %s\n", __FILE__, __LINE__, err);        leveldb_free(err);        exit(1);    }
   server.woptions = leveldb_writeoptions_create();    server.roptions = leveldb_readoptions_create();    leveldb_readoptions_set_verify_checksums(server.roptions, 0);    leveldb_readoptions_set_fill_cache(server.roptions, 1);
   leveldb_writeoptions_set_sync(server.woptions, 0); }

我们在redis.c里的initServer方法最后调用ds_init()即可。这样我们就可以在redis内部对leveldb进行操作了。

2) 一个简单的读取流程 (rl_get命令)

当client连上redis的时候,他的标准读取流程是:先从redis读取, 如果redis没有,则到leveldb读取。代码示例:

static void rl_getCommand(redisClient *c, int set) {    //从redis里取数据    robj *o;
   if ((o = lookupKeyRead(c->db, c->argv[1])) == NULL) {  //没有读取数据        ds_getCommand(c, set);  //从leveldb读取        checkRlTTL(c->db, c->argv[1]);        return;    }
   if (o->type == REDIS_STRING) {        addReplyBulk(c, o);        checkRlTTL(c->db, c->argv[1]);        return;    }
   addReply(c, shared.nullbulk);
}

3) 一个简单的写入流程(rl_set)

当client连上redis的时候,他的标准写入流程是:先写到leveldb中,写成功了,再写到redis中, 代码示例:

void rl_set(redisClient *c) {    if(!server.ds_open) {        addReplyError(c,"REDIS_STORAGE CLOSED");        return;    }    char *key, *value;    char *err = NULL;
   key = (char *) c->argv[1]->ptr;    value = (char *) c->argv[2]->ptr;    leveldb_put(server.ds_db, server.woptions, key, sdslen((sds) key), value, sdslen((sds) value), &err);    if (err != NULL) {   //leveldb写入失败,直接返回错误        addReplyError(c, err);        leveldb_free(err);        return;    }    //addReply(c,shared.ok);
   //存到redis    setCommand(c);    checkRlTTL(c->db, c->argv[1]); 
}

4)各种组合:

=======string数据操作======
rl_get key (从redis或leveldb取值, 优先顺序:redis > leveldb)
rl_getset key (返回同rl_get, 当leveldb有值,redis无值时,会回写到redis)
rl_mget k1 k2 k3 (取redis和leveldb的并集,优先级:redis>leveldb)
rl_mgetset k1 k2 k3 (返回同rl_mget, 当leveldb有值,redis无值,会回写到redis)
rl_set key val (往redis和leveldb写值, 优先顺序:leveldb > redis, leveldb如果失败,将中断往redis写,返回错误)
rl_mset k1 v1 k2 v2 (往redis和leveldb批量写值, 优先顺序:leveldb > redis, leveldb如果失败,将中断往redis写,返回错误)
rl_del k1 k2 k3 (往redis和leveldb删值, 优先顺序:leveldb > redis) ========hash数据操作========
rl_hget key hk (从redis或leveldb取值, 优先顺序:redis > leveldb)
rl_hgetset key hk (返回同rl_hget, 当leveldb有值,redis无值时,会回写到redis)
rl_hmget key hk1 hk2 (往redis和leveldb批量写值,优先级:redis>leveldb)
rl_hmgetset k1 k2 k3 (返回同rl_hmget, 当leveldb有值,redis无值,会回写到redis)
rl_hset key hk hv (往redis和leveldb写值, 优先顺序:leveldb > redis, leveldb如果失败,将中断往redis写,返回错误)
rl_hmset key hk1 hv1 hk2 hv2 (取redis和leveldb的并集,优先级:redis>leveldb)
rl_hdel key hk1 hk2 hk3 (往redis和leveldb删值, 优先顺序:leveldb > redis)

冷数据自动淘汰

到现在为止,还有个关键的功能没有提到,就是如果保证热数据在redis中,冷数据在leveldb中。给出的方案是:在往redis里写入数据的时候,强制设置一个过期时间  ,强制的过期时间通过全局的redis.conf里的  rl:ttl  来设置。

另一个问题:

项目到了后期,活跃用户大部分都是老用户,也就是所谓的热数据,所以新增了一个全局配置: rl:ttlcheck ,如果某个key在rl:ttlcheck 至  rl:ttl 这段时间内被读取,则把这个key自动续期一个 rl:ttl 周期。

代码示例: static void checkRlTTL(redisDb *db, robj *key) {    if(server.rl_ttl) {   //如果配置了。        if(server.rl_ttlcheck >= server.rl_ttl) {    //            return;        }        long long expire = getExpire(db,key);                                          if(expire == -1 || expire-mstime() < server.rl_ttlcheck*1000) {     //如果时间>rl:ttlcheck,则自动续期                                   expire = server.rl_ttl * 1000;                                                                                        setExpire(db, key, mstime()+expire);    //强制设置过期时间。        }    } }

示例: rl:ttl 60  rl:ttlcheck 40  代表: redis里的数据过期时间为60s,  如果一个key在创建的第40s ~ 60s 之前被读取到,则自动续期至 60s

redis-stroage 总结:

1) 可直接对外提供服务的持久化存储。

2) redis空重启

3) 冷数据自动淘汰,热数据自动续期,麻麻再也不用担心我的内存了。

4) 只做新增命令,完全兼容redis原有命令和主从机制

后记:

经过这一个改造之后,后面的几个项目都采用redis-storage做数据库,稳定使用超过一年了,在稳定性和内存的使用方便都达到了预期的效果。现项目已开源: https://github.com/shenzhe/redis-storage