分布式锁
setnx(set if not exists) 加锁
expire 设置自动释放时间
del 释放
// 这里的冒号:可以换为其他字符
> setnx lock:xxx true OK > expire lock:xxx 5 ... > del lock:xxx (integer) 1
因为setnx与expire不是原子操作，如果在 setnx 和 expire 之间服务器进程突然挂掉了，可能是因为机器掉电或者是被人为杀掉的，就会导致 expire 得不到执行，也会造成死锁。
所以Redis 2.8 版本中加入了 set 指令的扩展参数，使得 setnx 和 expire 指令可以一起执行。
> set lock:xxx true ex 5 nx OK ... > del lock:xxx
超时问题
Redis 的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻辑执行的太长，以至于超出了锁的超时限制，就会出现问题。因为这时候第一个线程持有的锁过期了，临界区的逻辑还没有执行完，这个时候第二个线程就提前重新持有了这把锁，导致临界区代码不能得到严格的串行执行。 为了避免这个问题，Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了，数据出现的小波错乱可能需要人工介入解决。
可重入性
可重入性是指线程在持有锁的情况下再次请求加锁，如果一个锁支持同一个线程的多次加锁，那么这个锁就是可重入的。Redis 分布式锁如果要支持可重入，需要对客户端的 set 方法进行包装，使用线程的 Threadlocal 变量存储当前持有锁的计数。
延时队列
对于那些只有一组消费者的消息队列，使用 Redis 就可以非常轻松的搞定。Redis 的消息队列不是专业的消息队列，它没有非常多的高级特性，没有 ack 保证，如果对消息的可靠性有着极致的追求，那么它就不适合使用。
异步消息队列
Redis 的 list(列表) 数据结构常用来作为异步消息队列使用，使用rpush/lpush操作入队列，使用lpop和rpop来出队列。
队列延迟
通常使用 sleep 来解决队列空的问题，让线程睡一会。
time.sleep(1) # python 睡 1s Thread.sleep(1000) # java 睡 1s
用上面睡眠的办法可以解决问题，但睡眠会导致消息的延迟增大。解决方法是用blpop/brpop，给这两个指令的前缀字符b代表的是blocking，也就是阻塞读。 阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。消息的延迟几乎为零。用blpop/brpop替代前面的lpop/rpop，就完美解决了上面的问题。
如果线程一直阻塞在哪里，Redis 的客户端连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用。这个时候blpop/brpop会抛出异常来。所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。
位图
位图不是特殊的数据结构，它的内容其实就是普通的字符串，也就是 byte 数组。我们可以使用普通的 get/set 直接获取和设置整个位图的内容，也可以使用位图操作 getbit/setbit 等将 byte 数组看成「位数组」来处理。
HyperLogLog
HyperLogLog 数据结构是 Redis 的高级数据结构，提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%。（优势：比set占据的空间少很多）
HyperLogLog 提供了两个指令 pfadd 和 pfcount，根据字面意义很好理解，一个是增加计数，一个是获取计数。pfadd 用法和 set 集合的 sadd 是一样的，来一条数据，就塞进去一条数据。pfcount 和 scard 用法是一样的，直接获取计数值。（pf 是 HyperLogLog 这个数据结构的发明人 Philippe Flajolet 的首字母缩写）
HyperLogLog 除了上面的 pfadd 和 pfcount 之外，还提供了第三个指令 pfmerge，用于将多个 pf 计数值累加在一起形成一个新的 pf 值。
占用空间
在计数比较小时，HyperLogLog的存储空间采用稀疏矩阵存储，空间占用很小，在计数慢慢变大，稀疏矩阵占用空间渐渐超过了阈值时会一次性转变成稠密矩阵，固定占用 12k 字节的空间。
HyperLogLog基本原理
给定一系列的随机整数二进制，低位连续零位的最大长度 k，通过这个 k 值可以估算出随机数的数量。通过这实验可以发现 K 和 随机数个数 N 的对数之间存在显著的线性相关性，即N=2^K。
采用多个 BitKeeper，然后进行加权估计，就可以得到一个比较准确的值。最后计算平均数使用了调和平均 (倒数的平均)。（普通的平均法可能因为个别离群值对平均结果产生较大的影响，调和平均可以有效平滑离群值的影响。）
pf 的内存占用为什么是 12k
Redis 的 HyperLogLog 实现中用到的是 16384 个桶(BitKeeper)，也就是 2^14，每个桶的 maxbits 需要 6 个 bits 来存储，最大可以表示 maxbits=63，于是总共占用内存就是2^14 * 6 / 8 = 12k字节。
布隆过滤器
布隆过滤器可以理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。 当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。（Redis 官方提供的布隆过滤器到了 Redis 4.0 提供了插件功能之后才正式出现）
应用场景举例
新闻客户端推荐新闻场景中，布隆过滤器能准确过滤掉那些已经看过的内容，那些没有看过的新内容，它也会过滤掉极小一部分 (误判)，但是绝大多数新内容它都能准确识别。这样就可以完全保证推荐给用户的内容都是无重复的。
基本命令
布隆过滤器有二个基本指令，bf.add 添加元素，bf.exists 查询元素是否存在，它的用法和 set 集合的 sadd 和 sismember 差不多。注意 bf.add 只能一次添加一个元素，如果想要一次添加多个，就需要用到 bf.madd 指令。同样如果需要一次查询多个元素是否存在，就需要用到 bf.mexists 指令。
127.0.0.1:6379> bf.add xxx user1 (integer) 1 127.0.0.1:6379> bf.exists xxx user1 (integer) 1
自定义参数布隆过滤器
Redis 其实还提供了自定义参数的布隆过滤器，需要我们在 add 之前使用bf.reserve指令显式创建。如果对应的 key 已经存在，bf.reserve会报错。bf.reserve有三个参数，分别是 key, error_rate和initial_size。错误率越低，需要的空间越大。initial_size参数表示预计放入的元素数量，当实际数量超出这个数值时，误判率会上升。 所以需要提前设置一个较大的数值避免超出导致误判率升高。如果不使用 bf.reserve，默认的error_rate是 0.01，默认的initial_size是 100。
布隆过滤器原理
每个布隆过滤器对应到 Redis 的数据结构里面就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都为 1，只要有一个位为 0，那么说明布隆过滤器中这个 key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。
计算布隆过滤器空间占用网站
简单限流
限流应用目的可以用于控制用户行为或是控制流量等。
实现策略：
限流需求中存在一个滑动时间窗口，zset 数据结构的 score 值，可以通过 score 来圈出这个时间窗口。而且只需要保留这个时间窗口，窗口之外的数据都可以砍掉。这个 zset 的 value 只需要保证唯一性即可，用 uuid 会比较浪费空间，可以直接用毫秒时间戳。
用一个 zset 结构记录用户的行为历史，每一个行为都会作为 zset 中的一个 key 保存下来。同一个用户同一种行为用一个 zset 记录。
为节省内存，我们只需要保留时间窗口内的行为记录，同时如果用户是冷用户，滑动时间窗口内的行为是空记录，那么这个 zset 就可以从内存中移除，不再占用空间。
通过统计滑动窗口内的行为数量与阈值 max_count 进行比较就可以得出当前的行为是否允许。
漏斗限流
漏斗的容量是有限的，如果将漏嘴堵住，然后一直往里面灌水，它就会变满，直至再也装不进去。如果将漏嘴放开，水就会往下流，流走一部分之后，就又可以继续往里面灌水。如果漏嘴流水的速率大于灌水的速率，那么漏斗永远都装不满。如果漏嘴流水速率小于灌水的速率，那么一旦漏斗满了，灌水就需要暂停并等待漏斗腾空。
漏斗的剩余空间就代表着当前行为可以持续进行的数量，漏嘴的流水速率代表着系统允许该行为的最大频率。
Redis-Cell
Redis 4.0 提供了一个限流 Redis 模块，它叫 redis-cell。该模块也使用了漏斗算法，并提供了原子的限流指令。该模块只有1条指令cl.throttle,用法:
> cl.throttle xxx:reply 15 30 60 1 ▲ ▲ ▲ ▲ ▲ | | | | └───── need 1 quota (可选参数，默认值也是1) | | └──┴─────── 30 operations / 60 seconds 这是漏水速率 | └───────────── 15 capacity 这是漏斗容量 └─────────────────── key xxx
上面这个指令的意思是允许「用户xxx回复行为」的频率为每 60s 最多 30 次(漏水速率)，漏斗的初始容量为 15，也就是说一开始可以连续回复 15 个帖子，然后才开始受漏水速率的影响。
> cl.throttle xxx:reply 15 30 60 1) (integer) 0 # 0 表示允许，1表示拒绝 2) (integer) 15 # 漏斗容量capacity 3) (integer) 14 # 漏斗剩余空间left_quota 4) (integer) -1 # 如果拒绝了，需要多长时间后再试(漏斗有空间了，单位秒) 5) (integer) 2 # 多长时间后，漏斗完全空出来(left_quota==capacity，单位秒)
在执行限流指令时，如果被拒绝了，就需要丢弃或重试。cl.throttle 指令考虑的非常周到，返回了重试时间，直接取返回结果数组的第四个值进行 sleep 即可，如果不想阻塞线程，也可以异步定时任务来重试。
GeoHash
GeoHash 算法是比较通用的地理位置距离排序算法，Redis 也使用 GeoHash 算法。
GeoHash 算法将二维的经纬度数据映射到一维的整数，这样所有的元素都将在挂载到一条线上，距离靠近的二维坐标映射到一维后的点之间距离也会很接近。当我们想要计算「附近的人时」，首先将目标位置映射到这条线上，然后在这个一维的线上获取附近的点就行了。
这个映射算法具体的流程是将整个地球看成一个二维平面，然后划分成了一系列正方形的方格，就好比围棋棋盘。所有的地图元素坐标都将放置于唯一的方格中。方格越小，坐标越精确。然后对这些方格进行整数编码，越是靠近的方格编码越是接近。
在使用 Redis 进行 Geo 查询时，我们要时刻想到它的内部结构实际上只是一个 zset(skiplist)。通过 zset 的 score 排序就可以得到坐标附近的其它元素 (实际情况要复杂一些，不过这样理解足够了)，通过将 score 还原成坐标值就可以得到元素的原始坐标。
Scan
Redis 提供了一个简单暴力的指令 keys 用来列出所有满足特定正则字符串规则的 key。
这个指令使用非常简单，提供一个简单的正则字符串即可，但是有很明显的两个缺点：
- 没有 offset、limit 参数，一次性吐出所有满足条件的 key，数据量太大一次展示。
- keys 算法是遍历算法，复杂度是 O(n)，如果实例中有千万级以上的 key，这个指令就会导致 Redis 服务卡顿，所有读写 Redis 的其它的指令都会被延后甚至会超时报错，因为 Redis 是单线程程序，顺序执行所有指令，其它指令必须等到当前的 keys 指令执行完了才可以继续。
Redis 为了解决这个问题，它在 2.8 版本中加入了指令—scan。scan 相比 keys 具备有以下特点:
- 复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程;
- 提供 limit 参数，可以控制每次返回结果的最大条数，limit 只是一个 hint，返回的结果可多可少;
- 同 keys 一样，它也提供模式匹配功能;
- 服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;
- 返回的结果可能会有重复，需要客户端去重复，这点非常重要;
- 遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的;
- 单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零。
— —总结自：《Redis深度历险》