製品の使用シナリオは確かにRedisのをどの機能、製品の特性に最初のリストが必要になります。
- 良好なパフォーマンスを読み書き
- 持久化
- 豊富なデータタイプ
- シングルスレッド
- データが自動的に有効期限が切れています
- パブリッシュおよびサブスクライブ
- 分散
ここではいくつかのシナリオがある、の異なる寸法は、Redisの下のアプリケーションと述べました。
高性能キャッシュとして適し
Redisのキャッシュは、最も一般的なシナリオであるので、主な理由は、優れRedisの読み取りと書き込みの性能を、それをすべて使用しています。そして、成長優先サーバー・サイド・キャッシング・コンポーネントとして、memcachedのを置き換えるがあります。また、Redisの内部の業務を効果的にデータの一貫性を確保することができる時間の使用に支持されています。データを保存するには2つの方法がありますが、キャッシュとして使用します。
Redisのに、プルアップデータを読み取るデータがない場合のRedisは、行く読んで、データベースを読み込む前に1、
2、Redisのを書き込みながら、データを挿入
オプション1：実装が簡単、しかし、2つの注意点があります。
1、キャッシュ破壊を避けます。（データベースのデータをヒットする必要はありませんRedisのデータにつながっていないしていない、とデータベースをヒットされています。）
2、リアルタイムのデータが比較的狭くなります。
オプション2：リアルタイムデータは強いが、統一された処理を開発することは容易ではありません。
もちろん、二つの方法は、実際の状況を適用します。以下のような：リアルタイムデータの要件に適したプログラムは特に高い場面ではありません。オプションIIは、辞書テーブルにデータを格納されたデータの量を適用します。
より豊富なデータ形式、機能豊富なアプリケーション・シナリオ
Redisのは、他のキャッシュに比べて、それは複数のデータ型をサポートすることで、非常に大きな利点があります。
そのようなシナリオID、詳細の説明文字列データ型、文字列、最も単純なKVのhashhash記憶フォーマット、フィールドの値と値。リスト単純なリスト、オーダーリスト、または順不同リストを設定された第1端部支持挿入データ、交差点や労働組合のための高速検索、違いソートセット順序集合を処理
実際には、機能の上記のデータ型によって、基本的には、適切なアプリケーションシナリオを考えることができます。
- 適当string--最も単純なのKVストレージは、ストレージのこのタイプを使用する同様のストレージ構造、およびメッセージ認証コード、設定情報等を、memcachedの
- IDまたは固有の識別子のための一般的なキー、詳細に対応する値をhash--。このような商品情報、個人情報の詳細、ニュースやその他の詳細など
- list--リストため順序付けされ、順序付けられたデータの固定された数に対応するデータを格納するためのより適切。その上地方テーブル、ディクショナリ表と同様。執筆のための時間に応じてソート、リストが注文されたため、など：***最新の、メッセージキュー、など
- set--は、単に、そのようなマイクロブログにおける人の友人として、IDリストモードとして理解することができる牛のように設定されている場合、SETは、2つの交差点、及び組合、差分演算を提供することができます。例えば：など、一緒に友人二人を探します
- ソートされたSet--は、セットの拡張バージョンで、スコアパラメータが自動的にスコアの値に基づいてソートされます追加します。挿入データの時間に応じて同様のトップ10の比較などを注文されていません
平均キャッシュデータ構造以上に、ないリレーショナルデータベースとしてRedisの少ない複雑なデータ構造が、だけでなく、シーンの多くのために、前述したように。各ビジネスシナリオのためのデータ構造を理解することが、効果的にRedisをのパフォーマンスで利用することができ、開発効率の向上に貢献するだけでなく。
これは、シングルスレッド分散ロックとして使用することができます
そういえば違いRedisのとMemcachedのは、我々はより多くのデータ構造およびこれらの二つの特性の持続性について話している、実際には、比較的大きな差があるがあります：
- Redisのは、処理効率の多重化を改善する、シングルスレッドであります
- memcachedのは、CPUスレッドスイッチによって処理効率を向上させるために、マルチスレッド化され
だから、それは最も一般的に使用され、実際には非常に重要なアプリケーションのシナリオシングルスレッドであるRedisのこの機能は分散ロックです。
すべてのマルチサーバー展開で非常に並行システム、対処、データロックについて、それぞれの技術的なフレームワークは、このような.NETのロックのような非常に良いアプローチを、持っている、Javaのスレッドリードに対応できるオブジェクトをロックすることにより、同期化データの汚染問題。しかし、すべての後に、このスレッドは、処理することはより困難である、サーバー、将来的にはデータの汚染問題の分散配置を制御することができます。Redisのシングルスレッドこの特徴で、それは次のように疑似コードであり、この要求と非常に一致しています。
/产生锁 while lock!=1 //过期时间是为了避免死锁 now = int(time.time()) lock_timeout = now + LOCK_TIMEOUT + 1 lock = redis_client.setnx(lock_key, lock_timeout) //真正要处理的业务 doing() //释放锁 now = int(time.time()) if now < lock_timeout: redis_client.delete(lock_key)
以上是一个只说明流程的伪代码，其实整体的逻辑是很简单的，只要考虑到死锁时的情况，就比较好处理了。Redis作为分布式锁，因为其性能的优势，不会成为瓶颈，一般会产生瓶颈的是真正的业务处理内容，还是尽量缩小锁的范围来确保系统性能。
自动过期能有效提升开发效率
Redis针对数据都可以设置过期时间，这个特点也是大家应用比较多的，过期的数据清理无需使用方去关注，所以开发效率也比较高，当然，性能也比较高。最常见的就是：短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。因为使用比较简单，就不赘述了。
分布式和持久化有效应对海量数据和高并发
Redis初期的版本官方只是支持单机或者简单的主从，大多应用则都是自己去开发集群的中间件，但是随着应用越来越广泛，用户关于分布式的呼声越来越高，所以Redis 3.0版本时候官方加入了分布式的支持，主要是两个方面：
- Redis服务器主从热备，确保系统稳定性
- Redis分片应对海量数据和高并发
而且Redis虽然是一个内存缓存，数据存在内存，但是Redis支持多种方式将数据持久化，写入硬盘，所有，Redis数据的稳定性也是非常有保障的，结合Redis的集群方案，有的系统已经将Redis当做一种NoSql数据存储来适用。
示例：秒杀和Redis的结合
秒杀是现在互联网系统中常见的营销模式，作为开发者，其实最不愿意这样的活动，因为非技术人员无法理解到其中的技术难度，导致在资源协调上总是有些偏差。秒杀其实经常会出现的问题包括：
- 并发太高导致程序阻塞
- 库存无法有效控制，出现超卖的情况
其实解决这些问题基本就两个方案：
- 数据尽量缓存,阻断用户和数据库的直接交互
- 通过锁来控制避免超卖现象
现在说明一下，如果现在做一个秒杀，那么，Redis应该如何结合进行使用?
- 提前预热数据，放入Redis
- 商品列表放入Redis List
- 商品的详情数据 Redis hash保存，设置过期时间
- 商品的库存数据Redis sorted set保存
- 用户的地址信息Redis set保存
- 订单产生扣库存通过Redis制造分布式锁，库存同步扣除
- 订单产生后发货的数据，产生Redis list，通过消息队列处理
- 秒杀结束后，再把Redis数据和数据库进行同步
以上是一个简略的秒杀系统和Redis结合的方案，当然实际可能还会引入http缓存，或者将消息对接用MQ代替等方案，也会出现业务遗漏的情况。
每个技术都有属于自己的应用场景，只有对技术的特点有一定清晰的认识，才能更好的利用技术，发挥其最大的优势。