背景:
当时我们正在做一个游戏项目,游戏项目相比于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