為了能夠讓大家更好的學習Redis，今天武林技術頻道的小編就教各位如何使用Redis實現SQL伸縮，在本文里還包括講到了鎖和時間序列等方面來提升傳統數據庫的性能，很值得收藏，需要的朋友趕緊來參考參考吧。
緩解行競爭
我們在Sentry開發的早起采用的是sentry.buffers。 這是一個簡單的系統，它允許我們以簡單的Last Write Wins策略來實現非常有效的緩沖計數器。 重要的是，我們借助它完全消除了任何形式的耐久性 (這是Sentry工作的一個非?？山邮艿姆绞?。
操作非常簡單，每當一個更新進來我們就做如下幾步：
現在每一個時間刻度 (在Sentry中為10秒鐘) 我們要轉儲(dump)這些緩沖區并且扇出寫道(fanout the writes)。 看起來像下面這樣:
?
現在RabbitMQ作業將能夠讀取和清除哈希表，和“懸而未決”更新已經彈出了一套。有幾件事情需要注意：
我們有了這個處理問題的模型之后，能夠確?！按蟛糠智闆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，因此我們的處理時間需要以秒計。散列最終看起來是這樣的：
?
一個可修改模型可能僅使用簡單的鍵并且僅在存儲區上增加一些增量寄存器。
??
?
我們選擇哈希映射模型基于以下兩個原因：
此外，離散的數字鍵允許我們在將虛擬的離散鍵值映射到固定數目的鍵值上，并在此分配單一存儲區（我們可以使用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)
歸結如下：
簡單的選擇
我是一個喜歡用簡單的方案解決問題的人，在這個范疇里使用Redis無疑是很適合的。它的文檔是那樣讓人驚訝，那是因為（閱讀）其文檔的門檻非常的低。雖然他也有折衷（主要是如果你使用持久化），但是他們工作地很好并且比較直觀。
那么Redis為您解決什么問題呢？如果大家想了解更多相關內容，請持續關注本站，本站小編將在第一時間為大家帶來更好的經典內容。
新聞熱點
疑難解答
圖片精選
