導入
のRedisのNoSQLは、値が文字列、ハッシュ、リスト、セット、からなることができるのRedisのキー（キー値）に基づいてデータベースである ZSET、ビットマップ、HyperLogLogのデータ構造およびアルゴリズム、およびその他のコンポーネント。Redisのは、キー期限切れの、パブリッシュ・サブスクライブ、トランザクション、Luaのスクリプト、センチネル、クラスタや他の機能を提供します。Redisのコマンドの実行速度は10ワット+ QPSを達成することができ、公式性能に応じて、非常に高速です。本論文では、以下の主なポイント終了非常に高速のRedisで：
まず、言語の発達
とは、今、私たちは、そのようなので、上のJava、Pythonと同様に、高レベルのプログラミング言語を持っています。あなたは、C言語は非常に古いですが、C言語は、オペレーティングシステムの言語に非常に近いので、すべてのUNIXシステムは、Cで実装された後、それは、本当に便利であるかもしれません。Redisのは、C言語の開発を使用しているので、実装が速くなります。
また、もう一つのことを言って、大学生の良い学習C、あなたのコンピュータのオペレーティング・システムをより良く理解するようになります。常に返済するために借金を借りて、あなたが一番下に焦点を当てることができない高レベルの言語を学ぶとは思いません。ここでは本より難しいナットをお勧めします「コンピューティング・システムの深い理解を。」
第二に、純粋なメモリアクセス
メモリ内のすべてのデータは、非データ同期がで動作するようにRedisのは、ディスク、0回IOからデータを読み取るために必要とされていません。Redisの速いスピードの重要な基盤であり、約100ナノ秒のメモリの応答時間、。CPU速度を見てみましょう：
フェイス質問：シングルスレッドのRedisなぜ速いですか？
私のコンピュータを取る、あなたは毎秒3.1×10 ^ 9の指示を行うことができることを意味、3.1Gでクロック。だから、彼より百万倍遅く、そのメモリよりも百倍遅く、世界は非常に、非常に遅いディスクを見るためにCPUは、あなたが速い不幸と言いますか？
「コンピュータシステムの深い理解を、」借用図は、典型的なメモリ階層を示し、L0層では、CPUを使用すると、いくつかのCPUクロックにすることができ、春のSRAMキャッシュの更新に基づいて、1クロックサイクルでアクセスすることができますサイクルへのアクセス、およびDRAMメインメモリに基づいており、あなたはクロック・サイクルの数十〜数百でそれらにアクセスすることができます。
三、单线程
第一，单线程简化算法的实现，并发的数据结构实现不但困难且测试也麻烦。第二，单线程避免了线程切换以及加锁释放锁带来的消耗，对于服务端开发来说，锁和线程切换通常是性能杀手。当然了，单线程也会有它的缺点，也是Redis的噩梦：阻塞。如果执行一个命令过长，那么会造成其他命令的阻塞，对于Redis是十分致命的，所以Redis是面向快速执行场景的数据库。
除了Redis之外，Node.js也是单线程，Nginx也是单线程，但他们都是服务器高性能的典范。
四、非阻塞多路I/O复用机制
在这之前先要说一下传统的阻塞I/O是如何工作的：当使用read或者write对某一文件描述符（File Descriptor FD）进行读写的时候，如果数据没有收到，那么该线程会被挂起，直到收到数据。阻塞模型虽然易于理解，但是在需要处理多个客户端任务的时候，不会使用阻塞模型。
I/O多路复用实际上是指多个连接的管理可以在同一进程。多路是指网络连接，复用只是同一个线程。在网络服务中，I/O多路复用起的作用是一次性把多个连接的事件通知业务代码处理，处理的方式由业务代码来决定。在I/O多路复用模型中，最重要的函数调用就是I/O 多路复用函数，该方法能同时监控多个文件描述符（fd）的读写情况，当其中的某些fd可读/写时，该方法就会返回可读/写的fd个数。
Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll的read、write、close等都转换成事件，不在网络I/O上浪费过多的时间。实现对多个FD读写的监控，提高性能。
举个形象的例子吧。比如一个tcp服务器处理20个客户端socket。A方案：顺序处理，如果第一个socket因为网卡读数据处理慢了，一阻塞后面都玩蛋去。B方案：每个socket请求都创建一个分身子进程来处理，不说每个进程消耗大量系统资源，光是进程切换就够操作系统累的了。C方案（I/O复用模型，epoll）：将用户socket对应的fd注册进epoll（实际上服务器和操作系统之间传递的不是socket的fd而是fd_set的数据结构），然后epoll只告诉哪些需要读/写的socket，只需要处理那些活跃的、有变化的socket fd的就好了。这样，整个过程只在调用epoll的时候才会阻塞，收发客户消息是不会阻塞的。