redis的使用场景

数据缓存

Redis作为缓存层，加速读写和降低后端DB压力。这也是最常用的场景之一了。

不仅仅可以缓存热点数据，也可以缓存页面的 局部page文本 ，甚至在系统对接中的缓存一些固定的报文信息。

• 针对不同的场景，数据特点，使用不同的数据结构类型。
• 指定合适的key管理规范，设置过期时间。
• 针对缓存穿透、缓存雪崩和缓存击穿等问题要提前采用解决方案。不能视而不见。

不同缓存结构特点

原生字符串：每个属性一个键

• 优点：简单直观，每个属性都支持更新操作。
• 缺点：占用过多的键，内存占用量较大，同时用户信息内聚性比较差，所以此种方案一般不会在生产环境使用。

序列化字符串：将用户信息序列化后用一个键保存。

• 优点：简化编程，如果合理的使用序列化可以提高内存的使用效率。
• 缺点：序列化和反序列化有一定的开销，同时每次更新属性都需要把全部数据取出进行反序列化，更新后再序列化到Redis中。

哈希：每个用户属性使用一对field-value，但是只用一个键保存。

• 优点：简单直观，如果使用合理可以减少内存空间的使用。
• 缺点：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多内存。

自增ID

用来处理相关的发号业务，例如分布式业务场景中的的自增ID，短链系统的id发号器等。

计数器

• 动态计数：例如 点赞数，评论数，收藏数，浏览数 等，先存入redis，后持久化到db。
• 静态计数：例如 多维度的数据统计，我们可以将数据统计结果存入 redis，然后前端进行渲染，例如每月，每周，每时的一些动态数据。也或者跨语言取数，例如c++语言通过日志或自定义报文统计定点数据然后将结果存入redis，然后通过php去取数。如果你有elk等一些成熟且部门推荐的技术栈，那也是极好的的。

session共享

分布式结构下，将用户的Session进行集中管理，每次用户更新或查询登陆信息都直接从Redis中获取。

集中式的session管理，不受应用数量影响。很容易实现单点登入登出。

限速或者接口频率访问限制

例如： set u1:100:code 123456 ex 600

验证码，邮件等接口访问频率限制指定描述，防止接口被频繁访问。

也可以用来做简单的api限速（INCR + EXPIRE）

分布式锁

分布式环境，不同的系统或同一个系统的不同主机之间共享了资源时，就需要互斥来防止彼此干扰来保证一致性。

例如单机多进程消费task，布式多任务处理等。

消息队列

redis实现消息队列与专有的MQ消息中间件相比，没有高级特性，ACK保证等。

但在日常的简单业务中，异步处理，应用层解耦，消息通讯，redis都是可以满足。区别也只是看你的衡量指标。

• pub/sub，订阅/发布模式
• 基于stream类型的实现(redis 5.0+)
• lpush+rpop / rpush+lpop / lpush + brpop = Message Queue(消息队列)

当然list还提供其他的场景，自行选择

• lpush + lpop = Stack(栈)
• lpush + rpop = Queue(队列)
• lpush + ltrim = Capped Collection(有限集合)

唯一性数据 统计

利用集合当中元素不唯一性，可以快速实时统计唯一性的数据。例如:统计网站的独立IP。

SADD ip 192.168.1.100 
SADD ip 192.168.1.101
SADD ip 192.168.1.102
SADD ip 192.168.1.100
SADD ip 192.168.1.101


128.127.0.0.1:6379> SMEMBERS ip
1) "192.168.1.100"
2) "192.168.1.102"
3) "192.168.1.101"

交集数据统计

共同好友列表，共同爱好等。例如统计喜欢的编程语言。

sadd u:1 php java golang 
sadd u:2 java php golang
sadd u:3 java php node

127.0.0.1:6379> sinter u:1 u:3
1) "java"
2) "php"

权重排行

有序集合的元素都会关联一个score,所以我们可以将其使用在一些权重场景。

例如排行榜，积分榜。甚至瀑布流，产品推荐，广告排行等。

基数统计

这里的技术统计和上面的唯一性统计是有不同的。

这里的基数统计，是利用Redis 在 2.8.9 版本添加了 HyperLogLog 结构。

• 耗空间极小，支持海量的数据统计。

• 基数统计的结果是一个带有 0.81% 标准错误（standard error）的近似值。

• 每个hyperloglog key占用了12K的内存用于标记基数

• redis 对 HyperLogLog 的存储进行了优化，在计数比较小时，它的存储空间采用稀疏矩阵存储，空间占用很小，仅仅在计数慢慢变大，稀疏矩阵占用空间渐渐超过了阈值时才会一次性转变成稠密矩阵，才会占用 12k 的空间

pfadd access_ip '192.168.1.200' '192.168.1.201' '192.168.1.220' '192.168.1.203'

pfcount access_ip
(integer) 4

地理位置应用

Redis 在 3.2 版本实现了一个地理位置计算的特性。例如测量两个城市的距离。

geoadd cn_city 116.405285 39.904989 beijing
geoadd cn_city 121.472644 31.231706 shanghai

geodist cn_city beijing shanghai km
"1067.5980"

基于地理位置计算redis提供常用的功能，细节可以查看redis文档。

发布/订阅

pub/sub 是 Redis 内置的一个非常强大的特性。

发布订阅模式。改变了以往的pull模型，改为服务端主动push，客户端进行订阅消费。

我们可根据这个特性，创建实时的聊天系统，系统通知。当然也可以做通讯模型，来规划系统架构。