场景一：类似于微博，实现关注和被关注功能。
思路：
对每个用户使用两个集合类型键，用来存储关注别人的用户和被该用户关注的用户。当用户A关注用户B的时候，执行两步操作：
sadd user:A B
sadd user:B A
问题1：
完成一次用户关注操作，需要执行两步代码，第一次实现用户A关注B，成为了B的粉丝。而第二步的时候，因为某种原因没有执行或执行成功，则A并不知道B关注了自己
事务：
事务的原理是，先将一个事务的命令发送给Redis，然后再让Redis依次执行这些命令。
一个事务中，要么都执行成功，要么都不执行
multi命令告诉redis准备介绍事务，先暂存起来，不要执行。然后发送需要一起执行的命令，最后exec结束事务，redis依次执行那么命令
如果在执行exec命令之前，因为某种原因，redis断掉了，Redis会清空事务队列.
问题2：
有些时候，我们不仅需要通过事务来处理一些必须一起成功的动作，比如银行转账，从银行卡1转出钱到银行卡2，必须是都一起成功，不能说从银行卡1中扣完钱之后，没有进到银行卡2账上，两者动作比如都要完成。还有些时候，我们既要一起完成，也需要根据其中一步操作的结果来进行下一步操作
WATCH命令
watch，事务中的另一个命令。监控一个或多个键，一旦其中一个键被修改或删除，之后的事务就不会执行，一直到exec结束。
通过watch监控key1，之后修改了key1，所以事务中的set命令并没有执行
场景二：限时活动，缓存，验证码失效
在实际开发中，经常会遇到限时活动，邮箱失效时间，验证码失效时间等场景，这些数据需要在一定的时间内有效，过期删除，如果在关系型数据库中保存这些数据，每次校验都需要查询数据，对比时间，然后将数据置为失效，或者删除。而在Redis中，则可以通过expire设置失效时间，自动删除。
expire设置失效时间，时间单位秒。成功返回1，如果key不存在返回0
当 key 不存在时，返回 -2 。 当 key 存在但没有设置剩余生存时间时，返回 -1 。
注意：在 Redis 2.8 以前，当 key 不存在，或者 key 没有设置剩余生存时间时，命令都返回 -1
实现缓存
为了提供网站的负载能力，需要将一个访问频路较高，且经过复杂计算或者IO资源消耗较大的操作的结果缓存起来，并设置一个失效时间。每次用户访问的时候，先检查该键是否存在，如果存在直接获取该元素并返回，如果不存在，则经过一系列计算并将结果缓存，设置失效时间，在返回给用户
问题：
这种缓存的实现，显然会有两个问题，第一个是缓存都是存在内容中的，如果大量的使用缓存会导致Redis沾满内存，另一方面，为了防止Redis沾满内存而设置失效时间的键，如果设置时间太短，就可能导致缓存命中率过低并且大量内容白白浪费。
使用方式：
在开发中，很难合理的设置键的生存时间，所以可以限制Redis使用的最大内存，并让Redis按照一定规则删除一些不需要的键。
具体方式，修改配置文件的maxmemory参数
OS X下通过Homebrew安装的redis的话，配置文件在/usr/local/etc/redis.conf
限制Redis最大内存之后，当超出了这个内存，会根据maxmemory-policy
指定的参数删除不需要的键。当设置此参数为allkeys-lru，一旦Redis内存超过了限制值时，Redis会不断删除数据库中最近最少使用的键，直到满足了当前内存大小限制