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）

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