1. ビジネスの背景
当社のプロジェクトの背景を紹介することを避けるため、この質問を試験問題の質問と比較することにしました。ビジネスの詳細については、気にする必要はありません~タイトルだけ読んでください:
あなたは、ある国で最高のコレクターであり、継続的に価値のあるさまざまな宝物を持っていると仮定します。あなたの手。ある日、自分のコレクションが飽きてきたと感じて、これらの貴重なアイテムを売って現金に換えることに決めるかもしれません。
しかし、これらの貴重な宝物を野菜市場で売るには低すぎます。 「インターネット」の時代では、当然、さまざまな販売方法を講じなければなりません。あなたの名前で 300 部屋ある建物 (001 から 300 までの番号が付けられています) があり、各部屋にはパスワード付きの金庫があります。来月には ( 12 月 1 日から 12 月 31 日までの毎日）、最高の「最高の宝物」（クラス A の宝物とも呼ばれます）を 300 個選択し、毎日各部屋の 300 室の金庫に入れます。配置される宝物はすでに用意されています。お宝を購入したい人は、前日までにインターネットで予約し、予約コードを使用して金庫を開けて商品を受け取る必要があります。予約されていないお宝は引き取られ、販売されなくなります。
このようなオンライン予約システムを構築するには、そのフロントエンド インターフェイスは次のようになります。
フィールドに入力する 3 つのコントロールをクリックします。選択ボックスが表示されます。今の問題は、部屋に宝物が 1 つしかなく、重複して予約できないことです。購入者が宝物の種類と部屋番号を選択した後、予約日を選択するときに日付選択ボックスにいくつかの情報を入力することをお勧めします。たとえば、部屋番号 051 は 12 月 3 日に予約されており、別のユーザーが部屋番号 051 を選択しました。その後、日付選択ボックスがポップアップ表示されたら、12 月 3 日を選択不可に設定する必要があります。以下に示すように (12 月 3 日は「欠落」と表示されます):
では、このような単純なインベントリ システムを Redis に保存するにはどうすればよいでしょうか?
2. 在庫管理ソリューション (Redis)
私たちの最初のアイデアは、在庫を巨大な 3 次元配列とみなすことができ、最初の次元が宝物の種類を表し、2 番目の次元が宝物の種類を表すというものです。次元 最初の次元は部屋番号を表し、3 番目の次元は予約日を表します。 Redis は、文字列、ハッシュ、リスト、セット、ソート セットの 5 つのストレージ タイプを提供します。現在のシナリオではニーズを満たすことができるため、データの保存にハッシュ タイプを使用できます。また、セット タイプも実行可能なオプションです。
Redis のキーは宝物タイプの部屋番号 (たとえば、A:205、A は最高の宝物を表し、205 は部屋番号) に設定され、Redis の値はハッシュ タイプ、およびハッシュ キーは日付 (例: 2016-12-05 )、ハッシュ値は true または false で、予約されているかどうかを示します。グラフィック表現は次のとおりです。
# カテゴリー A の宝物の部屋 158 が 12 月 8 日に予約されている場合、それは
# として保存されます。 |
#1
2
3
|
#Redis キー —— A:158
Redis 値 —— ハッシュ テーブル [ => 1]# ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃<p>3. 高度なシナリオと在庫管理ソリューション</p>
<p>クラス A トップトレジャーの発売は大歓迎され、発売直後からすでに多数の注文が入っています。多くの中産階級の人がコレクションに興味を持っていますが、値段が高いので躊躇することがよくあります。そこで、コレクションの中からタイプBのお宝を選びますが、タイプAのお宝に比べると若干劣るものの、価格がリーズナブルで「優良なお宝」とも呼ばれています。 </p>
<p> タイプ A よりもタイプ B の方が宝の数が多いので、遊び方を変えてみましょう。この 300 部屋のうち、各部屋に金庫を置きます。今回は、各部屋に金庫を置きます。 300ルームボックスにBタイプの宝物を1つずつ入れると、予約されていない宝物は1時間後に回収され、次の1時間分の宝物と交換されます。購入者が予約をすると、予定された時間に従って宝物を受け取ります。カテゴリー B の宝物の場合、予約システムには受け取り時間という追加オプションがあります。 </p>
<p><img src="https://img.php.cn/upload/article/000/000/164/168523994675673.png" alt="Redis を使用してスケジュールされたインベントリ キャッシュ機能を使用する方法"></p>
<p># さて、在庫保管を行う場合、あらかじめ決められた条件（受け取り時間）が追加されるので、ざっくりと考えると、在庫は実際には大きな 4 次元配列です。この文は次のように書き換えることができます。 4 次元情報には、宝物の種類、部屋番号、予約日、受け取り時間が含まれます。この種の宝物を Redis に保存するにはどうすればよいでしょうか? </p>
<p>実際、よく考えてみると、クラス A の最高品質の宝物を保存する場合、Redis のストレージは次元の無駄です。</p>
<p>実際、使用された hashValue ストレージは 1 つだけです。その時点で所定のステータスに達し、この次元の情報が無駄になります。お迎えの時間が0時から1時、1時から2時、…、23時から24時と全て正時であることを考えると、1日を通して合計24件となります。したがって、完全に 2 進整数を使用して予約アイテムの時間を表すことができます。たとえば、1 は 0 ～ 1 点、2 は 1 ～ 2 点、4 は 2 ～ 3 点、...、</p>
<p>23 ～ 24 点は 2 の 23 乗で表現できます (8388608) 。複数の期間を予約するには、値に対して論理 OR 演算を実行するだけです。 </p>
<p>このようにして、Redis 構造は次のようになります: </p>
<p><img src="https://img.php.cn/upload/article/000/000/164/168523994619607.png" alt="Redis を使用してスケジュールされたインベントリ キャッシュ機能を使用する方法"></p>
<p>たとえば、クラス B 宝物室 103、12 月 5 日と 6 日の午前中から予約されました。 8:00 ～ 12:00、</p>
<table><tbody>
<tr class="firstRow">
<td>
<p>#1</p>
<p>2</p>
<p>3</p># として Redis に保存されます</td>
<td>
<p>#Redis キー —— B:103<code>
Redis 値 —— ハッシュ テーブル [ '2016-12-05' => 3840, => 3840]
|
#B タイプのお宝の場合、新たに予約する場合は、同じことを行うのではなく、最初に元のハッシュ値を取り出し、新しい受け取り予定時刻と論理 OR 演算を実行し、その結果を Redis に書き戻す必要があります。 A級秘宝と同様、hSetを直接呼び出してハッシュ値を設定するため、予約をキャンセルする場合は、ハッシュ値からキャンセルする期間を差し引いた元のハッシュ値を取り出すことに注意してください（XOR論理積演算）残りの予約されたピックアップ時間は Redis に書き戻されるため、hDel を呼び出して直接削除することはできません。
4. 高度な在庫管理プラン
クラス B 宝物の発売以来、あなたのビジネスは以前よりもはるかに人気が高まっています。新たな需要が再び生まれ、観光客や学生など、あまり貯金のない人たちもあなたのお宝に興味を持ち、この街に来た人たちはお土産を持って帰りたいと思っています。タイプBの宝物の価格はタイプAよりもわずかに低くなりますが、それでもこの人々にとっては少し高価です。そこで、最も手頃な価格の宝物 (カテゴリー C の宝物) を売却することにしました。
この 300 部屋のうち、タイプ C の宝物が最も多く保管されているため、各部屋にタイプ C の宝物を保管するための専用の宝箱を 100 個追加します。この 100 個の宝箱には、No.1、No.2、...、No.100 と番号が付けられています。同様に、1 時間ごとに、これら 300 の部屋のそれぞれにある 100 個の宝箱に C タイプの宝物を 1 つずつ入れます (つまり、建物全体で 1 時間ごとに 30,000 個の C タイプの宝物が更新されることになります)。誰も予約しない場合、宝物は次の時間に置き換えられます。最後に、あらゆる人のニーズを満たすことができます。
C タイプの宝物の場合、予約インターフェイスは次のようになります:
別の予約条件を追加しました。現時点では、在庫の保管の問題に直面しています。いつものように、この在庫は実際には大きな 5 次元配列であり、宝物の種類、部屋番号、予約日、受け取り時間、宝箱番号がそれぞれ 1 次元を占めています。以前に Redis の容量をすべて使い果たしてしまいました。データを保存するにはどうすればよいでしょうか?
今回は、Redis インベントリ ストレージをビジネス特性と組み合わせる必要があります。まず、宝箱番号と受け取り時間の二次元は値の範囲があまり多くなく、宝箱番号は 100 個しかありません。ハッシュ値を長さ 100 の配列に変換し、配列の各位置を変更するだけです。 INTが含まれており、タイプに示されているピックアップ時間で十分です。ただし、ハッシュ値は文字列のみにすることができます。そのため、配列のシリアル化操作を実行し、読み取り時に逆シリアル化して戻す必要があります。幸いなことに、長さはわずか 100 であるため、シリアル化効率がシステムのボトルネックになることはありません。
保管方法は、12月23日と24日の午前11時から午後1時までの間、258号室のCタイプの宝物のうち、97番と99番の宝箱を確保しました。
##1
| 23
#Redis キー —— C :258 |
Redis 値 —— ハッシュ テーブル ['2016-12-23' => ; '[97 => 6144, 99 => 6144]', '2016-12-24' => ; '[97 => 6144, 99 => 6144]' ]
このうち、6144はバイナリで「110000000000」と表現され、ハッシュ値は配列を直列化した後の文字列となり、実際のプロジェクトで利用できるjson形式となっています。さて、Redis には 3 種類の宝物を保存できるストレージができました。
カテゴリ C の宝物の場合、ユーザーが予約をキャンセルしたり、新しい予約を追加したりするときに、単に hSet および hDel を呼び出して設定を上書きして削除することもできません。すでに予約されている状況を取り出す必要があり、予定されたピックアップ時間でビット単位の演算を実行します。
5. ストレージの最適化
インベントリは理論的には多次元配列です。私たちが行う主な作業は、各次元を合理的に格納し、追加、削除、クエリを容易にする方法です。 。メモリ節約の観点から、最初に誰も予約していない場合、Redis は空でも構いませんが、クラス A のトレジャーの場合、ハッシュ値が false に等しく、対応する Redis キーまたはハッシュ キーが存在しない場合に有効です。
また、宝の種類と部屋番号を組み合わせてredisキーを作成すると、redis上で宝の目録に関わるキーの数が多くなりますが、これらのキーを一元管理しやすくするために、別の Redis キャッシュを追加します。以下の図に示すように、宝物インベントリに関連するすべての Redis キー値を保存するために特別に使用されます。なお、この場合、セットデータ型の追加、削除、変更、クエリの複雑さはO(1)であるため、ハッシュデータ型を使用する代わりにセットデータ型を使用することで要件を満たすことができます。 Redis にすでに存在するすべてのインベントリ キー値を保存します。
これを行う利点の 1 つは、ある日特別な状況に遭遇し、インベントリ関連のキャッシュをすべてクリアする必要がある場合に、すべてのインベントリ キーを簡単に削除して削除できることです。 。もう 1 つの利点は、継続的な拡張のためのアイデアを提供してくれることです... 現在最も複雑な状況は、合計 5 つの次元を持つタイプ C の宝物であると想像してください。将来、宝物を販売するために 1 つの建物の 300 の部屋を使用するのではなく、複数の建物を使用するようになったとします。その場合、ユーザーは注文時に別の次元、つまり建物番号を追加する必要があります。このような状況が発生した場合、使用する建物番号に設定されている余分なインベントリ キーを完全に削減し、発生する可能性のあるより複雑な状況でもスケーラビリティを確保できます。
この拡張後、新しい予約レコードを追加するたびに、対応する redis キー値がインベントリ キー セットに既に存在するかどうかを確認する必要があります。存在しない場合は、redis キーを追加する必要がありますインベントリキーセットの値。削除操作も同様です。
|
以上がRedis を使用してスケジュールされたインベントリ キャッシュ機能を使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
