网站建设项目申请书,推广恶意点击软件怎样使用,ac68u做网站,营销型网站策划公司前言学习是一个持续的过程。像咱们一直在更新的Redis学习内容#xff0c;由基础结构#xff0c;到原理应用#xff0c;再到集群搭建#xff0c;了解的够充分了#xff0c;咱们接着又介绍Redis拓展应用#xff0c;将知识面拓宽#xff0c;毕竟技术都是相通的#xff0c;…前言学习是一个持续的过程。像咱们一直在更新的Redis学习内容由基础结构到原理应用再到集群搭建了解的够充分了咱们接着又介绍Redis拓展应用将知识面拓宽毕竟技术都是相通的只有灵活运用才能发挥出最大作用。好了接着今天的学习更新拓宽Redis应用。拓展 2无所不知 —— Info 指令在使用 Redis 时时常会遇到很多问题需要诊断在诊断之前需要了解 Redis 的运行状 态通过强大的 Info 指令你可以清晰地知道 Redis 内部一系列运行参数。 Info 指令显示的信息非常繁多分为 9 大块每个块都有非常多的参数这 9 个块分别是1、Server 服务器运行的环境参数 2、Clients 客户端相关信息 3、Memory 服务器运行内存统计数据 4、Persistence 持久化信息 5、Stats 通用统计数据 6、Replication 主从复制相关信息 7、CPU CPU 使用情况 8、Cluster 集群信息 9、KeySpace 键值对统计数量信息Info 可以一次性获取所有的信息也可以按块取信息。# 获取所有信息 info# 获取内存相关信息 info memory# 获取复制相关信息 info replication考虑到参数非常繁多一一说明工作量巨大下面我只挑一些关键性的、非常实用和最常用的参数进行详细讲解。Redis 每秒执行多少次指令这个信息在 Stats 块里可以通过 info stats 看到。# ops_per_sec: operations per second也就是每秒操作数 redis-cli info stats |grep opsinstantaneous_ops_per_sec:789以上表示 ops 是 789也就是所有客户端每秒会发送 789 条指令到服务器执行。极限情况下Redis 可以每秒执行 10w 次指令CPU 几乎完全榨干。如果 qps 过高可以考虑通过 monitor 指令快速观察一下究竟是哪些 key 访问比较频繁从而在相应的业务上进行优化以减少 IO 次数。monitor 指令会瞬间吐出来巨量的指令文本所以一般在执行monitor 后立即 ctrlc 中断输出。 redis-cli monitorRedis 连接了多少客户端 这个信息在 Clients 块里可以通过 info clients 看到。 redis-cli info clients# Clientsconnected_clients:124 # 这个就是正在连接的客户端数量client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0这个信息也是比较有用的通过观察这个数量可以确定是否存在意料之外的连接。如果发现这个数量不对劲接着就可以使用 client list 指令列出所有的客户端链接地址来确定源头。关于客户端的数量还有个重要的参数需要观察那就是 rejected_connections它表示因为超出最大连接数限制而被拒绝的客户端连接次数如果这个数字很大意味着服务器的最大连接数设置的过低需要调整 maxclients 参数。 redis-cli info stats |grep rejectrejected_connections:0Redis 内存占用多大 这个信息在 Memory 块里可以通过 info memory 看到。 redis-cli info memory | grep used | grep humanused_memory_human:827.46K # 内存分配器 (jemalloc) 从操作系统分配的内存总量used_memory_rss_human:3.61M # 操作系统看到的内存占用 ,top 命令看到的内存used_memory_peak_human:829.41K # Redis 内存消耗的峰值used_memory_lua_human:37.00K # lua 脚本引擎占用的内存大小如果单个 Redis 内存占用过大并且在业务上没有太多压缩的空间的话可以考虑集群化了。 复制积压缓冲区多大 这个信息在 Replication 块里可以通过 info replication 看到。 redis-cli info replication |grep backlogrepl_backlog_active:0repl_backlog_size:1048576 # 这个就是积压缓冲区大小repl_backlog_first_byte_offset:0repl_backlog_histlen:0复制积压缓冲区大小非常重要它严重影响到主从复制的效率。当从库因为网络原因临时断开了主库的复制然后网络恢复了又重新连上的时候这段断开的时间内发生在 master 上的修改操作指令都会放在积压缓冲区中这样从库可以通过积压缓冲区恢复中断的主从同步过程。 积压缓冲区是环形的后来的指令会覆盖掉前面的内容。如果从库断开的时间过长或者缓冲区的大小设置的太小都会导致从库无法快速恢复中断的主从同步过程因为中间的修改指令被覆盖掉了。这时候从库就会进行全量同步模式非常耗费 CPU 和网络资源。 如果有多个从库复制积压缓冲区是共享的它不会因为从库过多而线性增长。如果实例的修改指令请求很频繁那就把积压缓冲区调大一些几十个 M 大小差不多了如果很闲那就设置为几个 M。 redis-cli info stats | grep syncsync_full:0sync_partial_ok:0sync_partial_err:0 # 半同步失败次数通过查看 sync_partial_err 变量的次数来决定是否需要扩大积压缓冲区它表示主从半同步复制失败的次数。拓展 3拾遗漏补 —— 再谈分布式锁在之前我们细致讲解了分布式锁的原理它的使用非常简单一条指令就可以完成 加锁操作。不过在集群环境下这种方式是有缺陷的它不是绝对安全的。 比如在 Sentinel 集群中主节点挂掉时从节点会取而代之客户端上却并没有明显感 知。原先第一个客户端在主节点中申请成功了一把锁但是这把锁还没有来得及同步到从节点主节点突然挂掉了。然后从节点变成了主节点这个新的节点内部没有这个锁所以当另一个客户端过来请求加锁时立即就批准了。这样就会导致系统中同样一把锁被两个客户端同时持有不安全性由此产生。不过这种不安全也仅仅是在主从发生 failover 的情况下才会产生而且持续时间极短 业务系统多数情况下可以容忍。Redlock 算法 为了解决这个问题Antirez 发明了 Redlock 算法它的流程比较复杂不过已经有了很多开源的 library 做了良好的封装用户可以拿来即用比如 redlock-py。import redlockaddrs [{ host: localhost, port: 6379, db: 0}, { host: localhost, port: 6479, db: 0}, { host: localhost, port: 6579, db: 0}]dlm redlock.Redlock(addrs)success dlm.lock(user-lck-laoqian, 5000)if success: print lock success dlm.unlock(user-lck-laoqian)else: print lock failed为了使用 Redlock需要提供多个 Redis 实例这些实例之前相互独立没有主从关系。 同很多分布式算法一样redlock 也使用「大多数机制」。 加锁时它会向过半节点发送 set(key, value, nxTrue, exxxx) 指令只要过半节点 set 成功那就认为加锁成功。释放锁时需要向所有节点发送 del 指令。不过 Redlock 算法还 需要考虑出错重试、时钟漂移等很多细节问题同时因为 Redlock 需要向多个节点进行读写意味着相比单实例 Redis 性能会下降一些。Redlock 使用场景如果你很在乎高可用性希望挂了一台 redis 完全不受影响那就应该考虑 redlock。不过代价也是有的需要更多的 redis 实例性能也下降了代码上还需要引入额外的library运维上也需要特殊对待这些都是需要考虑的成本使用前请再三斟酌。今天的Redis拓展应用就先到这里吧希望朋友们都有所收获啊~~~喜欢请多多点赞评论分享让更多的人看到获益关注小编后续小编会带来更丰富的学习内容更新希望能帮到大家更好的学习~~~
