谈谈如果提高缓存命中率
通过计算hits和miss,我们可以得到缓存的命中率:7039865/ (7039865 + 793620) = 89% ,一个缓存失效机制,和过期时间设计良好的系统,命中率可以做到95%以上

以下是预生产服务器的INFO信息详解:
keyspace_hits:7039865 ###查找数据库键成功的次数。可以计算命中率
keyspace_misses:793620 ###查找数据库键失败的次数。

1、根据自身企业环境选择合理的利用缓存业务,缓存适合查询较多,写入较少的环境,反之缓存运用的的意义不大,浪费资源,缓存命中率也会很低。
业务需求决定了对时效性的要求,直接影响到缓存的过期时间和更新策略。时效性要求越低,就越适合缓存。在相同key和相同请求数的情况下,缓存时
间越长,命中率会越高。

提高缓存命中率,需要考虑以下几点:
既然业务需求对数据时效性要求很高,而缓存时间又会影响到缓存命中率,建议不要使用缓存。
筛选高频率访问时效有不是很高的热点业务,统计出来,通过预热、增加存储容量、更新缓存周期等手段提高命中率。

Info信息

# Server
redis_version:3.2.3  ###redis版本号 
redis_git_sha1:00000000   ###git SHA1
redis_git_dirty:0         ###git dirty flag
redis_build_id:672aed6eb816ad6c
redis_mode:standalone    ###redis运行模式
os:Linux 3.10.0-514.26.2.el7.x86_64 x86_64   ###os版本号
arch_bits:64                                ###64位架构
multiplexing_api:epoll                      ###调用epoll算法
gcc_version:4.8.5                          ###gcc版本号
process_id:2137                             ###服务器进程PID
run_id:87104e906fc694c9653ec95cf2efaf900975358e     ###Redis的随机标识符(用于sentinel和集群)
tcp_port:6379                                     ###Redis监听的端口号
uptime_in_seconds:44064743                        ###Redis运行时长(s为单位)
uptime_in_days:510                                  ###Redis运行时长(天为单位)
hz:10
lru_clock:15989400                                  ###以分钟为单位的自增时钟,用于LRU管理
executable:/usr/bin/redis-server                     ###redis配置文件
config_file:

# Clients
connected_clients:3         ###已连接客户端的数量(不包括通过从属服务器连接的客户端)这个参数也要一定关注,有飙升和明显下降时都会有问题。即使不操作
client_longest_output_list:0   ###当前连接的客户端中最长的输出列表
client_biggest_input_buf:0      ###当前连接的客户端中最大的。输出缓存
blocked_clients:0                  ###正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量 需监控

# Memory
used_memory:813024        ###由 Redis 分配器分配的内存总量,以字节(byte)为单位
used_memory_human:793.97K  ###以更友好的格式输出redis占用的内存
used_memory_rss:5939200     ###从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致,包含了used_memory和内存碎片。
used_memory_rss_human:5.66M
used_memory_peak:813024          ###Redis 的内存消耗峰值(以字节为单位)
used_memory_peak_human:793.97K     ###以更友好的格式输出redis峰值内存占用
total_system_memory:3705339904
total_system_memory_human:3.45G
used_memory_lua:37888                 ###LUA引擎所使用的内存大小
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:7.31  ###   =used_memory_rss /used_memory 这两个参数都包含保存用户k-v数据的内存和redis内部不同数据结构需要占用的内存,并且RSS指的是包含操作系统给redis实例分配的内存,这里面还包含不连续分配所带来的开销。因此在理想情况下, used_memory_rss 的值应该只比 used_memory_rss_human 稍微高一点儿。当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。可以说这个值大于1.5或者小于1都是有问题的。当大于1.5的时候需要择机进行服务器重启。当小于1的时候需要对redis进行数据清理
mem_allocator:jemalloc-3.6.0
mem_allocator:jemalloc-3.6.0

# Persistence
loading:0             ###记录服务器是否正在载入持久化文件,1为正在加载
rdb_changes_since_last_save:0    ###距离最近一次成功创建持久化文件之后,产生了多少次修改数据集的操作
rdb_bgsave_in_progress:0        ###记录了服务器是否正在创建 RDB 文件,1为正在进行
rdb_last_save_time:1504692371     ###最近一次成功创建 RDB 文件的 UNIX 时间戳
rdb_last_bgsave_status:ok         ###最近一次创建 RDB 文件的结果是成功还是失败,失败标识为err,这个时候写入redis 的操作可能会停止,因为默认stop-writes-on-bgsave-error是开启的,这个时候如果需要尽快恢复写操作,可以手工将这个选项设置为no。
rdb_last_bgsave_time_sec:-1     ###最近一次创建 RDB 文件耗费的秒数
rdb_current_bgsave_time_sec:-1   ###如果服务器正在创建 RDB 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:0                    ###AOF 是否处于打开状态,1为启用
aof_rewrite_in_progress:0         ###服务器是否正在创建 AOF 文件
aof_rewrite_scheduled:0     ###RDB 文件创建完毕之后,是否需要执行预约的 AOF 重写操作(因为在RDB时aof的rewrite会被阻塞一直到RDB结束)
aof_last_rewrite_time_sec:-1   ###最近一次创建 AOF 文件耗费的时长
aof_current_rewrite_time_sec:-1  ###如果服务器正在创建 AOF 文件,那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_last_bgrewrite_status:ok  ###最近一次创建 AOF 文件的结果是成功还是失败
aof_last_write_status:ok

# Stats
total_connections_received:1327039865     ###服务器已接受的连接请求数量,注意这是个累计值。
total_commands_processed:8912957                ###服务器已执行的命令数量,这个数值需要持续监控,如果在一段时间内出现大范围波动说明系统要么出现大量请求,要么出现执行缓慢的操作。
instantaneous_ops_per_sec:1        ###服务器每秒钟执行的命令数量
total_net_input_bytes:31
total_net_output_bytes:5896620
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0                  ###因为最大客户端数量限制而被拒绝的连接请求数量
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0                       ###因为过期而被自动删除的数据库键数量
evicted_keys:0                       ###因为最大内存容量限制而被驱逐(evict)的键数量。这个数值如果不是0则说明maxmemory被触发,并且    evicted_keys一直大于0,则系统的latency增加,此时可以临时提高最大内存,但这只是临时措施,需要从应用着手分析。
keyspace_hits:7039865             ###查找数据库键成功的次数。可以计算命中率
keyspace_misses:793620              ###查找数据库键失败的次数。
pubsub_channels:0          ###目前被订阅的频道数量
pubsub_patterns:0           ###目前被订阅的模式数量
latest_fork_usec:0 
migrate_cached_sockets:306    ###最近一次 fork() 操作耗费的毫秒数

# Replication
role:master   ###如果当前服务器没有在复制任何其他服务器,那么这个域的值就是 master ;否则的话,这个域的值就是 slave 。注意,在创建复制链的时候,一个从服务器也可能是另一个服务器的主服务器
connected_slaves:2    ###2个slaves
slave0:ip=172.16.1.222,port=6379,state=online,offset=1639,lag=1
slave1:ip=172.16.1.223,port=6379,state=online,offset=1639,lag=0
master_repl_offset:1639
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1638

# CPU
used_cpu_sys:1899.56  ###Redis 服务器耗费的系统 CPU
used_cpu_user:1179.91   ###Redis 服务器耗费的用户 CPU
used_cpu_sys_children:0.01  ###后台进程耗费的系统 CPU
used_cpu_user_children:0.01 ###后台进程耗费的用户 CPU

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=1,expires=0,avg_ttl=0 ###keyspace 部分记录了数据库相关的统计信息,比如数据库的键数量、数据库过期键数量等。对于每个数据库,这个部分都会添加一行此信息
127.0.0.1:6379> 

打赏作者

Leave a Reply

Your email address will not be published.