Redis(四) 主从、哨兵、集群环境搭建

news2024/10/7 16:24:11

结合前三期 Redis(一) Redis简介(Redis(一) Redis简介-CSDN博客) Redis(二) 可编程性(Redis(二) 可编程性-CSDN博客) Redis(三) 事务与发布订阅(Redis(三) 事务与发布订阅-CSDN博客)

目录

1.0 Redis主从

1.1 Redis 主从结构的基本原理和工作方式

1.2 Redis 主从结构的好处

1.3 Redis 主从结构的不足

1.4 主从环境搭建 

1.4.0 docker启动两个redis容器

1.4.1 从redis配置

1.4.2 主从模式测试 

1.5 Redis主从总结

2.0 Redis哨兵

2.1 Redis Sentinel 的基本原理和工作方式

2.2 Redis Sentinel 的好处

2.3 Redis Sentinel 的不足

2.4 Redis Sentinel环境搭建

2.4.0 Sentinel配置

2.4.1 Redis配置

2.4.2 YML文件

2.4.3 启动 

2.5 总结

3.0 Redis集群

3.1 背景介绍

3.2 工作原理

3.3 部署方式

3.4 Redis集群的好处

3.5 Redis集群的不足

3.6 总结

1.0 Redis主从

1.1 Redis 主从结构的基本原理和工作方式

Redis 主从结构由一个主节点（master）和多个从节点（slave）组成。主节点负责处理客户端的写操作和读操作，而从节点则负责复制主节点的数据，并可以处理读操作。主节点将写操作记录在自己的日志文件中，并将写操作的指令发送给所有的从节点，从节点接收到指令后执行相同的操作，从而保持数据的一致性。

主从结构的数据复制过程分为全量复制和增量复制两个阶段。在全量复制阶段，从节点首先从主节点获取全部数据的副本，并在本地进行保存。在增量复制阶段，从节点持续地从主节点获取新的写操作指令，并在本地执行这些指令，从而保持数据的同步。

1.2 Redis 主从结构的好处

  1. 高可用性： 当主节点发生故障时，从节点可以自动切换为主节点，继续提供服务，从而保证系统的高可用性。主从结构能够在极短的时间内完成故障转移，使系统可以快速恢复。

  2. 数据备份： 从节点保存了主节点的完整数据副本，当主节点发生数据丢失或损坏时，可以通过从节点恢复数据，避免数据的永久丢失，保证数据的安全性。

  3. 负载均衡： 主从结构可以通过将读操作分发给多个从节点来分担主节点的读负载，提高系统的读取性能。通过增加从节点的数量，可以进一步提高系统的读取性能和吞吐量。

  4. 灾难恢复： 当整个 Redis 主节点所在的数据中心发生故障时，可以将另一个数据中心的从节点提升为主节点，从而实现跨数据中心的灾难恢复。

  5. 扩展性： 通过添加更多的从节点，可以实现 Redis 集群的扩展，从而支持更大规模的数据存储和并发访问。

1.3 Redis 主从结构的不足

  1. 单点故障： Redis 主节点仍然是系统的单点故障，当主节点发生故障时，系统的写操作将无法执行，需要手动进行故障转移和恢复。

  2. 数据延迟： 由于主从结构采用异步复制机制，从节点的数据可能会有一定的延迟，导致从节点上的数据与主节点上的数据存在一定的不一致性。在一些应用场景中，数据的一致性和实时性是非常重要的，这种延迟可能会导致数据不一致的问题。

  3. 复制链路带宽限制： 在大规模的系统中，主节点与从节点之间的复制链路可能成为瓶颈，限制了数据复制的速度和性能。当主节点的写操作频率很高时，可能会导致复制链路的带宽不足，从而影响系统的性能。

  4. 配置和管理复杂性： 管理和维护一个包含多个主从节点的 Redis 集群是一项复杂的任务，需要考虑节点的部署、配置、监控和故障恢复等方面的问题。如果配置不当或管理不善，可能会导致系统出现性能问题或数据丢失等严重后果。

  5. 一致性保证： 在主从结构中，数据的一致性是由主节点负责保证的，但由于网络延迟、节点故障等原因，可能会导致数据不一致的情况发生。因此，开发者需要自行处理数据的一致性问题，确保系统能够正确处理数据不一致的情况。

1.4 主从环境搭建 

1.4.0 docker启动两个redis容器

docker run --name my-redis 6379:6379 redls

docker run --name my-redis2 -d -p 6378:6379 redis

 查看运行容器情况

docker ps -a

此时两个redis容器均已启动并运行。

1.4.1 从redis配置

进入my-redis2的容器内部，并运行redis-cli。

docker exec -it my-redis2 redis-cli

配置主节点

#slaveof  主服务器的IP  端口号
slaveof 192.168.157.157 6379

主节点已配置成功。

从节点配置成只读模式。

#从服务器只读(推荐配置)
config set slave-read-only yes

 查看主从关系

info replication

从节点已经配置成功，并于主节点连接成功。

1.4.2 主从模式测试 

我们进入主节点的cli

docker exec -it my-redis redis-cli

主要节点存一个数据

从节点读取 

可以看到主从模式已经搭建完成，并完成了读写分离。 

1.5 Redis主从总结

Redis 主从结构是一种常用的高可用性和扩展性解决方案，通过将数据复制到多个节点实现数据的备份和负载均衡。它能够提高系统的可用性、可靠性和性能，并支持灾难恢复和系统扩展。然而，主从结构仍然存在一些不足之处，如单点故障、数据延迟、复制链路带宽限制、配置和管理复杂性以及一致性保证等问题，需要开发者在设计和实现系统时进行充分考虑和处理。

 

2.0 Redis哨兵

2.1 Redis Sentinel 的基本原理和工作方式

Redis Sentinel 是一个独立的进程，通过运行在单独的服务器上来监控 Redis 主从结构中的多个节点。每个 Redis Sentinel 进程都会定期向 Redis 主节点和从节点发送 PING 命令，并根据节点的响应情况来判断节点的健康状态。当主节点发生故障或变得不可达时，Redis Sentinel 会通过选举算法自动选举一个新的主节点，并将从节点切换到新的主节点上，从而实现故障转移。

Redis Sentinel 还负责监控 Redis 主从结构中的其他节点状态，如从节点的连接状态、同步状态和复制延迟等，并在发现异常情况时采取相应的措施，如重新配置从节点、重启节点或重新连接节点等。此外，Redis Sentinel 还提供了命令行界面和 API 接口，用于管理和监控 Redis 主从结构的状态，并可以通过配置文件进行自定义设置和调整。

2.2 Redis Sentinel 的好处

  1. 高可用性： Redis Sentinel 可以监控和管理 Redis 主从结构中的多个节点，当主节点发生故障时，可以自动选举新的主节点，并将从节点切换到新的主节点上，从而实现故障转移，保证系统的高可用性。

  2. 自动化故障转移： Redis Sentinel 提供了自动化的故障转移功能，当主节点发生故障时，可以自动选举新的主节点，并将从节点切换到新的主节点上，无需人工干预，从而降低了系统的运维成本和管理复杂性。

  3. 监控和警报： Redis Sentinel 可以监控 Redis 主从结构中的节点状态，并在发现异常情况时发送警报通知管理员，帮助管理员及时发现和处理问题，保证系统的稳定性和可靠性。

  4. 动态配置： Redis Sentinel 提供了动态配置功能，管理员可以通过修改配置文件或使用命令行界面来添加、删除或修改监控的节点，从而灵活调整系统的配置和部署，满足不同场景的需求。

  5. 分布式部署： Redis Sentinel 支持分布式部署，可以将多个 Sentinel 进程部署在不同的服务器上，实现对 Redis 主从结构的多地监控和管理，提高了系统的可扩展性和容错能力。

2.3 Redis Sentinel 的不足

  1. 单点故障： Redis Sentinel 本身也是一个单点故障，当 Sentinel 进程发生故障时，可能会影响到整个系统的正常运行。为了解决这个问题，可以部署多个 Sentinel 进程，并使用哨兵集群来实现 Sentinel 的高可用性和容错能力。

  2. 配置复杂性： Redis Sentinel 的配置相对复杂，需要管理员熟悉 Redis 的相关知识和配置参数，才能正确配置和管理 Sentinel 进程。如果配置不当，可能会导致系统的性能问题或故障转移失败等严重后果。

  3. 故障恢复时间： 当主节点发生故障时，Redis Sentinel 需要一定的时间来完成故障转移和数据同步操作，期间可能会导致系统的一段时间内不可用或数据不一致。虽然 Redis Sentinel 能够尽快地完成故障转移，但仍然无法避免短暂的服务中断和数据延迟问题。

  4. 性能开销： Redis Sentinel 需要定期向监控的节点发送 PING 命令，并接收节点的响应，从而增加了系统的网络开销和负载。在大规模的系统中，可能会出现 Sentinel 进程的负载过高或网络带宽不足的情况，影响系统的性能和稳定性。

  5. 一致性保证： 在故障转移过程中，可能会出现数据不一致的情况，特别是在主节点发生故障后，从节点和新的主节点之间可能存在数据延迟或数据丢失的问题，需要开发者自行处理数据的一致性问题，确保系统能够正确处理数据不一致的情况。

2.4 Redis Sentinel环境搭建

2.4.0 Sentinel配置

sentinel1.conf

# bind 127.0.0.1
​
# 哨兵的端口号
# 因为各个哨兵节点会运行在单独的Docker容器中
# 所以无需担心端口重复使用
# 如果需要在单机
port 26379
​
# 设定密码认证
requirepass 123456
​
# 配置哨兵的监控参数
# 格式：sentinel monitor <master-name> <ip> <redis-port> <quorum>
# master-name是为这个被监控的master起的名字
# ip是被监控的master的IP或主机名。因为Docker容器之间可以使用容器名访问，所以这里写master节点的容器名
# redis-port是被监控节点所监听的端口号
# quorom设定了当几个哨兵判定这个节点失效后，才认为这个节点真的失效了
sentinel monitor local-master 127.0.0.1 6379 2
​
# 连接主节点的密码
# 格式：sentinel auth-pass <master-name> <password>
sentinel auth-pass local-master 123456
​
# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds local-master 30000

 sentinel2.conf

port 26380
requirepass 123456
sentinel monitor local-master 192.168.157.157 6379 2
sentinel auth-pass local-master 123456
# master在连续多长时间无法响应PING指令后，就会主观判定节点下线，默认是30秒
# 格式：sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds local-master 30000

 sentinel3.conf

port 26381
requirepass 123
sentinel monitor master3 192.168.157.157 6381 2
sentinel auth-pass master3 123
sentinel down-after-milliseconds master3 30000

2.4.1 Redis配置

redismaster.confr

# 监听端口
port 6379
​
# 启动时不打印logo
# 这个不重要，想看logo就打开它
always-show-logo no
​
# 设定密码认证
requirepass 123
​
# 禁用KEYS命令
# 一方面 KEYS * 命令可以列出所有的键，会影响数据安全
# 另一方面 KEYS 命令会阻塞数据库，在数据库中存储了大量数据时，该命令会消耗很长时间
# 期间对Redis的访问也会被阻塞，而当锁释放的一瞬间，大量请求涌入Redis，会造成Redis直接崩溃
rename-command KEYS ""

redisslave1.conf

# 监听端口
port 6380
always-show-logo no
requirepass 123
​
rename-command KEYS ""
slaveof 192.168.157.157 6379
​
# 设定连接主节点所使用的密码
masterauth "123"

redisslave2.conf


# 监听端口
port 6381
always-show-logo no
​
# 设定密码认证
requirepass 123
rename-command KEYS ""
​
slaveof 192.168.157.157 6379
​
# 设定连接主节点所使用的密码
masterauth "123"

2.4.2 YML文件

SENTINEL的DOCKER-COMPOSE.YML文件

version: '3'
​
services:
  redis-sentinel-1:
    image: redis
    container_name: redis-sentinel-1
    restart: always
    # 为了规避Docker中端口映射可能带来的问题
    # 这里选择使用host网络
    network_mode: host
    volumes:
      - ./redis-sentinel-1.conf:/usr/local/etc/redis/redis-sentinel.conf
    # 指定时区，保证容器内时间正确
    environment:
      TZ: "Asia/Shanghai" 
    command: ["redis-sentinel", "/usr/local/etc/redis/redis-sentinel.conf"]
  redis-sentinel-2:
    image: redis
    container_name: redis-sentinel-2
    restart: always
    network_mode: host
    volumes:
      - ./redis-sentinel-2.conf:/usr/local/etc/redis/redis-sentinel.conf
    environment:
      TZ: "Asia/Shanghai" 
    command: ["redis-sentinel", "/usr/local/etc/redis/redis-sentinel.conf"]
  redis-sentinel-3:
    image: redis
    container_name: redis-sentinel-3
    restart: always
    network_mode: host
    volumes:
      - ./redis-sentinel-3.conf:/usr/local/etc/redis/redis-sentinel.conf
    environment:
      TZ: "Asia/Shanghai"
    command: ["redis-sentinel", "/usr/local/etc/redis/redis-sentinel.conf"]
version: '3'

services:
  # 主节点的容器
  redis-server-master:
    image: redis
    container_name: redismaster
    restart: always
    # 为了规避Docker中端口映射可能带来的问题
    # 这里选择使用host网络
    network_mode: host
    # 指定时区，保证容器内时间正确
    environment:
      TZ: "Asia/Shanghai"
    volumes:
      # 映射配置文件和数据目录
      - ./redismaster.conf:/usr/local/etc/redis/redis.conf
      - ./data/redismaster:/data 
    command: ["redismaster", "/usr/local/etc/redis/redis.conf"]
  # 从节点1的容器
  redis-server-slave-1:
    image: redis
    container_name: redisslave1
    restart: always
    network_mode: host
    depends_on:
      - redismaster
    environment:
      TZ: "Asia/Shanghai"
    volumes:
      - ./redisslave1.conf:/usr/local/etc/redis/redis.conf
      - ./data/redisslave-1:/data 
    command: ["redisslave1", "/usr/local/etc/redis/redis.conf"]
  # 从节点2的容器
  redis-server-slave-2:
    image: redis
    container_name: redisslave2
    restart: always
    network_mode: host
    depends_on:
      - redismaster
    environment:
      TZ: "Asia/Shanghai"
    volumes:
      - ./redisslave2.conf:/usr/local/etc/redis/redis.conf
      - ./data/redisslave2:/data 
    command: ["redisslave2", "/usr/local/etc/redis/redis.conf"]

2.4.3 启动 

运行yml文件

查看全部容器 

redis哨兵模式已经搭建完成。 

2.5 总结

Redis Sentinel 是一种可靠的高可用性解决方案，通过监控和管理 Redis 主从结构中的多个节点，实现了自动化的故障转移和系统的自愈能力。它能够提高系统的可用性、可靠性和稳定性，并支持动态配置、监控和警报、分布式部署等功能。然而，Redis Sentinel 也存在一些不足之处，如单点故障、配置复杂性、故障恢复时间、性能开销和一致性保证等问题，需要开发者在设计和实现系统时进行充分考虑和处理

3.0 Redis集群

3.1 背景介绍

Redis 最初是一个单机的内存数据库，虽然非常快速和高效，但是随着数据量的增长和负载的增加，单机 Redis 会面临性能瓶颈和可用性问题。为了解决这些问题，Redis 引入了集群模式。

3.2 工作原理

Redis 集群模式通过将数据分片存储在多个 Redis 节点上来实现高可用性和横向扩展。每个节点负责管理部分数据，而整个集群负责协调数据的分布和访问。

Redis 集群模式采用了一种称为哈希槽（hash slot）的机制来分配数据。Redis 将所有可能的数据分成 16384 个哈希槽，每个槽都有一个唯一的编号。当客户端发送一个命令时，Redis 集群根据命令中的键计算哈希值，并根据哈希值确定应该存储在哪个哈希槽中。然后集群将这个哈希槽映射到一个或多个节点上，每个节点负责管理一部分哈希槽。

3.3 部署方式

部署 Redis 集群通常需要多个 Redis 实例和一个集群管理器。Redis 集群管理器负责监视集群的状态，进行节点的发现和故障恢复，并处理客户端的请求路由。

常见的 Redis 集群管理器包括 Redis Sentinel 和 Redis Cluster。Redis Sentinel 是一个用于高可用性的监控系统，可以监视多个 Redis 实例并在主节点失效时自动进行故障转移。而 Redis Cluster 则是一个原生的分布式解决方案，提供自动分片和数据重新分布功能。

在部署 Redis 集群时，通常会有以下步骤：

  1. 安装和配置 Redis：在每个节点上安装和配置 Redis，确保它们能够相互通信。

  2. 配置集群管理器：如果使用 Redis Cluster，则需要配置集群管理器，指定初始节点和哈希槽分配方式。

  3. 启动集群：启动 Redis 节点和集群管理器，并确保它们能够正常工作。

  4. 添加节点：根据需要添加或移除 Redis 节点，集群管理器会自动进行数据重分配。

3.4 Redis集群的好处

Redis 集群模式具有以下优势：

  • 高可用性：由于数据分布在多个节点上，即使某些节点发生故障，集群仍然能够继续工作。

  • 横向扩展：通过添加更多的节点，可以线性地扩展 Redis 集群的性能和容量。

  • 自动数据重分配：当添加或移除节点时，Redis 集群能够自动重新分配数据，保持各个节点的负载均衡。

  • 无单点故障：Redis 集群不依赖于单个节点，因此不会因为某个节点的故障而导致整个集群不可用。

3.5 Redis集群的不足

尽管 Redis 集群模式提供了许多优势，但在实践中仍然可能遇到一些常见问题，包括：

  • 数据一致性：由于数据分片存储在不同的节点上，可能会导致数据一致性的问题。可以通过使用复制（replication）和数据同步（synchronization）来解决这个问题。

  • 网络分区：网络分区可能会导致集群中的节点无法相互通信，从而导致数据不一致或数据丢失。可以通过增加节点和使用 quorum 策略来减轻网络分区的影响。

  • 负载均衡：在集群中均衡负载是一个复杂的问题，特别是当数据分布不均匀时。可以通过监控和调整哈希槽的分配来解决负载均衡问题。

  • 故障恢复：当节点发生故障时，需要及时进行故障恢复，以确保集群的可用性。可以通过使用监控系统和自动故障转移功能来实现快速的故障恢复。

3.6 总结

Redis 集群模式是一种用于提高性能和可扩展性的解决方案，通过将数据分片存储在多个节点上来实现高可用性和横向扩展。虽然部署和管理 Redis 集群可能会有一些挑战，但通过合适的配置和监控系统，可以确保集群的稳定运行和高效工作。

 

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

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

相关文章

经典案例｜使用Supabase解决可视化大屏项目的常见问题

经典案例｜使用Supabase解决可视化大屏项目的常见问题

敏博科技专业致力于应急管理行业&#xff0c;提供以物联网技术和感知预警算法模型为核心的先进产品和解决方案。应急管理行业的业务非常繁多和复杂&#xff0c;很多时候都需要在短时间内交付出稳定高效的业务系统。如下两张图某市的安全生产监测预警系统 MemFire Cloud应用开…
阅读更多...
图像处理之模板匹配（C++）

图像处理之模板匹配（C++）

图像处理之模板匹配&#xff08;C&#xff09; 文章目录 图像处理之模板匹配&#xff08;C&#xff09;前言一、基于灰度的模板匹配1.原理2.代码实现3.结果展示 总结 前言 模板匹配的算法包括基于灰度的匹配、基于特征的匹配、基于组件的匹配、基于相关性的匹配以及局部变形匹…
阅读更多...
Maven的下载和环境变量的配置

Maven的下载和环境变量的配置

1下载 maven官网https://maven.apache.org/index.html点击Download 这个是Windows的下载版本&#xff0c;一般是最新的版本&#xff0c; 老的版本下载 以下是对应的老版本下载链接 下载好后是一个压缩包的形式 点击他进行解压到想放的文件夹中&#xff0c;&#xff08;一般不…
阅读更多...
设计模式-00 设计模式简介之几大原则

设计模式-00 设计模式简介之几大原则

设计模式-00 设计模式简介之几大原则 本专栏主要分析自己学习设计模式相关的浅解&#xff0c;并运用modern cpp 来是实现&#xff0c;描述相关设计模式。 通过编写代码&#xff0c;深入理解设计模式精髓&#xff0c;并且很好的帮助自己掌握设计模式&#xff0c;顺便巩固自己的c…
阅读更多...
【神经网络基础辨析】什么是神经网络的主干（backbone）、颈部（neck）和头部（head）网络

【神经网络基础辨析】什么是神经网络的主干（backbone）、颈部（neck）和头部（head）网络

在神经网络中&#xff0c;通常将网络分为三个部分&#xff1a;骨干网络&#xff08;Backbone&#xff09;、颈部网络&#xff08;Neck&#xff09;、和头部网络&#xff08;Head&#xff09;。 骨干网络&#xff08;Backbone&#xff09; 骨干网络通常是神经网络的主要部分&a…
阅读更多...
探索设计模式的魅力：主从模式与AI大模型的结合-开启机器学习新纪元

探索设计模式的魅力：主从模式与AI大模型的结合-开启机器学习新纪元

​&#x1f308; 个人主页&#xff1a;danci_ &#x1f525; 系列专栏&#xff1a;《设计模式》 &#x1f4aa;&#x1f3fb; 制定明确可量化的目标&#xff0c;坚持默默的做事。 ✨欢迎加入探索主从模式与AI大模型之旅✨ &#x1f31f;Hey, tech enthusiasts! 你是否还在追…
阅读更多...
【嵌入式AI部署神经网络】STM32CubeIDE上部署神经网络之指纹识别（Pytorch）——篇一|环境搭建与模型初步部署篇

【嵌入式AI部署神经网络】STM32CubeIDE上部署神经网络之指纹识别（Pytorch）——篇一|环境搭建与模型初步部署篇

前言&#xff1a;本篇主要讲解搭建所需环境&#xff0c;以及基于pytorch框架在stm32cubeide上部署神经网络&#xff0c;部署神经网络到STM32单片机&#xff0c;本篇实现初步部署模型&#xff0c;没有加入训练集与验证集&#xff0c;将在第二篇加入。篇二详细讲解STM32CubeIDE上…
阅读更多...
PHP之内置web服务器

PHP之内置web服务器

1. 前言 PHP从5.4开始&#xff0c;就提供了一个内置的web服务器。 这个主要是用来做本地的开发测试用的&#xff0c;不能用于线上环境。 将PHP的安装路径配置到电脑的系统环境变量Path中&#xff0c;下图是win7&#xff0c;win10中会看的更清楚 2. 进入项目目录&#xff0c;执…
阅读更多...
OpenHarmony南向开发案例：【 智能家居中控】

OpenHarmony南向开发案例：【 智能家居中控】

应用场景简介 智能家居。 今天打造的这一款全新智能家庭控制系统&#xff0c;凸显应用在智能控制和用户体验的特点&#xff0c;开创国内智能家居系统体验新局面。新的系统主要应用在鸿蒙生态。 工程版本 系统版本/API版本&#xff1a;OpenHarmony SDK API 8IDE版本&#xf…
阅读更多...
unity cinemachine相机 （案例 跟随角色移动）

unity cinemachine相机 （案例 跟随角色移动）

安装相机包 打开包管理工具 在 unity registry 搜索cinemachine 会在maincamera中生成一个组件cinemachineBrain 只能通过虚拟相机操控 主相机 虚拟相机的参数 案例 1.固定相机效果 位置 在固定的地方 默认的模式 2.相机跟随人物效果 焦距设置 20 跟随设置 把playere…
阅读更多...
【LeetCode热题100】【多维动态规划】不同路径

【LeetCode热题100】【多维动态规划】不同路径

题目链接&#xff1a;62. 不同路径 - 力扣&#xff08;LeetCode&#xff09; 一个机器人位于一个 m x n 网格的左上角 &#xff08;起始点在下图中标记为 “Start” &#xff09;。 机器人每次只能向下或者向右移动一步。机器人试图达到网格的右下角&#xff08;在下图中标记…
阅读更多...
Django模型继承之Meta继承

Django模型继承之Meta继承

在Django模型继承中&#xff0c;当一个抽象基类被设计完成后&#xff0c;它会将该基类中定义的Meta内部类以属性的形式提供给子类。另外&#xff0c;如果子类未定义自己的Meta类&#xff0c;那么它就会默认继承抽象基类的Meta类。 关于Meta类的继承&#xff0c;大致总结如下&a…
阅读更多...
Ubuntu20.04安装redis5.0.7

Ubuntu20.04安装redis5.0.7

redis下载命令&#xff1a; wget https://download.redis.io/releases/redis-5.0.7.tar.gz 解压到 opt目录下 tar -zxvf redis-5.0.7.tar.gz -C /opt apt install -y gcc # 安装gccapt install make # 安装make 后面执行make一直报错 make报错后清除&#xff1a; make …
阅读更多...
机器学习(XgBoost）预测顶和底

机器学习(XgBoost）预测顶和底

之前的文章中&#xff0c;我们对中证1000指数进行了顶和底的标注。这一篇我们将利用这份标注数据&#xff0c;实现机器学习预测顶和底&#xff0c;并探讨一些机器学习的原理。 我们选取的特征非常简单–上影线和WR&#xff08;William’s R&#xff09;的一个变种。选取这两个…
阅读更多...
环境配置——Windows平台配置VScode运行环境为远程服务器或虚拟机

环境配置——Windows平台配置VScode运行环境为远程服务器或虚拟机

1. 远程机需要先安装SSH服务&#xff0c;命令如下 sudo apt install openssh-server 2. 安装好后需要开启SSH服务&#xff1a; sudo service sshd start 3. 查看SSH服务是否有被开启&#xff1a; sudo systemctl status sshd.service 4. 本地Windows需要生成密钥将公钥放…
阅读更多...
毕业撒花 流感服务小程序的设计与实现

毕业撒花 流感服务小程序的设计与实现

目录 1.1 总体页面设计 1.1.1 用户首页 1.1.2 新闻页面 1.1.3 我的页面 1.1.5 管理员登陆页面 1.1.6 管理员首页 1.2 用户模块 1.2.1 体检预约功能 1.2.2 体检报告功能 1.2.4 流感数据可视化功能 1.2.5 知识科普功能 1.2.6 疾病判断功能 1.2.7 出示个人就诊码功能 …
阅读更多...
（五）AB测试及两个案例 学习简要笔记 #统计学 #CDA学习打卡

（五）AB测试及两个案例 学习简要笔记 #统计学 #CDA学习打卡

目录 一. AB测试简介 1&#xff09;假设检验的一般步骤 2&#xff09;基于假设检验的AB测试步骤 二. 案例1&#xff1a;使用基于均值的假设检验进行AB测试 1&#xff09;原始数据 2&#xff09;提出原假设H0和备择假设H1 3&#xff09;使用均值之差的t检验&#xff0c;计…
阅读更多...
计算机网络3——数据链路层3以太网的MAC层

计算机网络3——数据链路层3以太网的MAC层

文章目录 一、MAC 层的硬件地址1、介绍2、注意点3、定制标准 二、MAC 帧的格式1、结构2、工作原理3、其他 一、MAC 层的硬件地址 1、介绍 在局域网中&#xff0c;硬件地址又称为物理地址或 MAC地址(因为这种地址用在MAC帧中)。 大家知道&#xff0c;在所有计算机系统的设计中…
阅读更多...
MySQL从入门到高级 --- 2.DDL基本操作

MySQL从入门到高级 --- 2.DDL基本操作

文章目录 第二章&#xff1a;2.基本操作 - DDL2.1 数据库的常用操作创建数据库选择要操作的数据库删除数据库修改数据库编码 2.2 表结构的常用操作创建表格式查看当前数据库的所有表名称查看指定某个表的创建语句查看表结构删除表 2.3 修改表结构添加列修改列名和类型删除列修改…
阅读更多...
在Spring boot中指定随机可用的端口

在Spring boot中指定随机可用的端口

​ 正常情况下每个spring boot启动都有固定的端口&#xff0c;也就是8080&#xff0c;如果启动多个项目&#xff0c;很容易出现端口冲突&#xff0c;那么怎么解决这个问题呢&#xff1f; 解决方案1&#xff1a; random 随机端口 ​ 在spring boot中&#xff0c;可以通过${ran…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023