关于rediskey命名规范的设计
本⽂为joshua317原创⽂章，转载请注明：转载⾃
⼀、实现⽬标
简洁，⾼效，可维护
⼆、键值设计规约
1 、 Redis key命名风格
【推荐】Redis key命名需具有可读性以及可管理性，不该使⽤含义不清的key以及特别长的key名；
【强制】以英⽂字母开头，命名中只能出现⼩写字母、数字、英⽂点号(.)和英⽂半⾓冒号(:)；
【强制】不要包含特殊字符，如下划线、空格、换⾏、单双引号以及其他转义字符；
2 、命名规范
【强制】命名规范：业务模块名：业务逻辑含义：其他:value类型
1 ）业务模块名：具体的功能模块
2）逻辑含义段：
【强制】不同业务逻辑含义使⽤英⽂半⾓冒号(:)分割，
【强制】同⼀业务逻辑含义段的单词之间使⽤英⽂半⾓点号 (.)分割，⽤来表⽰⼀个完整的语义
3）value类型：
【强制】Redis key命名以key所代表的value类型结尾，以提⾼可读性；
⽰例：user:basic.info:{userid}:string
3 、value 设计
【强制】：拒绝bigkey(防⽌⽹卡流量、慢查询)。
String类型控制在10KB以内，Hash、List、Set、ZSet元素个数不要超过5000。
三、业务规范
1、【强制】使⽤Redis进⾏缓存时，必须进⾏申请。申请之前，需要拿出使⽤的合理⽅案，然后进⾏评估，避免随意使⽤。
2、【强制】Redis应⽤场景应该是纯缓存服务，功能主要是缓存数据，缓存数据可丢失，除特殊需求外，需提供可⾏性、可实施的⽅案。
3、【强制】 关于过期时间
Redis key⼀定要设置过期时间。要跟⾃⼰的业务场景，需要对key设置合理的过期时间。可以在写⼊key时，就要追加过期时间；也可以在需要写⼊另⼀个key时，删除上⼀个key。
说明：
(1)若不设置的话，这些key会⼀直占⽤内存不释放，随着时间的推移会越来越⼤，直到达到服务器的内存上限，导致服务器宕机等重⼤事故；
(2)对于key的超时时长设置，可根据业务场景进⾏评估，设置合理有效期；
(3)某些业务的确需要长期有效，可以判断即将到期时，重新设置有效期，避免引起热点key问题。
4、【推荐】Redis的使⽤，应该考虑冷热数据分离，不该将所有数据全部放到Redis中，对于使⽤不频繁，且⽆关紧要的信息存⼊MySQL，或⽇志⽂件中，Redis的数据存储全部都是在内存中的，成本昂贵。
5、【推荐】Redis有数据丢失风险，程序处理数据时，应该考虑丢失后的重新加载过程。redis支持的数据结构
6、【强制】禁⽌⼤key
⼤key数据存⼊Redis，除了带来极⼤的内存占⽤外，在并发⾼时，很容易就会将⽹卡流量占满，进⽽造成整个服务器上的所有服务不可⽤。虽然Redis⽀持512MB⼤⼩的string，但是假设1mb的string⼤key，每秒重复写⼊10次，就会导致写⼊⽹络IO达10MB;
(1)读写⼤key会导致超时严重，⽹卡流量占满，甚⾄阻塞服务，更甚者导致宕机风险。
(2)如果删除⼤key，DEL命令可能阻塞Redis进程数⼗秒，使得其他请求阻塞，对应⽤程序和Redis集可⽤性造成严重的影响。
(3)每个key不要超过10Kb。
7、【强制】Redis⼀定不可使⽤Keys正则匹配操作。
8、【推荐】选择合适的数据类型。
⽬前Redis⽀持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等，需要根据业务场景选择合适的类型。
在不能确定其它复杂数据结构⼀定优于String类型时，避免使⽤Redis的复杂数据结构。 每种数据结构都有相应的使⽤场景，String类型是Redis中最简单的数据类型，建议使⽤String类型。 但是考虑到具体的业务场景，综合评估性能、存储⽹络等⽅⾯之后使⽤适当的数据结构。 需要根据业务场景选择合适的类型，常见的如：String可以⽤作普通的K-V、简单数据类类型等；Hash可以⽤作对象如居民、医⽣等，包含较多属性的信息；List可以⽤作息队列、医⽣同⾏/关注列表等；Set可以⽤于推荐；Sorted Set可以⽤于排⾏等。
9、【推荐】关于集合类操作
出现问题最多的就是超时问题，因为使⽤了O(N)的操作，导致服务超时，甚⾄服务不可⽤。
使⽤Set，Zset，List，Hash等集合类的O(N)操作时要评估当前元素个数的规模以及将来的增长规模，对于短期就可能变为⼤集合的key，要预估O(N)操作的元素数量，避免全量操作，可以使⽤HSCAN，
SSCAN，ZSCAN进⾏渐进操作。集合元素数量过⼤在使⽤过程中会影响Redis的实际性能，Hash类元素个数建议尽量不要超过100，集合类、链表类数据尽量不要超过10k。元素数量过⼤可考虑拆分成多个key进⾏处理。
写到最后：
如果您有好的建议和想法，欢迎留⾔，我会继续完善⽂档，提⾼⽂档输出质量。
本⽂为joshua317原创⽂章，转载请注明：转载⾃

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。