redis监控

一、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.mzph.cn/news/744291.shtml

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

相关文章

C语言易错知识点:scanf函数

scanf在C语言学习中比较常用,但因为其涉及屏幕缓冲区导致有的时候会调入陷阱,下面分享一下常见的需要注意的事项: 1.输入末尾带有回车\n 当我们输入数据后,最后按下回车时,屏幕缓冲区的末尾都会含有这个字符 scanf的…

Web安全攻防措施

2024最新Web安全攻防教程资料PPT大合集(143份).zip 输入验证和过滤:对用户输入进行严格的验证和过滤,以防止SQL注入、跨站脚本攻击(XSS)等。例如,对特殊字符进行转义处理,限制输入…

代码书写在if __name__ == ‘__main__‘前后的区别

if __name__ __main__这个东西,所有见过python代码的程序猿们一定都不会陌生。为方便理解,有人直接把它等同于java中的主函数。我们今天不是为了来探讨它和Java主函数的异同的(因为我已经忘了Java主函数的细节了,也懒得再回顾…&…

leetcode110.平衡二叉树

之前没有通过的样例 return语句只写了一个 return abs(l-r)<1缺少了 isBalanced(root->left)&&isBalanced(root->right);补上就好了 class Solution { public:bool isBalanced(TreeNode* root) {if(!root){return true;}int lgetHeight(root->left);i…

(学习日记)2024.03.11:UCOSIII第十三节:使用优先级的流程 (持续更新)

写在前面&#xff1a; 由于时间的不足与学习的碎片化&#xff0c;写博客变得有些奢侈。 但是对于记录学习&#xff08;忘了以后能快速复习&#xff09;的渴望一天天变得强烈。 既然如此 不如以天为单位&#xff0c;以时间为顺序&#xff0c;仅仅将博客当做一个知识学习的目录&a…

vulntarget-k - 内网渗透

标签 xxl-job rce Spring-Cloud-CVE-2022-22947 nacos auth bypass iox 靶机难度比较简单&#xff0c;都是用用 exp 就好了 拓扑图 网卡设置 首先需要使用虚拟网络编辑器&#xff0c;增加 VMnet1、VMnet2、VMnet3 对三张网卡设置子网 IP VMnet1 192.168.100.0 VMnet2 1…

EM算法详解

EM(Expectation-Maximum)算法也称期望最大化算法,曾入选“数据挖掘十大算法”中,可见EM算法在机器学习、数据挖掘中的影响力。EM算法是最常见的隐变量估计方法,在机器学习中有极为广泛的用途,例如常被用来学习高斯混合模型(Gaussian mixture model,简称GMM)的参数;隐…

SIP-7043 20W SIP网络有源吸顶喇叭

SIP-7043 20W SIP网络有源吸顶喇叭 一、描述 18123651365微信 声卡喊话IP喇叭&#xff0c;IP网络吸顶天花喇叭 SIP-7043VP是我司的一款SIP网络有源吸顶喇叭&#xff0c;具有10/100M以太网接口&#xff0c;内置有一个高品质扬声器&#xff0c;将网络音源通过自带的功放和喇叭…

jpg格式图片怎么生成二维码?扫码看图在线制作方法

多张jpg格式的图片如何做成二维码展示&#xff1f;jpg是现在最常用的一种图片格式&#xff0c;不管是拍摄的照片、设计图片或是其他类型的图片基本上都是这种格式。那么如何将jpg格式的图片放到二维码中展示呢&#xff1f;通过下面的文章内容来分享一下图片制作二维码在线的技巧…

scrcpy远程投屏控制Android

下载 下载后解压压缩包scrcpy-win64-v2.4.zip scrcpy连接手机 1. 有线连接 - 手机开启开发者选项&#xff0c;并开启USB调试&#xff0c;连接电脑&#xff0c;华为手机示例解压scrcpy&#xff0c;在scrcpy目录下打开终端&#xff0c;&#xff08;或添加scrcpy路径为环境变…

前端面试题 ===> 【HTML】

HTML面试题总结 1. 对 HTML 语义化的理解 去掉或者丢失样式的时候能够让页面呈现出清晰的结构&#xff1b;代码结构清晰&#xff0c;方便团队的管理和维护&#xff0c;并且语义化更具有可读性&#xff0c;减少差异化&#xff1b;提升用户体验&#xff1b; 例如&#xff1a;ti…

【数组】41. 缺失的第一个正数【困难】

缺失的第一个正数 给你一个未排序的整数数组 nums &#xff0c;请你找出其中没有出现的最小的正整数。请你实现时间复杂度为 O(n) 并且只使用常数级别额外空间的解决方案。 示例 1 输入&#xff1a;nums [1,2,0]输出&#xff1a;3 示例 2 输入&#xff1a;nums [3,4,-1,…

同态滤波算法详解

同态滤波是一种用于增强图像的方法&#xff0c;特别适用于去除图像中的照明不均和阴影。该算法基于照射反射模型&#xff0c;将图像分解为两个分量&#xff1a;照射分量&#xff08;illumination component&#xff09;和反射分量&#xff08;reflection component&#xff09;…

精品基于Uniapp+ssm停车场预约缴费微信小程序的设计与实现

《[含文档PPT源码等]精品微信小程序基于Uniappssm停车场微信小程序的设计与实现》该项目含有源码、文档、PPT、配套开发软件、软件安装教程、项目发布教程&#xff01; 软件开发环境及开发工具&#xff1a; 开发语言&#xff1a;Java 后台框架&#xff1a;ssm 安卓框架&…

Python打印输出Linux中最常用的linux命令之示例

一、Linux中的~/.bash_history文件说明&#xff1a; 该文件保存了linux系统中运行过的命令的历史。使用该文件来获取命令的列表&#xff0c;并统计命令的执行次数。统计时&#xff0c;只统计命令的名称&#xff0c;以不同参数调用相同的命令也视为同一命令。 二、示例代码&am…

csp模拟题(201604-2,俄罗斯方块模拟下坠)

题目 问题描述 俄罗斯方块是俄罗斯人阿列克谢帕基特诺夫发明的一款休闲游戏。   游戏在一个15行10列的方格图上进行&#xff0c;方格图上的每一个格子可能已经放置了方块&#xff0c;或者没有放置方块。每一轮&#xff0c;都会有一个新的由4个小方块组成的板块从方格图的上方…

一文掌握Python控制语句操作及实例详解

在 Python 中,控制语句是用于流程控制的重要工具,可以帮助我们根据不同的条件执行不同的代码块。本文将带你快速掌握 Python 中的控制语句操作,并通过实际例子让你更好地理解。 1. 条件控制语句:if-elif-else Python中的条件判断主要依赖于if,elif(else if)和else语句…

应急响应实战笔记03权限维持篇(6)

0x00 前言 在渗透测试中&#xff0c;有三个非常经典的渗透测试框架----Metasploit、Empire、Cobalt Strike。 那么&#xff0c;通过漏洞获取到目标主机权限后&#xff0c;如何利用框架获得持久性权限呢&#xff1f; 0x01 MSF权限维持 使用MSF维持权限的前提是先获得一个met…

蓝桥集训之正则问题

蓝桥集训之正则问题 核心思想&#xff1a;递归 归结到一棵树 向上返回x数量 #include<iostream>#include<cstring>using namespace std;int k;string str;int dfs(){int res0; //记录x数量while(k<str.size()){if(str[k] (){k ; //跳过左括号res dfs();k …

【C#】【SAP2000】OAPI文档案例详解

创建一个简单的结构模型,运行分析,提取结果,并将结果与手算值进行比较。 以下是详细的代码解析: 开头部分是一些using语句,引用了必要的命名空间,特别是SAP2000v1, 它包含了SAP2000 API的类和方法。 在Main方法中,首先定义了一些变量,用于控制是启动一个新的SAP2000实例还是附…