1. Overview of Redis
2. Redis installation and configuration (master-slave replication)
3. Redis cluster
4. Redis Java development
>>>>>>>>>>>>>>>>>>>>>>>>>>>一.Redis 概述
1. Essence: The full name of Redis is Remote Dictionary Server, which is a Key-Value in-memory database similar to Memcache;
2. Features:
(1) It is a high-performance Key-Value storage system with extremely high read and write performance, which can process more than 100,000 read and write operations per second, with a read and write frequency of more than 100K+/sec
Note: The read and write performance of Redis is about 100,000 ops/s, and the latency is generally about 10 to 70 microseconds; while the read and write performance of HBase is generally not more than 1,000 ops/s, and the latency is generally between 1 and 5 milliseconds.
(2) Compared with Memcached, it supports more abundant data structures, including string (string), list (linked list), set (collection), zset (sorted set--ordered collection) and hash (hash type)
(3) Redis provides a data persistence mechanism, which can periodically and asynchronously flush data to the hard disk. In some scenarios, you can use it as a non-relational database;
(4) Support for publishing/subscribing of messages, so that you have another choice when building a high-performance message queuing system.
(5) Also as an in-memory database, (1) It has high requirements for physical memory storage (2) The amount of data processed is much smaller than HBase and MongoDB (3) The goal is to be an efficient distributed cache. Data is generally not available in real time. It is also not suitable for storage and analysis (4) Of course, it is far from the function of the database
3. Application scenarios:
(1) Redis is very suitable for caching, as an enhanced version of Memached
(2) It is used as a "read library" in some scenarios of "separation of read and write". For example, it is commonly used to store the analysis results of Hadoop or Spark.
(3) Because it supports rich operations on lists, a lightweight high-performance message queue server can be realized by using List as a FIFO bidirectional list.
(4) Use its Set as a high-performance tag system
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Redis installation and configuration (master-slave replication)
Redis stand-alone
Reference: Mr. Wu Shuicheng's <<Redis installation and use.pdf>> attachment
Practice: Combine your own practice
1. Environment configuration
(1) Machine configuration: hostname (edu-redis)
(2)IP:192.168.1.122
(3) System: CentOS 6.6
(4) Redis version: redis-3.0.6.tar.gz (Considering the characteristics of Redis3.0 in terms of clustering and performance improvement, the rc version is the candidate version of the official version, and the official version will be released soon)
(5) Installation directory: /usr/local/redis
(6) User: root
2. Redis installation
#Configure the hostname
hostname "edu-redis-01" #Set the hostname to edu-redis-01
vi /etc/sysconfig/network #Edit configuration file
HOSTNAME=edu-redis-01
vi /etc/hosts #Edit configuration file
127.0.0.1 edu-redis-01 localhost
:wq! #Save and exit
#Compile and install the required packages
yum install gcc tcl
#Download and install 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
The following series of operations: follow <<Redis installation and use.pdf>>
# Some file introductions
(1) redis-benchmark performance testing tool
(2) redis-check-aof log file detection tool (such as log damage caused by power failure, it can be detected and repaired)
(3) redis-check-dump snapshot file detection tool , on the effect class
(4) redis-cli client
(5) redis-server server
3. Redis configuration
vi /usr/servers/redis-2.8.19/redis.conf
1. Basic settings
#Port settings, default 6379
port 6379
#Log file, default /dev/null
logfile ""
2. Redis memory settings
Memory size correspondence
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#Set the size of Redis to occupy 100mb
maxmemory 100mb
#If the memory is full, you need to delete the expired/oldest according to the corresponding algorithm
#volatile-lru Remove expired keys according to the LRU algorithm
#allkeys-lru Remove any keys according to the LRU algorithm (including those keys without an expiration time)
#volatile-random/allkeys->random use random algorithm instead of LRU for deletion
#volatile-ttl Remove expiring keys based on Time-To-Live
#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发给你而你写的话也会瞬间检索到该写的内存区域并写进去。所以不存在读写分离这种需求。
要谈分离，也仅仅是并发量大之后的集群压力分离，把读写压力分摊到集群的单元节点上。而不是把[读][写]拆开。