图解四种 IO 模型

最近越来越认为,在讲解技术相关问题时,大白话固然很重要,通俗易懂,让人有想读下去的欲望。但几乎所有的事,都有两面性,在看到其带来好处时,不妨想想是否也引入了不好的地方。

例如在博客中,过于大白话的语言的确会让你阅读起来更加顺畅,也更容易理解。但这都是其他人理解,已经咀嚼过了的,人家是已经完全理解了,你从这些信息中大概可能会观察不到全貌。所以,适当的白话是很好的,但这个度得控制一下。

接下来切入正文。

相信大家经常看到这个问题:

BIO、NIO 和 AIO 有什么区别?

看到这个问题,可能你脑海中就会浮现以下这些字眼。比如 BIO 就是如果从内核获取数据会一直阻塞,直到数据准备完毕返回。再比如 NIO,内核在数据没有准备好时不会阻塞住,调用程序会一直询问内核数据是否 Ready。

继续阅读图解四种 IO 模型

玩转 ByteBuffer

为什么要讲 Buffer

首先为什么一个小小的 Buffer 我们需要单独拎出来聊?或者说,Buffer 具体是在哪些地方被用到的呢?

例如,我们从磁盘上读取一个文件,并不是直接就从磁盘加载到内存中,而是首先会将磁盘中的数据复制到内核缓冲区中,然后再将数据从内核缓冲区复制到用户缓冲区内,在图里看起来就是这样:

从磁盘读取文件

再比如,我们往磁盘上写文件,也不是直接将数据写到磁盘。而是将数据从用户缓冲区写到内核缓冲区,由操作系统择机将其刷入磁盘,图跟上面这个差不多,就不画了,自行理解。

再再比如,服务器接受客户端发过来的数据时,也不是直接到用户态的 Buffer 中。而是会先从网卡到内核态的 Buffer 中,再从内核态的 Buffer 中复制到用户态的 Buffer 中。

那为什么要这么麻烦呢?复制来复制去的,首先我们用排除法排除这样做是为了好玩。

继续阅读玩转 ByteBuffer

用户态和内核态的区别是啥

这篇文章的深度不会太深,重点就是了解一下用户态和内核态的区别就 OK 了。

先给不了解内核态、用户态的简单介绍一下,我们在什么时候会提到这两个概念。

例如我们的应用程序需要从磁盘读取某个文件的数据,此时并不是直接从磁盘加载到应用内存中,而是:

  • 先将数据从「磁盘」复制到「内核 Buffer」
  • 再将数据从「内核 Buffer」复制到「用户 Buffer」

以上就是用户态内核态的概念。首先我们给他下个定义,这两个是操作系统的运行级别

然后我们知道,我们写的程序,最终运行的时候实际都会被编译、解释成一条一条的 CPU 指令被 CPU 执行。

继续阅读用户态和内核态的区别是啥

关于 RocketMQ ClientID 相同引发的消息堆积的问题

首先,造成这个问题的 BUG RocketMQ 官方已经在 3月16号这个提交中修复了,这里只是探讨一下在修复之前造成问题的具体细节,更多的上下文可以参考我之前写的 《RocketMQ Consumer 启动时都干了些啥?》 ,这篇文章讲解了 RocketMQ 的 Consumer 启动之后都做了哪些操作,对理解本次要讲解的 BUG 有一定的帮助。

其中讲到了:

消息堆积

重复消费自不必说,你 ClientID 都相同了。本篇着重聊聊为什么会消息堆积

继续阅读关于 RocketMQ ClientID 相同引发的消息堆积的问题

RocketMQ Consumer 启动时都干了些啥?

可能我们对 RocketMQ 的消费者认知乍一想很简单,就是一个拿来消费消息的客户端而已,你只需要指定对应的 Topic 和 ConsumerGroup,剩下的就是只需要:

  • 接收消息
  • 处理消息

就完事了。

简略消费模型

当然,可能在实际业务场景下,确实是这样。但是如果我们不清楚 Consumer 启动之后到底会做些什么,底层的实现的一些细节,在面对复杂业务场景时,排查起来就会如同大海捞针般迷茫。

继续阅读RocketMQ Consumer 启动时都干了些啥?

请求数据包从发送到接收,都经历什么?

之前讲了「从输入 URL 再到浏览器成功看到界面」中的域名是如何变成 IP 地址的,了解了 DNS 相关的东西。这篇文章就聊聊发生在 DNS 解析之后的操作——建立连接。也就是我们常说的三次握手

看到三次握手你可能会说,这不是面试都被问烂了的题吗?

三次握手不就是:

  1. 服务器开始为 CLOSE 状态,然后监听某个端口,此时服务器会进入 LISTEN 状态
  2. 客户端最初也是 CLOSE 状态,客户端会向服务器发送一个带 SYN 标志位的数据包,主动发起连接。此时客户端会变成 SYN-SENT 状态
  3. 服务器接收到客户端的数据包之后,通过标志位判断出了客户端想要建立连接。然后返回一个 SYNACK ,此时服务器的状态变为了 SYN-RCVD
  4. 客户端收到了服务器的 ACK 之后,会回一个 ACK 给服务器,回完这个 ACK 之后,客户端的状态就变为了 ESTABLISH
  5. 服务器收到了客户端回复的 ACK 之后,服务器的状态也变成了 ESTABLISH
继续阅读请求数据包从发送到接收,都经历什么?

你的域名是如何变成 IP 地址的?

可能大家都知道或者被问过一个问题,那就是很经典的「从浏览器输入 URL 再到页面展示,都发生了什么」。这个问题虽然简单,但是真的能够从回答的各种细节上看出不同人之间的水平差距。

这篇文章主要是聊一聊输入 URL 之后的第一步——域名解析

域名就类似于 http://www.google.com,而通过 ping 命令,就可以查询到对应域名的 IP 地址了。

那为什么又要有域名,又要有 IP 呢?

继续阅读你的域名是如何变成 IP 地址的?

Base64 原理

Base64

Base64 是什么?是将字节流转换成可打印字符、将可打印字符转换为字节流的一种算法。Base64 使用 64 个可打印字符来表示转换后的数据。

准确的来说,Base64 不算是一种加、解密的算法,它是一种编码、解码的算法。这也是为什么我的用词是编码、解码,而不是加密、解密。

编码原理

这里的讨论的前提是使用 UTF-8 编码

Base64 算法的原理,是将输入流中的字节按每 3 个分为一组,然后每次取 6 个比特,将其转换成表格中对应的数据,一直重复到没有剩余的字符为止,转换表格如下:

IndexCharacterIndexCharacterIndexCharacterIndexCharacter
0A1B2C3D
4E5F6G7H
8I9J10K11L
12M13N14O15P
16Q17R18S19T
20U21V22W23X
24Y25Z26a27b
28c29d30e31f
32g33h34i35j
36k37l38m39n
40o41p42q43r
44s45t46u47v
48w49x50y51z
520531542553
564575586597
60861962+63/
继续阅读Base64 原理

MySQL 不完全入门指南

由于 MySQL 的整个体系太过于庞大,文章的篇幅有限,不能够完全的覆盖所有的方面。所以我会尽可能的从更加贴进我们日常使用的方式来进行解释。

小白眼中的 MySQL

首先,对于我们来说,MySQL 是个啥?我们从一个最简单的例子来回顾一下。

这可能就是最开始大家认知中的 MySQL。那 MySQL 中是怎么处理这个查询语句的呢?换句话说,它是如何感知到这串字符串是一个查询语句的?它是如何感知到该去哪张表中取数据?它是如何感知到该如何取数据?

到目前为止,都不知道。接下来我们一步一补来进行解析。

连接池

首先,要去 MySQL 执行命令,肯定是需要连接上 MySQL 服务器的,就像我们通过「用户名」和「密码」登陆网站一样。所以,我们首先要认识的就是连接池

这种池化技术的作用很明显,复用连接,避免频繁的销毁、创建线程所带来的开销。除此之外,在这一层还可以根据你的账号密码对用户的合法性、用户的权限进行校验。

每一个连接都对应一个线程,「服务器」 和 「MySQL」 都一样,服务器的一个线程从服务器的连接池中取出一个连接,发起查询语句。MySQL 服务器的线程从连接池中取出一个线程,继续后续的流程。

那么后面的流程是啥呢?当然是分析 SQL 语句了。

继续阅读MySQL 不完全入门指南