0
点赞
收藏
分享

微信扫一扫

uniapp 使用安卓模拟器运行调试

蒸熟的土豆 2024-03-02 阅读 9
redis数据库缓存nosql
加载失败

特点与工作原理

以下是Redis哨兵模式的主要特点与工作原理：

  1. 监控功能：
    • 哨兵会持续不断地通过心跳检测机制检查主节点和其他从节点的健康状态。
    • 如果主节点无法响应，哨兵会根据预设的超时规则判断主节点是否宕机。
  2. 自动故障转移：
    • 当哨兵确定主节点不可达后，它会执行自动故障转移操作。
    • 选择一个从节点提升为主节点，并负责更新其他从节点的配置，让它们切换到新的主节点进行同步。
  3. 协商机制：
    • 在多个哨兵组成的集群中，哨兵间会相互通信并达成共识，确保只有在足够数量的哨兵同意的情况下才会执行故障转移。
    • 这种多哨兵集群设计增强了系统的鲁棒性和正确性。
  4. 通知机制：
    • 哨兵不仅负责故障转移，还会通过发布订阅功能向客户端或者其他系统发送通知，告知Redis主节点的状态变化。
  5. 配置持久化：
    • 哨兵会将集群的当前配置信息持久化存储，即使哨兵自身重启也能恢复其监控状态。

通过这种模式，Redis能够实现无中心化的、高可用的服务部署，当主节点出现故障时，能够在无需人工干预的情况下快速恢复服务，保证了Redis服务的稳定性和可靠性。

架构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。

数据节点：主节点和从节点都是数据节点

作用

哨兵模式在Redis中主要用于提供高可用性和故障恢复功能。具体作用如下：

  1. 监控：哨兵（Sentinel）进程会持续监控主服务器和从服务器的运行状态，包括但不限于检查服务是否正常响应、判断主从复制是否正常进行等。
  2. 自动故障检测与转移：当主服务器发生故障（如宕机或网络断开），哨兵能及时发现并确定主服务器是否真的不可达。如果达到预设条件，哨兵将自动执行故障转移操作，选择一个从服务器升级为主服务器，并通知其他从服务器开始复制新的主节点。
  3. 配置更新：哨兵不仅负责切换主从角色，还会自动更新相关的配置信息，确保整个集群中的所有节点都知道新的主服务器是谁，从而维持集群的正确配置和数据同步。
  4. 系统通知：哨兵可以向管理员或者其他应用程序发送报警信息，报告关于Redis服务器的各种状态变化，通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
配置步骤
配置文件

复制和修改配置文件

到原 redis 解压目录下复制 sentinel.conf

[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]# cd /opt/soft/redis-6.0.6/
[root@localhost redis-6.0.6]# ls
00-RELEASENOTES  CONTRIBUTING  deps     Makefile   README.md   runtest          runtest-moduleapi  sentinel.conf  tests   utils
BUGS             COPYING       INSTALL  MANIFESTO  redis.conf  runtest-cluster  runtest-sentinel   src            TLS.md
[root@localhost redis-6.0.6]# cp sentinel.conf /usr/local/bin     ## 把哨兵配置文件 拷贝到 安装目录
cp: overwrite ‘/usr/local/bin/sentinel.conf’? y   
[root@localhost redis-6.0.6]# 

#### 切换到安装目录 检查
[root@localhost redis-6.0.6]# cd /usr/local/bin/
[root@localhost bin]# ls
dump.rdb  redis81.conf  redis82.conf  redis-benchmark  redis-check-aof  redis-check-rdb  redis-cli  redis.conf  redis-sentinel  redis-server  sentinel.conf
[root@localhost bin]#
监控主节点

编辑修改配置文件，监控主节点

sentinel monitor mymaster 127.0.0.1 6379 1 ###注意监控主节点

修改 把 2 修改为 1。如果有一个哨兵节点认为主节点宕机了，则开始选举机制。

启动哨兵进程

思路：启动三个节点 > 并指定主从关系 > 然后启动哨兵节点来监控主节点

[root@localhost bin]# redis-server redis.conf 
2417:C 05 Aug 2021 20:50:27.725 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2417:C 05 Aug 2021 20:50:27.725 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2417, just started
2417:C 05 Aug 2021 20:50:27.725 # Configuration loaded
[root@localhost bin]# ^C
[root@localhost bin]# redis-cli -p 6379

#### 上面启动成功后，下面查看自己当前角色
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=56,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=56,lag=0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:56
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:56
指定主从节点

启动 6381 端口和6382 端口，并指定从节点：

[root@localhost bin]# redis-cli -p 6381
127.0.0.1:6381> slaveof 127.0.0.1 6379    ####指定主从节点####
OK
127.0.0.1:6381> info replication
# Replication
role:slave                                #####从节点#####
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:42
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2a3410fe212ea06a10413e6c93b59b9746a55d7a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

启动6382 并指定主从节点

[root@localhost bin]# redis-server redis82.conf 
2441:C 05 Aug 2021 20:51:19.197 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2441:C 05 Aug 2021 20:51:19.197 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2441, just started
2441:C 05 Aug 2021 20:51:19.197 # Configuration loaded
127.0.0.1:6382> slaveof 127.0.0.1 6379
OK
127.0.0.1:6382> info replication
启动哨兵节点

redis-sentinel sentinel.conf

[root@localhost bin]# redis-sentinel sentinel.conf 
2485:X 05 Aug 2021 20:54:16.497 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2485:X 05 Aug 2021 20:54:16.497 # Redis version=6.0.6, bits=64, commit=00000000, modified=0, pid=2485, just started
2485:X 05 Aug 2021 20:54:16.497 # Configuration loaded
2485:X 05 Aug 2021 20:54:16.497 * Increased maximum number of open files to 10032 (it was originally set to 1024).
选举机制

Redis Sentinel（哨兵）模式下的选举

测试选举机制：停止主节点后，哨兵节点会输出日志，监控到变化和启动选举机制

127.0.0.1:6379> shutdown
not connected> quit
2485:X 05 Aug 2021 20:55:34.787 # +sdown master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.787 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
2485:X 05 Aug 2021 20:55:34.787 # +new-epoch 1
2485:X 05 Aug 2021 20:55:34.787 # +try-failover master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +vote-for-leader fe3f7dda47b7a9ca63194aeaeb31660c30a7316a 1
2485:X 05 Aug 2021 20:55:34.788 # +elected-leader master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.788 # +failover-state-select-slave master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 # +selected-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.860 * +failover-state-send-slaveof-noone slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:34.919 * +failover-state-wait-promotion slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +promoted-slave slave 127.0.0.1:6382 127.0.0.1 6382 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.924 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:35.999 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:36.992 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +failover-end master mymaster 127.0.0.1 6379
2485:X 05 Aug 2021 20:55:37.093 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:55:37.093 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382
2485:X 05 Aug 2021 20:56:07.186 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6382
多哨兵模式

优缺点

以下是多哨兵模式的优缺点：

优点：

  1. 高可用性：通过部署多个Sentinel节点，即使有个别Sentinel发生故障，其他Sentinel也能继续监控和管理Redis集群，确保系统的整体稳定性和可用性。
  2. 自动故障检测与恢复：当主服务器出现故障时，多个Sentinel可以通过协商机制达成一致意见，并选举出一个Leader Sentinel执行故障转移操作，将新的主服务器推举出来，从而实现快速恢复服务。
  3. 容错能力增强：由于有多个哨兵并行工作，可以减少单点故障的风险，增加对网络波动、机器宕机等异常情况的容忍度。
  4. 分布式决策：通过投票机制确定主服务器是否下线以及选择哪个从服务器升级为主服务器，避免了单一节点决策可能带来的误判或延迟。

缺点：

  1. 复杂性增加：配置和维护多哨兵架构会比单个哨兵更为复杂，需要考虑哨兵之间的通信、配置一致性等问题。
  2. 资源消耗：每个哨兵都是一个独立运行的进程，因此需要额外的计算资源和网络带宽来支持其运行。
  3. 潜在的问题点增多：随着哨兵数量的增加，可能出现更多潜在的故障点，例如如果所有哨兵同时无法正确监测到主节点状态，可能会导致集群不能正常进行故障切换。
  4. 一致性问题：虽然Sentinel之间通过协议保证了一致性，但在实际部署中，如若配置不当或网络分区等因素，仍有可能引发一致性问题，比如脑裂现象，即不同哨兵群组认为不同的节点是主服务器。

总结来说，多哨兵模式增强了Redis集群的健壮性和可靠性，但也相应增加了管理和运维的复杂度，因此在设计和部署时需要权衡这些因素，确保系统的稳健运行。

举报

相关推荐

uniapp启动安卓模拟器mumu

sql数据库

uniapp 连接夜神安卓模拟器真机调试

uni-appcss

【Android】如何使用模拟器调试安卓项目

linux

安卓模拟器genymotion 安装使用

htmldesktop3c虚拟化云计算

mac上如何启动adb调试连接安卓模拟器

android安卓网络安全移动移动开发

Hbuilder X/Uniapp 关于app运行调试及mumu模拟器运行问题

vue.js

Android Emulator安卓模拟器去黑边

android

安卓(雷电)模拟器清除屏幕密码

android

uniapp 写安卓app，运行到手机端 调试

服务器运维网络

安卓模拟器第二弹（补充说明）

安卓调试JavaScript前端开发yyds干货盘点
0 条评论
加载失败