一、Redis数据结构之【字符串】，掌握它的实际应用场景（3）--学以致用

最新推荐文章于 2022-11-21 14:29:56 发布

淼仔爱学习

最新推荐文章于 2022-11-21 14:29:56 发布

阅读量285

点赞数 2

分类专栏： redis

本文链接：https://blog.csdn.net/qq_32317661/article/details/88721306

版权

redis 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

上面几章讲到了字符串结构类型的一些命令和执行效率，本章讲一下字符串结构类型，能使用在哪几种典型的场景中。

一、缓存功能

图2-10是比较典型的缓存使用场景，其中Redis作为缓存层，MySQL作为存储层，绝大部分请求的数据都是从Redis中获取。由于Redis具有支撑高
并发的特性，所以缓存通常能起到加速读写和降低后端压力的作用。
下面伪代码模拟了图2-10的访问过程：

图2-10　Redis + MySQL组成的缓存存储架构

1）该函数用于获取用户的基础信息：
UserInfo getUserInfo(long id)

{ ... }

2）首先从Redis获取用户信息：

// 定义键 userRedisKey = "user:info:" + id;

// 从Redis获取值 value = redis.get(userRedisKey);

if (value != null) {

// 将值进行反序列化为UserInfo并返回结果

userInfo = deserialize(value);

return userInfo;

}

开发提示:
与MySQL等关系型数据库不同的是，Redis没有命令空间，而且也没有
对键名有强制要求（除了不能使用一些特殊字符）。但设计合理的键名，有利于防止键冲突和项目的可维护性，比较推荐的方式是使用“业务名：对象名：id：[属性]”作为键名（也可以不是分号）。例如MySQL的数据库名为 vs，用户表名为user，那么对应的键可以用"vs：user：1"，"vs：user：1： name"来表示，如果当前Redis只被一个业务使用，甚至可以去掉“vs：”。如果键名比较长，例如“user：{uid}：friends：messages：{mid}”，可以在能描述键含义的前提下适当减少键的长度，例如变为“u：{uid}：fr：m： {mid}”，从而减少由于键过长的内存浪费。

3）如果没有从Redis获取到用户信息，需要从MySQL中进行获取，并将结果回写到Redis，添加1小时（3600秒）过期时间：

// 从MySQL获取用户信息

userInfo = mysql.get(id);

// 将userInfo序列化，并存入Redis

redis.setex(userRedisKey, 3600, serialize(userInfo));

// 返回结果

return userInfo
整个功能的伪代码如下：

UserInfo getUserInfo(long id){

userRedisKey = "user:info:" + id ；

value = redis.get(userRedisKey);

UserInfo userInfo;

if (value != null) {

userInfo = deserialize(value);

} else {

userInfo = mysql.get(id);

if (userInfo != null)

redis.setex(userRedisKey, 3600, serialize(userInfo));

}

return userInfo;

}

读到这里，如果你是一个善于思考的、并且有一些开发经验的童鞋，可能会想到一个问题，那就是数据库和redis缓存怎么能保持一致性？为了保持一致性你能想到哪些方式？你的这些方式在某些应用场景下是不是有一些弊端？带着这些问题，看一下这篇文章：https://blog.csdn.net/u012562943/article/details/81482914

--------------------------------------------------------------------------------------

2.计数

许多应用都会使用Redis作为计数的基础工具，它可以实现快速计数、查询缓存的功能，同时数据可以异步落地到其他数据源。例如一个视频播放数系统就是使用Redis作为视频播放数计数的基础组件，用户每播放一次视频，相应的视频播放数就会自增1：
long incrVideoCounter(long id) {

key = "video:playCount:" + id;

return redis.incr(key);

}
开发提示：
实际上一个真实的计数系统要考虑的问题会很多：防作弊、按照不同维度计数，数据持久化到底层数据源等。

--------------------------------------------------------------------------------------

3.共享Session

如图2-11所示，一个分布式Web服务将用户的Session信息（例如用户登录信息）保存在各自服务器中，这样会造成一个问题，出于负载均衡的考虑，分布式服务会将用户的访问均衡到不同服务器上，用户刷新一次访问可能会发现需要重新登录，这个问题是用户无法容忍的。