Redis 的key 设计原则
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命令可以非常便利的
实现高并发场景下的精确控制。
转自：https://blog.csdn.net/xingyue0422/article/details/88837790