Hello，大家好，我是阿粉，最近互联网大厂频繁有动静出来，先是滴滴被下架二十多款 APP，后面有快手，字节宣布取消大小周，再有京东宣布涨薪两个月，这边 7.13 号晚 B站也挂了。

滴滴下架 APP 我们就不说了，毕竟涉及到很多政治因素。关于字节取消大小周的事情，几家欢喜几家愁，据说有很大一部分员工是有意见的，因为毕竟字节加班是双倍工资的，如果说取消了大小周，每年可能会少了十多万的收入。相比很多 996 加班不给钱的公司，已经算是人性化了，所以最近阿粉的朋友圈就被很多在哭穷的字节大佬刷屏，表示不满但是有干不掉。

那边人家取消大小周，这边东哥宣布涨薪两个月，建议互联网大厂的老板都跟东哥学学，人狠话不多，直接涨薪就好了。那为什么东哥能这么豪横呢？简单来说就是不差钱啊！不过这次普遍涨薪的是 N序列，T 序列和 P 序列，分别就是管理，技术和项目三条线，不包含很多物流小哥，不过具体方案还没定下来，这对于有三十多万员工的京东来说，着实是一笔大手笔。为啥京东现在这么有钱呢？主要是京东一季度的净利润是 36 亿，同比增长两倍多。而且去年年底京东健康上市，今年京东物流又上市，所以一句话说那就是东哥有钱。

正在京东员工开心的回家跟老婆说要涨薪两个月的时候，7.13 号晚上，B 站的程序员就没那么幸运了，传来的却是服务挂了的噩耗。7.13 号晚上十点多的时候，阿粉准备上 B 站看看视频（别想多了，正经的），结果刷了半天出现了如下页面，抱着怀疑的心态，阿粉再试了几次，在确定阿粉网络没问题的情况下，阿粉用手机也试了一下，还是不行。同时各种群里都传来了消息，B 站挂了。

差不多等了一个小时，还是没有恢复，看来此次的事故不是简单的上线升级失败了，具体原因等官方回答吧。

最后阿粉说一句没经历过线上事故的人不知道这种线上事故的严肃性，可能就等着吃瓜，只有真正经历过这种事故的人才能真正从内心里面产生敬畏之心！

敬畏线上！

Hello，大家好，我是阿粉，最近看文章发现一个 Java 学习路线图的资料，觉得很不错就拿过来分享给大家，目前这个版本是 1.0 的，之所以说这个是 1.0 的版本主要是因为还有一些高级内容没有加进去，比如 JVM，容器，消息队列，云原生等都还没有提到，不过对于初学者来说这个路线图已经可以上手完成工作了。

作为 Java 程序员的阿粉不得不说，现在的小伙伴们是真的很幸福，互联网如此的发达，网上各种学习资料以及开源项目可以免费学习。虽然说这些资料方便了小伙伴们的学习，但是同样也会带来一个问题，那就是对于琳琅满目的资料显得无从下手，没有体系，不知道工作中到底会用到哪些，抓不到重点。这个时候 Java 学习路线图就可以起到一个辅助的作用了。

![]http://www.justdojava.com/assets/images/2019/java/image_ziyou/2021/0708/1.png)

Git

Git 作为目前最流行的版本控制软件没有之一，作为每个开发人员，不单单是 Java 程序员而是每个程序员都需要学习使用的。我们进入一家公司，刚开始的时候除了阅读文档之外能做的第一件事情就是把自己所在的小组的代码克隆下来。所以 git clone 相信是大家使用的第一个命令。另外虽然说都是在 IDE 里面使用git 的命令操作，但是还是强烈建议大家把 git 的常用命令给记下来，通过 git bash 或者其他命令窗口手动执行，可以加深大家这 git 的使用理解。如果说对于还没有步入职场的小伙伴没有实际的项目练手的话，可以考虑通过 GitHub 来练手。毕竟 GitHub 作为全球最大的同性网站，在互联网行业有着举足轻重的地位。

Linux

Linux 同样的作为后端程序员也是要学习的一个知识点，不过针对 Linux 我们刚开始可以先学习一些简单的基础，随着使用频率的增加再慢慢深入，毕竟很多时候我们在服务器上面查看日志，查找文件，以及编写一些简单的 shell 来处理一些任务。学习 Linux 我们需要循序渐进，毕竟一个操作系统要想完全搞透对于我们普通人来说那是不太可能的。

数据结构与算法

数据结构与算法这个更不用说了，是一个老生常谈的话题，虽然说在科班出身的在大学会学习相关内容，但是相信很多人都没有好好学习过，社会会告诉你该来的还是会来，有些东西是躲不掉的，除非不干这一行。学习数据结构和算法的唯一途径就是不断练习，而且一个题目要练习很多遍，尝试不同的方案去解决，只有这样才能熟练的掌握。刷题可以在 LeetCode 或者牛客网都是可以的，海量的题目足够练手。

通用编程技能

通用编程技能主要包含一些网络知识比如 HTTP，HTTPS，TCP，UDP，设计模式，可能很多时候大家会觉得真正在工作中这些东西用到的会很少，有必要学习吗？有必要！有必要！有必要！重要的事情说三遍，要知道我们的日常工作除了写业务代码之外，很多时候还会涉及到组件，框架的封装或者代码的阅读，这个时候如果不具备这部分的知识，那看起来会很吃力的。所以建议大家一定要把基础知识给打牢，这样才能再需要的时候得心应手。

Java

讲到这里终于到了核心模块，在 1.0 的路线图中 Java 的学习主要包含工具，JDK，框架，单元测试，数据库相关知识。这块的东西就相对较多了，而且很多内容都需要结合项目来实际操作才能更好的掌握，单独看资料代码是不怎么能掌握的。

工具

工具这块主要要学习 IDEA，Maven，Gradle 还有 Docker 容器部署相关的内容。图中的有些东西可以不用学，比如 Eclipse，ANT，这些现在很多公司都不用了，就没必要在浪费时间了，毕竟要学习的东西还有很多。JDK 这块的内容就更多了，1.0 的路线图中提到了集合，并发，IO，和 JDK8 的一些特性，这些内容需要好好的学习，因为在工作中占据了很大的一部分场景。并且如果在找工作面试的过程中也是必问的一些内容。特别是集合和并发这块的内容，阿粉经历的面试基本上都有被问到过相关的内容。IO 这块的内容是很多网络工具的底层核心，特别是一些 RPC 服务，底层的 Netty 都会使用到 IO 相关的内容。

框架

框架这边就更不用多说，现在 Java 主流的编程框架非 Spring，SpringBoot 莫属，这块的内容确实很难啃，需要找一些资料或者视频去学习，如果条件和时间允许的话也可以去报一些线上或者线下课程，这个根据自己的情况去决定就好。GitHub 上面也有很多基于 Spring，SpringBoot 的开源项目，特别是一些大公司开源的优秀项目，比如阿里的 Dubbo，SpringCloud Alibaba，都可以下载下来阅读一下。阿粉上家公司使用的微服务框架就是 SpringCloud Alibaba，他的注册中心 Nacos 是基于服务发现与配置中心一体的注册中心，还是挺好用的。

单元测试

单元测试这个也是一个很有必要学习的内容，优秀的代码单元测试的用例要覆盖 80% 以上才算合格，但是实际工作中往往很少会有人写单元测试。这个不是个好习惯，该写的单元测试还是要写的，这样再后续代码有所改动的时候我们可以直接测试一下，避免新的改动导致了新的 bug。关于测试框架 Mockito 公众号前几天有发过一篇介绍的文章，感兴趣的可以看看 Mockito。

数据库

线路图中的数据库主要想表达的是 JDBC 以及一些 ORM 的内容，其实关于数据库的知识是很复杂的，作为 Java 程序员只关注这么一点是不够的，特别是对于 MySQL 数据库，我们必须熟练的掌握，包括事务，锁，索引等内容，相应的内容大家可以看看公众前面的文章，有很多关于 MySQL 的内容。

上面的内容比较多，但是阿粉觉得还少了一个重要的内容，那就是前端知识，不会写页面的的 Java 开发不是一个好开发，简单的页面和 JS 我们还是要会写的，不说多么精通，至少能看懂代码并且能实现功能。

总结

今天给大家分享了一个 Java 学习路径图，可以帮助初学者更好的入门，对于我们程序员来说，真的有很多东西需要学习，新的技术层出不穷，唯一不变的就是变化。最后借用乔帮主的一句话：Stay foolish，Stay hungry!

作为一个 Java 开发，在面试的过程中垃圾回收器是经常会被问到的一个问题，随着 Java 的发展，垃圾回收器也经历了很多的发展。大家熟知的垃圾回收器主要有下面几种。

1. Serial 单线程新生代复制算法的垃圾回收器；
2. SerialOld 垃圾回收器，是一种单线程老年代标记整理算法；
3. ParNew 垃圾回收器，是 Serial 的多线程实现，采用复制算法实现；
4. Parallel Scavenge 垃圾回收器，是一种高效的多线程复制算法；
5. ParallelOld 垃圾回收器，是 Parallel Scavenge 的一种老年代的多线程标记整理算法；
6. CMS 垃圾回收器，是一种多线程标记清除算法，后面会详细介绍；
7. G1 垃圾回收器，是一种高吞吐量的垃圾回收器。

回收算法

在介绍垃圾回收器之前，我们先了解一下垃圾回收器背后的算法，每个垃圾回收器都是具体算法的实现，不同的垃圾回收器只是背后的算法不同而已，下面就先简单介绍下具体的算法。

标记清除

标记清除算法是一种先标记，后清除的算法，在第一次扫描的时候先标记出所有需要清理的内存，将所有需要回收的内存都标记过后，一次性清理掉。这种算法简单但是效率低，而且内存碎片化严重。内存一旦碎片化严重的话，就会浪费内存，无法分配较大的对象。

复制算法

复制算法的实现方式比较简洁明了，就是霸道的把内存分成两部分，在平时使用的时候只用其中的固定一份，在当需要进行 GC 的时候，把存活的对象复制到另一部分中，然后将已经使用的内存全部清理掉。这种算法可以解决碎片化的问题，但是缺点也很明显，就是浪费内存，有一半的内存都不能使用。

标记整理算法

既然标记清除和复制算法各有优缺点，那自然的我们就想到是否可以把这两种算法结合起来，于是就出现了标记整理算法。标记阶段是标记清除算法一样，先标记出需要回收的部分，不过清除阶段不是直接清除，而是把存活的对象往内存的一端进行移动，然后清除剩下的部分。

标记整理的算法虽然可以解决上面两个算法的一些问题，但是还是需要先进行标记，然后进行移动，整个效率还是偏低的。

分代回收算法

分代回收算法是目前使用较多的一种算法，这个不是一个新的算法，只是将内存进行的划分，不同区域的内存使用不同的算法。根据对象的存活时间将内存的划分为新生代和老年代，其中新生代包含 Eden 区和 S0，S1。在新生代中使用是复制算法，在进行对象内存分配的时候只会使用 Eden 和 S0 区，当发生 GC 的时候，会将存活的对象复制到 S1 区，然后循环往复进行复制。当某个对象在进行了 15 次GC 后依旧存活，那这个对象就会进入老年代。老年代因为每次回收的对象都会比较少，因此使用的是标记整理算法。

垃圾回收器

上面虽然提到了好几个垃圾回收器，但是目前主流的垃圾回收器只有 CMS 和 G1。下面就跟大家聊下这两个垃圾回收器。

CMS 垃圾回收器

CMS 全称 Concurrent Mark Sweep 并发标记清除垃圾回收器。CMS 是一种以获取最短停顿时间为目的的垃圾回收器。提到停顿时间，我们都知道任何垃圾回收器在进行工作的时候都会出现 STW，Stop the World 停止用户进程，这对业务来说只很难接受的，但是现在市面上所有的垃圾回收器都无法避免这个问题，只能最大化的去优化，从而降低停顿的时间。

CMS 虽然被称为是并发的垃圾回收器，但是也并不是完全并发的，从名字上我们可以看到是采用标记-清除算法来实现的，整个实现过程分为五个步骤：

1. 初始标记：暂停所有线程，从来可达性分析来标记对象，这也是 CMS 垃圾回收器第一个 STW 的时候；
2. 并发标记：并发标记的时候 GC 线程和用户线程是同时存在的，这个过程中会记录所有可达的对象，但是这个过程结束过后由于用户线程一直在运行所以还会产生新的引用更新，也就是需要下一步了；
3. 并发预清理：这个阶段用户线程和 GC 线程同时运行，GC 线程会进行一下预清理的动作；
4. 重新标记：重新标记这个阶段会暂停用户线程，将上一步并发标记过程中用户线程引起的更新进行修正，这个时间会比初始标记时间长，但是会比并发标记时间短一点；
5. 并发清除：在所有需要清理的对象都被标记完过后就会执行最后一步清理的动作。清理的时候用户线程是可以继续运行的，GC 线程只清理标记的区域。

G1 垃圾回收器

G1 全称 Garbage-First 是一种面向服务器的垃圾回收器，通过将堆内存划分为多个 Region 来实现可预测的停顿时间模型。在 G1 当中，新生代和老年代已经不再是物理隔离，而都是被划分一个个 Region 区域。正是由于这种可预测的时间停顿模型让 G1 成为了一个高吞吐量的垃圾回收器。G1 能充分利用 CPU，多核环境下可以缩短 STW 的时间。

G1 垃圾回收器的整个实现过程分为四个步骤：

1. 初始标记：通过可达性分析标记 GC Roots 的直接关联对象，这个阶段与 CMS 一样需要 STW；
2. 并发标记：并发标记是通过 GC Roots 找到存活的对象，这个阶段 GC 线程是与用户线程同时运行的，并且这个阶段的时间比初始标记长；
3. 最终标记：最终标记跟 CMS 的重新标记一样，也是为了修正并发标记过程中因用户线程继续运行而导致产生新的引用更新；同样的这里也需要 STW；
4. 筛选回收：筛选回收这里会对每个 Region 的回收成本进行排序，根据用户期望的停顿时间来制定收回计划，这也就是可预测的停顿时间模型的体现之处，这个阶段 GC 线程是与用户线程同时运行的。

总结

虽然说 Java 开发不用程序员去手动创建和回收内存，但是了解和掌握垃圾回收器是每个 Java 程序员必须要掌握的，不仅仅是面试的过程中会被问到，对自己的职业发展也是很有帮助的。本文是阿粉自己学习和整理的，部分资料参考网络上，分享给大家，帮助大家一起成长。

上一次的文章中，阿粉在面试官面前说了对启动流程不太理解，然后和他聊了一会，然后他又提出了你既然不是特别了解启动流程的话，那你对Tomcat的生命周期熟悉么？

前言

首先说下我们为什么需要分布式 ID，以及分布式 ID 是用来解决什么问题的。当我们的项目还处于单体架构的时候，我们使用数据库的自增 ID 就可以解决很多数据标识问题。但是随着我们的业务发展我们的架构就会逐渐演变成分布式架构，那么这个时候再使用数据的自增 ID 就不行了，因为一个业务的数据可能会放在好几个数据库里面，此时我们就需要一个分布式 ID 用来标识一条数据，因此我们需要一个分布式 ID 的生成服务。那么分布式 ID 的服务有什么要求和挑战呢？

要求

1. 全局唯一：既然是用来标识数据唯一的，那么一个分布式 ID 肯定要是全局唯一的，在同一业务下的每个服务下面都是一致的，不会变的，这是一个基本的要求；
2. 全局递增：递增这个也很好理解，我们要保证生成的 ID 是依次递增的，因为很多时候 ID 是给人看的，如果说不具备递增性，就缺乏了很多的可读性；
3. 信息安全：分布式 ID 的安全性也很重要，因为我们提到生成的 ID 是递增的，这就有可能会给竞争对手知道我们的 ID 的生成频率，这种在电商等场景会有很大的问题，但是这个往往跟全局递增有点冲突；
4. 高可用性：分布式 ID 的生成服务必须是高可用，毕竟一旦不能生成 ID，后续的所有服务都无法继续使用；

常见的分布式 ID 实现

在当下的互联网当中，根据业务场景以及需求的不同，对于分布式 ID 的实现有如下几种实现方式：

1. UUID；
2. Redis；
3. 变形的数据库自增 ID；
4. 推特雪花算法
5. 美团的 Leaf——雪花算法的变形；

UUID

写 Java 的朋友对 UUID 肯定不陌生，7dbb9f04-d15e-4c88-b74b-72a35e0d7580 这是一个标准的 UUID，虽然都说 UUID 是全球唯一，具备我们前面提到的要求中的第一点，但是很显然不具备全局递增，这种分布式 ID 可读性很差，如果说只是用来记录日志或者不需要人去理解的场景是可以用，但是不适合我们这里说的业务数据的唯一标识。而且这种无序的 UUID 如果作为主键会很严重影响性能。

Redis

Redis 有个 incr 的命令，这个命令是能保证原子递增的，在某种程度上也是可以生成全局 ID，不过使用 Redis 有两个问题：

1. 不美观，虽然说我们需要的是一个全局 ID，但是 incr 命令是从 1 开始的整型，所以会导致全局 ID 的长度不一致，虽然说也可以用来标识唯一业务数据，但是某些场景也缺少可读性，因为不携带日期信息；
2. 依赖 Redis 的高可用，因为 Redis 是基于内存的，为了保证 ID 的不丢失所以需要对 Redis 进行持久化，但是关于 Redis 的两种持久化的方式各有优缺点，详细的可以参考公众号之前的文章 面试官：请说下 Redis 是如何保证在宕机后数据不丢失的；

数据库自增 ID

前面我们提到单个数据库在分布式环境下已经没办法使用自增 ID 了，因为每个 MySQL 的实例自增 ID 都是从 1 开始，并且步长都按照 1依次递增，这种情况下我们很容易想到是不是可以考虑给每个数据库设置不同的步长。如果我们设置了不同的步长，这样就可以保证每个数据库实例都可以生成 ID，并且不会重复。虽然简单的系统可以这样用，但是也有几个问题：

1. 依赖数据库 DB，在分布式环境下，如果过多的依赖数据库是有风险的，无法支持高并发的情况，特别是对于一些电商交易的场景，每秒几十万的 QPS，数据库是扛不住的；
2. 不同数据库实例的数据不能直接关联上，需要额外的存储，才能把数据串起来，增加业务复杂度；

推特的雪花算法—— snowflake

snowflake 算法是推特开源的分布式 ID 生成算法，这个算法提供了一个标准的思路，很多公司都参考这个算法做了自己的实现，比较有名的是美团的 Leaf。这里我们就着重看下雪花算法是怎么实现的。

感兴趣的可以去参考文章 https://tech.meituan.com/2017/04/21/mt-leaf.html 看下美团的 leaf 的实现原理。

雪花算法的思想是化整为零，将分布式 ID 的生成分散到每个机房和机器上，采用一个 64 位 long 类型的的结构来表示一个 ID，64 的结构如下所示，第一位符号位 0，然后是 41 位的时间戳，接下来的 10 位是机房加机器，最后的 12 位是序列号。

上面这个结构是雪花算法的基本结构，不同公司根据自身的业务会进行相应的调整，有的可以采用 32 位或者其他位数，而且时间戳的位数也可以根据实际情况进行调整，10 位的 workerID 有机房的公司可以用机房加机器组成，没有机房的公司可以直接用机器来组成，序列位也可以根据情况适当调整。

我们可以简单算一下，41 位的时间位是2 ^ 41 / (365 * 24 * 3600 * 1000) = 69 年，每个机器每毫秒可以生成 2 ^ 12 = 4096 个 ID。

那是不是说我们这个代码只能运行 69 年呢？其实不是的，这里服务在启动的时候会设置一个初始值，这里的时间戳是用机器的时间减去初始值的差值。那 SnowFlake 算法有什么优缺点呢？

1. 因为有时间戳，所以满足自增的要求，同时也具备一定的可读性；
2. 化整为零每个服务在各自的机器上可以直接生成唯一 ID，只需要配置好机房和机器编号记刻；
3. 长度可以根据业务自行调整；
4. 缺点是依赖机器的时钟，如果说机器的时钟有问题，会导致生成的 ID 可能会重复，这个需要控制；

结合上面的原理，我们可以通过 Java 代码来具体实现，代码如下：

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

public class SnowFlakeUtil {

    //初始时间戳
    private final static long START_TIMESTAMP = 1624796691000L;
    //数据中心占用的位数
    private final static long DATA_CENTER_BIT = 5;
    //机器标识占用的位数
    private final static long MACHINE_BIT = 5;
    //序列号占用的位数
    private final static long SEQUENCE_BIT = 12;


    /**
     * 每一部分的最大值
     */
    private final static long MAX_SEQUENCE = ~(-1L << SEQUENCE_BIT);
    private final static long MAX_MACHINE_NUM = ~(-1L << MACHINE_BIT);
    private final static long MAX_DATA_CENTER_NUM = ~(-1L << DATA_CENTER_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;

    private final long idc;
    private final long serverId;
    private long sequence = 0L;
    private long lastTimeStamp = -1L;

    private long getNextMill() {
        long mill = System.currentTimeMillis();
        while (mill <= lastTimeStamp) {
            mill = System.currentTimeMillis();
        }
        return mill;
    }

    /**
     * 根据指定的数据中心ID和机器标志ID生成指定的序列号
     *
     * @param idc      数据中心ID
     * @param serverId 机器标志ID
     */
    public SnowFlakeUtil(long idc, long serverId) {
        if (idc > MAX_DATA_CENTER_NUM || idc < 0) {
            throw new IllegalArgumentException("IDC 数据中心编号非法！");
        }
        if (serverId > MAX_MACHINE_NUM || serverId < 0) {
            throw new IllegalArgumentException("serverId 机器编号非法！");
        }
        this.idc = idc;
        this.serverId = serverId;
    }

    /**
     * 生成下一个 ID
     *
     * @return
     */
    public synchronized long genNextId() {
        long currTimeStamp = System.currentTimeMillis();
        if (currTimeStamp < lastTimeStamp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }
        if (currTimeStamp == lastTimeStamp) {
            //相同毫秒内，序列号自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            //同一毫秒的序列数已经达到最大
            if (sequence == 0L) {
                currTimeStamp = getNextMill();
            }
        } else {
            //不同毫秒内，序列号置为0
            sequence = 0L;
        }
        lastTimeStamp = currTimeStamp;
        return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT | idc << DATA_CENTER_LEFT | serverId << MACHINE_LEFT | sequence;
    }

    public static void main(String[] args) {
        SnowFlakeUtil snowFlake = new SnowFlakeUtil(4, 3);
        for (int i = 0; i < 100; i++) {
            System.out.println(snowFlake.genNextId());
        }
    }
}

参考

1. 知乎·一口气说出9种分布式ID生成方式，面试官有点懵了
2. Leaf——美团点评分布式ID生成系统

Hello 大家好，我是阿粉，在了解什么是 Serveless 架构之前，我们先看下传统的项目发布和部署的流程是什么样子的。

物理机

最初的时候每个公司如果想发布自己的应用，则需要建设自己的机房，然后购买服务器主机，组装路由器交换机和网络，网络通了过后还要安装 Linux 系统以及安装各种软件，最后将开发完成的 Java 项目打包放到 Tomact 容器里面或者以 Jar 包的形式运行起来对外服务。这个过程好一点的公司是通过 Jenkins 等 CICD 的方式来完成的，但是更有很多公司是通过人工手动拷贝的方式来进行的。这种方式很容易出错，而且也不方便回滚，更无法应对高峰期的缩扩容。每次升级部署的时候都是一个很艰巨的任务，如果说业务初期这种方式还是可以的，不需要多大的成本，但是当我们的业务发展到一定程度的时候，需要开发的部署的服务越来越多的时候就不行了。

简单的形式如上图所示，在自建机房的时候还是要考虑很多细节问题的，比如机房温度往往都较高所以要安装空调；然后如何保证机房长期不断电，毕竟机房如果断电服务将不可用。

云主机

物理机的机房建设对于很多公司来说不会考虑，因为并没有相应的能力去建设。所以很多公司往往采用的是购买云主机的方式来部署服务，云主机的方式与物理机的区别就是不用自己去搭建机房，不用考虑机房的建设和机器的维护，这些都是云厂商负责。国内知名的云厂商有阿里云，腾讯云，华为云等。根据自己服务的要求我们可以选择购买对应配置的云主机，自有选择内存和硬盘以及带宽等配置。

虽然说云主机解决了我们不用建设机房的问题，但是在整个过程中我们依然需要关注服务器的状态，内存是不是不够了，磁盘是不是不够了，高峰期的时候需要及时购买服务器去扩容，低峰期的时候又不能立马退掉机器，对于我们开发或者运维的同学来说还是要对服务器进行管理。

对于很多公司来说目前的服务部署都是基于云主机的，通过购买云主机自建各种组件的集群用于支持自己的服务器，这无疑更加增加了对服务器的维护成本以及人力成本。

Serveless 架构

既然上面的架构都有缺点，那有没有一种方式可以免去开发同学和运维同学的一些烦恼呢？答案是肯定的，随着云原生开发模型的诞生 Serveless 架构被大家广泛提出。

Serveless 无服务器架构是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。

Serveless 架构中文是无服务器架构 ，是一种基于云原生的开发模型，虽然说的是无服务器但是并不代表不需要服务器，只是表示的是开发人员不需要关注服务器，只需要关注应用的构建即可。对于服务器可以做到透明，整个服务器的管理和维护完全由云厂商来负责，开发人员只需要将自己的应用打包到容器中即可对外提供服务。

同时在收费的方面也有了很大的变化，不管是上面自己搭建机房亦或是购买云主机，在服务不使用的时候依然会产生相应的费用，但是，基于云原生的 Serveless 方式，只有在服务被使用的时候才会产生计费，无请求的时候是不会产生任何费用的。另外对于服务的扩容和缩容由于是基于云原生的容器部署的，所以可以做到即时动态扩容和缩容来适配流量的峰值情况。

Serveless 架构还有以下优点

1. 降低运营和开发成本；
2. 自动扩缩容；
3. 更简单的架构和高效的性能；

Serveless 架构的产品通常分为两类，分别是 BaaS 后端即服务，另一种是 Faas 功能即服务。BaaS可以让开发人员访问各种第三方服务和应用，可以使用很多云厂商提供的服务，包括认证，加密，数据库等；不过我们经常提到的 Serveless 通常指的是 FaaS。FaaS 模型下我们通常还是正常的编写业务逻辑，只不过是可以完全运行在云厂商提供的容器里面。

FaaS 功能即服务

FaaS 是一种事件驱动计算模型，开发人员正常的编写业务逻辑，部署到云厂商的容器中，然后按需执行。容器是由云厂商提供的，无状态的，并且能随停随启的基于事件驱动的，在需要的时候自动运行。

对于我们开发人员来说，实现了 Serveless 架构过后，我们的整个架构就变了，以一个简单的 web 应用为例，在我们以前的架构简化成下面这边样子

但是当我们切换到 Serveless 架构的时候，整个架构就变成了下面这个样子

可以看到整个架构已经处于服务器不可见的状态了，对于开发人员不需要关心具体的服务器了，只需要关注自己的业务逻辑就行，统一的接入，安全，认证和调度都交给了云厂商。

前面讲的都是原理部分，下面通过实践阿粉带大家一起看下 Serveless 应用要怎么玩，我们通过腾讯云来演示 Serveless 的玩法。

实现 Serveless 架构的 Hello World

首先我们打开腾讯云，找到 Serveless 下面的云函数，点击进去过后会提示让我们进行授权，直接点击前往授权，并且同意就好了，如下图。

前往授权

直接同意就好了

授权完成过后，我们新建应用，通过自定义创建，当然也可以选择模板创建，阿粉这边就自定义创建了，直接点击完成就好，一个基于 Python 的云函数就创建好了。

前面提到 FaaS 是基于事件的，所以我们需要创建触发，这里我们创建一个基于 API 的触发方式，创建完成过后系统会生成一个地址，复制这个地址，当浏览器去执行就好了。

执行完成过后，我们看下日志查询，会看到有相应的日志输出了，这是默认的代码输出的，我们可以把 Python 脚本调整下，直接输出 Hello world，如下图，调整完成过来点击部署，再次访问原先的地址就可以了。

结果如下：

总结

阿粉今天给大家介绍了什么 Serveless，以及通过腾讯云带大家实践了一下云函数的创建，更多的玩法大家可以自行解锁。

参考

1. Infoq 入门 Serverless：如何实现 Hello World
2. AWS 从IaaS到FaaS—— Serverless架构的前世今生

Hello 大家好，我是阿粉，Redis 作为工作中不可缺少的缓存组件，相信很多小伙伴都会使用到，我们日常使用的时候都是通过代码或者客户端去链接 Redis 服务器来操作数据的。那么一条简单的set name ziyou 命令是如何执行的，中间都经历了哪些过程想必很少会有人去了解。今天阿粉就带大家看一下一条简单的set name ziyou 命令是如何执行的。

我们可以看到在执行set name ziyou 这个命令过后，先显示一个OK 在终端里面。下面我们看下这整个过程都经历了哪些步骤。

命令的整个执行分为下面几个步骤，我们先看流程，在仔细分析：

1. 客户端发送命令请求；
2. 服务端读取命令请求；
3. 命令执行器进行操作
   1. 命令执行器查找命令实现函数；
   2. 命令执行器执行预备操作；
   3. 命令执行器调用命令的实现函数；
   4. 命令执行器执行后续工作；
4. 服务端将命令回复发送给客户端；
5. 客户端接收并打印命令回复内容；

客户端发送命令请求

首先当客户端和服务端建立好了链接过后，当我们输入命令 set name ziyou 命令请求的时候，客户端会将这个命令进行协议转换，然后通过连接将转换后的协议发送到服务端。

比如当我们输入命令set name ziyou 的时候，客户端会将这个原始命令转换成*3\r\n$3\r\nset\r\n$4\r\nname\r\n$5\r\nziyou，这个协议大家应该比较眼熟，就是 Redis 管道的文件格式。简单解释下这个协议的意思，前面的*3 表示这个命令总共有三个参数，其中的$3,$4,$5 表示相应参数的长度。

服务端读取命令请求

当服务端收到该客户端的数据时，就会调用命令请求处理器来处理对应的消息。这块主要涉及到三个操作，第一个是保存命令，也就是会将命名的请求信息读取出来保存到对应客户端的输入缓冲区里面；保存完了过后会对输入缓冲区里面的内容进行解析，也就是对上面转换后的协议进行解析，解析出要执行的命令和对应的参数，将参数内容和参数个数保存到客户端的对应参数里面；第三步是调用命令执行器来执行命令。

命令执行器

命令执行器查找实现函数

看完本文，你一定会有所收获

Hello 大家好，我是阿粉，前面的文章给大家介绍了一下如何在本地搭建微服务环境下的服务注册中心和配置管理中心 Nacos，今天通过

我们通过使用 SpringBoot 项目集成 Nacos 来给大家演示一下是如何使用 Nacos 来实现服务发现和配置管理的。

启动 Nacos 服务

启动完本地搭建的 Nacos 服务后，我们可以看到，目前的服务管理下面的服务列表里面在三个命名空间下都没有服务，这是正常的，因为目前我们还没有服务接入 Nacos。

Nacos 服务启动成功后，我们再创建两个 SpringBoot 项目，一个用于接入 Nacos 服务注册与发现和配置中心作为服务提供者 Producer，另一个只接入 Nacos的服务注册与发现，调用 Producer 获取配置中心的参数，我们叫做 Consumer。

服务提供者 Producer

1. 我们首先创建一个 SpringBoot 的项目，bootstrap.properties 文件内容如下：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

   spring.application.name=producer #######################配置中心配置################################# # 指定的命名空间，只会在对应的命名空间下查找对应的配置文件 spring.cloud.nacos.config.namespace=caeser-adsys-naming spring.cloud.nacos.config.file-extension=properties # 配置的分组名称 spring.cloud.nacos.config.group=TEST1 # 配置文件，数组形式，可以多个，依次递增 spring.cloud.nacos.config.ext-config[0].data-id=com.example.properties spring.cloud.nacos.config.ext-config[0].group=TEST1 # 配置中心的地址 spring.cloud.nacos.config.server-addr=127.0.0.1:8848 #启用自动刷新对应的配置文件 spring.cloud.nacos.config.ext-config[0].refresh=true ######################服务注册发现配置################################## # 服务集群名称 spring.cloud.nacos.discovery.cluster-name=TEST1_GROUP # 服务注册中心的地址 spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 # 服务的命名空间 spring.cloud.nacos.discovery.namespace=caeser-adsys-naming

2. application.properties 的文件内容如下，主要就是一个端口，其他配置根据情况自行添加或删除就好：

   1 2 3 4 5 6 7 8 9 10 11 12 13

   # 服务启动的端口 server.port=8080 spring.main.allow-bean-definition-overriding=true # tomcat 配置 server.tomcat.max-threads=500 spring.mvc.servlet.load-on-startup=1 spring.servlet.multipart.max-file-size=40MB spring.servlet.multipart.max-request-size=100MB # 日志配置 logging.level.root=info logging.level.com.alibaba=error logging.pattern.console=%clr{[%level]}{green} [%d{yyyy-MM-dd HH:mm:ss}] %clr{[${PID:-}]}{faint} %clr{[%thread]}{magenta} %clr{[%-40.40logger{80}:%line]}{cyan} %msg%n

3. 在启动类上面增加如下注解

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   package com.ziyou.nacos.demo.producer; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cache.annotation.EnableCaching; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; @SpringBootApplication(scanBasePackages = "com.ziyou.nacos") @EnableDiscoveryClient @EnableCaching public class ProducerApplication { public static void main(String[] args) { SpringApplication.run(ProducerApplication.class, args); } }

4. pom.xml 文件内容如下：

   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

   <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.example</groupId> <artifactId>nacos-demo</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>producer</artifactId> <version>1.0-SNAPSHOT</version> <name>producer Maven Webapp</name> <!-- FIXME change it to the project's website --> <url>http://www.example.com</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.7</maven.compiler.source> <maven.compiler.target>1.7</maven.compiler.target> <spring.maven.plugin.version>2.2.2.RELEASE</spring.maven.plugin.version> </properties> <dependencies> <!-- Spring Boot --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-log4j2</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- nacos 配置中心 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> <!-- nacos 注册发现 --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> </dependencies> <build> <!--指定下面的目录为资源文件--> <resources> <!--设置自动替换--> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>**/**</include> </includes> </resource> </resources> <finalName>producer</finalName> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <version>${spring.maven.plugin.version}</version> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project>

5. 在 Producer 侧提供一个获取配置里面内容的接口，代码如下：

   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

   package com.ziyou.nacos.demo.producer.controller; import com.ziyou.nacos.demo.producer.config.UserConfig; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 19:59<br> * <b>Desc：</b>无<br> */ @RestController @RequestMapping(value = "producer") public class ProducerController { private UserConfig userConfig; @GetMapping("/getUsername") private String getUsername() { String result = userConfig.getUsername() + "-" + userConfig.getPassword(); System.out.println(result); return result; } @Autowired public void setUserConfig(UserConfig userConfig) { this.userConfig = userConfig; } }

   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

   package com.ziyou.nacos.demo.producer.config; import org.springframework.beans.factory.annotation.Value; import org.springframework.cloud.context.config.annotation.RefreshScope; import org.springframework.stereotype.Component; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 20:39<br> * <b>Desc：</b>无<br> */ @RefreshScope @Component public class UserConfig { @Value("${username}") private String username; @Value("${password}") private String password; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } }

6. 启动 Producer，并且手动调用接口，启动 Producer 过后，我们在 Nacos 的服务注册列表可以看如下所示的内容，在 test1 的命名空间下，已经有了我们创建的 Producer 服务。

   

7. 通过手动调用 Producer 的接口 http://127.0.0.1:8080/producer/getUsername 显示如下内容并且我们看下此时 Nacos 的配置中心里面配置文件com.example.properties 里面的内容正是这个，这个时候我们手动把配置里面password 参数的值改成JavaGeek666，再次访问接口，我们会发现接口的输出也自动改变了。

   

   修改配置内容如下：

   

   再次访问结果如下：

   

服务调用者 Consumer

前面我们已经完成了 Producer 的服务注册与配置动态生效的功能，这个时候基本已经可以使用了，不过我们还需要更进一步通过 Nacos 来实现服务发现，接下来我们创建 Consumer 的 SpringBoot 的项目，配置文件和pom.xml 文件基本一致，只要修改端口以及对应地方，下面贴一下不一样的地方

1. boostrap.properties 内容如下，因为这里我们只调用Producer 的接口，不需要接入 Nacos 的配置中心，所以这里只配置发服务注册与发现

   1 2 3 4 5 6

   spring.application.name=consumer ######################服务注册发现配置################################## spring.cloud.nacos.discovery.cluster-name=TEST1_GROUP spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 spring.cloud.nacos.discovery.namespace=caeser-adsys-naming

2. 启动类，配置上 feignClient 需要扫描的包路径

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

   package com.ziyou.nacos.demo.consumer; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cache.annotation.EnableCaching; import org.springframework.cloud.openfeign.EnableFeignClients; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 17:07<br> * <b>Desc：</b>无<br> */ @SpringBootApplication(scanBasePackages = "com.ziyou.nacos") @EnableFeignClients(basePackages = {"com.ziyou.nacos.demo.consumer.rpc"}) @EnableCaching public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }

3. 编写调用 Producer 的接口，FeignClient 里面的 value 就是 Producer 的应用名称

   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

   package com.ziyou.nacos.demo.consumer.rpc; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.stereotype.Component; import org.springframework.web.bind.annotation.GetMapping; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 20:01<br> * <b>Desc：</b>无<br> */ @FeignClient(value = "producer") @Component public interface IProducerFeign { /** * 获取生产者名称接口 * * @return */ @GetMapping("/producer/getUsername") String getUsername(); }

   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

   package com.ziyou.nacos.demo.consumer.controller; import com.ziyou.nacos.demo.consumer.rpc.IProducerFeign; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; /** * <br> * <b>Function：</b><br> * <b>Author：</b>@author ziyou<br> * <b>Date：</b>2021-04-11 19:59<br> * <b>Desc：</b>无<br> */ @RestController @RequestMapping(value = "consumer") public class TestNacosController { private IProducerFeign iProducerFeign; @GetMapping("/testNacos") private String testNacos() { return iProducerFeign.getUsername(); } @Autowired public void setiProducerFeign(IProducerFeign iProducerFeign) { this.iProducerFeign = iProducerFeign; } }

4. 启动 Consumer，我们可以看到在 Nacos 如下图所示

5. 调用 Consumer 的接口consumer/testNacos，结果如下图所示，同样的如果此时更改了 Nacos 配置文件中的内容，Consumer 这边也是可以实时更新的，感兴趣的小伙伴可以自己试试。

   

今天主要给大家介绍了一下如何通过 SpringBoot 项目来接入 Naocs 实现服务注册与发现，以及配置管理和动态刷新，相关的代码已经上传到 GitHub 了，公众号回复【源码】获取地址。

看完本文，你一定会有所收获

看完本文，你一定会有所收获

Hello 大家好，我是阿粉，现如今微服务早就成为每个互联网公司必备的架构，在微服务中服务的注册发现和统一配置中心是不可或缺的重要角色。现有的服务注册中心主要有 ZooKeeper、Eureka、Consul ，Etcd、Nacos，而统一配置中心主要有 Apollo，Spring Cloud Config，Disconf，Nacos 可以看到服务注册中心和统一配置管理有很多，而且每一种都是网上比较流行的，使用人数也偏多，但是我们可以发现只有 Nacos 是集两者于一身的。这篇文章主要给大家介绍一下 Naocs 的基本信息以及安装步骤，后面的文章再带大家更深入的了解一下Nacos。

Nacos 是什么

打开网站 Nacos 的首页，我们可以看到下面的内容，写到 Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助我们发现、配置和管理微服务，提供了一组简单易用的特性集，帮助我们快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 本地搭建

Nacos 的安装可以通过安装包或者源码来时候，这里我们为了以后方便调试，所以选择采用源码来安装。

1. 第一步在 GitHub 上面下载源码，这里可以使用 HTTP 协议也可以使用 SSH，阿粉这里为了简单就直接采用 HTTP 协议来下载了：git clone https://github.com/alibaba/nacos.git；
2. 下载完成过后，我们使用 IDEA 的 File》Open 打开项目，如下图
3. 刚打开后我们会看到有很多个模块，从模块的命名我们大概可以猜到有些模块是干嘛的，比如有 auth 权限模块，config 配置模块等这篇文章我们主要看安装和使用，后面慢慢深入了解具体的细节。
4. 拉取下来过后，我们需要创建数据库，我们找到console 模块下的数据库脚本和配置文件，如下图，在 MySQL 数据库中创建一个名为nacos 的数据库，然后执行schema.sql 脚本，创建相应的表结构，同时在 application.properties 文件中找到对应配置数据源的地方，配置好账号密码。这里对于 MySQL 的数据库的搭建和创建不在这篇文章的讨论范围里面就不提了。
5. 配置好数据库过后，在控制台执行 mvn 命令 mvn -Prelease-nacos -Dmaven.test.skip=true -Drat.skip=true clean install -U，编译一下，然后执行 console 模块下面的 Nacos.java 中的 main 方法，启动后我们会看到下图，显示的是集群模式启动，因为我们是本地单机启动，所以可以增加一个 JVM 参数-Dnacos.standalone=true 来设置单机模式。按照下图设置好过后，重新启动即可。
6. 启动成功过后，我们可以访问地址http://127.0.0.1:8848/nacos ，我们可以看到如下页面，包含配置管理、服务管理、以及权限，命名空间和集群的管理。阿粉这里搭建的是最新的版本，旧版本是没有权限管理的。我们可以看到整个页面非常的简洁，其中配置管理服务管理基本上覆盖了我们常用的所有功能。

核心角色

上面我们已经搭建好了 Nacos 平台，现在给大家介绍一下，Nacos 的几个核心角色。

1. 命名空间Namespace ：用于进行租户粒度的配置隔离，不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
2. 分组group：每个命名空间下还可以进行分组，相同集群的服务可以设置在同一个分组里面，如果没有手动指定默认分组为DEFAULT_GROUP
3. 配置集 Data ID：用于唯一区分不同配置文件，可以根据配置的信息不同，分别设置，比如可以单独配置 Redis 的配置文件，以及 MySQL 的配置文件，可以尽量细分复用，这样在有调整的时候只需要改一处即可。
4. 更详细的名词解释可以参考官网https://nacos.io/zh-cn/docs/concepts.html

使用

上面介绍了 Nacos 的本地搭建，搭建好了过后我们就可以使用了，因为 Nacos 不仅支持服务发现也支持统一配置管理，这篇文章我们先创建两个命名空间 test1 和 test2，然后分别添加两个配置文件com.example.properties 和com.example2.properties，创建的步骤比较简单。首先点击命名空间菜单，然后在右上角新增命名空间，接着输入相关信息就好了，这里新版本的 Nacos 支持手动填入命名空间的 ID，旧版本是不支持的，会随机生成一个字符串，这里建议手动填入具有含义的ID。

创建完命名空间过后，就可以在此命名空间下创建相应的配置文件了，这篇文章主要给大家介绍一下 Nacos 的本地部署过程以及简单的系统使用，后面的文章结合代码来实现一下服务的注册发现和配置的动态更新，敬请期待。

Hello 大家好，我是阿粉，关于 TCP 的三次握手和四次挥手相比大家早就烂熟于心了，毕竟这也是一个高频的面试题，但是很多小伙伴只是照本宣科，并没有真正的理解其中的原理，这篇文章，阿粉用通俗易懂的大白话带你们重新熟悉一下，已经掌握的小伙伴可以在回味一下，没有掌握的小伙伴刚好可以查漏补缺。

三次握手

再解释三次握手之前我们先从生活中想一个场景，假如你现在需要给领导打个电话汇报一下工作，为了保证双方能正常交流，那么在电话接通的那一刻想象一下会不会是这样的场景。

我们：领导好，我是 xx，可以听到我说话吗？有个工作需要向您汇报下。

领导：嗯，可以的，能听到我说话吧。

我们：可以。

我们：…..(汇报工作)。

通过上面的场景我们可以看出，其实跟 TCP 的三次握手是一个意思，只不过在我们日常生活中并不是每次都这么严谨，但是 TCP 不一样，TCP 是通过程序实现的，可靠的，面向连接的协议。而且程序是严谨的，每一次的建立连接都会进行这样的步骤。放一张经典的 TCP 三次握手图。

我们先用大白话解释一下为什么需要三次握手，首先我们要知道建立连接的目的是什么，我们是为了可靠的传输数据。那既然是可靠的传输数据，我们必须保证客户端和服务端都能正常的发送和接收数据，如果某一方不能正常的发送或者接收数据，那整个数据的传输就不能成功也就不可靠了。知道这个我们看下，为什么会需要三次握手，而不是两次握手。

1. 刚开始客户端和服务端都是处于关闭的状态，而且服务器 B 端一直处于监听的状态，时刻监听是否有建立连接的请求；
2. 当有客户端需要建立连接的时候就会发送一个确定连接的报文，此报文是同步报文SYN = 1，并且会生成一个随机的序号 seq = x，这是第一次握手；
3. 当服务端接收到请求连接报文的时候，会发送一个同步报文确认报文，此报文 SYN = 1，并且 ACK = 1，同时服务端也会随机生成一个 seq = y，并将 ack 设置成 x + 1，回传给客户端，这是第二次握手；
4. 当客户端接收到服务端的 ACK 报文后，会回复一个 ACK 确认报文，用于确认确认报文已经收到，此报文 ACK = 1，seq = x + 1, ack = y + 1，这是第三次握手；

这里有个点说明一下：大写的 ACK 表示报文的类型是确认报文，小写的 ack 是报文里面的确认号，这个确认号是上一次握手对方的 seq 值加 1 得到。

上面是整个三次握手的过程，现在我们分析一下为什么三次握手可以可靠的确定客户端和服务端都能支持的发送和接收数据。

第一次握手：第一次握手是客户端发送同步报文到服务端，这个时候客户端是知道自己具备发送数据的能力的，但是不知道服务端是否有接收和发送数据的能力；

第二次握手：当服务端接收到同步报文后，回复确认同步报文，此时服务端是知道客户端具有发送报文的能力，并且知道自己具有接收和发送数据的能力，但是并不知道客户端是否有接收数据的能力；

第三次握手：当客户端收到服务端的确认报文后，知道服务端具备接收和发送数据的能力，但是此时服务端并不知道自己具有接收的能力，所以还需要发送一个确认报文，告知服务端自己是具有接收能力的。

当整个三次握手结束过后，客户端和服务端都知道自己和对方具备发送和接收数据的能力，随后整个连接建立就完成了，可以进行后续数据的传输了。

看到这里，如果大家理解了就会知道很明显，两次握手是不行的，因为服务端并不知道客户端是具备接收数据的能力，所以就不能成为面向连接的可靠的传输协议。就像我们上面提到的打电话的例子，也是为了双方能够正常的进行交流，只不过我们现实生活中不会那么严谨，并不是每次都这样，但是程序是不一样的。

四次挥手

三次握手是为了建立可靠的数据传输通道，四次挥手则是为了保证等数据完成的被接收完再关闭连接。既然提到需要保证数据完整的传输完，那就需要保证双方都达到关闭连接的条件才能断开。

从上图中我们可以看到，

1. 客户端发起 FIN 断开连接的报文，携带随机生成的 seq 值 u，发送给服务端，并且自己处于 FIN-WSIT 状态，这是第一次挥手；
2. 服务端接收到 FIN 报文后，回复一个确认报文，其中 ACK = 1，随机生成一个 seq，以及 ack = u + 1，这是第二次挥手；
3. 当服务端数据发送完了过后，再发送一个 FIN 报文给客户端，通知客户端，服务端准备关闭连接了，此报文 FIN = 1，ACK = 1，ack = u + 1，seq = w，这是第三次挥手；
4. 当客户端收到 FIN 确认报文时再发送一个FIN 的确认报文，其中 ACK = 1，seq = u + 1，ack = w + 1，并进入 TIME-WAIT 状态，当等待 2MSL 后关闭连接，这是第四次挥手。

第一次挥手客户端发起关闭连接的请求给服务端；

第二次挥手：服务端收到关闭请求的时候可能这个时候数据还没发送完，所以服务端会先回复一个确认报文，表示自己知道客户端想要关闭连接了，但是因为数据还没传输完，所以还需要等待；

第三次挥手：当数据传输完了，服务端会主动发送一个 FIN 报文，告诉客户端，表示数据已经发送完了，服务端这边准备关闭连接了。

第四次挥手：当客户端收到服务端的 FIN 报文过后，会回复一个 ACK 报文，告诉服务端自己知道了，再等待一会就关闭连接。

疑问

1. 为什么握手要三次，挥手却要四次呢？

   那是因为握手的时候并没有数据传输，所以服务端的 SYN 和 ACK 报文可以一起发送，但是挥手的时候有数据在传输，所以 ACK 和 FIN 报文不能同时发送，需要分两步，所以会比握手多一步。

2. 为什么客户端在第四次挥手后还会等待 2MSL？

   等待 2MSL 是因为保证服务端接收到了 ACK 报文，因为网络是复杂了，很有可能 ACK 报文丢失了，如果服务端没接收到 ACK 报文的话，会重新发送 FIN 报文，只有当客户端等待了 2MSL 都没有收到重发的 FIN 报文时就表示服务端是正常收到了 ACK 报文，那么这个时候客户端就可以关闭了。

总结

TCP 协议是面向连接的可靠的传输层协议，它的拥塞控制，失败重传等机制在互联网数据传输中是不可或缺的。当下互联网行业中，基于 TCP 实现的程序数不胜数。对于我们程序员来说，很多时候如果不是参与底层项目的话，很少有机会会主动编写 TCP 相关的代码，但是理解 TCP 的实现原理，对我们来说是很有帮助的。

Hello 大家好，传说中的金三银四就在当下，阿粉知道很多小伙伴都在蠢蠢欲动，明修栈道暗度陈仓，表面上还在公司踏踏实实的干着，心里早就有了自己的小算盘。作为一个 Java 工程师，涉及到的领域会很多，每次面试都会被问到头破血流，阿粉今天就给大家带来一份面试题目，具体是哪家公司的阿粉就不说了，因为不管哪家其实都差不多，重点是自己要完全掌握，才能更好的应对。

技术细节

第一个部分我们先来看技术细节，往往很多公司的第一面都是考察技术细节的，小伙伴们如果在面试的过程中经常一面没有过的话，那往往是基础不扎实，这个时候我们就需要静下心来，好好的补一下基础知识，看看面经刷刷题，或者看看我们 Java 极客技术的文章都是可以的。

1. 三分钟自我介绍

   自我介绍这块是面试的一个开场白，这块没什么好说的，不过建议大家可以将自己想表述的内容以文字的形式写下来，然后熟练的背诵下来，这样不管是在电话面试，视频面试还是现场面试都能够流畅的有条理的表述出来。

2. 最熟悉的领域是什么？

   这个问题给大家一个忠告！千万别说自己不会的领域，不然整个面试还没开始就已经结束了，千万别为了表现，说自己什么领域都擅长，这样在被面试官问了几个问题都答不上来的话，那基本上就判了死刑了，而且整个印象都不会好，以后再想面试都很难了。所以这里我们实事求是就好，熟悉什么就说什么，不熟悉的就不说。

3. Redis 的常用数据类型有哪些？

   Redis 常用的五大数据类型，String，Hash，List，Set，Sorted Set。然后不要说完这几个类型就不说了，可以再扩展下，顺便可以说下每种数据类型在自己的项目里面是否有用到，具体使用在什么地方，为什么选用这种类型。面试的过程中虽然说是一问一答，但是也要适当的扩展一下，把自己知道的东西稍等多说一点，让面试官知道你是真正的了解。问你数据类型有哪些你就回答有这五个，这样的面试就比较枯燥，很难继续进展下去，给面试官的印象就不好。

4. Redis 的持久化了解吗？有几种方式，区别是什么？

   关于 Redis 的持久化，我们公众号之前有篇文章专门写了，大家可以看下面试官：请说下 Redis 是如何保证在宕机后数据不丢失的

5. Redis 的三种集群模式了解吗？

   关于 Redis 的集群模式不管自己有没有搭建过，都可以把自己知道的说出来，主从模式，哨兵模式，集群模式，以及三种模式的区别。

6. Redis 的主从数据是如何同步的？

   Redis 的主从数据同步跟上面的集群模式这两点都可以单独成一篇文章了，后期阿粉单独分享。

7. Redis 使用的场景？

   Redis 作为目前主流的缓存数据库，使用的场景有很多，用户 token 的存储，热点数据的存储，当成队列使用，分布式锁，计数器，布隆过滤器等等，结合自己项目中使用的场景可以跟面试官多聊一下。

8. Redis 为何性能如此高？

   Redis 官文号称最高 QPS 可以达到十万，那么问什么 Redis 可以有这么高的并发呢？主要是 Redis 采用多路复用 IO 模型，在处理命令的时候是采用单线程去处理的，同时 Redis 的底层采用 C 语言编写，数据结构也相对简单，所以才能如此快速。

9. MySQL 的存储引擎有哪些，InnoDB 和 MyISAM有什么区别？

   MySQL 常用的存储引擎主要有 InnoDB 和 MyISAM 以及 Memory，其中关于 InnoDB 和 MyISAM 的区别公众号前面有文章详细说过，感兴趣的小伙伴可以看一下面试必问的 MySQL 知识点，你还有哪些没准备好，赶紧收藏脑图！

10. 什么是事务？事务的隔离级别有哪些？为什么需要事务的隔离级别？

事务的内容在上面的文章里面也有详细说到，可以进去看下。

1. SQL 优化方面的内容？分库分表是怎么做的？

   关于 SQL 优化也是一个老生常谈的话题，在面试中也经常会被问到，关于 SQL 优化，有一篇文章很不错，推荐给大家，里面讲到了很多优化的点，认真记下来对我们很有帮助52条SQL语句性能优化策略，建议收藏

2. MySQL 的索引采用的是什么存储结构？为什么采用这个？

   MySQL 的索引也是一个面试中逃避不了的一个问题，详细的内容可以参考公号前面的文章为什么Mysql的常用引擎都默认使用B+树作为索引？

3. Java 中的线程池有哪些默认实现，几个核心参数是如何配合工作的？拒绝策略有哪些？

   Java 中的线程池有默认的实现，但是日常工作的时候我们一般都会手动创建线程池，具体的内容可以看文章面试官因为线程池，让我出门左拐！，聊聊面试中的 Java 线程池

4. Java 中 volatile, synchronized 的作用是什么？

   这两个关键词在 Java 中的重要性已经不言而喻了，不用阿粉在多说什么了，那对于这两个关键词小伙伴都理解了吗？同样的，我们前面也有写过，诡异的并发之可见性

5. 什么是类加载机制？

   啥也不说了，直接看文章 JVM 是如何加载 Java 类的？，相信看完你就懂了。

看完上面 15 个面试题，很容易发现一个问题，那就是真正面试的时候很多东西我们公众号之前都有写过，只要好好的把这些东西消化了，再加上面试的时候好好发挥，不说一定能拿到 offer，至少前几面都能很完美的过。看到这样是不是觉得这篇文章值得收藏呢？收藏起来，以后在面试前或者面试别人的时候都可以拿出来用一用。

项目部分

上面提到的是一些技术细节，其实还有很多很多东西，毕竟 Java 的领域涉及到很多地方，像这种面试题简直可以无休止的问下去。聊完了技术细节，后面一般都是针对项目开始询问，每个人的项目不一样，涉及的领域也不一样，不具有参考性，但是一些通用的问题还是要准备下的，比如

1. 项目运用到了哪些技术，整个的框架是什么样子的？
2. 你在这个项目中主要负责哪些内容，你是怎么设计的？
3. 在做这个项目的时候有没有遇到什么技术难点，你是怎么解决的？
4. 项目上线后的 QPS 是多少，用户量有多少，有没有出现过 Fullgc 或者线上 OOM 的情况，你是如何处理的？
5. 模块与模块之前是怎样调用的？HTTP 还是 RPC？RPC 框架用的是什么？了解其实现原理吗？
6. 做这个项目的目的是什么？你对项目所涉及的行业有了解吗？

上面这几个都是日常做项目的时候需要知道和思考的，技术上面涉及到的东西肯定要知道，在最后一个问题上面往往很多小伙伴会忽略，认为不就是一个项目吗？关行业什么事情？其实不是这样的，了解了一个项目的背景和价值可以更好的帮忙我们理解业务需求，从而做到更好的实现，而且对于一些想在某个方向长期发展的朋友，那就更有必要了。

架构部署方面

1. 你们项目是分布式的吗？怎么部署的？
2. 如何在不增加机器的情况下提升 QPS？
3. 如何降低各个服务或者机房之间网络通信耗时？
4. 如果机房突然出现故障如何保证数据不丢失？
5. 当下游服务出现问题时如何做熔断限流保证自己的服务不受影响？

上面几个问题是阿粉遇到的几个架构部署相关的问题，关于这一方面阿粉也不是特殊熟悉，所以就不做回答了，相信关注阿粉的小伙伴都是厉害的，可以在我们的留言下面回答下，大家一起学习谈论，帮助他人同时也是提升自己。