1.缓存功能

典型的缓存使用场景，其中Redis作为缓存层，MySQL作 为存储层，绝大部分请求的数据都是从Redis中获取。由于Redis具有支撑高

并发的特性，所以缓存通常能起到加速读写和降低后端压力的作用。

三种方法缓存用户信息，下面给出三种方案的实现方法和优缺点分析

1）原生字符串类型：每个属性一个键。

set user:1:name tom set user:1:age 23 set user:1:city beijing

优点：简单直观，每个属性都支持更新操作。

缺点：占用过多的键，内存占用量较大，同时用户信息内聚性比较差，

所以此种方案一般不会在生产环境使用。

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

set user:1 serialize(userInfo)

优点：简化编程，如果合理的使用序列化可以提高内存的使用效率。

缺点：序列化和反序列化有一定的开销，同时每次更新属性都需要把全 部数据取出进行反序列化，更新后再序列化到Redis中。

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

hmset user:1 name tomage 23 city beijing

优点：简单直观，如果使用合理可以减少内存空间的使用。

缺点：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多内存。

2.计数

许多应用都会使用Redis作为计数的基础工具，它可以实现快速计数、查询缓存的功能，同时数据可以异步落地到其他数据源。例如笔者所在团队 的视频播放数系统就是使用Redis作为视频播放数计数的基础组件，用户每 播放一次视频，相应的视频播放数就会自增1：

实际上一个真实的计数系统要考虑的问题会很多：防作弊、按照不同维度计数，数据持久化到底层数据源

3.共享Session

一个分布式Web服务将用户的Session信息（例如用户登录信息）保存在各自服务器中，这样会造成一个问题，出于负载均衡的考虑，分布式服务会将用户的访问均衡到不同服务器上，用户刷新一次访问可能会发现需要重新登录，这个问题是用户无法容忍的

4.限速

很多应用出于安全的考虑，会在每次进行登录时，让用户输入手机验证码，从而确定是否是用户本人。但是为了短信接口不被频繁访问，会限制用 户每分钟获取验证码的频率，例如一分钟不能超过5次

phoneNum = "138xxxxxxxx";

key = "shortMsg:limit:" + phoneNum;

// SET key value EX 60 NX

isExists = redis.set(key,1,"EX 60","NX");

if(isExists != null || redis.incr(key) <=5)

{    // 通过

}else{   

// 限速 }

例如一些网站限制一个IP地址不 能在一秒钟之内访问超过n次也可以采用类似的思路。

应用场景：

 缓存—数据的查询，新闻和商品的查询等，聊天室的在线好友列表

 任务对列

 应用排行榜

 网站访问统计

 数据过期处理

 分布式集群架构中的session分离