发表于 | 分类于

Hello，大家好，我是阿粉~

无论你现在使用什么编程语言，每天最高频使用的应该就是字符串。可以说字符串对象很基础，也很重要。

那么今天想跟大家聊聊 Redis 字符串相关实现，来看下这个看起来简单的字符串，为什么实现起来确实不简单？

看完这篇文章你可以学到：

  • Redis 字符串对象多种数据结构
  • 底层数据结构转换关系
  • SDS 动态字符串
  • Redis 采用 C 语言实现，那么字符串为什么不直接使用 C 语言的字符串？

Redis 对象

每当我们在 Redis 中保存一对新的键值对时，Redis 至少会创建两个对象，一个对象用作保存键，而另一个对象用作保存值。

Redis 中每个对象都是一个 redisObject 结构，这个结构中有三个属性：

  • type，表示对象的类型
  • encoding，表示编码
  • pstr，指向底层数据结构的指针

type 代表对象类型，目前可以使用类型为：

  • 字符串对象
  • 列表对象
  • 哈希对象
  • 集合对象
  • 有序集合对象

我们可以使用 Redis 的 TYPE 指令，查看当前键对应值对象类型。

Redis 键对象说起来很简单，它总是是一个字符串对象，而值对象就相对复杂了，它可以是字符串，也可以是集合，也可以是字典等对象。

每个对象类型底层实现的时候将会采用了多种数据结构，而 encoding 代表底层数据结构类型：

我们可以使用 Redis 的 OBJECT ENCODING 指令查看一个当前键值对象底层的编码：

每个对象类型，可能支持多种数据结构，关系如下：

Redis 字符串对象

Redis 字符串对象底层支持三种数据结构，分别是(下面使用 OBJECT ENCODING 输出)：

  • int
  • embstr
  • raw

int 代表 long 类型的整数，只要字符串对象中保存的是一个整数值，就将会使用 int 。

这里需要注意，只有整数才会使用 int，如果是浮点数， Redis 内部其实先将浮点数转化为字符串值，然后再保存。

embstr 与 raw 类型底层的数据结构其实都是 SDS (简单动态字符串)，Redis 内部定义 sdshdr 一种结构。

那这两者的区别其实在于，embstr类型将会调用内存分配函数，分配一块连续的内存空间，空间中依次包含 redisObject 与 sdshdr 两个数据结构。

而 raw 类型将会调用两次内存分配函数，分配两块内存空间，一块用于包含 redisObject结构，而另一块用于包含 sdshdr 结构。

SDS 简单动态字符串

接下来我们来看下简单动态字符串。

sdshdr

sds 底层的结构包含三个属性：

  • len，用于记录下面 buf[] 数组已使用的长度，即等于 SDS 所保存的字符串长度
  • free，用于记录下面buf[] 数组未使用长度
  • buf[],用户保存字符串

这里我们需要注意了，buf[]数组中最后一个字节将会保存一个空字符 \0,代表字符串结束。sdshdr 结构中的 len 长度是没有包含这个这一个空字符。

这一点设计上与 C 语言的字符串相同。

SDS 扩容

当我们对 SDS 字符串进行增长操作，如果 SDS 空间不足，SDS 将会先进行扩容，然后再执行修改操作。

假设当前 SDS 值如下所示：

现在执行一次字符串拼接指令，

1
APPEND sds " Cluster"

由于拼接完成之后字符串总长度为 13，SDS 剩余空间不足，所以 SDS 将进行扩容，重新执行一次内存重分配。

由于我们上面的例子，SDS 修改之后的长度（即 len 属性值）小于 1MB，那么程序将会分配和 len 属性同样大小的未使用空间，此时 SDS 中 len 属性与 free 属性值相同。

此时 SDS buf 数组的实际长度为：

1
13+13+1=27

如果 SDS 修改之后长度大于 1MB，那么 Redis 将会分配 1MB的未使用空间。

假设进行修改之后，SDS len 属性变为 20MB，那么程序将会分配 1 MB 的未使用空间，此时 SDS buf 数组的实际长度为：

1
20MB+1MB+1byte

接着上面的例子，如果我们再次执行字符串拼接指令：

1
APPEND sds " Guide"

这次 SDS 未使用空间足够保存拼接字符串，所以这次不需要重新分配内存。

SDS 惰性空间释放

当我们对字符串进行缩减操作， SDS 字符串值将会被缩短，这样 SDS 剩余空间将会变多。

此时程序不会立即就使用内存分配函数回收多余空间，而是使用 free 属性记录多余空间，等待后面使用。

通过这种惰性空间释放策略，SDS 避免字符串缩短所需内存重分配操作，后续 SDS 字符串增长，可以直接使用多余的空间。

当然 SDS 也有相应的 API，可以真正释放 SDS 未使用的空间，所以不用担心惰性释放策略带来的内存浪费。

为什么 Redis 不直接使用 C 语言字符串？

Redis 底层使用 C 语言编程，那么其实 C 语言也有字符串，Redis 完全可以复用 C 语言字符串~

那么为什么 Redis 还要闭门造车，重新设计一个 SDS 数据结构呢？

这是因为 C 原因这种简单的字符串形式，在安全性，效率以及功能方面不满足 Redis 需求。

首先如果我们需要获取 C 语言字符串的长度，我们可以使用以下函数：

1
strlen(str)

strlen函数实际上使用遍历的方式，对每个字符计数，直到遇到代表字符串结束的空字符。

这个操作时间复杂度 O(N)。

而 SDS 由于 len 记录当前字符串的长度，所以直接读取即可，时间复杂度仅为 O(1)。

这就确保获取字符串长度的操作不会成为 Redis 性能瓶颈。

第二点每次增长或缩短 C 语言的字符串将会进行内存的重分配，否则可能导致缓冲区溢出，也有可能导致内存泄漏。

而 SDS 由于使用空间预分配的策略，如果 SDS 连续增长 N 次，内存重分配的次数从必定 N 次降低为最多 N 次。

第三点，C 语言字符串不能包含空字符，否则第一个空字符将会被误认为字符串结尾，这就大大限制使用的场景。

而 SDS 中由于可以使用 len 属性的值判断字符串是否结束，所以没有这种困扰。

所以 SDS 字符串是二进制安全的。

字符串对象底层数据结构转换

SDS 结构由于需要额外的属性记录长度以及未使用长度，虽然这样减少系统的复杂度，提高了性能，但是还是付出相应的代价，即存在一定内存空间浪费。

所以 Redis 字符串对象底层结构并不都是采用了 SDS。

如果字符串对象保存的是整数值，那么这个整数值将会直接保存在字符串对象结构的 ptr 属性。

如果保存不是整数，但是字符串长度小于等于 39 字节，那么字符串将会使用 embstr编码方式。 最后上述两个都不满足才会使用 raw 编码方式。

另外，int 编码与 embstr，在一定条件也将会转换为 raw 编码格式。

如果对底层整数执行追加操作，使其不再是一个整数，则字符串对象的编码就会从 int 变为 raw。

对于 embstr 编码，实际其实只读的，这是因为 Redis 底层并没有提供任何程序修改 embstr 编码对象。

所以一旦我们对embstr 编码字符串进行修改，字符串对象的编码就会从 embstr 变为 raw。

总结

Redis 字符串是我们平常操作最频繁的数据结构，了解底层字符串对象，对于我们了解 Redis 非常重要的。

Redis 字符串对象底层结构可以分为整数与 SDS，当我们在操作 set 命令保存整数时，就将会直接使用整数。

而 SDS 是 Redis 内部定义另一种结构，相比于 C 语言字符串，它可以快速计算字符串长度，不需要频繁的分配的内存，最终要一点 SDS 是一种二进制安全的字符串。

SDS 设计虽然带来的很多优势，但是这种结构相比于 C 语言，至少多占用 4(len)+4(free)=8 字节内存，如果 buf []数组还存在没有使用的空间，空间浪费更加严重。

所以 Redis 字符串不是万金油，某些场景下可能会占用大量内存。但是如果换一种数据结构，可能内存占用就会变少。

所以我们一定要基于合适场景使用合适的数据机构。

站在巨人的肩膀

  1. Redis 设计与实现
阅读全文 »

发表于 | 分类于

阿粉最近看了一场架构师之路沈剑老师的一场直播，最近又重温了一下，根据自己的认知总结了一下，分享给大家。

MQ 想必大家或多或少都用过，接入 MQ 之后的整体架构如下：

可以看到使用 MQ 之后，上下游通信就变成图上的这种方式。

这种跨进程的通信方式，我们还有一种常用的解决方案，使用 Dubbo 等这类 RPC 服务。

理论上使用 RPC 的跨进程通信的场景，使用 MQ 也能解决，当然反过来也能说通。

那为什么不都用 RPC，或者 MQ 来解决那？

这其实都是业务场景决定的，抛开业务场景来谈架构都是耍流氓！没有全能的架构，只要适合的架构。

下面我们来看看那些场景适合 RPC，而那些场景适合 MQ。

RPC 场景

使用 RPC 的场景一般都是上游服务需要实时依赖下游服务的返回。

我们以一个登录服务为例，架构图如下：

用户发起的登录请求首先由对外的 WEB 服务接受，然后 WEB 服务服务调用用户服务查询用户信息，然后比对用户密码。

也就是说我们的 WEB 应用需要实时依赖用户服务返回的用户信息，如果没有返回，这次登录将会失败。

假如这个场景我们用 MQ 代替， WEB 应用发送 MQ 消息之后，然后流程就结束了，此时 WEB 应用无法拿到用户信息。

所以说对于这种需要强依赖下游返回的场景，使用 MQ 将会带来以下不足：

  • 上游无法直接得到下游结果
  • 增加一个 MQ 组件，系统更复杂

MQ 场景

上游不关心下游结果的场景

举个例子，在我们第三方支付系统中，每支付成功一笔，都需要计算手续费。

这个场景我们显然可以使用 RPC 完成调用，但是实际上，支付系统是不关心的计费系统的结果，两个系统不存在直接强依赖的关系。

大家可以想象一下，用户实际上已经收到银行卡扣款短信了，但是支付系统因为计费系统失败，导致对外返回是失败的结果。这对于用户来讲，不能接受啊。我都付钱了，你却告诉我支付异常。

所以对于这种场景，直接使用 RPC 调用由以下几点不足：

  • 系统整体调用延时增加
  • 下游服务异常，影响上游服务。两者物理以及逻辑依赖严重
  • 若后面再增加一个下游系统，需要知道支付成功的结果，上游系统需要改动代码。这种情况对于上游情况来讲，就会很烦。明明与上游系统没有什么关系，却需要修改代码。

那一定要用 MQ 解决吗？

其实不一定，对于我们上面举的场景，我们其实可以使用异步 RPC 或者线程池异步调用 RPC 就可以解决。

毕竟增加一个 MQ， 系统就变得更加复杂，我们还要单独运维 MQ，这对于小团队来讲，工作量还是很大的。

但是这种方式，还是解决不了，增加一个下游系统，上游系统还要改动的代码囧境。

增加 MQ 解耦

这个场景使用 MQ 解耦，带来几点优点：

  • 任务一：上游系统执行时间变短
  • 任务二：上下游逻辑解耦，物理解耦
  • 任务三：最重要一点，增加一个下游服务，其只要订阅即可，上游服务无需要改动代码

数据驱动的定时任务场景

举个例子，支付公司每日都需要对账，主要目的是核实自己系统的应收的钱与支付渠道端是否一致，主要流程分为以下几步：

  • 定时任务下载渠道对账文件，下载方式可能为 Http 接口下载，也有可能 SFTP 下载
  • 定时任务解析对账文件，然后将对账数据入库
  • 定时任务将自己本端支付数据与对账数据核对

上面的定时任务使用 Spring-Schedule 调度，假设各个定时任务下载时间如下所示：

上图中三个任务，任务二需要依赖任务一完成，而任务三有需要依赖任务二完成。

我们之前使用这种模式，通常会碰到几个问题：

  • 通常 06:00 就能下载到对账文件，但是有时候渠道端对账文件延迟，就会导致任务一执行失败，这样就会后续两个定时任务也会执行失败
  • 假设任务二数据过多，执行时间过长，任务三执行时还没结束，这就导致任务三无法拿到全量数据，导致对账异常
  • 整体任务执行时间过长
  • 任务一若调整时间，可能导致任务二，任务三都需要调整时间

使用 MQ解耦

使用 MQ 解耦之后架构图如下：

这种方式，只要任务一的定时任务准时启动，任务一完成之后发送 MQ 消息，任务二收到之后就会启动任务，结束之后再发送消息给 MQ。任务三流程同任务二

使用这种方式存在优点为：

  • 下游任务只要收到消息就能立刻执行，不需要额外等待，整体任务执行时间变短
  • 上游任务时间变动，无需修改下游任务时间。我们这个例子，只需要任务一的实际即可

总结

对于上游需要关注下游返回结果的场景，不适合使用 MQ。

适合使用 MQ 的场景有：

  • 上游不关心下游结果的场景
  • 数据驱动的定时任务依赖

阅读全文 »

发表于 | 分类于

Hello 大家好，我是阿粉，不知道你有没有遇到过这种场景，一套代码部署在不同的环境中，随着时间的过去，各个环境代码有版本差异，代码层面可以通过不同的版本来控制，但是数据库层面经常容易忘记更新！

阅读全文 »

发表于 | 分类于

在开始之前，咱们要知道：如果我的 SQL 语句执行的足够快，还有没有必要去做优化？

完全没有必要对吧

所以我们一般说，要给 SQL 做个优化，那肯定就是这条 SQL 语句执行的比较慢了

那么，为什么它会执行比较慢呢？

SQL 语句执行较慢的 3 个原因

没有建立索引，或者索引失效导致了 SQL 语句执行较慢

这个应该是比较好理解的，如果数据比较多，在千万级别以上，然后呢又没有建立索引，在这千万级别的数据中查找你想要的内容，简直就是在肉搏啊（哎呦，可了不得，竟然敢肉搏

索引失效这块内容说起来就比较多了，比如在查询的时候，让 like 通配符在前面了，比如经常念叨的“最左匹配原则”，又比如我们在查询条件中使用 or ，而且 or 前后条件中有一个列没有索引，等等这些情况都会导致索引失效

锁等待

常用的存储引擎主要有 InnoDB 和 MyISAM 这两种了，前者支持行锁和表锁，后者就只支持表锁

如果数据库操作都是基于表锁的话，意思就是说，现在有个更新操作，就会把整张表锁起来，那么查询的操作都不被允许，所以就不要说提高系统的并发性能了

  • 聪明的你肯定就知道了，既然 MyISAM 只支持表锁，那么使用 InnoDB 不就好了？你以为 InnoDB 的行锁不会升级成表锁嘛？ too young too simple ！

  • 如果对一张表进行大量的更新操作， mysql 就觉得你这样用会让事务的执行效率降低，到最后还是会导致性能下降，这样的话，还不如把你的行锁升级成表锁呢

  • 还有一点，行锁可是基于索引加的锁，在执行更新操作时，条件索引都失效了，那么这个锁也会执行从行锁升级为表锁

不恰当的 SQL 语句

这个也比较常见了，啥是不恰当的 SQL 语句呢？就比如，明明你需要查找的内容是 name ， age ，但是呢，为了省事，直接 select * ，或者在 order by 时，后面的条件不是索引字段，这就是不恰当的 SQL 语句

优化 SQL 语句

在知道了 SQL 语句执行比较慢的原因之后，接下来要做的就是对症下药了

针对 没有索引/索引失效 这块，最有效的办法就是 EXPLAIN 语法了，那你知不知道 Show Profile 也可以嘞

针对 锁等待 这块，没办法了，只能自己多注意

针对 不恰当的 SQL 语句 这块，介绍几个常用的 SQL 优化，比如分页查询怎么优化一下可以查询的更快一些呀，你不是说 select * 不是正确的打开方式嘛？那什么是正确的 select 方式呢？别急嘛，阿粉下面都会说到的

废话不多说，咱们开始了

先来个表

为了确保优化后的结果和我写的一样（起码 90% 是相符的

所以咱们用一样的数据库好不好？乖~

首先建个 demo 的数据库

接下来咱们建表，就建个非常简单的表好不好

1
2
3
4
5
6
CREATE TABLE demo.table(
	id int(11) NOT NULL,
	a int(11) DEFAULT NULL,
	b int(11) DEFAULT NULL,
	PRIMARY KEY(id)
) ENGINE = INNODB

然后插入 10 万条数据

1
2
3
4
5
6
7
8
9
10
11
DROP PROCEDURE IF EXISTS demo_insert;
CREATE PROCEDURE demo_insert()
BEGIN
    DECLARE i INT; 
		SET i = 1;
    WHILE i <= 100000 DO
        INSERT INTO demo.`table` VALUES (i, i, i);
        SET i = i + 1 ;
    END WHILE;
END;
CALL demo_insert();

OK ，准备工作做好了，接下来开始实战

通过 EXPLAIN 分析 SQL 是怎样执行的

只要说 SQL 调优，那就离不开 EXPLAIN

EXPLAIN SELECT * FROM table WHERE id < 100 ORDER BY a;

咱们能够看到有好几个参数:

  • id :每个执行计划都会有一个 id ，如果是一个联合查询的话，这里就会显示好多个 id

  • select_type :表示的是 select 查询类型，常见的就是 SIMPLE (普通查询，也就是没有联合查询/子查询), PRIMARY (主查询), UNION ( UNION 中后面的查询), SUBQUERY (子查询)

  • table :执行查询计划的表，在这里我查的就是 table ，所以显示的是 table， 那如果我给 table 起了别名 a ，在这里显示的就是 a

  • type :查询所执行的方式，这是咱们在分析 SQL 优化的时候一个非常重要的指标，这个值从好到坏依次是: system > const > eq_ref > ref > range > index > ALL

    • system/const :说明表中只有一行数据匹配，这个时候根据索引查询一次就能找到对应的数据

    • eq_ref :使用唯一索引扫描，这个经常在多表连接里面，使用主键和唯一索引作为关联条件时可以看到

    • ref :非唯一索引扫描，也可以在唯一索引最左原则匹配扫描看到

    • range :索引范围扫描，比如查询条件使用到了 < ， > ， between 等条件

    • index :索引全表扫描，这个时候会遍历整个索引树

    • ALL :表示全表扫描，也就是需要遍历整张表才能找到对应的行

  • possible_keys :表示可能使用到的索引

  • key :实际使用到的索引

  • key_len :使用的索引长度

  • ref :关联 id 等信息

  • rows :找到符合条件时，所扫描的行数，在这里虽然有 10 万条数据，但是因为索引的缘故，所以扫描了 99 行的数据

  • Extra :额外的信息，常见的有以下几种

    • Using where :不用读取表里面的所有信息，只需要通过索引就可以拿到需要的数据，这个过程发生在对表的全部请求列都是同一个索引部分时

    • Using temporary :表示 mysql 需要使用临时表来存储结果集，常见于 group by / order by

    • Using filesort :当查询的语句中包含 order by 操作的时候，而且 order by 后面的内容不是索引，这样就没有办法利用索引完成排序，就会使用”文件排序”,就像例子中给出的，建立的索引是 id ， 但是我的查询语句 order by 后面是 a ，没有办法使用索引

    • Using join buffer :使用了连接缓存

    • Using index :使用了覆盖索引

如果对这些参数了解的非常不错，那么 EXPLAIN 这块内容就难不住你了

Show Profile 分析下 SQL 执行性能

通过 EXPLAIN 分析执行计划，只能说明 SQL 的外部执行情况，如果想要知道 mysql 具体是如何查询的，需要通过 Show Profile 来分析

可以通过 SHOW PROFILES; 语句来查询最近发送给服务器的 SQL 语句，默认情况下是记录最近已经执行的 15 条记录，如下图我们可以看到:

我想看具体的一条语句，看到 Query_ID 了嘛？然后运行下 SHOW PROFILE FOR QUERY 82; 这条命令就可以了:

可以看到，在结果中， Sending data 耗时是最长的，这是因为此时 mysql 线程开始读取数据并且把这些数据返回到客户端，在这个过程中会有大量磁盘 I/O 操作

通过这样的分析，我们就能知道， SQL 语句在查询过程中，到底是 磁盘 I/O 影响了查询速度，还是 System lock 影响了查询速度，知道了病症所在，接下来对症下药就容易多了

分页查询怎么可以更快一些

在使用分页查询时，都会使用 limit 关键字

但是对于分页查询，其实还可以优化一步

我这里给出的数据库不是太好，因为它太简单了，看不出来有什么区别，我使用目前项目上正在用的表来做个实验，可以看下区别（使用的 SQL 语句如下面）:

1
2
3
4
EXPLAIN SELECT * FROM `te_paper_record` ORDER BY id LIMIT 10000, 20;

EXPLAIN SELECT * FROM `te_paper_record` WHERE id >= ( SELECT id FROM `te_paper_record` ORDER BY id LIMIT 10000, 1) LIMIT 20;

上面一张图片，我没有使用子查询，可以看到执行了 0.033s ，下面的查询语句，我使用了子查询去做优化，能够看到执行了 0.007s ，优化的结果还是很显而易见的

那么，为什么使用了子查询，查询的速度就提上来了呢，这是因为当我们没有使用子查询时，查询到的 10020 行数据都返回回来了，接下来要对这 10020 行数据再进行过滤操作

那可不可以直接就返回需要的 20 行数据呢，这样就不需要再做过滤操作了，直接返回就可以了嘛

你也太聪明了吧。子查询就是在做这件事情

所以查询时间上有了一个很大的优化

正确的 select 打开方式

在查询时，有时为了省事，直接使用 select * from table where id = 1 这样的 SQL 语句，但是这样的写法在一些环境下是会存在一定的性能损耗的

所以最好的 select 查询就是，需要什么字段就查询什么字段

一般在查询时，都会有条件，按照条件查找

这个时候正确的 select 打开方式是什么呢？

如果可以通过主键索引的话， where 后面的条件，优先选择主键索引

为什么呢？这就要知道 MySQL 的存储规则

MySQL 常用的存储引擎有 MyISAM 和 InnoDB ， InnoDB 会创建主键索引，而主键索引属于聚簇索引，也就是在存储数据时，索引是基于 B+ 树构成的，具体的行数据则存储在叶子节点

也就是说，如果是通过主键索引查询的，会直接搜索 B+ 树，从而查询到数据

如果不是通过主键索引查询的，需要先搜索索引树，得到在 B+ 树上的值，再到 B+ 树上搜索符合条件的数据，这个过程就是“回表”

很显然，回表能够产生时间。

这也是为什么建议， where 后面的条件，优先选择主键索引

其他调优

看完上面的，心里应该就大概有数了， SQL 调优主要就是建立索引/防止产生锁等待/使用恰当的 SQL 语句去查询

但是，如果问你除了索引，除了上面这些手段，还有没有其他调优方式

啥？竟然还有？！

有的，这就需要跳出来，不要局限在具体的 SQL 语句上了，需要在数据库设计之初就考虑好

比如说，我们常说的要遵循三范式，但是在有的业务场景里面，如果在数据库里面多几个冗余字段的话，可能要比严格遵循三范式带来的性能要好很多。

但是这点就及其考验平时的积累了，阿粉在这里把这一点提出来之后，希望读者们可以看看自己项目上目前用的数据库有没有多余的字段，为什么要这样设计呢？这样多去观察，你的技术能力想不提高都很难

以上，就这样啦~

阅读全文 »

发表于 | 分类于

前几天阿粉的公司不是在进行CodeReview吗，而在此期间，不光进行了CodeReview，而且间接的也进行了代码的重构，这时候阿粉就不得自己开始研究这个代码重构这块的事情了，于是砸锅卖铁的买了这个《重构：改善既有的代码设计》这本书，看了几篇文章，确实有一些心得，阿粉也是把自己的心得体会一点点的分享给大家。

阅读全文 »

发表于 | 分类于

Hello 大家好，我是阿粉，转眼已经到八月份了，好久也没有给大家介绍知识星球的动态了，今天给大家看下星球七月份的一些优质的分享，有专业技术的，有职场生涯的，有干货分享的，也有解答疑惑的，下面我们来看下吧。

阅读全文 »

发表于 | 分类于

作为对象的创建模式，单例模式确保其某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类。

阅读全文 »

发表于 | 分类于

模版模式又叫模板方法模式，在一个方法中定义算法的骨架，而将一些步骤延迟到子类中去实现。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

阅读全文 »

发表于 | 分类于

最近阿粉的同事们在准备面试，其中也有收到offer的几个不错的人，毕竟疫情稳定了，而阿粉在电话面试的时候，被问到关于HTTP协议的内容的时候，却显得有点麻木了，为什么呢？因为套路太深了，让阿粉猝不及防呀。 <–more–>

面试官：你了解TCP/IP协议么？

说实话在阿粉听到这个问题的时候，阿粉的第一想法就是，我回答了这个问题，接下来肯定还有一个三次握手和四次挥手等着我，但是还是得回答呀，于是阿粉就开始作答了。

阿粉开始作答：TCP/IP协议虽然会放在一起说，但是他们其实呢是属于两个不同的协议。

  • IP协议：

    1
      IP协议实际上是用来查找地址的，而它对应的层级也是网络层，也可以称之为网际互联层，区别不大，叫法不同而已。

  • TCP协议：

    1
      TCP协议是用来规范传输规则的，和IP协议是不同的，而它对应的层级是传输层，而这样的话，也就是IP去寻找地址，把所有的传输任务都交给TCP，而TCP这时候就相当于一个快递员的身份出现并且存在。

面试官：那你说说什么是三次握手，什么是四次挥手吧

三次握手

大家看这个图，图是来自于百度搜索，而且百度上有各种各样的图，当你看到图的时候第一时间肯定是看不懂的，也就是只能通过这个画的标志的“线”来进行分析，其实这仅仅只是一个方面。

那么我们就来根据图来解析一下这个图中都代表了什么意思，图中存在着两个序号和三个不同的标志位其中有大小写容易混淆的呦。

序号：

  • seq：sequence number 的缩写，直译的话，序号，对没错，它就是序号，你没有翻译错，相信自己，而这个seq表示的则是自己传递的序号，TCP在传输的时候，其中的每一个字节，都会有一个序号，发送数据的时候，会把第一个数据的第一个序号发送给对方，就是我们所看到的第一步，而接收的这一方面，会按照这个序号来检查是否是一个连接完整的数据，如果说你数据是完整的，那么好，我们可以继续下一步，如果你不是完整的，那就重新传送呗，而这样的话也能保证数据的完整性不被破坏。

  • ack：注意，这是小写的ack，也就是acknoledgement number的缩写，而他表示的是确认号，这个要和ACK(确认位)进行区分，接收端这时候用它来给发送端返回成功接收消息的数据信息，而这时候，它的值就是表明，我现在想接收下一个数据包了，而这个值就是下一个数据包的开始的序号，而这个ack所代表的的值的序号前面的数据都已经接收成功了。

  • ACK：确认位，确认位来了，只有当ACK=1的时候ack才会起到自己应该起的作用，而在我们第一次发起请求的时候，因为没有需要我们确认的接收的数据，所以这个时候的ACK就是0，而正常通信的情况下，ACK就1.

  • SYN：同步位,而同步位的作用就是用于建立连接时同步序号，而刚连接的时候，说ACK是0，那么ack就不起作用，这时候SYN就来说，你看没我你们不行了把，要你们有何用，当接收端接收到SYN=1的报文的时候，就会将ack设置为接收到的seq+1的值，这也是大家在看百度上提供的内容的时候看到的，各种seq=k，ACK=k+1,这玩意就是这么来的，这时候ack的值就是根据SYN来直接设置的，这样你才能正常的进行传输，而SYN有时候会被面试官问到为什么在前两次握手的时候都是1呢？其实这是因为传输数据的双方的ack都是要一个初始值的，不然你还怎么传输，还怎么玩。

  • FIN：终止位，这个在本图中，并没有完全的体现，在四次挥手的时候就能完全的体现出来了。而它则是用来在数据传输都完成之后来释放连接的。

那么关于这个图，我们怎么给面试官说呢？

(1) 第一次握手(SYN=1, seq=x):

客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。

发送完毕后，客户端进入 SYN_SEND 状态。

(2) 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。 发送完毕后，服务器端进入 SYN_RCVD 状态。

(3) 第三次握手(ACK=1，ACKnum=y+1)

客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1

发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。

你如果这么说，面试官有可能还会问，你这也太官方了，能不能说说你的理解，那么你可以用一个实际上的例子来给他说一下，

阿粉：鸡丁，嘿，我是阿粉，你听的到我说话么？

鸡丁：吵吵啥，听到了，除了你我还能认识谁。

阿粉：你听的到你还不赶紧回复，怪不得你没有女朋友呢。那我们再继续交流一下吧。

而这三次的对话过程就是通俗的三次握手，期间对话三次，以此来确定两个方向上的数据传输通道是否正常。

四次挥手

那么四次挥手怎么来回答呢？

(1)第一次挥手(FIN=1，seq=x)

假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。

发送完毕后，客户端进入 FIN_WAIT_1 状态。

(2) 第二次挥手(ACK=1，ACKnum=x+1)

服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。

发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

(3) 第三次挥手(FIN=1，seq=y)

服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。

发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

(4) 第四次挥手(ACK=1，ACKnum=y+1)

客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。

服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。两次后会重传直到超时。如果多了会有大量半链接阻塞队列。

那么怎么去通俗的给面试官说呢？

阿粉：鸡丁呀，我要说的都说完了，你还有啥事么？

鸡丁：你说的我都明白了，但是别断，我还有要嘱咐你的，给我找女朋友的事情。

鸡丁：xxxxx，我说完了。

阿粉，行啦，别BB了，记住了，挂了把。

如果面试官问你的时候，你这么回答的话，既有官方的解释，还有本身自己的理解，那么这个问题就已经算是差不多了，

而面试官显然不可能会这么放过你，肯定再给你来个雷，为啥是三次握手，而是四次挥手呢？为啥不是三次呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方ACK和FIN一般都会分开发送。所以这时候挥手的时候就是四次，而不再是三次了。

那么我们怎么去手写一个HTTP协议呢？代码送上：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
public class Server {
    public static void main(String[] args) throws Exception{
        ServerSocketChannel ssc = ServerSocketChannel.open();
        ssc.socket().bind(new InetSocketAddress(8080));
        ssc.configureBlocking(false);
        Selector selector = Selector.open();
        ssc.register(selector, SelectionKey.OP_ACCEPT);
        while (true){
            if (selector.select(3000)==0){
                continue;
            }
            Iterator<SelectionKey> keyIterator = selector.selectedKeys().iterator();
            while (keyIterator.hasNext()){
                SelectionKey key = keyIterator.next();
                new Thread(new HttpHandler(key)).run();
                keyIterator.remove();
            }
        }
    }
    private static class HttpHandler implements Runnable{

        private int bufferSize = 1024;
        private String localCharset = "UTF-8";
        private SelectionKey key;
        public HttpHandler(SelectionKey key){
            this.key=key;
        }

        public void handleAccept()throws IOException{
            SocketChannel clientChannel = ((ServerSocketChannel)key.channel()).accept();
            clientChannel.configureBlocking(false);
            clientChannel.register(key.selector(),SelectionKey.OP_READ, ByteBuffer.allocate(bufferSize));
        }

        @Override
        public void run() {
            try {
                if (key.isAcceptable()){
                    handleAccept();
                }
                if (key.isReadable()){
                    handleRead();
                }
            }catch (IOException e){
               e.printStackTrace();
            }
        }

        public void handleRead() throws IOException{
            SocketChannel sc = (SocketChannel) key.channel();
            ByteBuffer buffer = (ByteBuffer) key.attachment();
            buffer.clear();
            if (sc.read(buffer)==-1){
                sc.close();
            }else {
                buffer.flip();
                String receiveString = Charset.forName(localCharset).newDecoder().decode(buffer).toString();
                String[] requestMessage = receiveString.split("\r\n");
                for (String s:requestMessage) {
                    System.out.println(s);
                    if (s.isEmpty()){
                        break;
                    }
                    String[] firstLine = requestMessage[0].split(" ");
                    System.out.println();
                    System.out.println("Method:\t"+firstLine[0]);
                    System.out.println("url:\t"+firstLine[1]);
                    System.out.println("HTTP Version:\t"+firstLine[2]);
                    System.out.println();

                    StringBuffer sendString = new StringBuffer();
                    sendString.append("HTTP/1.1 200 OK\r\n");
                    sendString.append("Content-Type:text/html;charset="+localCharset+"\r\n");
                    sendString.append("\r\n");
                    sendString.append("<html><head><title>显示报文</title></head><body>");
                    sendString.append("接受到的请求报文是：<br/>");
                    for (String s1:requestMessage) {
                        sendString.append(s1+"<br/>");
                    }
                    sendString.append("</body></html>");
                    buffer = ByteBuffer.wrap(sendString.toString().getBytes(localCharset));
                    sc.write(buffer);
                    sc.close();
                }
            }

        }

    }
}

这这是一个简单的实现，只是实现思路，并不是真正的处理请求，而大家也要注意设置Content-Type的类型，不然容易出问题的，毕竟长度是有限制的。 文章参考 《HTTP协议详解》 《TCP/IP协议详解》

阅读全文 »

发表于 | 分类于

在实际项目中，经常需要用到邮件通知功能。比如，用户通过邮件注册，通过邮件找回密码等；又比如通过邮件发送系统情况，通过邮件发送报表信息等等，实际应用场景很多。

正常我们会用 JavaMail 相关 api 来写发送邮件的相关代码，但现在 SpringBoot 提供了一套更简易使用的封装。这篇文章，阿粉就带大家通过 SpringBoot 快速的实现发送邮件的功能。

阅读全文 »

发表于 | 分类于

Hello 大家好，我是阿粉，作为团队中的主程阿粉经常参与很多核心功能的开发，而且很多时候一个需求没做好中间又插入新的紧急的需求或者 bug 修复，每次遇到这种情况，如果两个地方代码不冲突的话还好，可以直接在本分支修改然后提交，但是当遇到需要修改同一个类文件的时候就比较麻烦了。这种情况如何优雅的处理呢？让阿粉来带你了解 Git 的高级骚操作！

阅读全文 »