点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

  • Hadoop（已更完）
  • HDFS（已更完）
  • MapReduce（已更完）
  • Hive（已更完）
  • Flume（已更完）
  • Sqoop（已更完）
  • Zookeeper（已更完）
  • HBase（已更完）
  • Redis （正在更新…）

章节内容

上节我们完成了：

  • Redis的缓存机制
  • Redis的淘汰策略
  • LRU LFU 等机制

大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_lua

通信协议

  • Redis是单进程+单线程的。
  • 应用系统和Redis之间是通过Redis协议（RESP）来进行交互的。

响应模式

概念介绍

Redis 协议位于 TCP 层上，即客户端和Redis实例保持双工的连接。

大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_lua_02

串行模式

  • 串行化是最简单的模式，客户端与服务端建立长连接。
  • 连接通过心跳机制来检测（ping-pong）ACK应答。
  • 客户端发送请求，服务端响应，客户端收到响应后，再发起第二个请求，服务端再响应。
  • telnet 和 redis-cli 都属于这种模式，耗时在网络传输且性能较低

大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_大数据_03

双工模式

批量请求，批量响应，请求和响应交叉进行，不会混淆（TCP双工）

  • pipline 的作用是将一批命令进行打包，然后发送给服务器，服务器执行完后按顺序打包返回。
  • 通过pipline，一次pipline中包含多条命令+一次网络时间

我们使用Jedis库可以很轻松的使用 pipline

Jedis redis = new Jedis("h121.wzk.icu", 6379);
redis.auth("111111");
Pipeline pipe = jedis.pipelined();
for (int i = 0; i <50000; i++) {
    pipe.set("key_"+String.valueOf(i),String.valueOf(i));
}
// 将封装后一次性发给redis
pipe.sync();
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.

数据格式

Redis 客户端与服务器交互采用序列化协议（RESP）。
请求以字符串的形式来表示要执行的命令的参数
Redis使用特有的数据类型作为回复。

  • 客户端与服务端通过TCP连接来进行数据交互，服务端口号为：6379
  • 客户端与服务端发送的命令和数据一律以 \r\n（CRLF）结尾
  • 所有参数都是二进制安全（binary safe）

内联格式

可以使用 telnet 工具进行测试，发送一些内容过去

telnet h121.wzk.icu 6379

xxx
xxx
xxx
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.

处理流程

处理流程

  • 服务器启动监听
  • 接受命令请求并解析
  • 执行命令请求
  • 返回命令回复

具体的过程图可以看下边的流程图片：

大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_redis_04

处理机制

Redis 服务器是典型的事件驱动系统，Redis将事件分为两大类：

  • 文件事件
  • 时间事件

文件事件

文件事件即Socket读写事件，也就是IO事件，比如客户端连接、命令请求、数据回复、连接断开等等。

Reactor

Redis 事件处理机制采用单线程的Reactor模式，属于 I/O 多路复用的一种常见模式。
IO 多路复用指单个线程管理多个Socket，Reactor Pattern（反应器设计模式）是一种为处理并发服务请求，并将请求提交到一个或者多个服务器处理的事件设计模式。

  • Reactor 模式是事件驱动的
  • 有一个或者多个并发输入源
  • 有一个ServiceHandler
  • 有多个RequestHandlers
  • ServiceHandler会同步的将输入的Event多路复用的分发给相应的RequestHandler

下面这些图片可以让你更好地理解 Reactor 模式：

大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_大数据_05


大数据-48 Redis 通信协议原理RESP 事件处理机制原理 文件事件 时间事件 Reactor多路复用_redis_06

多路复用

IO多路复用机制就是通过一种机制，一个进程可以监视多个描述符（Socket），一旦某个描述符就绪，能够通知程序进行相应的复写操作。
IO多路复用机制有这么几种：

  • select
  • poll
  • epoll
  • kqueue

Select

select函数监视的文件描述符分3类：

  • writefds
  • readfds
  • exceptfds

调用后select函数会阻塞，直到有描述符就绪或者超时，函数返回。
当select函数返回后，可以通过 fd 列表遍历，来找到就绪的描述符。

Select优点

几乎在所有平台上都有支持，跨平台支持。

Select缺点

单个进程打开文件描述有一定的限制，有 FD_SETSIZE 设置，默认是 1024 ，采用数组存储，另外在检查数组中是否有文件描述符需要读写时，采用的是线性的扫描（不管是否活跃都扫描轮询），效率较低。

Poll

poll使用一个 pollfd 的指针实现，pollfd结构包含了要监视的 Event 和 发生的 Event，不再使用 select 的参数值传递的方式。

Poll 优点

采用链表的形式存储，它监听的描述符数量没有限制，可以超过select默认限制的1024大小

Poll缺点

另外在检查链表中是否有文件描述符需要读写时，采用线性扫描的方法，即不管Socket是不是活跃的，都轮询一次，效率较低。

epoll

epoll 子啊 Linux2.6 内核中提出的，是之前 select 和 poll 的加强版本。
相对于 select 和 poll 来说，epoll 更加灵活，没有描述符限制。

epoll 使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy就只需要一次。

epoll优点

epoll 没有最大并发连接限制，上限是最大能打开文件的数目，比如1GB内存大约能打开10万文件左右。
epoll 最大的优点就在于只处理活跃的连接，而不需要轮询遍历，所以效率很高。

kqueue

kqueue 是 unix 下的一个 IO 多路复用库。最初是 2000年在FreeBSD系统上开发的一个高性能的事件的事件通知接口。
注册一批Socket描述符kqueue后，当其中描述符状态发生改变时，kqueue将一次性通知应用程序哪些描述符可读可写或出错。

kqueue优点

能处理大量数据，性能较高。