• 关于redis key命名规范的设计


    一、实现目标

    简洁,高效,可维护

    二、键值设计规约

    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有数据丢失风险,程序处理数据时,应该考虑丢失后的重新加载过程。

    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进行处理。

    写到最后:

    如果您有好的建议和想法,欢迎留言,我会继续完善文档,提高文档输出质量。

  • 相关阅读:
    读入输出优化
    码表
    windows下bat批处理实现守护进程(有日志)
    cmd批处理常用符号详解
    批处理之 for/f 详解
    WINDOWS XP中用命令行管理用户 net user命令
    VacmMIB
    工作遇到
    snmp之GenericAddress
    snmp4j 之 ArgumentParser
  • 原文地址:https://www.cnblogs.com/weibanggang/p/14167572.html
Copyright © 2020-2023  润新知