緩解行競爭

我們在Sentry開發的早起采用的是sentry.buffers。 這是一個簡單的系統，它允許我們以簡單的Last Write Wins策略來實現非常有效的緩沖計數器。 重要的是，我們借助它完全消除了任何形式的耐久性 (這是Sentry工作的一個非?？山邮艿姆绞?。

操作非常簡單，每當一個更新進來我們就做如下幾步：

•     創建一個綁定到傳入實體的哈希鍵(hash key)
•     使用HINCRBY使計數器值增加
•     HSET所有的LWW數據(比如 "最后一次見到的")
•     用當前時間戳ZADD哈希鍵(hash key)到一個"掛起" set

現在每一個時間刻度 (在Sentry中為10秒鐘) 我們要轉儲(dump)這些緩沖區并且扇出寫道(fanout the writes)。 看起來像下面這樣:

•     使用ZRANGE獲取所有的key
•     為每一個掛起的key發起一個作業到RabbitMQ

現在RabbitMQ作業將能夠讀取和清除哈希表，和“懸而未決”更新已經彈出了一套。有幾件事情需要注意：

•     在下面我們想要只彈出一個設置的數量的例子中我們將使用一組排序(舉例來說我們需要那100個舊集合)。
•     假使我們為了處理一個鍵值來結束多道排序的作業，這個人會得到no-oped由于另一個已經存在的處理和清空哈希的過程。
•     該系統能夠在許多Redis節點上不斷擴展下去僅僅是通過在每個節點上安置把一個'懸置'主鍵來實現。

我們有了這個處理問題的模型之后，能夠確?！按蟛糠智闆r下”每次在SQL中只有一行能夠被馬上更新，而這樣的處理方式減輕了我們能夠預見到的鎖問題。考慮到將會處理一個突然產生且所有最終組合在一起進入同一個計數器的數據的場景，這種策略對Sentry用處很多。

速度限制

出于哨兵的局限性，我們必須終結持續的拒絕服務攻擊。我們通過限制連接速度來應對這種問題，其中一項是通過Redis支持的。這無疑是在sentry.quotas范圍內更直接的實現。

它的邏輯相當直接，如同下面展示的那般：

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存儲數據，它也是使用計數器的簡單范例。

在目前的模型中，我們使用單一的hash map來存儲全部時間序列數據。例如，這意味所有數據項在都將同一個哈希鍵擁有一個數據類型和1秒的生命周期。如下所示：

因此在這種狀況，我們需要追蹤事件的數目。事件類型映射到枚舉類型"1".該判斷的時間是1s，因此我們的處理時間需要以秒計。散列最終看起來是這樣的：

一個可修改模型可能僅使用簡單的鍵并且僅在存儲區上增加一些增量寄存器。

我們選擇哈希映射模型基于以下兩個原因：

1.     我們可以將所有的鍵設為一次性的（這也可能產生負面影響，但是目前為止是穩定的）
2.     大幅壓縮鍵值，這是相當重要的處理

此外，離散的數字鍵允許我們在將虛擬的離散鍵值映射到固定數目的鍵值上，并在此分配單一存儲區（我們可以使用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)

歸結如下：

•     生成所必須的鍵。
•     使用工作區，提取所有連接操作的最小結果集（Nydus負責這些）。
•     給出結果，并且基于指定的時間間隔內和給定的鍵值將它們映射到當前的存儲區內。

簡單的選擇

我是一個喜歡用簡單的方案解決問題的人，在這個范疇里使用Redis無疑是很適合的。它的文檔是那樣讓人驚訝，那是因為（閱讀）其文檔的門檻非常的低。雖然他也有折衷（主要是如果你使用持久化），但是他們工作地很好并且比較直觀。

那么Redis為您解決什么問題呢？