2024年软件测试最新Web 功能测试下的 Redis缓存数据库_redis缓存数据怎么测试，【秋招面试专题解析】

最新推荐文章于 2024-05-09 20:20:32 发布

asdakdnfh

最新推荐文章于 2024-05-09 20:20:32 发布

阅读量342

点赞数 3

分类专栏：程序员文章标签：缓存数据库功能测试

本文链接：https://blog.csdn.net/asdakdnfh/article/details/138604640

版权

程序员专栏收录该内容

126 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

可以持久化特定数据。

利用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把数据添加到队列是返回添加元素在队列的第几位，所以可以做判断用户是第几个访问这种业务

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

四、位操作（大数据处理）

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