[Redis#4] string | 常用命令 | + mysql use：cache

raw ：最基本的形式，类似 Java 中的 byte[] 数组。
int ：当值是整数时，直接用 int 类型存储。
embstr ：当字符串较短时，使用优化的 embstr 存储。
Redis会根据当前值的类型和长度 动态决定****使用哪种内部编码实现

整形

set key 2333
OK
object encoding key
"int"

短字符串

set key "hello"
OK
object encoding key
"embstr"

⼤于39个字节的字符串

set key "one string greater than 39 bytes ........"
OK
object encoding key
"raw

思考：

某个业务场景，有很多很多的 key，类型都是 string，但是每个 value 的 string 长度都是 100 左右。
更关注整体的内存空间。因此，这样的字符串使用 embstr 来存储也不是不能考虑。

上述效果具体怎么实现？

先看 redis 是否提供了对应的配置项，可以修改 39 这个数字。
如果没有提供配置型，就需要针对 redis 源码进行魔改。

为啥很多大厂，往往是自己造轮子，而不是直接使用业界成熟的呢？

开源的组件，往往考虑的是通用性。
但是大厂往往会遇到一些极端的业务场景，
往往就需要根据当前的极端业务，针对上述的开源组件进行定制化。
大厂造轮子，不仅仅是为了 kpi~

之后准备的两个轮子项目：

rpc 框架
raft 源码

String 类型的具体应用场景

缓存功能 ：作为缓存层，提高读写速度，减轻后端数据库压力。
计数功能：实现快速计数，如视频播放次数统计。
共享会话：集中管理用户会话，支持分布式系统。
手机验证码：存储验证码，设置过期时间，确保安全性。

下面将进行详细的介绍

3.应用场景

1. 缓存 (Cache) 功能

Redis+MySQL 组成的缓存存储架构
Redis 作为缓冲层，MySQL 作为存储层，大多数请求的数据从 Redis 中获取。由于 Redis 支持高并发，缓存通常能加速读写并降低后端压力。

模拟业务数据访问过程

根据用户 uid 获取用户信息

UserInfo GetUserInfo(long uid) {
// 根据 uid 得到 Redis 的键
String key = "user:info:" + uid;

  // 尝试从 Redis 中获取对应的值
  String value = Redis 执行命令：get key;

  // 如果缓存命中 (hit)
  if (value != null) {
      // 假设用户信息按照 JSON 格式存储
      UserInfo userInfo = JSON 反序列化 (value);
      return userInfo;
  }

  // 如果缓存未命中 (miss)
  if (value == null) {
      // 从数据库中，根据 uid 获取用户信息
      UserInfo userInfo = MySQL 执行 SQL：select * from user_info where uid = <uid>;

      // 如果表中没有 uid 对应的用户信息
      if (userInfo == null) {
          响应 404;
          return null;
      }

      // 将用户信息序列化成 JSON 格式
      String value = JSON 序列化 (userInfo);

      // 写入缓存，为了防止数据腐烂 (rot)，设置过期时间为 1 小时 (3600 秒)
      Redis 执行命令：set key value ex 3600;

      // 返回用户信息
      return userInfo;
  }

}

注意：

Redis 没有表、字段等命名空间，键名没有强制要求（除了一些特殊字符）。
设计合理的键名 ，有利于防止键冲突和项目的可维护性。推荐使用 "业务名:对象名:唯一标识:属性" 作为键名。
例如：MySQL 的数据库名为 vs，用户表名为 user_info，键名可以是 "vs:user_info:2333" 或 "vs:user_info:2333:name"。
如果当前 Redis 只会被一个业务使用，可以省略业务名，如 "user:2333:friends:messages:6666" 可以被 "u:2333:fr:m:666" 代替。
简写的原因：键名过长会影响 Redis 性能，网络传输需要成本

思考：

Redis 缓存策略

热点数据: 经常用来存储频繁被访问的数据。
缓存定义: 结合业务场景有很多种方式。
把最近使用到的数据作为热点数据。（隐含了一层假设：某个数据一旦被用到了，那么很可能在这段时间就会反复用到）

存在一个明显的问题:

随着时间的推移，肯定会有越来越多的 key 在 redis 上访问不到，从而从 mysql 读取并写入 redis 了。此时 redis 中的数据是不是就越来越多嘛？？

过期时间: 在把数据写给 redis 的同时，给这个 key 设置一个过期时间。详见[Redis#3] 通用命令 | 数据类型 | 内部编码 | 单线程 | 快的原因定时器部分的介绍
淘汰策略: Redis 也在内存不足的时候，提供了淘汰策略。（后面再说）

2. 计数 (Counter) 功能

应用场景 ：许多应用使用 Redis 作为计数的基础工具，实现快速计数、查询缓存，数据可以异步处理或落地到其他数据源。

示例：统计视频播放次数

long IncrVideoCounter(long vid) {
    String key = "video:" + vid;
    long count = Redis 执行命令：incr key;
    return count;
}

注意：实际开发一个成熟、稳定的计数系统面临更多挑战，如防作弊、按不同维度计数、避免单点问题、数据持久化到底层数据源等。
根据实际的业务需求设计场景

3. 共享会话 (Session)

背景：++分布式 Web 服务将用户的 Session 信息保存在各自的服务器中，负载均衡导致用户请求可能被分配到不同的服务器，造成用户需要重新登录的问题。++

生活中举例：

Cookie: 浏览器存储数据的机制。
Session: 服务器存储数据的机制。

实际案例：医院就诊

初次就诊:

- 我生病了，声带发炎，发烧到完全说不出话。
- 到医院挂号，挂了个专家号。
- 医生开了雾化理疗，先开了一周的药量，并建议一周后再来复查。

复查:

- 一周后去复查，发现初诊的医生不在。
- 新的医生之前没有给我看过病，不了解我的情况。
- 新医生通过刷我的就诊卡，看到了我之前的病例和治疗情况。

类比说明

病人：相当于客户端。
医生：相当于服务器。
就诊卡：相当于会话标识（如 Session ID）。

会话的概念

会话：客户端和服务端在交互过程中产生的专属于该客户端的中间状态数据。
目的：确保服务器能够识别和记住客户端的多次访问状态。

多服务器环境

多个医生：多个服务器。
负载均衡：服务器以负载均衡的方式提供服务。
问题：同一个客户端多次访问可能遇到不同的服务器。
解决方案：

- 共享会话数据 ：就诊卡的使用，需要存在：使用一套系统记录客户端的会话数据，让多个服务器共享这些数据。

会话管理的重要性

一致性：确保客户端在多次访问中的一致性体验。
数据共享：多个服务器之间共享会话数据，避免因服务器切换导致的信息丢失。

解决方案

使用 Redis 集中管理 Session 信息，确保无论用户被均衡到哪台 Web 服务器上，都能从 Redis 中查询和更新 Session 信息。

4. 示例：手机验证码

用户在登录的时候,为了保证用户账号的安全,我们会使用验证码.
当用户登录的时候,redis就会在服务器中保存一个与用户对应的验证码,这个验证码具有过期时间(比如在5分钟内有效).
在用户输入验证码之后,会从redis中查询对应的键值对,校验用户的验证码.
当然为了用户反复接收验证码,导致redis压力过大,一般规定在一分钟之内,最多接收一次验证码,如果手机没有验证码,可以尝试在一分钟之后重新获取验证码.

此功能可以⽤以下伪代码说明基本实现思路：

String SendCapcha(String phoneNumber) {
    String key = "shortMsg:limit:" + phoneNumber;

    // 设置过期时间为 1 分钟
    // 使用 NX，只在不存在 key 时才能设置成功
    bool r = Redis 执行命令：set key ex 60 nx;
    if (r == false) {
        // 说明之前设置过该手机的验证码了
        long c = Redis 执行命令：incr key;
        if (c > 5) {
            // 说明超过一分钟 5 次的限制了
            // 限制发送
            return null;
        }
    }

    // 说明要么之前没有设置过手机的验证码；要么次数没有超过 5 次
    String validationCode = 生成随机的 6 位数的验证码();

    String validationKey = "validation:" + phoneNumber;
    // 验证码 5 分钟内有效
    Redis 执行命令：set validationKey validationCode ex 300;

    // 返回验证码，随后通过手机短信发送给用户
    return validationCode;
}

// 验证用户输入的验证码是否正确
bool VerifyCode(String phoneNumber, String validationCode) {
    String validationKey = "validation:" + phoneNumber;

    String value = Redis 执行命令：get validationKey;
    if (value == null) {
        // 说明没有这个手机的验证码记录，验证失败
        return false;
    }

    if (value.equals(validationCode)) {
        return true;
    } else {
        return false;
    }
}

[Redis#4] string | 常用命令 | + mysql use：cache | session

1.前言

1. 基本概念

2. string 存储方式

3. 支持的数据类型

4. 与 MySQL 的对比

5. 性能考虑

2.命令

1. 通用命令

1.1 字符串的存储方式

1.2 常见命令

set

get

mset

mget

setnx

setex

数字操作

incr

incrby

decr

decrby

incrbyfloat

append

getrange

setrange

strlen

命令小结

String 的内部编码方式

整形

短字符串

⼤于39个字节的字符串