使用 Redis 实现 SQL 伸缩

我喜欢Redis。这是目前的技术当中唯一让你奇怪为什么需要这么长时间编译它的技术。可预测的，高性能并且适应性强，这是我过去几年

我喜欢Redis。这是目前的技术当中唯一让你奇怪为什么需要这么长时间编译它的技术。可预测的，高性能并且适应性强，这是我过去几年越来越多使用它的原因。Sentry主要在PostgreSQL上运行已经不是秘密（尽管目前它还依赖于一系列其它技术）

 

一个多星期前，我在 Python Nordeste 上作了主题演讲。某种程度上而言我只能作一些快速的总结，我决定去找一些黑客来探讨大量使用Sentry，特别是Redis技术。这篇文章是一个5分钟讨论的扩充。

缓解行之间的争夺

 

我们采用了早在哨兵发展的东西是什么成为著名的sentry.buffers。这是一个简单的系统，使我们能够实现非常有效的缓冲计数器，一个简单的上次写入赢的策略。重要的是要注意，我们完全与此几乎杜绝任何形式的耐用性（这是非常可以接受的哨兵的工作方式）。

该操作是相当简单的，每当一个更新进来，我们做到以下几点：

1.创建绑定到给定实体散列键

2.增量'反'使用HINCRBY

3.HEST各种不同LWW数据（如“最后一次见到”）

4.ZADD散列键到'挂起'使用当前时间戳设置

现在，每个刻度（在哨兵的情况下，这是10秒），我们要转储这些缓冲区和扇出的写入。这看起来像下面这样：

1.开始使用ZRANGE所有键

2. 火了一个作业分成RabbitMQ的每一个悬而未决的关键

3. ZREM给定的键

现在RabbitMQ作业将能够读取和清除哈希表，和“悬而未决”更新已经弹出了一套。有几件事情需要注意：

在下面我们想要只弹出一个设置的数量的例子中我们将使用一组排序(举例来说我们需要那100个旧集合)。

假使我们为了处理一个键值来结束多道排序的作业，这个人会得到no-oped由于另一个已经存在的处理和清空哈希的过程。

我们有了这个处理问题的模型之后，能够确保“大部分情况下”每次在SQL中只有一行能够被马上更新，而这样的处理方式减轻了我们能够预见到的锁问题。考虑到将会处理一个突然产生且所有最终组合在一起进入同一个计数器的数据的场景，这种策略对Sentry用处很多。

速度限制

它的逻辑相当直接，如同下面展示的那般：

def incr_and_check_limit(user_id, limit):

key = '{user_id}:{epoch}'.format(user_id, int(time() / 60))

 

pipe = redis.pipeline()

pipe.incr(key)

pipe.expire(key, 60)

current_rate, _ = pipe.execute()

 

return int(current_rate) > limit

我们所阐明的限制速率的方法是 Redis在高速缓存服务上最基本的功能之一：增加空的键字。在高速缓存服务中实现同样的行为可能最终使用这种方法：

def incr_and_check_limit_memcache(user_id, limit):

key = '{user_id}:{epoch}'.format(user_id, int(time() / 60))

 

if cache.add(key, 0, 60):

return False

 

current_rate = cache.incr(key)

 

return current_rate > limit

事实上我们最终采取这种策略可以使哨兵追踪不同事件的短期数据。在这种情况下，我们通常对用户数据进行排序以便可以在最短的时间内找到最活跃用户的数据。

基本锁

虽然Redis的是可用性不高，我们的用例锁，使其成为工作的好工具。我们没有使用这些在哨兵的核心了，但一个示例用例是，我们希望尽量减少并发性和简单无操作的操作，如果事情似乎是已经在运行。这对于可能需要执行每隔一段时间类似cron任务非常有用，但不具备较强的协调。
在Redis的这样使用SETNX操作是相当简单的：

from contextlib import contextmanagerr = Redis()@contextmanagerdef lock(key, nowait=True):

while not r.setnx(key, '1'):

if nowait:

raise Locked('try again soon!')

sleep(0.01)

 

# limit lock time to 10 seconds r.expire(key, 10)

 

# do something crazy yield

 

# explicitly unlock r.delete(key)

而锁()内的哨兵利用的memcached的，但绝对没有理由我们不能在其切换到Redis。

时间序列数据

近来我们创造一个新的机制在Sentry(包含在sentry.tsdb中)存储时间序列数据。这是受RRD模型启发，特别是Graphite。我们期望一个快速简单的方式存储短期（比如一个月）时间序列数，以便于处理高速写入数据，，特别是在极端情况下计算潜在的短速率。尽管这是第一个模型，我们依旧期望在Redis存储数据，它也是使用计数器的简单范例。

如下所示：

{

"::": {

"":

}}

因此在这种状况，我们需要追踪事件的数目。事件类型映射到枚举类型"1".该判断的时间是1s，因此我们的处理时间需要以秒计。散列最终看起来是这样的：

{

"1:1399958363:0": {

"1": 53,

"2": 72,

}}

一个可修改模型可能仅使用简单的键并且仅在存储区上增加一些增量寄存器。

"1:1399958363:0:1": 53

我们选择哈希映射模型基于以下两个原因：

我们可以将所有的键设为一次性的（这也可能产生负面影响，但是目前为止是稳定的）

大幅压缩键值，这是相当重要的处理

此外，离散的数字键允许我们在将虚拟的离散键值映射到固定数目的键值上，并在此分配单一存储区（我们可以使用64，映射到32个物理结点上）

现在通过使用Nydus和它的map()(依赖于一个工作区)（），数据查询已经完成。这次操作的代码是相当健壮的，但幸好它并不庞大。

def get_range(self, model, keys, start, end, rollup=None):

""" To get a range of data for group ID=[1, 2, 3]: Start and end are both inclusive. >>> now = timezone.now() >>> get_keys(tsdb.models.group, [1, 2, 3], >>> start=now - timedelta(days=1), >>> end=now) """

normalize_to_epoch = self.normalize_to_epoch

normalize_to_rollup = self.normalize_to_rollup

make_key = self.make_key

 

if rollup is None:

rollup = self.get_optimal_rollup(start, end)

 

results = []

timestamp = end

with self.conn.map() as conn:

while timestamp >= start:

real_epoch = normalize_to_epoch(timestamp, rollup)

norm_epoch = normalize_to_rollup(timestamp, rollup)

 

for key in keys:

model_key = self.get_model_key(key)

hash_key = make_key(model, norm_epoch, model_key)

results.append((real_epoch, key, conn.hget(hash_key, model_key)))

 

timestamp = timestamp - timedelta(seconds=rollup)

 

results_by_key = defaultdict(dict)

for epoch, key, count in results:

results_by_key[key][epoch] = int(count or 0)

 

for key, points in results_by_key.iteritems():

results_by_key[key] = sorted(points.items())

return dict(results_by_key)

归结如下：

生成所必须的键。

给出结果，并且基于指定的时间间隔内和给定的键值将它们映射到当前的存储区内。

简单的选择