Redis（CentOS)

最新推荐文章于 2024-06-04 11:23:55 发布

芋泥*

最新推荐文章于 2024-06-04 11:23:55 发布

阅读量678

点赞数

分类专栏： JavaEE 文章标签： redis centos python

本文链接：https://blog.csdn.net/qq_53869058/article/details/132192778

版权

JavaEE 专栏收录该内容

35 篇文章 0 订阅

订阅专栏

6379默认端口号
命令大全：
https://redis.io/commands/set/

安装与开启

#使⽤yum安装Redis
yum -y install redis

#查看是否启动
ps -ef|grep redis
    
#启动redis:
redis-server /etc/redis.conf &
    
#停⽌Redis
redis-cli shutdown
    
#或者直接杀掉进程(kill -9 强制杀掉, kill -15优雅退出)
kill -9 PID

操作Redis

redis-cli

（存放一个key，获取key）

开启隧道

Xshell 配置隧道

全部配置之后, 需要重新关闭连接, 打开连接才可以
后续访问云服务器的Redis, 就可以使⽤ 127.0.0.1 6379端⼝号(上图中配置的端⼝号) 来访问

可视化客户端连接

如果报Stream On Error: NOAUTH Authentication required.错误，把密码填上（123456）

开启防⽕墙

#开启防火墙
systemctl start firewalld 

//查询已开放的端⼝
firewall-cmd --zone=public --list-ports
    
//如果没有6379, 则开启
firewall-cmd --add-port=6379/tcp --permanent
    
//重载⼊添加的端⼝
firewall-cmd --reload

Redis 常⻅数据类型

– string 字符串
– hash 哈希
– list 列表
– set 集合
– zset 有序集合

Redis 有 5 种数据结构，但它们都是键值对种的值，对于键来说有⼀些通⽤的命令。

set 一个存在的key会把之前的key对应的value覆盖

KEYS

返回所有满⾜样式（pattern）的 key。⽀持如下统配样式。
语法：KEYS pattern

h?llo 匹配 hello, hallo 和 hxllo
h*llo 匹配 hllo 和heeeello
h[ae]llo 匹配hello 和hallo 但不匹配 hillo
h[^e]llo 匹配hallo, hbllo, ... 但不匹配 hello
h[a-b]llo 匹配hallo 和 hbllo

EXISTS

判断某个 key 是否存在。
语法：EXISTS key [key …]

DEL

删除指定的 key

EXPIRE

为指定的 key 添加秒级的过期时间（Time To Live TTL）

TTL

获取指定 key 的过期时间，秒级。

-1表示没有设置有效期，-2表示过期了

TYPE

返回 key 对应的数据类型。

数据结构

type 命令实际返回的就是当前键的数据结构类型

string（字符串）
list（列表）
hash（哈希）
set（集合）
zset（有序集合）

SpringBoot 集成Redis

添加Redis依赖

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

或者

配置

#数据库索引
spring.redis.database=1
#端⼝号
spring.redis.port=6379
#IP
spring.redis.host=43.143.223.50
#连接池最⼩空闲连接数
spring.redis.lettuce.pool.min-idle=5
#连接池最⼤空闲连接数
spring.redis.lettuce.pool.max-idle=10
#连接池最⼤连接数
spring.redis.lettuce.pool.max-active=8
#最⼤等待时间
spring.redis.lettuce.pool.max-wait=1ms
#关闭超时时间
#spring.redis.lettuce.shutdown-timeout=100ms

spring:
 redis:
 	database: 1
 	port: 6379
 	host: 139.159.150.152
    password: 123456
 	lettuce:
 		pool:
     		min-idle: 5
     		max-idle: 10
     		max-active: 8
     		max-wait: 1ms

操作string

@RequestMapping("/redis")
@RestController
public class RedisController {

    @Autowired
    private RedisTemplate stringRedisTemplate;

    @RequestMapping("/setStr")
    public String setStr(String key,String value){
        if (!StringUtils.hasLength(key) || !StringUtils.hasLength(value)){
            return "failed";
        }
        stringRedisTemplate.opsForValue().set(key,value);
        //hash
        stringRedisTemplate.opsForHash().put("hashKey","k1","v1");
        stringRedisTemplate.opsForHash().put("hashKey","k2","v2");
        //list
        stringRedisTemplate.opsForList().leftPush("listKey","l1");
        stringRedisTemplate.opsForList().leftPush("listKey","l2");

        //set
        stringRedisTemplate.opsForSet().add("setKey","s1","s2","s3");
        //zset
        stringRedisTemplate.opsForZSet().add("zsetKey","z1",80);
        stringRedisTemplate.opsForZSet().add("zsetKey","z2",90);
        stringRedisTemplate.opsForZSet().add("zsetKey","z3",10);

        return "success";
    }
}

Spring Session 持久化

Http协议是⽆状态的，这样对于服务端来说，没有办法区分是新的访客还是旧的访客。但是，有些业务场景，需要追踪⽤户多个请求，此时就需要Session.
⼀个Web应⽤, 可能部署在不同的服务器上, 通过Nginx等进⾏负载均衡. 此时, 来⾃同⼀个⽤户的Http请求就会被分发到不同的服务器上. 这样就会出现Session信息不同步的问题. 当⽤户刷新⼀次访问是可能会发现需要重新登录，这个问题是⽤户⽆法容忍的
为了解决这个问题，可以使⽤ Redis 将⽤户的 Session 信息进⾏集中管理，如下图所示，在这种模式下，只要保证 Redis 是⾼可⽤和可扩展性的，⽆论⽤户被均衡到哪台 Web 服务器上，都集中从 Redis 中查询、更新 Session 信息。

添加依赖

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
 <groupId>org.springframework.session</groupId>
 <artifactId>spring-session-data-redis</artifactId>
</dependency>

配置

spring:
  redis:
    database: 0
    port: 6379
    host: 127.0.0.1
    password: 123456
  session:
    store-type: redis
    redis:
      flush-mode: on_save
      namespace: spring:session
server:
  servlet:
    session:
      timeout: 30m

操作

@RequestMapping("/session")
@RestController
public class SessionController {
    @RequestMapping("/login")
    public String login(String name, Integer age, HttpSession session) throws JsonProcessingException {
        //模拟,不登录, 只存session
        User user = new User();
        user.setName(name);
        user.setAge(age);
        ObjectMapper mapper = new ObjectMapper();
        session.setAttribute("user_session",mapper.writeValueAsString(user));
        return "success";
    }

    @RequestMapping("/getSess")
    public String getSess(HttpServletRequest request){
        HttpSession session = request.getSession(false);
        if (session!=null && session.getAttribute("user_session")!=null){
            return (String) session.getAttribute("user_session");
        }
        return null;
    }

}
@Data
class User{
    private String name;
    private Integer age;
}

运行，观察Session存储结果

⽤前缀配置来⾃于spring配置项: spring.session.redis.namespace
spring:session:sessions:expires+sessionId 对应⼀个空值, 判断session是否存在
spring:session:sessions: sessionId: 对应⼀个hash数据结构, 存储session相关的属性, 包括有效期, 创建时间等

lastAccessedTime: 系统字段-最后访问时间
maxInactiveInterval: 系统字段-session失效的间隔时⻓
sessionAttr:session_user_key: ⽤户存⼊session中的数据
creationTime: 系统字段-创建时间
spring:session:expirations+时间戳(过期时间): 对应的是⼀个set数据结构. 存储待
过期的sessionid列表

Redis 典型应⽤ - 缓存(cache)

缓存 (cache) 是计算机中的⼀个经典的概念. 在很多场景中都会涉及到.
核⼼思路就是把⼀些常⽤的数据放到触⼿可及(访问速度更快)的地⽅, ⽅便随时读取.

使⽤Redis 做缓存

在⼀个⽹站中, 我们经常会使⽤关系型数据库 (⽐如 MySQL) 来存储数据.
关系型数据库虽然功能强⼤, 但是有⼀个很⼤的缺陷, 就是性能不⾼. (换⽽⾔之, 进⾏⼀次查询操作消耗的系统资源较多).

为什么说关系型数据库性能不⾼?

数据库把数据存储在硬盘上, 硬盘的 IO 速度并不快. 尤其是随机访问.
如果查询不能命中索引, 就需要进⾏表的遍历, 这就会⼤⼤增加硬盘 IO 次数.
关系型数据库对于 SQL 的执⾏会做⼀系列的解析, 校验, 优化⼯作.
如果是⼀些复杂查询, ⽐如联合查询, 需要进⾏笛卡尔积操作, 效率更是降低很多

因此, 如果访问数据库的并发量⽐较⾼, 对于数据库的压⼒是很⼤的, 很容易就会使数据库服务器宕机.

为什么并发量⾼了就会宕机?
服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的. 所谓的硬件资源包括
不限于 CPU, 内存, 硬盘, ⽹络带宽…
⼀个服务器的硬件资源本身是有限的. ⼀个请求消耗⼀份资源, 请求多了, ⾃然把
资源就耗尽了. 后续的请求没有资源可⽤, ⾃然就⽆法正确处理. 更严重的还会导
致服务器程序的代码出现崩溃

如何让数据库能够承担更⼤的并发量呢? 核⼼思路主要是两个:

开源: 引⼊更多的机器, 部署更多的数据库实例, 构成数据库集群. (主从复制, 分库分表等…)
节流: 引⼊缓存, 使⽤其他的⽅式保存经常访问的热点数据, 从⽽降低直接访问数据库的请求数量.

实际开发中, 这两种⽅案往往是会搭配使⽤的.
Redis 就是⼀个⽤来作为数据库缓存的常⻅⽅案.
Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系
统资源⽐ MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤.

Redis 数据在内存中, 访问内存⽐硬盘快很多.
Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则.

Redis 就是⼀个⽤来作为数据库缓存的常⻅⽅案.
Redis 访问速度⽐ MySQL 快很多. 或者说处理同⼀个访问请求, Redis 消耗的系
统资源⽐ MySQL 少很多. 因此 Redis 能⽀持的并发量更⼤.

Redis 数据在内存中, 访问内存⽐硬盘快很多.
Redis 只是⽀持简单的 key-value 存储, 不涉及复杂查询的那么多限制规则.

客户端访问业务服务器, 发起查询请求.

业务服务器先查询 Redis, 看想要的数据是否在 Redis 中存在.
如果已经在 Redis 中存在了, 就直接返回. 此时不必访问 MySQL 了.
如果在 Redis 中不存在, 再查询 MySQL, 同时存在保存在Redis中

缓存穿透, 缓存雪崩和缓存击穿

缓存穿透 (Cache penetration)

什么是缓存穿透?
访问的 key 在 Redis 和数据库中都不存在. 此时这样的 key 不会被放到缓存上, 后续如果仍然在访问该 key, 依然会访问到数据库.
这就会导致数据库承担的请求太多, 压⼒很⼤.
这种情况称为缓存穿透.
为何产⽣?
原因可能有⼏种:
● 业务设计不合理. ⽐如缺少必要的参数校验环节, 导致⾮法的 key 也被进⾏查询了.
● 开发/运维误操作. 不⼩⼼把部分数据从数据库上误删了.
● ⿊客恶意攻击.
如何解决?
● 针对要查询的参数进⾏严格的合法性校验. ⽐如要查询的 key 是⽤户的⼿机号, 那么就需要校验当前 key 是否满⾜⼀个合法的⼿机号的格式.
● 针对数据库上也不存在的 key , 也存储到 Redis 中, ⽐如 value 就随便设成⼀个 “”. 避免后续频繁访问数据库.
● 使⽤布隆过滤器先判定 key 是否存在, 再真正查询.

关于缓存雪崩 (Cache avalanche)

什么是缓存雪崩
短时间内⼤量的 key 在缓存上失效, 导致数据库压⼒骤增, 甚⾄直接宕机.
15本来 Redis 是 MySQL 的⼀个护盾, 帮 MySQL 抵挡了很多外部的压⼒. ⼀旦护盾突然失效了, MySQL ⾃身承担的压⼒骤增, 就可能直接崩溃.
为何产⽣?
⼤规模 key 失效, 可能性主要有两种:
● Redis 挂了.
● Redis 上的⼤量的 key 同时过期.
为啥会出现⼤量的 key 同时过期?
这种和可能是短时间内在 Redis 上缓存了⼤量的 key, 并且设定了相同的过期时间.
如何解决?
● 部署⾼可⽤的 Redis 集群, 并且完善监控报警体系.
● 不给 key 设置过期时间或者设置过期时间的时候添加随机时间因⼦.