redis key命名规范
<h1>redis key命名规范</h1>
<ul>
<li><a href="https://note.youdao.com/ynoteshare/index.html?id=31c4fd85ded4dfef9e7fef1e4d7e76cc&type=note&_time=1648113611414"><a href="https://note.youdao.com/ynoteshare/index.html?id=31c4fd85ded4dfef9e7fef1e4d7e76cc&type=note&\_time=1648113611414">https://note.youdao.com/ynoteshare/index.html?id=31c4fd85ded4dfef9e7fef1e4d7e76cc&type=note&\_time=1648113611414</a></a></li>
</ul>
<h2>一、键值设计规约</h2>
<h4>1、redis key命名风格</h4>
<ul>
<li>
<p>【推荐】Redis key命名需具有可读性以及可管理性，不该使用含义不清的key以及特别长的key名；</p>
</li>
<li>
<p>【强制】以英文字母开头，命名中只能出现小写字母、数字、英文点号(.)和英文半角冒号(:)；</p>
</li>
<li>【强制】不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；</li>
</ul>
<h4>2、命名规范</h4>
<p>【强制】命名规范：<strong>业务模块名:业务逻辑含义:其他:value类型</strong></p>
<p>1 ）<strong>业务模块名</strong>：具体的功能模块</p>
<p>2）逻辑含义段：</p>
<ul>
<li>
<p>【强制】不同业务逻辑含义使用英文半角冒号(:)分割，</p>
</li>
<li>【强制】同一业务逻辑含义段的单词之间使用英文半角点号 (.)分割，用来表示一个完整的语义</li>
</ul>
<p>3）value类型：</p>
<ul>
<li>
<p>【强制】Redis key命名以key所代表的value类型结尾，以提高可读性；</p>
</li>
<li>示例：user:basic.info:{userid}:string</li>
</ul>
<h4>3、value 设计</h4>
<p>【强制】：拒绝bigkey(防止网卡流量、慢查询)。</p>
<p>String类型控制在10KB以内，Hash、List、Set、ZSet元素个数不要超过5000。</p>
<h2>二、业务规范</h2>
<p>1、<strong>【强制】</strong>使用Redis进行缓存时，必须进行申请。申请之前，需要拿出使用的合理方案，然后进行评估，避免随意使用。</p>
<p>2、<strong>【强制】</strong>Redis应用场景应该是<strong>纯缓存服务，</strong>功能主要是缓存数据，缓存数据可丢失，除特殊需求外，需提供可行性、可实施的方案。</p>
<p>3、<strong>【强制】</strong> 关于过期时间</p>
<ul>
<li>
<p>Redis key一定要设置过期时间。</p>
</li>
<li>
<p>要跟自己的业务场景，需要对key设置合理的过期时间。</p>
</li>
<li>
<p>可以在写入key时，就要追加过期时间；也可以在需要写入另一个key时，删除上一个key。</p>
</li>
<li>
<p>说明：</p>
</li>
<li>
<p>(1)若不设置的话，这些key会一直占用内存不释放，随着时间的推移会越来越大，直到达到服务器的内存上限，导致服务器宕机等重大事故；</p>
</li>
<li>
<p>(2)对于key的超时时长设置，可根据业务场景进行评估，设置合理有效期；</p>
</li>
<li>(3)某些业务的确需要长期有效，可以判断即将到期时，重新设置有效期，避免引起热点key问题。</li>
</ul>
<p>4、【<strong>推荐</strong>】Redis的使用，应该考虑冷热数据分离，不该将所有数据全部放到Redis中，对于使用不频繁，且无关紧要的信息存 入mysql，或日志文件中，Redis的数据存储全部都是在内存中的，成本昂贵。</p>
<p>5、【推荐】Redis有数据丢失风险，程序处理数据时，应该考虑丢失后的重新加载过程。</p>
<p>6、【<strong>强制</strong>】禁止大key</p>
<ul>
<li>
<p>大key数据存⼊Redis，除了带来极大的内存占用外，在并发高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用。</p>
<ul>
<li>虽然Redis支持512MB大小的string，但是假设1mb的string大key，每秒重复写入10次，就会导致写入网络IO达10MB;</li>
</ul>
</li>
<li>
<p>(1)读写大key会导致超时严重，网卡流量占满,甚至阻塞服务,更甚者导致宕机风险。</p>
</li>
<li>
<p>(2)如果删除大key，DEL命令可能阻塞Redis进程数十秒，使得其他请求阻塞，对应用程序和Redis集群可用性造成严重的影响。</p>
</li>
<li>(3)每个key不要超过10Kb。</li>
</ul>
<p>7、<strong>【强制】</strong>Redis一定不可使用Keys正则匹配操作。</p>
<p>8、<strong>【推荐】</strong>选择合适的数据类型。</p>
<ul>
<li>
<p>目前Redis支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog和地理空间索引（geospatial）等,需要根据业务场景选择合适的类型。</p>
</li>
<li>
<p>在不能确定其它复杂数据结构⼀定优于String类型时，避免使用Redis的复杂数据结构。</p>
<ul>
<li>
<p>每种数据结构都有相应的使⽤场景，String类型是Redis中最简单的数据类型，建议使用String类型。</p>
</li>
<li>但是考虑到具体的业务场景，综合评估性能、存储网络等方面之后使用适当的数据结构。</li>
</ul>
</li>
<li>
<p>需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、简单数据类类型等；</p>
<ul>
<li>
<p>Hash可以用作对象如居民、医生等，包含较多属性的信息；</p>
</li>
<li>
<p>List可以用作息队列、医生同行/关注列表等；</p>
</li>
<li>Set可以用于推荐；Sorted Set可以用于排行等。</li>
</ul>
</li>
</ul>
<p>9、【<strong>推荐</strong>】关于集合类操作</p>
<ul>
<li>
<p>出现问题最多的就是超时问题，因为使用了O(N)的操作，导致服务超时，甚至服务不可用。</p>
</li>
<li>
<p>使用Set，Zset，List，Hash等集合类的O(N)操作时要评估当前元素个数的规模以及将来的增长规模，对于短期就可能变为大集合的key，要预估O(N)操作的元素数量，避免全量操作，可以使用HSCAN，SSCAN，ZSCAN进行渐进操作。</p>
<ul>
<li>
<p>集合元素数量过大在使用过程中会影响Redis的实际性能，Hash类元素个数建议尽量不要超过100，集合类、链表类数据尽量不要超过10k。</p>
</li>
<li>元素数量过大可考虑拆分成多个key进行处理。</li>
</ul>
</li>
</ul>