Web 功能测试下的 Redis缓存数据库

做web功能测试,最应该了解的一块知识点 。

作为一名出色的功能测试工程师,真的不是随便点点就可以,需要从多方面去了解一个项目,一个系统的原理,配置,才可以更好,更完善的做好测试。

今天给大家分享一篇关于Redis的作用和使用场景的文章。

 

1、Redis

一、为什么使用

解决应用服务器的cpu和内存压力

减少io的读操作,减轻io的压力

关系型数据库的扩展性不强,难以改变表结构

 

二、优点:

nosql数据库没有关联关系,数据结构简单,拓展表比较容易

nosql读取速度快,对较大数据处理快

 

三、适用场景:

数据高并发的读写

海量数据的读写

对扩展性要求高的数据

 

四、不适场景:

需要事务支持(非关系型数据库)

基于sql结构化查询储存,关系复杂

 

五、Redis结构:

Redis是一个开源的key—value型数据库,支持string、list、set、zset和hash类型数据。对这些数据的操作都是原子性的,redus为了保证效率会定期持久化数据。

 

六、使用场景:

配合关系型数据库做高速缓存

缓存高频次访问的数据,降低数据库io

分布式架构,做session共享

可以持久化特定数据。

利用zset类型可以存储排行榜

利用list的自然时间排序存储最新n个数据

 

七、Linux下redis:

redis目录:usr/local/bin

linux下redis常用命令:

redis-benchmark:性能测试工具

redis-server:启动redis服务器

redis-cli:启动redis客户端,操作入口

 

八、Redis基础知识

端口:6379

默认16个数据库,下标从0开始

单线程:redis是单线程+io多路复用:检查文件描述的就绪状态

Memchached:多线程+锁

redis数据类型:String set list hash zset

 

 

2、redis 实际应用中的缓存作用

有人说互联网用户是用脚投票的,这句话其实也从侧面说明了,用户体验是多么的重要;这就要求在软件架构设计时,不但要注重可靠性、安全性、可扩展性以及可维护性等等的一些指标,更要注重用户的体验,用户体验分很多方面,但是有一点非常重要就是对用户操作的响应一定要快;怎样提高用户访问的响应速度,这就是摆在架构设计中必须要解决的问题;说道提高服务的响应速度就不得不说缓存了;

从系统的层面说,CPU的速度远远高于磁盘IO的速度;所以要想提高响应速度,必须减少磁盘IO的操作,但是有很多信息又是存在数据库当中的,每次查询数据库就是一次IO操作;比如查询用户信息的例子。

通常如下图:

 

请求响应时间等于网络响应时间和服务器响应时间;网络我们控制不了,服务器响应时间包括CPU计算时间和磁盘IO时间。

其中CPU计算时间这个有硬件资源决定的,我们尽量减少算法的复杂度来减少它,磁盘IO时间,这个时间是非常慢的,应该尽量减少;

当客户端调用getUser接口的查询用户信息的时候,执行顺序1、2、3、4;由于用户信息存放在DB中,所以2、3就有一次磁盘IO;这个看似非常简单业务逻辑,但是当你做架构设计的时候往往要考虑最坏的场景,或者当成千上万的用户频繁的调用这个接口应该怎么处理?

如果按照上图这样的架构处理,这个看似简单业务的接口会使整个系统变慢,这样用户的请求就会长时间得不到响应;这样的问题怎么解决那,这时候就该缓存登场了;

谈到缓存有几种形式,其中最简单的是在每个进程中开辟一块内存,存放缓存的信息,每次先从内存查… …  但是在一个分布式或者集群的环境中,getUser的接口可能会部署多套,每个进程的的内存是不能共享、相互独立的,这就悲剧了;

还有一种使用一个第三方的缓存也叫公共缓存(比如redis、memcache等);不论部署多少个包含getUser接口的服务,都去访问同一套缓存,那结果就不一样了。

看一下下面这幅图:

 

有Redis,当用客户端调用getUser接口查询用户信息的时候,getUser接口直接去redis中查询,如果redis中有该用户信息,直接返回,避免查询DB,从而避免了磁盘IO操作;

 

如果redis中没有该用户信息,则从DB查询,并且把该用户信息存放到redis中;这样在服务接口(getUser)和DB中间,增加了一个缓存层;看似逻辑增加了,其实当面对高并发的时候,比如上边提到的频繁查询用户信息的情况,只有第一次查询有磁盘IO操作,以后只要redis中存在就没必要再查询数据库了;由于没有了磁盘IO操作,并且redis所有数据都在内存操作,所以速度回大大提升;

 

我们上面用到的缓存是redis,其实常用的还有memcache等,它们都提供了集群模式,并且都是直接内存操作,所以速度特别快,也是目前业内使用的比较热门的技术;

 

redis相对于memcache提供了更丰富的数据类型,根据不同的业务场景可以选在不同的数据类型;redis本身也提供了主从模式、集群模式;也有第三方的比如codis提供了redis集群解决方案;这次咱们主要聊缓存在架构设计中的作用,等有机会详细介绍redis的使用;

 

总之一句话,要想提高系统的性能,尽量减少IO的操作,特别是磁盘IO的操作;使用缓存可以有效的避免这种情况;所以在架构设计过程中,社交到查询数据库的时候,应该考虑一下是不是考虑使用缓存技术来提高系统的性能,并且降低数据库的负载。

 

 

3、Redis的7个应用场景

一、缓存——热数据

热点数据(经常会被查询,但是不经常被修改或者删除的数据),首选是使用redis缓存,毕竟强大到冒泡的QPS和极强的稳定性不是所有类似工具都有的,而且相比于memcached还提供了丰富的数据类型可以使用,另外,内存中的数据也提供了AOF和RDB等持久化机制可以选择,要冷、热的还是忽冷忽热的都可选。

 

结合具体应用需要注意一下:很多人用spring的AOP来构建redis缓存的自动生产和清除,过程可能如下:

 

Select 数据库前查询redis,有的话使用redis数据,放弃select 数据库,没有的话,select 数据库,然后将数据插入redis

update或者delete数据库钱,查询redis是否存在该数据,存在的话先删除redis中数据,然后再update或者delete数据库中的数据。

 

上面这种操作,如果并发量很小的情况下基本没问题,但是高并发的情况请注意下面场景:

 

为了update先删掉了redis中的该数据,这时候另一个线程执行查询,发现redis中没有,瞬间执行了查询SQL,并且插入到redis中一条数据,回到刚才那个update语句,这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错!于是这个redis中的错误数据就永远的存在了下去,直到下一个update或者delete。

 

二、计数器

诸如统计点击数等应用。由于单线程,可以避免并发问题,保证不会出错,而且100%毫秒级性能!爽。

 

命令:INCRBY

当然爽完了,别忘记持久化,毕竟是redis只是存了内存!

 

三、队列

相当于消息系统,ActiveMQ,RocketMQ等工具类似,但是个人觉得简单用一下还行,如果对于数据一致性要求高的话还是用RocketMQ等专业系统。

由于redis把数据添加到队列是返回添加元素在队列的第几位,所以可以做判断用户是第几个访问这种业务

队列不仅可以把并发请求变成串行,并且还可以做队列或者栈使用

 

四、位操作(大数据处理)

用于数据量上亿的场景下,例如几亿用户系统的签到,去重登录次数统计,某用户是否在线状态等等。

 

想想一下腾讯10亿用户,要几个毫秒内查询到某个用户是否在线,你能怎么做?千万别说给每个用户建立一个key,然后挨个记(你可以算一下需要的内存会很恐怖,而且这种类似的需求很多,腾讯光这个得多花多少钱。。)好吧。这里要用到位操作——使用setbit、getbit、bitcount命令。

 

原理是:redis内构建一个足够长的数组,每个数组元素只能是0和1两个值,然后这个数组的下标index用来表示我们上面例子里面的用户id(必须是数字哈),那么很显然,这个几亿长的大数组就能通过下标和元素值(0和1)来构建一个记忆系统,上面我说的几个场景也就能够实现。用到的命令是:setbit、getbit、bitcount

 

五、分布式锁与单线程机制

验证前端的重复请求(可以自由扩展类似情况),可以通过redis进行过滤:每次请求将request Ip、参数、接口等hash作为key存储redis(幂等性请求),设置多长时间有效期,然后下次请求过来的时候先在redis中检索有没有这个key,进而验证是不是一定时间内过来的重复提交

秒杀系统,基于redis是单线程特征,防止出现数据库“爆破”

全局增量ID生成,类似“秒杀”

 

六、最新列表

例如新闻列表页面最新的新闻列表,如果总数量很大的情况下,尽量不要使用select a from A limit 10这种low货,尝试redis的 LPUSH命令构建List,一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办?也简单,查询不到存储key的话,用mysql查询并且初始化一个List到redis中就好了。

 

七、排行榜

谁得分高谁排名往上。命令:ZADD(有续集,sorted set)

最近在研究股票,发现量化交易是个非常好的办法,通过臆想出来规律,用程序对历史数据进行验证,来判断这个臆想出来的规律是否有效,这玩意真牛!

阅读更多
换一批

没有更多推荐了,返回首页