Redis基本知识

珂兮

已于 2022-05-24 09:57:52 修改

阅读量376

点赞数

分类专栏： Redis 文章标签： redis 数据库限流

于 2022-05-16 21:43:51 首次发布

本文链接：https://blog.csdn.net/jk19920523/article/details/124725256

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1、介绍Redis默认16个数据库

安装完Redis界面化软件后，打开才发现原来Redis有16个数据库，后面就去查了一下这块的设计思想。

首先，Redis可以在配置问价中修改数据库个数，默认值16；默认我们写数据都是0这个数据库；我们知道，在关系型数据库如MySQL中不同数据库通常存储不同的应用数据，通常我们可以清空某些实例下的所有库数据；而Redis的这些DB更像是命名空间，而存储于不同的应用数据最好使用不同的Redis实例，但是我们可以使用0号数据库存储某个应用生产环境中的数据，使用1号数据库存储测试环境中的数据，方便我们进行隔离调试；同时要特别注意的是以下两个命令的使用：

# 清空一个 redis 实例中的当前 db 中的数据

redis 127.0.0.1:6379> FLUSH

# 清空一个 redis 实例中所有数据库中的数据

redis 127.0.0.1:6379> FLUSHALL

2、限流的方法和思想

从限流的目的，有哪些限流方法，以及如何实现三个方面进行讲解。

由于在现实生活中，会存在大量突发流量涌入应用，比如商品中的秒杀活动，系统的规划能力，最多可以支撑200万访问，那么就要执行限流规则，保证是一个可用的状态，不至于服务器崩溃，所有请求不可用。因此我们就需要对有些流量进行拦截，这个过程就是限流。

常见的限流方法：计数器、漏桶、令牌桶；

2.1 计数器

在一段时间间隔内（时间窗/时间区间），处理请求的最大数量固定，超过部分不做处理。

当在窗口周期内，超过100就进行丢弃；当超过1分钟后，会将count重置；

存在的问题：就是临界时刻，比如第一分钟的第59秒和第二分钟的第一秒同时来了100个请求，则会使系统崩溃；

2.2 漏桶

漏桶大小固定，处理速度固定，但请求进入速度不固定（在突发情况请求过多时，会丢弃过多的请求）。规则如下：

1）入水口，即处理客户端请求，是以任意的速率流入漏桶；

2）漏桶的容量和出水的速率都是固定的；

削峰：有大量流量进入时,会发生溢出,从而限流保护服务可用

缓冲：不至于直接请求到服务器, 缓冲压力

同时消费速度固定因为计算性能固定

2.3 令牌桶

令牌桶的大小固定，令牌的产生速度固定，但是消耗令牌（即请求）速度不固定（可以应对一些某些时间请求过多的情况）；每个请求都会从令牌桶中取出令牌，如果没有令牌则丢弃该次请求。令牌桶算法可以把请求平均分散在时间段内。

规则如下：

1）根据时间，按照一个匀速产生令牌，这里假设是r；

2）事先分配好一个适合容量的令牌数，假设令牌数capicity；

3）根据请求的数量（这里假设是d）取出令牌来使用，如果获取不到令牌的话，就直接触发限速保护策略，往往是直接丢弃；

当前时间t内可以消费的令牌数量为：当前令牌桶剩余的令牌数(这里最大是capicity) + r*t

3、单点应用限流和分布式集群限流

单点应用下，对应用进行限流，既能满足本服务的需求，又可以很好的保护好下游资源。在选型上，可以采用Google Guava的RateLimiter即可。

而在多机部署分布式场景下，需要将限流算法的存储信息全局化，同时需要考虑性能和一致性，可以采用redis+lua的方式，通过把逻辑放在redis端，来减少调用次数。

lua的逻辑如下：
        1）redis中存储剩余令牌的数量cur_token，和上次获取令牌的时间last_time；
        2）在每次申请令牌时，可以根据(当前时间cur_time - last_time)的时间差乘以令牌发放速率，计算出当前可用令牌数；
        3）如果有剩余令牌，则准许请求通过；否则丢弃请求不通过；

限流：计数器、漏桶、令牌桶三大算法的原理与实战（史上最全） - 疯狂创客圈 - 博客园