7.Redis之String编码方式应用场景业务

1.内部编码

字符串类型的内部编码有 3 种：

• int：8 个字节（64位）的⻓整型。

• embstr：⼩于等于 39 个字节的字符串。压缩字符串.适用于表示比较短的字符串。

• raw：⼤于 39 个字节的字符串。普通字符串.适用于表示更长的字符串.只是单纯的持有字节数组。

Redis 会根据当前值的类型和⻓度动态决定使⽤哪种内部编码实现。
整型类型示例如下：

redis 存储储小数,本质上还是当做字符串来存储.这就和整数相比差别很大了
整数直接使用 int 来存 (准确来说是一个 long long(C++)/long (ava))
比较方便进行算术运算的
小数则是使用字符串来存
意味着每次进行算术运算,都需要把字符串转成小数,进行运算,结果再转回字符串保存

2.典型使⽤场景

2.1 作为缓存

整体的思路:
应用服务器访问数据的时候,先查询 Redis.如果 Redis 上数据存在了,就直接从 Redis 取数据交给应用服务器不继续访问数据库了.
如果 Redis 上数据不存在, 再读取 MySQL. 把读到的结果, 返回给应用服务器同时,把这个数据也写入到 Redis 中
Redis 这样的缓存, 经常用来存储"热点"数据（高频被使用的数据.）
热点数据这个定义方式,结合业务场景有很多种方式的.
刚才上述描述的过程,相当于是把最近使用到的数据作为热点数据.
上述策略,存在一个明显的问题:
(暗含了一层假设: 某个数据一旦被用到了,那么很可能在最近这段时间就关被反复用到)
随着时间的推移,肯定是会有越来越多的 key 在 redis 上访问不到
从而从 mysql 读取并写入 redis 了.
此时 redis 中的数据不是就越来越多嘛??
解决方式：
1)在把数据写给 redis 的同时,给这个 key 设置一个|过期时间.
2)Redis 也在内存不足的时候,提供了淘汰策略

2.2 计数功能

许多应⽤都会使⽤ Redis 作为计数的基础⼯具，它可以实现快速计数、查询缓存的功能，同时数据可以异步处理或者落地到其他数据源
例如视频⽹站的视频播放次数可以使⽤Redis 来完成：⽤⼾每播放⼀次视频，相应的视频播放数就会⾃增 1。
实际中要开发一个成熟、稳定的真实计数系统，要面临的挑战远不止如此简单:防作弊、按照不同维度计数、避免单点问题、数据持久化到底层数据源等。

2.3 共享会话

⼀个分布式 Web 服务将⽤⼾的 Session 信息（例如⽤⼾登录信息）保存在各⾃的服务器中，但这样会造成⼀个问题：出于负载均衡的考虑，分布式服务会将⽤⼾的访问请求均衡到不同的服务器上，并且通常⽆法保证⽤⼾每次请求都会被均衡到同⼀台服务器上，这样当⽤⼾刷新⼀次访问是可能会发现需要重新登录，这个问题是⽤⼾⽆法容忍的。

Cookie(浏览器存储数据的机制
Session(服务器这边存储数据的机制)

基于键值对来存储

如果每个应用服务器,维护自己的会话数据,此时彼此之间不共享,用户请求访问到不同的服务器上,就可能会出现一些不能正确处理的情况了~~

升级操作！！！

2.4 手机验证码

很多应⽤出于安全考虑，会在每次进⾏登录时，让⽤⼾输⼊⼿机号并且配合给⼿机发送验证码，然后让⽤⼾再次输⼊收到的验证码并进⾏验证，从⽽确定是否是⽤⼾本⼈。为了短信接⼝不会频繁访问，会限制⽤⼾每分钟获取验证码的频率，例如⼀分钟不能超过 5 次。

1.生成验证码.
用户输入一下手机号 ~~
点击获取验证码~~【限制(1分钟之内,最多获取 5 次验证码（主要还是怕用户频繁获取验证码,对于我们的服务器压力过大~~）或者每次获取验证码必须间隔 30 秒（验证码存在一个有效时间,此处假定是 5 分钟）~~】
2.检查验证码.
把短信收到的验证码这一串数,提交到系统中~~ 系统进行验证验证码是否正确~~