Redis - 哨兵(Sentinel)

news2024/11/24 5:29:36

        Redis 的主从复制模式下,⼀旦主节点由于故障不能提供服务,需要⼈⼯进⾏主从切换,同时⼤量 的客⼾端需要被通知切换到新的主节点上,对于上了⼀定规模的应⽤来说,这种⽅案是⽆法接受的, 于是Redis从2.8开始提供了RedisSentinel(哨兵)加个来解决这个问题。本章主要内容如下:

  • RedisSentinel的概念
  • RedisSentinel的部署
  • RedisSentinel命令
  • RedisSentinel客⼾端
  • RedisSentinel实现原理

一、基本概念

        由于对Redis的许多概念都有不同的名词解释,所以在介绍RedisSentinel之前,先对⼏个名词 概念进⾏必要的说明,如表所⽰。

Redis Sentinel 相关名词解释

名词逻辑结构物理结构
主节点Redis 主服务⼀个独⽴的redis-server进程
从节点Redis 从服务⼀个独⽴的redis-server进程
Redis 数据节点主从节点主节点和从节点的进程
哨兵节点监控Redis数据节点的节点⼀个独⽴的redis-sentinel进程
哨兵节点集合若⼲哨兵节点的抽象组合若⼲redis-sentinel 进程
Redis 哨兵(Sentinel)Redis 提供的⾼可⽤⽅案哨兵节点集合 和 Redis主从节点
应⽤⽅泛指⼀个多多个客⼾端⼀个或多个连接Redis的进程

        Redis Sentinel 是Redis 的⾼可⽤实现⽅案,在实际的⽣产环境中,对提⾼整个系统的⾼可⽤是⾮常有 帮助的,本节⾸先整体梳理主从复制模式下故障处理可能产⽣的问题,⽽后引出⾼可⽤的概念,最后 重点分析RedisSentinel的基本架构、优势,以及是如何实现⾼可⽤的。

1.1、主从复制的问题

        Redis 的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作⽤: 第⼀,作为主节点的⼀个备份,⼀旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上 来,并且保证数据尽量不丢失(主从复制表现为最终⼀致性)。第⼆,从节点可以分担主节点上的读 压⼒,让主节点只承担写请求的处理,将所有的读请求负载均衡到各个从节点上。

  1. 主节点发⽣故障时,进⾏主备切换的过程是复杂的,需要完全的⼈⼯参与,导致故障恢复时间⽆法 保障。
  2. 主节点可以将读压⼒分散出去,但写压⼒/存储压⼒是⽆法被分担的,还是受到单机的限制。

        其中第⼀个问题是⾼可⽤问题,即Redis哨兵主要解决的问题。第⼆个问题是属于存储分布式的问 题,留给Redis集群去解决,本章我们集中讨论第⼀个问题。

1.2、⼈⼯恢复主节点故障

        Redis 主从复制模式下,主节点故障后需要进⾏的⼈⼯⼯作是⽐较繁琐的,在图中⼤致展⽰了整体过程。

Redis 主节点故障后需要进⾏的操作

 

 

 

 

 

 1)运维⼈员通过监控系统,发现Redis主节点故障宕机。

 2)运维⼈员从所有节点中,选择⼀个(此处选择了slave1)执⾏slaveofnoone,使其作为新的主 节点。

 3)运维⼈员让剩余从节点(此处为slave2)执⾏slaveof{newMasterIp}{newMasterPort}从新主节 点开始数据同步。

 4)更新应⽤⽅连接的主节点信息到{newMasterIp}{newMasterPort}。

 5)如果原来的主节点恢复,执⾏slaveof{newMasterIp}{newMasterPort}让其成为⼀个从节点。 上述过程可以看到基本需要⼈⼯介⼊,⽆法被认为架构是⾼可⽤的。⽽这就是RedisSentinel所要做 的。

1.3、哨兵⾃动恢复主节点故障

        当主节点出现故障时,RedisSentinel能⾃动完成故障发现和故障转移,并通知应⽤⽅,从⽽实现 真正的⾼可⽤。

        Redis Sentinel 是⼀个分布式架构,其中包含若⼲个Sentinel节点和Redis数据节点,每个 Sentinel 节点会对数据节点和其余Sentinel节点进⾏监控,当它发现节点不可达时,会对节点做下线表⽰。如果下线的是主节点,它还会和其他的Sentinel节点进⾏“协商”,当⼤多数Sentinel节点对 主节点不可达这个结论达成共识之后,它们会在内部“选举”出⼀个领导节点来完成⾃动故障转移的 ⼯作,同时将这个变化实时通知给Redis应⽤⽅。整个过程是完全⾃动的,不需要⼈⼯介⼊。整体的 架构如图所⽰。

这⾥的分布式架构是指:Redis数据节点、Sentinel节点集合、客⼾端分布在多个物理节点上,不要与后边介绍的RedisCluster分布式混淆。

Redis Sentinel 架构

        Redis Sentinel 相⽐于主从复制模式是多了若⼲(建议保持奇数)Sentinel节点⽤于实现监控数据节 点,哨兵节点会定期监控所有节点(包含数据节点和其他哨兵节点)。针对主节点故障的情况,故障 转移流程⼤致如下:

 1)主节点故障,从节点同步连接中断,主从复制停⽌。

 2)哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商,达成多数认   同主 节点故障的共识。这步主要是防⽌该情况:出故障的不是主节点,⽽是发现故障的哨兵节       点,该情况 经常发⽣于哨兵节点的⽹络被孤⽴的场景下。

 3)哨兵节点之间使⽤Raft算法选举出⼀个领导⻆⾊,由该节点负责后续的故障转移⼯作。

 4)哨兵领导者开始执⾏故障转移:从节点中选择⼀个作为新主节点;让其他从节点同步新主节点;通知应⽤层转移到新主节点。

 通过上⾯的介绍,可以看出RedisSentinel具有以下⼏个功能:

  • 监控:Sentinel节点会定期检测Redis数据节点、其余哨兵节点是否可达。
  • 故障转移:实现从节点晋升(promotion)为主节点并维护后续正确的主从关系。
  • 通知:Sentinel节点会将故障转移的结果通知给应⽤⽅。

二、安装部署(基于docker)

2.1、准备⼯作

1) 安装docker和docker-compose

docker-compose 的安装

 # ubuntu
 apt install docker-compose

 # centos
 yum install docker-compose

 

2) 停⽌之前的redis-server

 # 停⽌
 redis-server
 service redis-server stop

 # 停⽌ redis-sentinel 如果已经有的话. 
 service redis-sentinel stop

 3) 使⽤docker获取redis镜像

 docker pull redis:5.0.

2.2、编排redis主从节点

1) 编写 docker-compose.yml

 创建 /root/redis/docker-compose.yml ,同时cd到yml所在⽬录中.

注意: docker中可以通过容器名字,作为ip地址,进⾏相互之间的访问.

version: '3.7'
services:
     master:
         image: 'redis:5.0.9'
         container_name: redis-master
         restart: always
         command: redis-server --appendonly yes
         ports: 
            - 6379:6379

     slave1:
         image: 'redis:5.0.9'
         container_name: redis-slave1
         restart: always
         command: redis-server --appendonly yes --slaveof redis-master 6379
         ports:
            - 6380:6379
     slave2:
         image: 'redis:5.0.9'
         container_name: redis-slave2
         restart: always
         command: redis-server --appendonly yes --slaveof redis-master 6379
         ports:
            - 6381:6379

也可以直接在windows上使⽤vscode编辑好yml,然后在上传到 linux 上.

2) 启动所有容器

docker-compose up -d

        如果启动后发现前⾯的配置有误,需要重新操作,使⽤ docker-compose down 即可停⽌并删除 刚才创建好的容器.

3) 查看运⾏⽇志

 docker-compose logs

上 述操作必须保证⼯作⽬录在yml的同级⽬录中,才能⼯作.

4) 验证

连接主节点

redis-cli -p 6379
 127.0.0.1:6379> info replication
 # Replication
 role:master
 connected_slaves:2
 slave0:ip=172.22.0.3,port=6379,state=online,offset=348,lag=1
 slave1:ip=172.22.0.4,port=6379,state=online,offset=348,lag=1
 master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:348
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:348

连接从节点

redis-cli -p 6380
 127.0.0.1:6380> info replication
 # Replication
 role:slave
 master_host:redis-master
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:10
 master_sync_in_progress:0
 slave_repl_offset:446
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:446
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:446
redis-cli -p 6381
 127.0.0.1:6381> info replication
 # Replication
 role:slave
 master_host:redis-master
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:7
 master_sync_in_progress:0
 slave_repl_offset:516
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:a22196b425ab42ddfd222cc5a64d53acffeb3e63
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:516
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:1
 repl_backlog_histlen:516

2.3、编排 redis-sentinel节点

        也可以把redis-sentinel放到和上⾯的redis的同⼀个yml中进⾏容器编排.此处分成两组,主要是为 了两⽅⾯:

  • 观察⽇志⽅便
  • 确保redis主从节点启动之后才启动redis-sentinel.如果先启动redis-sentinel的话,可能触发额 外的选举过程,混淆视听.(不是说先启动哨兵不⾏,⽽是观察的结果可能存在⼀定随机性).

1) 编写 docker-compose.yml

创建  /root/redis-sentinel/docker-compose.yml  ,同时cd到yml所在⽬录中.

注意: 每个⽬录中只能存在⼀个docker-compose.yml⽂件.

 version: '3.7'
 services:
     sentinel1:
         image: 'redis:5.0.9'
         container_name: redis-sentinel-1
         restart: always
         command: redis-sentinel /etc/redis/sentinel.conf
         volumes:
            - ./sentinel1.conf:/etc/redis/sentinel.conf
         ports:
            - 26379:26379
     sentinel2:
         image: 'redis:5.0.9'
         container_name: redis-sentinel-2
         restart: always
         command: redis-sentinel /etc/redis/sentinel.conf
         volumes:
            - ./sentinel2.conf:/etc/redis/sentinel.conf
         ports:
            - 26380:26379
     sentinel3:
             image: 'redis:5.0.9'
             container_name: redis-sentinel-3
             restart: always
             command: redis-sentinel /etc/redis/sentinel.conf
             volumes:
                - ./sentinel3.conf:/etc/redis/sentinel.conf
             ports:
                - 26381:26379
 networks:
     default:
         external:
             name: redis-data_default  

也可以直接在windows上使⽤vscode编辑好yml,然后在上传到linux上.

2) 创建配置⽂件

创建 sentinel1.conf  sentinel2.conf  sentinel3.conf .三份⽂件的内容是完全相同的.

都放到 /root/redis-sentinel/ ⽬录中.

 bind 0.0.0.0
 port 26379
 sentinel monitor redis-master redis-master 6379 2
 sentinel down-after-milliseconds redis-master 1000

理解 sentinel monitor

sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数
  • 主节点名,这个是哨兵内部⾃⼰起的名字.
  • 主节点ip,部署redis-master的设备ip.此处由于是使⽤docker,可以直接写docker的容器名,会 被⾃动 DNS 成对应的容器ip
  • 主节点端⼝,不解释.
  • 法定票数,哨兵需要判定主节点是否挂了.但是有的时候可能因为特殊情况,⽐如主节点仍然⼯作正 常,但是哨兵节点⾃⼰⽹络出问题了,⽆法访问到主节点了.此时就可能会使该哨兵节点认为主节点 下线,出现误判.使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法.需要多个哨兵都认为 主节点挂了,票数>=法定票数之后,才会真的认为主节点是挂了.

理解 sentinel down-after-milliseconds

  • 主节点和哨兵之间通过⼼跳包来进⾏沟通.如果⼼跳包在指定的时间内还没回来,就视为是节点出现 故障.

既然内容相同,为啥要创建多份配置⽂件?

redis-sentinel 在运⾏中可能会对配置进⾏rewrite,修改⽂件内容.如果⽤⼀份⽂件,就可能出现修改 混乱的情况.

3) 启动所有容器

docker-compose up -d

如果启动后发现前⾯的配置有误,需要重新操作,使⽤docker-compose down 即可停⽌并删除刚才创建好的容器.

4) 查看运⾏⽇志

docker-compose logs

 上述操作必须保证⼯作⽬录在yml的同级⽬录中,才能⼯作.

可以看到,哨兵节点已经通过主节点,认识到了对应的从节点.

5) 观察redis-sentinel 的配置rewrite

再次打开哨兵的配置⽂件,发现⽂件内容已经被⾃动修改了.

 bind 0.0.0.0
 port 26379
 sentinel myid 4d2d562860b4cdd478e56494a01e5c787246b6aa
 sentinel deny-scripts-reconfig yes
 # Generated by CONFIG REWRITE
 dir "/data"
 sentinel monitor redis-master 172.22.0.4 6379 2
 sentinel down-after-milliseconds redis-master 1000
 sentinel config-epoch redis-master 1
 sentinel leader-epoch redis-master 1
 sentinel known-replica redis-master 172.22.0.2 6379
 sentinel known-replica redis-master 172.22.0.3 6379
 sentinel known-sentinel redis-master 172.22.0.7 26379 
 f718caed536d178f5ea6d1316d09407cfae43dd2
 sentinel known-sentinel redis-master 172.22.0.5 26379 
 2ab6de82279bb77f8397c309d36238f51273e80a
 sentinel current-epoch 1

# Generated by CONFIG REWRITE 这⾥的内容就是⾃动修改的.

对⽐这三份⽂件,可以看到配置内容是存在差异的.

三、重新选举

3.1、redis-master 宕机之后

⼿动把 redis-master ⼲掉

docker stop redis-master

观察哨兵的⽇志,可以看到哨兵发现了主节点sdown,进⼀步的由于主节点宕机得票达到 master 被判定为odown.

  • 主观下线(SubjectivelyDown,SDown):哨兵感知到主节点没⼼跳了.判定为主观下线
  • 客观下线(ObjectivelyDown,ODown):多个哨兵达成⼀致意⻅,才能认为master确实下线了.

接下来,哨兵们挑选出了⼀个新的master.

此时,对于Redis来说仍然是可以正常使⽤的.

3.2、redis-master 重启之后

⼿动把 redis-master 启动起来

docker start redis-master

观察哨兵⽇志

可以看到刚才新启动的 redis-master 被当成了slave

使⽤redis-cli 也可以进⼀步的验证这⼀点

 127.0.0.1:6379> info replication
 # Replication
 role:slave
 master_host:172.22.0.4
 master_port:6379
 master_link_status:up
 master_last_io_seconds_ago:0
 master_sync_in_progress:0
 slave_repl_offset:324475
 slave_priority:100
 slave_read_only:1
 connected_slaves:0
 master_replid:ececc285a2892fba157318c77ebe1409f9c2254e
 master_replid2:0000000000000000000000000000000000000000
 master_repl_offset:324475
 second_repl_offset:-1
 repl_backlog_active:1
 repl_backlog_size:1048576
 repl_backlog_first_byte_offset:318295
 repl_backlog_histlen:6181

3.3、结论

  • Redis主节点如果宕机,哨兵会把其中的⼀个从节点,提拔成主节点.
  • 当之前的Redis主节点重启之后,这个主节点被加⼊到哨兵的监控中,但是只会被作为从节点使⽤.

四、选举原理

        假定当前环境如上⽅介绍,三个哨兵(sentenal1,sentenal2,sentenal3),⼀个主节点(redis-master),两 个从节点(redis-slave1,redis-slave2).

当主节点出现故障,就会触发重新⼀系列过程.

4.1、 主观下线

当redis-master 宕机,此时redis-master和三个哨兵之间的⼼跳包就没有了.

此时,站在三个哨兵的⻆度来看,redis-master出现严重故障.因此三个哨兵均会把redis-master判定 为主观下线(SDown)

4.2、客观下线

        此时,哨兵sentenal1,sentenal2,sentenal3均会对主节点故障这件事情进⾏投票.当故障得票数>=配置的法定票数之后,

sentinel monitor redis-master 172.22.0.4 6379 2

在这个地⽅配置的2,即为法定票数

此时意味着redis-master故障这个事情被做实了.此时触发客观下线(ODown)

4.3、选举出哨兵的leader

        接下来需要哨兵把剩余的slave中挑选出⼀个新的master.这个⼯作不需要所有的哨兵都参与.只需要 选出个代表(称为leader),由leader负责进⾏slave升级到master的提拔过程.

这个选举的过程涉及到 Raft 算法

假定一共三个哨兵节点,S1, S2, S3

  1. 每个哨兵节点都给其他所有哨兵节点,发起⼀个"拉票请求".(S1->S2,S1->S3,S2->S1,S2->S3, S3->S1,S3->S2)
  2. 收到拉票请求的节点,会回复⼀个"投票响应".响应的结果有两种可能,投or不投;⽐如S1给S2发了个投票请求,S2就会给S1返回投票响应.  到底S2是否要投S1呢?取决于S2是否给别⼈投过票了.(每个哨兵只有⼀票).  如果S2没有给别⼈投过票,换⽽⾔之,S1是第⼀个向S2拉票的,那么S2就会投S1.否则则不投.
  3. ⼀轮投票完成之后,发现得票超过半数的节点,⾃动成为leader;如果出现平票的情况(S1投S2,S2投S3,S3投S1,每⼈⼀票),就重新再投⼀次即可,这也是为啥建议哨兵节点设置成奇数个的原因.如果是偶数个,则增⼤了平票的概率,带来不必要的开销.
  4. leader 节点负责挑选⼀个slave成为新的master.当其他的sentenal发现新的master出现了,就 说明选举结束了.

简⽽⾔之,Raft算法的核⼼就是"先下⼿为强".谁率先发出了拉票请求,谁就有更⼤的概率成为leader.

这里的决定因素成了"⽹络延时".⽹络延时本⾝就带有⼀定随机性.

具体选出的哪个节点是leader,这个不重要,重要的是能选出⼀个节点即可.

4.4、leader 挑选出合适的slave成为新的 master

挑选规则:

  1. ⽐较优先级.优先级⾼(数值⼩的)的上位.优先级是配置⽂件中的配置项(slave-priority 或者 replica-priority ).
  2. ⽐较 replication offset 谁复制的数据多,⾼的上位.
  3. ⽐较 run id ,谁的id⼩,谁上位

当某个slave节点被指定为master之后,

  1. leader 指定该节点执⾏ slave no one ,成为master
  2. leader 指定剩余的slave节点,都依附于这个新master

五、⼩结

        上述过程,都是"⽆⼈值守",Redis⾃动完成的.这样做就解决了主节点宕机之后需要⼈⼯⼲预的问题, 提⾼了系统的稳定性和可⽤性.

⼀些注意事项:

  • 哨兵节点不能只有⼀个.否则哨兵节点挂了也会影响系统可⽤性.
  • 哨兵节点最好是奇数个.⽅便选举leader,得票更容易超过半数.
  • 哨兵节点不负责存储数据.仍然是redis主从节点负责存储.
  • 哨兵+主从复制解决的问题是"提⾼可⽤性",不能解决"数据极端情况下写丢失"的问题.
  • 哨兵+主从复制不能提⾼数据的存储容量.当我们需要存的数据接近或者超过机器的物理内存,这样 的结构就难以胜任了.

为了能存储更多的数据,就引⼊了集群.

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

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

相关文章

使用wordpress搭建简易的信息查询系统

背景 当前有这样的一个需求,要实现让客户能够自助登录系统查询一些个人的信息,市面上没有特别符合我的需求的产品,经过一段时间的研究,想出了一个用wordpress实现简易信息查询系统,有两种方式。 方式一:使…

探索 Python HTTP 的瑞士军刀:Requests 库

文章目录 探索 Python HTTP 的瑞士军刀:Requests 库第一部分:背景介绍第二部分:Requests 库是什么?第三部分:如何安装 Requests 库?第四部分:Requests 库的基本函数使用方法第五部分&#xff1a…

【青牛科技】 GC6153——TMI8152 的不二之选,可应用于摇头机等产品中

在电子工程领域,不断寻求性能更优、成本更低的解决方案是工程师们的永恒追求。今天,我们要为广大电子工程师带来一款极具竞争力的产品 —— GC6153,它将成为 TMI8152 的完美替代之选。 一、产品背景 随着科技的飞速发展,电子设备…

基于yolov8、yolov5的番茄成熟度检测识别系统(含UI界面、训练好的模型、Python代码、数据集)

摘要:番茄成熟度检测在农业生产及质量控制中起着至关重要的作用,不仅能帮助农民及时采摘成熟的番茄,还为自动化农业监测提供了可靠的数据支撑。本文介绍了一款基于YOLOv8、YOLOv5等深度学习框架的番茄成熟度检测模型,该模型使用了…

艾体宝干货丨微突发流量检测与分析:IOTA让网络监控更精准

网络流量中的微突发问题常常难以察觉,但它们可能对网络性能产生显著影响。这篇文章深入探讨了如何利用IOTA来捕捉和分析微突发,帮助您快速有效地解决网络中的突发流量问题。 什么是微突发(Microburst)流量? 微突发是…

论文略读: ALPAGASUS: TRAINING A BETTER ALPACA WITH FEWER DATA

ICLR 2024 1 背景 大模型通常需要在有监督指令数据集上进行指令微调来加强指令遵循能力 但是广泛使用的数据集包含许多具有不正确或不相关响应的低质量样本,这对大模型微调具有误导性——>论文提出了一种简单有效的数据选择策略,使用ChatGPT自动识别…

【Android】ANR监控治理技术方案

一、 背景 1、 bugly针对crash监控做的比较好,但是对anr监控,早期版本监听 /data/anr 目录的变化可以拿到数据,但是现在高版本已经没有权限监听此目录,当前数据非常少,结合历次数据来看对我们解决ANR问题没有任何帮助…

FreeRTOS学习11——时间片任务调度

时间片任务调度 时间片任务调度 时间片任务调度 概念:时间片调度主要针对优先级相同的任务,当多个任务的优先级相同时,任务调度器会在每一次系统时钟节拍到的时候切换任务,也就是说 CPU 轮流运行优先级相同的任务,每个…

怎么把模糊照片变清晰?4种方法助你修复图片清晰度!

在我们的日常生活中,模糊的图片常常成为影响视觉体验的一大障碍,无论是由于时间久远导致老照片分辨率降低,还是拍摄时因手抖造成的画面模糊,都会让我们的图片质量大打折扣。为了帮助你解决这一困扰,我们为你整理了四种…

Pytorch学习--神经网络--完整的模型验证套路

一、选取的图片 全部代码依托于该博客 二、代码(调用训练好的模型) import torch import torchvision from PIL import Image from model import *img_path "dog.png" image Image.open(img_path)print(image.size)transform torchvisi…

力扣 LeetCode 454. 四数相加II(Day3:哈希表)

解题思路: 使用map 四个数组两两一组 前两个数组的各个值遍历相加,和为key,出现的次数为value 后两个数组的各个值遍历相加,如果该值的负数能在map中找到(表示能抵消为0,符合题意四数之和为0&#xff0…

期权懂|交易股票期权该怎么操作?又该如何开户?

期权小懂每日分享期权知识,帮助期权新手及时有效地掌握即市趋势与新资讯! 交易股票期权该怎么操作?又该如何开户? 一、交易股票期权主要包括以下几个步骤: (1)选择交易平台‌: 选择…

Unity类银河战士恶魔城学习总结(P124 CharacterStats UI玩家的UI)

【Unity教程】从0编程制作类银河恶魔城游戏_哔哩哔哩_bilibili 教程源地址:https://www.udemy.com/course/2d-rpg-alexdev/ 本章节实现了玩家属性栏,仓库,物品栏UI的制作 UI_StatSlot.cs 这个脚本是用来在Unity的UI上显示玩家属性&#xf…

【SSL-RL】自监督强化学习:自预测表征 (SPR)算法

📢本篇文章是博主强化学习(RL)领域学习时,用于个人学习、研究或者欣赏使用,并基于博主对相关等领域的一些理解而记录的学习摘录和笔记,若有不当和侵权之处,指出后将会立即改正,还望谅…

Docker部署kafka集群

1,编写Docker Compose文件 编写一个docker-compose.yml文件来定义服务,以下定义了一个Zookeeper服务和三个Kafka Broker服务: 注意:把10.0.8.4替换成宿主IP version: 3.8services:zookeeper:image: bitnami/zookeeper:latestconta…

Qt滑动条美化自定义

效果展示 主要代码 头文件 下面是hi控件的头文件,我们继承一个Qt原生的滑动条类QSlider,然后在基类的基础上进行自定义,我会对重要的变量进行解析: class XSlider : public QSlider {Q_OBJECT public:explicit XSlider(QWidget…

wordpress实用功能A5资源网同款 隐藏下载框 支付框 需要登录才能查看隐藏的内容

实用功能 隐藏下载框 支付框 需要登录才能查看隐藏的内容, 个人网站防天朝申查实测有效 。 登录前,未登录: 登录后,已登录: 功能说明 该代码段的主要功能是隐藏支付框并为未 登录用户显示一条提示信息,告知他们需要…

Vue 简单入手

前端工程化(Front-end Engineering)指的是在前端开发中,通过一系列工具、流程和规范的整合,以提高开发效率、代码质量和可维护性的一种技术和实践方法。其核心目的是使得前端开发变得更高效、可扩展和可维护。 文章目录 一、Vue 项…

Spingboot 定时任务与拦截器(详细解释)

在 boot 环境中,一般来说,要实现定时任务,我们有两中方案,一种是使用 Spring 自带的定时 任务处理器 Scheduled 注解,另一种就是使用第三方框架 Quartz , Spring Boot 源自 SpringSpringMVC &#…

无人机+无人车+无人狗+无人船:互通互联技术探索详解

关于“无人机无人车机器狗(注:原文中的“无人狗”可能是一个笔误,因为在实际技术领域中,常用的是“机器狗”这一术语)无人船”的互通互联技术,以下是对其的详细探索与解析: 一、系统架构与关键…