Keepalived+Redis高可用部署（第二版）

更新

20150625

• 脚本由5个减少为4个，sh脚本指令做了精简。
• 修改了另外3个脚本，在日志里增加了日期显示。
• 新增redis数据类型，持久化，主从同步简介。
• 新增hiredis简介。
• 新增c语言客户端测试。

Redis简介及安装

 

Redis是一个开源，先进的key-value存储，用于构建高性能，可扩展的Web应用程序的完美解决方案。

Redis从它的许多竞争继承来的三个主要特点：

Redis数据库完全在内存中，使用磁盘仅用于持久性。

相比许多键值数据存储，Redis拥有一套较为丰富的数据类型。

Redis可以将数据复制到任意数量的从服务器。

REDIS优势

异常快速：Redis的速度非常快，每秒能执行约11万集合，每秒约81000+条记录。

支持丰富的数据类型：Redis支持最大多数开发人员已经知道像列表，集合，有序集合，散列数据类型。这使得它非常容易解决各种各样的问题，因为我们知道哪些问题是可以处理通过它的数据类型更好。

操作都是原子性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。

多功能实用工具：Redis是一个多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数等。

 

REDIS安装

在redis官网下载最新的源码包

http://download.redis.io/releases/redis-2.8.3.tar.gz

1. 解压

# tar xzf redis-3.0.0.tar.gz

2. 拷贝目录

# mv redis-3.0.0 /usr/local/redis

3. 进入目录

# cd /usr/local/redis

4. 编译

# make && make install

5. 查看命令运行结果，如果是0则是成功

# echo $?

 

REDIS启动

# redis-server

第一次启动时可能会有提示的warning信息；可以忽略，但最好是按照提示的处理办法修改。

 

REDIS客户端启动

# redis-cli

验证客户端操作

# redis> set iom dtsoft

OK

# redis> get iom

“dtsoft”

Redis数据类型

String

常用命令：

除了get、set、incr、decr、mget等操作外，Redis还提供了下面一些操作：

获取字符串长度

往字符串append内容

设置和获取字符串的某一段内容

设置及获取字符串的某一位（bit）

批量设置一系列字符串的内容

 

应用场景：

String是最常用的一种数据类型，普通的key/value存储都可以归为此类，value其实不仅是String，

也可以是数字：比如想知道什么时候封锁一个IP地址(访问超过几次)。INCRBY命令让这些变得很容易，通过原子递增保持计数。

实现方式：

incr，decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

1、String常用命令：除了get、set、incr、decr mget等操作外，Redis还提供了下面一些操作：获取字符串长度往字符串append内容设置和获取字符串的某一段内容设置及获取字符串的某一位（bit）批量设置一系列字符串的内容 应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类，value其实不仅是String，也可以是数字：比如想知道什么时候封锁一个IP地址(访问超过几次)。INCRBY命令让这些变得很容易，通过原子递增保持计数。 实现方式：m,decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。

 

Hash

常用命令：

hget，hset，hgetall 等。

应用场景：

我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：

用户ID，为查找的key，存储的value用户对象包含姓名name，年龄age，生日birthday等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：第一种方式将用户ID作为查找key，把其他信息封装成一个对象以序列化的方式存储，如：set u001 “李三，18，20010101”

这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护。

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，如：mset user:001:name 李三 user:001:age 18 user:001:birthday

“20010101”

虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费严重。

Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如：hmset user:001 name “李三” age 18 birthday “20010101”。也就是说，Key仍然是用户ID，value是一个Map，这个Map的key是成员的属性名，value是属性值。

这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field)， 也就是通过key(用户ID) + field(属性标签)，比如读取上面用户的年龄就可以用： hget user:001 name来取得对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。

 

这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据，但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。

实现方式：

上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap，此时encoding为ht。

常用命令：hget,hset,hgetall 等。应用场景：我们简单举个实例来描述下Hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：           用户ID，为查找的key，           存储的value用户对象包含姓名name，年龄age，生日birthday等信息，   如果用普通的key/value结构来存储，主要有以下2种存储方式：       第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储，           如：set u001 “李三,18,20010101”           这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入CAS等复杂问题。       第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户ID+对应属性的名称作为唯一标识来取得对应属性的值，           如：mset user:001:name “李三 “user:001:age18 user:001:birthday “20010101”           虽然省去了序列化开销和并发问题，但是用户ID为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。    那么Redis提供的Hash很好的解决了这个问题，Redis的Hash实际是内部存储的Value为一个HashMap，    并提供了直接存取这个Map成员的接口，        如：hmset user:001 name “李三” age 18 birthday “20010101”              也就是说，Key仍然是用户ID,value是一个Map，这个Map的key是成员的属性名，value是属性值，            这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field),也就是通过             key(用户ID) + field(属性标签)操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。           这里同时需要注意，Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多，那么涉及到遍历整个内部Map的操作，由于Redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。  实现方式：    上面已经说到Redis Hash对应Value内部实际就是一个HashMap，实际这里会有2种不同实现，这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

 

Sort Set

常用命令：

zadd，zrange，zrem，zcard等

使用场景：

以某个条件为权重排序。

Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而

Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序

sort set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。

比如:全班同学成绩的SortedSets，value可以是同学的学号，而score就可以是其考试得分，这样数据插入集合的，就已经进行了天然的排序。

另外还可以用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

实现方式：

Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

 

List

常用命令：

lpush，rpush，lpop，rpop，lrange，BLPOP(阻塞版)等。

应用场景：

Redis list的应用场景非常多，也是Redis最重要的数据结构之一。我们可以轻松地实现最新消息排行等功能。

Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。

实现方式：

Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

 

Set

常用命令：

sadd，spop，sdiff，sinter，sunion，smembers，sismember 等。

应用场景：

Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

比如在微博应用中，每个人的好友存在一个集合（set）中，这样求两个人的共同好友的操作，可能就只需要用求交集命令即可。

Redis还为集合提供了求交集、并集、差集等操作。

实现方式：

set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

Redis持久化

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB

RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。

AOF

AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性。

AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。

AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异，确认问题点
4.重启redis，加载修复后的AOF文件

 

 

Redis主从同步

从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。

在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前，如果从服务器与主服务器因某些原因断开连接的话，都会进行一次主从之间的全量的数据同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。

主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和自己的ID匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。

增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。

Redis高可用分析

场景描述

假设有两台服务器A，B，A为主节点，B为从节点，每台上都装有keepalived和redis，并且已为keepalived分配一个VIP，下面分两种情况讨论：

 

B-redis挂掉

VIP仍为A服务器占用，用户读写不受任何影响，问题修复后，在B机以slave配置文件启动B-redis，启动B-keepalived， A、B两节点回到初始状态。

 

A-redis挂掉

A-keepalived检测到A-redis挂掉后自动丢失VIP，VIP被B服务器占用，B-redis设置为主节点；问题修复后，在A机以slave配置文件启动A-redis并自动同步B-redis数据，同步完成后开启A-keepalived， VIP重回A 服务器，A-redis设置成主节点， B-redis设置为A-redis的从节点，A、B两节点回到初始状态

 

切换要点

1. A，B上的keepalived要能在本服务器上的redis挂掉后即可将VIP转给另一台机器；
2. 不论A-redis还是B-redis，都是以slave配置文件重启（第一次安装，或两个服务都宕掉重启等特殊情况例外）；
3. A-reids必须在同步完成后才能开启keepalived；
4. A-redis必须在本服务器获得VIP后，设置为主节点；
5. 0描述的第二种情况，一定要在A-redis变成主节点后，B-redis才能设置成从节点，要控制好这个顺序。

几个注意的问题

• 由于redis本身主从同步是异步方式，因此如果主机宕机，从机有可能会损失一些数据。
• 如果非正常关闭keepalived，可能会出现VIP不能正常释放。
• redis挂掉后不关keepalived VIP也能自动转移，但redis重新启动时一定要先关keepalived，否则会造成VIP在两台机子同时出现的情况。
• redis节点不能开启从节点只读模式，也就是slave-read-only要设置为 no。因为keepalived或得VIP后才回执行将redis变为主节点的脚本，在这期间redis是以从节点身份接收客户端请求的。
• 如果AB服务器keepalived都挂掉，VIP有可能长久固定在某个上面。
• keepalived的配置文件里的脚本要注意执行权限。
• A，B服务器各脚本里的变量要注意区别，尤其是IP地址和密码。

 

keepalived配置

    A-keepalived配置

红字为手工加的备注，原文件里没有。

vi /etc/keepalived/keepalived.cnf文件

 

global_defs {

router_id LVS_MASTER

}

 

vrrp_script monitor_redis {

script “/etc/keepalived/script/redis_monitor.sh” –检查redis服务状态脚本；

interval 1                        –检查频率，单位为秒

}

 

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

 

track_script {

monitor_redis      –检查redis服务状态脚本；对应上面的vrrp_script

}

 

virtual_ipaddress {

192.168.10.251/24

#virtual server –VIP配置

}

notify_backup /etc/keepalived/script/redis_backup.sh –keepalived变为从节点（丢失VIP）后执行的脚本

notify_master /etc/keepalived/script/redis_master.sh — keepalived变为主节点（获得VIP）后执行的脚本

}

    B-keepalived配置

vi /etc/keepalived/keepalived.cnf文件

 

global_defs {

router_id LVS_BACKUP

}

 

vrrp_script monitor_redis {

script “/etc/keepalived/script/redis_monitor.sh” –检查redis服务状态脚本；

interval 3

}

 

vrrp_instance VI_1 {

state BACKUP

interface eth0

virtual_router_id 51

priority 99

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

 

track_script {

monitor_redis      –检查redis服务状态脚本；对应上面的vrrp_script

}

 

virtual_ipaddress {

192.168.10.251/24     #virtual server

}

notify_backup /etc/keepalived/script/redis_backup.sh –keepalived变为从节点（丢失VIP）后执行的脚本

notify_master /etc/keepalived/script/redis_master.sh — keepalived变为主节点（获得VIP）后执行的脚本

}

 

Redis配置

我们是根据keepalived自动切换VIP的原理来实现redis主从切换，每次切换，主从角色都会调换。

    编辑主节点配置文件

# vim redis.conf

daemonize yes                    –进程后台启动

logfile /usr/local/redis/redis.log       –日志文件

syslog-enabled no                –日志不写进系统日志

dir /usr/local/redis/data      –数据文件存放

requirepass system                   –认证密码

slave-server-stale-data no               –同步未完成从机不能接收除slaveof和info之外的命令，相当重要

slave-read-only  no –从机时也可以执行写命令

 

    编辑从节点配置文件

# vim redis_slave.conf

daemonize yes

logfile /usr/local/redis/redis.log

syslog-enabled no

dir /usr/local/redis/data

 

slaveof 192.168.10.3 6379           –主服务器的IP（两台机器不同）地址和端口

masterauth system                       –主服务器上的认证密码

slave-server-stale-data no               –同步未完成从机不能接收除slaveof和info之外的命令，相当重要

slave-read-only  no –从机时也可以执行写命令

 

编写脚本

    redis_start.sh(A机)

#!/bin/bash

export CONFIGPATH=/usr/local/redis/redis_slave.conf

export REDISPATH=/usr/local/redis/src

export REDISPASS=system

export REDISIOM=123                         –IOMkey值对应的value

export VIP=192.168.10.251                      –虚拟IP

export SLAVEIP=192.168.10.4                   –如果是备用机角色，需要连接的master机IP

 

echo “stop keepalived”

service keepalived stop                         –一定要关闭keepalived服务，否则可能造成主备服务器共有vip。

echo “kill redis-server”

ps -ef|grep redis-server|awk ‘{print $2}’|xargs kill -9

#wait 5s，sure the slave keepalived get vip

#sleep 5

for i in $(seq 1 5)

do

echo $i

sleep 1

done

 

 

echo “start redis-server with $CONFIGPATH”

nohup $REDISPATH/redis-server $CONFIGPATH >/dev/null 2>&1 &

 

sleep 1

echo “sh redis_monitor.sh”

REDISRESULT=`sh redis_monitor.sh`

echo “REDISRESULT IS $REDISRESULT”

until [  “$REDISRESULT” -eq “$REDISIOM”  ]

do

REDISRESULT=`sh redis_monitor.sh`

echo “REDISRESULT IS $REDISRESULT”

sleep 2

done

 

echo “start keepalived”

service keepalived start

 

exit 0

 

 

redis_monitor.sh

#!/bin/bash

LOGDATE=`date “+%m-%d %H:%M:%S”`

export LOGDATE

REDISIOM=123                             –IOM key值对应的vlaue值

export REDISIOM

REDISPASS=system

export REDISPASS

LOGFILE=/etc/keepalived/log/alive_state.log

export LOGFILE

ALIVE=$(/usr/local/redis/src/redis-cli -a $REDISPASS get iom)

export ALIVE

echo “$LOGDATE ALIVE=$ALIVE” >>$LOGFILE

if [ “$ALIVE” = “$REDISIOM” ]; then

echo $ALIVE

exit 0

else

echo “$LOGDATE redis-server no running”>>$LOGFILE

exit 1

fi

 

redis_master.sh

#!/bin/bash

LOGDATE=`date “+%m-%d %H:%M:%S”`

export LOGDATE

REDISPATH=/usr/local/redis/src

export REDISPATH

REDISPASS=system

export REDISPASS

LOGFILE=”/etc/keepalived/log/alive_state.log”

export LOGFILE

echo “$LOGDATE set master ” >> $LOGFILE

echo “run slaveof no one cmd …”

$REDISPATH/redis-cli -a $REDISPASS slaveof no one

 

 

redis_backup.sh

#!/bin/bash

LOGDATE=`date “+%m-%d %H:%M:%S”`

export LOGDATE

REDISPATH=/usr/local/redis/src

export REDISPATH

REDISPASS=system                            –master机设置的连接密码

export REDISPASS

REDISMASTER=”192.168.10.4 6379″             –master机地址和端口，主备机不同

export REDISMASTER

LOGFILE=”/etc/keepalived/log/alive_state.log”

export LOGFILE

sleep 10                                       –等候10秒再更改为slaveof角色，如果要更保险，可以设置为如果没有slave连接，才能执行下面的命令。

echo “$LOGDATE set back up ” >> $LOGFILE

echo “$LOGDATE MASTER:$REDISMASTER”>>$LOGFILE

echo “run slaveof cmd …”

$REDISPATH/redis-cli -a $REDISPASS slaveof $REDISMASTER

 

系统测试

测试环境

VIP：192.168.10.251

A机器IP：192.168.10.2

B机器IP：192.168.10.4

客户机IP：192.168.10.3

 

客户机测试脚本

 

测试过程

A机器启动redis和keepalived

# redis-server redis.conf

# service keepalived start

 

B机器启动redis和keepalived

# redis-server redis_slave.conf

# service keepalived start

 

测试客户机与A，B集群连接

客户机运行redis客户端：

# redis-cli –h 192.168.10.251 –p 6379

redis:6379> auth system –第一次需要输入密码

OK

客户机上做些写（增，删，改）操作，看A-redis和B-redis是否数据同步。

 

测试A-redis（主节点）挂掉后客户机业务

关掉A-redis，查看A机是否还占有VIP

# ps –ef|grep redis|awk ‘{print $2}’|xargs kill -9

# ip a

B机器是否获得VIP

# ip a

B-redis是否变为主机状态

redis> info

客户机上做些写（增，删，改）操作，看B-redis是否数据同步。

 

测试A-redis重启后客户机业务

用命令脚本启动A-redis主机

# sh redis_start.sh

查看A-redis是否将B-redis数据同步完全，分别在A，B redis运行

redis> keys * 看数量是否相等

查看A机器是否或得VIP

# ip a

查看A-redis是否变为主节点（keepalived获得VIP会执行命令，将A-redis变为主节点），登陆A-redis，运行命令

redis> info

查看B-redis是否变为从节点（keepalived丢失VIP会执行命令，将B-redis变为从节点），登陆B-redis，运行命令

redis> info

客户机连接redis客户端，测试业务是否正常

# redis-cli –h 192.168.10.251 –p 6379

redis c语言客户端开发包hiRedis

hiRedis 是 Redis 官方指定的 C 语言客户端开发包，支持 Redis 完整的命令集、管线以及事件驱动编程。我们可以用hiredis编写个测试程序，来更好更全面的验证redis主备环境。

安装hiredis：下载好hiredis后，执行make && make install 完成编译安装。安装完成后会多出libhiredis.a静态库和libhiredis.so动态库。

下面这个程序test.c每秒执行一次key-string类型的数据插入，第一次执行的是set 1 1，第二次是set 2 2，依次类推。

# vi test.c

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <hiredis.h>

static const char *hostname;

static int port;

static unsigned int i;

redisContext *c;

redisReply *reply;

struct timeval timeout = { 1， 500000 };  // 1.5 seconds

int redis_conn()

{

 

c = redisConnectWithTimeout(hostname， port， timeout);

if (c == NULL || c->err)

{

if (c)

{

printf(“Connection error: %s\n”， c->errstr);

redisFree(c);

} else

{

printf(“Connection error: can’t allocate redis context\n”);

}

return 1;

}

return 0;

}

 

int main(int argc， char **argv)

{

hostname = (argc > 1) ? argv[1] : “127.0.0.1”;

port = (argc > 2) ? atoi(argv[2]) : 6379;

 

int conn_res=redis_conn();

if (conn_res==1) _exit(1);

reply = redisCommand(c， “flushall”);

reply = redisCommand(c， “set iom 123”);

for (i = 0; i < 90000; i++)

{

reply = redisCommand(c， “SET %d %d”， i， i);

if (reply == NULL)

{

printf(“rediscommand exec err…\n”);

int res = redis_conn();

while (res)

{

sleep(1);

printf(“redis server conn…\n”);

res=redis_conn();

}

 

reply = redisCommand(c， “SET %d %d”， i， i);

}

printf(“%d SET: %s\n”， i， reply->str);

sleep(1);

}

freeReplyObject(reply);

return 0;

}

编译：gcc –o test test.c –L. –I. –lhiredis    (-L和-I选项要根据本机具体情况选择)

执行./test 开始测试，测试方法和6.1.3一样，只是插入操作由test程序自动执行。