标签：
20150625
Redis是一个开源，先进的key-value存储，用于构建高性能，可扩展的Web应用程序的完美解决方案。
Redis从它的许多竞争继承来的三个主要特点：
Redis数据库完全在内存中，使用磁盘仅用于持久性。
相比许多键值数据存储，Redis拥有一套较为丰富的数据类型。
Redis可以将数据复制到任意数量的从服务器。
异常快速：Redis的速度非常快，每秒能执行约11万集合，每秒约81000+条记录。
支持丰富的数据类型：Redis支持最大多数开发人员已经知道像列表，集合，有序集合，散列数据类型。这使得它非常容易解决各种各样的问题，因为我们知道哪些问题是可以处理通过它的数据类型更好。
操作都是原子性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。
多功能实用工具：Redis是一个多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数等。
在redis官网下载最新的源码包
http://download.redis.io/releases/redis-2.8.3.tar.gz
# tar xzf redis-3.0.0.tar.gz
# mv redis-3.0.0 /usr/local/redis
# cd /usr/local/redis
# make && make install
# echo $?
# redis-server
第一次启动时可能会有提示的warning信息；可以忽略，但最好是按照提示的处理办法修改。
# redis-cli
# redis> set iom dtsoft
OK
# redis> get iom
“dtsoft”
除了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。
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。
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，使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
lpush，rpush，lpop，rpop，lrange，BLPOP(阻塞版)等。
Redis list的应用场景非常多，也是Redis最重要的数据结构之一。我们可以轻松地实现最新消息排行等功能。
Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。
Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
sadd，spop，sdiff，sinter，sunion，smembers，sismember 等。
Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。
比如在微博应用中，每个人的好友存在一个集合（set）中，这样求两个人的共同好友的操作，可能就只需要用求交集命令即可。
Redis还为集合提供了求交集、并集、差集等操作。
set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是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文件
从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。
在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前，如果从服务器与主服务器因某些原因断开连接的话，都会进行一次主从之间的全量的数据同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。
主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和自己的ID匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。
增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。
假设有两台服务器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两节点回到初始状态
红字为手工加的备注，原文件里没有。
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）后执行的脚本
}
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）后执行的脚本
}
我们是根据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 –从机时也可以执行写命令
#!/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
#!/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
#!/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
#!/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
客户机运行redis客户端：
# redis-cli –h 192.168.10.251 –p 6379
redis:6379> auth system –第一次需要输入密码
OK
客户机上做些写（增，删，改）操作，看A-redis和B-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主机
# 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
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程序自动执行。
标签：
原文地址：http://www.cnblogs.com/grimm/p/5771053.html
