摘要:之前记录在公司内部的上的现在把这些经验分享出来当然这些优化都已经在框架的底层做掉了使用框架时并不需要特别在意和的性能差别在注册用户的时候之前我们大量使用可以保证用户数据的唯一性防止多次写入但经过测试这种方式相比性能差别巨大所以采取了下面的方
之前记录在公司内部的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内部预生成分配的办法,批量插入的时候将大量提升
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/20933.html
摘要:优化的一些建议尽量使用短的当然在精简的同时,不要完了的见名知意。的开发者向的开发者之一询问优化方案,得到的回复是使用结构。所以内存分配策略应该设置为表示内核允许分配所有的物理内存,而不管当前的内存状态如何。 优化的一些建议 1、尽量使用短的key 当然在精简的同时,不要完了key的见名知意。对于value有些也可精简,比如性别使用0、1。 2、避免使用keys * keys *, 这个...
阅读 3132·2021-11-10 11:35
阅读 1279·2019-08-30 13:20
阅读 1096·2019-08-29 16:18
阅读 2099·2019-08-26 13:54
阅读 2127·2019-08-26 13:50
阅读 939·2019-08-26 13:39
阅读 2453·2019-08-26 12:08
阅读 1936·2019-08-26 10:37