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

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

进入从

/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

但是此时重启redis后该配置会丢失，可以执行如下命令重写配置文件

127.0.0.1:6660> config rewrite

注意：此时所以配置包括主从配置都会重写。

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发给你而你写的话也会瞬间检索到该写的内存区域并写进去。所以不存在读写分离这种需求。
要谈分离，也仅仅是并发量大之后的集群压力分离，把读写压力分摊到集群的单元节点上。而不是把[读][写]拆开。