Redis持久化主从哨兵分片集群

文章目录

    • 1. 单点Redis的问题
      • 数据丢失问题
      • 并发能力问题
      • 故障恢复问题
      • 存储能力问题
    • 2. Redis持久化 -> 数据丢失问题
      • RDB持久化
        • linux单机安装Redis步骤
        • RDB持久化与恢复示例
        • RDB机制
        • RDB配置示例
        • RDB的fork原理
        • 总结
      • AOF持久化
        • AOF配置示例
        • AOF文件重写
        • RDB与AOF对比
    • 3. Redis主从 -> 并发能力问题
      • 主从架构
        • 搭建主从架构示例
          • 集群架构
          • 准备实例和配置
          • 启动
          • 开启主从关系
          • 测试
      • 主从数据同步原理
        • 主从的全量同步原理
          • 简述全量同步的流程
        • 主从的增量同步原理
          • 主从数据同步优化点
        • 总结
    • 4. Redis哨兵 -> 故障恢复问题
    • 5. Redis分片集群 -> 存储能力问题

【redis学习篇】主从&哨兵&集群架构详解

1. 单点Redis的问题

在这里插入图片描述

数据丢失问题

Redis是内存存储，服务重启可能会丢失数据

并发能力问题

单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景

故障恢复问题

如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段

存储能力问题

Redis基于内存，单节点能存储的数据量难以满足海量数据需求

2. Redis持久化 -> 数据丢失问题

RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

在这里插入图片描述

save命令：由于redis是单线程执行的，使用此save命令时，主进程会阻塞其它的命令，而将数据持久化到磁盘的耗时比较久，等到save命令结束，主进程才能执行其它命令。不推荐使用此命令，它通常用在Redis停机时使用。

bgsave命令：后台异步执行，它会开启子进程执行RDB，避免主进程收到影响，推荐使用该命令作RDB。

Redis停机时会自动执行一次RDB（通过redis-cli连接上redis服务之后，输入shutdown命令即可让redis服务停止或者在redis未开启以守护模式运行时通过ctrl+c停止运行时，会自动执行一次RDB）。

linux单机安装Redis步骤

首先需要安装Redis所需要的依赖：

yum install -y gcc tcl

然后将课前资料提供的Redis安装包上传到虚拟机的任意目录：

在这里插入图片描述

例如，我放到了/tmp目录：

在这里插入图片描述

解压缩：

tar -xvf redis-6.2.4.tar.gz

解压后：

在这里插入图片描述

进入redis目录：

cd redis-6.2.4

运行编译命令：

make && make install

如果没有出错，应该就安装成功了（redis的默认安装位置是/usr/local/bin，在此/usr/local/bin目录下有：redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件；同时在redis-6.2.4目录下有redis.conf和sentinel.conf配置文件；同时在redis-6.2.4目录下的是src目录中也有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件）。

然后修改redis.conf文件中的一些配置：

# 绑定地址，默认是127.0.0.1，会导致只能在本地访问。修改为0.0.0.0则可以在任意IP访问
bind 0.0.0.0

# 数据库数量，设置为1
databases 1

启动Redis：

redis-server redis.conf # 使用redis-server命令启动redis, 并指定配置文件; 其中redis-server命令可在任意目录下执行

停止redis服务：

redis-cli shutdown # 其中redis-cli命令可在任意目录下执行
RDB持久化与恢复示例

按照【单机安装Redis步骤】中的步骤安装好redis后：

  • 在/usr/local/bin目录下有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件，并且
  • 在/usr/local/redis6/redis6.2.4/src目录下也有这些可执行文件；
  • 在/usr/local/redis6/redis6.2.4/src下有redis.conf和sentinel.conf配置文件。

（这里主要是说明安装情况）

在如上安装好redis之后，这里演示下在关闭redis服务时，redis会自动执行RDB的案例

现在切换/usr/local/redis6/redis-6.2.4目录下（不是必须在这个目录，在其它目录也可以执行redis-server命令）

在这里插入图片描述

使用redis-server ./redis.conf 命令，来指定对应的配置文件启动redis服务，redis开始接收连接

在这里插入图片描述

现在开启另外1个窗口，使用set num 123来保存1条数据到redis内存中，然后发出shutdown的命令，让redis关闭服务，此时redis服务会自动做1次RDB操作，将内存中的数据持久化到dump.rdb文件中（此dump.rdb文件默认会生成在运行redis-server命令时所在的目录中，这里在/usr/local/redis6/redis-6.2.4目录下）

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

现在/usr/local/redis6/redis-6.2.4目录下，继续在重新启动redis服务，查看前面通过RDB持久化的文件是否恢复到内存当中（这里就没有指定redis.conf了，也可以指定对应的配置文件）

在这里插入图片描述

在另外1个窗口，使用redis-cli连接上redis服务，查看数据，发现数据没有丢失，说明redis能够从持久化的文件恢复到内存中

在这里插入图片描述

RDB机制

上面案例演示了在redis服务关闭时，会自动执行RDB命令，将内存中的数据持久化到磁盘中。但是，假设redis运行过程中，突然宕机了，此时还没持久化到磁盘中，那么在存储在redis内存中的数据将会全部丢失，所以redis应该要有一套自动持久化的机制。

Redis内部有触发RDB的机制，可以在redis.conf文件中找到（这3个配置默认是被注释的，默认情况下RDB是开启的），格式如下：

在这里插入图片描述

RDB的其它配置也可以在redis.conf文件中设置：

在这里插入图片描述

（配置的含义就是 在指定的一段时间内，有指定数量的key被修改了，那么就执行1次RDB操作，将内存中的数据持久化到指定的目录下的指定的文件中。当然，redis启动时，也会从这个指定的目录下查找这个指定的文件加载到内存中。）

当有了RDB后，即使不关闭redis服务，也能通过配置将redis内存中的数据持久化到磁盘上，但是它会每隔一段时间，才会执行RDB操作。如果在某段时间内，尚未执行RDB时，此时宕机了，那么这段时间内的数据就丢失了。所以，可能会想着把间隔时间设置的尽可能短，但如果间隔时间很短，执行RDB的操作就太频繁了，影响redis的性能。所以使用默认的就好了。

RDB配置示例

说明：5s内，如果有1个key发生变化，那么持久化内存钟的数据到指定的文件中。其中，修改redis.conf文件部分如下：

# 5s内，如果有1个key发生变化, 则触发1次RDB持久化（如果需要禁用RDB, 则配置: save "" 即可）
save 5 1

# 指定持久化文件的名字
dbfilename test.data  

# 指定RDB持久化文件的所在目录
dir ./my_data_dir

在/usr/local/redis6/redis-6.2.4下创建rdb_test目录，并在此rdb_test目录下创建my_data_dir文件夹用于存放持久化文件。修改号redis.conf配置文件后，使用该配置文件启动redis。

在这里插入图片描述

redis启动后，使用redis-cli连接上redis服务，并向redis中存储2条数据，然后观察redis服务的控制台上观察输出，看到了redis执行持久化的日志，关闭redis后，查看my_data_dir文件夹，看到了test.data数据持久化文件

在这里插入图片描述
在这里插入图片描述

再次使用指定的配置文件，启动redis，使用redis-cli再次查询数据，发现数据已恢复

在这里插入图片描述

在这里插入图片描述

RDB的fork原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。（bgsave是异步执行持久化的，对主进程几乎零阻塞，零阻塞的原因在于主进程在执行fork得到子进程时，此fork操作会阻塞，此时无法处理客户端请求）

fork采用的是copy-on-write技术：

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作（当此时针对很多key写操作时，就相当于要拷贝大量数据作为副本，此时就需要事先考虑给redis预留足够的空间）

在这里插入图片描述

总结

RDB方式bgsave的基本流程？

  • fork主进程得到一个子进程，共享内存空间
  • 子进程读取内存数据并异步写入新的RDB文件
  • 用新RDB文件替换旧的RDB文件。

RDB会在什么时候执行？save 60 1000代表什么含义？

  • 默认是服务停止时。
  • 代表60秒内至少执行1000次修改则触发RDB

RDB的缺点？

  • RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
  • fork子进程、压缩、写出RDB文件都比较耗时

AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

在这里插入图片描述

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

在这里插入图片描述

AOF的命令记录的频率也可以通过redis.conf文件来配：

在这里插入图片描述

配置项刷盘时机优点缺点
Always同步刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到AOF文件磁盘中，此时主进程是阻塞的，等到写完AOF才返回给用户，主进程再处理其它请求）可靠性高，几乎不丢数据性能影响大
everysec每秒刷盘（redis接收到命令后，使用命令操作完内存后，把此命令写到内存缓冲区中，写完缓冲区后，主进程立即返回。1s后再通过异步的方式将缓冲区中的数据写到AOF文件磁盘中，因为主进程是面对内存缓冲区中的读写，所以效率高，但是如果在写入的过程中宕机了，那么就会丢失这1s内的所有操作。它是默认方案。）性能适中最多丢失1秒数据
no操作系统控制（由操作系统决定，可能频率会比较低）性能最好可靠性较差，可能丢失大量数据
AOF配置示例

说明：AOF会记录每条执行的redis命令到aof文件中，这里关闭了rdb机制，开启了aof机制

# 关闭RDB机制
save ""

# aof文件将会保存在此目录, 启动时会读取该目录下的aof文件（与RDB持久化文件所保存的目录相同）
dir ./aof_data_dir

# 开启aof
appendonly yes

# aof文件名
appendfilename "my_aof.data"

# aof刷盘策略, 默认就是everysec, 不需要修改
appendfsync everysec

在/usr/local/redis6/redis-6.2.4下创建aof_test目录，并在此aof_test目录下创建aof_data_dir文件夹用于存放aof文件。修改好redis.conf配置文件后，使用该配置文件启动redis。

在这里插入图片描述

使用redis-cli客户端连接上redis服务，并且保存1条数据，然后退出redis-cli客户端，就可以在指定的目录下看到保存的aof文件了，并且这里看到了aof文件的内容，aof文件确实记录了每条redis命令

在这里插入图片描述

关闭redis时，redis也会执行1次aof

在这里插入图片描述

重新启动redis服务，会自动加载aof文件，然后使用redis-cli客户端连接上redis服务，查询redis服务关闭之前所保存的数据，能够查询到，说明aof文件被加载了

在这里插入图片描述

在这里插入图片描述

AOF文件重写

因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果（此命令为异步执行，他会让aof文件变小，并对内容作编码处理）。

在这里插入图片描述

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置：

在这里插入图片描述

RDB与AOF对比

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

特点RDBAOF
持久化方式定时对整个内存做快照记录每一次执行的命令
数据完整性不完整，两次备份之间会丢失相对完整，取决于刷盘策略
文件大小会有压缩，文件体积小记录命令，文件体积很大
宕机恢复速度很快慢
数据恢复优先级低，因为数据完整性不如AOF高，因为数据完整性更高
系统资源占用高，大量CPU和内存消耗低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景可以容忍数分钟的数据丢失，追求更快的启动速度对数据安全性要求较高常见

  • RDB与AOF数据恢复优先级：当目录下同时存在AOF与RDB文件时，会优先使用AOF文件来恢复数据，因为AOF文件数据更加完整，而RDB会丢失从上次备份的数据后到发生故障时这段时间内的数据。所以RDB更适合作为一种数据备份的手段。

  • AOF操作是异步的

3. Redis主从 -> 并发能力问题

主从架构

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群（而不是负载均衡的那种集群），实现读写分离（因为redis查询操作多，增删改比较少，所以需要更多的处理读的压力，实现读写分离，提高读的并发能力）。

在这里插入图片描述

搭建主从架构示例
集群架构

我们搭建的主从集群结构如图：

在这里插入图片描述

共包含三个节点，一个主节点，两个从节点。这里我们会在同一台虚拟机中开启3个redis实例，模拟主从集群，信息如下：

IPPORT角色
172.17.23.2347001master
172.17.23.2347002slave
172.17.23.2347003slave
准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

1）创建目录

我们在/usr/local/redis6/redis-6.2.4/master-slave-cluster目录下，创建三个文件夹，名字分别叫redis7001、redis7002、redis7003，和1个最初的redis.conf配置文件（未作任何修改）

在这里插入图片描述

修改redis.conf配置文件：将其中的持久化模式改为默认的RDB模式，AOF保持关闭状态；配置bind允许远程连接；虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息。然后，将此redis.conf分别拷贝到redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003。

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000

# 关闭AOF
appendonly no

# 允许远程连接（不设置此配置, 会无法同步）
bind 0.0.0.0

# 虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息
replica-announce-ip 172.17.23.234

# 这个目录在本示例中为了方便就不改了, 但是注意启动的时候, 需要到对应的目录下去启动, 否则rdb生成的文件会在redis-server的运行目录下
dir ./

# 端口: redis7001、redis7002、redis7003中，然后分别修改他们对应的端口为：7001，7002，7003
port 7001 # 这里以7001为例
启动

分别在redis7001目录下启动7001，redis7002目录下7002，redis7003目录下7003（注意运行redis-server命令的目录，因为我们的dir配置的是./）

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

有临时和永久两种模式：

  • 修改配置文件（永久生效）

    • 在redis.conf中添加一行配置：slaveof <masterip> <masterport>

  • 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

    slaveof <masterip> <masterport>

注意：在5.0以后新增命令replicaof，与salveof效果一致。

这里让7002成为7001的slave，即让7002成为7001的从节点，执行该命令后，就会把7001主节点的数据同步过来

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

让7003成为7001的slave，并且从节点只能读取数据，不能够写入数据，只有主节点才能写入数据

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

测试

在主节点中写入数据，再分别从7002、7003从节点中读取到了数据，证明主从数据同步成功了。可以执行info replication查看集群状态。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

主从数据同步原理

主从的全量同步原理

主从第一次同步是全量复制

在这里插入图片描述

master如何判断slave是不是第一次来同步数据？这里会用到两个很重要的概念：

  • Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
  • offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据

全量同步过程：从节点将自己的replication id发给主节点，主节点判断此replication id是否与自己的replication id是否一致，如果replication id不一致，说明该从节点是第一次来，主节点需要执行bgsave命令来做RDB保存起来，然后将自己的全量数据和offset同步到该从节点；如果replication id一致，说明从节点之前已经来过了，做过了全量同步了，并且从节点将offset也发过来了，因此主节点就可以从offset得知从节点的同步进度，因此主节点就将offset后面的数据发过去给从节点）

简述全量同步的流程

  • 第1步：slave与master建立连接

  • 第2步：slave节点请求增量同步

  • 第3步：master节点判断replid，发现不一致，拒绝增量同步

  • 第4步：master将完整内存数据生成RDB，发送RDB到slave

  • 第5步：slave清空本地数据，加载master的RDB

  • 第6步：master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave

  • 第7步：slave执行接收到的命令，保持与master之间的同步

主从的增量同步原理

主从第一次同步是全量同步，，但如果slave重启后同步，则执行增量同步。

增量同步过程：从节点重启后，依然需要携带自己的replid和offset向主节点请求同步数据，主节点收到该节点发过来的replid后，与自己的replid比较，发现一致，说明不是第一次来同步的，因此，就查看该节点发过来的offset查看该节点之前的同步进度，然后从repl_baklog中读取大于此offset的命令发送给从节点去同步。如果主节点这边检测到该未同步的数据已经被覆盖了，那么就会要求该节点做全量同步。

在这里插入图片描述

repl_baklog大小有上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，此时只能再次全量同步。

主从数据同步优化点

可以从以下几个方面来优化Redis主从就集群：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO（需要网络带宽足够大）。

  • Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

    在这里插入图片描述

总结

简述全量同步和增量同步区别？

  • 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
  • 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

  • slave节点第一次连接master节点时
  • slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

  • slave节点断开又恢复，并且在repl_baklog中能找到offset时

4. Redis哨兵 -> 故障恢复问题

5. Redis分片集群 -> 存储能力问题

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

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

虚拟机配置桥接模式

虚拟机配置桥接模式

背景 因为要打一些awd比赛,一些扫描工具什么的,要用到kali,就想着换成一个桥接模式 但是我看网上的一些文章任然没弄好,遇到了一些问题 前置小问题 每次点开虚拟网络编辑器的时候都没有vmnet0,但是点击更改的时候却有vmnet0 第一步: 点击更改设置 第二步: 把wmnet0删掉 …
阅读更多...
【车载开发系列】CAN通信总线再理解（中篇）

【车载开发系列】CAN通信总线再理解（中篇）

【车载开发系列】CAN通信总线再理解&#xff08;中篇&#xff09; 九. CAN总线标准十. CAN物理层十一. CAN数据链路层1&#xff09;CAN的通信帧类型2&#xff09;CAN的标准帧格式1. CAN ID2. 数据场 3&#xff09;CAN总线仲裁 十二. CAN应用层1&#xff09;CANopen2&#xff09…
阅读更多...
傅里叶级数在不连续点会怎么样？？？

傅里叶级数在不连续点会怎么样？？？

文章目录 一、前言背景二、用狄利克雷核表达傅里叶级数三、狄利克雷核与狄拉克函数四、傅里叶级数在不连续点的表示五、吉伯斯现象的解释六、总结参考资料 一、前言背景 笔者最近在撸《信号与系统》&#xff0c;写下此博客用作记录和分享学习笔记。由于是笔者为电子爱好者&…
阅读更多...
前端锚点 点击 滑动双向绑定

前端锚点 点击 滑动双向绑定

一. 页面样式 二. 代码 <div class"flexBox"><div class"mdDiv" v-for"(item,index) in tabList" :key"index" :class"nowChooseindex?choosed:" click"jumpMD(index, item.id)">{{item.name}}&l…
阅读更多...
简单分析一下地产行业使用堡垒机的必要性-行云管家

简单分析一下地产行业使用堡垒机的必要性-行云管家

地产行业&#xff0c;一个关系民生的行业&#xff0c;一个与大家生活密不可分的行业。随着信息技术的快速发展&#xff0c;以及数字化转型的要求&#xff0c;以及地产行业业务迅猛发展&#xff0c;如何保障数据安全以及网络安全至关重要。在这种背景下&#xff0c;使用堡垒机就…
阅读更多...
VBA基础知识点总结

VBA基础知识点总结

VBA教程 VBScript教程 数据类型 数字数据类型 非数字数据类型 变量&常量 可以通过Dim、Public或Private语句声明变量。 变量语法&#xff1a;Dim <<variable_name>> As <<variable_type>>&#xff08;需要在使用它们之前声明&#xff09; 常量语…
阅读更多...
全球AI新闻速递6.20

全球AI新闻速递6.20

1.国家药监局综合司&#xff1a;关于印发药品监管人工智能典型应用场景清单的通知。 2.Canalys&#xff1a;预计今年全球 AI 手机市场份额达 16%。 3.Adobe Acrobat 升级 AI 技能&#xff1a;文生图、梳理信息等。 4.中国科大人形机器人研究院揭牌。 5.华为官方预告&#x…
阅读更多...
对30年国债利率破2.5%的复盘反思

对30年国债利率破2.5%的复盘反思

短期看&#xff0c;以月为维度&#xff0c;长端和超长端利率依然具有较强的向下突破的惯性&#xff1b;中期看&#xff0c;以季为维度&#xff0c;长端依然面临向下赔率不足的约束&#xff0c;但调整需要多重利空共振的契机。 短期看多&#xff0c;逢高配置”的四点逻辑 逻辑一…
阅读更多...
四川赤橙宏海商务信息咨询有限公司引领抖音电商潮流

四川赤橙宏海商务信息咨询有限公司引领抖音电商潮流

在当今数字化浪潮下&#xff0c;电商行业蓬勃发展&#xff0c;抖音电商作为新兴力量&#xff0c;正以其独特的魅力吸引着越来越多的商家和消费者。四川赤橙宏海商务信息咨询有限公司&#xff0c;作为抖音电商服务领域的佼佼者&#xff0c;凭借其专业的团队和丰富的经验&#xf…
阅读更多...
基于SpringBoot+Vue北部湾地区助农平台设计和实现(源码+LW+调试文档+讲解等)

基于SpringBoot+Vue北部湾地区助农平台设计和实现(源码+LW+调试文档+讲解等)

&#x1f497;博主介绍&#xff1a;✌全网粉丝1W,CSDN作者、博客专家、全栈领域优质创作者&#xff0c;博客之星、平台优质作者、专注于Java、小程序技术领域和毕业项目实战✌&#x1f497; &#x1f31f;文末获取源码数据库&#x1f31f; 感兴趣的可以先收藏起来&#xff0c;还…
阅读更多...
系统学习PLC

系统学习PLC

1.OB组织块 程序循环 PC ob1执行一次 ob123也执行一次 是 statup是程序启动的是第一个周期先执行starup&#xff08;0b100&#xff09;然后在执行ob1和0b123.这二个循环&#xff0c;周期执行这二个循环。1000是1s 2.DB块 建立指定数据块可以直接建立自己喜欢的类型 3.FB与…
阅读更多...
【维护服务器安全，如何应对恶意的威胁行为?】

【维护服务器安全，如何应对恶意的威胁行为?】

随着互联网的迅猛发展&#xff0c;网络服务器成为现代社会中不可或缺的基础设施。然而&#xff0c;恶意攻击行为也日益猖獗&#xff0c;技术不断升级&#xff0c;给网络服务器的安全带来了严峻挑战。下面德迅云安全就分享一些常见的危害服务器安全的行为&#xff0c;和相应的应…
阅读更多...
什么是嵌入式，单片机又是什么，两者有什么关联又有什么区别？

什么是嵌入式，单片机又是什么，两者有什么关联又有什么区别？

在开始前刚好我有一些资料&#xff0c;是我根据网友给的问题精心整理了一份「嵌入式的资料从专业入门到高级教程」&#xff0c; 点个关注在评论区回复“888”之后私信回复“888”&#xff0c;全部无偿共享给大家&#xff01;&#xff01;&#xff01;从科普的角度&#xff0c;…
阅读更多...
看完再买不后悔！希喂、小米、霍尼韦尔宠物空气净化器性价比比拼

看完再买不后悔！希喂、小米、霍尼韦尔宠物空气净化器性价比比拼

在忙碌的工作之余&#xff0c;养一只猫真的能治愈一切的不快&#xff0c;让我们的心灵得到片刻的宁静。然而&#xff0c;这份宁静背后&#xff0c;却隐藏着一些不易察觉的烦恼——猫浮毛和异味。 猫浮毛&#xff0c;这个看似微不足道的小问题&#xff0c;实则给许多宠物主人带…
阅读更多...
如何在MySql数据库中以经纬度进行查询

如何在MySql数据库中以经纬度进行查询

要在数据库中以经纬度进行查询&#xff0c;特别是针对MySQL数据库&#xff0c;你可以遵循以下步骤来实现基于地理位置的查询&#xff1a; 1. 数据表设计 首先&#xff0c;你需要设计一个数据表来存储地理位置信息。可以使用POINT类型来直接存储经纬度坐标&#xff0c;或者分别…
阅读更多...
家用洗地机哪个品牌耐用？推荐这四款清洁力强的机型

家用洗地机哪个品牌耐用？推荐这四款清洁力强的机型

近两年智能家庭清洁产品的快速崛起&#xff0c;典型代表就是家用洗地机。它集合吸尘、扫地、洗地、消杀等功能为一体&#xff0c;给人们生活带来了很多的便利&#xff0c;但随着洗地机的普及&#xff0c;市场上的机型也越来越多&#xff0c;让很多新手购机的朋友们无法快速下决…
阅读更多...
视频监控平台功能：国外的硬盘录像机NVR通过ISUP协议(原ehome协议)接入AS-V1000视频平台

视频监控平台功能：国外的硬盘录像机NVR通过ISUP协议(原ehome协议)接入AS-V1000视频平台

目录 一、背景说明 二、ISUP协议介绍 1、海康ISUP协议概述 2、ISUP协议支持主码流和子码流切换 &#xff08;1&#xff09;灵活配置和个性化 &#xff08;2&#xff09;适应不同网络带宽&#xff0c;提高使用体验 3、海康ehome相关文章 三、ISUP协议接入说明 1、平台侧…
阅读更多...
使用 Python 进行测试（5）测试的类型

使用 Python 进行测试（5）测试的类型

总结 和我一起唱&#xff01; 冒烟测试&#xff0c;让你快速失败&#xff1b; 回归测试&#xff0c;不打破过去&#xff1b; 健全性检查&#xff0c;保留所拥有&#xff1b; 集成测试&#xff0c;处理副作用&#xff1b; 端到端&#xff0c;永无尽头&#xff01; 回测&#xf…
阅读更多...
C++基础知识——命名空间

C++基础知识——命名空间

P. S.&#xff1a;以下代码均在VS2019环境下测试&#xff0c;不代表所有编译器均可通过。 P. S.&#xff1a;测试代码均未展示头文件stdio.h的声明&#xff0c;使用时请自行添加。 博主主页&#xff1a;Yan. yan. 文章目录 1、什么是命名空间2、命名空间的作用3、如何定义命名…
阅读更多...
FastAPI 作为H5中流式输出的后端

FastAPI 作为H5中流式输出的后端

FastAPI 作为H5中流式输出的后端 最近大家都在玩LLM&#xff0c;我也凑了热闹&#xff0c;简单实现了一个本地LLM应用&#xff0c;分享给大家&#xff0c;百分百可以用哦&#xff5e;^ - ^ 先介绍下我使用的三种工具&#xff1a; Ollama&#xff1a;一个免费的开源框架&…
阅读更多...
最新文章

Copyright @ 2022~2023