redis监控

news/2024/5/30 18:52:33/文章来源:https://blog.csdn.net/w_t_y_y/article/details/136701062

一、Redis监控方法

1、redis info命令

Redis的监控指标主要通过INFO命令获取,该命令可以返回丰富的运行监控信息。info主要有以下几项,因版本不同可能略有差别:

# Server
redis_version:7.2.4
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:ee3f37b1e139265
redis_mode:standalone
os:Linux 3.10.0-693.el7.x86_64 x86_64
arch_bits:64
monotonic_clock:POSIX clock_gettime
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:4.8.5
process_id:710649
process_supervised:no
run_id:d18cddfec1ae8e55e35c83079be0b5f31ae9dc4f
tcp_port:6379
server_time_usec:1710384474327851
uptime_in_seconds:580373
uptime_in_days:6
hz:10
configured_hz:10
lru_clock:15885658
executable:/usr/local/redis/bin/./redis-server
config_file:/usr/local/redis/bin/./redis.conf
io_threads_active:0
listener0:name=tcp,bind=127.0.0.1,bind=-::1,port=6379# Clients
connected_clients:1
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:20480
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0
total_blocking_keys:0
total_blocking_keys_on_nokey:0# Memory
used_memory:1064464
used_memory_human:1.02M
used_memory_rss:4321280
used_memory_rss_human:4.12M
used_memory_peak:1283112
used_memory_peak_human:1.22M
used_memory_peak_perc:82.96%
used_memory_overhead:888632
used_memory_startup:865896
used_memory_dataset:175832
used_memory_dataset_perc:88.55%
allocator_allocated:1350328
allocator_active:1617920
allocator_resident:6791168
total_system_memory:33568501760
total_system_memory_human:31.26G
used_memory_lua:31744
used_memory_vm_eval:31744
used_memory_lua_human:31.00K
used_memory_scripts_eval:0
number_of_cached_scripts:0
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:32768
used_memory_vm_total:64512
used_memory_vm_total_human:63.00K
used_memory_functions:184
used_memory_scripts:184
used_memory_scripts_human:184B
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.20
allocator_frag_bytes:267592
allocator_rss_ratio:4.20
allocator_rss_bytes:5173248
rss_overhead_ratio:0.64
rss_overhead_bytes:-2469888
mem_fragmentation_ratio:4.07
mem_fragmentation_bytes:3258640
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_total_replication_buffers:0
mem_clients_slaves:0
mem_clients_normal:22400
mem_cluster_links:0
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0# Persistence
loading:0
async_loading:0
current_cow_peak:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1710320429
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_saves:2
rdb_last_cow_size:569344
rdb_last_load_keys_expired:0
rdb_last_load_keys_loaded:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_rewrites:0
aof_rewrites_consecutive_failures:0
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0# Stats
total_connections_received:20
total_commands_processed:40
instantaneous_ops_per_sec:0
total_net_input_bytes:989
total_net_output_bytes:1037319
total_net_repl_input_bytes:0
total_net_repl_output_bytes:0
instantaneous_input_kbps:0.02
instantaneous_output_kbps:124.94
instantaneous_input_repl_kbps:0.00
instantaneous_output_repl_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:10942
evicted_keys:0
evicted_clients:0
total_eviction_exceeded_time:0
current_eviction_exceeded_time:0
keyspace_hits:8
keyspace_misses:3
pubsub_channels:0
pubsub_patterns:0
pubsubshard_channels:0
latest_fork_usec:747
total_forks:2
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
total_active_defrag_time:0
current_active_defrag_time:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:3
dump_payload_sanitizations:0
total_reads_processed:61
total_writes_processed:52
io_threaded_reads_processed:0
io_threaded_writes_processed:0
reply_buffer_shrinks:8
reply_buffer_expands:2
eventloop_cycles:5789265
eventloop_duration_sum:718037603
eventloop_duration_cmd_sum:8342
instantaneous_eventloop_cycles_per_sec:11
instantaneous_eventloop_duration_usec:181
acl_access_denied_auth:0
acl_access_denied_cmd:0
acl_access_denied_key:0
acl_access_denied_channel:0# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:4a0c850d2ca9045fc42a3fb5d506348bf5d8f738
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0# CPU
used_cpu_sys:317.508411
used_cpu_user:507.646145
used_cpu_sys_children:0.005300
used_cpu_user_children:0.000140
used_cpu_sys_main_thread:317.505063
used_cpu_user_main_thread:507.643396# Modules# Errorstats
errorstat_ERR:count=3# Cluster
cluster_enabled:0# Keyspace
db0:keys=3,expires=0,avg_ttl=0
127.0.0.1:6379> 
1.1、Server

 有关redis服务器的常规信息

redis_version : 2.8.19                             # Redis服务器版本
redis_git_sha1:00000000                           #Git  SHA1
redis_git_dirty: 0                                 #Git dirty flag
os:  Linux 3.2.0-23-generic x86_64                 #Redis服务器的宿主操作系统
arch_bits: 64                                      #服务器系统架构(32位或64位)
multiplexing_api: epoll                            #Redis使用的事件处理机制
gcc_version:4.6.3                                  #编译Redis时所使用的GCC版本
process_id:7573                                    #Redis服务的进程PID
run_id:f1c233c4194cba88616c5bfff2d97fc3074865c1    #Redis服务器的随机标识符(用于Sentinel和集群)
tcp_port:6379                                      #Redis服务监听的TCP端口
uptime_in_seconds:7976                             #自Redis服务器启动以来,经过的秒数
uptime_in_days:0                                   #自Redis服务器启动以来,经过的天数. 这里还不到1天,故显示为0
hz:10                                              # Redis调用内部函数来执行许多后台任务的频率为每秒10次
lru_clock:1133773                                  #以分钟为单位进行自增的时钟,用于LRU管理
config_file:/data/redis_6379/redis.conf            #redis.conf配置文件所在路径
1.2、 Clients:

客户端连接部分。

因为Redis是单线程模型(只能使用单核),来处理所有客户端的请求,且Redis默认允许客户端连接的最大数量是10000。若是看到连接数超过5000以上,那可能会影响Redis的性能。因此监控客户端连接数是非常重要的,因为客户端创建连接数的数量可能超出预期的数量,也可能是客户端端没有有效的释放连接。

connected_clients:2                    #已连接客户端的数量(不包括通过从服务器连接的客户端)
client_longest_output_list:0           #当前的客户端连接中,最长的输出列表
client_biggest_input_buf:0             #当前连接的客户端中,最大的输入缓存
blocked_clients:0                      #正在等待阻塞命令(BLOP、BRPOP、BRPOPLPUSH)的客户端的数量
1.3、Memory:

内存消耗相关信息,记录了服务器的内存信息:

used_memory:894216               #Redis分配器分配给Redis的内存。例如,当Redis增加了存储数据时,需要的内存直接从分配器分配给它的内存里面取就可以了,也就是直接从used_memory取。而Redis分配器分配给Redis的内存,是从操作系统分配给Redis的内存里面取的(单位是字节)
used_memory_human:873.26K        #以人类可读格式显示Redis消耗的内存
used_memory_rss:2691072          #操作系统分配给Redis的内存。也就是Redis占用的内存大小。这个值和top指令输出的RES列结果是一样的。RES列结果就表示Redis进程真正使用的物理内存(单位是字节)
used_memory_peak:914160          #Redis的内存消耗峰值(单位是字节)
used_memory_peak_human:892.73K   #以人类可读的格式返回Redis的内存消耗峰值
used_memory_lua:35840            #Lua引擎所使用的内存大小(单位是字节)
mem_fragmentation_ratio:3.01     # used_memory_rss和used_memory之间的比率
mem_allocator:jemalloc-3.6.0     #在编译时指定的,Redis所使用的内存分配器。可以是libc、jemalloc或者tcmalloc理想情况下,used_memory_rss的值应该只比used_memory稍微高一点。当rss >used,且两者的值相差较大时,表示存在(内部或者外部的)内存碎片。内存碎片的比率可以通过mem_fragmentation_ratio的值看出;当used>rss时,表示Redis的部分内存被操作系统换出到交换空间,在这种情况下,操作可能会产生明显的延迟。
used_memory                      #是你的Redis实例中所有key及其value占用的内存大小;
used_memory_rss                  #是操作系统实际分配给Redis进程的内存。这个值一般是大于used_memory的,因为Redis的内存分配策略会产生内存碎片。
used_fragmentation_ratio         #就是内存碎片的比率,正常情况下是1左右,如果大于1比如1.8说明内存碎片很严重了

在使用redis经常会因为memory引发一些列的问题。像因为内存交换产生的性能问题以及延迟问题等。

(1)使用Hash Redis在储存小于100个字段的Hash结构上,其存储效率是非常高的

(2)设置key的过期时间

(3)回收key

(4)另外一定要配置/proc/sys/vm/min_free_kbytes 让系统及时回收内存
echo 102400 > /proc/sys/vm/min_free_kbytes 设置100m开始回收内存

1.4、Persistence:

记录了RDB持久化和AOF持久化有关的信息

loading:0                           #一个标志值,记录了服务器是否正在载入持久化文件
rdb_changes_since_last_save:0       #距离最后一次成功创建持久化文件之后,改变了多少个键值
rdb_bgsave_in_progress:0            #一个标志值,记录服务器是否正在创建RDB文件
rdb_last_save_time:1427189587       #最近一次成功创建RDB文件的UNIX时间戳
rdb_last_bgsave_status:ok           #一个标志值,记录了最后一次创建RDB文件的结果是成功还是失败
rdb_last_bgsave_time_sec:0          #记录最后一次创建RDB文件耗费的秒数
rdb_current_bgsave_time_sec:-1      #如果服务器正在创建RDB文件,那么这个值记录的就是当前的创建RDB操作已经耗费了多长时间(单位为秒)
aof_enabled:0                       #一个标志值,记录了AOF是否处于打开状态
aof_rewrite_in_progress:0           #一个标志值,记录了服务器是否正在创建AOF文件
aof_rewrite_scheduled:0             #一个标志值,记录了RDB文件创建完之后,是否需要执行预约的AOF重写操作
aof_last_rewrite_time_sec:-1        #记录了最后一次AOF重写操作的耗时
aof_current_rewrite_time_sec:-1     #如果服务器正在进行AOF重写操作,那么这个值记录的就是当前重写操作已经耗费的时间(单位是秒)
aof_last_bgrewrite_status:ok        #一个标志值,记录了最后一次重写AOF文件的结果是成功还是失败

如果AOF持久化功能处于开启状态,那么在Persistence部分还会加上以下域:

aof_current_size:14301           #AOF文件目前的大小
aof_base_size:14301              #服务器启动时或者最近一次执行AOF重写之后,AOF文件的大小
aof_pending_rewrite:0            #一个标志值,记录了是否有AOF重写操作在等待RDB文件创建完之后执行
aof_buffer_length:0              # AOF缓冲区的大小
aof_rewrite_buffer_length:0      #AOF重写缓冲区的大小
aof_pending_bio_fsync:0          #在后台I/0队列里面,等待执行的fsync数量
aof_delayed_fsync:0              #被延迟执行的fsync数量
 1.5、Stats:

一般统计

total_connections_received:8     #服务器已经接受的连接请求数量
total_commands_processed:10673   #服务器已经执行的命令数量
instantaneous_ops_per_sec:0      #服务器每秒中执行的命令数量
rejected_connections:0           #因为最大客户端数量限制而被拒绝的连接请求数量
expired_keys:0                   #因为过期而被自动删除的数据库键数量
evicted_keys:0                   #因为最大内存容量限制而被驱逐(evict)的键数量
keyspace_hits:1                  #查找数据库键成功的次数
keyspace_misses:0                #查找数据库键失败的次数
pubsub_channels:0                #目前被订阅的频道数量
pubsub_patterns:0                #目前被订阅的模式数量
latest_fork_usec:159             #最近一次fork()操作耗费的时间(毫秒)

因为Redis是个单线程模型,客户端过来的命令是按照顺序执行的。因此网络问题、慢命令会造成阻塞导致redis性能下降。

如果发生命令阻塞就可以看到每秒命令处理数在明显下降。要分析解决这个性能问题,需要跟踪命令处理数的数量和延迟时间。

1.6、CPU

CPU消耗统计

used_cpu_sys:75.46               #Redis服务器耗费的系统CPU
used_cpu_user:90.12              #Redis服务器耗费的用户CPU
used_cpu_sys_children:0.00       #Redis后台进程耗费的系统CPU
used_cpu_user_children:0.00      #Redis后台进程耗费的用户CPU
1.7、Replication:

主从同步信息

1.8、Cluster:

集群部分

1.9、Keyspace:

数据库相关统计

1.10、错误指标:

包括Error相关参数,这些指标显示了错误日志和错误类型。

2、其他命令

Redis的监控还可以通过其他命令进行,例如:

  • get命令:用于获取慢查询日志条目数、重置慢查询日志。2
  • len命令:用于获取慢查询日志条目数。
  • reset命令:用于重置慢查询日志。
3、工具监控redis

如 lepus

二、cpu高常见原因

在使用Redis时,总会碰到一些redis-server端CPU及内存占用比较高的问题,下面看下常见原因:

1、短连接导致CPU高

QPS(每秒查询率,Queries-per-second)不高,从监控看CPU确实偏高。

短连接与长连接差距比较大,原因来自两方面:

  • 每次重新建连接引入的网络开销。
  • 释放连接时,redis-server需消耗额外的CPU周期做清理工作。(这一点可以尝试从redis-server端做优化)

2、info命令导致CPU高

频繁执行info时通过perf分析发现getClientsMaxBuffers、getClientOutputBufferMemoryUsage及getMemoryOverheadData这几个函数占用CPU比较高。

3、pipeline导致内存占用高

4、Big Key导致内存占用高

4.1、Big Key介绍

Big Key就是某个key对应的value很大,占用的redis空间很大,本质上是大value问题。key往往是程序可以自行设置的,value往往不受程序控制,因此可能导致value很大。

4.2、降低性能原因

redis中这些Big Key对应的value值很大,在序列化/反序列化过程中花费的时间很大,因此当我们操作Big Key时,通常比较耗时,这就可能导致redis发生阻塞,从而降低redis性能。

4.3、危害

(1)阻塞请求

Big Key对应的value较大,我们对其进行读写的时候,需要耗费较长的时间,这样就可能阻塞后续的请求处理。Redis的核心线程是单线程,单线程中请求任务的处理是串行的,前面的任务完不成,后面的任务就处理不了。

(2)内存增大

读取Big Key耗费的内存比正常Key会有所增大,如果不断变大,可能会引发OOM(内存溢出),或达到redis的最大内存maxmemory设置值引发写阻塞或重要Key被逐出。

(3)阻塞网络

读取单value较大时会占用服务器网卡较多带宽,自身变慢的同时可能会影响该服务器上的其他Redis实例或者应用。

(4)影响主从同步、主从切换

删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换。

三、优化方法

1、尽量不要使用短连接;

2、尽量不要在连接数比较高的场景下频繁使用info;

3、使用pipeline时,要及时接收请求处理结果,且pipeline不宜一次打包太多请求;

4、Big Key问题

4.1、识别方法

(1)使用redis自带的命令识别

Redis官方客户端redis-cli加上--bigkeys参数,可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。
优点是可以在线扫描,不阻塞服务;缺点是信息较少,内容不够精确。

(2)使用debug object key命令

根据传入的对象(Key的名称)来对Key进行分析并返回大量数据,其中serializedlength的值为该Key的序列化长度,需要注意的是,Key的序列化长度并不等同于它在内存空间中的真实长度,此外,debug object属于调试命令,运行代价较大,并且在其运行时,进入Redis的其余请求将会被阻塞直到其执行完毕。并且每次只能查找单个key的信息,官方不推荐使用。

(3)redis-rdb-tools开源工具

这种方式是在redis实例上执行bgsave,bgsave会触发redis的快照备份,生成rdb持久化文件,然后对dump出来的rdb文件进行分析,找到其中的大key。

4.2、解决方法

对于String数据结构的话,减少存储的字符串的长度;对于List、Hash、Set、ZSet数据结构则是减少集合中元素的个数。

(1)对大Key进行拆分

将一个Big Key拆分为多个key-value这样的小Key,并确保每个key的成员数量或者大小在合理范围内,然后再进行存储,通过get不同的key或者使用mget批量获取。

(2)对大Key进行清理

对Redis中的大Key进行清理,从Redis中删除此类数据。Redis自4.0起提供了UNLINK命令,该命令能够以非阻塞的方式缓慢逐步的清理传入的Key,通过UNLINK,你可以安全的删除大Key甚至特大Key。

(3)监控Redis的内存、网络带宽、超时等指标

通过监控系统并设置合理的Redis内存报警阈值来提醒我们此时可能有大Key正在产生,如:Redis内存使用率超过70%,Redis内存1小时内增长率超过20%等。

(4)定期清理失效数据

如果某个Key有业务不断以增量方式写入大量的数据,并且忽略了其时效性,这样会导致大量的失效数据堆积。可以通过定时任务的方式,对失效数据进行清理。

(5)压缩value

使用序列化、压缩算法将key的大小控制在合理范围内,但是需要注意序列化、反序列化都会带来一定的消耗。如果压缩后,value还是很大,那么可以进一步对key进行拆分。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.luyixian.cn/news_show_1007817.aspx

如若内容造成侵权/违法违规/事实不符,请联系dt猫网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【三】安装k8s+kuboard, 拉取harbor镜像并执行yml文件

自己的配置 我在尊云上两百多买了三台2c4g的服务器,其实买两台就够了。 修改服务网卡掩码 确保几台服务器内网之间可以ping通 以尊云为例,vi /etc/sysconfig/network-scripts/ifcfg-eth1 修NETMASK值为255.0.0.0,重启服务器,尝试…

J-Flash 导入AIR32F103x下载算法直接下载程序

一、下载AIR32F103x SDK luatos-soc-air32f103: Air32f103_Firmware_Library (gitee.com)https://gitee.com/openLuat/luatos-soc-air32f103 二、打开J-Flash根目录,如下图所示 三、新建文件夹\Devices\Air32 四、复制下载算法文件到此文件夹\Devices\Air32下 下…

SpringCloudAlibaba 网关gateway整合sentinel日志默认路径修改

SpringCloudAlibaba 网关gateway整合sentinel 实现网关限流熔断 问题提出 今天运维突然告诉我 在服务器上内存满了 原因是nacos日志高达3G,然后将日志文件发给我看了一下之后才发现是gateway整合sentinel使用了默认日志地址导致日志生成地址直接存在与根路径下而且一下存在多…

C语言之指针(四)

一、前言 哈喽大家好,经过前三次的学习,我们已经了解到了指针的诸多概念,同时也分别从计算机内存、&符号、机器位数和野指针等多方面去研究指针,那么接下来,我们要研究的是关于指针在数组中的应用,在此…

linux查看服务器登录成功和登录失败的命令

last 查看成功登录服务器的信息,包括ip,时间,登录用户,时长。lastb 查看登录服务器失败的信息。 last命令实例: 其他参数: -a:把从何处登入系统的主机名称或ip地址,显示在最后一行…

leetcode判断子序列

本题中,我们可以删除原始字符串的一些字符但是不能改变其他字符的位置,这种求子序列的题都可以用动态规划来解决。 首先我们要确定dp数组的定义,这里我们将dp数组定义为dp[i][j] 表示以下标i-1为结尾的字符串s,和以下标j-1为结尾的…

29-Java组合实体模式 (Composite Entity Pattern)

Java组合实体模式 实现范例 组合实体模式(Composite Entity Pattern)用在 EJB 持久化机制中一个组合实体是一个 EJB 实体 bean,代表了对象的图解当更新一个组合实体时,内部依赖对象 beans 会自动更新,因为它们是由 EJB…

vscode的 c++ 环境搭建

2024.3.11 一、vscode的安装 Visual Studio Code - Code Editing. Redefinedhttps://code.visualstudio.com/#alt-downloads点击下载即可 (普通的软件安装,这里跳过) 安装完后,下载 C/C 和 C/C Extension Pack 两个模块 二、 M…

UI自动化、性能、API测试一体平台:RunnerGo

UI自动化测试已经成为现代软件开发过程中不可或缺的一部分。它能够提供诸多优势,包括提高测试效率、减少人力成本、提升软件质量等。同时,可视化工具为UI自动化测试带来了更多便利和灵活性。RunnerGo近期上线脚本录制器,根据你的测试操作直接…

【数据分析】数据分析介绍

专栏文章索引:【数据分析】专栏文章索引 目录 一、介绍 二、生活中的数据分析 1.无处不在的数据 2.为什么要进行数据分析? 三、数据挖掘案例 1.案例分析 一、介绍 数据采集:数据采集是指从不同来源收集原始数据的过程,包括…

基于jsp+mysql+Spring+mybatis的SSM汽车保险理赔管理系统设计和实现

基于jspmysqlSpringmybatis的SSM汽车保险理赔管理系统设计和实现 博主介绍:多年java开发经验,专注Java开发、定制、远程、文档编写指导等,csdn特邀作者、专注于Java技术领域 作者主页 央顺技术团队 Java毕设项目精品实战案例《1000套》 欢迎点赞 收藏 ⭐…

产品必会的30个Axure使用技巧

1. 安装Axure后要做的第一件事 如果系统崩溃后,再次进入时,系统一般会提示恢复最近备份的文件。也可以通过文件→从“备份中恢复”找回最新的版本。 2. 必须会的快捷键 快捷键不需要刻意去记忆,经常使用就熟记于心 3. 日常技巧汇总 &#…

【Stable Diffusion】入门-03:图生图基本步骤+参数解读

目录 1 图生图原理2 基本步骤2.1 导入图片2.2 书写提示词2.3 参数调整 3 随机种子的含义4 拓展应用 1 图生图原理 当提示词不足以表达你的想法,或者你希望以一个更为简单清晰的方式传递一些要求的时候,可以给AI输入一张图片,此时图片和文字是…

rust学习(简单链表)

编写一个简单链表&#xff0c;主要遇到的问题就是next指针&#xff08;按照C的写法&#xff09;的数据如何定义。按照网上的建议&#xff0c;一般定义如下&#xff1a; struct Node {pub value:u32,pub next:Option<Rc<RefCell<Node>>>, //1 }1.用Option主要…

CSS 文档流

是指页面上的元素在摆放的时候所占用的空间&#xff0c;也泛指页面元素放置的位置。 块元素&#xff1a;比如li标签或者h1这种&#xff0c;都是默认自上而下摆放的。内联标签&#xff1a;如果是span标签或者strong标签&#xff0c;它是从左到右进行摆放的。 有些场景并非得从…

HTML 学习笔记(十)块和内联

每个HTML元素都有一个默认的显示值&#xff0c;显示值又可以再分为block(块)和inline(内联) 一、块元素 通过F12进入浏览器开发者模式查看该元素会发现其所占宽度为整个网页的宽度 1.div标签 通过div标签将一些元素装进"盒子"&#xff0c;从而对盒子中的全部元素…

mysql5.6---windows和linux安装教程和忘记密码怎么办

一、windows安装 1.完成解压 解压完成之后将其放到你喜欢的地址当中去&#xff0c;这里我默认放在了D盘&#xff0c;这是我的根目录 2.配置环境变量 我的电脑->属性->高级->环境变量->系统变量 选择PATH,在其后面添加: (注意自己的安装地址) D:\mysql-5.6.49…

产品必会的6个Axure使用技巧(高阶)

1. 事件也可以复制/剪切/粘贴 只需要选中事件&#xff0c;复制/剪切&#xff0c;再选择其它事件&#xff0c;即可粘贴到这个事件上。同时支持跨页面的复制粘贴。 2. Axure支持复制粘贴Excel里的表格 具体操作 在excel里复制具体内容&#xff0c;如下图&#xff1a; 进入axur…

phpcms上传导致getshell详解及案例

一、环境 这里我根据大佬的文章将环境复原 phpcms上传导致getshell详解及案例 | 离别歌 回忆phpcms头像上传漏洞以及后续影响 | 离别歌 二、代码&#xff1a; php&#xff1a; <?php header("Content-Type:text/html; charsetutf-8"); require_once(pclzip…

交叉注意力融合时域、频域特征的FFT + CNN -BiLSTM-CrossAttention电能质量扰动识别模型

往期精彩内容&#xff1a; 电能质量扰动信号数据介绍与分类-Python实现-CSDN博客 Python电能质量扰动信号分类(一)基于LSTM模型的一维信号分类-CSDN博客 Python电能质量扰动信号分类(二)基于CNN模型的一维信号分类-CSDN博客 Python电能质量扰动信号分类(三)基于Transformer…