陕西省建设监理协会网站成绩查询网站网站建设公

陕西省建设监理协会网站成绩查询,网站网站建设公,网站集群建设实施方案,炫酷的企业网站模板免费下载一、Redis Key-Value设计规范性能优化 1. key名设计规范 【建议】 以业务名(或数据库名)为前缀(防止key冲突)#xff0c;用冒号分隔#xff0c;比如业务名:表名:id login:user:10 优点#xff1a; 可读性强避免key冲突方便管理更节省内存#xff1a;key是string类…一、Redis Key-Value设计规范性能优化1. key名设计规范【建议】以业务名(或数据库名)为前缀(防止key冲突)用冒号分隔比如业务名:表名:id login:user:10优点可读性强避免key冲突方便管理更节省内存key是string类型底层编码包含int、embstr和raw三种。embstr在小于44字节使用采用连续内存空间内存占用更小(2)【建议】简洁性保证语义的前提下控制key的长度当key较多时内存占用也不容忽视例如(3)【强制】不要包含特殊字符反例包含空格、换行、单双引号以及其他转义字符(4)、拒绝BigKeyBigKey通常以Key的大小和Key中成员的数量来综合判定例如Key本身的数据量过大一个String类型的Key它的值为5 MB。Key中的成员数过多一个ZSET类型的Key它的成员数量为10,000个。Key中成员的数据量过大一个Hash类型的Key它的成员数量虽然只有1,000个但这些成员的Value值总大小为100 MB。2. Value设计规范(1)【强制】拒绝bigkey(防止网卡流量、慢查询)在Redis中一个字符串最大512MB一个二级数据结构例如hash、list、set、zset可以存储大约40亿个(2^32-1)个元素但实际中如果下面两种情况我就会认为它是bigkey。字符串类型它的big体现在单个value值很大一般认为超过10KB就是bigkey。非字符串类型哈希、列表、集合、有序集合它们的big体现在元素个数太多。一般来说string类型控制在10KB以内hash、list、set、zset元素个数不要超过5000。反例一个包含200万个元素的list。2、拒绝BigKeyBigKey通常以Key的大小和Key中成员的数量来综合判定例如Key本身的数据量过大一个String类型的Key它的值为5 MB。Key中的成员数过多一个ZSET类型的Key它的成员数量为10,000个。Key中成员的数据量过大一个Hash类型的Key它的成员数量虽然只有1,000个但这些成员的Value值总大小为100 MB。推荐单个key的value小于10KB对于集合类型的key建议元素数量小于10001、BigKey的危害网络阻塞 对BigKey执行读请求时少量的QPS就可能导致带宽使用率被占满导致Redis实例乃至所在物理机变慢数据倾斜 BigKey所在的Redis实例内存使用率远超其他实例无法使数据分片的内存资源达到均衡Redis阻塞 对元素较多的hash、list、zset等做运算会耗时较旧使主线程被阻塞CPU压力 对BigKey的数据序列化和反序列化会导致CPU的使用率飙升影响Redis实例和本机其它应用2、如何发现BigKeyredis-cli --bigkeys利用redis-cli提供的--bigkeys参数可以遍历分析所有key并返回Key的整体统计信息与每个数据的Top1的big keyscan扫描 自己编程利用scan扫描Redis中的所有key利用strlen、hlen等命令判断key的长度此处不建议使用MEMORY USAGE第三方工具 利用第三方工具如 Redis-Rdb-Tools 分析RDB快照文件全面分析内存使用情况网络监控 自定义工具监控进出Redis的网络数据超出预警值时主动告警3、如何删除BigKeyBigKey内存占用较多即便时删除这样的key也需要耗费很长时间导致Redis主线程阻塞引发一系列问题。redis 3.0 及以下版本如果是集合类型则遍历BigKey的元素先逐个删除子元素最后删除BigKeyRedis 4.0以后Redis在4.0后提供了异步删除的命令unlink3、恰当的数据类型数据存储到Redis当中如何选择恰当的类型呢举例说明一下例1比如存储一个User对象我们有三种存储方式方式一json字符串user:1{name: Jack, age: 21}优点实现简单粗暴缺点数据耦合不够灵活方式二字段打散user:1:nameJackuser:1:age21优点可以灵活访问对象任意字段缺点占用空间大、没办法做统一控制方式三hashuser:1nameJack其实第一列的单元格是合并的jack21优点底层使用ziplist空间占用小可以灵活访问对象的任意字段缺点代码相对复杂PS总的来说还是哈希比较好一点空间小且灵活代码其实也复杂不到哪去多那几行代码一下就完事了例2假如有hash类型的key其中有100万对field和valuefield是自增id这个key存在什么问题如何优化方案一hash存储如果还使用hash来存储的话会存在以下问题hash的entry数量超过500时会使用哈希表而不是ZipList内存占用较多。可以通过hash-max-ziplist-entries配置entry上限。但是如果entry过多就会导致BigKey问题方案二采用String类型存储拆分为StringKeyvalueid:0value0..........id:999999value999999存在的问题string结构底层没有太多内存优化内存占用较多。想要批量获取这些数据比较麻烦方案三拆分为小的hash将 id / 100 作为key 将id % 100 作为field这样每100个元素为一个Hash采用小的hash结构之后内存缩小了接近1/3。4、总结Key的最佳实践固定格式[业务名]:[数据名]:[id]足够简短不超过44字节不包含特殊字符Value的最佳实践合理的拆分数据拒绝BigKey选择合适数据结构Hash结构的entry数量不要超过1000设置合理的超时时间