专业的外贸网站建设公司在线制图网页版

当前位置： 首页 > news >正文

专业的外贸网站建设公司,在线制图网页版,装修平台网站有哪些,公司名字查重系统Redis 核心技术与实战 笔记 作者#xff1a; 蒋德钧 毕竟#xff0c;高性能和节省内存#xff0c;是我们的两个目标#xff0c;只有规范地使用Redis#xff0c;才能真正实现这两个目标。如果说之前的内容教会了你怎么用#xff0c;那么今天的内容#xff0c;就是帮助你用…Redis 核心技术与实战 笔记 作者 蒋德钧 毕竟高性能和节省内存是我们的两个目标只有规范地使用Redis才能真正实现这两个目标。如果说之前的内容教会了你怎么用那么今天的内容就是帮助你用好Redis尽量不出错。 好了话不多说我们来看下键值对的使用规范。 键值对使用规范 关于键值对的使用规范我主要想和你说两个方面 key 的命名规范只有命名规范才能提供可读性强、可维护性好的 key方便日常管理value 的设计规范包括避免bigkey、选择高效序列化方法和压缩方法、使用整数对象共享池、数据类型选择。 规范一key 的命名规范 一个 Redis 实例默认可以支持 16 个数据库我们可以把不同的业务数据分散保存到不同的数据库中。 但是在使用不同数据库时客户端需要使用 SELECT 命令进行数据库切换相当于增加了一个额外的操作。 其实我们可以通过合理命名 key减少这个操作。具体的做法是把业务名作为前缀然后用冒号分隔再加上具体的业务数据名。这样一来我们可以通过 key 的前缀区分不同的业务数据就不用在多个数据库间来回切换了。 我给你举个简单的小例子看看具体怎么命名 key。 比如说如果我们要统计网页的独立访客量就可以用下面的代码设置 key这就表示这个数据对应的业务是统计 unique visitor独立访客量而且对应的页面编号是 1024。 uv:page:1024这里有一个地方需要注意一下。key 本身是字符串底层的数据结构是 SDS。SDS 结构中会包含字符串长度、分配空间大小等元数据信息。从 Redis 3.2 版本开始当 key 字符串的长度增加时SDS 中的元数据也会占用更多内存空间。 所以我们在设置 key 的名称时要注意控制 key 的长度。否则如果 key 很长的话就会消耗较多内存空间而且SDS 元数据也会额外消耗一定的内存空间。 SDS 结构中的字符串长度和元数据大小的对应关系如下表所示 为了减少 key 占用的内存空间我给你一个小建议对于业务名或业务数据名可以使用相应的英文单词的首字母表示比如 user 用 u 表示message 用 m或者是用缩写表示例如 unique visitor 使用 uv。 规范二避免使用 bigkey Redis 是使用单线程读写数据bigkey 的读写操作会阻塞线程降低 Redis 的处理效率。所以在应用 Redis 时关于 value 的设计规范非常重要的一点就是避免 bigkey。 bigkey 通常有两种情况。 情况一键值对的值大小本身就很大例如 value 为 1MB 的 String 类型数据。为了避免 String 类型的 bigkey在业务层我们要尽量把 String 类型的数据大小控制在 10KB 以下。 情况二键值对的值是集合类型集合元素个数非常多例如包含 100 万个元素的 Hash 集合类型数据。为了避免集合类型的 bigkey我给你的设计规范建议是尽量把集合类型的元素个数控制在 1 万以下。
当然这些建议只是为了尽量避免 bigkey如果业务层的 String 类型数据确实很大我们还可以通过数据压缩来减小数据大小如果集合类型的元素的确很多我们可以将一个大集合拆分成多个小集合来保存。 这里还有个地方需要注意下Redis 的 4 种集合类型 List、Hash、Set 和 Sorted Set在集合元素个数小于一定的阈值时会使用内存紧凑型的底层数据结构进行保存从而节省内存。例如假设 Hash 集合的 hash-max-ziplist-entries 配置项是 1000如果 Hash 集合元素个数不超过 1000就会使用 ziplist 保存数据。 紧凑型数据结构虽然可以节省内存但是会在一定程度上导致数据的读写性能下降。所以如果业务应用更加需要保持高性能访问而不是节省内存的话在不会导致 bigkey 的前提下你就不用刻意控制集合元素个数了。 规范三使用高效序列化方法和压缩方法 为了节省内存除了采用紧凑型数据结构以外我们还可以遵循两个使用规范分别是使用高效的序列化方法和压缩方法这样可以减少 value 的大小。 Redis 中的字符串都是使用二进制安全的字节数组来保存的所以我们可以把业务数据序列化成二进制数据写入到 Redis 中。 但是不同的序列化方法在序列化速度和数据序列化后的占用内存空间这两个方面效果是不一样的。比如说protostuff 和 kryo 这两种序列化方法就要比 Java 内置的序列化方法java-build-in-serializer效率更高。 此外业务应用有时会使用字符串形式的 XML 和 JSON 格式保存数据。 这样做的好处是这两种格式的可读性好便于调试不同的开发语言都支持这两种格式的解析。 缺点在于XML 和 JSON 格式的数据占用的内存空间比较大。为了避免数据占用过大的内存空间我建议使用压缩工具例如 snappy 或 gzip把数据压缩后再写入 Redis这样就可以节省内存空间了。 规范四使用整数对象共享池 整数是常用的数据类型Redis 内部维护了 0 到 9999 这 1 万个整数对象并把这些整数作为一个共享池使用。 换句话说如果一个键值对中有 0 到 9999 范围的整数Redis 就不会为这个键值对专门创建整数对象了而是会复用共享池中的整数对象。 这样一来即使大量键值对保存了 0 到 9999 范围内的整数在 Redis 实例中其实只保存了一份整数对象可以节省内存空间。 基于这个特点我建议你在满足业务数据需求的前提下能用整数时就尽量用整数这样可以节省实例内存。 那什么时候不能用整数对象共享池呢主要有两种情况。 第一种情况是如果 Redis 中设置了 maxmemory而且启用了 LRU 策略allkeys-lru 或 volatile-lru 策略那么整数对象共享池就无法使用了。 这是因为LRU 策略需要统计每个键值对的使用时间如果不同的键值对都共享使用一个整数对象LRU 策略就无法进行统计了。 第二种情况是如果集合类型数据采用 ziplist 编码而集合元素是整数这个时候也不能使用共享池。因为 ziplist 使用了紧凑型内存结构判断整数对象的共享情况效率低。 好了到这里我们了解了和键值对使用相关的四种规范遵循这四种规范最直接的好处就是可以节省内存空间。接下来我们再来了解下在实际保存数据时该遵循哪些规范。 数据保存规范 规范一使用 Redis 保存热数据 为了提供高性能访问Redis 是把所有数据保存到内存中的。 虽然 Redis 支持使用 RDB 快照和 AOF 日志持久化保存数据但是这两个机制都是用来提供数据可靠性保证的并不是用来扩充数据容量的。而且内存成本本身就比较高如果把业务数据都保存在 Redis 中会带来较大的内存成本压力。 所以一般来说在实际应用 Redis 时我们会更多地把它作为缓存保存热数据这样既可以充分利用 Redis 的高性能特性还可以把宝贵的内存资源用在服务热数据上就是俗话说的“好钢用在刀刃上”。 规范二不同的业务数据分实例存储 虽然我们可以使用 key 的前缀把不同业务的数据区分开但是如果所有业务的数据量都很大而且访问特征也不一样我们把这些数据保存在同一个实例上时这些数据的操作就会相互干扰。 你可以想象这样一个场景假如数据采集业务使用 Redis 保存数据时以写操作为主而用户统计业务使用 Redis 时是以读查询为主如果这两个业务数据混在一起保存读写操作相互干扰肯定会导致业务响应变慢。 那么我建议你把不同的业务数据放到不同的 Redis 实例中。这样一来既可以避免单实例的内存使用量过大也可以避免不同业务的操作相互干扰。 规范三在数据保存时要设置过期时间 对于 Redis 来说内存是非常宝贵的资源而且Redis 通常用于保存热数据。热数据一般都有使用的时效性。所以在数据保存时我建议你根据业务使用数据的时长设置数据的过期时间。 不然的话写入 Redis 的数据会一直占用内存如果数据持续增多就可能达到机器的内存上限造成内存溢出导致服务崩溃。 规范四控制 Redis 实例的容量 Redis 单实例的内存大小都不要太大根据我自己的经验值建议你设置在 2~6GB 。这样一来无论是 RDB 快照还是主从集群进行数据同步都能很快完成不会阻塞正常请求的处理。 命令使用规范 最后我们再来看下在使用 Redis 命令时要遵守什么规范。 规范一线上禁用部分命令 Redis 是单线程处理请求操作如果我们执行一些涉及大量操作、耗时长的命令就会严重阻塞主线程导致其它请求无法得到正常处理这类命令主要有 3 种。 KEYS按照键值对的 key 内容进行匹配返回符合匹配条件的键值对该命令需要对 Redis 的全局哈希表进行全表扫描严重阻塞 Redis 主线程FLUSHALL删除 Redis 实例上的所有数据如果数据量很大会严重阻塞 Redis 主线程FLUSHDB删除当前数据库中的数据如果数据量很大同样会阻塞 Redis 主线程。 所以我们在线上应用 Redis 时就需要禁用这些命令。具体的做法是管理员用 rename-command 命令在配置文件中对这些命令进行重命名让客户端无法使用这些命令。 当然你还可以使用其它命令替代这 3 个命令。 对于 KEYS 命令来说你可以用 SCAN 命令代替 KEYS 命令分批返回符合条件的键值对避免造成主线程阻塞对于 FLUSHALL、FLUSHDB 命令来说你可以加上 ASYNC 选项让这两个命令使用后台线程异步删除数据可以避免阻塞主线程。 规范二慎用 MONITOR 命令 Redis 的 MONITOR 命令在执行后会持续输出监测到的各个命令操作所以我们通常会用 MONITOR 命令返回的结果检查命令的执行情况。 但是MONITOR 命令会把监控到的内容持续写入输出缓冲区。如果线上命令的操作很多输出缓冲区很快就会溢出了这就会对 Redis 性能造成影响甚至引起服务崩溃。 所以除非十分需要监测某些命令的执行例如Redis 性能突然变慢我们想查看下客户端执行了哪些命令你可以偶尔在短时间内使用下 MONITOR 命令否则我建议你不要使用 MONITOR 命令。 规范三慎用全量操作命令 对于集合类型的数据来说如果想要获得集合中的所有元素一般不建议使用全量操作的命令例如 Hash 类型的 HGETALL、Set 类型的 SMEMBERS。这些操作会对 Hash 和 Set 类型的底层数据结构进行全量扫描如果集合类型数据较多的话就会阻塞 Redis 主线程。 如果想要获得集合类型的全量数据我给你三个小建议。 第一个建议是你可以使用 SSCAN、HSCAN 命令分批返回集合中的数据减少对主线程的阻塞。第二个建议是你可以化整为零把一个大的 Hash 集合拆分成多个小的 Hash 集合。这个操作对应到业务层就是对业务数据进行拆分按照时间、地域、用户 ID 等属性把一个大集合的业务数据拆分成多个小集合数据。例如当你统计用户的访问情况时就可以按照天的粒度把每天的数据作为一个 Hash 集合。最后一个建议是如果集合类型保存的是业务数据的多个属性而每次查询时也需要返回这些属性那么你可以使用 String 类型将这些属性序列化后保存每次直接返回 String 数据就行不用再对集合类型做全量扫描了。 小结 这节课我围绕 Redis 应用时的高性能访问和节省内存空间这两个目标分别在键值对使用、命令使用和数据保存三方面向你介绍了 11 个规范。 我按照强制、推荐、建议这三个类别把这些规范分了下类如下表所示 我来解释一下这 3 个类别的规范。 强制类别的规范这表示如果不按照规范内容来执行就会给 Redis 的应用带来极大的负面影响例如性能受损。推荐类别的规范这个规范的内容能有效提升性能、节省内存空间或者是增加开发和运维的便捷性你可以直接应用到实践中。建议类别的规范这类规范内容和实际业务应用相关我只是从我的经历或经验给你一个建议你需要结合自己的业务场景参考使用。 我再多说一句你一定要熟练掌握这些使用规范并且真正地把它们应用到你的 Redis 使用场景中提高 Redis 的使用效率。 我总结的 Redis 使用规范分为两大方面主要包括业务层面和运维层面。业务层面主要面向的业务开发人员1、key 的长度尽量短节省内存空间 2、避免 bigkey防止阻塞主线程 3、4.0版本建议开启 lazy-free 4、把 Redis 当作缓存使用设置过期时间 5、不使用复杂度过高的命令例如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 6、查询数据尽量不一次性查询全量写入大量数据建议分多批写入 7、批量操作建议 MGET/MSET 替代 GET/SETHMGET/HMSET 替代 HGET/HSET 8、禁止使用 KEYS/FLUSHALL/FLUSHDB 命令 9、避免集中过期 key 10、根据业务场景选择合适的淘汰策略 11、使用连接池操作 Redis并设置合理的参数避免短连接 12、只使用 db0减少 SELECT 命令的消耗 13、读请求量很大时建议读写分离写请求量很大建议使用切片集群运维层面主要面向的是 DBA 运维人员1、按业务线部署实例避免多个业务线混合部署出问题影响其他业务 2、保证机器有足够的 CPU、内存、带宽、磁盘资源 3、建议部署主从集群并分布在不同机器上slave 设置为 readonly 4、主从节点所部署的机器各自独立尽量避免交叉部署对从节点做维护时不会影响到主节点 5、推荐部署哨兵集群实现故障自动切换哨兵节点分布在不同机器上 6、提前做好容量规划防止主从全量同步时实例使用内存突增导致内存不足 7、做好机器 CPU、内存、带宽、磁盘监控资源不足时及时报警任意资源不足都会影响 Redis 性能 8、实例设置最大连接数防止过多客户端连接导致实例负载过高影响性能 9、单个实例内存建议控制在 10G 以下大实例在主从全量同步、备份时有阻塞风险 10、设置合理的 slowlog 阈值并对其进行监控slowlog 过多需及时报警 11、设置合理的 repl-backlog降低主从全量同步的概率 12、设置合理的 slave client-output-buffer-limit避免主从复制中断情况发生 13、推荐在从节点上备份不影响主节点性能 14、不开启 AOF 或开启 AOF 配置为每秒刷盘避免磁盘 IO 拖慢 Redis 性能 15、调整 maxmemory 时注意主从节点的调整顺序顺序错误会导致主从数据不一致 16、对实例部署监控采集 INFO 信息时采用长连接避免频繁的短连接 17、做好实例运行时监控重点关注 expired_keys、evicted_keys、latest_fork_usec这些指标短时突增可能会有阻塞风险 18、扫描线上实例时记得设置休眠时间避免过高 OPS 产生性能抖动