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.检查验证码.
  把短信收到的验证码这一串数,提交到系统中~~ 系统进行验证验证码是否正确~~

3.业务 

• 业务其实就是一个公司/一个产品,是如何解决一个/一系列问题的~~
• 解决问题的过程,就可以称为是"业务"
• 一个公司/产品要想生存，要想赚钱, 就得能帮别人解决问题!
• 不同的公司, 不同的产品,有不同的业务~~
  不同的业务就需要不同的技术作为支撑!!
• 业务是非常重要的!!
  很多时候,优化技术解决不了的问题,可以通过优化业务来解决~~
• 实际开发过程中,必须要结合实际业务场景,做一些技术上的调整~~