簡単な紹介
Redisの著者：イタリアサルヴァトーレサンフィリッポ（スクリーンネームAntirez）の開発。Antirezないだけでハンサムとは異なり、送信するために、電力だけでなく、非常に興味深いです。Antirez今年はRedisのが原因に貢献していき、オープンソースの書き込みコードにまだ疲れを知らずに、4歳となっています。
Redisのは、データベース、キャッシュ、メッセージブローカーとして、メモリに格納されているオープンソース（BSDライセンス）のデータ構造です。これは、ソート範囲クエリ、ビットマップ、超地理空間インデックスとログ・ストリームおよびその他のデータ構造を持つコレクションで、文字列、ハッシュ、リスト、セットをサポートします。Redisのは、LUAスクリプト、LRU回復、トランザクション、およびディスクの異なるレベルでの組み込みの複製、持続性を持っており、自動的に分割し、RedisのRedisのセンチネルクラスタによって高可用性を提供します。
源码githubの：github.com/antirez/red...
圧力測定
まず、パフォーマンスのRedis Redisのは、ストレステストツールのRedis-ベンチマークに付属しているかを確認するためのテストの期間を経て、我々はパイプラインをテストするには、このツールを使用することができます。
まず、私たちは、共通の命令セットの圧力を測定した5ワット/ sの約QPS。
> redis-benchmark -t set -q
SET: 51975.05 requests per second
复制代码我々は、P = 2、下記参照単一のチューブ内の同時要求の数を表し、パイプラインオプション-Pパラメータを加え、QPSは9ワット/秒に達しました。
> redis-benchmark -t set -P 2 -q
SET: 91240.88 requests per second
复制代码ルックP = 3は、QPSは10ワット/秒に達しました。
> redis-benchmark -t set -P 3 -q
SET: 102354.15 requests per second
复制代码我々はPパラメータを強化し続けた場合でも、QPSは増加しないことが判明しました。これはなぜでしょうか？
ここでは、CPUの処理能力がボトルネックに達しましたので、私は充実し続けることはできませんので、Redisのは、シングルスレッドCPUが100％に急増しています。
Redisのはなぜそんなに早く？
通常の状況下では、速度が非常に速いRedisのコマンド実行で与えられた公式の数字10万/秒までのパフォーマンスを読み書きしている、もちろん、これはまた、マシンの性能に依存しますが、ここでは分析し、マシンのパフォーマンスの違いを議論していませんそれはさらに速いスピードでRedisのは、それが広く、以下の5点に分類することができる作るものです：
Redisのは、実行速度が比較的速くなり、一般的な「距離」より最新のオペレーティングシステムではC、C言語プログラムで実装されています。
完全にメモリに基づいて、要求のほとんどは非常に速く、純粋なメモリ操作です。データはHashMapのと同様に、メモリに格納され、HashMapの利点は、ルックアップ操作の時間と複雑さはO（1）があり、Redisのはシングルスレッドであるため、慎重に使用しなければならないもの時間計算のためのRedisの命令は、O（nは）レベルの命令は、注意して使用しなければならない、我々はそれがRedisのカトンにつながる可能性があると信じています。
単純なデータ構造、データの操作が簡単で、Redisのデータ構造が適合するように設計された、シングルスレッド、コンテキストが不要と競合条件を回避するために、スイッチ、何らマルチプロセスまたはマルチリードスレッド切り替え消費されるCPUが存在しません、様々な問題がないため、発生する可能性がデッドロックと原因のパフォーマンスのオーバーヘッドの、ロックロック解除操作が存在しない場合、ロックを検討する必要はありません。
IO、同時クライアント接続のRedisのシングルスレッドモデル番号をノンブロッキング、モデルを多重化、複数のI / Oを使用しました。クライアントと道の間の通信を達成するために、異なる基礎となるモデル、それらの間の基本的なアプリケーションプロトコルを使用して、システムコールシステムの機能のほとんどは、それが移動するためにいくつかの時間と要求を無駄になりますので、RedisのVMは、自分の直接のメカニズムを構築し、同じではありません;
ソースコードのRedisの前記及び審議することができるため、これはRedisの評価されたオープン・ソース・コードのいずれかでの性能とエレガンスのまれなセットです。
Redisのは非常に速く、次の外観は実装アーキテクチャをRedisの理由を知っています
全体的なアーキテクチャをRedisの
通信アーキテクチャ
第1層：などのよく知られたネイティブRedisの-CLIなどのクライアント、Java言語Jedis、Redisの-PYのようなPython言語
第二層：通信、TCP RESPに基づいて、トランスポート層プロトコル
第三層：サーバー、多重化、イベントループ、持続性、など
プロセス・アーキテクチャ
のサーバー側で全体的なコア処理のRedis
このフローチャートは以下のようです：
epoll：基本的な多重化モデル
イベント：イベントのイベントと時間を含むデザインファイルを多重化します。コマンド処理：接続手順、プロセス、プロセスの応答
3つの相補形上記のプロセスフローのコアは、サービスをRedisの。
次のように全体的なプロセスは、次のとおりです。クライアントが開始ソケット接続
サーバーは、ソケット接続を受け入れます
クライアントの書き込み
Serverが書かれた受信します
サーバーが返す結果
クライアントのリターン結果を受け取ります
看到这里，对整体流程有个大概的印象了，你可能好奇两个点，一个是Redis事件是什么，第二个是I/O多路复用是什么，下面分别简单的说一下：
Redis事件
文件事件：
Redis通过套接字与客户端（或者其他服务器）进行连接，而文件事件就是服务器对套接字操作的抽象。服务器与客户端的通信会产生相应的文件事件，而服务器则通过监听并处理这些事件来完成一系列的网络通信操作。
Redis基于Reactor模式开发了自己的网络事件处理器：这个处理器则被称为文件时间处理器。
文件事件处理器使用I/O多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的时间处理器。
当被监听的套接字准备好执行连接应答accept、读取read、写入write、关闭close等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
时间事件：
Redis服务器中一些操作（比如serverCron的函数）则需要在给定的时间点执行，时间事件就是服务器对这类定时操作的抽象。默认一秒执行10次，即100ms执行一次。配置在redis.conf中的hz
serverCron函数的主要工作：
更新服务器的各类统计信息，比如内存占用、数据库占用情况等。
清理数据库中的过期键值对。
关闭和清理链接失效的客户端。
尝试进行AOF或RDB持久化操作。
如果服务器是主服务器，对从服务器进行定时同步。
集群模式，对集群进行定期同步和连接测试。
I/O 多路复用技术
详解：
blog.chinaunix.net/uid-2451754…
实现机制：
多种线程模型：同步阻塞、同步非阻塞、多路复用、异步的对比，这里不展开介绍，感兴趣的同学可以自行查看相关资料。
下面介绍一下多路复用中的epoll，Redis事件管理器核心实现基本依赖于它。
epoll是在Linux 2.6内核中引进的，是一种强大的I/O多路复用技术，上面我们已经说到在进行网络操作的时候是通过文件描述符来进行读写的，那么平常我们就是一个进程操作一个文件描述符。然而epoll可以通过一个文件描述符管理多个文件描述符，并且不阻塞I/O。这使得我们单进程可以操作多个文件描述符，这就是redis在高并发性能还如此强大的原因之一。
下面简单介绍epoll 主要的三个方法：
int epoll_create(int size) //创建一个epoll句柄用于监听文件描述符FD，size用于告诉内核这个监听的数目一共有多大。该epoll句柄创建后在操作系统层面只会占用一个fd值，但是它可以监听size+1 个文件描述符
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) //epoll事件注册函数,在创建文件事件的时候进行调用注册
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)//等待事件的产生
Redis 的事件管理器主要是基于epoll机制，先采用 epoll_ctl方法 注册事件，然后再使用epoll_wait方法取出已经注册的事件。
以上就是本篇文章的全部内容，感谢您的阅读，如果您在其中发现任何不正确或者不严谨的描述，欢迎指正。