redis+keepalived+haproxy集群的简单搭建

本文详细介绍Redis集群的搭建过程,包括配置与启动步骤、使用Keepalived实现高可用及HAProxy负载均衡配置。深入探讨了哈希槽、数据同步机制及集群状态维护等内容。
部署运行你感兴趣的模型镜像
#############################redis集群
参考
[url]http://www.cnblogs.com/wuxl360/p/5920330.html[/url]

redis-3.2.9
make PREFIX=/usr/local/redis install

cp redis-3.2.9/src/redis-trib.rb /usr/local/redis/bin/
cp redis-3.2.9/redis.conf 到
一台机器
/opt/redis_cluster/7000/redis.conf
/opt/redis_cluster/7001/redis.conf
/opt/redis_cluster/7002/redis.conf


另一台机器
/opt/redis_cluster/7003/redis.conf
/opt/redis_cluster/7004/redis.conf
/opt/redis_cluster/7005/redis.conf

每台配置如下,端口按照编号改
#############
port 7000 //端口7000,7002,7003
bind 本机ip //默认ip为127.0.0.1 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口,无法创建集群
daemonize yes //redis后台运行
pidfile /var/run/redis_7000.pid //pidfile文件对应7000,7001,7002
cluster-enabled yes //开启集群 把注释#去掉
cluster-config-file nodes_7000.conf //集群的配置 配置文件首次启动自动生成 7000,7001,7002
cluster-node-timeout 15000 //请求超时 默认15秒,可自行设置
appendonly yes //aof日志开启 有需要就开启,它会每次写操作都记录一条日志 
######################################

每台机器上启动redis
#/bin/sh
/usr/local/redis/bin/redis-server /opt/redis_cluster/7001/redis.conf
/usr/local/redis/bin/redis-server /opt/redis_cluster/7002/redis.conf
/usr/local/redis/bin/redis-server /opt/redis_cluster/7003/redis.conf

ps -ef|grep redis
3个进程
netstat -nltp|grep redis
6个端口

安装ruby
yum -y install ruby ruby-devel rubygems rpm-build -y
gem install redis

关联集群
./redis-trib.rb create --replicas 1 192.168.139.161:7000 192.168.139.161:7001 192.168.139.161:7002 192.168.139.193:7003 192.168.139.193:7004 192.168.139.193:7005

任意节点写入任意节点接收
./redis-cli -h 192.168.139.161 -c -p 7000
set hao ning
./redis-cli -h 192.168.139.193 -c -p 7005
get hao


redis cluster在设计的时候,就考虑到了去中心化,去中间件,也就是说,集群中的每个节点都是平等的关系,都是对等的,每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接,而且这些连接保持活跃,这样就保证了我们只需要连接集群中的任意一个节点,就可以获取到其他节点的数据。
Redis 集群没有并使用传统的一致性哈希来分配数据,而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot,当我们set一个key 时,会用CRC16算法来取模得到所属的slot,然后将这个key 分到哈希槽区间的节点上,具体算法就是:CRC16(key) % 16384。所以我们在测试的时候看到set 和 get 的时候,直接跳转到了7000端口的节点。
Redis 集群会把数据存在一个 master 节点,然后在这个 master 和其对应的salve 之间进行数据同步。当读取数据时,也根据一致性哈希算法到对应的 master 节点获取数据。只有当一个master 挂掉之后,才会启动一个对应的 salve 节点,充当 master 。
需要注意的是:必须要3个或以上的主节点,否则在创建集群时会失败,并且当存活的主节点数小于总节点数的一半时,整个集群就无法提供服务了。


######################keepalived########################
通常说的双机热备是指两台机器都在运行,但并不是两台机器都同时在提供服务。
当提供服务的一台出现故障的时候,另外一台会马上自动接管并且提供服务,而且切换的时间非常短。
keepalived的工作原理是VRRP(Virtual Router Redundancy Protocol)虚拟路由冗余协议。
在VRRP中有两组重要的概念:VRRP路由器和虚拟路由器,主控路由器和备份路由器。
VRRP路由器是指运行VRRP的路由器,是物理实体,虚拟路由器是指VRRP协议创建的,是逻辑概念。一组VRRP路由器协同工作,共同构成一台虚拟路由器。 Vrrp中存在着一种选举机制,用以选出提供服务的路由即主控路由,其他的则成了备份路由。当主控路由失效后,备份路由中会重新选举出一个主控路由,来继续工作,来保障不间断服务


wget http://www.keepalived.org/software/keepalived-1.3.5.tar.gz
./configure --prefix=/usr/local/keepalived
make
make install
设置虚ip 192.168.139.201


cat /usr/local/keepalived/etc/keepalived/keepalived.conf
一台机器上
#################
global_defs {
router_id NodeA
}

vrrp_instance VI_1 {
state MASTER #设置为主服务器
interface br-ex #监测网络接口
virtual_router_id 51 #主、备必须一样
priority 100 #(主、备机取不同的优先级,主机值较大,备份机值较小,值越大优先级越高)
advert_int 1 #VRRP Multicast广播周期秒数
authentication {
auth_type PASS #VRRP认证方式,主备必须一致
auth_pass 1111
}
virtual_ipaddress {
192.168.139.201/20 #VRRP HA虚拟地址
}
}
###############

另一台机器上
#################
global_defs {
router_id NodeB
}

vrrp_instance VI_1 {
state BACKUP
interface br-ex
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.139.201/20
}
}
###############
启动
/usr/local/keepalived/sbin/keepalived -D -f /usr/local/keepalived/etc/keepalived/keepalived.conf

ifconfig br-ex
ip a show br-ex
看ip地址
ip link show br-ex
看mac地址

ping 192.168.139.201
arp -a 看201的mac地址

然后kill掉主节点上的keepalived
再arp -a 看201的mac地址 变为backup节点的mac了

在两台机器上都tailf /var/log/message 看log变化


##########################haproxy################
yum install haproxy -y

haproxy 配置中分成五部分内容,分别如下:
1、global:参数是进程级的,通常是和操作系统相关。这些参数一般只设置一次,如果配置无误,就不需要再次进行修改
2、defaults:配置默认参数,这些参数可以被用到frontend,backend,Listen组件
3、frontend:接收请求的前端虚拟节点,Frontend可以更加规则直接指定具体使用后端的backend
4、backend:后端服务集群的配置,是真实服务器,一个Backend对应一个或者多个实体服务器
5、Listen Fronted和backend的组合体

作为redis的haproxy
需要配置
/etc/haproxy/haproxy.cfg
frontend 和 backend 先注释掉
使用tcp
###################
defaults
#mode http
mode tcp
log global
# option httplog
# option dontlognull
# option http-server-close
# option forwardfor except 127.0.0.0/8
# option redispatch
##############
最后加
##################
listen test1 0.0.0.0:6380
server s1 192.168.139.161:7000 check inter 2000 rise 2 fall 5
server s2 192.168.139.161:7001 check inter 2000 rise 2 fall 5
server s3 192.168.139.161:7002 check inter 2000 rise 2 fall 5
server s4 192.168.139.193:7003 check inter 2000 rise 2 fall 5
server s5 192.168.139.193:7004 check inter 2000 rise 2 fall 5
server s6 192.168.139.193:7005 check inter 2000 rise 2 fall 5
##############

./redis-cli -h 192.168.139.161 -c -p 6380

####################################
综上加了keepalived之后
./redis-cli -h 192.168.139.201 -c -p 6380

挂了任何以一个节点都可以正常访问

您可能感兴趣的与本文相关的镜像

Llama Factory

Llama Factory

模型微调
LLama-Factory

LLaMA Factory 是一个简单易用且高效的大型语言模型(Large Language Model)训练与微调平台。通过 LLaMA Factory,可以在无需编写任何代码的前提下,在本地完成上百种预训练模型的微调

<think>嗯,用户问的是Keepalived+Nginx能不能替代Haproxy+Keepalived。首先,我得弄清楚这两个组合各自的用途优缺点。Keepalived主要是用来做高可用性的,通过VRRP协议实现VIP的切换,防止单点故障。而NginxHaproxy都是负载均衡器,但它们在功能性能上可能有所不同。 首先,我应该回忆一下NginxHaproxy的主要区别。Nginx最初是作为Web服务器设计的,后来增加了反向代理负载均衡的功能。它的负载均衡支持HTTP、HTTPS,以及TCP/UDP,不过可能功能上不如Haproxy全面。Haproxy则是专业的负载均衡器,支持更多的协议,比如HTTP、TCP,特别是在四层七层负载均衡上表现更优,配置也更灵活,比如健康检查、会话保持等高级功能。 然后,需要考虑用户的需求场景。如果用户的应用场景主要是HTTP/HTTPS的负载均衡,并且需要Web服务器功能,可能Nginx更合适,因为可以同时处理静态内容。但如果需要更复杂的负载均衡策略,比如基于cookie的会话保持,或者对TCP应用的支持,Haproxy可能更适合。 接下来,高可用性方面,Keepalived在两个组合中都负责VIP的管理故障切换,这部分应该差别不大。关键在负载均衡器本身的稳定性性能。Haproxy在处理大量并发连接时可能更高效,尤其是在长连接的情况下,而Nginx在短连接静态内容处理上更有优势。 还要考虑配置维护的难易程度。Nginx的配置语法可能对用户更友好,尤其是如果用户已经熟悉Nginx的话。而Haproxy的配置虽然更强大,但可能需要更多的学习成本。 另外,健康检查机制也很重要。Haproxy的健康检查功能更全面,支持更细致的检查方式,而Nginx的健康检查可能需要第三方模块或者较新的版本才能支持。 可能用户的实际需求是替换现有的Haproxy+Keepalived,想了解是否可以用Nginx替代Haproxy来降低成本或者统一技术栈。这时候需要确认用户的具体应用场景,是否有特殊的功能需求,比如是否需要四层负载均衡,是否需要高级的负载均衡算法等。 还需要注意性能指标,比如并发连接数、请求处理速率、资源消耗等。Haproxy可能在处理大量并发时更高效,但Nginx如果配置得当,也能满足大部分场景的需求。 最后,总结一下,替换是否可行主要取决于具体的应用需求。如果场景适合Nginx的负载均衡能力,且不需要Haproxy的高级特性,那么替换是可行的。否则,可能需要保持Haproxy。</think>Keepalived+Nginx 与 Haproxy+Keepalived 的对比及替换可行性分析如下: --- ### **一、组合功能定位** 1. **Keepalived 的作用** - 通过 VRRP 协议实现**虚拟 IP (VIP)** 的高可用,主备节点自动切换。 - 核心能力:**故障检测与容灾**,不直接处理流量。 2. **Nginx 与 Haproxy 的核心差异** | **功能** | **Nginx** | **Haproxy** | |----------------------|----------------------------|---------------------------| | **主要角色** | Web 服务器 + 反向代理 | 专业四层/七层负载均衡器 | | **协议支持** | HTTP/HTTPS、TCP/UDP | HTTP、TCP、WebSocket 等 | | **健康检查** | 基础检查(需第三方模块增强)| 精细化检查(端口、内容) | | **负载均衡算法** | 轮询、加权、IP Hash 等 | 支持动态算法(如 Least Connections) | | **会话保持** | 依赖 IP Hash 或 Cookie | 内置 Cookie/Session 绑定 | | **性能** | 高并发短连接优势 | 长连接处理更高效 | --- ### **二、替换可行性场景** #### ✅ **适合替换的场景** 1. **HTTP/HTTPS 负载均衡** - Nginx 可完美替代 Haproxy,尤其需同时处理静态资源时。 2. **简单 TCP 服务代理** - 如 MySQL、Redis 等,Nginx 的 Stream 模块可支持。 3. **技术栈统一需求** - 若已有 Nginx 作为 Web 服务器,可简化架构。 #### ❌ **不适合替换的场景** 1. **复杂四层负载均衡** - 如需要精细的 TCP 连接管理,Haproxy 更专业。 2. **高级会话保持需求** - Haproxy 的 Session 绑定策略更灵活。 3. **大规模长连接场景** - Haproxy 的内存管理更优,适合高并发长连接。 --- ### **三、性能对比** - **短连接场景** Nginx 的 Epoll 模型表现优异,适合 Web 请求。 - **长连接场景** Haproxy 的资源占用更低,适合数据库、消息队列等长连接服务。 --- ### **四、配置复杂度** - **Nginx** ```nginx http { upstream backend { server 192.168.1.10:80 weight=5; server 192.168.1.11:80; check interval=3000 rise=2 fall=3; # 需集成第三方模块 } } ``` - **Haproxy** ```haproxy backend app balance roundrobin server s1 192.168.1.10:80 check cookie s1 server s2 192.168.1.11:80 check cookie s2 ``` Haproxy 原生支持更丰富的负载均衡配置。 --- ### **五、结论** 1. **可平替条件** - 业务以 HTTP 为主,无需复杂四层代理。 - 健康检查、会话保持需求简单。 - 需兼顾 Web 服务与负载均衡。 2. **建议保留 Haproxy** - 存在 TCP 长连接、精细会话管理需求时。 - 超大规模集群需极致性能优化时。 **最终决策需结合业务流量特征、运维成本功能需求综合评估。**
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值