Redis 的key 设计原则-设计的好有助于提升效率

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/xingyue0422/article/details/88837790

             Redis是一款基于内存式的key-value的NO-SQL数据库。可以作为数据库、缓存服务或消息服务使等。支持丰富的数据类型。比如: 字符串、哈希表、链表、集合、有序集合、位图、Hyperloglogs等
        Redis具备LRU淘汰、事务实现、以及不同级别的硬盘持久化等能力,并且支持副本集和通过Redis Sentinel实现的高可用方案,同时还支持通过Redis Cluster实现的数据自动分片能力。
Redis的主要功能都基于单线程模型实现,也就是说Redis使用一个线程来服务所有的客户端请求,
同时Redis采用了非阻塞式IO,并精细地优化各种命令的算法时间复杂度,这些信息意味着:
Redis是线程安全的(因为只有一个线程),其所有操作都是原子的,不会因并发产生数据异

Redis的速度非常快(因为使用非阻塞式IO,且大部分命令的算法时间复杂度都是O(1))
使用高耗时的Redis命令是很危险的,会占用唯一的一个线程的大量处理时间,导致所有的请
求都被拖慢。(例如时间复杂度为O(N)的KEYS命令,严格禁止在生产环境中使用)

 关于Key的一些注意事项:
不要使用过长的Key。例如使用一个1024字节的key就不是一个好主意,不仅会消耗更多的内存,还
会导致查找的效率降低
Key短到缺失了可读性也是不好的,例如”u1000flw”比起”user:1000:followers”来说,节省了
寥寥的存储空间,却引发了可读性和可维护性上的麻烦
最好使用统一的规范来设计Key,比如”object-type:id:attr”,以这一规范设计出的Key可能
是”user:1000”或”comment:1234:reply-to”
Redis允许的最大Key长度是512MB(对Value的长度限制也是512MB)

Redis没有Int、Float、Boolean等数据类型的概念,所有的基本类型在Redis中都以String体现。

与String相关的常用命令:
SET:为一个key设置value,可以配合EX/PX参数指定key的有效期,通过NX/XX参数针对
key是否存在的情况进行区别操作,时间复杂度O(1)
GET:获取某个key对应的value,时间复杂度O(1)
GETSET:为一个key设置value,并返回该key的原value,时间复杂度O(1)
MSET:为多个key设置value,时间复杂度O(N)
MSETNX:同MSET,如果指定的key中有任意一个已存在,则不进行任何操作,时间复杂度
O(N)
MGET:获取多个key对应的value,时间复杂度O(N)

Redis的基本数据类型只有String,但Redis可以把String作为整型或浮点型数字来使
用,主要体现在INCR、DECR类的命令上:
INCR:将key对应的value值自增1,并返回自增后的值。只对可以转换为整型的String数据起
作用。时间复杂度O(1)
INCRBY:将key对应的value值自增指定的整型数值,并返回自增后的值。只对可以转换为整
型的String数据起作用。时间复杂度O(1)
DECR/DECRBY:同INCR/INCRBY,自增改为自减。

INCR/DECR系列命令要求操作的value类型为String,并可以转换为64位带符号的整型数字,否则
会返回错误。
也就是说,进行INCR/DECR系列命令的value,必须在[-2^63 ~ 2^63 - 1]范围内。
前文提到过,Redis采用单线程模型,天然是线程安全的,这使得INCR/DECR命令可以非常便利的
实现高并发场景下的精确控制。

猜你喜欢

转载自blog.csdn.net/xingyue0422/article/details/88837790