图解四种 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. 服务器接收到客户端的数据包之后，通过标志位判断出了客户端想要建立连接。然后返回一个 SYN 和 ACK ，此时服务器的状态变为了 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 不完全入门指南