您的位置：360文档中心› Keepalived+HAproxy实现redis高可用负载均衡

Keepalived+HAproxy实现redis高可用负载均衡

Keepalived+HAproxy实现redis高可用负载均衡
Keepalived+HAproxy实现redis高可用负载均衡

Keepalived+HAproxy实现redis的高可用负载均衡

总概：

Keepalived是一个类似于layer3, 4 & 5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。

这里我利用HAproxy对多台redis服务器进行负载，然后用Keepalived对HAproxy进行监控：（主）服务器A：192.168.4.143 （从）服务器B：192.168.4.126

A上安装redis(主)、reids-slave1(从)、redis-slave2(从)、HAproxy、Keepalived

B上安装redis-slave3（从）、redis-slave4（从）、HAproxy、Keepalived

Keepalived监控A、B上的HAproxy，利用Keepalived的VIP漂移技术，若A、B上的HAprox 都工作正常，则VIP与优先级别高的服务器（主服务器）绑定，当主服务器当掉时，则与从服务器绑定，而VIP则是暴露给外部访问的ip；HAproxy利用Keepalived生产的VIP对多台redis（从）进行读负载，当某台redis当掉，则将其移除，回复后加入集群。

安装redis

1、下载后解压tar zxvf redis-2.6.14.tar.gz 到任意目录，例如/usr/local/redis-2.6.14

解压后，进入redis目录

cd /usr/local/redis-2.6.14

make&& make install

2、配置redis

vi /usr/local/redis-2.6.14/redis.conf

redis配置文件参数说明：

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程

daemonize no

2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

pidfile /var/run/redis.pid

3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字

port 6379

4. 绑定的主机地址

bind 127.0.0.1

5.当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能

timeout 300

6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose

loglevel verbose

7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null

logfile stdout

8. 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

databases 16

9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

save

Redis默认配置文件中提供了三个条件：

save 900 1

save 300 10

save 60 10000

分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes

11. 指定本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb

12. 指定本地数据库存放目录

dir ./

13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

slaveof

14. 当master服务设置了密码保护时，slav服务连接master的密码

masterauth

15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭

requirepass foobared

16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

maxclients 128

17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

maxmemory

18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同

步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no

appendonly no

19. 指定更新日志文件名，默认为appendonly.aof

appendfilename appendonly.aof

20. 指定更新日志条件，共有3个可选值：

no：表示等操作系统进行数据缓存同步到磁盘（快）

always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）

everysec：表示每秒同步一次（折衷，默认值）

appendfsync everysec

21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）

vm-enabled no

22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据就是keys),也就是说,当

vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0

vm-max-memory 0

24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值

vm-page-size 32

25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。

vm-pages 134217728

26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

vm-max-threads 4

27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启

glueoutputbuf yes

28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）

activerehashing yes

30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

include /path/to/local.conf

安装keepalived

1、下载后解压tar zxvf keepalived-1.2.7.tar.gz 到任意目录，例如/usr/local/keepalived-1.2.7 解压后，进入keepalived目录

cd /usr/local/keepalived-1.2.7

./configure

Make&& make install

（注：若这里报错提示没有装openssl，则执行yum –y install openssl-devel安装，若还有其他的包没装，则执行yum命令进行安装）

2、配置keepalived

cp /usr/local/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/

cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/

mkdir /etc/keepalived

cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/

ln -s /usr/local/sbin/keepalived /usr/sbin/

vi /etc/keepalived.conf

! Configuration File for keepalived

vrrp_script chk_haproxy {

script "/etc/keepalived/check_haproxy.sh"

interval 2

}

vrrp_instance VI_1 {

state MASTER #从服务器上改为BACKUP

interface eth5 #用ipconfig查看

virtual_router_id 51

priority 150 #从服务器上改为120

authentication {

auth_type PASS

auth_pass 1111

}

track_script {

chk_haproxy

}

virtual_ipaddress {

192.168.4.200

}

}

}

vi /etc/keepalived/check_haproxy.sh

#!/bin/bash

A=`ps -C haproxy --no-header |wc -l`

if [ $A -eq 0 ];then

/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.conf

sleep 3

if [ `ps -C haproxy --no-header |wc -l` -eq 0 ];then

/etc/init.d/keepalived stop

fi

fi

chmod 755 /etc/keepalived/check_haproxy.sh

安装HAproxy

1、下载后解压tar zxvf haproxy-1.4.24.tar.gz 到任意目录，例如/usr/local/haproxy-1.4.24 解压后，进入keepalived目录

cd /usr/local/haproxy-1.4.24

make TARGET=linux26 PREFIX=/usr/local/haproxy

将haproxy安装到/usr/local/haproxy

make install PREFIX=/usr/local/haproxy

2、配置HAproxy

cd /usr/local/haproxy

vi haproxy.cfg

（注：这里是没有haproxy.cfg文件的，可以回到安装文件目录下将examples下的haproxy.cfg 拷贝到usr/local/haproxy下）

global

log 127.0.0.1 local0

maxconn 3000 #限制单个进程的最大连接数

chroot /usr/local/haproxy

uid 99 #所属运行用户，默认99为nobody

gid 99 #所属运行用户组，默认99为nobody

daemon #让进程作为守护进程在后台运行

quiet

nbproc 2 #指定作为守护进程运行时的进程数

pidfile /usr/local/haproxy/haproxy.pid

defaults

log global

mode http

option httplog

option dontlognull #不记录空连接

log 127.0.0.1 local3 info #日志级别[err warning info debug]

retries 3 #设置在一个服务器上链接失败后的重连次数

option redispatch #在连接失败或断开的情况下，允许当前会话被重新分发

maxconn 3000 #可被发送到后端服务器的最大并发连接数

contimeout 5000ms #设置等待连接到服务器成功的最大时间

clitimeout 50000ms #设置客户端的最大超时时间

srvtimeout 50000ms #设置服务器端的最大超时时间

listen cluster 192.168.4.200:6380 #运行的端口及主机名(这里用keepalived虚拟的ip及端口) mode tcp #使用tcp的4层模式

balance roundrobin #设置服务器负载分配算法

#option httpclose

option forwardfor

#option httpchk GET /keepalive.html #健康检测页面

server redis-slave1 192.168.4.143:63791 weight 100 check inter 2000 rise 2 fall 3

server redis-slave2 192.168.4.143:63792 weight 100 check inter 2000 rise 2 fall 3

server redis-slave3 192.168.4.126:63791 weight 100 check inter 2000 rise 2 fall 3 server redis-slave4 192.168.4.126:63792 weight 100 check inter 2000 rise 2 fall 3

# weight - 调节服务器的负重

# check - 允许对该服务器进行健康检查

# inter - 设置连续的两次健康检查之间的时间，单位为毫秒(ms)，默认值2000(ms)

# rise - 指定多少次连续成功的健康检查后，可认定该服务器处于可操作状态，默认值2 # fall - 指定多少次不成功的健康检查后，认为服务器为当掉状态，默认值3

# maxconn - 指定可被发送到该服务器的最大并发连接数

listen localhost *:8888 #监控页面的端口

mode http

transparent

stats refresh 10s #统计页面自动刷新时间

stats uri /haproxyadmin #监控页面的访问地址

stats realm Haproxy \ statistic #统计页面密码框上提示文本

stats auth shiwei:shiwei #统计页面用户名和密码设置

stats hide-version #隐藏统计页面上HAProxy的版本信息

3、加上日志支持

vim /etc/rsyslog.conf

在最下边增加

local3.* /var/log/haproxy.log

local0.* /var/log/haproxy.log

vim /etc/sysconfig/rsyslog

修改：SYSLOGD_OPTIONS="-r -m 0"

重启日志服务service rsyslog restart

测试

（主）服务器A(192.168.4.143)：

配置redis-slave1

cd /usr/local/redis-2.6.14

cp redis.conf redis.salve

vi redis.slave

修改端口：

# Accept connections on the specified port, default is 6379.

# If port 0 is specified Redis will not listen on a TCP socket.

port 63791

配置主从：

# Master-Slave replication. Use slaveof to make a Redis instance a copy of

# another Redis server. Note that the configuration is local to the slave

# so for example it is possible to configure the slave to save the DB with a

# different interval, or to listen to another port, and so on.

#

# slaveof

slaveof localhost 6379

同上配置redis-slave2

cp redis.conf redis.salve2

vi redis.slave2

修改端口：

# Accept connections on the specified port, default is 6379.

# If port 0 is specified Redis will not listen on a TCP socket.

port 63792

配置主从：

# Master-Slave replication. Use slaveof to make a Redis instance a copy of # another Redis server. Note that the configuration is local to the slave

# so for example it is possible to configure the slave to save the DB with a # different interval, or to listen to another port, and so on.

#

# slaveof

slaveof localhost 6379

启动redis、redis-slave1、redis-slave2

/usr/local/redis-2.6.14/src/redis-server /usr/local/redis-2.6.14/redis.conf (若未配置成daemonize yes则会打印启动信息)

/usr/local/redis-2.6.14/src/redis-server /usr/local/redis-2.6.14/redis.slave /usr/local/redis-2.6.14/src/redis-server /usr/local/redis-2.6.14/redis.slave2

（从）服务器B(192.168.4.126)：

配置redis-slave3

cd /usr/local/redis-2.6.14

cp redis.conf redis.salve

vi redis.slave

修改端口：

# Accept connections on the specified port, default is 6379.

# If port 0 is specified Redis will not listen on a TCP socket.

port 63791

配置主从：

# Master-Slave replication. Use slaveof to make a Redis instance a copy of # another Redis server. Note that the configuration is local to the slave

# so for example it is possible to configure the slave to save the DB with a # different interval, or to listen to another port, and so on.

#

# slaveof

slaveof 192.168.4.143 6379

同上配置redis-slave4

cp redis.conf redis.salve2

vi redis.slave2

修改端口：

# Accept connections on the specified port, default is 6379.

# If port 0 is specified Redis will not listen on a TCP socket.

port 63792

配置主从：

# Master-Slave replication. Use slaveof to make a Redis instance a copy of

# another Redis server. Note that the configuration is local to the slave

# so for example it is possible to configure the slave to save the DB with a

# different interval, or to listen to another port, and so on.

#

# slaveof

slaveof 192.168.4.143 6379

启动redis-slave3、redis-slave4

/usr/local/redis-2.6.14/src/redis-server /usr/local/redis-2.6.14/redis.slave

/usr/local/redis-2.6.14/src/redis-server /usr/local/redis-2.6.14/redis.slave2

这时候在主服务器上连接redis查看信息

/usr/redis-2.6.14/src/redis-cli info

# Replication

role:master

connected_slaves:4

slave0:127.0.0.1,63791,online

slave1:127.0.0.1,63792,online

slave2:192.168.4.126,63791,online

slave3:192.168.4.126,63792,online

两台服务器的redis的主从配置OK。

主服务器上启动Keepalived

[root@alex]# service keepalived start

正在启动keepalived：[确定]

(Keepalived启动后会去检查HAproxy,若HAproxy未启动，则启动HAproxy,若启动HAproxy失败，则关闭Keepalived)

查看keepalived状况：

[root@alex]# service keepalived status

keepalived (pid 5420) 正在运行...

查看HAproxy状况：

[root@alex]# ps -aux|grep haproxy

Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ

nobody 5430 0.0 0.0 11980 944 ? Ss 16:37 0:00 /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.conf

nobody 5431 0.0 0.0 11980 944 ? Ss 16:37 0:00 /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/haproxy.conf

root 5618 0.0 0.0 103252 844 pts/2 S+ 16:38 0:00 grep haproxy Keepalived启动后自动将HAproxy启动了，查看Keepalived生成的VIP是否与主服务器绑定

[root@alex]# ip addr

1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth5: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 08:00:27:42:71:2d brd ff:ff:ff:ff:ff:ff

inet 192.168.4.143/24 brd 192.168.4.255 scope global eth5

inet 192.168.4.200/32 scope global eth5

inet6 fe80::a00:27ff:fe42:712d/64 scope link

valid_lft forever preferred_lft forever

VIP绑定OK。

打开HAproxy的图形管理界面：

浏览器输入http://localhost:8888/haproxy-admin

用户名shiwei 密码shiwei

这时候我们Kill掉HAproxy，Keepalived检查到后会重新将HAproxy启动。

[root@alex sysconfig]# killall haproxy

[root@alex sysconfig]#

刷新页面，可以看到HAproxy的pid改变了。

这时我们将主服务器上的keepalived当掉，看VIP是否漂移到了从服务器上，从服务器接管服务。

主服务器上：

[root@alex]# killall keepalived

[root@alex sysconfig]# ip addr

1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth5: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 08:00:27:42:71:2d brd ff:ff:ff:ff:ff:ff

inet 192.168.4.143/24 brd 192.168.4.255 scope global eth5

inet6 fe80::a00:27ff:fe42:712d/64 scope link

valid_lft forever preferred_lft forever

从服务器上：

[root@alex 桌面]# ip addr

1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth6: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 08:00:27:be:47:90 brd ff:ff:ff:ff:ff:ff

inet 192.168.4.126/24 brd 192.168.4.255 scope global eth6

inet 192.168.4.200/32 scope global eth6

inet6 fe80::a00:27ff:febe:4790/64 scope link

valid_lft forever preferred_lft forever

VIP漂移OK。

这时候重启主服务器的Keepalived，查看VIP是否漂移回来。

[root@alex]# service keepalived start

正在启动keepalived：[确定]

[root@alex]# ip addr

1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth5: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 08:00:27:42:71:2d brd ff:ff:ff:ff:ff:ff

inet 192.168.4.143/24 brd 192.168.4.255 scope global eth5

inet 192.168.4.200/32 scope global eth5

inet6 fe80::a00:27ff:fe42:712d/64 scope link

valid_lft forever preferred_lft forever

VIP漂移到主服务器。

接下来主服务器上通过VIP连接redis

[root@alex 桌面]# /usr/local/redis-2.6.14/src/redis-cli -h 192.168.4.200 -p 6379

redis 192.168.4.200:6379> keys *

(empty list or set)

redis 192.168.4.200:6379> set name shiwei

OK

redis 192.168.4.200:6379> keys *

1) "name"

redis 192.168.4.200:6379>

实地址连接redis

redis 192.168.4.200:6379> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.143 -p 6379

redis 192.168.4.143:6379> keys *

1) "name"

redis 192.168.4.143:6379>

VIP连接redis-slave(注：这里我们不知道VIP访问哪台从redis，redis-slave1/3、2/4端口相同)

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.200 -p 6380

redis 192.168.4.200:6380> keys *

1) "name"

redis 192.168.4.143:6380> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.200 -p 63791

redis 192.168.4.200:63791> keys *

1) "name"

redis 192.168.4.200:63791> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.200 -p 63792

redis 192.168.4.200:63792> keys *

1) "name"

redis 192.168.4.126:63792> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.200 -p 63793

Could not connect to Redis at 192.168.4.126:63793: Connection refused

not connected>

实地址连接redis-slave1、redis-slave2、redis-slave3、redis-slave4

redis 192.168.4.200:63792> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.143 -p 63791

redis 192.168.4.143:63791> keys *

1) "name"

redis 192.168.4.143:63791> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.143 -p 63792

redis 192.168.4.143:63792> keys *

1) "name"

redis 192.168.4.143:63792>quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.126 -p 63791

redis 192.168.4.126:63791> keys *

1) "name"

redis 192.168.4.126:3791> quit

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-cli -h 192.168.4.126 -p 63792

redis 192.168.4.126:63792> keys *

1) "name"

redis 192.168.4.263:63792>

主服务器上redis压力测试：

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-benchmark -h 192.168.4.143 -p 6379 -t get -q -r 1000 -n 100000 -c 800

GET: 25361.40 requests per second

主服务器redis-slave1压力测试

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-benchmark -h 192.168.4.143 -p 63791 -t get -q -r 1000 -n 100000 -c 800

GET: 26532.24 requests per second

VIP压力测试：

[root@alex 桌面]# /usr/redis-2.6.14/src/redis-benchmark -h 192.168.4.200 -p 6380 -t get -q -r 1000 -n 100000 -c 800

GET: 4803.54 requests per second

[root@alex 桌面]#

redis3.0.2 分布式集群安装详细步骤

redis3.0.2 分布式集群安装详细步骤 --(centos5.8 X64系统) 版本历史 一: redis cluster介绍篇 1:redis cluster的现状 目前redis支持的cluster特性(已亲测): 1):节点自动发现 2):slave->master 选举,集群容错 3):Hot resharding:在线分片 4):进群管理:cluster xxx 5):基于配置(nodes-port.conf)的集群管理 6):ASK 转向/MOVED 转向机制. 2:redis cluster 架构 1)redis-cluster架构图

架构细节: (1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽. (2)节点的fail是通过集群中超过半数的节点检测失效时才生效. (3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可 (4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value 2) redis-cluster选举:容错

(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master 节点通信超过(cluster-node-timeout),认为当前master节点挂掉. (2):什么时候整个集群不可用(cluster_state:fail),当集群不可用时,所有对集群的 操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成进群的slot映射[0-16383]不完成时进入fail状态. b:如果进群超过半数以上master挂掉，无论是否有slave集群进入fail状态. 二.Redis集群安装篇(centos5.8 X64系统) （要让集群正常工作至少需要3个主节点，在这里我们要创建6个redis节点，其中三个为主节点，三个为从节点，对应的redis节点的ip和端口对应关系如下）

LVS keepalived负载均衡高可用 配置安装大全

LVS+Keepalived实现高可用集群 一、基础介绍 (2) 二、搭建配置LVS-NA T模式 (2) 三、搭建配置LVS-DR模式 (4) 四、另外一种脚本方式实现上面LVS-DR模式 (6) 五、keepalived + LVS(DR模式) 高可用 (8) 六、Keepalived 配置文件详细介绍 (11)

一、基础介绍 (一)根据业务目标分成三类： High Availability 高可用 Load Balancing 负载均衡 High Performance 高性能 (二)实现集群产品： HA类： rhcs、heartbeat、keepalived LB类： haproxy、lvs、nginx、f5、piranha HPC类： https://www.360docs.net/doc/6a10108957.html,/index/downfile/infor_id/42 (三)LVS 负载均衡有三种模式： LVS-DR模式（direct router）直接路由模式 进必须经过分发器，出就直接出 LVS-NAT模式（network address translation） 进出必须都经过分发器 LVS-TUN模式（ip tunneling）IP隧道模式 服务器可以放到全国各地 二、搭建配置LVS-NAT模式 1 、服务器IP规划： DR服务器添加一张网卡eth1，一个网卡做DIP，一个网口做VIP。 设置DIP、VIP IP地址: DIP的eth1和所有RIP相连同一个网段 CIP和DIP的eth0(Vip)相连同一个网段 Vip eth0 192.168.50.200 Dip eth1 192.168.58.4 客户机IP： Cip 192.168.50.3

Redis高可用VIP漂移方法、终端及存储介质与制作流程

本技术公开了一种Redis高可用VIP漂移方法、终端及存储介质，属于云数据库，要解决的技术问题为如何在确保Redis节点密钥的安全性、且主从节点身份切换时不会导致服务状态混乱的前提下，实现VIP漂移的问题。方法包括：通过哨兵监测每个Redis节点的运行状态；通过节点监控器监测对应Redis节点的身份；通过哨兵切换两个Redis节点的主从身份，通过部署于原主节点中的节点监控器将原节点与VIP解绑，通过部署于切换后主节点中的节点监控器将切换后主节点与VIP绑定。终端中处理器被配置用于调用程序指令执行上述方法。存储介质存储有计算机程序，计算机程序中程序指令当被处理器执行时处理器执行上述方法。 权利要求书 1.一种Redis高可用VIP漂移方法，其特征在于用于实现两个Redis节点之间主从身份的切换以及VIP漂移，所述两个Redis节点中一个节点的身份为主节点并绑定VIP，另一个节点的身份为从节点不绑定VIP，主节点和从节点数据同步，所述方法包括： 通过哨兵监测每个Redis节点的运行状态；

每个Redis节点均部署有节点监控器，通过节点监控器监测对应Redis节点的身份； 当哨兵监测到节点异常时，通过哨兵切换两个Redis节点的主从身份，每个节点监控器监测到对应的Redis节点的身份变化后，通过部署于原主节点中的节点监控器将原节点与VIP解绑，通过部署于切换后主节点中的节点监控器将切换后主节点与VIP绑定。 2.根据权利要求1所述的一种Redis高可用VIP漂移方法，其特征在于当哨兵监测到节点异常时，通过哨兵切换两个Redis节点的主从身份，并将切换后每个Redis节点的身份存储于哨兵。 3.根据权利要求2所述的一种Redis高可用VIP漂移方法，其特征在于每个Redis节点本地保存其身份，包括更新并保存切换后的身份。 4.根据权利要求3所述的一种Redis高可用VIP漂移方法，其特征在于所述节点监控器的工作包括： 监测对应Redis节点的身份； 如果所述Redis节点当前身份为主节点，判断所述Redis节点是否已绑定VIP，如果所述Redis 节点已绑定VIP，则监测对应Redis节点的身份，如果所述Redis节点未绑定VIP，则将所述Redis节点绑定VIP； 如果所述Redis节点当前身份为从节点，判断所述Redis节点是否已解绑VIP，如果所述Redis 节点已解绑VIP，则继续监测对应Redis节点的身份，如果所述Redis节点未解绑VIP，则将所述Redis节点解绑VIP。 5.根据权利要求4所述的一种Redis高可用VIP漂移方法，其特征在于节点监控器监测对应Redis节点的身份，包括如下步骤： 获取本地保存的身份；

利用LVS+Keepalived 实现高性能高可用负载均衡服务器

LVS+Keepalived 介绍 LVS LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）； 十种调度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）。 Keepalvied Keepalived在这里主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP 主机之间failover的实现 二. 网站负载均衡拓朴图 IP信息列表： 名称 IP LVS-DR-Master 61.164.122.6 ? LVS-DR-BACKUP 61.164.122.7 ? LVS-DR-VIP 61.164.122.8 ? WEB1-Realserver 61.164.122.9 ? WEB2-Realserver 61.164.122.10 ? GateWay 61.164.122.1 复制代码 三. 安装LVS和Keepalvied软件包 1. 下载相关软件包 #mkdir /usr/local/src/lvs ? #cd /usr/local/src/lvs ? #wget https://www.360docs.net/doc/6a10108957.html,/software/kernel-2.6/ipvsadm-1.24.tar.gz ? #wget https://www.360docs.net/doc/6a10108957.html,/software/keepalived-1.1.15.tar.gz 复制代码 2. 安装LVS和Keepalived #lsmod |grep ip_vs ? #uname -r ? 2.6.18-53.el5PAE ? #ln -s /usr/src/kernels/2.6.18-53.el5PAE-i686/ /usr/src/linux ? ? #tar zxvf ipvsadm-1.24.tar.gz ? #cd ipvsadm-1.24 ? #make && make install ? #find / -name ipvsadm # 查看ipvsadm的位置 ? ? #tar zxvf keepalived-1.1.15.tar.gz ? #cd keepalived-1.1.15 ? #./configure && make && make install

redis主备部署方案

redis主备部署方案 Redis部署方式采用主备的方式，通过keepalived来对外提供虚IP，并实现主备自动切换功能。 主实例A：192.168.20.30 备实例B：192.168.20.232 虚IP：192.168.20.110 正常工作时，虚IP在主实例A上，主实例A上的数据自动同步到备实例B上，当主实例A挂掉之后，备实例B将自动接管虚IP，并将redis转换为主模式，待原主实例A恢复后，A将自动切换成备模式，从B上同步数据，主备角色互换，实现融灾备份。 安装部署步骤如下： 1.安装keepalived wget https://www.360docs.net/doc/6a10108957.html,/software/keepalived-1.2.6.tar.gz tarzxvf keepalived-1.2.6.tar.gz cd keepalived-1.2.6 ./configure 如果报错 configure: error: !!! OpenSSL is not properly installed on your system. !!! !!! Can not include OpenSSL headers files. 解决办法： yum -y install openssl-devel yum -y install popt-devel ln -s /usr/src/kernels/2.6.32-220.el6.x86_64/ /usr/src/linux ./configure make make install cp /usr/local/etc/rc.d/init.d/keepalived /etc/rc.d/init.d/ cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/ cp /usr/local/sbin/keepalived /usr/sbin/ mkdir /etc/keepalived 添加keepalived的配置项： vi /etc/keepalived/keepalived.conf global_defs { router_id LVS_DEVEL } vrrp_scriptMonitor_Redis { script "/home/bbcv/redis/redis_keepalive.sh"

系统部署方案与优化

系统部署方案与优化 方案背景： 目前部署在阿里云上的系统存在内存不够用，不定期的应用假死 问题。为了解决这些问题并能够很好的对系统的扩展性和可用性进行配置。系统需要进行部署改造。为此提出改造方案。 目前的通讯过程主要有2中构成，分别如下表： 详细的通讯过程如下图： ActiveMQ 消息 服务器数据库 Tomcat 应用服务器支付客户端1 支付客户端N 支付宝 财付通 支付网关7、消息发送 1、发送请求 4、返回结果 2、处理后发送 3、处理后返回6、发送回调消息 5、异步回调 图：通讯过程 其中通讯虚线标识是一次连接，但该连接为用完即关闭，特点为连接 序号 通讯路径 备注 1 ○1 ○2 ○3 ○4 生成订单、主动查询、退款、取消订单 2 ○5 ○6 ○7 付款通知

时间比较短。图中实线标识该为一个连接，但该连接具有连接时间长的特点，一般是系统起来后进行连接，系统主要注销后关闭。其中步骤6采用的连接池技术。从图中可以看出目前主要的瓶颈分别内存、硬盘速度和大小、带宽（目前较好）。 分别讨论如下： 目前的内存的主要消耗对象为： 内存消耗对象分析 序号系统主要对象建议内存 1 Tomcat应用服 务器目前没有使用缓存技术，主要是线程占 用数和连接数占用相关的内存 4G 2 ActiveX消息服 务器主要是连接数和消息的存储（自带数据 库存储引擎） 4G 3 Mysql 查询缓存4G 4 操作系统进程管理、调度10% 4 预留应急和升级20% 结论：建议采用16G内存。因虚拟机内存可以调整，在开始阶段可以采用8G的内存（节省开支），支撑的数量高了调整为16G. 关于CPU,建议4核心CPU及以上。主要用来给Mysql、java使用。数据量来后，可以将mysql单独部署到独立的虚机上。 如果部署mysql，建议硬盘100G。不部署mysql50G即可。 本部署方案为迁移的方案，为计算优化需要的各个参数。

数据库负载均衡解决方案

双节点数据库负载均衡解决方案 问题的提出？ 在SQL Server数据库平台上，企业的数据库系统存在的形式主要有单机模式和集群模式（为了保证数据库的可用性或实现备份）如：失败转移集群（MSCS）、镜像（Mirror）、第三方的高可用（HA）集群或备份软件等。伴随着企业的发展，企业的数据量和访问量也会迅猛增加，此时数据库就会面临很大的负载和压力，意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗？SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，属于高可用集群，Microsoft称之为失败转移集群。 MSCS 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server 数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份； 因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性，和MSCS相比，用户实现数据库的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。共设了三个服务器，第一是工作数据库（Principal Datebase），第二个是镜像数据库（Mirror），第三个是监视服务器（Witness Server，在可用性方面有了一些保证，但仍然是单服务器工作；在扩展和性能的提升上依旧没有什么帮助。

Redis备份容灾及高可用方案

Redis 备份、容灾及高可用方案

一，Redis简单介绍 Redis是一个高性能的key-value非关系型数据库，由于其具有高性能的特性，支持高可用、持久化、多种数据结构、集群等，使其脱颖而出，成为常用的非关系型数据库。 此外，Redis的使用场景也比较多。 我们常通过Reids的队列功能做购买限制。比如到节假日或者推广期间，进行一些活动，对用户购买行为进行限制，限制今天只能购买几次商品或者一段时间内只能购买一次。也比较适合适用。 4.排名 Redis在内存中对数字进行递增或递减的操作实现得非常好。所以我们在很多排名的场景中会应用Redis来进行，比如小说网站对小说进行排名，根据排名，将排名靠前的小说推荐给用户。

5.发布/订阅 Redis提供发布和订阅功能，发布和订阅的场景很多，比如我们可以基于发布和订阅的脚本触发器，实现用Redis的发布和订阅功能建立起来的聊天系统。 此外还有很多其它场景，Redis都表现的不错。 二，Redis使用中单点故障问题 正是由于Redis具备多种优良特新，且应用场景非常丰富，以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富，但部分公司在实践Redis应用的时候还是相对保守使用单节点部署，那为日后的维护带来了安全风险。 在2015年的时候，曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。 当时我们通过Redis服务器做用户购买优惠商品的行为控制，但后来由于未知原因Redis节点的服务器宕机了，导致我们无法对用户购买行为进行控制，造成了用户能够在一段时间内多次购买优惠商品的行为。 这种宕机事故可以说已经对公司造成了不可挽回的损失了，安全风险问题非常严重，作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。

几种负载均衡策略比较~

PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比

tair与redis分析

1. Tair总述 1.1 系统架构 一个Tair集群主要包括3个必选模块：configserver、dataserver和client，一个可选模块：invalidserver。通常情况下，一个集群中包含2台configserver及多台dataServer。两台configserver互为主备并通过维护和dataserver之间的心跳获知集群中存活可用的dataserver，构建数据在集群中的分布信息（对照表）。dataserver负责数据的存储，并按照configserver的指示完成数据的复制和迁移工作。client在启动的时候，从configserver获取数据分布信息，根据数据分布信息和相应的dataserver交互完成用户的请求。invalidserver主要负责对等集群的删除和隐藏操作，保证对等集群的数据一致。 从架构上看，configserver的角色类似于传统应用系统的中心节点，整个集群服务依赖于configserver的正常工作。但实际上相对来说，tair的configserver是非常轻量级的，当正在工作的服务器宕机的时候另外一台会在秒级别时间内自动接管。而且，如果出现两台服务器同时宕机的最恶劣情况，只要应用服务器没有新的变化， tair依然服务正常。而有了configserver这个中心节点，带来的好处就是应用在使用的时候只需要配置configserver的地址（现在可以直接配置Diamond key），而不需要知道内部节点的情况。 1.1.1 ConfigServer的功能 1) 通过维护和dataserver心跳来获知集群中存活节点的信息 2) 根据存活节点的信息来构建数据在集群中的分布表。 3) 提供数据分布表的查询服务。 4) 调度dataserver之间的数据迁移、复制。 1.1.2 DataServer的功能

nginx负载均衡高可用

n g i n x负载均衡高可用 This model paper was revised by the Standardization Office on December 10, 2020

1nginx负载均衡高可用 1.1什么是负载均衡高可用 nginx作为负载均衡器，所有请求都到了nginx，可见nginx处于非常重点的位置，如果nginx服务器宕机后端web服务将无法提供服务，影响严重。 为了屏蔽负载均衡服务器的宕机，需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。 1.2keepalived+nginx实现主备 1.2.1什么是keepalived keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。 1.2.2keepalived工作原理 keepalived是以VRRP协议为实现基础的，VRRP全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议。

redis2.8生产环境下真实配置过程

#### YUM安装源请自行查找,需要注意,两台主备服务机器配置大体相同,但是个别参数不一样,切记!!! ###安装编译库 yum install cpp binutils glibc glibc-common glibc-devel gcc make tcl-devel.x86_64 ###编译安装REDIS wget http://download.redis.io/releases/redis-2.8.23.tar.gz cd /soft tar zxvf redis-2.8.23.tar.gz mv redis-2.8.23 /usr/local/src cd /usr/local/src/redis-2.8.23 ##修改MAKE文件,修改对应的安装目录PREFIX?=/usr/local/redis vi /usr/local/src/redis-2.8.23/src/Makefile make make install ###配置REDIS mkdir -p /usr/local/redis/{bin,conf,logs,data} ##配置REDIS系统环境变量 vi /etc/profile.d/redis.sh ## redis PATH export PATH=/usr/local/redis/bin:$PATH source /etc/profile.d/redis.sh ##配置系统参数 vi /etc/sysctl.conf net.core.somaxconn = 1024 vm.overcommit_memory = 1 sysctl -p ##编辑REDIS参数及停止启动脚本 vi /usr/local/redis/redis-start.sh vi /usr/local/redis/redis-stop.sh vi /usr/local/redis/conf/redis.conf cd /usr/local/redis chmod 700 redis_check.sh redis-start.sh redis-stop.sh

虚拟化群集中的网络负载平衡和高可用性

什么是群集？简单的说，群集（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是群集的节点（node）。一个理想的群集是，用户从来不会意识到群集系统底层的节点，在用户看来，群集是一个完整系统，而非多个计算机系统。并且群集系统的管理员可以随意增加和删改群集系统的节点。 服务器群集 如上图，由2台服务器（Server1，Server2）组成的群集方式，其中每台服务器的地位是平等的。都可以为客户端提供服务并且不用其它服务器的辅助。上图中Server3是服务器群集虚拟出来的主机，客户端所能看到的群集只是一台Server3主机。群集中的主机将均衡处理客户端发来的应用请求，以此来实现负载均衡（NLB）；如果某一台服务器出现宕机，客户端发来的应用请求将被分配给另外一台服务器，通过这种方式来保障业务应用的高可用性（HA）。

虽然，根据群集系统的不同特征可以有多种分类方法，但是一般把群集系统分为两类：高可用(High Availability)群集，简称HA群集；性能计算(High Perfermance Computing)群集，简称HPC群集，也称为科学计算群集。在本文中我们只介绍前者。 HA群集，不难理解，这类群集致力于提供高度可靠的服务。就是利用群集系统的容错性对外提供7*24小时不间断的服务，如高可用的文件服务器、数据库服务等关键应用。HA群集和负载均衡（NLB）群集之间的界限有时非常模糊，负载均衡群集使任务可以在群集中尽可能平均地分摊到不同的计算机中进行处理，充分利用群集的处理能力，提高对任务的处理效率。在实际应用中，这几种群集类型可能会混合使用，以提供更加高效稳定的服务。如在一个使用的网络流量负载均衡群集中，就会包含高可用的网络文件系统、高可用的网络服务。 服务器群集技术常见的有Linux中的LVS和Windows中的NLB。NLB即Network Load Balancing，也就是网络负载平衡。Microsoft在所有的Windows Server操作系统上提供这一负载平衡技术。NLB的用途很广，将多台应用服务器通过NLB的方式捆绑在一起，这样以来NLB可以根据实际的访问流量均分开来减少各服务器的网络占用及资源占用，所以NLB 被广泛用于终端服务、Web服务、FTP服务等，用来解决大量并发访问服务问题，帮助用户使用较少的投资获得接近于大型主机的性能。同时，由于实际处理应用请求的服务器变为多台，高可用性也得到了有效的保证。 大致概括一下群集技术的主要优点，主要包括以下4个方面： (1)高可扩展性：群集系统的管理员可以随意增加和删改群集系统的节点。

集群情况下Session共享解决方案 redis

集群情况下Session共享解决方案redis 1、集群情况下session会产生什么原因? 由于session存放在服务器端，集群下用户可能访问不同的服务器，则可能session无法共享。 2、Session共享解决方案 1）NGINX做的负载均衡可以绑定ip_hash，从而使同一个IP访问同一个服务器------------------该方案使得集群失去意义。 2）利用数据库同步session----------------------太过复杂 3）利用cookie同步session（保存一个session到本地，再次访问将其带到服务器端）----------------------安全性差、http请求都需要带参数增加了带宽消耗 4）使用session集群，存放到redis中（spring-session） 3、spring-session项目，解决session共享问题 org.springframework.boot spring-boot-starter-redis org.springframework.session spring-session-data-redis 创建SessionConfig

import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.data.redis.connection.jedis.JedisConnectionFactory; import org.springframework.session.data.redis.config.annotation.web.http.EnableRedisHttpSession; //这个类用配置redis服务器的连接 //maxInactiveIntervalInSeconds为SpringSession的过期时间（单位：秒） @EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800) Public class SessionConfig { //冒号后的值为没有配置文件时，制动装载的默认值 @Value("${redis.hostname:localhost}") String HostName; @Value("${redis.port:6379}") int Port; @Bean Public JedisConnectionFactory connectionFactory() { JedisConnectionFactory connection = new JedisConnectionFactory(); connection.setPort(Port); connection.setHostName(HostName); return connection; } } 初始化Session: //初始化Session配置

可扩展、高可用与负载均衡网站架构设计策划方案

可扩展、高可用、负载均衡网站架构设计方案 2009-06-08 13:22 差不多需求: 1、高可用性：将停止服务时刻降低到最低甚至是不间断服务 2、可扩展性：随着访问的增加，系统具备良好的伸缩能力 3、可视性：系统、服务的状态处于一个实时的监控之下 4、高性能高可靠性：通过优化的体系结构及合理的备份策略 5、安全性：结构上的安全及主机的安全策略 差不多思路 1、关于访问频繁，用户量大的对象（bbs,blog）采纳某种合理的方式负载到多个 服务器上。把数据库独立出来，预备2套mysql数据库，以实现主从复制，即减轻负载，又提高了可靠性。更近一步，使用mysql proxy技术，实现主从服务器的读写分离，大大提高那个系统的性能和负载能力。 2、数据库与外部网络隔离，只同意web服务器（bbs,blog等）通过私有地址方 式访问。如此就提高了数据库的安全性，同时也节约了宝贵的带宽。 3、部署监控系统，通过监控主机存活、服务、主机资源，实时把系统的健康状 态置于可视状态，对系统的运营状态心中有数。 4、备份是想都不用想的情况，使用单独的服务器集中备份，是一个比较不错的 主意。 拓扑结构

业务逻辑

技术实现 1、负载均衡。2台同样配置的linux服务器，内核支持lvs,配置keepalived工具，即可实现负载转发。一旦其后的真实服务器出现故障，keepalived会自动把故障机器从转发队列删除掉，等到故障修复，它又会自动把真实服务器的地址加入转发列表。由于lvs支持会话保持，因此关于bbs 如此的应用，一点也不用担心其登录丢失。 2、mysql主从复制。即保证数据的安全，又提高了访问性能。我们在前端的每个web服务器上加入mysql proxy那个工具，即可期待实现读写的自动分离，让写的操作发生在主数据库，让查询这类读操作发生在从数据库。 3、nagios是一个开源的，受广泛欢迎的监控平台。它可对主机的存活、系统资源（磁盘空间、负载等）、网络服务进行实时监控。一旦探测到故障，将自动发送邮件（短信）通知故障。 4、备份。包括web数据和数据库服务器的备份。关于web服务而言，GNU tar 即可实现备份的一切愿望。简单的设置一下crontab 就能够让系统在我们做梦的时刻老老实实的帮我们备份了。然而，由于空间的限制，不可能一直备份下去，因此要做一个合适的策略，以不断的用新的备份去替换陈旧的备份数据；多少天合适？看磁盘容量吧。关于数据库，先mysqldump一下，再tar.完成这些工作后把备份文件传输到备份服务器集中。一个比较省事的方法是把备份服务器以NFS 方式挂接到web服务器及数据库服务器。

keepalived+redis主备

keepalived+redis主备容灾部署 XXX 2016/8/8

目录 1 方案图 (3) 2 安装redis (3) 2.1 redis master安装 (3) 2.2 redis slave安装 (4) 3 安装keepalived (5) 4 配置keepalived (8) 4.1 redis-master 配置 (8) 4.2 redis-slave 配置 (11)

1 方案图 Redis-master 192.168.11.149 Redis-slave 192.168.11.150 图1方案部署图 现网环境中有两个数据库主机，master，和slave。以及一个vip Master：192.168.11.149 Slave：192.168.11.150 Vip：192.168.200.200 节点A Redis-Master主节点，节点B Redis-Slave 备用节点，虚拟IP是对外提供访问的IP。虚拟IP在某个时刻只能属于某一个节点，另一个节点作为备用节点存在。当主节点不可用时，备用节点接管虚拟IP，提供正常服务。 2安装redis 2.1redis master安装 下载redis-3.0.3.tar.gz 创建redis账户 #useradd -d /home/cin_redis –s /bin/bash –m cin_redis # passwd cin_redis 上传redis-3.0.3.tar.gz

解压 # tar –xzvf redis-3.0.3.tar.gz #cd rediis-3.0.3/src #mak MALLOC=libc #make PREFIX=$HOME install 在redis的解压目录下有一个redis.conf 文件，编辑redis.conf文件 daemonize yes后台模式运行 port 15093 端口 logfile “/home/cin_redis/redis-15093.log” pidfile “/home/cin_redis/redis-15093.pid” 可以把该配置文件拷贝到bin目录下修改；启动redis # redis-server redis.conf 2.2redis slave安装 redis slave机器上同样安装redis数据库，安装步骤同2.1安装，修改redis.conf 文件 daemonize yes后台模式运行 port 15093 端口 logfile “/home/cin_redis/redis-15093.log” pidfile “/home/cin_redis/redis-15093.pid” slaveof 192.168.11.149 15093建立与192.168.11.149的主从关系 可以把该配置文件拷贝到bin目录下修改；启动redis #redis-server redis.conf 用redis-cli客户端连接redis-master数据库，查看replication 图2-1redis-master主从关系信息图 用redis-cli客户端连接redis-slave数据库，查看replication

LVS搭建高可用性Web负载均衡服务器

LVS搭建高可用性Web负载均衡服务器 一.系统需求 实现Linux下的Web服务器负载均衡，LVS以主备方式工作，并且实现LVS机器同时加入Web服务器群。 二．软硬件需求 操作系统：Red Hat Enterprise Linux Server release 5(关闭selinux及iptables) 相关软件：heartbeat-2.1.4 、net-snmp 、lm_sensors 、net-snmp、ipvsadm、perl模块 网络要求：所有服务器位于同一VLan,机器无特殊要求。 三．软件安装 以本次安装为例，先后安装下列rpm包以解决依赖关系. #rpm –ivh libnet-1.1.2.1-2.1.i386.rpm #rpm –ivh ipvsadm-1.24-8.1.i386.rpm #rpm –ivh lm_sensors-2.10.0-3.1.i386.rpm #rpm –ivh net-snmp-libs-5.3.1-14.el5.i386.rpm #rpm –ivh net-snmp-5.3.1-14.el5.i386.rpm #rpm –ivh perl-Compress-Zlib-1.42-1.fc6.i386.rpm #rpm –ivh perl-HTML-Parser-3.55-1.fc6.i386.rpm #rpm –ivh perl-HTML-Tagset-3.10-2.1.1.noarch.rpm #rpm –ivh perl-Net-SSLeay-1.30-4.fc6.i386.rpm #rpm –ivh perl-TimeDate-1.16-5.el5.noarch.rpm #rpm –ivh perl-MailTools-2.02-1.el5.rf.noarch.rpm #rpm –ivh perl-URI-1.35-3.noarch.rpm #rpm –ivh perl-libwww-perl-5.805-1.1.1.noarch.rpm 以上软件包主要用来实现ISO/RM 2/3层数据转换及7层应用检测。 #rpm –ivh heartbeat-stonith-2.1.4-4.1.i386.rpm #rpm –ivh heartbeat-pils-2.1.4-4.1.i386.rpm #rpm –ivh heartbeat-ldirectord-2.1.4-4.1.i386.rpm #rpm –ivh heartbeat-2.1.4-4.1.i386.rpm #rpm –ivh heartbeat-devel-2.1.4-4.1.i386.rpm

软件负载均衡优缺点总结

（总结）Nginx/LVS/HAProxy负载均衡软件的优缺点详解 PS：Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，参考了一些资料，结合自己的一些使用经验，总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案：Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 Nginx的优点是： 1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会； 3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。 3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器

相关主题
相关文档
最新文档