文档库 最新最全的文档下载
当前位置:文档库 › redis缓存技术学习

redis缓存技术学习

redis缓存技术学习
redis缓存技术学习

1 什么是redis

redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。

2 性能怎么样

Redis是一个高性能的key-value内存数据库。官方性能测试结果:

set操作每秒110000次,get操作每秒81000次。

3 可不可以存对象

和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。

4 Redis与memcache的最大区别

Replication(树形)

data types(String、Lists、Sorted Sets、Hashes)

persistence (snapshot、aof)

很多开发者都认为Redis不可能比Memcached快,Memcached完全基于内存,而Redis 具有持久化保存特性,即使是异步的,Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因,目前想到的原因有这几方面。

Libevent。和Memcached不同,Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis 用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis

使用另外一个libevent高性能替代libev,但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。

CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token,cas相当value版本号,每次set会token 需要递增,因此带来CPU和内存的双重开销,虽然这些开销很小,但是到单机10G+ cache 以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。

5单台Redis的存放数据必须比物理内存小

Redis的数据全部放在内存带来了高速的性能,但是也带来一些不合理之处。比如一个中型网站有100万注册用户,如果这些资料要用Redis来存储,内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户,1周来访问过1次的也只有15万用户,因此全部100万用户的数据都放在内存有不合理之处,RAM需要为冷数据买单。

这跟操作系统非常相似,操作系统所有应用访问的数据都在内存,但是如果物理内存容纳不下新的数据,操作系统会智能将部分长期没有访问的数据交换到磁盘,为新的应用留出空间。现代操作系统给应用提供的并不是物理内存,而是虚拟内存(Virtual Memory)的概念。

基于相同的考虑,Redis 2.0也增加了VM特性。让Redis数据容量突破了物理内存的限制。并实现了数据冷热分离。

6 Redis的VM实现是重复造轮子

Redis的VM依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到OS也可以自动帮程序实现冷热数据分离,Redis只需要OS申请一块大内存,OS会自动将热数据放入物理内存,冷数据交换到硬盘,另外一个知名的“理解了现代操作系统(3)”的Varnish就是这样实现,也取得了非常成功的效果。

作者antirez在解释为什么要自己实现VM中提到几个原因(6)。主要OS的VM换入换出是基于Page概念,比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问,这个页也不会被SWAP, 换入也同样道理,读到一个字节可能会换入4K无用的内

存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block进程,也是导致Redis要自己实现VM原因之一。

7 用get/set方式使用Redis

作为一个key value存在,很多开发者自然的使用set/get方式来使用Redis,实际上这并不是最优化的使用方法。尤其在未启用VM情况下,Redis全部数据需要放入内存,节约内存尤其重要。

假如一个key-value单元需要最小占用512字节,即使只存一个字节也占了512字节。这时候就有一个设计模式,可以把key复用,几个key-value放入一个key中,value再作为一个set存入,这样同样512字节就会存放10-100倍的容量。

这就是为了节约内存,建议使用hashset而不是set/get的方式来使用Redis

8使用aof代替snapshot

Redis有两种存储方式,默认是snapshot方式,实现方法是定时将内存的快照(snapshot)持久化到硬盘,这种方法缺点是持久化之后如果出现crash则会丢失一段数据。因此在完美主义者的推动下作者增加了aof方式。aof即append only mode,在写入内存数据的同时将操作命令保存到日志文件,在一个并发更改上万的系统中,命令日志是一个非常庞大的数据,管理维护成本非常高,恢复重建时间会非常长,这样导致失去aof高可用性本意。另外更重要的是Redis是一个内存数据结构模型,所有的优势都是建立在对内存复杂数据结构高效的原子操作上,这样就看出aof是一个非常不协调的部分。

其实aof目的主要是数据可靠性及高可用性,在Redis中有另外一种方法来达到目的:Replication。由于Redis的高性能,复制基本没有延迟。这样达到了防止单点故障及实现了高可用。

9Redis是否支持集群

支持

redis主从复制配置和使用都非常简单。通过主从复制可以允许多个slave server拥有和master server相同的数据库副本。下面是关于redis主从复制的一些特点

1.master可以有多个slave

2.除了多个slave连到相同的master外,slave也可以连接其他slave形成图状结构

3.主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时,master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。

4.主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求,比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余

5.可以在master禁用数据持久化,只需要注释掉master 配置文件中的所有save配置,然后只在slave上配置数据持久化。

下面介绍下主从复制的过程

当设置好slave服务器后,slave会建立和master的连接,然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连接,master都会启动一个后台进程,将数据库快照保存到文件中,同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件后,master就发送文件给slave,slave将文件保存到磁盘上,然后加载到内存恢复数据库快照到slave上。接着master就会把缓存的命令转发给slave。而且后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个slave发来的同步连接命令,只会使用启动一个进程来写数据库镜像,然后发送给所有slave。

可以通过"make test”命令判断是否安装成功。

2. 在Linux服务器上创建一个目录,Demo,Demo存放Slave服务,在服务中的配置文件修改:

view sourceprint?

会发送一个SYNC请求,从Master上面进行相应,而且它支持自动重连,即当master

能够接受Slave的应答,并且开始持久化操作,说明在Slave每次去连接Master的时候,

运行结果:

数据Set的时候,数据保存在内存中,当调用Save方法时候,将数据保存在磁盘中。

其中你会发现在3个服务目录中,都出现了dump.rdb,说明Master的文件都同步到Slave 中去了。

用UE编辑器打开文件查看:

从Redis源码中,可以发现rdb文件采用的是lzf压缩算法进行实现,默认lzf压缩算法是开启的。

10安装与使用

一、下载安装

Wget https://www.wendangku.net/doc/7b16747170.html,/files/redis-2.2.7.tar.gz

二、.安装部署

Redis代码

1.tar zxvf

2.redis-2.2.7.tar.gz

3.cd redis-2.2.7.tar.gz

4.make

可以将redis.conf 复制到 /etc/下

Redis代码

1.cp redis.conf /etc/

2.cp src/redis-server src/redis-cli src/redis-benchmark /usr/loc

al/redis

启动redis

Redis代码

1./usr/local/redis/redis-server redis.conf

Port默认端口是6379

简单的测试:

存值:

./redis-cli set hxaaa

取值:

./redis-cli get hx

要配置参数的意义:

?daemonize:是否以后台daemon方式运行

?pidfile:pid文件位置

?port:监听的端口号

?timeout:请求超时时间

?loglevel:log信息级别

?logfile:log文件位置

?databases:开启数据库的数量

?save * *:保存快照的频率,第一个*表示多长时间,第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时,自动保存快照。可设置多个条件。

?rdbcompression:是否使用压缩

?dbfilename:数据快照文件名(只是文件名,不包括目录)

?dir:数据快照的保存目录(这个是目录)

?appendonly:是否开启appendonlylog,开启的话每次写操作会记一条log,这会提高数据抗风险能力,但影响效率。

appendfsync:appendonlylog如何同步到磁盘(三个选项,分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步)

Redis命令总结

Redis提供了丰富的命令(command)对数据库和各种数据类型进行操作,这些command可以在Linux终端使用。在编程时,比如使用Redis 的Java语言包,这些命令都有对应的方法,比如上面例子中使用的sadd方法,就是对集合操作中的SADD命令。下面将Redis提供的命令做一总结。

连接操作相关的命令

quit:关闭连接(connection)

auth:简单密码认证

对value操作的命令

exists(key):确认一个key是否存在

del(key):删除一个key

type(key):返回值的类型

keys(pattern):返回满足给定pattern的所有key

randomkey:随机返回key空间的一个key

rename(oldname, newname):将key由oldname重命名为newname,若newname存在则删除newname表示的key

dbsize:返回当前数据库中key的数目

expire:设定一个key的活动时间(s)

ttl:获得一个key的活动时间

select(index):按索引查询

move(key, dbindex):将当前数据库中的key转移到有dbindex索引的数据库

flushdb:删除当前选择数据库中的所有key

flushall:删除所有数据库中的所有key

对String操作的命令

set(key, value):给数据库中名称为key的string赋予值value

get(key):返回数据库中名称为key的string的value

getset(key, value):给名称为key的string赋予上一次的value

mget(key1, key2,…, key N):返回库中多个string(它们的名称为key1,key2…)的value

setnx(key, value):如果不存在名称为key的string,则向库中添加string,名称为key,值为value

setex(key, time, value):向库中添加string(名称为key,值为value)同时,设定过期时间time

mset(key1, value1, k ey2, value2,…key N, value N):同时给多个string 赋值,名称为key i的string赋值value i

msetnx(key1, value1, key2, value2,…key N, value N):如果所有名称为key i的string都不存在,则向库中添加string,名称key i赋值为value i

incr(key):名称为key的string增1操作

incrby(key, integer):名称为key的string增加integer

decr(key):名称为key的string减1操作

decrby(key, integer):名称为key的string减少integer

append(key, value):名称为key的string的值附加value

substr(key, start, end):返回名称为key的string的value的子串

对List操作的命令

rpush(key, value):在名称为key的list尾添加一个值为value的元素

lpush(key, value):在名称为key的list头添加一个值为value的元素

llen(key):返回名称为key的list的长度

lrange(key, start, end):返回名称为key的list中start至end之间的元素(下标从0开始,下同)

ltrim(key, start, end):截取名称为key的list,保留start至end之间的元素

lindex(key, index):返回名称为key的list中index位置的元素

lset(key, index, value):给名称为key的list中index位置的元素赋值为value

lrem(key, count, value):删除count个名称为key的list中值为value 的元素。count为0,删除所有值为value的元素,count>0从头至尾删除count 个值为value的元素,count<0从尾到头删除|count|个值为value的元素。

lpop(key):返回并删除名称为key的list中的首元素

rpop(key):返回并删除名称为key的list中的尾元素

blpop(key1, key2,… key N, timeout):lpop命令的block版本。即当timeout为0时,若遇到名称为key i的list不存在或该list为空,则命令结束。如果timeout>0,则遇到上述情况时,等待timeout秒,如果问题没有解决,则对key i+1开始的list执行pop操作。

brpop(key1, key2,… key N, timeout):rpop的block版本。参考上一命令。

rpoplpush(srckey, dstkey):返回并删除名称为srckey的list的尾元素,并将该元素添加到名称为dstkey的list的头部

对Set操作的命令

sadd(key, member):向名称为key的set中添加元素member

srem(key, member) :删除名称为key的set中的元素member

spop(key) :随机返回并删除名称为key的set中一个元素

smove(srckey, dstkey, member):将member元素从名称为srckey的集合移到名称为dstkey的集合

scard(key) :返回名称为key的set的基数

sismember(key, member):测试member是否是名称为key的set的元素 sinter(key1, key2,…key N) :求交集

sinterstore(dstkey, key1, key2,…key N) :求交集并将交集保存到dstkey的集合

sunion(key1, key2,…key N) :求并集

sunionstore(dst key, key1, key2,…key N):求并集并将并集保存到dstkey的集合

sdiff(key1, key2,…key N) :求差集

sdiffstore(dstkey, key1, key2,…key N):求差集并将差集保存到dstkey的集合

smembers(key):返回名称为key的set的所有元素

srandmember(key):随机返回名称为key的set的一个元素

对zset(sorted set)操作的命令

zadd(key, score, member):向名称为key的zset中添加元素member,score用于排序。如果该元素已经存在,则根据score更新该元素的顺序。

zrem(key, member):删除名称为key的zset中的元素member

zincrby(key, increment, member) :如果在名称为key的zset中已经存在元素member,则该元素的score增加increment;否则向集合中添加该元素,其score的值为increment

zrank(key, member) :返回名称为key的zset(元素已按score从小到大排序)中member元素的rank(即index,从0开始),若没有member元素,返回“nil”

zrevrank(key, member) :返回名称为key的zset(元素已按score从大到小排序)中member元素的rank(即index,从0开始),若没有member元素,返回“nil”

zrange(key, start, end):返回名称为key的zset(元素已按score从小到大排序)中的index从start到end的所有元素

zrevrange(key, start, end):返回名称为key的zset(元素已按score 从大到小排序)中的index从start到end的所有元素

zrangebyscore(key, min, max):返回名称为key的zset中score >= min 且score <= max的所有元素

zcard(key):返回名称为key的zset的基数

zscore(key, element):返回名称为key的zset中元素element的score

zremrangebyrank(key, min, max):删除名称为key的zset中rank >= min 且rank <= max的所有元素

zremrangebyscore(key, min, max):删除名称为key的zset中score >= min且score <= max的所有元素

zunionstore / zinterstore(dstkeyN, key1,…,keyN, WEIGHTS w1,…wN, AGGREGATE SUM|MIN|MAX):对N个zset求并集和交集,并将最后的集合保存在dstkeyN中。对于集合中每一个元素的score,在进行AGGREGATE运算前,都要乘以对于的WEIGHT参数。如果没有提供WEIGHT,默认为1。默认的AGGREGATE 是SUM,即结果集合中元素的score是所有集合对应元素进行SUM运算的值,而MIN和MAX是指,结果集合中元素的score是所有集合对应元素中最小值和最大值。

对Hash操作的命令

hset(key, field, value):向名称为key的hash中添加元素

field<—>value

hget(key, field):返回名称为key的hash中field对应的value

hmget(key, field1, …,field N):返回名称为key的hash中field i 对应的value

hmset(key, field1, value1,…,field N, value N):向名称为key的hash 中添加元素field i<—>value i

hincrby(key, field, integer):将名称为key的hash中field的value 增加integer

hexists(key, field):名称为key的hash中是否存在键为field的域 hdel(key, field):删除名称为key的hash中键为field的域

hlen(key):返回名称为key的hash中元素个数

hkeys(key):返回名称为key的hash中所有键

hvals(key):返回名称为key的hash中所有键对应的value

hgetall(key):返回名称为key的hash中所有的键(field)及其对应的value

持久化

save:将数据同步保存到磁盘

bgsave:将数据异步保存到磁盘

lastsave:返回上次成功将数据保存到磁盘的Unix时戳

shundown:将数据同步保存到磁盘,然后关闭服务

远程服务控制

info:提供服务器的信息和统计

monitor:实时转储收到的请求

slaveof:改变复制策略设置

config:在运行时配置Redis服务器

在192.168.134.96 上安装了redis的master

在192.168.134.97 上安装了slave 绑定了192.168.134.96

11 redis事务

redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行,而中间不会插入其他client的命令。由于redis是单线程来处理所有client 的请求的所以做到这点是很容易的。一般情况下redis在接受到一个client发来的命令后会立即处理并返回处理结果,但是当一个client在一个连接中发出multi命令有,这个连接会进入一个事务上下文,该连接后续的命令并不是立即执行,而是先放到一个队列中。当从此连接受到exec命令后,redis会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给client.然后此连接就结束事务上下文。下面可以看一个例子

redis> multi

OK

redis>incr a

QUEUED

redis>incr b

QUEUED

redis> exec

1. (integer) 1

2. (integer) 1

从这个例子我们可以看到incr a ,incr b命令发出后并没执行而是被放到了队列中。调用e xec后俩个命令被连续的执行,最后返回的是两条命令执行后的结果

我们可以调用discard命令来取消一个事务。接着上面例子

redis> multi

OK

redis>incr a

QUEUED

redis>incr b

QUEUED

redis> discard

OK

redis> get a

"1"

redis> get b

"1"

可以发现这次incr a incr b都没被执行。discard命令其实就是清空事务的命令队列并退出事务上下文。

虽说redis事务在本质上也相当于序列化隔离级别的了。但是由于事务上下文的命令只排队并不立即执行,所以事务中的写操作不能依赖事务中的读操作结果。看下面例子

redis> multi

OK

redis> get a

QUEUED

redis> get b

QUEUED

redis> exec

1. "1"

2. "1"

发现问题了吧。假如我们想用事务实现incr操作怎么办?可以这样做吗?

redis> get a

"1"

redis> multi

OK

redis> set a 2

QUEUED

redis> exec

1. OK

redis> get a,

"2"

结论很明显这样是不行的。这样和get a 然后直接set a是没区别的。很明显由于get a 和set a并不能保证两个命令是连续执行的(get操作不在事务上下文中)。很可能有两个client同时做这个操作。结果我们期望是加两次a从原来的1变成3. 但是很有可能两个c lient的get a,取到都是1,造成最终加两次结果却是2。主要问题我们没有对共享资源a 的访问进行任何的同步

也就是说redis没提供任何的加锁机制来同步对a的访问。

还好redis 2.1后添加了watch命令,可以用来实现乐观锁。看个正确实现incr命令的例子,只是在前面加了watch a

redis> watch a

OK

redis> get a

"1"

redis> multi

OK

redis> set a 2

QUEUED

redis> exec

1. OK

redis> get a,

"2"

watch 命令会监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败。也可以调用watch多次监视多个key.这样就可以对指定的key加乐

观锁了。注意watch的key是对整个连接有效的,事务也一样。如果连接断开,监视和事务都会被自动清除。当然了exec,discard,unwatch命令都会清除连接中的所有监视. redis的事务实现是如此简单,当然会存在一些问题。第一个问题是redis只能保证事务的每个命令连续执行,但是如果事务中的一个命令失败了,并不回滚其他命令,比如使用的命令类型不匹配。

redis> set a 5

OK

redis>lpush b 5

(integer) 1

redis> set c 5

OK

redis> multi

OK

redis>incr a

QUEUED

redis>incr b

QUEUED

redis>incr c

QUEUED

redis> exec

1. (integer) 6

2. (error) ERR Operation against a key holding the wrong kind of value

3. (integer) 6

可以看到虽然incr b失败了,但是其他两个命令还是执行了。

最后一个十分罕见的问题是当事务的执行过程中,如果redis意外的挂了。很遗憾只有部分命令执行了,后面的也就被丢弃了。当然如果我们使用的append-only file方式持久化,redis会用单个write操作写入整个事务内容。即是是这种方式还是有可能只部分写入了事务到磁盘。发生部分写入事务的情况下,redis重启时会检测到这种情况,然后失败退出。可以使用redis-check-aof工具进行修复,修复会删除部分写入的事务内容。修复完后就能够重新启动了。

12 redis的持久化

redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式,一种是Snapshotting(快照)也是默认方式,另一种是Append-only file(缩写aof)的方式。下面分别介绍

Snapshotting

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照,下面是默认的快照保存配置

save 900 1 #900秒内如果超过1个key被修改,则发起快照保存

save 300 10 #300秒内容如超过10个key被修改,则发起快照保存

save 60 10000

下面介绍详细的快照保存过程

1.redis调用fork,现在有了子进程和父进程。

2. 父进程继续处理client请求,子进程负责将内存内容写入到临时文件。由于os的写时复制机制(copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时os会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。

3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的,由于redis是用一个主线程来处理所有client的请求,这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

另外由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话,可以采用aof持久化方式。下面介绍

Append-only file

aof比快照方式有更好的持久化性,是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改,所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下(默认是:每秒fsync一次)

appendonly yes //启用aof持久化方式

# appendfsync always //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用

appendfsynceverysec //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐

# appendfsync no //完全依赖os,性能最好,持久化没保证

aof的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test 命令100次,文件中必须保存全部的100条命令,其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis 提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件。具体过程如下

1. redis调用fork ,现在有父子两个进程

2. 子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令

3.父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。

4.当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。

5.现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。

需要注意到是重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

Redis面试专题及答案

redis和memcached什么区别?为什么高并发下有时单线程的redis比多线程的memcached效率要高? 区别: 1.mc可缓存图片和视频。rd支持除k/v更多的数据结构; 2.rd可以使用虚拟内存,rd可持久化和aof灾难恢复,rd通过主从支持数据备份; 3.rd可以做消息队列。 原因:mc多线程模型引入了缓存一致性和锁,加锁带来了性能损耗。 redis主从复制如何实现的?redis的集群模式如何实现?redis的key是如何寻址的? 主从复制实现:主节点将自己内存中的数据做一份快照,将快照发给从节点,从节点将数据恢复到内存中。之后再每次增加新数据的时候,主节点以类似于mysql的二进制日志方式将语句发送给从节点,从节点拿到主节点发送过来的语句进行重放。 分片方式: -客户端分片 -基于代理的分片 ●Twemproxy ●codis -路由查询分片 ●Redis-cluster(本身提供了自动将数据分散到Redis Cluster不同节点的能力,整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的) redis-cluster分片原理:Cluster中有一个16384长度的槽(虚拟槽),编号分别为0-16383。每个Master节点都会负责一部分的槽,当有某个key被映射到某个Master负责的槽,那么这个Master负责为这个key提供服务,至于哪个Master节点负责哪个槽,可以由用户指定,也可以在初始化的时候自动生成,只有Master才拥有槽的所有权。Master节点维护着一个16384/8字节的位序列,Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽,Master只要判断序列的第二位(索引从0开始)是不是为1即可。这种结构很容易添加或者删除节点。比如如果我想新添加个节点D, 我需要从节点A、B、C中得部分槽到D上。 使用redis如何设计分布式锁?说一下实现思路?使用zk可以吗?如何实现?这两种有什么区别? redis: 1.线程A setnx(上锁的对象,超时时的时间戳t1),如果返回true,获得锁。 2.线程B 用get获取t1,与当前时间戳比较,判断是是否超时,没超时false,若超时执行第3步; 3.计算新的超时时间t2,使用getset命令返回t3(该值可能其他线程已经修改过),如果 t1==t3,获得锁,如果t1!=t3说明锁被其他线程获取了。 4.获取锁后,处理完业务逻辑,再去判断锁是否超时,如果没超时删除锁,如果已超时,不用处理(防止删除其他线程的锁)。 zk: 1.客户端对某个方法加锁时,在zk上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点node1; 2.客户端获取该路径下所有已经创建的子节点,如果发现自己创建的node1的序号是最小的,就认为这个客户端获得了锁。 3.如果发现node1不是最小的,则监听比自己创建节点序号小的最大的节点,进入等待。

memcached&redis性能测试

一、Memcached 1.1、memcached简介 Memcached 是一个高性能的分布式内存对象缓存系统,用于动态Web 应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程(daemon )是用C写的,但是客户端可以用任何语言来编写,并通过memcached协议与守护进程通信。但是它并不提供冗余(例如,复制其hashmap条目);当某个服务器S停止运行或崩溃了,所有存放在S上的键/值对都将丢失。 Memcached由Danga Interactive开发,其最新版本发布于2010年,作者为Anatoly Vorobey和Brad Fitzpatrick。用于提升LiveJournal . com访问速度的。LJ每秒动态页面访问量几千次,用户700万。Memcached将数据库负载大幅度降低,更好的分配资源,更快速访问。 1.2、Memcached是如何工作的 Memcached的神奇来自两阶段哈希(two-stage hash)。Memcached就像一个巨大的、存储了很多对的哈希表。通过key,可以存储或查询任意的数据。客户端可以把数据存储在多台memcached上。当查询数据时,客户端首先参考节点列表计算出key的哈希值(阶段一哈希),进而选中一个节点;客户端将请求发送给选中的节点,然后memcached节点通过一个内部的哈希算法(阶段二哈希),查找真正的数据(item)。举个列子,假设有3个客户端1, 2, 3,3台memcached A, B, C:Client 1想把数 据”tuletech”以key “foo”存储。Client 1首先参考节点列表(A, B, C),计算key “foo”的哈希值,假设memcached B被选中。接着,Client 1直接connect 到memcached B,通过key “foo”把数据”tuletech”存储进去。Client 2使用与Client 1相同的客户端库(意味着阶段一的哈希算法相同),也拥有同样的

Redis的5个常见使用场景

Redis的5个常见使用场景概括 大家平时在使用Redis的时候有没有总结过Redis常用于哪些场景呢。下面科多老师带着大家一起来总结一下,希望能够帮助到各位同学。 1、会话缓存(Session Cache) 最常用的一种使用Redis的情景是会话缓存(session cache)。用Redis 缓存会话比其他存储(如Memcached)的优势在于:Redis提供持久化。当维护一个不是严格要求一致性的缓存时,如果用户的购物车信息全部丢失,大部分人都会不高兴的,现在,他们还会这样吗? 幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用Redis 来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。 2、全页缓存(FPC) 除基本的会话token之外,Redis还提供很简便的FPC平台。回到一致性 问题,即使重启了Redis实例,因为有磁盘的持久化,用户也不会看到页面加载速度的下降,这是一个极大改进,类似PHP本地FPC。 再次以Magento为例,Magento提供一个插件来使用Redis作为全页缓存后端。 此外,对WordPress的用户来说,Pantheon有一个非常好的插件wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。 3、队列 Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作,这使得Redis 能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作,就类似于本地程序语言(如Python)对 list 的 push/pop 操作。 如果你快速的在Google中搜索“Redis queues”,你马上就能找到大量的开源项目,这些项目的目的就是利用Redis创建非常好的后端工具,以满足各种队列需求。例如,Celery有一个后台就是使用Redis作为broker,你可以从这 里去查看。 4、排行榜/计数器 Redis在内存中对数字进行递增或递减的操作实现的非常好。集合(Set) 和有序集合(Sorted Set)也使得我们在执行这些操作的时候变的非常简单,Redis只是正好提供了这两种数据结构。所以,我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”,我们只需要像下面一样执行即可: 当然,这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数,你需要这样执行: ZRANGE user_scores 0 10 WITHSCORES

memcache、redis、tair性能对比测试报告材料

memcache、redis、tair性能对比测试报告 第1章限制条件 前一周所做的分布缓存技术预言中有包括ehcache、memcache、redis、tair,还包括了基于MongoDB的分布式技术。测试中,考虑到各自功能的差异化特点,其中选择了memcache、redis、tair功能特性相近的缓存服务器进行性能对比,所以ehcache、MongoDB将不做为本次测试的规范,其原因如下: 1)Ehcache是组件级别的缓存,要搭建一个独立的缓存服务器,需要用到ehcache server 模块,这是个war包,能运行在web 容器中,决定整个缓存服务器性能的好坏因素太多,比如web服务器,集群方式等。跟memcache、redis、tair没有对比性。 2)MongoDB是面向文档的数据库,跟缓存没有可比性。 第2章测试场景概述 性能测试包括单机环境和分布式环境,主要针对memcache、redis、tair各缓存服务器在缓存了不同级别的数据下,多个线程并发操作向缓存set/get缓存数据,考虑到网络方面的负载,又将每次set/get操作的缓存数据的大小分为三个不同的级别:1KB,10KB,100KB,通过对上述的条件进行排列,取得以下的测试场景。 第3章单机环境测试 3.1.测试场景: 1.当各缓存的数据库空时,以单线程通过各缓存客户端set调用向服务端推送数据,比较 10000操作所消耗的时间,以上动作通过使用不同大小的单个缓存对象重复三次。2.在场景一完成的情况下,以单线程通过各缓存客户端get调用向服务端获取数据,比较 10000操作所消耗的时间,以上动作通过使用不同大小的单个缓存对象重复三次。3.并发200个线程通过缓存软件的客户set调用向服务端推送数据,每个线程完成10000 次的操作,比较服务器的tps大小,以上动作通过使用不同大小的单个缓存对象重复三

Redis面试题及答案

Redis 是一个基于内存的高性能key-value数据库。(有空再补充,有理解错误或不足欢迎指正) Reids的特点 Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。 因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存多种数据结构,此外单个value的最大限制是1GB,不像 memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等。 另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 Redis支持的数据类型 Redis通过Key-Value的单值不同类型来区分, 以下是支持的类型: Strings Lists Sets 求交集、并集 Sorted Set hashes

为什么redis需要把所有数据放到内存中? Redis为了达到最快的读写速度将数据都读到内存中,并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。 如果不将数据放在内存中,磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天,redis将会越来越受欢迎。 如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。 Redis是单进程单线程的 redis利用队列技术将并发访问变为串行访问,消除了传统数据库串行控制的开销 虚拟内存 当你的key很小而value很大时,使用VM的效果会比较好.因为这样节约的内存比较大. 当你的key不小时,可以考虑使用一些非常方法将很大的key变成很大的value,比如你可以考虑将key,value组合成一个新的value. vm-max-threads这个参数,可以设置访问swap文件的线程数,设置最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的. 可能会造成比较长时间的延迟,但是对数据完整性有很好的保证. 自己测试的时候发现用虚拟内存性能也不错。如果数据量很大,可以考虑分布式或者其他数据库 分布式 redis支持主从的模式。原则:Master会将数据同步到slave,而slave不会将数据同步到master。Slave启动时会连接master来同步数据。 这是一个典型的分布式读写分离模型。我们可以利用master来插入数据,slave提供检索服务。这样可以有效减少单个机器的并发访问数量。

redis-jedis笔记整理

启动Redis服务器 启动客户端 Redis命令目录key(建) 保存键值对set key value 查询指定键对象get key 删除给定键的对象del key1key2…

设置键过期时间EXPIRE key exptime 剩余时间ttl key 查看搜索有键值keys键 migrate指令(移动将数据移动另外一个数据) 将key原子性地从当前实例传送到目标实例的指定数据库上,一旦传送成功,key保证会出现在目标实例上,而当前实例上的key会被删除。 MOVE key db 将数据库的key移动到指定的数据库db当中。如果当前数据库(源数据库)和给定数据库(目标数据库)有相同的名字的给定key,或者key不存在于当前数据库,那么MOVE没有任何效果。因此,也可以利用这一特性,将MOVE当作锁(locking)原语(primitive)。

Obejct{refcount|encoding|idletime} 通常用在debug或者了解为了节省空间使用特殊的编码情况,当redis用作缓存时候,也可以通过OBJECT命令中的信息,决定key的驱逐策略. object refcount key:返回给定key引用所存储的值的次数. object encoding key:返回给定key所存储的值编码可以有 raw(一般字符串)或int(用字符串表示64位数字是为了节约空间)。 ziplist或linkedlist。ziplist是为节约大小较小的列表空间而作的特殊表示。 intset或者hashtable。intset是只储存数字的小集合的特殊表示。 zipmap或者hashtable。zipmap是小哈希表的特殊表示。 ziplist或者skiplist格式。ziplist用于表示小的有序集合,而skiplist则用于表 示任何大小的有序集合。 object idletime key:返回给定key自存储的空闲时间 persist key 将key从带生存时间转换为持久的不带生存时间.

redis系列三-springboot如何使用redis做缓存及缓存注解的用法总结

redis系列三-springboot如何使用redis做缓存及缓存注解的 用法总结 1. 概述 本文介绍spring boot 如何使用Redis做缓存,如何对redis 缓存进行定制化配置(如key的有效期)以及spring boot 如何初始化redis做缓存。使用具体的代码介绍了@Cacheable,@CacheEvict,@CachePut,@CacheConfig等注解及其属性的用法。 2. spring boot集成redis 2.1. application.properties 配置application.properties,包含如下信息: 指定缓存的类型 配置redis的服务器信息 请不要配置spring.cache.cache-names值,原因后面再说 ## 缓存 # spring.cache.cache-names=book1,book2 spring.cache.type=REDIS # REDIS (RedisProperties)

spring.redis.database=0 spring.redis.host=192.168.188.7 spring.redis.password= spring.redis.port=6379 spring.redis.pool.max-idle=8 spring.redis.pool.min-idle=0 spring.redis.pool.max-active=100 spring.redis.pool.max-wait=-1123456789101112131234567891 0111213 2.2. 配置启动类 @EnableCaching: 启动缓存 重新配置RedisCacheManager,使用新的配置的值 @SpringBootApplication @EnableCaching // 启动缓存 public class CacheApplication { private static final Logger log = LoggerFactory.getLogger(CacheApplication.class); public static void main(String[] args) { https://www.wendangku.net/doc/7b16747170.html,("Start CacheApplication.. ");

【IT专家】Redis缓存Mysql模拟用户登录Java实现实例

本文由我司收集整编,推荐下载,如有疑问,请与我司联系Redis缓存Mysql模拟用户登录Java实现实例2016/03/18 1 这段时间在研究Redis,作为缓存界的新宠,现在使用它的公司越来越多。本文使用的是最新稳定版Redis3.0.实现的具体逻辑是: 1. 用户登录首先判断是否在redis缓存中,如果在redis缓存中,直接登录成功; 2. 若用户未在redis缓存,则访问Mysql,判断用户是否存在,如果不存在,则提示用户注册;如果存在,则登录成功; 3. 在mysql存在并登录成功的同时,将改条数据用Redis Hash类型进行缓存,并设置过期时间为30分钟; 4. 设置redis最大内存,若超出内存范围,则使用FIFO方式进行清除。 ?本文实现方式为最简单的模拟方式,有的代码有进一步封装得必要。 ?一、首先创建两个类,一个类连接Mysql,一个类连接Redis,并复写相关方法:?public class Mysql {public Connection conn;{try {Class.forName( com.mysql.jdbc.Driver conn=DriverManager.getConnection( jdbc:mysql://localhost/spring , root , root } catch (ClassNotFoundException e) {e.printStackTrace();} catch (SQLException e) {e.printStackTrace();}}} ?public class Redis extends Jedis {public Jedis redis;{redis = new Jedis( 192.168.217.128 , 6379);redis.auth( root }// public static void main(String[] args) {// System.out.println(redis.get( name ));// System.out.println(redis.keys( * ));// // redis.sinter(keys);// }public String get(String key) {return redis.get( name }public String set(String key, String value) {return redis.set(key, value);}public Long del(String... keys) {return redis.del(keys);}// 键值增加字符public Long append(String key, String str) {return redis.append(key, str);}public Boolean exists(String key) {return redis.exists(key);}// Need researchpublic Long setnx(String key, String value) {return redis.setnx(key, value);}public String setex(String key, String value, int seconds) {return redis.setex(key, seconds, value);}public Long setrange(String key, String str, int offset)

Ehcache-Redis-Tair缓存性能对比

Ehcache/Redis/Tair缓存性能对比 后面介绍的不同方式都有测试数据,这些测试数据都是在同一的测试环境下得出的测试结果: 测试机器的配置如下: 64位5核CPU, E5620 @ 2.40GHz,内存8G CDN端缓存 由于计数器的价值并不在,具体的值是多少,尤其是对一些大访问量的商品来说个位或者十位的数据并没有什么意义,所以对这些热门商品的计数器访问可以采用定时更新的办法,可以将计数器的值直接缓存在CDN上或者后端Nginx的缓存中,定时再到数据库服务器上获取最新的计数器的值,这样能够大量减少对后端服务器的访问请求,而且计数器的数据量很小对缓存服务器的空间需求也不大。 改进的结构图如下: 直接在Nginx中利用Cache策略缓存住热门计数器的值,利用http协议的cache+max age来失效缓存的方式更新计数器的值。

优点: 实现方式简单,改动小,能够挡住热门商品的计数器访问请求,采用这种方式对查询请求来说,能达到类似于静态服务器的性能,如Nginx能达到2w的QPS 缺点:没有解决同一商品的计数器合并请求的问题,数据量会增大一倍对更新请求没有办法缓存,只能减少查询请求的压力 基于Java的存储方式 由于目前采用Nginx模块的方法开发,每次修改要重新编译Nginx服务器,所以想采用基于Java的方式,使得维护要容易一些。 选用Ehcache作为数据存储服务器,Ehcache也是基于内存存储,支持定时持久化功能,非常适合存储像计数器这种小数据类型。处理Http请求使用Tomcat容器,结构图如下: 处理逻辑采用一个servlet实现,并且在这个servlet中通过一致性Hash从Ehcache中获取计数器值。 在实际的部署结构中,可以将Tomcat和Ehcache部署在同一台机器上。 基于这种模式的测试结果如下:

基于Spark的机器学习资料66、后台服务代码架构:项目实际应用中redis缓存与数据库一致性问题解决

后台服务代码架构:项目实际应用中redis缓存与数据库一致性问题解决 一、需求起因 假设先写数据库,再淘汰缓存:第一步写数据库操作成功,第二步淘汰缓存失败,则会出现DB中是新数据,Cache中是旧数据,数据不一致【如下图:db中是新数据,cache中是旧数据】。 假设先淘汰缓存,再写数据库:第一步淘汰缓存成功,第二步写数据库失败【如下图:cache 中无数据,db中是旧数据】。 结论:先淘汰缓存,再写数据库。 二、数据不一致原因 先操作缓存,在写数据库成功之前,如果有读请求发生,可能导致旧数据入缓存,引发数据不一致。 写流程: (1)先淘汰cache (2)再写db

(1)先读cache,如果数据命中hit则返回 (2)如果数据未命中miss则读db (3)将db中读取出来的数据入缓存 什么情况下可能出现缓存和数据库中数据不一致呢? 在分布式环境下,数据的读写都是并发的,上游有多个应用,通过一个服务的多个部署(为了保证可用性,一定是部署多份的),对同一个数据进行读写,在数据库层面并发的读写并不能保证完成顺序,也就是说后发出的读请求很可能先完成(读出脏数据): (a)发生了写请求A,A的第一步淘汰了cache(如上图中的1) (b)A的第二步写数据库,发出修改请求(如上图中的2) (c)发生了读请求B,B的第一步读取cache,发现cache中是空的(如上图中的步骤3) (d)B的第二步读取数据库,发出读取请求,此时A的第二步写数据还没完成,读出了一个脏数据放入cache(如上图中的步骤4) 即在数据库层面,后发出的请求4比先发出的请求2先完成了,读出了脏数据,脏数据又入了缓存,缓存与数据库中的数据不一致出现了 三、问题解决思路 能否做到先发出的请求一定先执行完成呢?常见的思路是“串行化”

Redis备份容灾及高可用方案

Redis 备份、容灾及高可用方案

一,Redis简单介绍 Redis是一个高性能的key-value非关系型数据库,由于其具有高性能的特性,支持高可用、持久化、多种数据结构、集群等,使其脱颖而出,成为常用的非关系型数据库。 此外,Redis的使用场景也比较多。 我们常通过Reids的队列功能做购买限制。比如到节假日或者推广期间,进行一些活动,对用户购买行为进行限制,限制今天只能购买几次商品或者一段时间内只能购买一次。也比较适合适用。 4.排名 Redis在内存中对数字进行递增或递减的操作实现得非常好。所以我们在很多排名的场景中会应用Redis来进行,比如小说网站对小说进行排名,根据排名,将排名靠前的小说推荐给用户。

5.发布/订阅 Redis提供发布和订阅功能,发布和订阅的场景很多,比如我们可以基于发布和订阅的脚本触发器,实现用Redis的发布和订阅功能建立起来的聊天系统。 此外还有很多其它场景,Redis都表现的不错。 二,Redis使用中单点故障问题 正是由于Redis具备多种优良特新,且应用场景非常丰富,以至于Redis在各个公司都有它存在的身影。那么随之而来的问题和风险也就来了。Redis虽然应用场景丰富,但部分公司在实践Redis应用的时候还是相对保守使用单节点部署,那为日后的维护带来了安全风险。 在2015年的时候,曾处理过一个因为单点故障原因导致的业务中断问题。当时的Redis都未采用分布式部署,采用单实例部署,并未考虑容灾方面的问题。 当时我们通过Redis服务器做用户购买优惠商品的行为控制,但后来由于未知原因Redis节点的服务器宕机了,导致我们无法对用户购买行为进行控制,造成了用户能够在一段时间内多次购买优惠商品的行为。 这种宕机事故可以说已经对公司造成了不可挽回的损失了,安全风险问题非常严重,作为当时运维这个系统的我来说有必要对这个问题进行修复和在架构上的改进。于是我开始了解决非分布式应用下Redis单点故障方面的研究学习。

redis缓存技术学习

1 什么是redis redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。 2 性能怎么样 Redis是一个高性能的key-value内存数据库。官方性能测试结果: set操作每秒110000次,get操作每秒81000次。 3 可不可以存对象 和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。 4 Redis与memcache的最大区别 Replication(树形) data types(String、Lists、Sorted Sets、Hashes) persistence (snapshot、aof) 很多开发者都认为Redis不可能比Memcached快,Memcached完全基于内存,而Redis 具有持久化保存特性,即使是异步的,Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因,目前想到的原因有这几方面。 Libevent。和Memcached不同,Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis 用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis

REDIS缓存穿透,缓存击穿,缓存雪崩原因+解决方案

REDIS缓存穿透,缓存击穿,缓存雪崩原因+解决方案

文档修订摘要

目录 REDIS缓存穿透,缓存击穿,缓存雪崩原因+解决方案 (1) 1. 概述 (4) 2. 初认识 (4) 3. 缓存穿透解决方案 (4) 4. 缓存击穿解决方案 (5) 5. 缓存雪崩的解决方案 (6) 6. 小结 (8)

1.概述 在我们日常的开发中,无不都是使用数据库来进行数据的存储,由于一般的系统任务中通常不会存在高并发的情况,所以这样看起来并没有什么问题,可是一旦涉及大数据量的需求,比如一些商品抢购的情景,或者是主页访问量瞬间较大的时候,单一使用数据库来保存数据的系统会因为面向磁盘,磁盘读/写速度比较慢的问题而存在严重的性能弊端,一瞬间成千上万的请求到来,需要系统在极短的时间内完成成千上万次的读/写操作,这个时候往往不是数据库能够承受的,极其容易造成数据库系统瘫痪,最终导致服务宕机的严重生产问题。 为了克服上述的问题,项目通常会引入NoSQL技术,这是一种基于内存的数据库,并且提供一定的持久化功能。 redis技术就是NoSQL技术中的一种,但是引入redis又有可能出现缓存穿透,缓存击穿,缓存雪崩等问题。本文就对这三种问题进行较深入剖析。 2.初认识 ?缓存穿透:key对应的数据在数据源并不存在,每次针对此key的请求从缓存获取不到,请求都会到数据源,从而可能压垮数据源。比如用一个不存在的用户id获取用户信息,不论缓存还是数据库都没有,若黑客利用此漏洞进行攻击可能压垮数据库。 ?缓存击穿:key对应的数据存在,但在redis中过期,此时若有大量并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。 ?缓存雪崩:当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力。 3.缓存穿透解决方案 一个一定不存在缓存及查询不到的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不 到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个 足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外 也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数据不存在,还是系 统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。 粗暴方式伪代码: //伪代码public object GetProductListNew() { int cacheTime = 30; String cacheKey = "product_list"; String cacheValue = CacheHelper.Get(cacheKey);

Windows下Redis集群搭建

Windows下搭建Redis集群 Redis 集群简介 Redis 是一个开源的 key-value 存储系统,由于出众的性能,大部分互联网企业都用来做服务器端缓存。Redis 在3.0版本前只支持单实例模式,虽然支持主从模式、哨兵模式部署来解决单点故障,但是现在互联网企业动辄大几百G的数据,可完全是没法满足业务的需求,所以,Redis 在 3.0 版本以后就推出了集群模式。 Redis 集群采用了P2P的模式,完全去中心化。Redis 把所有的 Key 分成了16384 个 slot,每个 Redis 实例负责其中一部分 slot 。集群中的所有信息(节点、端口、slot等),都通过节点之间定期的数据交换而更新。 Redis 客户端可以在任意一个 Redis 实例发出请求,如果所需数据不在该实例中,通过重定向命令引导客户端访问所需的实例。 集群搭建 要让集群正常运作至少需要三个主节点,不过在刚开始试用集群功能时,强烈建议使用六个节点:其中三个为主节点,而其余三个则是各个主节点的从节点。 主节点崩溃,从节点的Redis就会提升为主节点,代替原来的主节点工作,崩溃的主Redis回复工作后,会成为从节点 1). 创建Redis集群目录 在redis安装的根目录下通过命令行创建6个以端口命名的文件夹 mkdir 7000 7001 7002 7003 7004 7005

将安装的redis文件夹中的redis.windows.conf以及redis-server,分别拷贝到新建的六个文件夹中 2). 更改配置 将六个文件夹下的redis.windows.conf文件中以下属性进行修改: port 7001(对应文件夹的端口号) cluster-enabled yes(开启实例的集群模式)去掉注释

Redis开发常用规范

Redis开发常用规范 1.冷热数据分离,不要将所有数据全部都放到Redis中 虽然Redis支持持久化,但是Redis的数据存储全部都是在内存中的,成本昂贵。建议根据业务只将高频热数据存储到Redis中【QPS大于5000】,对于低频冷数据可以使用 MySQL/ElasticSearch/MongoDB等基于磁盘的存储方式,不仅节省内存成本,而且数据量小在操作时速度更快、效率更高! 2.不同的业务数据要分开存储 不要将不相关的业务数据都放到一个Redis实例中,建议新业务申请新的单独实例。因为Redis为单线程处理,独立存储会减少不同业务相互操作的影响,提高请求响应速度;同时也避免单个实例内存数据量膨胀过大,在出现异常情况时可以更快恢复服务! 3.规范Key的格式 合适的key,便于查看,统计,排错。 “平台缩写“+“:”+“项目名”+“:”+“业务含义” 例如:GW:TRADE:USERID GW是新网关,TRADE是交易项目,USERID为业务ID。 ":"-作为key分隔符,方便客户端工具作为目录分级 4.存储的Key一定要设置超时时间 如果应用将Redis定位为缓存Cache使用,对于存放的Key一定要设置超时时间!因为若不设置,这些Key会一直占用内存不释放,造成极大的浪费,而且随着时间的推移会导致内存占用越来越大,直到达到服务器内存上限!另外Key的超时长短要根据业务综合评估,而不是越长越好!(某些业务要求key长期有效。可以在每次写入时,都设置超时时间,让超时时间顺延。) public Boolean set(final byte[] key, final byte[] value, final long liveTime) { return redisTemplate.execute(new RedisCallback() {

金蝶云星空K3 Cloud V7.2 分布式缓存使用说明书

金蝶云星空 分布式缓存使用说明书 修改记录 Ver. No 发版日期编制人批准人修改的章节号V1.02017/12/08 刘兵赖碧云初始版本 V1.22018/01/03 刘兵赖碧云 6.1.2 V1.3 2018/02/24 刘兵赖碧云 6.1

目录 1.概述 (3) 1.1.目的 (3) 1.2.范围 (3) 1.3.适用对象 (3) 1.4.参考资料 (3) 2.问题与解决策略 (3) 3.目标和约束 (3) 4.部署Redis服务 (4) 4.1.安装服务--service-install(安装必须的步骤) (4) 4.2.卸载服务--service-uninstall (4) 4.3.启动服务--service-start(安装必须的步骤) (4) 4.4.停止服务--service-stop (5) 4.5.服务配置修改(服务名和端口) (5) 4.6.Redis-cli配置(如果4.1按照2,3小点进行了修改,此节配置可以忽略) (5) 5.Redis配置文件修改 (5) 6.Redis缓存代码示例 (6) 6.1.1.写缓存和读缓存 (6) 6.1.2.错误的读写缓存 (7) 7.附录 (8)

1. 概述 1.1. 目的 为系统集群及分布式应用提供基础缓存服务。 1.2. 范围 适用版本:V6.2和后续版本 1.3. 适用对象 本文档适用于: 开发工程师:部署和开发指导。 实施人员:部署指导。 1.4. 参考资料 Redis相关资料 2. 问题与解决策略 愿景关注点描述与示例 3. 目标和约束 目标: 提供单据和基础数据的分布式缓存支持;

Django使用redis缓存服务器 光环大数据Python培训

https://www.wendangku.net/doc/7b16747170.html, Django使用redis缓存服务器光环大数据Python培训 光环大数据Python培训了解到,redis相信大家都很熟悉了,和memcached 一样是一个高性能的key-value数据库,至于什么是缓存服务器,度娘都有很明 白的介绍了,我在这里就不一一介绍了。 那我们一般什么情况下才会使用缓存服务器呢?可不是什么情况都需要的 哦,一般来说是在需要频繁对一个字段读取的时候才会需要将这个字段放入到缓 存服务器上,而且由于key-value数据库一般只是放很简单的数据,所以在选择 保存的对象的时候要注意选择好。 下面我就来介绍如何在Django中配置使用redis数据库,首先是先安装 redis了,在Ubuntu中执行下面这句命令: #安装Redis服务器端 sudo apt-get install redis-server 然后为了能在Django中使用redis,还需要安装redis for Django的插件: pip install django-redis 那么现在就是在Django的settings中配置了。 CACHES = { 'default': { 'BACKEND': 'redis_cache.cache.RedisCache', 'LOCATION': '127.0.0.1:6379', "OPTIONS": { "CLIENT_CLASS":

https://www.wendangku.net/doc/7b16747170.html, "redis_cache.client.DefaultClient", }, },}REDIS_TIMEOUT=7*2 4*60*60CUBES_REDIS_TIMEOUT=60*60NEVER_REDIS_TIMEOUT=365*24*60*60 其实只是需要CACHES中的那几条就可以了,后面这三句可以不需要的,只 是我后面的例子里需要用到,我就在这里配置了。 好了,现在连接和配置都已经完成了,那么在项目中该如何使用呢?接下来 看下面这段例子吧。 from django.conf import settingsfrom django.core.cache import cache#read cache user iddef read_from_cache(self, user_name): key = 'user_id_of_'+user_name value = cache.get(key) if value == None: data = None else: data = json.loads(value) return data#write cache user iddef write_to_cache(self, user_name): key = 'user_id_of_'+user_name cache.set(key, json.dumps(user_name), settings.NEVER_REDIS_TIMEOUT) 通过上面的这两个方法就可以实现对redis的读取操作了,只需要将需要的 字段当参数传入到方法中就好了。 那么之前提到的memcached呢?其实也是一样的配置: CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11211', }} 当然用法也是和我上面的例子是一样的了。其实对于redis这样的缓存服务 器来说,配置都是很简单的,而具体的使用也不难,官网上面也有很多简单明了

黑马程序员:为什么更要用redis,应该如何使用redis

为什么缓存数据库更要首选redis?如何使用redis? 一、使用缓存数据库为什么首选用redis? 我们都知道,把一些热数据存到缓存中可以极大的提高速度,那么问题来了,是用Redis 好还是Memcached好呢,以下是它们两者之间一些简单的区别与比较: 1. Redis不仅支持简单的k/v类型的数据,同时还支持list、set、zset(sorted set)、hash等数据结构的存储,使得它拥有更广阔的应用场景。 2. Redis最大的亮点是支持数据持久化,它在运行的时候可以将数据备份在磁盘中,断电或重启后,缓存数据可以再次加载到内存中,只要Redis配置的合理,基本上不会丢失数据。 3. Redis支持主从模式的应用。 4. Redis单个value的最大限制是1GB,而Memcached则只能保存1MB内的数据。 5. Memcache在并发场景下,能用cas保证一致性,而Redis事务支持比较弱,只能保证事务中的每个操作连续执行。 6. 性能方面,根据网友提供的测试,Redis在读操作和写操作上是略领先Memcached的。 从上面这些看出,Redis的优势比Memcached大,不过Memcached也还是有它用武之地的。要是只选择装其中一种的话,还是要首选Redis。 二、如何使用redis? 你一定要知道的是:redis的key名要区分大小写,在redis中除了和空格外,其他的字符都可以做为key名,且长度不做限制,不过为了性能考虑,一般key名不要设置的太长。redis 功能强大,支持数据类型丰富,以下是redis操作命令大全,基本上涵盖了redis所有的命令! 1、redis命令基本篇 1)、【set key value 】存入一个key和值。如:set myname reson 2)、【get key 】读取一个key的值。 3)、【del key 】删除一个key。 4)、【del key1 key2 ... keyN 】删除多个key。如:del myname1 myname2 5)、【exists key 】判断一个key是否存在。 6)、【type key 】查看key的类型。 7)、【rename key keyNew 】重命名key名。如:rename myname myname2 8)、【dbsize 】查看当前库中的key的条数。

相关文档
相关文档 最新文档