Redis高可用部署及监控

fMRI独立成分分析方法(ICA)工具GIFT 详细介绍了进行fmri数据进行ICA分析的工具包GIFT的使用,和进行ICA分析的流程。 阅读详情

Redis高可用部署及监控

  (2013-11-15 15:25:53)
标签: 

redis

 

sentinel

 

monitor

 

it

分类: NOSQL

一、           Redis Sentinel简介

 

Redis Sentinel是redis自带的集群管理工具,主要功能有

·         监控(Monitoring): Redis Sentinel实时监控主服务器和从服务器运行状态。

·         提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Redis Sentinel 可以向系统管理员发送通知, 也可以通过 API 向其他程序发送通知。

·         自动故障转移(Automatic failover): 当一个主服务器不能正常工作时,Redis Sentinel 可以将一个从服务器升级为主服务器, 并对其他从服务器进行配置,让它们使用新的主服务器。当应用程序连接到Redis 服务器时, Redis Sentinel会告之新的主服务器地址和端口。

Redis Sentinel 是一个分布式系统, 你可以在架构中运行多个 Sentinel 进程,这些进程通过相互通讯来判断一个主服务器是否断线,以及是否应该执行故障转移。

在配置Redis Sentinel时,至少需要有1个Master和1个Slave。当Master失效后,Redis Sentinel会报出失效警告,并通过自动故障转移将Slave提升为Master,并提供读写服务;当失效的Master恢复后,Redis Sentinel会自动识别,将Master自动转换为Slave并完成数据同步。

通过Redis Sentinel可以实现Redis零手工干预并且短时间内进行M-S切换,减少业务影响时间。

 

 

二、           硬件需求

 

为了预防单节点故障,需要至少两台服务器,配置要求一致。

CPU

内存

磁盘

>2 CORES

>16 GB

>100 GB

 

 

三、           拓扑结构

 

在两个服务器中分别都部署Redis和Redis Sentinel。当Master中的Redis出现故障时(Redis进程终止、服务器僵死、服务器断电等),由Redis Sentinel将Master权限切换至Slave Redis中,并将只读模式更改为可读可写模式。应用程序通过Redis Sentinal确定当前Master Redis位置,进行重新连接。

根据业务模式,可以制定两种拓扑结构:单M-S结构和双M-S结构。如果有足够多的服务器,可以配置多M-S结构。

1、单M-S结构

单M-S结构特点是在Master服务器中配置Master Redis(Redis-1M)和Master Sentinel(Sentinel-1M)。Slave服务器中配置Slave Redis(Redis-1S)和Slave Sentinel(Sentinel-1S)。其中 Master Redis可以提供读写服务,但是Slave Redis只能提供只读服务。因此,在业务压力比较大的情况下,可以选择将只读业务放在Slave Redis中进行。

 Redis高可用部署及监控

2、双M-S结构

 

双M-S结构的特点是在每台服务器上配置一个Master Redis,同时部署一个Slave Redis。由两个Redis Sentinel同时对4个Redis进行监控。两个Master Redis可以同时对应用程序提供读写服务,即便其中一个服务器出现故障,另一个服务器也可以同时运行两个Master Redis提供读写服务。缺点是两个Master redis之间无法实现数据共享,不适合存在大量用户数据关联的应用使用。

 Redis高可用部署及监控

3、优劣对比

两个结构各有优缺点,分别适用于不同的应用场景:

单M-S结构适用于不同用户数据存在关联,但应用可以实现读写分离的业务模式。Master主要提供写操作,Slave主要提供读操作,充分利用硬件资源。

双(多)M-S结构适用于用户间不存在或者存在较少的数据关联的业务模式,读写效率是单M-S的两(多)倍,但要求故障时单台服务器能够承担两个Mater Redis的资源需求。

 

 

四、           配置部署

 

单M-S结构和双M-S结构配置相差无几,下面以双M-S结构配置为例。

1、Redis配置

1)Master Redis配置

在Server-1M上配置Redis-1M

# vi redis-1M.conf

## master redis-1M

## daemonize默认为no,修改为yes,启用后台运行

daemonize yes

 

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-1M.pid

 

##端口号

port 6379

 

##验证口令   

requirepass ************* 

masterauth *************

 

#绑定可连接Redis的IP地址,不设置将处理所有请求

# bind 127.0.0.1

 

#客户端连接的超时时间,单位为秒,超时后会关闭连接(0为不设置)

timeout 0

 

#日志记录等级

loglevel notice

 

#设置数据库的个数

databases 16

#日志刷新策略(Master禁用)

#save 900 1

#save 300 10

#save 60 10000

 

#是否使用压缩镜像备份

rdbcompression yes

 

#镜像备份文件的文件名

dbfilename redis-1M_dump.rdb

 

#镜像备份路径,默认值为 ./

dir /redis/backup

 

#设置该数据库为其他数据库的从数据库,主库无需设置

#slaveof

# slaveof

 

#指定与主数据库连接时需要的密码验证,主库无需设置

#masterauth

#masterauth

 

#如果 slave-serve-stale-data 设置成 'no',slave会返回"SYNC with master in #progress"错误信息,但 INFO和SLAVEOF命令除外。

slave-serve-stale-data yes

 

#客户端连接访问口令

# requirepass foobared

 

#限制同时连接的客户数量,防止过多的client导致内存耗尽。如果有足够内存可以不进行#设置

#maxclients 10000

 

#设置redis能够使用的最大内存。

# maxmemory

 

##启用增量(Master禁用) 

appendonly no

 

#增量日志文件名,默认值为appendonly.aof

appendfilename appendonly.aof

 

#设置对 appendonly.aof 文件进行同步的频率

#always 表示每次有写操作都进行同步,everysec 表示对写操作进行累积,每秒同步一次。

#no表示等操作系统进行数据缓存同步到磁盘,都进行同步,everysec 表示对写操作进行累#积,每秒同步一次

appendfsync everysec

 

#是否重置Hash表

#设置成yes后redis将每100毫秒使用1毫秒CPU时间来对redis的hash表重新hash,##可降低内存的使用。当使用场景有较为严格的实时性需求,不能接受Redis时不时的对请##求有2毫秒的延迟的话,把这项配置为no。如果没有这么严格的实时性要求,可以设置为 #yes,能够尽可能快的释放内存。

activerehashing yes

 

##Slave开启只读模式

slave-read-only yes

 

在Server-1S上配置Redis-2M

# vi redis-2M.conf

## master redis-2M

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-2M.pid

 

#镜像备份文件的文件名

dbfilename redis-1M_dump.rdb

 

#日志刷新策略(Slave启用)

save 900 1

save 300 10

save 60 10000

 

#-----------------其他参数与redis-1M保持一致-----------------

daemonize yes

#……

 

2)Slave Redis配置

在Server-1S上配置Redis-1S

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-1S.pid

 

##端口号

port 7379

 

#镜像备份文件的文件名

dbfilename redis-1S_dump.rdb

 

#设置该数据库为其他数据库的从数据库,主库无需设置

Slaveof server-1M 6379

 

##启用增量(Master禁用) 

appendonly yes

 

#-----------------其他参数与redis-1M保持一致-----------------

daemonize yes

#……

 

在Server-1M上配置Redis-2S

# Redis 默认pid 文件位置redis.pid

#当运行多个 redis 服务时,需要指定不同的 pid 文件和端口

pidfile redis-2S.pid

 

##端口号

port 7379

 

#镜像备份文件的文件名

dbfilename redis-2S_dump.rdb

 

#设置该数据库为其他数据库的从数据库,主库无需设置

Slaveof server-1S 6379

 

#-----------------其他参数与redis-2M保持一致-----------------

daemonize yes

#……

2、Redis Sentinel配置

在Server-1M上配置Sentinel-1M

vi sentinel-1M.conf

#Master redis-1M

#hostname server-1M

#ip 192.168.84.129

 

#端口号

port 26379

 

sentinel monitor server-1M 192.168.84.129 6379 1

sentinel down-after-milliseconds server-1M 5000

sentinel failover-timeout server-1M 900000

sentinel can-failover server-1M yes

sentinel parallel-syncs server-1M 1

 

#Master redis-1S

#hostname server-1S

#ip 192.168.84.128

sentinel monitor server-1S 192.168.84.128 6379 1

sentinel down-after-milliseconds server-1S 5000

sentinel failover-timeout server-1S 900000

sentinel can-failover server-1S yes

sentinel parallel-syncs server-1S 1

 

在Server-1S上配置Sentinel-1S

#Master redis-1M

#hostname server-1M

#ip 192.168.84.128

 

 

#端口号

port 27379

 

sentinel monitor server-1M 192.168.84.129 6379 1

sentinel down-after-milliseconds server-1M 5000

sentinel failover-timeout server-1M 900000

sentinel can-failover server-1M yes

sentinel parallel-syncs server-1M 1

 

#Master redis-1S

#hostname server-1S

#ip 192.168.84.128

sentinel monitor server-1S 192.168.84.128 6379 1

sentinel down-after-milliseconds server-1S 5000

sentinel failover-timeout server-1S 900000

sentinel can-failover server-1S yes

sentinel parallel-syncs server-1S 1

3、启动服务

Server-1M启动redis

redis-server redis-1M.conf

redis-server redis-2M.conf

 

Server-1S启动redis

redis-server redis-1S.conf

redis-server redis-2Sd.conf

 

检测同步

Master日志检查:

[28162] 10 Nov 23:32:11.810 * DB loaded from append only file: 0.000 seconds

[28162] 10 Nov 23:32:11.810 * The server is now ready to accept connections on port 6379

[28162] 10 Nov 23:32:35.360 * Slave ask for synchronization

[28162] 10 Nov 23:32:35.360 * Starting BGSAVE for SYNC

[28162] 10 Nov 23:32:35.361 * Background saving started by pid 28170

[28170] 10 Nov 23:32:35.373 * DB saved on disk

[28170] 10 Nov 23:32:35.375 * RDB: 0 MB of memory used by copy-on-write

[28162] 10 Nov 23:32:35.437 * Background saving terminated with success

[28162] 10 Nov 23:32:35.438 * Synchronization with slave succeeded

 

Slave日志检查:

[28091] 10 Nov 23:27:15.908 * DB loaded from append only file: 0.001 seconds

[28091] 10 Nov 23:27:15.908 * The server is now ready to accept connections on port 6389

[28091] 10 Nov 23:27:15.944 * Connecting to MASTER...

[28091] 10 Nov 23:27:15.947 * MASTER <-> SLAVE sync started

[28091] 10 Nov 23:27:15.951 * Non blocking connect for SYNC fired the event.

[28091] 10 Nov 23:27:15.952 * Master replied to PING, replication can continue...

[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: receiving 50 bytes from master

[28091] 10 Nov 23:27:15.990 * MASTER <-> SLAVE sync: Loading DB in memory

[28091] 10 Nov 23:27:15.991 * MASTER <-> SLAVE sync: Finished with success

[28091] 10 Nov 23:27:15.993 * Background append only file rewriting started by pid 28094

[28094] 10 Nov 23:27:15.998 * SYNC append only file rewrite performed

[28094] 10 Nov 23:27:15.998 * AOF rewrite: 0 MB of memory used by copy-on-write

[28091] 10 Nov 23:27:16.047 * Background AOF rewrite terminated with success

[28091] 10 Nov 23:27:16.047 * Parent diff successfully flushed to the rewritten AOF (0 bytes)

[28091] 10 Nov 23:27:16.048 * Background AOF rewrite finished successfully

 

启动sentinel服务

redis-server sentinel-1M.conf --sentinel

[28156] 10 Nov 23:33:22.337 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379

[28156] 10 Nov 23:39:37.071 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379

[28156] 10 Nov 23:39:37.072 # +sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379

[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379

[28156] 10 Nov 23:40:05.438 # -sdown sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379

[28156] 10 Nov 23:40:10.262 * -dup-sentinel masterserver-1S 192.168.84.128 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f

[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1S 192.168.84.128 6379

[28156] 10 Nov 23:40:10.263 * -dup-sentinel masterserver-1M 192.168.84.129 6379 #duplicate of 192.168.84.128:26389 or e453a45a5e1421519dcbe00a199f203579b27b0f

[28156] 10 Nov 23:40:10.263 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.129 6379

 

redis-server sentinel-1S.conf --sentinel

[16383] 10 Nov 23:40:05.499 * +slave slave 192.168.84.129:6389 192.168.84.129 6389 @server-1S 192.168.84.128 6379

[16383] 10 Nov 23:40:05.500 * +slave slave 192.168.84.128:6389 192.168.84.128 6389 @server-1M 192.168.84.129 6379

[16383] 10 Nov 23:40:06.098 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1S 192.168.84.128 6379

[16383] 10 Nov 23:40:08.404 * +sentinel sentinel 192.168.84.129:26379 192.168.84.129 26379 @server-1M 192.168.84.129 6379

 

4、故障模拟检测

模拟redis-1M(Master 192.168.84.129 6379)故障,sentinel自动检测状态,然后切换至redis-1S(Slave 192.168.84.128 6389),并将redis-1M转移为redis-1S的slave,状态为+sdown。

[28156] 11 Nov 00:42:48.431 # +sdown masterserver-1M 192.168.84.129 6379

[28156] 11 Nov 00:42:48.431 # +odown masterserver-1M 192.168.84.129 6379 #quorum 1/1

[28156] 11 Nov 00:42:56.570 # +failover-detected masterserver-1M 192.168.84.129 6379

[28156] 11 Nov 00:42:56.670 # +failover-end masterserver-1M 192.168.84.129 6379

[28156] 11 Nov 00:42:56.670 # +switch-masterserver-1M 192.168.84.129 6379 192.168.84.128 6389

[28156] 11 Nov 00:42:57.055 * +sentinel sentinel 192.168.84.128:26389 192.168.84.128 26389 @server-1M 192.168.84.128 6389

[28156] 11 Nov 00:43:01.688 # +sdown slave 192.168.84.129:6379 192.168.84.129 6379 @server-1M 192.168.84.128 6389

 

 

五、           备份恢复

1、备份策略

Redis提供两种相对有效的备份方法:RDB和AOF。

RDB是在某个时间点将内存中的所有数据的快照保存到磁盘上,在数据恢复时,可以恢复备份时间以前的所有数据,但无法恢复备份时间点后面的数据。

AOF是以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。优点是基本可以实现数据无丢失(缓存的数据有可能丢失),缺点是随着数据量的持续增加,AOF文件也会越来越大。

 

在保证数据安全的情况下,尽量避免因备份数据消耗过多的Redis资源,采用如下备份策略:

Master端:不采用任何备份机制

Slave端:采用AOF(严格数据要求时可同时开启RDB),每天将AOF文件备份至备份服务器。

为了最大限度减少Master端的资源干扰,将备份相关全部迁移至Slave端完成。同时这样也有缺点,当Master挂掉后,应用服务切换至Slave端,此时的Slave端的负载将会很大。目前Redis不支持RDB和AOF参数动态修改,需要重启Redis生效,希望能在新的版本中实现更高效的修改方式。

2、灾难恢复

·         当Master端Redis服务崩溃(包含主机断电、进程消失等),Redis sentinel将Slave切换为读写状态,提供生产服务。通过故障诊断修复Master,启动后会自动加入Sentinel并从Slave端完成数据同步,但不会切换。

·         当Master和Slave同时崩溃(如机房断电),启动服务器后,将备份服务器最新的AOF备份拷贝至Master端,启动Master。一切完成后再启动Slave。

 

六、           运维监控

 

目前针对redis的监控比较少见,主要有redis-live、dredis等。但这些工具对redis性能消耗比较严重,实时监控比较困难。

redis的监控可以简单分为安全监控和性能监控。安全监控可以通过redis sentinel的输出日志判断Master和Slave的状态;性能监控需要收集redis的性能参数进行评估。因此二者并不冲突,通过shell脚本可以实现轻量级的监控,缺点是没有可视化的实时图表。

1、安全监控

Redis sentinel的输出日志简洁而且内容很丰富,包含redis的实时状态、故障切换时间以及sentinel自身的状态,并且针对故障消除也有详细的记录。通过对sentinel日志挖掘,找出故障时刻进行及时报警,并通知管理员。

由于sentinel默认不启用日志记录,可以通过以下方法记录日志:

vi sentinel-1M.sh

LOG=/redis/redis-2.6.16/log/sentinel-1M.log

redis-server /redis/redis-2.6.16/sentinel-1M.conf  --sentinel >>$LOG &

 

sentinel_monitor

#---------------------------------------------------------------------------------------

#--                           Redis sentinel log monitor                              --

#--                                                                                   --

#-- VERSION : 1.0   Completed at 2013-11-12                                           --

#-- SUPPORT : redis 2.6 or later                                                      --

#-- FUNCTION:Sentinel log monitor                                                     --

#-- AUTHOR  : Icecream                                                               --

#---------------------------------------------------------------------------------------

脚本内容请联系作者。 

如有报错信息,通过Email通知管理员,并将日志信息写入监控日志。

通过crontab定期调用sentinel_monitor.sh进行日志监控:

##每分钟执行一次

* * * * * /redis/redis-2.6.16/log/sentinel_monitor.sh >/dev/null 2>&1

或

##每五分钟执行一次

*/5 * * * * /redis/redis-2.6.16/log/sentinel_monitor.sh >/dev/null 2>&1

 

监控日志输出样例:

-------------------------------------------------------------------------------

2013-11-11 17:46:01  Sentinel Monitor

-------------------------------------------------------------------------------

IP       :192.168.84.129

HOSTNAME :ice11g1

SENTINEL :sentinel-1M

ERRORS   :

[30220] 11 Nov 17:39:32.557 # +sdown slave 192.168.84.129:6379 192.168.84.129 6379 @ ice11g1 192.168.84.128 6389

[30220] 11 Nov 17:45:23.388 * +demote-old-slave slave 192.168.84.129:6379 192.168.84.129 6379 @ ice11g1 192.168.84.128 6389

[30220] 11 Nov 17:45:23.587 # -sdown slave 192.168.84.129:6379 192.168.84.129 6379 @ ice11g1 192.168.84.128 6389

[30220] 11 Nov 17:45:33.426 * +slave slave 192.168.84.129:6379 192.168.84.129 6379 @ ice11g1 192.168.84.128 6389

-------------------------------------------------------------------------------

 

-------------------------------------------------------------------------------

2013-11-11 17:47:01  Sentinel Monitor

-------------------------------------------------------------------------------

IP       :192.168.84.129

HOSTNAME :ice11g1

SENTINEL :sentinel-1M

ERRORS   :

OK,no error in sentinel-1M.log

 

2、性能监控 

redis_monitor

#---------------------------------------------------------------------------------------

#--                           Redis  monitor                              --

#--                                                                                   --

#-- VERSION : 1.0   Completed at 2013-11-12                                           --

#-- SUPPORT : redis 2.6 or later                                                      --

#-- FUNCTION:redis monitor                                                     --

#-- AUTHOR  : Icecream                                                               --

#---------------------------------------------------------------------------------------

脚本内容请联系作者!

脚本输出样例:

[2013-11-15 14:52:31]   9 105.54M 116338688 1.05 135.59M

[2013-11-15 14:52:36]   9 105.58M 116338688 1.05 135.59M

[2013-11-15 14:52:41]   9 105.58M 116338688 1.05 135.59M

[2013-11-15 14:52:46]   9 105.58M 116338688 1.05 135.59M

[2013-11-15 14:52:51]   9 105.58M 116338688 1.05 135.59M

[2013-11-15 14:52:56]   9 105.58M 116338688 1.05 135.59M

[2013-11-15 14:53:01]   9 105.54M 116338688 1.05 135.59M

[2013-11-15 14:53:06]   9 105.54M 116338688 1.05 135.59M

[2013-11-15 14:53:11]   10 105.56M 116338688 1.05 135.59M

[2013-11-15 14:53:16]   10 105.60M 116338688 1.05 135.59M

[2013-11-15 14:53:21]   10 105.56M 116338688 1.05 135.59M

[2013-11-15 14:53:26]   10 105.63M 116338688 1.05 135.59M

[2013-11-15 14:53:31]   10 105.60M 116338688 1.05 135.59M

[2013-11-15 14:53:36]   10 105.56M 116338688 1.05 135.59M

 

通过输出日志可以手工绘制曲线图:

Redis高可用部署及监控

Python 爬虫实战:爬取去哪儿网酒店评价,提取住宿体验关键词 本文介绍了基于去哪儿网酒店评价数据的爬取与分析方法。首先通过分析网页结构和数据加载机制,定位到评价数据的JSON接口及关键参数。然后使用Python搭建爬虫环境,实现多页评价数据的批量采集与存储,并通过反爬策略确保数据获取的稳定性。在文本分析环节,采用jieba分词和TF-IDF算法提取高频关键词,结合词云可视化展示用户关注点。分析结果显示位置、服务、卫生是核心关注维度,同时识别出好评与差评的关键驱动因素。该方法为酒店服务优化和消费者决策提供了数据支持,并可通过扩展实现更深入的情感分析和竞品对比。 阅读详情

相关推荐

R3LIVE 1.0 适配 Velodyne 16线雷达:3步配置解决150米漂移问题

本文详细解析了R3LIVE 1.0适配Velodyne 16线雷达时出现的150米漂移问题,并提供三步配置方案。通过调整雷达类型设置、运动补偿与时间对齐、视觉-激光联合优化等关键参数,有效解决了系统漂移问题,提升定位精度。适用于机器人定位与建图领域的开发者。

weixin_29054195的博客 271

Redis哨兵模式搭建示例(配置开机自启)

Redis配置哨兵模式示例(Sentinel),附带开机自启配置说明

cl617287的博客 1500

图片数据爬取工具Image-Downloader的安装和使用

文章目录1、python安装2、下载chromedriver并配置3、下载phantomjs并配置.4、安装相关python库5、使用 安装包地址:https://github.com/sczhengyabin/Image-Downloader 下载: 方式一:打开cmd,输入: git clone https://github.com/sczhengyabin/Image-Downloader.git 方式二:打开网址 1、python安装 该数据爬取工具要求python>=3.5,由于

wxplol的博客 6674

Redis的几种高可用方案部署

主从切换技术的操作是:当主机宕机后,需要手动把一台从机切换为主机。这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis 从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。它是“谋朝篡位”的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从机转换为主机。哨兵模式是一种特殊的模式,首先 Redis 提供了哨兵的命令,哨兵是一个独立的进程,它会独立运行。

WU18948905539的博客 2050

VisionMaster4.2.0与C#控件开发实战:从入门到精通的完整指南

本文详细介绍了VisionMaster4.2.0与C#控件开发的实战指南,从基础环境搭建到核心控件使用,再到高级功能实现。通过VmFrontendControl、VmGlobalToolControl等核心控件的深入解析,帮助开发者快速掌握机器视觉应用开发技巧,提升开发效率。特别适合需要集成VisionMaster4.2.0 SDK进行视觉系统开发的C#程序员。

weixin_42665725的博客 383

R语言生存分析

自己整理编写的R语言常用数据分析模型的模板,原文件为Rmd格式,直接复制粘贴过来,作为个人学习笔记保存和分享。部分参考薛毅的《统计建模与R软件》和《R语言实战》生存分析是研究生存时间的分布规律,以及生存时间和相关因素之间关系的一种统计分析方法。生存分析在医学科学研究中具有广泛而重要的应用价值,它对人群寿命的研究,各种慢性疾病的现场追踪研究,临床疗效试验和动物试验等研究中随访资料的处理骑着举足轻重的作

Tiaaaaa的博客 2万+

Redis高可用方法及配置

主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master),后者称为从节点(Slave);数据的复制是单向的,只能由主节点到从节点。默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。主从切换技术的方法是:当服务器宕机后,需要手动一台从机切换为主机,这需要人工干预,不仅费时费力而且还会造成一段时间内服务不可用。为了解决主从复制的缺点,就有了哨兵机制。

m0_74412260的博客 1617

Windows Server安装Intel I219-V网卡驱动完整教程

在Windows Server系统上安装Intel I219-V网卡驱动的方法。

小白成长历程 5188

Redis高可用部署

Redis 实现高可用有三种部署模式:主从模式,哨兵模式,集群模式。

2301_76171195的博客 1198

一文看懂—Agent多智能体协作

多智能体协作已成为AI应对复杂任务的关键范式,通过模拟人类团队分工,实现专业化、高效化和纠错能力。本文系统阐述了多智能体协作的核心概念(智能体分工、工作流编排、工具使用)、与产品规划的关联(任务拆解、错误处理、组织架构设计),以及典型应用场景(报告生成、客服工单、学习规划)。同时剖析了常见陷阱(循环卡死、信息失真、成本失控)及解决方案,并提供了实用工具模板(角色定义卡、工作流画布、成本仪表盘)。最后通过市场竞品分析和旅行规划两个实战案例,展示了多智能体协作的实际价值。该技术正推动AI从单点智能迈向系统智能,

lee006006的博客 1036

U盘装Linux系统完整教程:从镜像写入到启动安装

Linux系统安装是许多开发者入门时面临的第一道门槛,其核心原理是将ISO镜像以可引导方式写入U盘,使U盘成为临时启动设备。这一过程涉及镜像校验、分区方案选择(如GPT与MBR)、UEFI与Legacy启动模式差异等基础技术概念。掌握U盘启动盘制作不仅能帮助开发者快速部署Linux环境,还可用于系统修复、数据恢复和硬件兼容性测试。在实际应用中,Rufus、balenaEtcher等写入工具的选择、BIOS启动顺序设置以及GRUB引导程序配置是关键环节。本文围绕U盘安装Linux的完整流程,详细讲解镜像写入、

weixin_30899023的博客 243

Redis高可用架构与监控部署指南

Redis高可用架构与监控部署指南 Redis核心架构 主从复制:搭建Master-Slave架构实现读写分离,通过replicaof配置实现数据同步。 哨兵模式:部署3节点Sentinel集群监控主从状态,支持自动故障转移(配置quorum=2)。 持久化策略:同步启用RDB快照和AOF日志,配置save规则和appendfsync everysec平衡性能与安全。 关键配置项 主节点绑定内网IP并关闭protected-mode 所有节点设置统一密码(requirepass + masterauth)

希望大家一起进步吧!!! 199

数据分析案例-电脑笔记本价格数据可视化分析3

本文基于Kaggle笔记本数据集(1303条记录,13个变量),使用Python进行数据可视化分析。通过自定义函数预处理了CPU频率、内存类型等关键特征,利用Seaborn和Matplotlib绘制了品牌分布、内存类型占比、价格影响因素等可视化图表。研究发现:1)Dell和Lenovo市场份额最大;2)SSD是主流存储类型;3)高RAM配置普遍采用SSD;4)Intel处理器占据绝对优势。分析揭示了不同品牌、配置与价格的关系,为消费者购买决策和市场策略制定提供了数据支持。

m0_64336780的博客 1万+

翼支付门户架构之redis高可用部署及监控

一、Redis Sentinel简介 Redis Sentinel是redis自带的集群管理工具,主要功能有 1、监控(Monitoring):Redis Sentinel实时监控主服务器和从服务器运行状态; 2、提醒(Notification):当被监控的某个Redis服务器出现问题时,Redis Sentinal可以向系统管理员发送通知,也可以通过API向其他程序发送通知; 3、自动故

lichunan的专栏 1643

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

Redis高可用集群一sentinel哨兵集群概述

在分布式架构中,Redis 的高可用性(High Availability, HA)是保障业务稳定运行的关键。​Redis Sentinel(哨兵集群)​​ 作为官方推荐的 HA 解决方案,通过自动化监控、故障检测和主从切换,有效解决了单点故障问题。Sentinel 采用分布式共识机制,确保在主节点(Master)宕机时,能够快速、可靠地选举新主节点,并通知客户端更新拓扑信息,从而最小化服务中断时间。理解 Sentinel 的核心原理与最佳实践,是构建健壮 Redis 集群的重要基础。

m0_58259081的博客 2572

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候 提示IE WebControls 不通过,这个工具可以欺骗u8的检查。 跳过U8环境检测的IE WebControls。提示导入失败后,重新检测通过。

Docker-GitLab Redis集群部署终极指南:主从复制与哨兵高可用配置

想要构建企业级的GitLab代码托管平台吗?Redis集群的高可用配置是确保系统稳定运行的关键环节!🚀 在Docker环境中部署GitLab时,Redis作为关键组件负责会话存储、缓存和后台任务队列。本文将为您详细解析如何配置Redis主从复制与哨兵模式,打造真正的高可用架构。 ## 为什么需要Redis高可用性? 在GitLab的架构中,Redis承担着至关重要的角色。它不仅存储用户会话信

gitblog_00679的博客 399

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

Redis集群运维实战:从节点部署到故障自愈全指南

Redis集群(Redis Cluster)是解决单节点性能瓶颈和高可用性的核心方案,但节点扩缩容、脑裂防护、性能监控等运维难题常让开发者头疼。本文基于Redis官方工具链,通过**3大实战场景+5个核心命令+2套自动化脚本**,带你系统化掌握集群运维技术,让你的分布式缓存系统稳如磐石。 ## 一、集群快速部署:3步搭建高可用架构 ### 1.1 环境准备与配置 Redis集群要求至少3个主...

gitblog_00853的博客 862

Apache Airflow高可用集群部署与故障恢复策略

Apache Airflow高可用集群部署与故障恢复策略 【免费下载链接】airflow Airflow 是一款用于管理复杂数据管道的开源平台,可以自动执行任务并监控其状态。高度可定制化、易于部署、支持多种任务类型、具有良好的可视化界面。灵活的工作流调度和管理系统,支持多种任务执行引擎。适用自动化数据处理流程的管理和调度...

gitblog_00910的博客 971

Scrapy-Redis在生产环境的部署指南:高可用架构设计终极方案

Scrapy-Redis作为Scrapy框架的分布式扩展,在生产环境中能够提供强大的爬虫集群管理能力。本指南将详细介绍如何设计高可用的Scrapy-Redis架构,确保你的爬虫系统能够稳定运行并处理海量数据。🚀 ## 为什么选择Scrapy-Redis进行分布式爬虫部署 Scrapy-Redis通过Redis作为消息队列和状态存储,实现了多个爬虫实例之间的任务协调和数据共享。在生产环境中,这

gitblog_00054的博客 946
上一篇: Redis的Java客户端Jedis的八种调用方式(事务、管道、分布式…)介绍
下一篇: redis 之sentinel配置
zljjava
博客等级 码龄15年 155粉丝 15原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值