营销型网站需要备案吗,域名费用和网站服务器费用是同样的吗,dede学校网站,网站设置在哪里找文章目录 内部编码使用场景缓存功能计数功能共享会话手机验证码 内部编码
字符串类型的内部编码有3种#xff1a;
int#xff1a;8个字节#xff08;64位#xff09;的⻓整型#xff0c;存储整数embstr#xff1a;压缩字符串#xff0c;适用于表示较短的字符串raw
int8个字节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 执⾏ SQLselect * from user_info where uid uid// 如果表中没有 uid 对应的⽤⼾信息if (userInfo null) {响应 404return 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 nxif (r false) {// 说明之前设置过该⼿机的验证码了long c Redis 执⾏命令incr keyif (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;}
}
