我们所阐明的限制速率的方法是 Redis在高速缓存服务上最基本的功能之一：增加空的键字。在高速缓存服务中实现同样的行为可能最终使用这种方法：
事实上我们最终采取这种策略可以使哨兵追踪不同事件的短期数据。在这种情况下，我们通常对用户数据进行排序以便可以在最短的时间内找到最活跃用户的数据。
基本锁
虽然Redis的是可用性不高，我们的用例锁，使其成为工作的好工具。我们没有使用这些在哨兵的核心了，但一个示例用例是，我们希望尽量减少并发性和简单无操作的操作，如果事情似乎是已经在运行。这对于可能需要执行每隔一段时间类似cron任务非常有用，但不具备较强的协调。
在Redis的这样使用SETNX操作是相当简单的：
而锁()内的哨兵利用的memcached的，但绝对没有理由我们不能在其切换到Redis。 时间序列数据
近来我们创造一个新的机制在Sentry(包含在sentry.tsdb中) 存储时间序列数据。这是受RRD模型启发，特别是Graphite。我们期望一个快速简单的方式存储短期(比如一个月)时间序列数，以便于处理高速写入数据，特别是在极端情况下计算潜在的短期速率。尽管这是第一个模型，我们依旧期望在Redis存储数据，它也是使用计数器的简单范例。
在目前的模型中，我们使用单一的hash map来存储全部时间序列数据。例如，这意味所有数据项在都将同一个哈希键拥有一个数据类型和1秒的生命周期。如下所示：
因此在这种状况，我们需要追踪事件的数目。事件类型映射到枚举类型"1".该判断的时间是1s，因此我们的处理时间需要以秒计。散列最终看起来是这样的：
一个可修改模型可能仅使用简单的键并且仅在存储区上增加一些增量寄存器。
我们选择哈希映射模型基于以下两个原因：
我们可以将所有的键设为一次性的(这也可能产生负面影响，但是目前为止是稳定的)
大幅压缩键值，这是相当重要的处理
此外，离散的数字键允许我们在将虚拟的离散键值映射到固定数目的键值上，并在此分配单一存储区(我们可以使用64，映射到32个物理结点上)
现在通过使用 Nydus和它的map()(依赖于一个工作区)()，数据查询已经完成。这次操作的代码是相当健壮的，但幸好它并不庞大。
归结如下：
生成所必须的键。 使用工作区，提取所有连接操作的最小结果集(Nydus负责这些)。 给出结果，并且基于指定的时间间隔内和给定的键值将它们映射到当前的存储区内。以上就是如何利用Redis实现SQL伸缩的方法，希望对大家的学习有所帮助。
