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，客户端进行订阅消费。
我们可根据这个特性，创建实时的聊天系统，系统通知。当然也可以做通讯模型，来规划系统架构。
