Redis介绍，安装使用及集群介绍
1.Redis概述
2.Redis安装、配置(主从复制)
3.Redis集群
4.Redis Java开发
>>>>>>>>>>>>>>>>>>>>>>>>>>>一.Redis 概述
1.本质：Redis全称Remote Dictionary Server，是类似于Memcache的Key-Value内存数据库;
2.特点：
(1)它是一个高性能Key-Value存储系统,具有极高的读写性能，每秒可以处理超过10万次读写操作，超过 100K+/秒的读写频率
注：Redis的读写性能在100,000 ops/s左右，时延一般为10～70微妙左右；而HBase的单机读写性能一般不会超过1,000ops/s，时延则在1～5毫秒之间
(2)和Memcached相比,它支持更丰富的数据结构，包括string(字符串)、list(链表)、set(集合)、zset(sorted set--有序集合)和hash（哈希类型）
(3)Redis提供了数据持久化机制，可以定期异步把数据flush到硬盘，在某些场景下，你完全可以把它当做非关系型数据库来使用；
(4)支持消息的发布/订阅，从而让你在构建高性能消息队列系统时多了另一种选择。
(5)同样作为内存型数据库，(1) 对物理内存存储要求很高 (2)处理的数据量要远小于HBase与MongoDB (3) 目标是做高效的分布式缓存。数据一般不实时落地。也不适合做存储和分析(4)当然和数据库的功能相差甚远3.应用场景：
(1) Redis很适合用来做缓存，做加强版的Memached
(2) 在一些“读写分离”的场景下作为“读库”来用，常用的比如，用来存放Hadoop或Spark的分析结果。
(3) 因为支持对list的丰富操作，可以通过使用List做FIFO双向列表，实现轻量级的高性能消息队列服务器
(4) 用它的Set做高性能的tag系统
>>>>>>>>>>>>>>>>>>>>>>>>>>>二.Redis安装、配置(主从复制)
Redis 单机
参考：吴水成老师的<<Redis的安装与使用.pdf>> 附件
实践：结合自身的实践
1.环境配置
(1)机器配置:主机名(edu-redis)
(2)IP:192.168.1.122
(3)系统: CentOS 6.6
(4)Redis版本 ： redis-3.0.6.tar.gz （考虑到 Redis3.0 在集群和性能提升方面的特性，rc 版为正式版的候选版，而且很快就出正式版）
(5)安装目录：/usr/local/redis
(6)用户： root
2.Redis安装
#配置主机名
hostname "edu-redis-01" #设置主机名为 edu-redis-01
vi /etc/sysconfig/network #编辑配置文件
HOSTNAME=edu-redis-01
vi /etc/hosts #编辑配置文件
127.0.0.1 edu-redis-01 localhost
:wq! #保存退出
#编译和安装所需的包
yum install gcc tcl
#下载安装redis-3.0.6
cd /usr/local/src
wget http://download.redis.io/releases/redis-3.0.6.tar.gz;
tar -zxvf redis-3.0.6.tar.gz;
mv redis-3.0.6 redis3.0
cd redis3.0
以下一系列操作：按照<<Redis的安装与使用.pdf>>即可
#一些文件介绍
(1)redis-benchmark 性能测试工具
(2)redis-check-aof 日志文件检测工(比如断电造成日志损坏,可以检测并修复)
(3)redis-check-dump 快照文件检测工具,效果类上
(4)redis-cli 客户端
(5)redis-server 服务端
3.Redis配置
vi /usr/servers/redis-2.8.19/redis.conf
1.基本设置
#端口设置，默认6379
port 6379
#日志文件，默认/dev/null
logfile ""
2.Redis内存 设置
内存大小对应关系
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#设置Redis占用100mb的大小
maxmemory 100mb
#如果内存满了就需要按照如相应算法进行删除过期的/最老的
#volatile-lru 根据LRU算法移除设置了过期的key
#allkeys-lru 根据LRU算法移除任何key(包含那些未设置过期时间的key)
#volatile-random/allkeys->random 使用随机算法而不是LRU进行删除
#volatile-ttl 根据Time-To-Live移除即将过期的key
#noeviction 永不过期，而是报错
maxmemory-policy volatile-lru
#Redis并不是真正的LRU/TTL，而是基于采样进行移除的，即如采样10个数据移除其中最老的/即将过期的
maxmemory-samples 10
Memcached是真正的LRU，此处要根据实际情况设置缓存策略
如缓存用户数据时可能带上了过期时间，此时采用volatile-lru即可；
假设我们的数据未设置过期时间，此时可以考虑使用allkeys-lru/allkeys->random；
假设我们的数据不允许从内存删除那就使用noeviction。
内存大小尽量在系统内存的60%~80%之间，因为如客户端、主从时复制时都需要缓存区的，这些也是耗费系统内存的。
Redis本身是单线程的，因此我们可以设置每个实例在6-8GB之间，通过启动更多的实例提高吞吐量。如128GB的我们可以开启8GB * 10个实例，充分利用多核CPU。
4.Redis主从 设置
>>结合学习：13-redis主从复制.wmv
实际项目时，为了提高吞吐量，我们使用主从策略
(1)主从备份：可以通过主从机制，在叶子节点开启持久化方式防止数据丢失，也可在主机宕机时切换
(2)读写分离：数据写到主Redis，读的时候从从Redis上读，这样可以通过挂载更多的从来提高吞吐量
(3)任务分离：分单备份和计算这些操作
Redis集群的几种形式
(1)一主多从 (2)多台承接主从，第二种的好处是，master宕机后可直接切到slave1
主从通信过程
# vi /usr/servers/redis-2.8.19/redis.conf
#在配置文件中挂载主从，不推荐这种方式，我们实际应用时Redis可能是会宕机的
slaveof masterIP masterPort
#从是否只读，默认yes
slave-read-only yes
#当从失去与主的连接或者复制正在进行时，从是响应客户端（可能返回过期的数据）还是返回“SYNC with master in progress”错误，默认yes响应客户端
slave-serve-stale-data yes
#从库按照默认10s的周期向主库发送PING测试连通性
repl-ping-slave-period 10
#设置复制超时时间（SYNC期间批量I/O传输、PING的超时时间），确保此值大于repl-ping-slave-period
#repl-timeout 60
#当从断开与主的连接时的复制缓存区，仅当第一个从断开时创建一个，缓存区越大从断开的时间可以持续越长
# repl-backlog-size 1mb
#当从与主断开持续多久时清空复制缓存区，此时从就需要全量复制了，如果设置为0将永不清空
# repl-backlog-ttl 3600
#slave客户端缓存区，如果缓存区超过256mb将直接断开与从的连接，如果持续60秒超过64mb也会断开与从的连接
client-output-buffer-limit slave 256mb 64mb 60
此处需要根据实际情况设置client-output-buffer-limit slave和 repl-backlog-size；比如如果网络环境不好，从与主经常断开，而每次设置的数据都特别大而且速度特别快（大量设置html片段）那么就需要加大repl-backlog-size。
>>>>>单机：主从示例（针对性的设置多台机器，IP不同）
cd /usr/servers/redis-2.8.19
cp redis.conf redis_6660.conf
cp redis.conf redis_6661.conf
vi redis_6660.conf
vi redis_6661.conf
将端口分别改为port 6660和port 6661，然后启动
nohup /usr/servers/redis-2.8.19/src/redis-server /usr/servers/redis-2.8.19/redis_6660.conf &
nohup /usr/servers/redis-2.8.19/src/redis-server /usr/servers/redis-2.8.19/redis_6661.conf &
查看是否启动
ps aux | grep redis
进入从客户端，挂主
/usr/servers/redis-2.8.19/src/redis-cli -p 6661
127.0.0.1:6661> slaveof 127.0.0.1 6660
OK
127.0.0.1:6661> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6660
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:57
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
进入主
/usr/servers/redis-2.8.19/src/redis-cli -p 6660
127.0.0.1:6660> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6661,state=online,offset=85,lag=1
master_repl_offset:85
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:84
127.0.0.1:6660> set i 1
OK
进入从
/usr/servers/redis-2.8.19/src/redis-cli -p 6661
127.0.0.1:6661> get i
"1"
此时可以看到主从挂载成功，可以进行主从复制了。使用slaveof no one断开主从。
5.Redis持久化
>>结合学习：redis入门到精通视频之11-rdb快照持久化.wmv/12-aof日志持久化.wmv
Redis虽然不适合做持久化存储，但是为了防止数据丢失有时需要进行持久化存储
做法：可以挂载一个从（叶子节点）只进行持久化存储工作，这样假设其他服务器挂了，我们可以通过这个节点进行数据恢复。
Redis持久化有RDB快照模式和AOF追加模式，根据自己需求进行选择。
4.1 RDB持久化
#格式save seconds changes 即N秒变更N次则保存，从如下默认配置可以看到丢失数据的周期很长，通过save “” 配置可以完全禁用此持久化
save 900 1
save 300 10
save 60 10000
#RDB是否进行压缩，压缩耗CPU但是可以减少存储大小
rdbcompression yes
#RDB保存的位置，默认当前位置
dir ./
#RDB保存的数据库名称
dbfilename dump.rdb
#不使用AOF模式，即RDB模式
appendonly no
可以通过set一个数据，然后很快的kill掉redis进程然后再启动会发现数据丢失了。
4.2 AOF持久化
AOF（append only file）即文件追加模式，即把每一个用户操作的命令保存下来，这样就会存在好多重复的命令导致恢复时间过长，那么可以通过相应的配置定期进行AOF重写来减少重复。
#开启AOF
appendonly yes
#AOF保存的位置，默认当前位置
dir ./
#AOF保存的数据库名称
appendfilename appendonly.aof
#持久化策略，默认每秒fsync一次，也可以选择always即每次操作都进行持久化，或者no表示不进行持久化而是借助操作系统的同步将缓存区数据写到磁盘
appendfsync everysec
#AOF重写策略（同时满足如下两个策略进行重写）
#当AOF文件大小占到初始文件大小的多少百分比时进行重写
auto-aof-rewrite-percentage 100
#触发重写的最小文件大小
auto-aof-rewrite-min-size 64mb
#为减少磁盘操作，暂缓重写阶段的磁盘同步
no-appendfsync-on-rewrite no
此处的appendfsync everysec 可以认为是RDB和AOF的一个折中方案。
#当bgsave出错时停止写（MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk.），遇到该错误可以暂时改为no，当写成功后再改回yes
stop-writes-on-bgsave-error yes
更多Redis持久化请参考http://redis.readthedocs.org/en/latest/topic/persistence.html。
在dump rdb过程中,aof如果停止同步,会不会丢失?
答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.
aof重写是指什么? (set a=1 set a=2 set a=3…最后a=100 à set a =100)
答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.以解决 aof日志过大的问题.
问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?
答: aof
问: 2种是否可以同时用?
答: 可以,而且推荐这么做
问: 恢复时rdb和aof哪个恢复的快
答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行
========需要补充进去==========
11-12.Redis持久化配置
Redis的持久化有2种方式
1. 快照: 将内存以
2. 日志
rdb的工作原理:
每隔N分钟或N次写操作后,从内存dump数据形成rdb文件,压缩放在备份目录
注:红色部分可通过参数来配置
Rdb快照的配置选项
Vi /etc/local/redis/...conf
save 900 1 // 900内,有1条写入,则产生快照
save 300 1000 // 如果300秒内有1000次写入,则产生快照
save 60 10000 // 如果60秒内有10000次写入,则产生快照
(这3个选项都屏蔽,则rdb禁用)
stop-writes-on-bgsave-error yes // 后台备份进程出错时,主进程停不停止写入?
rdbcompression yes // 导出的rdb文件是否压缩
Rdbchecksum yes // 导入rbd恢复时数据时,要不要检验rdb的完整性
dbfilename dump.rdb //导出来的rdb文件名
dir ./ //rdb的放置路径
Aof 的配置
工作原理：见ppt
appendonly no # 是否打开 aof日志功能
appendfsync always # 每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec # 折衷方案,每秒写1次
appendfsync no # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
no-appendfsync-on-rewrite yes: # 正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写
15.aof恢复与rdb服务器间迁移
5.Redis动态调整配置
获取maxmemory(10mb)
127.0.0.1:6660> config get maxmemory
1) "maxmemory"
2) "10485760"
设置新的maxmemory(20mb)
127.0.0.1:6660> config set maxmemory 20971520
OK
但是此时重启redis后该配置会丢失，可以执行如下命令重写配置文件
127.0.0.1:6660> config rewrite
OK
注意：此时所以配置包括主从配置都会重写。
6.设置密码
在配置文件设置password
操作如下：
# vi ../conf/6379.conf
搜索passwd,设置：requirepass 123456
[root@edu-redis-01 bin]# redis-cli
127.0.0.1:6379> get name
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> get name
"z"
127.0.0.1:6379>
对于从服务器也需要设置密码才能同步和查看到
masterauth 123456
7.redis 运维常用命令
7.1基本命令
#显示服务器时间 , 时间戳(秒), 微秒数
redis 127.0.0.1:6380> time
1) "1375270361"
2) "504511"
#当前数据库的key的数量
redis 127.0.0.1:6380> dbsize
(integer) 2
#选择数据库
redis 127.0.0.1:6380> select 2
OK
redis 127.0.0.1:6380[2]> dbsize
(integer) 0
redis 127.0.0.1:6380[2]>
#后台进程重写AOF
BGREWRITEAOF
# 后台保存rdb快照
BGSAVE
#保存rdb快照
SAVE
#上次保存时间
LASTSAVE
#把当前实例设为master的slave
Slaveof master-Host port
#清空所有库所有键
Flushall
#清空当前库所有键
Flushdb
#关闭服务器
Showdown [save/nosave]
注: 如果不小心运行了flushall, 立即 shutdown nosave ,关闭服务器然后 手工编辑aof文件, 去掉文件中的 “flushall ”相关行, 然后开启服务器,就可以导入回原来数据.
如果,flushall之后,系统恰好bgrewriteaof了,那么aof就清空了,数据丢失.
Slowlog 显示慢查询
注:多慢才叫慢: 由slowlog-log-slower-than 10000 ,来指定,(单位是微秒)
服务器储存多少条慢查询的记录?
答: 由 slowlog-max-len 128 ,来做限制
Info [Replication/CPU/Memory..]
查看redis服务器的信息
Config get 配置项
Config set 配置项 值 (特殊的选项,不允许用此命令设置,如slave-of, 需要用单独的slaveof命令来设置)
Redis运维时需要注意的参数
1: 内存
# Memory
used_memory:859192 数据结构的空间
used_memory_rss:7634944 实占空间
mem_fragmentation_ratio:8.89 前2者的比例,1.N为佳,如果此值过大,说明redis的内存的碎片化严重,可以导出再导入一次.
2: 主从复制
# Replication
role:slave
master_host:192.168.1.128
master_port:6379
master_link_status:up
3:持久化
# Persistence
rdb_changes_since_last_save:0
rdb_last_save_time:1375224063
4: fork耗时
#Status
latest_fork_usec:936 上次导出rdb快照,持久化花费微秒
注意: 如果某实例有10G内容,导出需要2分钟,
每分钟写入10000次,导致不断的rdb导出,磁盘始处于高IO状态.
5: 慢日志
config get/set slowlog-log-slower-than
CONFIG get/SET slowlog-max-len
slowlog get N 获取慢日志
运行时更改master-slave
修改一台slave(设为A)为new master
1) 命令该服务不做其他redis服务的slave
命令: slaveof no one
2) 修改其readonly为yes
其他的slave再指向new master A
1) 命令该服务为new master A的slave
命令格式 slaveof IP port
8.监控工具 sentinel
Sentinel不断与master通信,获取master的slave信息.
监听master与slave的状态
如果某slave失效,直接通知master去除该slave.
如果master失效,,是按照slave优先级(可配置),选取1个slave做 new master
,把其他slave--> new master
疑问: sentinel与master通信,如果某次因为master IO操作频繁,导致超时,
此时,认为master失效,很武断.
解决: sentnel允许多个实例看守1个master, 当N台(N可设置)sentinel都认为master失效,才正式失效.
Sentinel选项配置
port 26379 # 端口
sentinel monitor mymaster 127.0.0.1 63792 ,
给主机起的名字(不重即可),
当2个sentinel实例都认为master失效时,正式失效
sentinel down-after-milliseconds mymaster 30000 多少毫秒后连接不到master认为断开
sentinel can-failover mymaster yes #是否允许sentinel修改slave->master. 如为no,则只能监控,无权修改./
sentinel parallel-syncs mymaster 1 , 一次性修改几个slave指向新的new master.
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh ,# 在重新配置new master,new slave过程,可以触发的脚本
9.Redis 中的事务
Redis支持简单的事务
Redis与 mysql事务的对比
Mysql
Redis
开启
start transaction
muitl
语句
普通sql
普通命令
失败
rollback 回滚
discard 取消
成功
commit
exec
注: rollback与discard 的区别
如果已经成功执行了2条语句, 第3条语句出错.
Rollback后,前2条的语句影响消失.
Discard只是结束本次事务,前2条语句造成的影响仍然还在
注:
在mutil后面的语句中, 语句出错可能有2种情况
1: 语法就有问题,
这种,exec时,报错, 所有语句得不到执行
2: 语法本身没错,但适用对象有问题. 比如 zadd 操作list对象
Exec之后,会执行正确的语句,并跳过有不适当的语句.
(如果zadd操作list这种事怎么避免? 这一点,由程序员负责)
思考:
我正在买票
Ticket -1 , money -100
而票只有1张, 如果在我multi之后,和exec之前, 票被别人买了---即ticket变成0了.
我该如何观察这种情景,并不再提交
悲观的想法:
世界充满危险,肯定有人和我抢, 给 ticket上锁, 只有我能操作. [悲观锁]
乐观的想法:
没有那么人和我抢,因此,我只需要注意,
--有没有人更改ticket的值就可以了 [乐观锁]
Redis的事务中,启用的是乐观锁,只负责监测key没有被改动.
具体的命令---- watch命令
例:
redis 127.0.0.1:6379> watch ticket
OK
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> decr ticket
QUEUED
redis 127.0.0.1:6379> decrby money 100
QUEUED
redis 127.0.0.1:6379> exec
(nil) // 返回nil,说明监视的ticket已经改变了,事务就取消了.
redis 127.0.0.1:6379> get ticket
"0"
redis 127.0.0.1:6379> get money
"200"
watch key1 key2 ... keyN
作用:监听key1 key2..keyN有没有变化,如果有变, 则事务取消
unwatch
作用: 取消所有watch监听
10.redis消息发布与订阅
使用办法:
订阅端: Subscribe 频道名称
发布端: publish 频道名称 发布内容
客户端例子:
redis 127.0.0.1:6379> subscribe news
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "news"
3) (integer) 1
1) "message"
2) "news"
3) "good good study"
1) "message"
2) "news"
3) "day day up"
服务端例子:
redis 127.0.0.1:6379> publish news 'good good study'
(integer) 1
redis 127.0.0.1:6379> publish news 'day day up'
(integer) 1
监听多个发布
Psubscribe new* : 监听所有的new开头的发布
以下在2.8版本以后才支持
Pubsub ..
11.冷数据写入MySQL
案例：微博，主动显示部分，当你下拉时去库内获取数据；
例如：微博超过1000条时，redis存最新的1000条，其余的存在MYSQL里
要点：
1． 把最新的20条微博放到一个有序集合内，供粉丝获取
2． 把最新的1000条微博放到一个链表内，自己获取，把1000后的旧微博，放到mysql内
思路：1000条存在global：store
1． 1只要获取最新20条即可
$r = connredis();
/****/
$r->hmset('post:postid:'.$postid,array('userid'=>$user['userid'],'username'=>$user['username'],
'time'=>$user['time'],'content'=>$user['content'])); -- 一次性设置key对象多个属性值
//把自己发的微博维护一个有序集合里，只需要20个，供粉丝取用
$r->zadd('starpost:userid:'.$user['userid'],$postid,$postid) -- 设置有序集合
if($r->zcard('starpost:userid:'.$user['userid'])>20){ --返回元素个数
$r->zremrangebyrank('starpost:userid'.$user['userid'],0,0); -->按排名删除最旧的那个
}
2． 2的方案如下：
$r->lpush('mypost:userid:'.$user['userid'],$postid); --在链表内从左边放入微博id
if($r->llen('mypost:userid:'.$user['userid'])>1000){ --计算链表的长度，若大于1000
$r->rpoplpush('mypost:userid'.$user['userid'],'global:store');--从前者右边取出，放入到后者的左边
}
查看globle：store所有： lrange global:store 0 -1
查看globle：store最右边： lrange global:store -1 -1
定时任务从global:store内取1000条
新建表：
$sql = 'insert into post(postid,userid,username,time,content) values';
$i=0;
while($r->llent('globle:store')&&$i++<1000){ -- 判断链表的长度
$postid = $r->rpop('globle:store'); -- 删除最右边的参数，并返回
$post = $r->hmget('post:postid:'.$postid,arr('userid','username','time','content')); -- 获取多个参数
$sql = --作者在这里是拼接，一次插入多条
}
if($i=0){}
连接数据库，把就微博写入数据库
设置定时任务执行
12.高速写入测试
微博：通过定时脚本，告诉写入
1、做压力测试的工具：ab
2、性能的监控工具：nmon
查看下linux主机上的ulimit -n 的数据，没有改动过的是1024，最好要改的大一点。这个是linux下最大线程数，如果过小的话无法进行大并量的测试。
ab经行压力测试时的脚本我用的形式为：
1.（get方式）./ab -n 1000 -c 1000 -k http://localhost/hello.php
2.（post方式./ab -n 2500 -c 2500 -k -p postfile http://localhost/hello.php
[1]参数n为请求的次数
[2]c为一次请求的并发次数
[3]-k为keep_alive,一般出现链接被重置的错误时最好带上-k的参数。
还有好多参数，可以在ab--help中看下(这个是超级秘籍)。
crontab -e 设置定时任务
1. 每一分钟执行一次
2. 执行对象：cron2mysql.php
压测脚本：..
测试结果如下：
Time taken for tests: 32.690 seconds
Complete requests: 20000
Failed requests: 0
Write errors: 0
Non-2xx responses: 20000
Total transferred: 13520000 bytes
Total POSTed: 5340000
HTML transferred: 9300000 bytes
Requests per second: 611.80 [#/sec] (mean)
Time per request: 81.726 [ms] (mean)
Time per request: 1.635 [ms] (mean, across all concurrent requests)
Transfer rate: 403.88 [Kbytes/sec] received
159.52 kb/s sent
563.41 kb/s total
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.9 0 19
Processing: 14 82 8.4 81 153
Waiting: 4 82 8.4 80 153
Total: 20 82 8.2 81 153
Percentage of the requests served within a certain time (ms)
50% 81
66% 84
75% 86
80% 88
90% 93
95% 96
98% 100
99% 103
100% 153 (longest request)
测试结果:
50个并发, 20000次请求, 虚拟下,未做特殊优化，每次请求redis写操作6次.
总的请求大概120000次：
30+秒左右完成.
平均每秒发布700（600）条微博, 4000（3600）次redis写入.
Redis配置文件
daemonize yes # redis是否以后台进程运行
Requirepass 密码 # 配置redis连接的密码
注:配置密码后,客户端连上服务器,需要先执行授权命令
# auth 密码
===========================================
13.php-redis扩展编译(通过PHP实现redis)
1: 到pecl.php.net 搜索redis
2: 下载stable版(稳定版)扩展
3: 解压,
4: 执行/php/path/bin/phpize (作用是检测PHP的内核版本,并为扩展生成相应的编译配置)
5: configure --with-php-config=/php/path/bin/php-config
6: make && make install
引入编译出的redis.so插件
1: 编辑php.ini
2: 添加
redis插件的使用
// get instance
$redis = new Redis();
// connect to redis server
$redis->open('localhost',6380);
$redis->set('user:userid:9:username','wangwu');
var_dump($redis->get('user:userid:9:username'));
14.Lua与Redis
>>>>>>>>>>>>>>>>>>三.Redis集群
redis集群的诸多方案：具体的内容需要看这篇文章的介绍 http://www.sohu.com/a/79200151_354963
由于Redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经用Redis存储了超过1TB的数据）。
Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例
1.客户端分片
2.Twemproxy ：Twemproxy-缓存代理分片机制 
3.Codis
4.Redis-sentinel哨兵模式集群
5.Redis 3.0 cluster 集群: Redis 3.0 cluster 集群
>>>>>>>>>>>>>>>>>>>>四.开发
<<Redis集群的高可用测试（含Jedis客户端的使用）.pdf>>
1. 单机版 参考 工程
D:\workFile\sofeInstall\rediSpace
edu-common-parent.rar
edu-demo-redis-cluster.rar
Spring_Redis(RedisTemplate).rar
2.哨兵集群
参考： http://blog.csdn.net/donggang1992/article/details/51064962
但是这个有Bug，当RedisCache内配置死的对象挂掉时就不能用了。
参考：account-mine(redis哨兵集群).rar
分析：
applicationContext.xml
applicationContext-mybatis.xml spring-redis.xml(被注释掉了)
accountDao.xml <cache eviction="LRU" type="com.bypay.account.common.redis.RedisCache" />
RedisCache
问题： 配置文件方式的未实现
3.cluster集群
暂未实现
4.twemproxy
4.1 jedis通过twemproxy使用1111端口无法访问
原因在于：twemproxy配置文件nutcracker.yml,监听的IP写的不对，可能写的是127.0.0.1，应该是你访问的实际地址，比如192.168.1.106
4.2 如上必须写上监听端口的地址：若本地写的192.168.1.122，则必须如下方式写：redis-cli -p 1111 不行，必须redis-cli -h 192.168.1.122 -p 1111则不行
关于："redis需要读写分离吗"的讨论
读写分离是对于有磁盘IO阻塞 的数据库才有的概念。 nosql不应该有这种概念。比如，redis你读的话，会瞬间从内存检索出你要的数据并通过网络IO发给你而你写的话也会瞬间检索到该写的内存区域并写进去。所以不存在读写分离这种需求。
要谈分离，也仅仅是并发量大之后的集群压力分离，把读写压力分摊到集群的单元节点上。而不是把[读][写]拆开。