文章目录
- 内部编码
- 使用场景
- 缓存功能
- 计数功能
- 共享会话
- 手机验证码
内部编码
字符串类型的内部编码有3种：
- int：8个字节（64位）的⻓整型，存储整数
- embstr：压缩字符串，适用于表示较短的字符串
- raw：普通字符串，适用于表示更长的字符串，内部是一个char类型的数组
Redis会根据当前值的类型和⻓度动态决定使⽤哪种内部编码实现
使用场景
缓存功能
Redis作为缓冲层，MySQL作为存储层，绝⼤部分请求的数据都是从Redis中获取。由于Redis具有⽀撑⾼并发的特性，所以缓存通常能起到加速读写和降低后端压⼒的作⽤
整体的思路：应用服务器访问数据的时候，先查询redis服务器，如果redis服务器上数据存在，那么就直接从redis当中取出数据交给应用服务器，不继续访问数据库
如果redis服务器上数据不存在，那么再读取MySQL，将读取到的结果范围给应用服务器，同时将这个查询到的数据写入到redis当中
伪代码模拟业务数据访问过程
1）假设业务是根据⽤⼾uid获取⽤⼾信息
UserInfo getUserInfo(long uid) {
...
}
2）⾸先从Redis获取⽤⼾信息，我们假设⽤⼾信息保存在user:info:<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;
}
3）如果没有从Redis中得到⽤⼾信息，及缓存miss，则进⼀步从MySQL中获取对应的信息，随后写⼊缓存并返回
// 如果缓存未命中（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;
}
通过增加缓存功能，极⼤地提升了查询效率，也降低了MySQL的访问数
注意：与MySQL等关系型数据库不同的是，Redis没有表、字段这种命名空间，⽽且也没有对键名有强制要求（除了不能使⽤⼀些特殊字符）。但设计合理的键名，有利于防⽌键冲突和项⽬的可维护性
- 推荐的⽅式是使⽤
业务名:对象名:唯⼀标识:属性作为键名 - MySQL的数据库名为vs，⽤⼾表名为user_info，那么对应的键可以使⽤
vs:user_info:6379、vs:user_info:6379:name来表⽰
如果当前Redis只会被⼀个业务使⽤，可以省略业务名"vs:"。如果键名过长，则可以使⽤团队内部都认同的缩写替代，例如"user:6379:friends:messages:5217"可以被"u:6379:fr:m:5217"代替。毕竟键名过⻓，还是会导致Redis的性能明显下降的。
计数功能
许多应⽤都会使⽤Redis作为计数的基础⼯具，它可以实现快速计数、查询缓存的功能，同时数据可以异步处理或者落地到其他数据源，例如视频⽹站的视频播放次数可以使⽤Redis来完成：⽤⼾每播放⼀次视频，相应的视频播放数就会⾃增1
- 注意：写入统计数据仓库的步骤是异步的，并不是说来一个播放请求就必须马上写一个数据，二者并不需要同时完成，只需要最后保证数据正确即可
要开发⼀个成熟、稳定的真实计数系统，要⾯临的挑战远不⽌如此简单：防作弊（防止别人刷播放量），按照不同维度计数、避免单点问题、数据持久化到底层数据源等
共享会话
回顾
cookie：浏览器存储数据的机制 session：服务器这边存储数据的机制
会话：客户端和服务器在交互的过程当中产生的一些专属于该客户端的中间状态的数据
⼀个分布式Web服务将⽤⼾的Session信息（例如⽤⼾登录信息）保存在各⾃的服务器中，但这样会造成⼀个问题：出于负载均衡的考虑，分布式服务会将⽤⼾的访问请求均衡到不同的服务器上，并且通常⽆法保证⽤⼾每次请求都会被均衡到同⼀台服务器上，这样当⽤⼾刷新⼀次访问是可能会发现需要重新登录，这个问题是⽤⼾⽆法容忍的
session分散存储
为了解决这个问题，可以使⽤Redis将⽤⼾的Session信息进⾏集中管理，如图2-13所⽰，在这种模式下，只要保证Redis是⾼可⽤和可扩展性的，⽆论⽤⼾被均衡到哪台Web服务器上，都集中从Redis中查询、更新Session信息
手机验证码
很多应⽤出于安全考虑，会在每次进⾏登录时，让⽤⼾输⼊⼿机号并且配合给⼿机发送验证码，然后让⽤⼾再次输⼊收到的验证码并进⾏验证，从⽽确定是否是⽤⼾本⼈。为了短信接⼝不会频繁访问，会限制⽤⼾每分钟获取验证码的频率，例如⼀分钟不能超过?5?次
伪代码实现上述功能
String 发送验证码(phoneNumber) {
key = "shortMsg:limit:" + phoneNumber;
// 设置过期时间为 1 分钟（60 秒）
// 使⽤ NX，只在不存在 key 时才能设置成功
bool r = Redis 执⾏命令：set key 1 ex 60 nx
if (r == false) {
// 说明之前设置过该⼿机的验证码了
long c = Redis 执⾏命令：incr key
if (c > 5) {
// 说明超过了⼀分钟 5 次的限制了
// 限制发送
return null;
}
}
// 说明要么之前没有设置过⼿机的验证码；要么次数没有超过 5 次
String validationCode = ⽣成随机的 6 位数的验证码();
validationKey = "validation:" + phoneNumber;
// 验证码 5 分钟（300 秒）内有效
Redis 执⾏命令：set validationKey validationCode ex 300;
// 返回验证码，随后通过⼿机短信发送给⽤⼾
return validationCode ;
}
// 验证⽤⼾输⼊的验证码是否正确
bool 验证验证码(phoneNumber, validationCode) {
validationKey = "validation:" + phoneNumber;
String value = Redis 执⾏命令：get validationKey;
if (value == null) {
// 说明没有这个⼿机的验证码记录，验证失败
return false;
}
if (value == validationCode) {
return true;
} else {
return false;
}
}
