Clever Geek Handbook

Redis：りんご

通常、NoSQLはリレーショナルデータベースの代替として認識されていますが、それらの多く、特に単純なデータベースは、置換するだけでなく、完全に補完することもできます。 実際、通常のデータベースではなく、ある種のNoSQLソリューションを使用するには、新しいプロジェクト、または古いプロジェクトをほぼ完全に書き換える機能が必要です。 日常の開発におけるまれなケース。 同時に、多くのぶら下がりの果物を簡単に選ぶことができます。



Redisについて説明します。これは、優れているため、あらゆる種類の便利な構造をサポートしているからです。 実際のプロジェクトで使用している私の助けを借りて、私の生活を楽にするいくつかのオプションについてお話します。



キーは価値



大根ベース、memcachedを置き換えるために使用できます。 キャッシュ、セッションなど 多くの場合、永続性は場違いです：長時間にわたるキャッシュ、セッション。 しかし、これはあまりにも明白であるため、退屈です。



カウンター



タスク-ビューの数を表示する必要がある投稿など、いくつかのエンティティがあります。 ソリューションは簡単です-投稿を表示するときに実行します 

INCR post:<id>
回答としてヒット数を取得します。キーが作成されない場合、値は1に増加して返されるため、初期化も必要ありません。 そして、大根がメモリにハングアップするため、すべてが非常に迅速に動作します。 また、どこかに何かを保存することを心配する必要はありません。大根が保存されます。



GETを使用して追加せずにカウンター値を取得し、MGETを使用して複数の値を一度に取得できます。 後者は、投稿のリストを表示するときに便利です。



トップス



前の例を少し複雑にしましょう。 ヒット数に加えて、トップ、最も人気のある投稿のリストを表示する必要があります。 この場合、通常のキーではもはや十分ではありません。順序セットを使用します。幸いなことに、そこにも増分があります。 前のコマンドは次のように変更されます。 

 ZINCRBY post 1 <id>


このチームは、見かけの単純さにもかかわらず、一度にいくつかのことを行います。 第一に、存在しない場合は順序付きセットポストを作成し、第二に、存在しない場合はスコア0の要素を追加し、第三にスコアを1増やします。つまり、構築に必要なすべてを行います請求書として表示される順序付けされた投稿のセット。



最も人気のある10の投稿のIDを取得するには、次のようにします。 

 ZREVRANGE post 0 9 WITHSCORES
ビューの数が必要ない場合は、WITHSCORESを削除できます。



タスクをもう少し複雑にしましょう。古い投稿が表示されなくなった場合、時間をかけて削除していきたいと思います。 簡単-各アカウントから定期的にX％を消し込むだけです（真珠の擬似コード）： 

 my $x = X / 100; my %posts = ZRANGE post 0 -1 WITHSCORES; while (my ($id, $score) = each %posts) { ZINCRBY post -$score*$x $id; }


1日1回王冠に入れて準備します 古いものは指数関数的に衰退し、新しいもののためのスペースを作ります。



サイトへの訪問者のリスト



従来の方法で実装するのは非常に面倒な作業です。 大根付き-簡単。 何らかの方法で、ユーザーのIDを定義します。実際には、対応するテーブルのID、セッションID、またはip + useragentを使用できます。 ヒットすると、最後の呼び出しの時間を節約できます。 

 ZADD guys_online <unix_timestamp> <user_id>


なぜなら これは、注文されているにもかかわらず、まだたくさんあります。guys_onlineの同じIDを持つ以前のレコードは置き換えられ、user_idレコードは1つだけ残ります（最後のヒットのタイムスタンプ）。 オンラインの人数を取得するには（過去15分間）： 

 ZCOUNT guys_online <unix_timestamp-15*60> +inf


リストを取得するには、ZCOUNTではなくZRANGEBYSCOREを使用します。 もちろん、guys_onlineの多くは次第に目詰まりするので、クラウンに入れます 

 ZREMRANGEBYSCORE guys_online -inf <unix_timestamp-15*60>


イベント無効化キャッシュ



イベントによる無効化を実装する通常の方法は、すべてのキャッシュ依存キーを実行し、イベントが発生したときにそれらを消去することです。 ここのマイナスは過度に依存しています-イベントハンドラーはキャッシュピースのヒープについて知っている必要があります。 新しいピースをキャッシュする場合、その無効化をイベントハンドラー、または複数のハンドラーに追加する必要があります。 ひどく、不快で、紛らわしいコード接続。



別の方法があります。 キャッシュに何かを保存するときに、無効化ツールを追加します。 

 SET <cache_key> <data> SADD <event_name1> <cache_key> # cache_key    event_name1 SADD <event_name2> <cache_key> # … event_name2


event_nameイベントが発生すると、すべての依存キャッシュキーとそれらを指す無効化キーが消去されます。 

 my @cache_keys = SMEMBERS <event_name>; DEL @cache_keys <event_name>


無効化されたイベントは、不要な依存関係から削除され、キャッシュが書き込まれた同じ場所で決定されます。 また、一般的なイベントハンドラを作成できます。 ところで、このようなことはcacheopsで産業規模でのみ行われます。



次は？



さらに、大根の作成者が作成した他の例を使用して、同様のアイデアで記事を読むことができます。 大根をタスクに適応させることも、大根の助けを借りて多くの問題がいかに簡単かつ自然に解決されるかに注意を払うこともできます。


More articles:


All Articles