redis的一些优化

之前记录在公司内部的wiki上的,现在把这些经验分享出来,当然这些优化,都已经在框架的底层做掉了,使用框架时,并不需要特别在意

hset/hsetnx和hmset的性能差别

在注册用户的时候,之前我们大量使用hsetnx,可以保证用户数据的唯一性,防止多次写入

但经过测试,这种方式,相比hmset性能差别巨大,所以采取了下面的方式



存储数据,某些情况采用ziplist节省空间

在做游戏时,我们大量使用redis的hash结构,但这种结构,虽然叫做hash,但当hash-max-ziplist-entries 512实用这个配置,数据key < 512条时,实际用的是ziplist,一种用binary做链表连接标识的压缩链表,为了节省存储空间,毕竟hash结构要记录的信息太多,空间换时间

在优化之前,我们的一个普通的角色信息,是类似这样存储的

Key role:96

Field 96

Value [96,96,0,10,1,100]

一个role:96里只有一个field(96),这样实际上非常浪费空间,用一个完整的ziplist结构描述,但只存储一个key

所以进行了优化,例如role:0这个key,存储了512个field,进行了这样的拆分后,即不会触发阀值,将存储结构变为真正的hash table,也充分利用了ziplist的结构描述,大大节省了空间

一个简单的配置:

$config['redis_cut_single_table'] = 512;

hIncrBy使用方法优化

在我们一次请求,比如用户道具的插入,这种时候,一次会需要生成很多的新id,这种情况,这个优化就非常关键了

减少hIncrBy方法的调用次数,采用php内部预生成分配的办法,批量插入的时候将大量提升