1 前言

1.1 什么是热部署

所谓热部署，就是在应用正在运行时升级软件，却不需要重新启动应用。对于Java应用程序来说，热部署就是在运行时更新Java类文件，同时触发Spring以及其他常用第三方框架的一系列重新加载的过程。在这个过程中不需要重新启动，并且修改的代码实时生效，好比是战斗机在空中完成加油，不需要战斗机熄火降落，一系列操作都在“运行”状态来完成。

1.2 为什么我们需要热部署

据了解，美团内部很多工程师每天本地重启服务高达5~12次，单次大概3~8分钟，每天向Cargo（美团内部测试环境管理工具）部署3~5次，单次时长20~45分钟，部署频繁频次高、耗时长，严重影响了系统上线的效率。而插件提供的本地和远程热部署功能，可让将代码变更“秒级”生效。一般而言，开发者日常工作主要分为开发自测和联调两个场景，下面将分别介绍热部署在每个场景中发挥的作用。

1.2.1 开发自测场景

一般来讲，在用插件之前，开发者修改完代码还需等待3~8分钟启动时间，然后手动构造请求或协调上游发请求，耗时且费力。在使用完热部署插件后，修改完代码可以一键增量部署，让变更“秒级”生效，能够做到快速自测。而对于那些无法本地启动项目，也可以通过远程热部署功能使代码变更“秒级”生效。

1.2.2 联调场景

通常情况下，在使用插件之前，开发者修改代码经过20~35分钟的漫长部署，需要联系上游联调开发者发起请求，一直要等到远程服务器查看日志，才能确认代码生效。在使用热部署插件之后，开发者修改代码远程热部署能够秒级（2~10s）生效，开发者直接发起服务调用，可以节省大量的碎片化时间（热部署插件还具备流量回放、远程调用、远程反编译等功能，可配合进行使用）。

所以，热部署插件希望解决的痛点是：在可控的条件内，帮助开发者减少频繁编译部署的次数，节省碎片化的时间。最终为开发者每天节约出一定量的编码时间。

1.3 热部署难在哪

为什么业界目前没有好用的开源工具？因为热部署不等同于热重启，像Tomcat或者Spring Boot DevTools此类热重启模式需要重新加载项目，性能较差。增量热部署难度较大，需要兼容常用的中间件版本，需要深入启动销毁加载流程。以美团为例，我们需要对JPDA（Java Platform Debugger Architecture）、Java Agent、ASM字节码增强、Classloader、Spring框架、Spring Boot框架、MyBatis框架、Mtthrift（美团RPC框架）、Zebra（美团持久层框架）、Pigeon（美团RPC框架），MDP（美团快速开发框架）、XFrame（美团快速开发脚手架）、Crane（美团分布式任务调度框架）等众多框架和技术原理深入了解才能做到全面的兼容和支持。另外，还需要IDEA插件开发能力，形成整体的产品解决方案闭环，美团的热部署插件Sonic正是在这种背景下应运而生。

1.4 Sonic可以做什么

Sonic是美团内部研发设计的一款IDEA插件，旨在通过低代码开发辅助远程/本地热部署，解决Coding、单测编写执行、自测联调等阶段的效率问题，提高开发者的编码产出效率。数据统计表明，开发者日常大概有35%时间用于编码的产出。如果想提高研发效率，要么扩大编码产出的时间占比，要么提高编码阶段的产出效率，而Sonic则聚焦提高编码阶段的产出效率。

目前，使用Sonic热部署可以解决大部分代码重复构建的问题。Sonic可以使用户在本地编写代码一键部署到远程环境，修改代码、部署、联调请求、查看日志，循环反复。如果不考虑代码修改时间，通常一个循环需要20~35分钟，而使用Sonic可以把整个时长缩短至5~10秒，而且能够给开发者带来高效沉浸式的开发体验。在实际编码工作中，多文件修改是家常便饭，Sonic对多文件的热部署能力尤为突出，它可以通过依赖分析等手段来对多文件批量进行远程热部署，并且支持Spring Bean Class、普通Class、Spring XML、MyBatis XML等多类型文件混合热部署。

那么跟业界现有的产品相比，Sonic有哪些优劣势呢？下面我们尝试给出几种产品的对比，仅供大家参考：

上表未把Sofa-Ark、Osgi、Arthas列举，此类属于插件化、模块化应用框架，以及Java在线诊断工具，核心能力非热部署。值得注意的是，Spring Boot DevTools只能应用在Spring Boot项目中，并且它不是增量热部署，而是通过Classloader迭代的方式重启项目，对大项目而言，性能上是无法接受的。虽然，JRebel支持三方插件较多，生态庞大，但是对于国产的插件不支持，例如FastJson等，同时它还存在远程热部署配置局限，对于公司内部的中间件需要个性化开发，并且是商业软件，整体的使用成本较高。

1.5 Sonic远程热部署落地推广的实践经验

相信大家都知道，对于技术产品的推广，尤其是开发、测试阶段使用的产品，由于远离线上环境，推动力、执行力、产品功能闭环能否做好，是决定着该产品是否能在企业内部落地并得到大多数人认可的重要的一环。此外，因为很多开发者在开发、测试阶段已逐渐形成了“固化动作”，如何改变这些用户的行为，让他们拥抱新产品，也是Sonic面临的艰巨挑战之一。我们从主动沟通、零成本（或极低成本）快速接入、自动化脚本，以及产品自动诊断、收集反馈等方向出发，践行出了四条原则。

2 整体设计方案

2.1 Sonic结构

Sonic插件由4大部分组成，包括脚本端、插件端、Agent端，以及Sonic服务端。脚本端负责自动化构建Sonic启动参数、服务启动等集成工作；IDEA插件端集成环境为开发者提供更便捷的热部署服务；Agent端随项目启动负责热部署的功能实现；服务端则负责收集热部署信息、失败上报等统计工作。如下图所示：

2.2 走进Agent

2.2.1 Instrumentation类常用API

public interface Instrumentation {

    //增加一个Class 文件的转换器，转换器用于改变 Class 二进制流的数据，参数 canRetransform 设置是否允许重新转换。
    void addTransformer(ClassFileTransformer transformer, boolean canRetransform);

    //在类加载之前，重新定义 Class 文件，ClassDefinition 表示对一个类新的定义，
    //如果在类加载之后，需要使用 retransformClasses 方法重新定义。addTransformer方法配置之后，后续的类加载都会被Transformer拦截。
    //对于已经加载过的类，可以执行retransformClasses来重新触发这个Transformer的拦截。类加载的字节码被修改后，除非再次被retransform，否则不会恢复。
    void addTransformer(ClassFileTransformer transformer);

    //删除一个类转换器
    boolean removeTransformer(ClassFileTransformer transformer);
    
    //是否允许对class retransform
    boolean isRetransformClassesSupported();

    //在类加载之后，重新定义 Class。这个很重要，该方法是1.6 之后加入的，事实上，该方法是 update 了一个类。
    void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;
   
    //是否允许对class重新定义
    boolean isRedefineClassesSupported();

    //此方法用于替换类的定义，而不引用现有的类文件字节，就像从源代码重新编译以进行修复和继续调试时所做的那样。
    //在要转换现有类文件字节的地方（例如在字节码插装中），应该使用retransformClasses。
    //该方法可以修改方法体、常量池和属性值，但不能新增、删除、重命名属性或方法，也不能修改方法的签名
    void redefineClasses(ClassDefinition... definitions) throws  ClassNotFoundException, UnmodifiableClassException;

    //获取已经被JVM加载的class，有className可能重复（可能存在多个classloader）
    @SuppressWarnings("rawtypes")
    Class[] getAllLoadedClasses();
}

2.2.2 Instrument简介

Instrument的底层实现依赖于JVMTI（JVM Tool Interface），它是JVM暴露出来的一些供用户扩展的接口集合，JVMTI是基于事件驱动的，JVM每执行到一定的逻辑就会调用一些事件的回调接口（如果存在），这些接口可以供开发者去扩展自己的逻辑。

JVMTIAgent是一个利用JVMTI暴露出来的接口提供了代理启动时加载（Agent On Load）、代理通过Attach形式加载（Agent On Attach）和代理卸载（Agent On Unload）功能的动态库。而Instrument Agent可以理解为一类JVMTIAgent动态库，别名是JPLISAgent（Java Programming Language Instrumentation Services Agent），也就是专门为Java语言编写的插桩服务提供支持的代理。

2.2.3 启动时和运行时加载Instrument Agent过程

2.3 那些年JVM和HotSwap之间的“相爱相杀”

围绕着Method Body的HotSwap JVM一直在进行改进。从1.4版本开始，JPDA引入HotSwap机制（JPDA Enhancements），实现Debug时的Method Body的动态性。大家可参考文档：enhancements1.4 。
1.5版本开始通过JVMTI实现的java.lang.instrument（Java Platform SE 8）的Premain方式，实现Agent方式的动态性（JVM启动时指定Agent）。大家可参考文档：package-summary。

1.6版本又增加Agentmain方式，实现运行时动态性（通过The Attach API 绑定到具体VM）。大家可参考文档：package-summary 。基本实现是通过JVMTI的retransformClass/redefineClass进行method、body级的字节码更新，ASM、CGLib基本都是围绕这些在做动态性。但是针对Class的HotSwap一直没有动作（比如Class添加method、添加field、修改继承关系等等），为什么会这样呢？因为复杂度过高，且没有很高的回报。

2.4 Sonic如何解决Instrumentation的局限性

由于JVM限制，JDK 7和JDK 8都不允许改类结构，比如新增字段，新增方法和修改类的父类等，这对于Spring项目来说是致命的。比如开发同学想修改一个Spring Bean，新增一个@Autowired字段，此类场景在实际应用时很多，所以Sonic对此类场景的支持必不可少。

那么，具体是如何做到的呢？这里要提一下“大名鼎鼎”的Dcevm。Dcevm（DynamicCode Evolution Virtual Machine）是Java Hostspot的补丁（严格上来说是修改），允许（并非无限制）在运行环境下修改加载的类文件。当前虚拟机只允许修改方法体（Method，Body），而Decvm可以增加、删除类属性、方法，甚至改变一个类的父类，Dcevm是一个开源项目，遵从GPL 2.0协议。更多关于Dcevm的介绍，大家可以参考：Wuerthinger10a以及GitHub Decvm。

值得一提的是，在美团内部，针对Dcevm的安装，Sonic已经打通HULK，集成发布镜像即可完成（本地热部署可结合插件功能实现一键安装热部署环境）。

3 Sonic热部署技术解析

3.1 Sonic整体架构模型

上一章节我们主要介绍了Sonic的组成。下图详细介绍了Sonic在运行期间各个组成部分的工作职责，由它们形成一整套完备的技术产品落地闭环方案：

3.2 Sonic功能流转

Sonic通过NIO监听本地文件变更，触发文件变更事件，例如Class新增、Class修改、Spring Bean重载等事件流程。下图展示了一次热部署单个文件的生命周期：

3.3 文件监听

Sonic首先会在本地和远程预定义两个目录，/var/tmp/sonic/extraClasspath和/var/tmp/sonic/classes。extraClasspath为Sonic自定义的拓展Classpath URL，classes为Sonic监听的目录，当有文件变更时，通过IDEA插件来部署到远程/本地，触发Agent的监听目录，来继续下面的热加载逻辑：

为什么Sonic不直接替换用户ClassPath下面的资源文件呢？因为考虑到业务方WAR包的API项目、Spring Boot、Tomcat项目、Jetty项目等，都是以JAR包来启动的，这样是无法直接修改用户的Class文件的。即使是用户项目可以修改，直接操作用户的Class，也会带来一系列的安全问题。

所以，Sonic采用拓展ClassPath URL路径来实现文件的修改和新增。并且存在这么一种场景，多个业务侧的项目引入相同的JAR包，在JAR里面配置MyBatis的XML和注解。在此类情况下，Sonic没有办法直接来修改JAR包中源文件，通过拓展路径的方式可以不需要关注JAR包，来修改JAR包中某一文件和XML。同理，采用此类方法可以进行整个JAR包的热替换。下面我们简单介绍一下Sonic的核心监听器，如下图所示：

3.4 JVM Class Reload

JVM的字节码批量重载逻辑，通过新的字节码二进制流和旧的Class对象生成ClassDefinition定义，instrumentation.redefineClasses（definitions），来触发JVM重载，重载过后将触发初始化时Spring插件注册的Transfrom。接下来，我们简单讲解一下Spring是怎么重载的。

新增class Sonic如何保证可以加载到Classloader上下文中？由于项目在远程执行，所以运行环境复杂，有可能是JAR包方式启动（Spring Boot），也有可能是普通项目，也有可能是War Web项目，针对此类情况Sonic做了一层Classloader URL拓展。

User ClassLoader是框架自定义的ClassLoader统称，例如Jetty项目是WebAppclassLoader。其中Urlclasspath为当前项目的lib文件件下，例如Spring Boot项目也是从当前项目BOOT-INF/lib/路径中加载CLass等等，不同框架的自定义位置稍有不同。所以针对此类情况，Agent必须拿到用户的自定义Classloader，如果是常规方式启动的，比如普通Spring XML项目，借助Plus（美团内部服务发布平台）发布，此类没有自定义Classloader，是默认AppClassLoader，所以Agent在用户项目启动过程中，借助字节码增强的方式来获取到真正的用户Classloader。

找到用户使用的子Classloader之后，通过反射的方式来获取Classloader中的元素Classpath，其中ClassPath中的URL就是当前项目加载Class时需要的所有运行时Class环境，并且包括三方的JAR包依赖等。

Sonic获取到URL数组，把Sonic自定义的拓展Classpath目录加入到URL数组首位，这样当有新增Class时，Sonic只需要将Class文件复制到拓展Classpath对应的包目录下面即可，当有其他Bean依赖新增的Class时，会从当前目录下面查找类文件。

为什么不直接对Appclassloader进行加强？而是对框架的自定义Classloader进行加强？

考虑这样一个场景，框架自定义类加载器中有ClassA，此时用户新增ClassB需要热加载，B Class里面有A的引用关系，如果增强AppClassLoader，初始化B实例时ClassLoader。loadclass首先从UserClassLoader开始加载ClassB的字节码，依靠双亲委派原则，B被Appclassloader加载，因为B依赖类A，所以当前AppClassLoader加载B一定是加载不到的，此时会抛出ClassNotFoundException异常。所以对类加载器拓展，一定要拓展最上层的类加载器，这样才会达到使用者想要的效果。

3.5 Spring Bean重载

Spring Bean Reload过程中，Bean的销毁和重启流程，主要内容如下图展示：

首先当修改Java Class D时，通过Spring ClasspathScan扫描校验当前修改的Bean是否Sprin Bean（注解校验），然后触发销毁流程（BeanDefinitionRegistry.removeBeanDefinition），此方法会将当前Spring上下文中的Bean D和依赖Spring Bean D的Bean C一并销毁，但是作用范围仅仅在当前Spring上下文。如果C被子上下文中的Bean B依赖，就无法更新子上下文中的依赖关系，当有系统请求时，Bean B中关联的Bean C还是热部署之前的对象，所以热部署失败。

因此，在Spring初始化过程中，需要维护父子上下文的对应关系，当子上下文变时若变更范围涉及到Bean B时，需要重新更新子上下文中的依赖关系，当有多上下文关联时需要维护多上下文环境，且当前上下文环境入口需要Reload。这里的入口是指：Spring MVC Controller、Mthrift和Pigeon，对不同的流量入口，采用不同的Reload策略。RPC框架入口主要操作为解绑注册中心、重新注册、重新加载启动流程等等，对Spring MVC Controller，主要是解绑和注册URL Mappping来实现流量入口类的变化切换。

3.6 Spring XML重载

当用户修改/新增Spring XML时，需要对XML中所有Bean进行重载。

重新Reload之后，将Spring销毁后重启。需要注意的是：XML修改方式改动较大，可能涉及到全局的AOP的配置以及前置和后置处理器相关的内容，影响范围为全局，所以目前只放开普通的XML Bean标签的新增/修改，其他能力酌情逐步放开。

3.7 MyBatis 热部署

Spring MyBatis热部署的主要处理流程是在启动期间获取所有Configuration路径，并维护它和Spring Context的对应关系，在热部署Class、XML时去匹配Configuration，从而重新加载Configuration以达到热部署的目的。

4 总结

4.1 热部署功能一览

上一章节主要讲述了Spring Bean、Spring MVC、MyBatis的重载流程，Sonic还支持其它常用的开发框架，丰富的框架支持和兼容能力是Sonic的基石，下面列举一些Sonic支持的常用的第三方框架：

截止目前，Sonic已经支持绝大部分常用第三方框架的热加载，常规业务开发几乎无需重启服务。并且在美团内部的成功率已经高达99.9%以上，真正地让热部署来代替常规部署构建成为一种可能。

4.2 IDE插件集成

Sonic也提供了功能强大的IDEA插件，让用户进行沉浸式开发，远程热部署也变得更加便利。

4.3 推广使用情况

截止到发稿时，Sonic在美团使用人数3000+，应用项目数量2000+。该项目还获得了美团内部2020年下半年到家研发平台“最佳效率团队”奖。

5 作者简介

凯哥、占峰、李晗、龚炎、程骁、玉龙等，均来自美团/到家研发平台。

来源：tech.meituan.com/2022/03/17/java-hotswap-sonic.html

重新认识自己

我一直对 NodeJS 工具方向比较感兴趣，今年终于有机会在公司内，开始工具项目的研发，调研并设计了整体架构、独立负责开发工作。

去年年末时，我刚刚来到字节半年，其实心态还没有完全转换过来，之前在创业公司，涉及了很多不同端的开发工作。所以我对自己的定位，还处于一个支持业务开发的状态，对技术渴望度足够，但对于技术路线有些许迷茫。只能看到一些比较聚焦度比较高的技术名词，例如 WASM、WebGL，会对这些技术存在追捧，却并没有做到脚踏实地。

相比去年的我，今年我对一些概念又有了许多新的见解，到底什么样才是出色的工程师？

当今国内工程师的问题

按照国内对工程师的区分，在各厂招聘列表中经常出现的是这几类，前端/后端/客户端工程师。

在我的工作中，经常会接触各端 SDK 的开发的同学，接触过程中，有时感觉到大家会存在一些 gap，也就是说 SDK 同学想去做一些事情，但是在他的角度他很明白底层逻辑，但对于其他端（前/后）同学，他们对底层原理其实并不了解。这就造成开发前，需要很长的时间去对齐功能的逻辑，合作同学也很难理解需求的意义与价值。

如果想摆脱这些困惑，那我认为你需要成为一名「全栈工程师」，其实说是全栈，不如是「软件工程师」，作为一名工程师，需要拥有一些闭环整体开发流程的能力。

例如，以 SDK 开发的角度来说，对于 SDK 同学，实际上最终只负责到上报这个动作，至于之后数据的流向，以及数据清洗，并不在掌控的范畴之内。这虽然降低了 SDK 侧上手的门槛，但并不利于长期的维护。

假如你是一个软件工程师，对于以下流程，你都了如指掌：

数据上报 -> 清洗 -> 存储 -> 消费

那你对于系统的整体认知就会提升，从优化上，可以给出更好的建议；在排查问题时，也可以更快速的定位问题。

何为工程师？

下面我详细谈一谈，如何成为一个有宏观视角的工程师。

首先，我目前的关注点主要在前端方向，如果你有仔细观察，你可以看到最终大部分比较厉害的前端，都是具有一些全栈能力的人。

对于服务端层面，我的建议是把 Golang 学好，这是一个还不错的方向。一个技术栈，如果有很多人关注聚焦，广泛地提出问题，那它的发展前景一定是不错的，起码不会垮掉，也就是说，开发生态是健康的。

对于前端层面，如果想去把前端学的很深入的话，那么前端工具以及工程化，必不可少。

在这一年内，我扩展一些自己原本不是很擅长的领域：

• 产品

  • 竞品调研

  • PRD 撰写

• 服务端方向

  • MySQL

  • Rust

  • Golang

• 前端方向

  • 单测/e2e：Jest、@testing-library/react、Cypress

  • 工程化：Rush.js、Pnpm、Webpack、TypeScript

  • 工具：Babel、CLI 相关的 npm 包工具

  • 插件：Chrome、VSCode

• 设计

  • Figma 学习

• 英语学习

除了开发角色，一个合格的工程师，还应该掌握技术方案设计的能力，这样可以将整体的开发流程闭环。也就是说一个人扮演，调研、方案设计、编码、测试的工作。从我的 Roadmap 中，你也可以看出来这一点。为什么要闭环呢，当一个需求，有越来越多的角色参与进来的时候，你会发现方案细节的对齐，变成了一个不简单的工作。

有时候我们经常会讲一个词，融会贯通。当你把一整套研发体系都吃下来的时候，你会发现可以顺利地解决掉项目的问题。

我的工作场景

在我的工作中，会涉及到工具链的开发。首先在开始前，需要做一些竞品调研，方案设计的工作。

开发环节，对前端来说，按照目前的趋势，我们更好的方式是以 Monorepo 的形式去做开发。这里 Pnpm 就是一个很不错的选择，但接下来你会遇到一些问题，例如如何去做这些包的发版编排？

由于在 Workspace 中会存在一些包之间的相互引用，在发版时，也要按照拓扑排序的方式进行发版，这时，我们就可以用到 Rush.js 去做拓扑发版，以及自动生成 Changelog。

工具链对于质量需要较强的把控，这时我们就要引入 Jest 做单测，但一些场景下，单测是不够的，这时我们需要引入 e2e 测试。

在 Monorepo 中，不像单仓中，可能只存在一个 tsconfig，这时会存在配置之间 extends 的关系，需要我们对 tsconfig 的配置了如指掌。

对于多种工具消费方式，例如 CLI、Chrome 插件等，实则需要公用一些方法与配置，这里就需要抽象出公用的 utils 等。

在开发中，可能会关注一些新闻，比如 Vite 4 启用了 SWC 替代 Babel做编译。那你是否有好奇过，为什么 SWC 会更快，这时候如果学过 Rust，就知道 Rust 特有的语言特性。

总结

我想说的是，作为一个工程师，不要去把自己划分为「前端/后端/ PM」这些更加细分的角色。你都可以去学习任何方面的知识。并且你学的一切知识，都是有意义的。虽然学习的道路很长，但只要坚持下去，你就会朝着优秀的工程师进发。

作者：EricLee
来源：juejin.cn/post/7181000277208760378

前言

  本文是笔者在日常开发过程中遇到的对 CAS 、 ABA 问题以及 JUC（java.util.concurrent）中 AtomicReference 相关类的设计的一些思考记录。 对需要处理 ABA 问题，或有诸如笔者一样的设计疑问探索好奇心的读者可能会带来一些启发。

本文主体由三部分构成：

1. 首先阐述多线程场景数据同步的常用语言工具

2. 接着阐述什么是 ABA 问题，以及产生的原因和可能带来的影响

3. 再探索 JUC 中官方为解决 ABA 问题而做一些工具类设计

文章的最后会对多线程数据同步常用解决方案做了简短地经验性总结与概括。

受限于笔者的理解与知识水平，文章的一些术语表述难免可能会失偏颇，对于有理解歧义或争议的部分，欢迎大家探讨和指正。

一、异步场景常用工具

在Java中的多线程数据同步的场景，常会出现：

1. 关键字 volatile

2. 关键字 synchronized

3. 可重入锁/读写锁 java.util.concurrent.locks.*

4. 容器同步包装，如 Collections.synchronizedXxx()

5. 新的线程安全容器，如 CopyOnWriteArrayList/ConcurrentHashMap

6. 阻塞队列 java.util.concurrent.BlockingQueue

7. 原子类 java.util.concurrent.atomic.*

8. 以及 JUC 中其他工具诸如 CountDownLatch/Exchanger/FutureTask 等角色。

  其中 volatile 关键字用于刷新数据缓存，即保证在 A 线程修改某数据后，B 线程中可见，这里面涉及的线程缓存和指令重排因篇幅原因不在本文探讨范围之内。而不论是 synchronized 关键字下的对象锁，还是基于同步器 AbstractQueuedSynchronizer 的 Lock 实现者们，它们都属于悲观锁。而在同步容器包装、新的线程程安全容器和阻塞队列中都使用的是悲观锁；只是各类的内部使用不同的 Lock 实现类和 JUC 工具，另外不同容器在加锁粒度和加锁策略上分别做了处理和优化。

  这里值得一说的，也是本文聚焦的重点则是原子类，即 java.util.concurrent.atomic.* 包下的几个类库诸如 AtomicBoolean/AtomicInteger/AtomicReference

二、CAS 与 ABA 问题

  我们知道在使用悲观锁的场景中，如果有有一个线程抢先取得了锁，那么其他想要获得锁的线程就得被阻塞等待，直到占锁线程完成计算释放锁资源。而现代 CPU 提供了硬件级指令来实现同步原语，也就是说可以让线程在运行过程中检测是否有其他线程也在对同一块内存进行读写，基于此 Java 提供了使用忙循环来取代阻塞的系列工具类 AutomicXxx，这属于是一种乐观锁的实现。其常规使用方式形如：

public class Requester {
    private AtomicBoolean isRequesting = new AtomicBoolean(false)

    public void request() {
        // 修改成功时返回true；compareAndSet 方法由 Native 层调硬件指令实现
        if (!isRequesting.compareAndSet(false, true)) {
            return;
        }
        try {
            // do sth...
        } finally {
            isRequesting.set(false)
        }
    }
}

  进入到 JDK11 AtomicBoolean 的源码中，可以看到 compareAndSet 最终调用 Native 层的方式如下。其实在旧的版本中 JDK 是使用 Unsafe 类处理的，在入参数中有传入状态变量的字段偏移值，新版本则将两者封装到 VarHandle 中采用DL方式查找依赖（笔者猜测可能和JDK9模块化改造有关）：

// 旧版
public class AtomicBoolean {
    private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
    private static final long VALUE;
    static {
        try {
            VALUE = U.objectFieldOffset
                (AtomicBoolean.class.getDeclaredField("value"));
        } catch (ReflectiveOperationException e) {
            throw new Error(e);
        }
    }

    private volatile int value;

    public final boolean compareAndSet(boolean expect, boolean update) {
        return U.compareAndSwapInt(this, VALUE, (expect ? 1 : 0), (update ? 1 : 0));
    }
}

// 新版
public class AtomicBoolean {
    private static final VarHandle VALUE;
    static {
        try {
            MethodHandles.Lookup l = MethodHandles.lookup();
            VALUE = l.findVarHandle(AtomicBoolean.class, "value", int.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }

    private volatile int value;

    public final boolean compareAndSet(boolean expectedValue, boolean newValue) {
        return VALUE.compareAndSet(this, (expectedValue ? 1 : 0), (newValue ? 1 : 0));
    }
}

  犹如入仓有 this 和 value 的偏移值，则 Native 层可根据此二者值定位到某块栈内存，这样对于基本类型没什么问题。原子类型体系中使用 AtomicReference 来引用复合类型实例，但 Java 中 Object 类型在栈中保存的只是堆中对象数据块的地址，其结构形如下图：

  而实际运行过程中，调用 AtomicReference#compareAndSet() 时，Native层只会对比栈中内存的值，而不会关注其指向的堆中数据。这样说可能有点抽象，看一段实验代码：

StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicReference<StringBuilder> ref = new AtomicReference<>(varA);
ref.compareAndSet(varA, varB); // (1)
System.out.println(ref.get()); // (2) varB->123
varB.append('4'); // (3) changed varB->1234
if (ref.compareAndSet(varB, varA)) { // (4)
    System.out.println("CAS succeed"); // (5) CAS succeed
}
System.out.println(ref.get()); // abc

喜欢动手的读者可以尝试自定义一个类，观察下 Compare 过程是否真的没有调用对象的 equals 方法。

  ref 在经过处理后再 (2) 处引用变量B，而在注释 (3) 处将 B 值修改了，但由于原子类不会检查堆中数据，所以还是能通过注释 (4) 处的相等比较走到注释 (5) 。这也就引入了 所谓的 ABA 问题：

1. 假设，线程 1 的任务希望将变量从 A 变为 C ，但执行到一半被线程 2 抢走 CPU

2. 线程 2 将变量从 A 改成了 B ，此时 CPU 时间片又被系统分给了线程 3

3. 线程 3 讲变量从 B 又设置成一个新的 A 。

4. 线程 1 获取时间片，检查变量发现其仍然是 A（但 A 对象内部的数据已经改变了），检查通过将变量置为 C 。

  若业务场景中，线程 1 不在意变量经过了一轮变化，也不在意 A 中数据是否有变化，则该问题无关痛痒。而若线程 1 对这两个变化敏感，则将变量置为 C 的操作就不符合预期了。用维基百科的例子来表述，其大意是:

你提着有很多现金的包去机场，这时来了个辣妹挑逗你，并趁你不注意时用一个看起来一样的空包换了你的现金包，然后她就走了；此时你检查了下发现你的包还在，于是就匆忙拿着包赶飞机去了。

换个角度看这几个关键字:

• 有现金的包：指向堆中数据的栈引用

• 辣妹挑逗：其他线程抢占 CPU

• 看起来一样空包：其他线程修改堆中数据

• 发现包还在：仅检查栈中内存的地址值是否一致

三、用 JUC 工具处理 ABA 问题

  为处理 ABA 问题，JDK 提供了另外两个工具类：AtomicMarkableReference 和 AtomicStampedReference 他们除了对比栈中对象的引用地址外，另外还保存了一个 boolean 或 int 类型的标记值，用于 CAS 比较。

StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicStampedReference<StringBuilder> ref = new AtomicStampedReference<>(varA, varA.toString().hashCode());
ref.compareAndSet(varA, varB, varA.toString().hashCode(), varB.toString().hashCode());
System.out.println(ref.get(new int[1]));
varB.append('4');
// CAS失败，因为Stamp值对不上
if (ref.compareAndSet(varB, varA, varB.toString().hashCode(), varA.toString().hashCode())) {
    System.out.println("compareAndSet: succeed");
}
System.out.println(ref.get(new int[1]));

注：这种设计和为快速判断文件是否相同，而比较文件摘要值（MD5、SHA值）和预期是否一致的思想倒有异曲同工之妙。

总结

  通常在多线程场景中，这些工具的应用场景具有各自的适用特征：

1. 若各线程读写数据没有竞争关系，则可考虑仅使用 volatile 关键字；

2. 若各线程对某数据的读写需要去重，则可优先考虑使用乐观锁实现，即用原子类型；

3. 若各线程有竞争关系且不去重必须按顺序抢占某资源，即必须用锁阻塞，若没有多条件队列的诉求则可先考虑使用 synchronized 添加对象锁（但需注意锁对象的不可变和私有化），否则考虑用 Lock 实现类，但特别的如需读写分锁以实现共享锁则只能用 Lock 了。

4. 若需使用线程安全容器，出于性能考虑优先考虑 java.util.concurrent.* 类，如 ConcurrentHashMap、CopyOnWriteArrayList；再考虑使用容器同步包装 Collections.synchronizedXxx()。而阻塞队列则多用于生产-消费模型中的任务容器，典型如用在线程池中。

作者：Chavin
来源：juejin.cn/post/7181077489211408443

沉淀、分享、成长，让自己和他人都能有所收获！😄

记得那是我毕业🎓后的第一个秋天，申请了域名，搭建了论坛。可惜好景不长，没多久进入论坛后就出现各种乱七八糟的广告，而这些广告压根都不是我加的。

这是怎么回事？后来我才知道，原来我的论坛没有加 HTTPS 也就是没有 SSL 证书。那这和数学中的素数有啥关系呢？这是因为每一个 SSL 的生成都用到了 RSA 非对称加密，而 RSA 的加解密就是使用了两个互为质数的大素数生成公钥和私钥的。

这就是我们今天要分享的，关于素数在 RSA 算法中的应用。

一、什么是素数

素数（或质数）指的是大于1的且不能通过两个较小的自然数乘积得来的自然数。而大于1的自然数如果不是素数，则称之为合数。例如：7是素数，因为它的乘积只能写成 1 * 7 或者 7 * 1 这样。而像自然数 8 可以写成 2 * 4，因为它是两个较小数字的乘积。

通常在 Java 程序中，我们可以使用下面的代码判断一个数字是否为素数；

boolean isPrime = number > 0;
// 计算number的平方根为k，可以减少一半的计算量
int k = (int) Math.sqrt(number);
for (int i = 2; i <= k; i++) {
    if (number % i == 0) {
        isPrime = false;
        break;
    }
}
return isPrime;

二、对称加密和非对称加密

假如 Alice 时而需要给北漂搬砖的 Bob 发一些信息，为了安全起见两个人相互协商了一个加密的方式。比如 Alice 发送了一个银行卡密码 142857 给 Bob，Alice 会按照与 Bob 的协商方式，把 142857 * 2 = 285714 的结果传递给 Bob，之后 Bob 再通过把信息除以2拿到结果。

但一来二去，Alice 发的密码、生日、衣服尺寸、鞋子大小，都是乘以2的规律被别人发现。这下这个加密方式就不安全了。而如果每次都给不同的信息维护不同的秘钥又十分麻烦，且这样的秘钥为了安全也得线下沟通，人力成本又非常高。

所以有没有另外一种方式，使用不同的秘钥对信息的加密和解密。当 Bob 想从 Alice 那获取信息，那么 Bob 就给 Alice 一个公钥，让她使用公钥对信息进行加密，而加密后的信息只有 Bob 手里有私钥才能解开。那么这样的信息传递就变得非常安全了。如图所示。

对称加密	非对称加密

三、算法公式推导

如果 Alice 希望更安全的给 Bob 发送的信息，那么就需要保证经过公钥加密的信息不那么容易被反推出来。所以这里的信息加密，会需用到求模运算。像计算机中的散列算法，伪随机数都是求模运算的典型应用。

例如；5^3 mod 7 = 6 —— 5的3次幂模7余6

• 5相当于 Alice 要传递给 Bob 的信息

• 3相当于是秘钥

• 6相当于是加密后的信息

经过求模计算的结果6，很难被推到出秘钥信息，只能一个个去验证；

5^1 mod 7 = 5
5^2 mod 7 = 3
5^3 mod 7 = 6
5^4 mod 7 = 2
...

但如果求模的值特别大，例如这样：5^3 mod 78913949018093809389018903794894898493... = 6 那么再想一个个计算就有不靠谱了。所以这也是为什么会使用模运算进行加密，因为对于大数来说对模运算求逆根本没法搞。

根据求模的计算方式，我们得到加密和解密公式；—— 关于加密和解密的公式推到，后文中会给出数学计算公式。

对于两个公式我们做一下更简单的转换；

从转换后的公式可以得知，m 的 ed 次幂，除以 N 求求模可以得到 m 本身。那么 ed 就成了计算公钥加密的重要因素。为此这里需要提到数学中一个非常重要的定理，欧拉定理。—— 1763年，欧拉发现。

欧拉定理：m^φ(n) ≡ 1 (mod n) 对于任何一个与 n 互质的正整数 m，的 φ(n) 次幂并除以 n 去模，结果永远等于1。φ(n) 代表着在小于等于 n 的正整数中，有多少个与 n 互质的数。

例如：φ(8) 小于等于8的正整数中 1、2、3、4、5、6、7、8 有 1、3、5、7 与数字 8 互为质数。所以 φ(8) = 4 但如果是 n 是质数，那么 φ(n) = n - 1 比如 φ(7) 与7互为质数有1、2、3、4、5、6 所有 φ(7) = 6

接下来我们对欧拉公式做一些简单的变换，用于看出ed的作用；

经过推导的结果可以看到 ed = kφ(n) + 1，这样只要算出加密秘钥 e 就可以得到一个对应的解密秘钥 d。那么整套这套计算过程，就是 RSA 算法。

四、关于RSA算法

RSA加密算法是一种非对称加密算法，在公开秘钥加密和电子商业中被广泛使用。

于1977年，三位数学家；罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）设计了一种算法，可以实现非对称加密。这种算法用他们三个人的名字命名，叫做RSA算法。

1973年，在英国政府通讯总部工作的数学家克利福德·柯克斯（Clifford Cocks）在一个内部文件中提出了一个与之等效的算法，但该算法被列入机密，直到1997年才得到公开。

RSA 的算法核心在于取了2个素数做乘积求和、欧拉计算等一系列方式算得公钥和私钥，但想通过公钥和加密信息，反推出来私钥就会非常复杂，因为这是相当于对极大整数的因数分解。所以秘钥越长做因数分解越困难，这也就决定了 RSA 算法的可靠性。—— PS：可能以上这段话还不是很好理解，程序员👨🏻‍💻还是要看代码才能悟。接下来我们就来编写一下 RSA 加密代码。

五、实现RSA算法

RSA 的秘钥生成首先需要两个质数p、q，之后根据这两个质数算出公钥和私钥，在根据公钥来对要传递的信息进行加密。接下来我们就要代码实现一下 RSA 算法，读者也可以根据代码的调试去反向理解 RSA 的算法过程，一般这样的学习方式更有抓手的感觉。嘿嘿 抓手

1. 互为质数的p、q

两个互为质数p、q是选择出来的，越大越安全。因为大整数的质因数分解是非常困难的，直到2020年为止，世界上还没有任何可靠的攻击RSA算法的方式。只要其钥匙的长度足够长，用RSA加密的信息实际上是不能被破解的。—— 不知道量子计算机出来以后会不会改变。如果改变，那么程序员又有的忙了。

2. 乘积n

n = p * q 的乘积。

public long n(long p, long q) {
    return p * q;
}

3. 欧拉公式 φ(n)

φ(n) = (p - 1) * (q - 1)

public long euler(long p, long q) {
    return (p - 1) * (q - 1);
}

4. 选取公钥e

e 的值范围在 1 < e < φ(n)

public long e(long euler){
    long e = euler / 10;
    while (gcd(e, euler) != 1){
        e ++;
    }
    return e;
}

5. 选取私钥d

d = (kφ(n) + 1) / e

public long inverse(long e, long euler) {
    return (euler + 1) / e;
}

6. 加密

c = m^e mod n

public long encrypt(long m, long e, long n) {
    BigInteger bM = new BigInteger(String.valueOf(m));
    BigInteger bE = new BigInteger(String.valueOf(e));
    BigInteger bN = new BigInteger(String.valueOf(n));
    return Long.parseLong(bM.modPow(bE, bN).toString());
}

7. 解密

m = c^d mod n

public long decrypt(long c, long d, long n) {
    BigInteger bC = new BigInteger(String.valueOf(c));
    BigInteger bD = new BigInteger(String.valueOf(d));
    BigInteger bN = new BigInteger(String.valueOf(n));
    return Long.parseLong(bC.modPow(bD, bN).toString());
}

8. 测试

@Test
public void test_rsa() {
    RSA rsa = new RSA();
    long p = 3,                         // 选取2个互为质数的p、q
            q = 11,                     // 选取2个互为质数的p、q
            n = rsa.n(p, q),            // n = p * q
            euler = rsa.euler(p, q),    // euler = (p-1)*(q-1)
            e = rsa.e(euler),           // 互为素数的小整数e | 1 < e < euler
            d = rsa.inverse(e, euler),  // ed = φ(n) + 1 | d = (φ(n) + 1)/e
            msg = 5;                    // 传递消息 5
            
    System.out.println("消息：" + msg);
    System.out.println("公钥(n,e)：" + "(" + n + "," + e + ")");
    System.out.println("私钥(n,d)：" + "(" + n + "," + d + ")");
    
    long encrypt = rsa.encrypt(msg, e, n);
    System.out.println("加密（消息）：" + encrypt);
    
    long decrypt = rsa.decrypt(encrypt, d, n);
    System.out.println("解密（消息）：" + decrypt);
}

测试结果

消息：5
公钥(n,e)：(33,3)
私钥(n,d)：(33,7)
加密（消息）：26
解密（消息）：5

• 通过选取3、11作为两个互质数，计算出公钥和私钥，分别进行消息的加密和解密。如测试结果消息5的加密后的信息是26，解密后获得原始信息5

六、RSA数学原理

整个 RSA 的加解密是有一套数学基础可以推导验证的，这里小傅哥把学习整理的资料分享给读者，如果感兴趣可以尝试验证。这里的数学公式会涉及到；求模运算、最大公约数、贝祖定理、线性同于方程、中国余数定理、费马小定理。当然还有一些很基础的数论概念；素数、互质数等。以下推理数学内容来自博客：luyuhuang.tech/2019/10/24/…

1. 模运算

1.1 整数除法

定理 1 令 a 为整数, d 为正整数, 则存在唯一的整数 q 和 r, 满足 0⩽r<d, 使得 a=dq+r.

当 r=0 时, 我们称 d 整除 a, 记作 d∣a; 否则称 d 不整除 a, 记作 d∤a

整除有以下基本性质:

定理 2 令 a, b, c 为整数, 其中 a≠0a≠0. 则:

• 对任意整数 m,n，如果 a∣b 且 a∣c, 则 a∣(mb + nc)

• 如果 a∣b, 则对于所有整数 c 都有 a∣bc

• 如果 a∣b 且 b∣c, 则 a∣c

1.2 模算术

在数论中我们特别关心一个整数被一个正整数除时的余数. 我们用 a mod m = b表示整数 a 除以正整数 m 的余数是 b. 为了表示两个整数被一个正整数除时的余数相同, 人们又提出了同余式(congruence).

定义 1 如果 a 和 b 是整数而 m 是正整数, 则当 m 整除 a - b 时称 a 模 m 同余 b. 记作 a ≡ b(mod m)

a ≡ b(mod m) 和 a mod m= b 很相似. 事实上, 如果 a mod m = b, 则 a≡b(mod m). 但他们本质上是两个不同的概念. a mod m = b 表达的是一个函数, 而 a≡b(mod m) 表达的是两个整数之间的关系.

模算术有下列性质:

定理 3 如果 m 是正整数, a, b 是整数, 则有

(a+b)mod m=((a mod m)+(b mod m)) mod m

ab mod m=(a mod m)(b mod m) mod m

根据定理3, 可得以下推论

推论 1 设 m 是正整数, a, b, c 是整数; 如果 a ≡ b(mod m), 则 ac ≡ bc(mod m)

证明 ∵ a ≡ b(mod m), ∴ (a−b) mod m=0 . 那么

(ac−bc) mod m=c(a−b) mod m=(c mod m⋅(a−b) mod m) mod m=0

∴ ac ≡ bc(mod m)

需要注意的是, 推论1反之不成立. 来看推论2:

推论 2 设 m 是正整数, a, b 是整数, c 是不能被 m 整除的整数; 如果 ac ≡ bc(mod m) , 则 a ≡ b(mod m)

证明 ∵ ac ≡ bc(mod m) , 所以有

(ac−bc)mod m=c(a−b)mod m=(c mod m⋅(a−b)mod m) mod m=0

∵ c mod m≠0 ,

∴ (a−b) mod m=0,

∴a ≡ b(mod m) .

2. 最大公约数

如果一个整数 d 能够整除另一个整数 a, 则称 d 是 a 的一个约数(divisor); 如果 d 既能整除 a 又能整除 b, 则称 d 是 a 和 b 的一个公约数(common divisor). 能整除两个整数的最大整数称为这两个整数的最大公约数(greatest common divisor).

定义 2 令 a 和 b 是不全为零的两个整数, 能使 d∣ad∣a 和 d∣bd∣b 的最大整数 d 称为 a 和 b 的最大公约数. 记作 gcd(a,b)

2.1 求最大公约数

如何求两个已知整数的最大公约数呢? 这里我们讨论一个高效的求最大公约数的算法, 称为辗转相除法. 因为这个算法是欧几里得发明的, 所以也称为欧几里得算法. 辗转相除法基于以下定理:

引理 1 令 a=bq+r, 其中 a, b, q 和 r 均为整数. 则有 gcd(a,b)=gcd(b,r)

证明 我们假设 d 是 a 和 b 的公约数, 即 d∣a且 d∣b, 那么根据定理2, d 也能整除 a−bq=r 所以 a 和 b 的任何公约数也是 b 和 r 的公约数;

类似地, 假设 d 是 b 和 r 的公约数, 即 d∣bd∣b 且 d∣rd∣r, 那么根据定理2, d 也能整除 a=bq+r. 所以 b 和 r 的任何公约数也是 a 和 b 的公约数;

因此, a 与 b 和 b 与 r 拥有相同的公约数. 所以 gcd(a,b)=gcd(b,r).

辗转相除法就是利用引理1, 把大数转换成小数. 例如, 求 gcd(287,91) 我们就把用较大的数除以较小的数. 首先用 287 除以 91, 得

287=91⋅3+14

我们有 gcd(287,91)=gcd(91,14) . 问题转换成求 gcd(91,14). 同样地, 用 91 除以 14, 得

91=14⋅6+7

有 gcd(91,14)=gcd(14,7) . 继续用 14 除以 7, 得

14=7⋅2+0

因为 7 整除 14, 所以 gcd(14,7)=7. 所以 gcd(287,91)=gcd(91,14)=gcd(14,7)=7.

我们可以很快写出辗转相除法的代码:

def gcd(a, b):
    if b == 0: return a
    return gcd(b, a % b)

2.2 贝祖定理

现在我们讨论最大公约数的一个重要性质:

定理 4 贝祖定理 如果整数 a, b 不全为零, 则 gcd(a,b)是 a 和 b 的线性组合集 {ax+by∣x,y∈Z}中最小的元素. 这里的 x 和 y 被称为贝祖系数

证明 令 A={ax+by∣x,y∈Z}. 设存在 x0x0, y0y0 使 d0d0 是 A 中的最小正元素, d0=ax0+by0 现在用 d0去除 a, 这就得到唯一的整数 q(商) 和 r(余数) 满足

又 0⩽r<d0, d0 是 A 中最小正元素

∴ r=0 , d0∣a.

同理, 用 d0d0 去除 b, 可得 d0∣b. 所以说 d0 是 a 和 b 的公约数.

设 a 和 b 的最大公约数是 d, 那么 d∣(ax0+by0)即 d∣d0

∴∴ d0 是 a 和 b 的最大公约数.

我们可以对辗转相除法稍作修改, 让它在计算出最大公约数的同时计算出贝祖系数.

def gcd(a, b):
    if b == 0: return a, 1, 0
    d, x, y = gcd(b, a % b)
    return d, y, x - (a / b) * y

3. 线性同余方程

现在我们来讨论求解形如 ax≡b(modm) 的线性同余方程. 求解这样的线性同余方程是数论研究及其应用中的一项基本任务. 如何求解这样的方程呢? 我们要介绍的一个方法是通过求使得方程 ¯aa≡1(mod m) 成立的整数 ¯a. 我们称 ¯a 为 a 模 m 的逆. 下面的定理指出, 当 a 和 m 互素时, a 模 m 的逆必然存在.

定理 5 如果 a 和 m 为互素的整数且 m>1, 则 a 模 m 的逆存在, 并且是唯一的.

证明 由贝祖定理可知, ∵ gcd(a,m)=1 , ∴ 存在整数 x 和 y 使得 ax+my=1 这蕴含着 ax+my≡1(modm) ∵ my≡0(modm), 所以有 ax≡1(modm)

∴ x 为 a 模 m 的逆.

这样我们就可以调用辗转相除法 gcd(a, m) 求得 a 模 m 的逆.

a 模 m 的逆也被称为 a 在模m乘法群 Z∗m 中的逆元. 这里我并不想引入群论, 有兴趣的同学可参阅算法导论

求得了 a 模 m 的逆 ¯a 现在我们可以来解线性同余方程了. 具体的做法是这样的: 对于方程 ax≡b(modm)a , 我们在方程两边同时乘上 ¯a, 得 ¯aax≡¯ab(modm)

把 ¯aa≡1(modm) 带入上式, 得 x≡¯ab(modm)

x≡¯ab(modm) 就是方程的解. 注意同余方程会有无数个整数解, 所以我们用同余式来表示同余方程的解.

4. 中国余数定理

中国南北朝时期数学著作 孙子算经 中提出了这样一个问题:

有物不知其数，三三数之剩二，五五数之剩三，七七数之剩二。问物几何？

用现代的数学语言表述就是: 下列同余方程组的解释多少?

孙子算经 中首次提到了同余方程组问题及其具体解法. 因此中国剩余定理称为孙子定理.

定理 6 中国余数定理 令 m1,m2,…,mn 为大于 1 且两两互素的正整数, a1,a2,…,an 是任意整数. 则同余方程组

有唯一的模 m=m1m2…mnm=m1m2…mn 的解.

证明 我们使用构造证明法, 构造出这个方程组的解. 首先对于 i=1,2,…,ni=1,2,…,n, 令

即, MiMi 是除了 mimi 之外所有模数的积. ∵∵ m1,m2,…,mn 两两互素, ∴∴ gcd(mi,Mi)=1. 由定理 5 可知, 存在整数 yiyi 是 MiMi 模 mimi 的逆. 即

上式等号两边同时乘 aiai 得

就是第 i 个方程的一个解; 那么怎么构造出方程组的解呢? 我们注意到, 根据 Mi 的定义可得, 对所有的 j≠ij≠i, 都有 aiMiyi≡0(modmj). 因此我们令

就是方程组的解.

有了这个结论, 我们可以解答 孙子算经 中的问题了: 对方程组的每个方程, 求出 MiMi , 然后调用 gcd(M_i, m_i) 求出 yiyi:

最后求出 x=−2⋅35+3⋅21+2⋅15=23≡23(mod105)

5. 费马小定理

现在我们来看数论中另外一个重要的定理, 费马小定理(Fermat's little theorem)

定理 7 费马小定理 如果 a 是一个整数, p 是一个素数, 那么

当 n 不为 p 或 0 时, 由于分子有质数p, 但分母不含p; 故分子的p能保留, 不被约分而除去. 即 p∣(np).

令 b 为任意整数, 根据二项式定理, 我们有

令 a=b+1, 即得 a^p ≡ a(mod p)

当 p 不整除 a 时, 根据推论 2, 有 a^p−1 ≡ 1(mod p)

6. 算法证明

我们终于可以来看 RSA 算法了. 先来看 RSA 算法是怎么运作的:

RSA 算法按照以下过程创建公钥和私钥:

1. 随机选取两个大素数 p 和 q, p≠qp≠q;

2. 计算 n=pq

3. 选取一个与 (p−1)(q−1) 互素的小整数 e;

4. 求 e 模 (p−1)(q−1) 的逆, 记作 d;

5. 将 P=(e,n)公开, 是为公钥;

6. 将 S=(d,n)保密, 是为私钥.

所以 RSA 加密算法是有效的.

(1) 式表明, 不仅可以用公钥加密, 私钥解密, 还可以用私钥加密, 公钥解密. 即加密计算 C=M^d mod n, 解密计算 M=C^e mod n

RSA 算法的安全性基于大整数的质因数分解的困难性. 由于目前没有能在多项式时间内对整数作质因数分解的算法, 因此无法在可行的时间内把 n 分解成 p 和 q 的乘积. 因此就无法求得 e 模 (p−1)(q−1)的逆, 也就无法根据公钥计算出私钥.

七、常见面试题

• 质数的用途

• RSA 算法描述

• RSA 算法加解密的过程

• RSA 算法使用场景

• 你了解多少关于 RSA 的数学数论知识

• RSA加密算法：zh.wikipedia.org/wiki/RSA%E5…

• RSA算法原理： http://www.ruanyifeng.com/blog/2013/0…

• RSA算法背后的数学原理：luyuhuang.tech/2019/10/24/…

• 莱昂哈德·欧拉：en.wikipedia.org/wiki/Leonha…

源码：github.com/fuzhengwei/…
作者：小傅哥
来源：juejin.cn/post/7173830290812370958

mybatis-plus作为mybatis的增强工具，它的出现极大的简化了开发中的数据库操作，但是长久以来，它的联表查询能力一直被大家所诟病。一旦遇到left join或right join的左右连接，你还是得老老实实的打开xml文件，手写上一大段的sql语句。

直到前几天，偶然碰到了这么一款叫做mybatis-plus-join的工具（后面就简称mpj了），使用了一下，不得不说真香！彻底将我从xml地狱中解放了出来，终于可以以类似mybatis-plus中QueryWrapper的方式来进行联表查询了，话不多说，我们下面开始体验。

引入依赖

首先在项目中引入引入依赖坐标，因为mpj中依赖较高版本mybatis-plus中的一些api，所以项目建议直接使用高版本。

<dependency>
    <groupId>com.github.yulichang</groupId>
    <artifactId>mybatis-plus-join</artifactId>
    <version>1.2.4</version>
</dependency>
<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.1</version>
</dependency>

引入相关依赖后，在springboot项目中，像往常一样正常配置数据源连接信息就可以了。

数据准备

因为要实现联表查询，所以我们先来建几张表进行测试。

订单表：

用户表，包含用户姓名：

商品表，包含商品名称和单价：

在订单表中，通过用户id和商品id与其他两张表进行关联。

修改Mapper

以往在使用myatis-plus的时候，我们的Mapper层接口都是直接继承的BaseMapper，使用mpj后需要对其进行修改，改为继承MPJBaseMapper接口。

@Mapper
public interface OrderMapper extends MPJBaseMapper<Order> {
}

对其余两个表的Mapper接口也进行相同的改造。此外，我们的service也可以选择继承MPJBaseService，serviceImpl选择继承MPJBaseServiceImpl，这两者为非必须继承。

查询

Mapper接口改造完成后，我们把它注入到Service中，虽然说我们要完成3张表的联表查询，但是以Order作为主表的话，那么只注入这一个对应的OrderMapper就可以，非常简单。

@Service
@AllArgsConstructor
public class OrderServiceImpl implements OrderService {
    private final OrderMapper orderMapper;
}

MPJLambdaWrapper

接下来，我们体验一下再也不用写sql的联表查询：

public void getOrder() {
    List<OrderDto> list = orderMapper.selectJoinList(OrderDto.class,
     new MPJLambdaWrapper<Order>()
      .selectAll(Order.class)
      .select(Product::getUnitPrice)
      .selectAs(User::getName,OrderDto::getUserName)
      .selectAs(Product::getName,OrderDto::getProductName)
      .leftJoin(User.class, User::getId, Order::getUserId)
      .leftJoin(Product.class, Product::getId, Order::getProductId)
      .eq(Order::getStatus,3));

    list.forEach(System.out::println);
}

不看代码，我们先调用接口来看一下执行结果：

可以看到，成功查询出了关联表中的信息，下面我们一点点介绍上面代码的语义。

首先，调用mapper的selectJoinList()方法，进行关联查询，返回多条结果。后面的第一个参数OrderDto.class代表接收返回查询结果的类，作用和我们之前在xml中写的resultType类似。

这个类可以直接继承实体，再添加上需要在关联查询中返回的列即可：

@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class OrderDto extends Order {
    String userName;
    String productName;
    Double unitPrice;
}

接下来的MPJLambdaWrapper就是构建查询条件的核心了，看一下我们在上面用到的几个方法：

• selectAll()：查询指定实体类的全部字段

• select()：查询指定的字段，支持可变长参数同时查询多个字段，但是在同一个select中只能查询相同表的字段，所以如果查询多张表的字段需要分开写

• selectAs()：字段别名查询，用于数据库字段与接收结果的dto中属性名称不一致时转换

• leftJoin()：左连接，其中第一个参数是参与联表的表对应的实体类，第二个参数是这张表联表的ON字段，第三个参数是参与联表的ON的另一个实体类属性

除此之外，还可以正常调用mybatis-plus中的各种原生方法，文档中还提到，默认主表别名是t，其他的表别名以先后调用的顺序使用t1、t2、t3以此类推。

我们用插件读取日志转化为可读的sql语句，可以看到两条左连接条件都被正确地添加到了sql中：

MPJQueryWrapper

和mybatis-plus非常类似，除了LamdaWrapper外还提供了普通QueryWrapper的写法，改造上面的代码：

public void getOrderSimple() {
    List<OrderDto> list = orderMapper.selectJoinList(OrderDto.class,
     new MPJQueryWrapper<Order>()
      .selectAll(Order.class)
      .select("t2.unit_price","t2.name as product_name")
      .select("t1.name as user_name")
      .leftJoin("t_user t1 on t1.id = t.user_id")
      .leftJoin("t_product t2 on t2.id = t.product_id")
      .eq("t.status", "3")
    );

    list.forEach(System.out::println);
}

运行结果与之前完全相同，需要注意的是，这样写时在引用表名时不要使用数据库中的原表名，主表默认使用t，其他表使用join语句中我们为它起的别名，如果使用原表名在运行中会出现报错。

并且，在MPJQueryWrapper中，可以更灵活的支持子查询操作，如果业务比较复杂，那么使用这种方式也是不错的选择。

分页查询

mpj中也能很好的支持列表查询中的分页功能，首先我们要在项目中加入分页拦截器：

@Bean
public MybatisPlusInterceptor mybatisPlusInterceptor(){
    MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
    interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.H2));
    return interceptor;
}

接下来改造上面的代码，调用selectJoinPage()方法：

public void page() {
    IPage<OrderDto> orderPage = orderMapper.selectJoinPage(
      new Page<OrderDto>(2,10),
      OrderDto.class,
      new MPJLambdaWrapper<Order>()
        .selectAll(Order.class)
        .select(Product::getUnitPrice)
        .selectAs(User::getName, OrderDto::getUserName)
        .selectAs(Product::getName, OrderDto::getProductName)
        .leftJoin(User.class, User::getId, Order::getUserId)
        .leftJoin(Product.class, Product::getId, Order::getProductId)
        .orderByAsc(Order::getId));

    orderPage.getRecords().forEach(System.out::println);
}

注意在这里需要添加一个分页参数的Page对象，我们再执行上面的代码，并对日志进行解析，查看sql语句：

可以看到底层通过添加limit进行了分页，同理，MPJQueryWrapper也可以这样进行分页。

最后

经过简单的测试，个人感觉mpj这款工具在联表查询方面还是比较实用的，能更应对项目中不是非常复杂的场景下的sql查询，大大提高我们的生产效率。当然，在项目的issues中也能看到当前版本中也仍然存在一些问题，希望在后续版本迭代中能继续完善。

作者：码农参上
来源：juejin.cn/post/7173493838143553549

今天聊一个小伙伴在星球上的提问：

问题不难，解决方案也有很多，因此我决定撸一篇文章和大家仔细说说这个问题。

1. 配置文件位置

首先小伙伴们要明白，Spring Boot 默认加载的配置文件是 application.properties 或者 application.yaml，默认的加载位置一共有五个，五个位置可以分为两类：

从 classpath 下加载，这个又细分为两种：

1. 直接读取 classpath 下的配置文件，对应到 Spring Boot 项目中，就是 resources 目录下的配置。

2. 读取 classpath:/config/ 目录下的文件，对应到 Spring Boot 项目中就是 resources/config 目录下的配置。

这两种情况如下图：

从项目所在的当前目录下加载，这个又细分为三种情况：

1. 从项目当前目录下加载配置文件。

2. 从项目当前目录下的 config 文件夹中加载配置文件。

3. 从项目当前目录下的 config 文件夹的子文件夹中加载（孙子文件夹不可以）。

这三种情况如下图：

config 目录下的配置文件可以被加载，config/a 目录下的配置文件也可以被加载，但是 config/a/b 目录下的配置文件不会被加载，因为不是直接子文件夹。

配置文件可以放在这么多不同的位置，如果同一个属性在多个配置文件中都写了，那么后面加载的配置会覆盖掉前面的。例如在 classpath:application.yaml 中设置项目端口号是 8080，在 项目当前目录/config/a/application.yaml 中设置项目端口是 8081，那么最终的项目端口号就是 8081。

这是默认的文件位置。

如果你不想让自己的配置文件叫 application.properties 或者 application.yaml，那么也可以自定义配置文件名称，只需要在项目启动的时候指定配置文件名即可，例如我想设置我的配置文件名为 app.yaml，那么我们可以在启动 jar 包的时候按照如下方式配置，此时系统会自动去上面提到的五个位置查找对应的配置文件：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.name=app

如果项目已经打成 jar 包启动了，那么前面所说的目录中，后三个中的项目当前目录就是指 jar 包所在的目录。

如果你不想去这五个位置查找，那么也可以在启动 jar 包的时候明确指定配置文件的位置和名称，如下：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:classpath:/app.yaml

注意，我在 classpath 前面加上了 optional: 表示如果这个配置文件不存在，则按照默认的方式启动，而不会报错说找不到这个配置文件。如果不加这个前缀，那么当系统找不到指定的配置文件时，就会抛出 ConfigDataLocationNotFoundException 异常，进而导致应用启动失败。

如果配置文件和 jar 包在相同的目录结构下，如下图：

那么启动脚本如下：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:javaboy/app.yaml

如果 spring.config.location 的配置，只是指定了目录，那么必须以 / 结尾，例如上面这个启动脚本，也可以按照如下方式启动：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:javaboy/ --spring.config.name=app

通过 spring.config.location 属性锁定配置文件的位置，通过 spring.config.name 属性锁定配置文件的文件名。

2. 额外位置

前面我们关于配置文件位置的设置，都是覆盖掉已有的配置，如果不想覆盖掉 Spring Boot 默认的配置文件查找策略，又想加入自己的，那么可以按照如下方式指定配置文件位置：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.additional-location=optional:javaboy/app.yaml

如果这个额外指定的配置文件和已有的配置文件有冲突，那么还是以后来者为准。

3. 位置通配符

有一种情况，假设我有 redis 和 mysql 的配置，我想将之放在两个不同的文件夹中以便于管理，像下面这样：

那么在项目启动时，可以通过通配符 * 批量扫描相应的文件夹：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:config/*/

使用通配符批量扫描 mysql 和 redis 目录时，默认的加载顺序是按照文件夹的字母排序，即先加载 mysql 目录后加载 redis 目录。

需要注意的是，通配符只能用在外部目录中，不可以用在 classpath 中的目录上。另外，包含了通配符的目录，只能有一个通配符 *，不可以有多个，并且还必须是以 */ 结尾，即一个目录的最后部分可以不确定。

4. 导入外部配置

从 Spring Boot2.4 开始，我们也可以使用 spring.config.import 方法来导入配置文件，相比于 additional-location 配置，这个 import 导入更加灵活，可以导入任意名称的配置文件。

spring.config.import=optional:file:./dev.properties

甚至，这个 spring.config.import 还可以导入无扩展名的配置文件，例如我有一个配置文件，是 properties 格式的，但是这个这个配置文件没有扩展名，现在我想将之作为 properties 格式的配置文件导入，方式如下：

spring.config.import=optional:file:/Users/sang/dev[.properties]

好啦，看完上面的内容，文章一开始的问题答案就不用我多说了吧～

作者：江南一点雨
来源：juejin.cn/post/7168285587374342180

01 引言

1）背景

这是本人在面试“字节抖音”部门的一道系统设计题，岗位是“后端高级开发工程师”，二面的时候问到的。一开始，面试官笑眯眯地让我做个自我介绍，然后聊了聊项目。

当完美无瑕（吞吞吐吐）地聊完项目，并写了一道算法题之后。

面试官就开始发问了：小伙子，简历里面写到了熟悉架构设计是吧，那你知道程序设计的‘三高’指什么吗？

我心想，那不是由于程序员的系统不靠谱，领导不当人，天天加班改 BUG，导致年纪轻轻都高血脂、高血压和高血糖嘛！

但是，既然是面试，那领导肯定不愿意听这，于是我回答：程序三高，就是系统设计时需要考虑的高并发、高性能和高可用：

• 高并发就是在系统开发的过程中，需要保证系统可以同时并行处理很多请求；

• 高性能是指程序需要尽可能地占用更少的内存和 CPU，并且处理请求的速度要快；

• 高可用通常描述系统在一段时间内不可服务的时候很短，比如全年停机不超过 31.5 秒，俗称 6 个 9，即保证可用的时间为 99.9999%。

于是，面试官微微点头，心想小伙子还行，既然这难不住你，那我可得出大招了，就来道系统设计题吧！

2）需求说明

众所周知，当业务场景需要给用户发送网络地址或者二维码时，由于地址的长度比较长，通常为了占用更少的资源和提升用户体验。例如，谷歌搜索“计算机”词条地址如下：

https://www.google.com/search?q=%E8%AE%A1%E7%AE%97%E6%9C%BA&ei=KNZ5Y7y4MpiW-AaI4LSACw&ved=0ahUKEwi87MGgnbz7AhUYC94KHQgwDbAQ4dUDCBA&uact=5&oq=%E8%AE%A1%E7%AE%97%E6%9C%BA&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIECAAQQzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCC4QgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDoKCAAQRxDWBBCwAzoLCC4QgAQQxwEQ0QM6FggAEOoCELQCEIoDELcDENQDEOUCGAE6BwguENQCEENKBAhBGABKBAhGGABQpBZYzSVglydoA3ABeACAAZ0DiAGdD5IBCTAuNy4xLjAuMZgBAKABAbABCsgBCsABAdoBBAgBGAc&sclient=gws-wiz-serp

很明显，如果将这一长串网址发给用户，是十分不“体面”的。而且，遇到一些有字数限制的系统里面，比如微博发帖子就有字数限制，肯定无法发送这样的长链接地址。一般的短信链接中，大多也都是短链接地址：

所以，为了提升用户体验，以及日常业务的需要。我们需要设计一个短链接生成系统，除了业务功能实现以外，我们还得为全国的网络地址服务。在这么大的用户量下，数据该如何存储，高并发如何处理呢？

02 三种链接生成方法

1）需求分析

我心想，这面试官看着“慈眉善目”还笑眯眯的，但出的题目可不简单，这种类型的系统需要考虑的点太多了，绝对不能掉以轻心。

于是，我分别从链接生成、网址访问、缓存优化和高可用四个方面开始着手设计。

首先，生成短链地址，可以考虑用 UUID 或者自增 ID。对于每一个长链接转短链地址时，都必须生成一个全局唯一的短链值，不然就会发生冲突。所以，短链接的特点是：

• 数据存储量很大，全国的网址每天至少都是百万个短链接地址需要生成；

• 并发量也不小，遇到同时来访问系统，按一天 3600 秒来算，平均每秒至少上千个请求数；

• 短链接不可重复，否则会引起数据访问冲突。

2）雪花算法

首先，生成短链接，可以用雪花算法+哈希的方式来实现。

雪花算法是在分布式场景下，根据时间戳、不同的机器 ID 以及序列号生成的唯一数。它的优点在于简单方便，随取随用。

通过雪花算法取到的唯一数，再用哈希映射，将数字转为一个随机的字符串，如果短链字符串比较长，可以直接取前 6 位。但是，由于哈希映射的结果可能会发生冲突，所以对哈希算法的要求比较高。

2）62 进制数生成短链接

除了雪花算法，还可以用 62 进制数（A-Za-z0-9）来生成短链接地址。首先得到一个自增 ID，再将此值转换为 62 进制（a-zA-Z0-9）的字符串，一个亿的数字转换后也就五六位（1亿 -> zAL6e）。

将短链接服务器域名，与这个字符串进行拼接，就能得到短链接的 URL，比如：t.cn/zAL6e。

而生成自增 ID 需要考虑性能影响和并发安全性，所以我们可以通过 Redis 的 incr 命令来做一个发号器，它是一个原子操作，因此我们不必担心数字的安全性。而 Redis 是内存操作，所以效率也挺高。

3）随机数+布隆过滤器

除了自增 ID 以外，我们还可以生成随机数再转 62 进制的方法来生成短链接。但是，由于随机数可能重复，因此我们需要用布隆过滤器来去重。

布隆过滤器是一个巧妙设计的数据结构，它的原理是将一个值多次哈希，映射到不同的 bit 位上并记录下来。当新的值使用时，通过同样的哈希函数，比对各个 bit 位上是否有值：如果这些 bit 位上都没有值，说明这个数是唯一的；否则，就可能不是唯一的。

当然，这可能会产生误判，布隆过滤器一定可以发现重复的值，但 也可能将不重复的值判断为重复值，误判率大概为 0.05%，是可以接受的范围，而且布隆过滤器的效率极高。

因此，通过布隆过滤器，我们能判断生成的随机数是否重复：如果重复，就重新生成一个；如果不重复，就存入布隆过滤器和数据库，从而保证每次取到的随机数都是唯一的。

4）将短链接存到数据库

存库时，可能会因为库存量和技术栈，选用不同的数据库。但由于公司部门用 MySQL 比较多，且当前题目未提及技术选型，所以我们还是选用 MySQL 作为持久化数据库。

每当生成一个短链接后，需要在 MySQL 存储短链接到长链接的映射关系并加上唯一索引，即 zAL6e -> 真实URL。

03 重定向过程

浏览器访问短链接服务时，根据短链地址取到原始 URL，然后进行网址重定向。我们通常有两种重定向方式：

• 一种是返回给浏览器 301 响应码永久重定向，让其后续直接访问真实的 URL 地址；

• 一种是 302 临时重定向，让浏览器当前这次访问真实 URL，但后续请求时还是根据短链地址访问。

虽然用 301 浏览器只需一次请求，后续可以直接从浏览器获取长链接，这种方法可以提升访问速度，但是它没法统计短链接的访问次数。

所以根据业务需要，我们一般选用 302 重定向。

04 缓存设计

由于短链接是分发到多个用户手里的，可能在短时间内会多次访问，所以从 MySQL 写入/获取到长链接后可以放入 redis 缓存。

1）加入缓存

并且，短链接和长链接的对应关系一般不会频繁修改，所以数据库和缓存的一致性通过简单的旁路缓存模式来保证：

• 读（Read）数据时，若缓存未命中，则先读 DB，从 DB 中取出数据，放入缓存，同时返回响应；

• 写（Write）数据时，先更新 DB，再删除缓存。

当用户需要生成短链接时，先到这个映射表中看一下有没有对应的短链接地址。有就直接返回，并将这个 key-value 的过期时间增加一小时；没有就重新生成，并且将对应关系存入这个映射表中。

缓存的淘汰策略可以选用：

• LRU：Least Recently Used，最近最少使用算法，最近经常被读写的短链地址作为热点数据可以一直存在于缓存，淘汰那些很久没有访问过的短链 key；

• LFU：Least Frequently Userd，最近最不频繁使用算法，最近访问频率高的短链地址作为热点数据，淘汰那些访问频率较低的短链 key。

2）缓存穿透

但是，使用缓存也防止不了一些异常情况，比如“缓存穿透”。所谓缓存穿透，就是查询一个缓存和数据库中都不存在的短链接，如果并发量很大，就会导致所有在缓存中不存在的请求都打到 MySQL 服务器上，导致服务器处理不了这么多请求而阻塞，甚至崩溃。

所以，为了防止不法分子通过类似“缓存穿透”的方式来攻击服务器，我们可以采用两种方法来应对：

• 对不存在的短链地址加缓存，key 为短链接地址，value 值为空，过期时间可以设置得短一点；

• 采用布隆过滤器将已有的短链接多次哈希后存起来，当有短链接请求时，先通过布隆过滤器判断一下该地址是否存在数据库中；如果不在，则说明数据库中不存在该地址，就直接返回。

05 高可用设计

由于缓存和数据库持久化依赖于 Redis 和 MySQL，因此 MySQL 和 Redis 的高可用性必须要保证。

1）MySQL 高可用

MySQL 数据库采用主从复制，进行读写分离。Master 节点进行写操作，Slave 节点用作读操作，并且可以用 Keepalived 来实现高可用。

Keepalived 的原理是采用虚拟 IP，检测入口的多个节点，选用一台热备服务器作为主服务器，并分配给它一个虚拟 IP，外部请求都通过这个虚拟 IP 来访问数据库。

同时，Keepalived 会实时检测多个节点的可用状态，当发现一台服务器宕机或出现故障时，会从集群中将这台服务器踢除。如果这台服务器是主服务器，keepalived 会触发选举操作，从服务器集群中再选出一个服务器充当 master 并分配给它相同的虚拟 IP，以此完成故障转移。

并且，在 Keepalived 的支持下，这些操作都不需要人工参与，只需修复故障机器即可。

2）Redis 高可用

由于在大数据高并发的场景下，写请求全部落在 Redis 的 master 节点上，压力太大。如果一味地采用增加内存和 CPU 这种纵向扩容的方式，那么一台机器所面临的磁盘 IO，网络等压力逐渐增大，也会影响性能。

所以 Redis 采用集群模式，实现数据分片。并且，加入了哨兵机制来保证集群的高可用。它的基本原理是哨兵节点监控集群中所有的主从节点，当主节点宕机或者发生故障以后，哨兵节点会标记它为主观下线；当足够多的哨兵节点将 Redis 主节点标记为主观下线，就将其状态改为客观下线。

此时，哨兵节点们通过选举机制选出一个领头哨兵，对 Redis 主节点进行故障转移操作，以保障 Redis 集群的高可用，这整个流程都不需要人工干预。

3）系统容错

服务在上线之前，需要做好充分的业务量评估，以及性能测试。做好限流、熔断和服务降级的逻辑，比如：采用令牌桶算法实现限流，hystrix 框架来做熔断，并且将常用配置放到可以热更新的配置中心，方便对其实时更改。

当业务量过大时，将同步任务改为异步任务处理。通过这些服务治理方案，让系统更加稳定。

06 后记

当我答完最后一个字的时候，面试官看着我，眼神中充满了“欣赏”与疑惑。我想，他应该是被我这番表现给镇住了，此次面试应该是十拿九稳。

但是，出奇地，面试官没有对刚才的架构设计提出评价，只看了看我说：“那今天的面试就到这里，你有什么想要问的吗？”

这下，轮到我震惊了，那到底过不过呢？倒是给句话呀，于是我问道：“通过这次面试，您觉得我有哪些方面需要提升呢？”

“算法和项目需要再多练练，但是我发现了你一个优点。”面试官笑了笑接着说，“八股文背的倒是挺不错的！”

悬着的心总算放下，我心想：“哦，那稳了~”

作者：xin猿意码
来源：juejin.cn/post/7168090412370886686

事情是这样的

下面是我朋友的面试记录：

面试官：讲一下你实习做了什么。

朋友：我在实习期间做了一个存储用户操作记录的功能，主要是从MQ获取上游服务发送过来的用户操作信息，然后把这些信息存到MySQL里面，提供给数仓的同事使用。由于数据量比较大，每天大概有四五千多万条，所以我还给它做了分表的操作。每天定时生成3张表，然后将数据取模分别存到这三张表里，防止表内数据过多导致查询速度降低。

这表述，好像没什么问题是吧，别急，接着看：

面试官：那你为什么要分三张表呢，两张表不行吗？四张表不行吗？

朋友：因为MySQL每张表最好不超过2000万条数据，否则会导致查询速度降低，影响性能。我们每天的数据大概是在五千万条左右，所以分成三张表比较稳妥。

面试官：还有吗？

朋友： 没有了…… 你干嘛，哎呦

面试官：那你先回去等通知吧。

🤣🤣🤣讲完了，看出什么了吗，你们觉得我这位朋友回答的有什么问题吗？

前言

一般来说，MySQL每张表最好不要超过2000万条数据，否则就会导致性能下降。阿里的Java开发手册上也提出：单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

但实际上，这个2000万或者500万都只是一个大概的数字，并不适用于所有场景，如果盲目的以为表数据只要不超过2000万条就没问题了，很可能会导致系统的性能大幅下降。

实际情况下，每张表由于自身的字段不同、字段所占用的空间不同等原因，它们在最佳性能下可以存放的数据量也就不同。

那么，该如何计算出每张表适合的数据量呢？别急，慢慢往下看。

本文适合的读者

阅读本文你需要有一定的MySQL基础，最好对InnoDB和B+树都有一定的了解，可能需要有一年以上的MySQL学习经验（大概一年？），知道 “InnoDB中B+树的高度一般保持在三层以内会比较好”。

本文主要是针对 “InnoDB中高度为3的B+树最多可以存多少数据” 这一话题进行讲解的。且本文对数据的计算比较严格（至少比网上95%以上的相关博文都要严格），如果你比较在意这些细节并且目前不太清楚的话，请继续往下阅读。

阅读本文你大概需要花费10-20分钟的时间，如果你在阅读的过程中对数据进行验算的话，可能要花费30分钟左右。

基础知识快速回顾

众所周知，MySQL中InnoDB的存储结构是B+树，B+树大家都熟悉吧？特性大概有以下几点，一起快速回顾一下吧！

注：下面这这些内容都是精华，看不懂或者不理解的同学建议先收藏本文，之后有知识基础了再回来看 。🤣🤣

1. 一张数据表一般对应一颗或多颗树的存储，树的数量与建索引的数量有关，每个索引都会有一颗单独的树。

2. 聚簇索引和非聚簇索引：

   主键索引也是聚簇索引，非主键索引都是非聚簇索引，两种索引的非叶子节点都是只存索引数据的，比如索引为id，那非叶子节点就只存id的数据。

   叶子节点的区别如下：

   • 聚簇索引的叶子节点存的是这条数据的所有字段信息。所以我们 select * from table where id = 1 的时候，都是要去叶子节点拿数据的。

   • 非聚簇索引的叶子节点存的是这条数据所对应的主键信息。比如这条非聚簇索引是username，然后表的主键是id，那该非聚簇索引的叶子节点存的就是id，而不存其他字段。 相当于是先从非聚簇索引查到主键的值，再根据主键索引去查数据内容，一般情况下要查两次（除非索引覆盖），这也称之为 回表 ，就有点类似于存了个指针，指向了数据存放的真实地址。

3. B+树的查询是从上往下一层层查询的，一般情况下我们认为B+树的高度保持在3层是比较好的，也就是上两层是索引，最后一层存数据，这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次，因为根节点会常驻内存)。

   如果数据量过大，导致B+数变成4层了，则每次查询就需要进行4次磁盘IO了，从而使性能下降。所以我们才会去计算InnoDB的3层B+树最多可以存多少条数据。

4. MySQL每个节点大小默认为16KB，也就是每个节点最多存16KB的数据，可以修改，最大64KB，最小4KB。

   扩展：那如果某一行的数据特别大，超过了节点的大小怎么办？

   MySQL5.7文档的解释是：

   • 对于 4KB、8KB、16KB 和 32KB设置 ，最大行长度略小于数据库页面的一半 ，例如：对于默认的 16KB页大小，最大行长度略小于 8KB 。

   • 而对于 64KB 页面，最大行则长度略小于 16KB。

   • 如果行超过最大行长度， 则将可变长度列用外部页存储，直到该行符合最大行长度限制。 就是说把varchar、text这种长度可变的存到外部页中，来减小这一行的数据长度。

   

   文档地址：MySQL :: MySQL 5.7 Reference Manual :: 14.12.2 File Space Management

5. MySQL查询速度主要取决于磁盘的读写速度，因为MySQL查询的时候每次只读取一个节点到内存中，通过这个节点的数据找到下一个要读取的节点位置，再读取下一个节点的数据，直到查询到需要的数据或者发现数据不存在。

   肯定有人要问了，每个节点内的数据难道不用查询吗？这里的耗时怎么不计算？

   这是因为读取完整个节点的数据后，会存到内存当中，在内存中查询节点数据的耗时其实是很短的，再配合MySQL的查询方式，时间复杂度差不多为 O(log2N)O(log_2N)O(log2N) ，相比磁盘IO来说，可以忽略不计。

MySQL B+树每个节点都存里些什么？

在Innodb的B+树中，我们常说的节点被称之为 页(page)，每个页当中存储了用户数据，所有的页合在一起组成了一颗B+树（当然实际会复杂很多，但我们只是要计算可以存多少条数据，所以姑且可以这么理解😅）。

页 是InnoDB存储引擎管理数据库的最小磁盘单位，我们常说每个节点16KB，其实就是指每页的大小为16KB。

这16KB的空间，里面需要存储 页格式 信息和 行格式 信息，其中行格式信息当中又包含一些元数据和用户数据。所以我们在计算的时候，要把这些数据的都计算在内。

页格式

每一页的基本格式，也就是每一页都会包含的一些信息，总结表格如下：

示意图：

页格式这块的内容，我在官网翻了好久，硬是没找到🤧。。。。不知道是没写还是我眼瞎，有找到的朋友希望可以在评论区帮我挂出来😋。

所以上面页格式的表格内容主要是基于一些博客中学习总结的。

另外，当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。参考文档：MySQL :: MySQL 5.7 Reference Manual :: 14.6.2.2 The Physical Structure of an InnoDB Index

除了 User Records和Free Space 以外所占用的内存是 38+56+26+8=12838 + 56 + 26 + 8 = 12838+56+26+8=128 字节，每一页留给用户数据的空间就还剩 16×1516×1024−128=1523216 \times \frac{15}{16} \times 1024 - 128 = 1523216×1615×1024−128=15232 字节（保留了1/16）。

当然，这是最小值，因为我们没有考虑页目录。页目录留在后面根据再去考虑，这个得根据表字段来计算。

行格式

首先，我觉得有必要提一嘴，MySQL5.6的默认行格式为COMPACT(紧凑)，5.7及以后的默认行格式为DYNAMIC(动态)，不同的行格式存储的方式也是有区别的，还有其他的两种行格式，本文后续的内容主要是基于DYNAMIC(动态)进行讲解的。

官方文档链接：MySQL :: MySQL 5.7 参考手册 :: 14.11 InnoDB 行格式（包括下面的行格式内容大都可以在里面找到）

每行记录都包含以下这些信息，其中大都是可以从官方文档当中找到的。我这里写的不是特别详细，仅写了一些能够我们计算空间的知识，更详细内容可以去网上搜索 “MySQL 行格式”。

示意图：

另外还有几点需要注意：

溢出页（外部页）的存储

注意：这一点是DYNAMIC的特性。

当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。

而 COMPACT 行格式（MySQL5.6默认格式）则是将前 768 个字节和 20 字节的指针存储在 B+ 树节点的记录中，其余部分存储在溢出页上。

列是否存储在页外取决于页大小和行的总大小。当一行太长时，选择最长的列进行页外存储，直到聚集索引记录适合 B+ 树页（文档里没说具体是多少😅）。小于或等于 40 字节的 TEXT 和 BLOB 直接存储在行内，不会分页。

优点

DYNAMIC 行格式避免了用大量数据填充 B+ 树节点从而导致长列的问题。

DYNAMIC 行格式的想法是，如果长数据值的一部分存储在页外，则通常将整个值存储在页外是最有效的。

使用 DYNAMIC 格式，较短的列会尽可能保留在 B+ 树节点中，从而最大限度地减少给定行所需的溢出页数。

字符编码不同情况下的存储

char 、varchar、text 等需要设置字符编码的类型，在计算所占用空间时，需要考虑不同编码所占用的空间。

varchar、text等类型会有长度字段列表来记录他们所占用的长度，但char是固定长度的类型，情况比较特殊，假设字段 name 的类型为 char(10) ，则有以下情况：

• 对于长度固定的字符编码（比如ASCII码），字段 name 将以固定长度格式存储，ASCII码每个字符占一个字节，那 name 就是占用 10 个字节。

• 对于长度不固定的字符编码（比如utf8mb4），至少将为 name 保留 10 个字节。如果可以，InnoDB会通过修剪尾部空格空间的方式来将其存到 10 个字节中。

  如果空格剪完了还存不下，则将尾随空格修剪为 列值字节长度的最小值（一般是 1 字节）。

  列的最大长度为： 字符编码的最大字符长度×N字符编码的最大字符长度 \times N字符编码的最大字符长度×N，比如 name 字段的编码为 utf8mb4，那就是 4×104 \times 104×10。

• 大于或等于 768 字节的 char 列会被看成是可变长度字段（就像varchar一样），可以跨页存储。例如，utf8mb4 字符集的最大字节长度为 4，则 char(255) 列将可能会超过 768 个字节，进行跨页存储。

说实话对char的这个设计我是不太理解的，尽管看了很久，包括官方文档和一些博客🤧，希望懂的同学可以在评论区解惑：

对于长度不固定的字符编码这块，char是不是有点像是一个长度可变的类型了？我们常用的 utf8mb4，占用为 1 ~ 4 字节，那么 char(10) 所占用的空间就是 10 ~ 40 字节，这个变化还是挺大的啊，但是它并没有留足够的空间给它，也没有使用可变长度字段列表去记录char字段的空间占用情况，就很特殊？

开始计算

好了，我们已经知道每一页当中具体存储的东西了，现在我们已经具备计算能力了。

由于页的剩余空间我已经在上面页格式的地方计算过了，每页会剩余 15232 字节可用，下面我们直接计算行。

非叶子节点计算

单个节点计算

索引页就是存索引的节点，也就是非叶子节点。

每一条索引记录当中都包含了当前索引的值 、 一个 6字节 的指针信息 、一个 5 字节的行标头，用来指向下一层数据页的指针。

索引记录当中的指针占用空间我没在官方文档里找到😭，这个 6 字节是我参考其他博文的，他们说源码里写的是6字节，但具体在哪一段源码我也不知道😭。

希望知道的同学可以在评论区解惑。

假设我们的主键id为 bigint 型，也就是8个字节，那索引页中每行数据占用的空间就等于 8+6+5=198 + 6 + 5 = 198+6+5=19 字节。每页可以存 15232÷19≈80115232 \div 19 \approx 80115232÷19≈801 条索引数据。

那算上页目录的话，按每个槽平均6条数据计算的话，至少有 801÷6≈134801 \div 6 \approx 134801÷6≈134 个槽，需要占用 268 字节的空间。

把存数据的空间分一点给槽的话，我算出来大约可以存 787 条索引数据。

如果是主键是 int 型的话，那可以存更多，大约有 993 条索引数据。

前两层非叶子节点计算

在 B+ 树当中，当一个节点索引记录为 NNN 条时，它就会有 NNN 个子节点。由于我们 3 层B+树的前两层都是索引记录，第一层根节点有 NNN 条索引记录，那第二层就会有 NNN 个节点，每个节点数据类型与根节点一致，仍然可以再存 NNN 条记录，第三层的节点个数就会等于 N2N^2N2。

则有：

• 主键为 bigint 的表可以存放 7872=619369787 ^ 2 = 6193697872=619369 个叶子节点

• 主键为 int 的表可以存放 9932=986049993 ^ 2 = 9860499932=986049 个叶子节点

OK计算完毕。

数据条数计算

最少存放记录数

前面我们提到，最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据，每条数据略小于8KB。如果某行的数据长度超过这个值，那InnoDB肯定会分一些数据到 溢出页 当中去了，所以我们不考虑。

那每条数据8KB的话，每个叶子节点就只能存放 2 条数据，这样的一张表，在主键为 bigint 的情况下，只能存放 2×619369=12387382 \times 619369 = 12387382×619369=1238738 条数据，也就是一百二十多万条，这个数据量，没想到吧🤣🤣。

较多的存放记录数

假设我们的表是这样的：

-- 这是一张非常普通的课程安排表，除id外，仅包含了课程id和老师id两个字段
-- 且这几个字段均为 int 型（当然实际生产中不会这么设计表，这里只是举例）。

CREATE TABLE `course_schedule` (
  `id` int NOT NULL,
  `teacher_id` int NOT NULL,
  `course_id` int NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

先来分析一下这张表的行数据：无null值列表，无可变长字段列表，需要算上事务ID和指针字段，需要算上行记录头，那么每行数据所占用的空间就是 4+4+4+6+7+5=304 + 4 + 4 + 6 + 7 + 5 = 304+4+4+6+7+5=30 字节，每个叶子节点可以存放 15232÷30≈50715232 \div 30 \approx 50715232÷30≈507 条数据。

算上页目录的槽位所占空间，每个叶子节点可以存放 502 条数据，那么三层B+树可以存放的最大数据量就是 502×986049=494,996,598502 \times 986049 = 494,996,598502×986049=494,996,598，将近5亿条数据！没想到吧🤡😏。

常规表的存放记录数

大部分情况下我们的表字段都不是上面那样的，所以我选择了一场比较常规的表来进行分析，看看能存放多少数据。表情况如下：

CREATE TABLE `blog` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '博客id',
  `author_id` bigint unsigned NOT NULL COMMENT '作者id',
  `title` varchar(50) CHARACTER SET utf8mb4 NOT NULL COMMENT '标题',
  `description` varchar(250) CHARACTER SET utf8mb4 NOT NULL COMMENT '描述',
  `school_code` bigint unsigned DEFAULT NULL COMMENT '院校代码',
  `cover_image` char(32) DEFAULT NULL COMMENT '封面图',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `release_time` datetime DEFAULT NULL COMMENT '首次发表时间',
  `modified_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `status` tinyint unsigned NOT NULL COMMENT '发表状态',
  `is_delete` tinyint unsigned NOT NULL DEFAULT 0,
  PRIMARY KEY (`id`),
  KEY `author_id` (`author_id`),
  KEY `school_code` (`school_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_general_mysql500_ci ROW_FORMAT=DYNAMIC;

这是我的开源项目“校园博客”（GitHub地址：github.com/stick-i/scb…） 中的博客表，用于存放博客的基本数据。

分析一下这张表的行记录：

1. 行记录头信息：肯定得有，占用5字节。

2. 可变长度字段列表：表中 title占用1字节，description占用2字节，共3字节。

3. null值列表：表中仅school_code、cover_image、release_time3个字段可为null，故仅占用1字节。

4. 事务ID和指针字段：两个都得有，占用13字节。

5. 字段内容信息：

   1. id、author_id、school_code 均为bigint型，各占用8字节，共24字节。

   2. create_time、release_time、modified_time 均为datetime类型，各占8字节，共24字节。

   3. status、is_delete 为tinyint类型，各占用1字节，共2字节。

   4. cover_image 为char(32)，字符编码为表默认值utf8，由于该字段实际存的内容仅为英文字母（存url的），结合前面讲的字符编码不同情况下的存储 ，故仅占用32字节。

   5. title、description 分别为varchar(50)、varchar(250)，这两个应该都不会产生溢出页（不太确定），字符编码均为utf8mb4，实际生产中70%以上都是存的中文(3字节)，25%为英文(1字节)，还有5%为4字节的表情😁，则存满的情况下将占用 (50+250)×(0.7×3+0.25×1+0.05×4)=765(50 + 250) \times (0.7 \times 3 + 0.25 \times 1 + 0.05 \times 4 ) = 765(50+250)×(0.7×3+0.25×1+0.05×4)=765 字节。

统计上面的所有分析，共占用 869 字节，则每个叶子节点可以存放 15232÷869≈1715232 \div 869 \approx 1715232÷869≈17 条，算上页目录，仍然能放 17 条。

则三层B+树可以存放的最大数据量就是 17×619369=10,529,27317 \times 619369 = 10,529,27317×619369=10,529,273，约一千万条数据，再次没想到吧👴。

数据计算总结

根据上面三种不同情况下的计算，可以看出，InnoDB三层B+树情况下的数据存储量范围为 一百二十多万条 到 将近5亿条，这个跨度还是非常大的，同时我们也计算了一张博客信息表，可以存储 约一千万条 数据。

所以啊，我们在做项目考虑分表的时候还是得多关注一下表的实际情况，而不是盲目的认为两千万数据都是那个临界点。

面试时如果谈到这块的问题，我想面试官也并不是想知道这个数字到底是多少，而是想看你如何分析这个问题，如何得出这个数字的过程。

如果本文中有任何写的不对的地方，欢迎各位朋友在评论区指正🥰。

写在后面的一些话

这篇文章写了整整两周😭😭（虽然第一周在划水），真的超级干货了，前前后后查了好多资料，也看了好多博文，官方文档有些地方写的确实含糊，我看了好久都没看懂😂😂。

作者：阿杆
来源：juejin.cn/post/7165689453124517896

前提

看B+树 看不懂树结构什么意思 这一篇可以帮你理解树结构生成的过程

在说B+ 树之前 需要知道 一页的大小是多少

show global status like 'innodb_page_size'

这个是看出 一页是 16384 也就是 16384/1024 = 16kb innodb中一页的大小默认是 16kb

正文

创建表结构 指定引擎为 Innodb

CREATE TABLE tree(
id int PRIMARY key auto_increment,
t_name VARCHAR(20),
t_code int 
) ENGINE=INNODB

查看一下当前表的索引情况

show index from tree 

B树和B+树的显示都是BTREE 但是实际使用的B+树 但是B+树也是B树的升级版 称之为B树也是没有问题的

创建数据 这里会有一个小知识点 如果看过上一篇文章的朋友可以明白是为什么

INSERT into tree VALUES(3,"变成派大星",3);
INSERT into tree VALUES(1,"变成派大星",1);
INSERT into tree VALUES(2,"变成派大星",2);
INSERT into tree VALUES(4,"变成派大星",4);
INSERT into tree VALUES(7,"变成派大星",7);
INSERT into tree VALUES(5,"变成派大星",5);
INSERT into tree VALUES(6,"变成派大星",6);
INSERT into tree VALUES(8,"变成派大星",8);

疑问

为什么创建数据的时候数据是乱的但是在创建好数据 被拍好顺序了

基础知识

我们在寻找答案之前 想明白一些基础知识

细心的朋友可以看出来 我们插入Id 时候数据是乱的 插入进去之后 数据就自动帮我通过Id 进行排序了 这是为什么呢？接着往下看

我们如果对于B+树有点了解的话就知道B+树是每页16KB 进行数据储存 在进行数据查询的时候也是一页一页的去查询

相当于下面的数据

首先每一页都有很多数据 就像 我们平常去写分页的时候我们返回给前端的数据也会有很多属性

这个可能比较抽象 我是把他当成平常 分页查询的思想代入进去

我们可以把一页想成是一个对象

@Data
public class page {

List<UserRecords> data;

....省略其余属性
}

我们先看一下 一页数据的图是什么样子 仅仅是进行逻辑思考画的图

这里的Data 就相当于 一页中的数据区域

但是这里是有限制的 上面我们说到 一页的数据只能是16Kb 也就是 一个Page 里面的data只能16Kb 数据 当超过16Kb 就会新开一个对象相当于在进行创建树的时候增加了判断

Java代码思路模拟：

当 Page 对象的大小已经达到16Kb 就算完成这一页 把这一页放到 磁盘中等待使用就行了 到时候进行查询数据的时候会直接返回这一页 里面包含这些数据

我们回到最初的问题 为什么我们在进行插入的时候明明Id 是乱的 等到插入到数据的时候 数据就变成有序的了 我们知道 同时这个数据是根据主键进行排序的 也就Innobd 的数据储存一定是要依赖主键的 有些人会想 我就是不创建主键 他还能排序吗？

疑问二

我们在疑问一的基础上 产生出的疑问 不设置主键 Mysql怎么办

解答

InnoDB对聚簇索引处理如下：

• 如果定义了主键，那么InnoDB会使用主键作为聚簇索引

• 如果没有定义主键，那么会使用第一非空的唯一索引（NOT NULL and UNIQUE INDEX）作为聚簇索引

• 如果既没有主键也找不到合适的非空索引，InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id，而且InnoDB 维护了一个全局的 dictsys.row_id，所以未定义主键的表都共享该row_id，每次插入一条数据，都把全局row_id当成主键id，然后全局row_id加1

很明显，缺少主键的表，InnoDB会内置一列用于聚簇索引来组织数据。而没有建立主键的话就没法通过主键来进行索引，查询的时候都是全表扫描，小数据量没问题，大数据量就会出现性能问题。

但是，问题真的只是查询影响吗？不是的，对于生成的ROW_ID，其自增的实现来源于一个全局的序列，而所以有ROW_ID的表共享该序列，这也意味着插入的时候生成需要共享一个序列，那么高并发插入的时候为了保持唯一性就避免不了锁的竞争，进而影响性能

解答

我们看完疑问二的解答就知道 即便我们不设置主键 数据也会帮我们去生成一个默认的主键 有点像 类默认生成构造器的思想

有了主键之后呢？

为什么会自动排序 大家都知道了 其实在文章之初就会有很多人明白是为什么 大概脑子里会有答案

疑问三

为什么要进行排序

解答

我们都知道 在进行数据查找的时候 比如几个基础的查找算法的 前提都是 先进行排序 再者 List 和 Map 的一些区别肯定都很熟悉了 当然是为了更快 所以无需的Id 会对插入效率造成影响 也就是为什么很多文章说使用自增Id比UUID 或者雪花算效率高的原因 第一个是UUID他们是随机的 每次都要重新排序 甚至可能会因为排序的原因造成页数据的更换 还有就是 UUID 一般都比较长 一页是16Kb 数据越短 一页的数据就会越多 查询的速度也就比较快

这里说完为什么排序 还有一个点就是上面的页目录

疑问三

页目录的作用是什么？

通过上一篇文章可以明白 页目录的作用是减少范围

这里的第三层是数据 上面都是目录 可以增加数据的检索效率

如果没有目录我们需要去直接遍历数据区域 会降低效率 目录能帮我们缩小范围 这里 我们查询 ID = 3 我们可以通过目录知道 1 < 3 < 4 如果 在1 中没有找到对应数据 但是 因为 3 < 4 就不会接着往下查询了 直接返回空结果

当第一页没有的时候去第二页查询 不会直接跳到第二页查询

为了提高效率 当目录数据数量过多时 就会网上延伸一层树 同时可以减少磁盘的IO次数

关于所有叶子节点都处于同一深度是如何实现的？这与B+树具体的插入和删除算法有关。简单解释一下插入时的情况，根据插入值的大小，逐步向下直到对应的叶子节点。如果叶子节点关键字个数小于2t，则直接插入值或者更新卫星数据；如果插入之前叶子节点已经满了，则分裂该叶子节点成两半，并把中间值提上到父节点的关键字中，如果这导致父节点满了的话，则把该父节点分裂，如此递归向上。所以树高是一层层的增加的，叶子节点永远都在同一深度。

小总结

• 内部节点并不存储真正的信息，而是保存其叶子节点的最小值作为索引。

• 每次插入删除都进行更新(此时用到parent指针)，保持最新状态。

• B+ 树非叶子节点上是不存储数据的，仅存储键值

• B+只在底层树储存数据，上层就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的 IO 次数又会再次减少，数据查询的效率也会更快。

• B+ 树的阶数是等于键值的数量的，如果我们的 B+ 树一个节点可以存储 1000 个键值，那么 3 层 B+ 树可以存储 1000×1000×1000=10 亿个数据。

• 一般根节点是常驻内存的，所以一般我们查找 10 亿数据，只需要 2 次磁盘 IO。

• 因为 B+ 树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的。

• 那么 B+ 树使得范围查找，排序查找，分组查找以及去重查找变得异常简单

• 有心的读者可能还发现上图 B+ 树中各个页之间是通过双向链表连接的，叶子节点中的数据是通过单向链表连接的。

• 其实上面的 B 树我们也可以对各个节点加上链表。这些不是它们之前的区别，是因为在 MySQL 的 InnoDB 存储引擎中，索引就是这样存储的。

• 我们通过数据页之间通过双向链表连接以及叶子节点中数据之间通过单向链表连接的方式可以找到表中所有的数据。

作者：变成派大星
来源：juejin.cn/post/7162856738692005918

本来是一个平静而美好的下午，其他部门的同事要一份数据报表临时汇报使用，因为系统目前没有这个维度的功能，所以需要写个SQL马上出一下，一个同事接到这个任务，于是开始在测试环境拼装这条 SQL，刚过了几分钟，同事已经自信的写好了这条SQL，于是拿给DBA，到线上跑一下，用客户端工具导出Excel 就好了，毕竟是临时方案嘛。

就在SQL执行了之后，意外发生了，先是等了一下，发现还没执行成功，猜测可能是数据量大的原因，但是随着时间滴滴答答流逝，逐渐意识到情况不对了，一看监控，CPU已经上去了，但是线上数据量虽然不小，也不至于跑成这样吧，眼看着要跑死了，赶紧把这个事务结束掉了。

什么原因呢？查询的条件和 join 连接的字段基本都有索引，按道理不应该这样啊，于是赶紧把SQL拿下来，也没看出什么问题，于是限制查询条数再跑了一次，很快出结果了，但是结果却大跌眼镜，出来的查询结果并不是预期的。

经过一番检查之后，最终发现了问题所在，是 join 连接中有一个字段写错了，因为这两个字段有一部分名称是相同的，于是智能的 SQL 客户端给出了提示，顺手就给敲上去了。但是接下来，更让人迷惑了，因为要连接的字段是 int 类型，而写错的这个字段是 varchar 类型，难道不应该报错吗？怎么还能正常执行，并且还有预期外的查询结果？

难道是 MySQL 有 bug 了，必须要研究一下了。

复现当时的情景

假设有两张表，这两张表的结构和数据是下面这样的。

第一张 user表。

CREATE TABLE `user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(50) COLLATE utf8_bin DEFAULT NULL,
 `age` int(3) DEFAULT NULL,
 `create_time` datetime DEFAULT NULL,
 `update_time` datetime DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;


INSERT INTO `user` VALUES (1, '张三', 28, '2022-09-06 07:40:56', '2022-09-06 07:40:59');

第二张 order表

CREATE TABLE `order` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` int(11) DEFAULT NULL,
 `order_code` varchar(64) COLLATE utf8_bin DEFAULT NULL,
 `money` decimal(20,0) DEFAULT NULL,
 `title` varchar(255) COLLATE utf8_bin DEFAULT NULL,
 `create_time` datetime DEFAULT NULL,
 `update_time` datetime DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;


INSERT INTO `order` VALUES (1, 2, '1d90530e-6ada-47c1-b2fa-adba4545aabd', 100, 'xxx购买两件商品', '2022-09-06 07:42:25', '2022-09-06 07:42:27');

目的是查看所有用户的 order 记录，假设数据量比较少，可以直接查，不考虑性能问题。

本来的 SQL 语句应该是这样子的，查询 order表中用户iduser_id在user表的记录。

select o.* from `user` u 
left JOIN `order` o on u.id = o.user_id;

但是呢，因为手抖，将 on 后面的条件写成了 u.id = o.order_code，完全关联错误，这两个字段完全没有联系，而且u.id是 int 类型，o.order_code是varchar类型。

select o.* from `user` u 
left JOIN `order` o on u.id = o.order_code;

这样的话， 当我们执行这条语句的时候，会不会查出数据来呢？

我的第一感觉是，不仅不会查出数据，而且还会报错，因为连接的这两个字段类型都不一样，值更不一样。

结果却被啪啪打脸，不仅没有报错，而且还查出了数据。

可以把这个问题简化一下，简化成下面这条语句，同样也会出现问题。

select * from `order` where order_code = 1;

明明这条记录的 order_code 字段的值是 1d90530e-6ada-47c1-b2fa-adba4545aabd，怎么用 order_code=1的条件就把它给查出来了。

根源所在

相信有的同学已经猜出来了，这里是 MySQL 进行了隐式转换，由于查询条件后面跟的查询值是整型的，所以 MySQL 将 order_code字段进行了字符串到整数类型的转换，而转换后的结果正好是 1。

通过 cast函数转换验证一下结果。

select cast('1d90530e-6ada-47c1-b2fa-adba4545aabd' as unsigned);

再用两条 SQL 看一下字符串到整数类型转换的规则。

select cast('223kkk' as unsigned);
select cast('k223kkk' as unsigned);

223kkk转换后的结果是 223，而k223kkk转换后的结果是0。总结一下，转换的规则是：

1、从字符串的左侧开始向右转换，遇到非数字就停止；

2、如果第一个就是非数字，最后的结果就是0；

隐式转换的规则

当操作符与不同类型的操作数一起使用的时候，就会发生隐式转换。

例如算数运算符的前后是不同类型时，会将非数字类型转换为数字，比如 '5a'+2，就会将5a转换为数字类型，然后和2相加，最后的结果就是 7 。

再比如 concat函数是连接两个字符串的，当此函数的参数出现非字符串类型时，就会将其转换为字符串，例如concat(88,'就是发')，最后的结果就是 88就是发。

MySQL 官方文档有以下几条关于隐式转换的规则：

1、两个参数至少有一个是 NULL 时，比较的结果也是 NULL，例外是使用 <=> 对两个 NULL 做比较时会返回 1，这两种情况都不需要做类型转换；

也就是两个参数中如果只有一个是NULL，则不管怎么比较结果都是 NULL，而两个 NULL 的值不管是判断大于、小于或等于，其结果都是1。

2、两个参数都是字符串，会按照字符串来比较，不做类型转换；

3、两个参数都是整数，按照整数来比较，不做类型转换；

4、十六进制的值和非数字做比较时，会被当做二进制字符串；

例如下面这条语句，查询 user 表中name字段是 0x61 的记录，0x是16进制写法，其对应的字符串是英文的 'a'，也就是它对应的 ASCII 码。

select * from user where name = 0x61;

所以，上面这条语句其实等同于下面这条

select * from user where name = 'a';

可以用 select 0x61;验证一下。

5、有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为 时间戳；

例如下面这两条SQL，都是将条件后面的值转换为时间戳再比较了，只不过

6、有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数（一般默认是 double），则会把 decimal 转换为浮点数进行比较；

在不同的数值类型之间，总是会向精度要求更高的那一个类型转换，但是有一点要注意，在MySQL 中浮点数的精度只有53 bit，超过53bit之后的话，如果后面1位是1就进位，如果是0就直接舍弃。所以超大浮点数在比较的时候其实只是取的近似值。

7、所有其他情况下，两个参数都会被转换为浮点数再进行比较；

如果不符合上面6点规则，则统一转成浮点数再进行运算

避免进行隐式转换

我们在平时的开发过程中，尽量要避免隐式转换，因为一旦发生隐式转换除了会降低性能外， 还有很大可能会出现不期望的结果，就像我最开始遇到的那个问题一样。

之所以性能会降低，还有一个原因就是让本来有的索引失效。

select * from `order` where order_code = 1;

order_code 是 varchar 类型，假设我已经在 order_code 上建立了索引，如果是用“=”做查询条件的话，应该直接命中索引才对，查询速度会很快。但是，当查询条件后面的值类型不是 varchar，而是数值类型的话，MySQL 首先要对 order_code 字段做类型转换，转换为数值类型，这时候，之前建的索引也就不会命中，只能走全表扫描，查询性能指数级下降，搞不好，数据库直接查崩了。

作者：古时的风筝
来源：juejin.cn/post/7161991470268825631

一、一台服务器最大能打开的文件数

1、限制参数

我们知道在Linux中一切皆文件，那么一台服务器最大能打开多少个文件呢？Linux上能打开的最大文件数量受三个参数影响，分别是：

• fs.file-max （系统级别参数）：该参数描述了整个系统可以打开的最大文件数量。但是root用户不会受该参数限制（比如：现在整个系统打开的文件描述符数量已达到fs.file-max ，此时root用户仍然可以使用ps、kill等命令或打开其他文件描述符）

• soft nofile（进程级别参数）：限制单个进程上可以打开的最大文件数。只能在Linux上配置一次，不能针对不同用户配置不同的值

• fs.nr_open（进程级别参数）：限制单个进程上可以打开的最大文件数。可以针对不同用户配置不同的值

这三个参数之间还有耦合关系，所以配置值的时候还需要注意以下三点：

1. 如果想加大soft nofile，那么hard nofile参数值也需要一起调整。如果因为hard nofile参数值设置的低，那么soft nofile参数的值设置的再高也没有用，实际生效的值会按照二者最低的来。

2. 如果增大了hard nofile，那么fs.nr_open也都需要跟着一起调整（fs.nr_open参数值一定要大于hard nofile参数值）。如果不小心把hard nofile的值设置的比fs.nr_open还大，那么后果比较严重。会导致该用户无法登录，如果设置的是*，那么所有用户都无法登录

3. 如果加大了fs.nr_open，但是是用的echo "xxx" > ../fs/nr_open命令来修改的fs.nr_open的值，那么刚改完可能不会有问题，但是只要机器一重启，那么之前通过echo命令设置的fs.nr_open值便会失效，用户还是无法登录。所以非常不建议使用echo的方式修改内核参数！！！

2、调整服务器能打开的最大文件数示例

假设想让进程可以打开100万个文件描述符，这里用修改conf文件的方式给出一个建议。如果日后工作里有类似的需求可以作为参考。

• vim /etc/sysctl.conf

fs.file-max=1100000 // 系统级别设置成110万，多留点buffer
fs.nr_open=1100000 // 进程级别也设置成110万，因为要保证比 hard nofile大

• 使上面的配置生效sysctl -p

• vim /etc/security/limits.conf

// 用户进程级别都设置成100完
soft nofile 1000000
hard nofile 1000000

二、一台服务器最大能支持多少连接

我们知道TCP连接，从根本上看其实就是client和server端在内存中维护的一组【socket内核对象】（这里也对应着TCP四元组：源IP、源端口、目标IP、目标端口），他们只要能够找到对方，那么就算是一条连接。那么一台服务器最大能建立多少条连接呢？

• 由于TCP连接本质上可以理解为是client-server端的一对socket内核对象，那么从理论上将应该是【2^32 (ip数) * 2^16 (端口数)】条连接（约等于两百多万亿）

• 但是实际上由于受其他软硬件的影响，我们一台服务器不可能能建立这么多连接（主要是受CPU和内存限制）。

如果只以ESTABLISH状态的连接来算（这些连接只是建立，但是不收发数据也不处理相关的业务逻辑）那么一台服务器最大能建立多少连接呢？以一台4GB内存的服务器为例！

• 这种情况下，那么能建立的连接数量主要取决于【内存的大小】（因为如果是）ESTABLISH状态的空闲连接，不会消耗CPU（虽然有TCP保活包传输，但这个影响非常小，可以忽略不计）

• 我们知道一条ESTABLISH状态的连接大约消耗【3.3KB内存】，那么通过计算得知一台4GB内存的服务器，【可以建立100w+的TCP连接】（当然这里只是计算所有的连接都只建立连接但不发送和处理数据的情况，如果真实场景中有数据往来和处理（数据接收和发送都需要申请内存，数据处理便需要CPU），那便会消耗更高的内存以及占用更多的CPU，并发不可能达到100w+）

上面讨论的都是进建立连接的理想情况，在现实中如果有频繁的数据收发和处理（比如：压缩、加密等），那么一台服务器能支撑1000连接都算好的了，所以一台服务器能支撑多少连接还要结合具体的场景去分析，不能光靠理论值去算。抛开业务逻辑单纯的谈并发没有太大的实际意义。

服务器的开销大头往往并不是连接本身，而是每条连接上的数据收发，以及请求业务逻辑处理！！！

三、一台客户端机器最多能发起多少条连接

我们知道客户端每和服务端建立一个连接便会消耗掉client端一个端口。一台机器的端口范围是【0 ~ 65535】，那么是不是说一台client机器最多和一台服务端机器建立65535个连接呢（这65535个端口里还有很多保留端口，可用端口可能只有64000个左右）？

由TCP连接的四元组特性可知，只要四元组里某一个元素不同，那么就认为这是不同的TCP连接。所以需要分情况讨论：

• 【情况一】、如果一台client仅有一个IP，server端也仅有一个IP并且仅启动一个程序，监听一个端口的情况下，client端和这台server端最大可建立的连接条数就是 65535 个。

  • 因为源IP固定，目标IP和端口固定，四元组中唯一可变化的就是【源端口】，【源端口】的可用范围又是【0 ~ 65535】，所以一台client机器最大能建立65535个连接

• 【情况二】、如果一台client有多个IP（假设客户端有 n 个IP），server端仅有一个IP并且仅启动一个程序，监听一个端口的情况下，一台client机器最大能建立的连接条数是：n * 65535个

  • 因为目标IP和端口固定，有 n 个源IP，四元组中可变化的就是【源端口】+ 【源IP】，【源端口】的可用范围又是【0 ~ 65535】，所以一个IP最大能建立65535个连接，那么n个IP最大就能建立n * 65535个连接了

  • 以现在的技术，给一个client分配多个IP是非常容易的事情，只需要去联系你们网管就可以做到。

• 【情况三】、如果一台client仅有一个IP，server端也仅有一个IP但是server端启动多个程序，每个程序监听一个端口的情况下（比如server端启动了m个程序，监听了m个不同端口），一台client机器最大能建立的连接数量为：65535 * m

  • 源IP固定，目标IP固定，目标端口数量为m个，可变化的是源端口，而源端口变化范围是【0 ~ 65535】，所以一台client机器最大能建立的TCP连接数量是 65535 * m个

• 其余情况类推，但是客户端的可用端口范围一般达不到65535个，受内核参数net.ipv4.ip_local_port_range限制，如果要修改client所能使用的端口范围，可以修改这个内核参数的值。

• 所以，不光是一台server端可以接收100w+个TCP连接，一台client照样能发出100w+个连接

四、其他

• 三次握手里socket的全连接队列长度由参数net.core.somaxconn来控制，默认大小是128，当两台机器离的非常近，但是建立连接的并发又非常高时，可能会导致半连接队列或全连接队列溢出，进而导致server端丢弃握手包。然后造成client超时重传握手包（至少1s以后才会重传），导致三次握手连接建立耗时过长。我们可以调整参数net.core.somaxconn来增加去按连接队列的长度，进而减小丢包的影响

• 有时候我们通过 ctrl + c方式来终止了某个进程，但是当重启该进程的时候发现报错端口被占用，这种问题是因为【操作系统还没有来得及回收该端口，等一会儿重启应用就好了】

• client程序在和server端建立连接时，如果client没有调用bind方法传入指定的端口，那么client在和server端建立连接的时候便会自己随机选择一个端口来建立连接。一旦我们client程序调用了bind方法传入了指定的端口，那么client将会使用我们bind里指定的端口来和server建立连接。所以不建议client调用bind方法，bind函数会改变内核选择端口的策略

  public static void main(String[] args) throws IOException {
      SocketChannel sc = SocketChannel.open();
      // 客户端还可以调用bind方法
      sc.bind(new InetSocketAddress("localhost", 9999));
      sc.connect(new InetSocketAddress("localhost", 8080));
      System.out.println("waiting..........");
  }

• 在Linux一切皆文件，当然也包括之前TCP连接中说的socket。进程打开一个socket的时候需要创建好几个内核对象，换一句直白的话说就是打开文件对象吃内存，所以Linux系统基于安全角度考虑（比如：有用户进程恶意的打开无数的文件描述符，那不得把系统搞奔溃了），在多个位置都限制了可打开的文件描述符的数量。

• 内核是通过【hash表】的方式来管理所有已经建立好连接的socket，以便于有请求到达时快速的通过【TCP四元组】查找到内核中对应的socket对象

  • 在epoll模型中，通过红黑树来管理epoll对象所管理的所有socket，用红黑树结构来平衡快速删除、插入、查找socket的效率

五、相关实际问题

在网络开发中，很多人对一个基础问题始终没有彻底搞明白，那就是一台机器最多能支撑多少条TCP连接。不过由于客户端和服务端对端口使用方式不同，这个问题拆开来理解要容易一些。

注意，这里说的是客户端和服务端都只是角色，并不是指某一台具体的机器。例如对于我们自己开发的应用程序来说，当他响应客户端请求的时候，他就是服务端。当他向MySQL请求数据的时候，他又变成了客户端。

1、"too many open files" 报错是怎么回事，该如何解决

你在线上可能遇到过too many open files这个错误，那么你理解这个报错发生的原理吗？如果让你修复这个错误，应该如何处理呢？

• 因为每打开一个文件（包括socket），都需要消耗一定的内存资源。为了避免个别进程不受控制的打开了过多文件而让整个服务器奔溃，Linux对打开的文件描述符数量有限制。如果你的进程触发到内核的限制，那么"too many open files" 报错就产生了

• 可以通过修改fs.file-max 、soft nofile、fs.nr_open这三个参数的值来修改进程能打开的最大文件描述符数量

  • 需要注意这三个参数之间的耦合关系！

2、一台服务端机器最大究竟能支持多少条连接

因为这里要考虑的是最大数，因此先不考虑连接上的数据收发和处理，仅考虑ESTABLISH状态的空连接。那么一台服务端机器上最大可以支持多少条TCP连接？这个连接数会受哪些因素的影响？

• 在不考虑连接上数据的收发和处理的情况下，仅考虑ESTABLISH状态下的空连接情况下，一台服务器上最大可支持的TCP连接数量基本上可以说是由内存大小来决定的。

• 四元组唯一确定一条连接，但服务端可以接收来自任意客户端的请求，所以根据这个理论计算出来的数字太大，没有实际意义。另外文件描述符限制其实也是内核为了防止某些应用程序不受限制的打开【文件句柄】而添加的限制。这个限制只要修改几个内核参数就可以加大。

• 一个socket大约消耗3kb左右的内存，这样真正制约服务端机器最大并发数的就是内存，拿一台4GB内存的服务器来说，可以支持的TCP连接数量大约是100w+

3、一条客户端机器最大究竟能支持多少条连接

和服务端不同的是，客户端每次建立一条连接都需要消耗一个端口。在TCP协议中，端口是一个2字节的整数，因此范围只能是0~65535。那么客户单最大只能支持65535条连接吗？有没有办法突破这个限制，有的话有哪些办法？

• 客户度每次建立一条连接都需要消耗一个端口。从数字上来看，似乎最多只能建立65535条连接。但实际上我们有两种办法破除65535这个限制

  • 方式一，为客户端配置多IP

  • 方式二，分别连接不同的服务端

• 所以一台client发起百万条连接是没有任何问题的

4、做一个长连接推送产品，支持1亿用户需要多少台机器

假设你是系统架构师，现在老板给你一个需求，让你做一个类似友盟upush这样的产品。要在服务端机器上保持一个和客户端的长连接，绝大部分情况下连接都是空闲的，每天也就顶多推送两三次左右。总用户规模预计是1亿。那么现在请你来评估一下需要多少台服务器可以支撑这1亿条长连接。

• 对于长连接推送模块这种服务来说，给客户端发送数据只是偶尔的，一般一天也就顶多一两次。绝大部分情况下TCP连接都是空闲的，CPU开销可以忽略

• 再基于内存来考虑，加色服务器内存是128G的，那么一台服务器可以考虑支持500w条并发。这样会消耗掉大约不到20GB内存用来保存这500w条连接对应的socket。还剩下100GB以上的内存来应对接收、发送缓冲区等其他的开销足够了。所以，一亿用户，仅仅需要20台服务器就差不多够用了！

参考：《深入理解Linux网络》

作者：文攀
来源：juejin.cn/post/7162824884597293086

自我介绍

我来自杭州的一所双非一本学校，是一名普通的本科生，专业【软件工程】。

初学编程

事实上，我从高中毕业起就开始思考未来的工作了，一开始网上都是 Python 相关的新闻，因此从高中毕业的暑假就开始学 Python，当时在新华书店，捧着一本入门书天天看；

但是看了并没有什么用，除了大一的时候吹牛皮，啥都没学到。

然后自 2020 年初(大一寒假) 疫情爆发，学校线上授课；课程中有【面向对象语言】的学习，自此开始正式的跟着视频学习 Java 了。

第一次实习

2021年暑假(大二暑假)，我的绩点排名在学校保研线边缘徘徊，但又不愿去刷那些水课的绩点，因此决定考研或者工作，期间比较迷茫。

当时在网上得到一位大数据方向前辈的指点，他说了一句话：“早，就是优势。”

因此，我决定先去实习，当时在杭州人工智能小镇找了家公司实习。

虽说是实习，但其实基本每天上班啥也不干，主管也没分配任务，就是一直在看书，期间看完了周志明老师的 JVM，以及几本讲并发编程的书。

第二次实习

大三上时，眼看着 Java 越来越卷，自己开始学习了大数据相关的组件，像 Hadoop、HBase、Flume 等等组件，一直学到了实时计算之前。

大三下时，我明白自己是一个心态非常不稳定的人，考研对我来说，最后几个月会非常的难熬，并且考研失败的风险也让我望而却步，因此下定决心本科就业！

寒假的时候跟着视频完成了【谷粒商城】那个项目，之后立刻着手准备找实习。

也就是在这第二段实习过程中(2022上半年)，我真正的学到了一些实际的开发技巧。

实习期间，看完了几本深入讲中间件 ZK、Redis、Spring源码 和 代码重构的书。

本次实习，让我受益良多，由衷感谢我的 mentor（导师）和主管！

秋招情况

我从 6 月底开始复习准备，因为准备得比较晚，所以基本没参加提前批。

正式批总共投递了近 150 家公司，笔试了 30 家，面试了 15 个公司，除了海康威视，其他基本都意向或排序了。

大致情况如下：

• offer：兴业数金

• 意向：猿辅导，Aloudata

• 排序 / 审批：华为，网易雷火，荣耀，招银网络，古茗奶茶，CVTE，以及一众独角兽公司

• 面试挂：海康威视

CVTE 提前批面试（已拒）

大应科技（OC）

e签宝 提前批（已拒）

荣耀 Honor（录用决策中）

猿辅导（OC）

趣链科技（流程中）

海康威视（已挂）

SMART（已拒）

寒王厂（泡池子）

网易雷火（排序中）

招银网络（流程中）

古茗奶茶（流程中）

复习方式

关于焦虑

我们先要肯定一点，在复习的时候，【焦虑】是一件必然的事情，我们要正视焦虑。

就拿我自己举例子吧，【双非本科】的学历会把我放到一个最最糟糕的位置。

自开始复习时，我内心就非常非常的焦虑，胸膛经常会像要爆炸一样的沉闷(真的)...

而我的缓解方式主要分为两种吧：

• 运动

• • 背一会八股或者刷一会题之后就去走走

  • 每天晚上去操场跑步

• 心理慰藉

• • 面试前，我会像《三傻大闹宝莱坞》里的阿米尔汗一样，拍着自己的胸口对自己说 “Aal izz well”

  • 给自己想好一个下下策，如果秋招真的找不到工作该怎么办？那至少还有春招，对比明年考研失利的同学，我至少积累了经验！

复习流程

我的整体复习流程分为三步：

• 处理基础知识

• 看八股

• 查漏补缺

阶段一：处理基础知识

对于基础知识部分，我自知《计网》和《操作系统》这两门课学的很差，所以一开始就复习这部分知识。

当时先把两门课的教材翻了一遍，然后做了一些摘抄，但说实话基本没用。

这部分知识，我在面试过程中，大概有 50% 的几率会被问到操作系统，但从来没被问到过计网(幸运)。

之后复习《设计模式》，先跟着一个 csdn 上的博客边看别写，之后找了一个很老的(2003年)博客总结，反复背诵，基本能手写大部分的模式实现了。

这部分知识，我在面试过程中，要求写过 单例 、三大工厂 和 发布订阅 的实现，问过项目中和 Spring 以及其它中间件中用到的设计模式。

阶段二：看八股

全面进军 Java 八股文。

我先看了自己在实习前准备的那些文档，之后网上找了 JavaGuide、JavaKeeper 这两份文档作为补充。

因为自己之前有过两段的实习经验，因此背过很多次八股。

但考虑到本次秋招可能会把战线拉得比较长，因此就自己总结了一份脑图。

阶段三：查漏补缺

经过几轮面试，逐渐察觉到了自己的一些不足，之后针对性的去完善了一下。

这里随便列举几个点，供其它同学参考：

• 为什么说进程切换开销比线程大？

• NIO到底有没有阻塞，NIO到底能不能提高 IO 效率？

• Redis分布式锁的限制，RedLock的实现？

• ZK 明明有了有序的指令队列，为什么还要用 zxid来辅助排序？

• basic paxos 和 multi paxos 的使用？

• 为什么拜占庭将军无解？

• 还有一些业务场景的选择问题。。。

总结

我一直提醒自己：你是一个双非本科生，这个秋招你如果再不拼命，你就要完蛋了。

我想，我是幸运的：

• 我很幸运 在实习的时候，有一个好的 mentor，带我开发了字节码相关的组件，让我的简历不容易挂；

• 我很幸运 在复习的时候，有几位好的朋友，分享经验，加油鼓励，让我没有被焦虑击倒；

• 我很幸运 在面试的时候，有无私的舍友们，能在我需要笔试面试时，把宿舍让给我，让我没有后顾之忧；

当然，也会有遗憾。每个人心中都有着大厂梦，而今年进大厂确实很难：

• 我从大一开始就非常渴望进入阿里巴巴，实习的时候五面阿里不得，秋招全部简历挂；

• 百度+度小满，投了 4 个岗位，全部简历挂；

• 字节，一开始担心算法没敢投，之后担心基础知识也没敢投，也很遗憾了；

人生，有所得就有所失，有所失就有所得。

最后，想给其他明后年参加秋招的同学一些提醒：

• 一定要早做准备，早点实习，早点刷算法题，早就是优势；

• 人生无常，意外太多，绝对不要 all in 一家公司；

• 鞋合不合适只有脚知道，自己总结的八股会更适合自己；

• 多刷 力扣 Hot 100，或者 Codetop 热门题，反复刷；

• 选择大于努力；

在寒气逼人的 2022，我们需要抱团取暖...

作者：OliQ
链接：http://www.cnblogs.com/yuanchuziwen/p/16770895.html

我是一名程序员，我的主要编程语言是 Java，我更是一名 Web 开发人员，所以我必须要了解 HTTP，所以本篇文章就来带你从 HTTP 入门到进阶，看完让你有一种恍然大悟、醍醐灌顶的感觉。

最初在有网络之前，我们的电脑都是单机的，单机系统是孤立的，我还记得 05 年前那会儿家里有个电脑，想打电脑游戏还得两个人在一个电脑上玩儿，及其不方便。我就想为什么家里人不让上网，我的同学 xxx 家里有网，每次一提这个就落一通批评：xxx上xxx什xxxx么xxxx网xxxx看xxxx你xxxx考xxxx的xxxx那xxxx点xxxx分。虽然我家里没有上网，但是此时互联网已经在高速发展了，HTTP 就是高速发展的一个产物。

认识 HTTP

首先你听的最多的应该就是 HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)，这你一定能说出来，但是这样还不够，假如你是大厂面试官，这不可能是他想要的最终结果，我们在面试的时候往往把自己知道的尽可能多的说出来，才有和面试官谈价钱的资本。那么什么是超文本传输协议？

超文本传输协议可以进行文字分割：超文本（Hypertext）、传输（Transfer）、协议（Protocol），它们之间的关系如下

按照范围的大小 协议 > 传输 > 超文本。下面就分别对这三个名次做一个解释。

什么是超文本

在互联网早期的时候，我们输入的信息只能保存在本地，无法和其他电脑进行交互。我们保存的信息通常都以文本即简单字符的形式存在，文本是一种能够被计算机解析的有意义的二进制数据包。而随着互联网的高速发展，两台电脑之间能够进行数据的传输后，人们不满足只能在两台电脑之间传输文字，还想要传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转，那么文本的语义就被扩大了，这种语义扩大后的文本就被称为超文本(Hypertext)。

什么是传输

那么我们上面说到，两台计算机之间会形成互联关系进行通信，我们存储的超文本会被解析成为二进制数据包，由传输载体（例如同轴电缆，电话线，光缆）负责把二进制数据包由计算机终端传输到另一个终端的过程（对终端的详细解释可以参考 你说你懂互联网，那这些你知道么？这篇文章）称为传输(transfer)。

通常我们把传输数据包的一方称为请求方，把接到二进制数据包的一方称为应答方。请求方和应答方可以进行互换，请求方也可以作为应答方接受数据，应答方也可以作为请求方请求数据，它们之间的关系如下

如图所示，A 和 B 是两个不同的端系统，它们之间可以作为信息交换的载体存在，刚开始的时候是 A 作为请求方请求与 B 交换信息，B 作为响应的一方提供信息；随着时间的推移，B 也可以作为请求方请求 A 交换信息，那么 A 也可以作为响应方响应 B 请求的信息。

什么是协议

协议这个名词不仅局限于互联网范畴，也体现在日常生活中，比如情侣双方约定好在哪个地点吃饭，这个约定也是一种协议，比如你应聘成功了，企业会和你签订劳动合同，这种双方的雇佣关系也是一种 协议。注意自己一个人对自己的约定不能成为协议，协议的前提条件必须是多人约定。

那么网络协议是什么呢？

网络协议就是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为网络协议。

没有网络协议的互联网是混乱的，就和人类社会一样，人不能想怎么样就怎么样，你的行为约束是受到法律的约束的；那么互联网中的端系统也不能自己想发什么发什么，也是需要受到通信协议约束的。

那么我们就可以总结一下，什么是 HTTP？可以用下面这个经典的总结回答一下： HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

与 HTTP 有关的组件

随着网络世界演进，HTTP 协议已经几乎成为不可替代的一种协议，在了解了 HTTP 的基本组成后，下面再来带你进一步认识一下 HTTP 协议。

网络模型

网络是一个复杂的系统，不仅包括大量的应用程序、端系统、通信链路、分组交换机等，还有各种各样的协议组成，那么现在我们就来聊一下网络中的协议层次。

为了给网络协议的设计提供一个结构，网络设计者以分层(layer)的方式组织协议，每个协议属于层次模型之一。每一层都是向它的上一层提供服务(service)，即所谓的服务模型(service model)。每个分层中所有的协议称为 协议栈(protocol stack)。因特网的协议栈由五个部分组成：物理层、链路层、网络层、运输层和应用层。我们采用自上而下的方法研究其原理，也就是应用层 -> 物理层的方式。

应用层

应用层是网络应用程序和网络协议存放的分层，因特网的应用层包括许多协议，例如我们学 web 离不开的 HTTP，电子邮件传送协议 SMTP、端系统文件上传协议 FTP、还有为我们进行域名解析的 DNS 协议。应用层协议分布在多个端系统上，一个端系统应用程序与另外一个端系统应用程序交换信息分组，我们把位于应用层的信息分组称为 报文(message)。

运输层

因特网的运输层在应用程序断点之间传送应用程序报文，在这一层主要有两种传输协议 TCP和 UDP，利用这两者中的任何一个都能够传输报文，不过这两种协议有巨大的不同。

TCP 向它的应用程序提供了面向连接的服务，它能够控制并确认报文是否到达，并提供了拥塞机制来控制网络传输，因此当网络拥塞时，会抑制其传输速率。

UDP 协议向它的应用程序提供了无连接服务。它不具备可靠性的特征，没有流量控制，也没有拥塞控制。我们把运输层的分组称为 报文段(segment)

网络层

因特网的网络层负责将称为 数据报(datagram) 的网络分层从一台主机移动到另一台主机。网络层一个非常重要的协议是 IP 协议，所有具有网络层的因特网组件都必须运行 IP 协议，IP 协议是一种网际协议，除了 IP 协议外，网络层还包括一些其他网际协议和路由选择协议，一般把网络层就称为 IP 层，由此可知 IP 协议的重要性。

链路层

现在我们有应用程序通信的协议，有了给应用程序提供运输的协议，还有了用于约定发送位置的 IP 协议，那么如何才能真正的发送数据呢？为了将分组从一个节点（主机或路由器）运输到另一个节点，网络层必须依靠链路层提供服务。链路层的例子包括以太网、WiFi 和电缆接入的 DOCSIS 协议，因为数据从源目的地传送通常需要经过几条链路，一个数据包可能被沿途不同的链路层协议处理，我们把链路层的分组称为 帧(frame)

物理层

虽然链路层的作用是将帧从一个端系统运输到另一个端系统，而物理层的作用是将帧中的一个个 比特 从一个节点运输到另一个节点，物理层的协议仍然使用链路层协议，这些协议与实际的物理传输介质有关，例如，以太网有很多物理层协议：关于双绞铜线、关于同轴电缆、关于光纤等等。

五层网络协议的示意图如下

OSI 模型

我们上面讨论的计算网络协议模型不是唯一的 协议栈，ISO（国际标准化组织）提出来计算机网络应该按照7层来组织，那么7层网络协议栈与5层的区别在哪里？

从图中可以一眼看出，OSI 要比上面的网络模型多了 表示层 和 会话层，其他层基本一致。表示层主要包括数据压缩和数据加密以及数据描述，数据描述使得应用程序不必担心计算机内部存储格式的问题，而会话层提供了数据交换的定界和同步功能，包括建立检查点和恢复方案。

浏览器

就如同各大邮箱使用电子邮件传送协议 SMTP 一样，浏览器是使用 HTTP 协议的主要载体，说到浏览器，你能想起来几种？是的，随着网景大战结束后，浏览器迅速发展，至今已经出现过的浏览器主要有

浏览器正式的名字叫做 Web Broser，顾名思义，就是检索、查看互联网上网页资源的应用程序，名字里的 Web，实际上指的就是 World Wide Web，也就是万维网。

我们在地址栏输入URL（即网址），浏览器会向DNS（域名服务器，后面会说）提供网址，由它来完成 URL 到 IP 地址的映射。然后将请求你的请求提交给具体的服务器，在由服务器返回我们要的结果（以HTML编码格式返回给浏览器），浏览器执行HTML编码，将结果显示在浏览器的正文。这就是一个浏览器发起请求和接受响应的过程。

Web 服务器

Web 服务器的正式名称叫做 Web Server，Web 服务器一般指的是网站服务器，上面说到浏览器是 HTTP 请求的发起方，那么 Web 服务器就是 HTTP 请求的应答方，Web 服务器可以向浏览器等 Web 客户端提供文档，也可以放置网站文件，让全世界浏览；可以放置数据文件，让全世界下载。目前最主流的三个Web服务器是Apache、 Nginx 、IIS。

CDN

CDN的全称是Content Delivery Network，即内容分发网络，它应用了 HTTP 协议里的缓存和代理技术，代替源站响应客户端的请求。CDN 是构建在现有网络基础之上的网络，它依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

打比方说你要去亚马逊上买书，之前你只能通过购物网站购买后从美国发货过海关等重重关卡送到你的家里，现在在中国建立一个亚马逊分基地，你就不用通过美国进行邮寄，从中国就能把书尽快给你送到。

WAF

WAF 是一种 Web 应用程序防护系统（Web Application Firewall，简称 WAF），它是一种通过执行一系列针对HTTP / HTTPS的安全策略来专门为Web应用提供保护的一款产品，它是应用层面的防火墙，专门检测 HTTP 流量，是防护 Web 应用的安全技术。

WAF 通常位于 Web 服务器之前，可以阻止如 SQL 注入、跨站脚本等攻击，目前应用较多的一个开源项目是 ModSecurity，它能够完全集成进 Apache 或 Nginx。

WebService

WebService 是一种 Web 应用程序，WebService是一种跨编程语言和跨操作系统平台的远程调用技术。

Web Service 是一种由 W3C 定义的应用服务开发规范，使用 client-server 主从架构，通常使用 WSDL 定义服务接口，使用 HTTP 协议传输 XML 或 SOAP 消息，它是一个基于 Web（HTTP）的服务架构技术，既可以运行在内网，也可以在适当保护后运行在外网。

HTML

HTML 称为超文本标记语言，是一种标识性的语言。它包括一系列标签．通过这些标签可以将网络上的文档格式统一，使分散的 Internet 资源连接为一个逻辑整体。HTML 文本是由 HTML 命令组成的描述性文本，HTML 命令可以说明文字，图形、动画、声音、表格、链接等。

Web 页面构成

Web 页面（Web page）也叫做文档，是由一个个对象组成的。一个对象(Objecy) 只是一个文件，比如一个 HTML 文件、一个 JPEG 图形、一个 Java 小程序或一个视频片段，它们在网络中可以通过 URL 地址寻址。多数的 Web 页面含有一个 HTML 基本文件 以及几个引用对象。

举个例子，如果一个 Web 页面包含 HTML 文件和5个 JPEG 图形，那么这个 Web 页面就有6个对象：一个 HTML 文件和5个 JPEG 图形。HTML 基本文件通过 URL 地址引用页面中的其他对象。

与 HTTP 有关的协议

在互联网中，任何协议都不会单独的完成信息交换，HTTP 也一样。虽然 HTTP 属于应用层的协议，但是它仍然需要其他层次协议的配合完成信息的交换，那么在完成一次 HTTP 请求和响应的过程中，需要哪些协议的配合呢？一起来看一下

TCP/IP

TCP/IP 协议你一定听过，TCP/IP 我们一般称之为协议簇，什么意思呢？就是 TCP/IP 协议簇中不仅仅只有 TCP 协议和 IP 协议，它是一系列网络通信协议的统称。而其中最核心的两个协议就是 TCP / IP 协议，其他的还有 UDP、ICMP、ARP 等等，共同构成了一个复杂但有层次的协议栈。

TCP 协议的全称是 Transmission Control Protocol 的缩写，意思是传输控制协议，HTTP 使用 TCP 作为通信协议，这是因为 TCP 是一种可靠的协议，而可靠能保证数据不丢失。

IP 协议的全称是 Internet Protocol 的缩写，它主要解决的是通信双方寻址的问题。IP 协议使用 IP 地址 来标识互联网上的每一台计算机，可以把 IP 地址想象成为你手机的电话号码，你要与他人通话必须先要知道他人的手机号码，计算机网络中信息交换必须先要知道对方的 IP 地址。（关于 TCP 和 IP 更多的讨论我们会在后面详解）

DNS

你有没有想过为什么你可以通过键入 http://www.google.com 就能够获取你想要的网站？我们上面说到，计算机网络中的每个端系统都有一个 IP 地址存在，而把 IP 地址转换为便于人类记忆的协议就是 DNS 协议。

DNS 的全称是域名系统（Domain Name System，缩写：DNS），它作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

URI / URL

我们上面提到，你可以通过输入 http://www.google.com 地址来访问谷歌的官网，那么这个地址有什么规定吗？我怎么输都可以？AAA.BBB.CCC 是不是也行？当然不是的，你输入的地址格式必须要满足 URI 的规范。

URI的全称是（Uniform Resource Identifier），中文名称是统一资源标识符，使用它就能够唯一地标记互联网上资源。

URL的全称是（Uniform Resource Locator），中文名称是统一资源定位符，也就是我们俗称的网址，它实际上是 URI 的一个子集。

URI 不仅包括 URL，还包括 URN（统一资源名称），它们之间的关系如下

HTTPS

HTTP 一般是明文传输，很容易被攻击者窃取重要信息，鉴于此，HTTPS 应运而生。HTTPS 的全称为 （Hyper Text Transfer Protocol over SecureSocket Layer），全称有点长，HTTPS 和 HTTP 有很大的不同在于 HTTPS 是以安全为目标的 HTTP 通道，在 HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在 HTTP 的基础上增加了 SSL 层，也就是说 HTTPS = HTTP + SSL。（这块我们后面也会详谈 HTTPS）

HTTP 请求响应过程

你是不是很好奇，当你在浏览器中输入网址后，到底发生了什么事情？你想要的内容是如何展现出来的？让我们通过一个例子来探讨一下，我们假设访问的 URL 地址为 http://www.someSchool.edu/someDepartment/home.index，当我们输入网址并点击回车时，浏览器内部会进行如下操作

• DNS服务器会首先进行域名的映射，找到访问http://www.someSchool.edu所在的地址，然后HTTP 客户端进程在 80 端口发起一个到服务器 http://www.someSchool.edu 的 TCP 连接（80 端口是 HTTP 的默认端口）。在客户和服务器进程中都会有一个套接字与其相连。

• HTTP 客户端通过它的套接字向服务器发送一个 HTTP 请求报文。该报文中包含了路径 someDepartment/home.index 的资源，我们后面会详细讨论 HTTP 请求报文。

• HTTP 服务器通过它的套接字接受该报文，进行请求的解析工作，并从其存储器(RAM 或磁盘)中检索出对象 http://www.someSchool.edu/someDepartment/home.index，然后把检索出来的对象进行封装，封装到 HTTP 响应报文中，并通过套接字向客户进行发送。

• HTTP 服务器随即通知 TCP 断开 TCP 连接，实际上是需要等到客户接受完响应报文后才会断开 TCP 连接。

• HTTP 客户端接受完响应报文后，TCP 连接会关闭。HTTP 客户端从响应中提取出报文中是一个 HTML 响应文件，并检查该 HTML 文件，然后循环检查报文中其他内部对象。

• 检查完成后，HTTP 客户端会把对应的资源通过显示器呈现给用户。

至此，键入网址再按下回车的全过程就结束了。上述过程描述的是一种简单的请求-响应全过程，真实的请求-响应情况可能要比上面描述的过程复杂很多。

HTTP 请求特征

从上面整个过程中我们可以总结出 HTTP 进行分组传输是具有以下特征

• 支持客户-服务器模式

• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。

• 灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

• 无状态：HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

详解 HTTP 报文

我们上面描述了一下 HTTP 的请求响应过程，流程比较简单，但是凡事就怕认真，你这一认真，就能拓展出很多东西，比如 HTTP 报文是什么样的，它的组成格式是什么？ 下面就来探讨一下

HTTP 协议主要由三大部分组成：

• 起始行（start line）：描述请求或响应的基本信息；

• 头部字段（header）：使用 key-value 形式更详细地说明报文；

• 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

其中起始行和头部字段并成为 请求头 或者 响应头，统称为 Header；消息正文也叫做实体，称为 body。HTTP 协议规定每次发送的报文必须要有 Header，但是可以没有 body，也就是说头信息是必须的，实体信息可以没有。而且在 header 和 body 之间必须要有一个空行（CRLF），如果用一幅图来表示一下的话，我觉得应该是下面这样

我们使用上面的那个例子来看一下 http 的请求报文

如图，这是 http://www.someSchool.edu/someDepartment/home.index 请求的请求头，通过观察这个 HTTP 报文我们就能够学到很多东西，首先，我们看到报文是用普通 ASCII 文本书写的，这样保证人能够可以看懂。然后，我们可以看到每一行和下一行之间都会有换行，而且最后一行（请求头部后）再加上一个回车换行符。

每个报文的起始行都是由三个字段组成：方法、URL 字段和 HTTP 版本字段。

HTTP 请求方法

HTTP 请求方法一般分为 8 种，它们分别是

• GET 获取资源，GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；

• POST 传输实体，虽然 GET 方法也可以传输主体信息，但是便于区分，我们一般不用 GET 传输实体信息，反而使用 POST 传输实体信息，

• PUT 传输文件，PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。

  但是，鉴于 HTTP 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 W eb 网站不使用该方法。若配合 W eb 应用程序的验证机制，或架构设计采用REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。

• HEAD 获得响应首部，HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。

• DELETE 删除文件，DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。

• OPTIONS 询问支持的方法，OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。

• TRACE 追踪路径，TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。

• CONNECT 要求用隧道协议连接代理，CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。

我们一般最常用的方法也就是 GET 方法和 POST 方法，其他方法暂时了解即可。下面是 HTTP1.0 和 HTTP1.1 支持的方法清单

HTTP 请求 URL

HTTP 协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。URL 带有请求对象的标识符。在上面的例子中，浏览器正在请求对象 /somedir/page.html 的资源。

我们再通过一个完整的域名解析一下 URL

比如 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 这个 URL 比较繁琐了吧，你把这个 URL 搞懂了其他的 URL 也就不成问题了。

首先出场的是 http

http://告诉浏览器使用何种协议。对于大部分 Web 资源，通常使用 HTTP 协议或其安全版本，HTTPS 协议。另外，浏览器也知道如何处理其他协议。例如， mailto: 协议指示浏览器打开邮件客户端；ftp:协议指示浏览器处理文件传输。

第二个出场的是 主机

http://www.example.com 既是一个域名，也代表管理该域名的机构。它指示了需要向网络上的哪一台主机发起请求。当然，也可以直接向主机的 IP address 地址发起请求。但直接使用 IP 地址的场景并不常见。

第三个出场的是 端口

我们前面说到，两个主机之间要发起 TCP 连接需要两个条件，主机 + 端口。它表示用于访问 Web 服务器上资源的入口。如果访问的该 Web 服务器使用HTTP协议的标准端口（HTTP为80，HTTPS为443）授予对其资源的访问权限，则通常省略此部分。否则端口就是 URI 必须的部分。

上面是请求 URL 所必须包含的部分，下面就是 URL 具体请求资源路径

第四个出场的是 路径

/path/to/myfile.html 是 Web 服务器上资源的路径。以端口后面的第一个 / 开始，到 ? 号之前结束，中间的 每一个/ 都代表了层级（上下级）关系。这个 URL 的请求资源是一个 html 页面。

紧跟着路径后面的是 查询参数

?key1=value1&key2=value2 是提供给 Web 服务器的额外参数。如果是 GET 请求，一般带有请求 URL 参数，如果是 POST 请求，则不会在路径后面直接加参数。这些参数是用 & 符号分隔的键/值对列表。key1 = value1 是第一对，key2 = value2 是第二对参数

紧跟着参数的是锚点

#SomewhereInTheDocument 是资源本身的某一部分的一个锚点。锚点代表资源内的一种“书签”，它给予浏览器显示位于该“加书签”点的内容的指示。 例如，在HTML文档上，浏览器将滚动到定义锚点的那个点上；在视频或音频文档上，浏览器将转到锚点代表的那个时间。值得注意的是 # 号后面的部分，也称为片段标识符，永远不会与请求一起发送到服务器。

HTTP 版本

表示报文使用的 HTTP 协议版本。

请求头部

这部分内容只是大致介绍一下，内容较多，后面会再以一篇文章详述

在表述完了起始行之后我们再来看一下请求头部，现在我们向上找，找到http://www.someSchool.edu/someDepartment/home.index，来看一下它的请求头部

Host: http://www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
复制代码

这个请求头信息比较少，首先 Host 表示的是对象所在的主机。你也许认为这个 Host 是不需要的，因为 URL 不是已经指明了请求对象的路径了吗？这个首部行提供的信息是 Web 代理高速缓存所需要的。Connection: close 表示的是浏览器需要告诉服务器使用的是非持久连接。它要求服务器在发送完响应的对象后就关闭连接。User-agent: 这是请求头用来告诉 Web 服务器，浏览器使用的类型是 Mozilla/5.0，即 Firefox 浏览器。Accept-language 告诉 Web 服务器，浏览器想要得到对象的法语版本，前提是服务器需要支持法语类型，否则将会发送服务器的默认版本。下面我们针对主要的实体字段进行介绍（具体的可以参考 developer.mozilla.org/zh-CN/docs/… MDN 官网学习）

HTTP 的请求标头分为四种： 通用标头、请求标头、响应标头 和 实体标头，依次来进行详解。

通用标头

通用标头主要有三个，分别是 Date、Cache-Control 和 Connection

Date

Date 是一个通用标头，它可以出现在请求标头和响应标头中，它的基本表示如下

Date: Wed, 21 Oct 2015 07:28:00 GMT 
复制代码

表示的是格林威治标准时间，这个时间要比北京时间慢八个小时

Cache-Control

Cache-Control 是一个通用标头，他可以出现在请求标头和响应标头中，Cache-Control 的种类比较多，虽然说这是一个通用标头，但是又一些特性是请求标头具有的，有一些是响应标头才有的。主要大类有 可缓存性、阈值性、 重新验证并重新加载 和其他特性

可缓存性是唯一响应标头才具有的特性，我们会在响应标头中详述。

阈值性，这个我翻译可能不准确，它的原英文是 Expiration，我是根据它的值来翻译的，你看到这些值可能会觉得我翻译的有点道理

• max-age: 资源被认为仍然有效的最长时间，与 Expires 不同，这个请求是相对于 request标头的时间，而 Expires 是相对于响应标头。（请求标头）

• s-maxage: 重写了 max-age 和 Expires 请求头，仅仅适用于共享缓存，被私有缓存所忽略（这块不理解，看完响应头的 Cache-Control 再进行理解）（请求标头）

• max-stale：表示客户端将接受的最大响应时间，以秒为单位。（响应标头）

• min-fresh: 表示客户端希望响应在指定的最小时间内有效。（响应标头）

Connection

Connection 决定当前事务（一次三次握手和四次挥手）完成后，是否会关闭网络连接。Connection 有两种，一种是持久性连接，即一次事务完成后不关闭网络连接

Connection: keep-alive
复制代码

另一种是非持久性连接，即一次事务完成后关闭网络连接

Connection: close
复制代码

HTTP1.1 其他通用标头如下

实体标头

实体标头是描述消息正文内容的 HTTP 标头。实体标头用于 HTTP 请求和响应中。头部Content-Length、 Content-Language、 Content-Encoding 是实体头。

• Content-Length 实体报头指示实体主体的大小，以字节为单位，发送到接收方。

• Content-Language 实体报头描述了客户端或者服务端能够接受的语言，例如

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
复制代码

• Content-Encoding 这又是一个比较麻烦的属性，这个实体报头用来压缩媒体类型。Content-Encoding 指示对实体应用了何种编码。

  常见的内容编码有这几种： gzip、compress、deflate、identity ，这个属性可以应用在请求报文和响应报文中

Accept-Encoding: gzip, deflate //请求头
Content-Encoding: gzip  //响应头
复制代码

下面是一些实体标头字段