模耦合有什么用

楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 ###### 另外，补充说一下，楼主的函数式风格，和我的函数式风格理解相差颇大。我的理解如下，所谓函数式风格，是将一批数据的若干处理，分解为正交串接的多个子步骤，每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理，可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作，可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块，实现数据处理。当然差异的模块调用顺序和不同处理模块的组合，可以有不同的效果。 但无论如何，都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合，牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错，我看现在的C模块基本就是你所说的面向对象风格，其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的，说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好；同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”，并且支持灵活的可变个数参数等特性，都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起，但通过规范地命令提供隐喻，比如代码中，所有操作Employee对象的函数都以employee_前缀开头。而且，这些接口之间也有层级关系，符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里，然后头文件里只放置公开的接口信息，这样就变得简洁多了。 最高层：使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C，对象Employee的最基础的操作，包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障：我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口，无需关心FILE结构体里有些什么内容，表示什么意思，以及各个接口是怎么实现的。 #3的确是一个问题，而且我在文章里也可以没有提及，因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言，例如Java的java.util.*容器、C++的STL容器，都符合你的设计，将容器这个单一职责抽象出来。当然，我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外，补充说一下，楼主的函数式风格，和我的函数式风格理解相差颇大。我的理解如下，所谓函数式风格，是将一批数据的若干处理，分解为正交串接的多个子步骤，每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理，可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作，可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块，实现数据处理。当然差异的模块调用顺序和不同处理模块的组合，可以有不同的效果。 但无论如何，都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”，让每个函数、每个模块责任都尽可能地单一，然后通过类似搭积木一样的灵活组合，完成不同的任务。就像UNIX下的命令，每个单独命令都只完成一件事情，通过管道等把这些功能单一的命令组织在一起，协作完成一个复杂的任务！ 我个人认为这是一种设计思想，和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码，并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错，我看现在的C模块基本就是你所说的面向对象风格，其实就是用数据结构组织起来。 嗯，将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的，很多C模块往往还会更进一步，把容器和对象也分离开来。这样容器能容纳各种不同的对象，对象则只保留数据本身，不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的，说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好；同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”，并且支持灵活的可变个数参数等特性，都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起，但通过规范地命令提供隐喻，比如代码中，所有操作Employee对象的函数都以employee_前缀开头。而且，这些接口之间也有层级关系，符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里，然后头文件里只放置公开的接口信息，这样就变得简洁多了。 最高层：使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C，对象Employee的最基础的操作，包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障：我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口，无需关心FILE结构体里有些什么内容，表示什么意思，以及各个接口是怎么实现的。 #3的确是一个问题，而且我在文章里也可以没有提及，因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言，例如Java的java.util.*容器、C++的STL容器，都符合你的设计，将容器这个单一职责抽象出来。当然，我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面（会产生数据加工的），这种方法最终组合出来的系统，会比面向对象出来的类套类更复杂。说实话，还不如用面相对象实现。 面向对象，是将数据和操作，进行耦合，并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写，说实话还不如用c++的类进行实现，因为类描述这些逻辑更为清晰，而且语法和编译器可以帮你做大量的事情。 而相反面向数据，是一批数据（不是一个具体数据单元），存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点，这两个分析清楚，那么并发计算，和分步骤计算就得以实现。并发计算不谈，分步骤计算的思想就是原子操作，或者微指令集管道设计思想。这样设计，可以令复杂的数据处理，根据流程细分到步骤，每个步骤细分到子步骤单元，而每个子步骤单元只负责处理，不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的，数据和操作松耦合。数据的特殊性导致的操作，是通过各种操作模块组合调用实现（这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的）。 这样做的好处是，模块的设计，可以独立进行，让外部数据格式依赖自身，而不是操作对应数据格式（面向对象是后者，成员变量类型决定了成员函数的实际操作），模块复用率高，同时是整批数据处理，只要数据流程（调用不同模块的系统设计良好），运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据，分层几组让同一个操作的多个进程处理。流水线技术的使用，一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路，这块需要考虑到不同计算单元之间数据流动的费用， hadoop整天扯分布计算，根本不考虑数据整体计算周期内的相关性的问题，基本上都是推给用户自己处理，而用户应该无法控制具体计算硬件设备，最后能有好效果就扯淡了。

楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 ###### 另外，补充说一下，楼主的函数式风格，和我的函数式风格理解相差颇大。我的理解如下，所谓函数式风格，是将一批数据的若干处理，分解为正交串接的多个子步骤，每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理，可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作，可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块，实现数据处理。当然差异的模块调用顺序和不同处理模块的组合，可以有不同的效果。 但无论如何，都是函数与数据松耦合的设计。这个和面向对象是反过来的。 ######相互嵌套耦合，牵一发动全身######楼主的代码有很浓重的其他语言的味道######楼主文章不错，我看现在的C模块基本就是你所说的面向对象风格，其实就是用数据结构组织起来。###### 引用来自“中山野鬼”的答案 楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的，说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好；同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”，并且支持灵活的可变个数参数等特性，都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起，但通过规范地命令提供隐喻，比如代码中，所有操作Employee对象的函数都以employee_前缀开头。而且，这些接口之间也有层级关系，符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里，然后头文件里只放置公开的接口信息，这样就变得简洁多了。 最高层：使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C，对象Employee的最基础的操作，包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障：我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口，无需关心FILE结构体里有些什么内容，表示什么意思，以及各个接口是怎么实现的。 #3的确是一个问题，而且我在文章里也可以没有提及，因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言，例如Java的java.util.*容器、C++的STL容器，都符合你的设计，将容器这个单一职责抽象出来。当然，我自己实际的工作也是这样做的。 ###### 引用来自“中山野鬼”的答案 另外，补充说一下，楼主的函数式风格，和我的函数式风格理解相差颇大。我的理解如下，所谓函数式风格，是将一批数据的若干处理，分解为正交串接的多个子步骤，每个步骤都是对整体数据的某个操作的实现。楼主的方案实质是对一个处理，可以挂接不同的操作方法。 我的理解函数式的风格在于每个独立模块处理极少的有逻辑关联的操作，可以看作针对一个数据池的原子操作。依次将数据池的数据灌入不同的独立模块，实现数据处理。当然差异的模块调用顺序和不同处理模块的组合，可以有不同的效果。 但无论如何，都是函数与数据松耦合的设计。这个和面向对象是反过来的。 我认为你说的是“责任单一原则”，让每个函数、每个模块责任都尽可能地单一，然后通过类似搭积木一样的灵活组合，完成不同的任务。就像UNIX下的命令，每个单独命令都只完成一件事情，通过管道等把这些功能单一的命令组织在一起，协作完成一个复杂的任务！ 我个人认为这是一种设计思想，和源自Lambda演算的函数式风格并没有太大关系。 ###### 引用来自“杨同学”的答案 楼主的代码有很浓重的其他语言的味道 因为其他语言也能写“面向对象风格”和“函数式风格”的代码，并且看起来比C更“专业”。 ###### 引用来自“优游幻世”的答案 楼主文章不错，我看现在的C模块基本就是你所说的面向对象风格，其实就是用数据结构组织起来。 嗯，将数据和操作数据的方法集中在一起会让代码更容易维护。 就像我在六楼回复里提到的，很多C模块往往还会更进一步，把容器和对象也分离开来。这样容器能容纳各种不同的对象，对象则只保留数据本身，不关心和其他对象是以什么形式组织在一起的。 ###### 引用来自“redraiment”的答案 引用来自“中山野鬼”的答案 楼主这是节点遍历时，通过函数指针动态加载节点处理函数的设计方法。这个几年前写过，后来不这么写了。主要有以下几个问题。 1、每个节点被访问时，操作可能不一样，通用的函数指针的入口参数，要么可变参，要么多套，入口指针，都是很繁琐的事情，把代码逻辑结构搞的会更复杂。 2、操作函数和操作对象没有绑定，这个在规模开发时，很容易引起混乱。这样设计的代码，我自己到后面都觉得混乱，更别说基于我的架子让别人开发，楼主你的例子不够复杂可能感觉不到。 3、上面两个问题，也导致，代码复用率不高。 现在我的设计思想，如果是基础的数据结构，如同你这个例子中就是个线形表，我都全部独立成模版，在头文件中。 特定数据的处理不会和处理方法绑定，而是调用不同通用模块来处理，这样是尽可能的让数据和处理松耦合。而关联数据再怎么关联，处理时，也是一类整体处理的，同时一批数据再怎么复合，总可以拆成不同大部分串联处理（例如，读取、处理、写出，通过增加cache的方式可以分批分步骤完成，而不是读、处理、写 、一个完整操作周期，仅针对一个单元）。所以这类数据的整体处理落在通用模块里，通过数据和处理的紧耦合的提升效率。 你说的问题#1和文章中函数式风格一节抱怨employee_read无法和Callback兼容的问题是类似的，说到底就是因为C语言静态类型等语法特性导致了对函数式风格支持不好；同时也反向说明了为什么大多数支持函数式风格的语言会选择“动态类型”，并且支持灵活的可变个数参数等特性，都是为了辅助函数式风格的编码。 #2这一点我不太同意。C语言里虽然没有类的概念把数据和函数在语法层次上绑定在一起，但通过规范地命令提供隐喻，比如代码中，所有操作Employee对象的函数都以employee_前缀开头。而且，这些接口之间也有层级关系，符合下表描述的抽象屏障。如果你把Employee相关的声明、操作独立出来放在一个文件里，然后头文件里只放置公开的接口信息，这样就变得简洁多了。 最高层：使用API的程序 main 基于Employee的接口实现的高级操作 employee_print, employee_adjust_salary 基于最底层的C，对象Employee的最基础的操作，包括读入、释放、遍历等 employee_read, employee_free, foreach, with_open_file C语言本身提供的最底层的工具 struct Empoloyee, for, free, calloc... 例如C语言自带的操作文件的接口同样符合这样的抽象屏障：我们只需要使用fopen、fclose、fread、fwrite等一系列操作FILE对象的接口，无需关心FILE结构体里有些什么内容，表示什么意思，以及各个接口是怎么实现的。 #3的确是一个问题，而且我在文章里也可以没有提及，因为这不是这篇文章要表达的重点。它最本质的问题在于将集合的数据结构和单个对象的信息保存在同一个地方。其他语言，例如Java的java.util.*容器、C++的STL容器，都符合你的设计，将容器这个单一职责抽象出来。当然，我自己实际的工作也是这样做的。 第二个问题其实是不同设计思想的核心问题。你举的例子只能说是些简单的系统中的模块。如果是个大系统中的底层模块特别是引擎方面（会产生数据加工的），这种方法最终组合出来的系统，会比面向对象出来的类套类更复杂。说实话，还不如用面相对象实现。 面向对象，是将数据和操作，进行耦合，并且封装在类里面。这种做法是有它的好处的。这样不会导致数据和操作之间出现问题。而c如果这么写，说实话还不如用c++的类进行实现，因为类描述这些逻辑更为清晰，而且语法和编译器可以帮你做大量的事情。 而相反面向数据，是一批数据（不是一个具体数据单元），存在一批不同操作。如何分析数据之间的无关性和前后操作的无关性是重点，这两个分析清楚，那么并发计算，和分步骤计算就得以实现。并发计算不谈，分步骤计算的思想就是原子操作，或者微指令集管道设计思想。这样设计，可以令复杂的数据处理，根据流程细分到步骤，每个步骤细分到子步骤单元，而每个子步骤单元只负责处理，不负责数据的格式问题。 上面这段的设计思想和面向对象是反过来的，数据和操作松耦合。数据的特殊性导致的操作，是通过各种操作模块组合调用实现（这些操作模块可以看作上面独立的子步骤单元和外部特定数据结构无关的）。 这样做的好处是，模块的设计，可以独立进行，让外部数据格式依赖自身，而不是操作对应数据格式（面向对象是后者，成员变量类型决定了成员函数的实际操作），模块复用率高，同时是整批数据处理，只要数据流程（调用不同模块的系统设计良好），运行效率会很高。而且便于并发操作。 并发操作并不单单是一批数据，分层几组让同一个操作的多个进程处理。流水线技术的使用，一样可以实现。 这里顺带喷下hadoop。貌似hadoop的map reduce并没有在流水线方面有什么突破的思路，这块需要考虑到不同计算单元之间数据流动的费用， hadoop整天扯分布计算，根本不考虑数据整体计算周期内的相关性的问题，基本上都是推给用户自己处理，而用户应该无法控制具体计算硬件设备，最后能有好效果就扯淡了。

面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... mq-1 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 mq-2 总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。 异步 再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 mq-3 一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。 如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ mq-4 削峰 每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。 mq-5 如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。 mq-6 这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 往期回顾： 【Java问答学堂】1期 为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 【Java问答学堂】2期 如何保证消息队列的高可用？ 【Java问答学堂】3期 如何保证消息不被重复消费？或者说，如何保证消息消费的幂等性？ 【Java问答学堂】4期 如何保证消息的可靠性传输？（如何处理消息丢失的问题？） 【Java问答学堂】5期 如何保证消息的顺序性？ 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题？ 【Java问答学堂】7期 如果让你写一个消息队列，该如何进行架构设计？ 【Java问答学堂】8期 es 的分布式架构原理能说一下么（es 是如何实现分布式的啊）？ 【Java问答学堂】9期 es 写入数据的工作原理是什么啊？es 查询数据的工作原理是什么啊？ 【Java问答学堂】10期 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 【Java问答学堂】11期 es 生产集群的部署架构是什么？每个索引的数据量大概有多少？ 【Java问答学堂】12期 项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 【Java问答学堂】13期 redis 和 memcached 有什么区别？ 【Java问答学堂】14期 redis 都有哪些数据类型？分别在哪些场景下使用比较合适？ 【Java问答学堂】15期redis 的过期策略都有哪些？内存淘汰机制都有哪些？ 【Java问答学堂】16期如何保证 redis 的高并发和高可用？redis 的主从复制原理能介绍

面试官心理分析 其实面试官主要是想看看： 第一，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队，leader 交给他一个任务，去设计个什么系统，他在里面用一些技术，可能都没考虑过选型，最后选的技术可能并不一定合适，一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 面试官问你这个问题，期望的一个回答是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个：解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！ 如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。 面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西，用 MQ 作解耦。 异步 再来看一个场景，A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。 一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。 如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了，爽！网站做得真好，真快！ 削峰 每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL，扛到每秒 2k 个请求就差不多了，如果每秒请求到 5k 的话，可能就直接把 MySQL 给打死了，导致系统崩溃，用户也就没法再使用系统了。 但是高峰期一过，到了下午的时候，就成了低峰期，可能也就 1w 的用户同时在网站上操作，每秒中的请求数量可能也就 50 个请求，对整个系统几乎没有任何的压力。 如果使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。 这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。 消息队列有什么优缺点 优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。 缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了，ABCD 四个系统还好好的，没啥问题，你偏加个 MQ 进来，万一 MQ 挂了咋整？MQ 一挂，整套系统崩溃，你不就完了？如何保证消息队列的高可用，可以点击这里查看。 系统复杂度提高 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。 综上，各种对比之后，有如下建议： 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高； 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。 所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。

1，架构师是什么？要想往架构师的方向发展首先要知道架构师是什么？架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些，架构师就是确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2，架构师的任务架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前，应当先成为Java工程师。熟练使用各种框架，并知道它们实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码；池技术，什么对象池，连接池，线程池……Java反射技术，写框架必备的技术，遇到有严重的性能问题，替代方案java字节码技术；nio，没什么好说的，值得注意的是"直接内存"的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题？不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对；总之一句话，越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构，首先打好基础，从最底层开始。然后发展到各种技术和语言，什么都要懂两点，要全面且不肤浅。为什么不是懂一点？你要看得透彻，必须尽量深入一些。别人懂一点，你要做架构师，必须再多懂一点。比如你发现golang很流行，别人可能写一个helloworld就说自己玩过golang，但你至少要尝试写一个完整的应用。不肯下苦功，如何高人一头？另外你要非常深入地了解至少一门语言，如果你的目标是java，就学到极致，作为敲门砖，先吃饱了才能谈理想。3，架构师都是从码农过来的而Java学到极致势必涉及到设计模式，算法和数据结构，多线程，文件及网络IO，数据库及ORM，不一而足。这些概念放之一切语言都适用。先精一门，为全面且不肤浅打基础。另外就是向有经验的架构师学习，和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前，你首先得知道并了解新的技术。架构师都是从码农过来的，媳妇熬成婆。千万不要成为不写代码的架构师，有些公司专门产不写技术的架构师。所谓架构师，只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识，学习各种规范，架构，需要广泛的知识面，懂的东西越多视野越开阔，设计的东西当然会越好越全面。成为架构师需要时间的积累的，不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处，但某天你会发现所有东西都没有白学的。4，架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文（ Distributed computing 分布式计算技术）的应用和工具，成熟目前的技术包括 J2EE，CORBA 和 .NET（DCOM），这些技术牵扯的内容非常广，相关的书籍也非常多。本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题，而近几年因为“大数据”概念的兴起，又焕发出了新的青春与活力。除此之外，分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向，学习分布式系统的同学往往会感觉：“入门容易，深入难”的确，学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域，学习一两门在线课程，看一两本书可能都是不能完全覆盖其所有内容的。总的来说，分布式系统要做的任务就是把多台机器有机的组合，连接起来，让其协同完成一件任务，可以是计算任务，也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话，我个人认为大概可以包括三大部分：分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热，大家都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是不是发展趋势？对于这些问题，我们都缺乏清楚的认识。为解决单体架构下的各种问题，微服务架构应运而生。与其构建一个臃肿庞大，难以驯服的怪兽，还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。将各个服务做轻，从而做到灵活，可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发，管理和迭代在分散的组件中使用云架构和平台式部署，管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确，业务比较精练的服务去解决更大，更实际的问题。三、源码分析从字面意义上来讲，源文件的英文指一个文件，指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符（程序开发代码）。源码分析是一种临界知识，掌握了这种临界知识，能不变应万变，源码分析对于很多人来说很枯燥，生涩难懂。源码阅读，我觉得最核心有三点：技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员，对学习的态度，基本上就是这几个层次（很偏激哦）：1，只关注项目本身，不懂就百度一下。2，除了做好项目，还会阅读和项目有关的技术书籍，看维基百科。3，除了阅读和项目相关的书外，还会阅读IT行业的书，比如学的Java的时，还会去了解函数语言，如LISP。4，找一些开源项目看看，大量试用第三方框架，还会写写演示。5，阅读基础框架，J2EE 规范，调试服务器内核。大多数程序都是第1种，到第5种不光需要浓厚的兴趣，还需要勇气：？我能读懂吗其实，你能够读懂的耐心，真的很重要。因为你极少看到阅读源码的指导性文章或书籍，也没有人要求或建议你读。你读的过程中经常会卡住，而一卡主可能就陷进了迷宫这时，你需要做的，可能是暂时中断一下，再从外围看看它：如API结构，框架的设计图。四、工具使用工欲善其事必先利其器，工具对 Java 的的程序员的重要性不言而喻现在有很多库，实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验，性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受，那如何让用户感受到快呢？加载速度真的很快，用户打开输入网址按下回车立即看到了页面加载速度并没有变快，但用户感觉你的网站很快性能优化取决于多个因素，包括垃圾收集，虚拟机和底层操作系统（OS）设置。有多个工具可供开发人员进行分析和优化时使用，你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是，没有两个应用程序可以使用相同的优化方式，也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化，你作为一个 Java 的开发人员，需要对 Java 的虚拟机（JVM）和底层操作系统有正确的理解。性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢？当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。

本文转自量子位(ID:QbitAI) 边策 鱼羊 发自 凹非寺 量子位 报道 | 公众号 QbitAI 只用99行代码，你也可以像《冰雪奇缘》里的艾莎公主一样拥有冰雪魔法。 虽然你不能在现实世界中肆意变出魔法，但却能在计算机的虚拟世界挥洒特效。 或许你不知道，电影和动画中特效有时仅仅短短的一秒，却可能需要高性能计算机演算一周，花费惊人。 《冰雪奇缘》没有真人出演，预算却高达1.5亿美元，每一秒的镜头都是经费在燃烧。一般人想用电脑做出CG特效简直不可想象。 然而，最近一位来自中国的MIT博士，开发了一种新的CG特效编程语言Taichi（太极），大大降低了门槛。 △白色：雪；红色：果冻；蓝色：水 一个简单的物理场景，普通PC仅需几分钟即可渲染完成，相比TensorFlow提速了188倍、比PyTorch快13.4倍，代码长度只有其他底层方法的十分之一。 安装它就像TensorFlow一样容易，使用起来也是差不多： import taichi as ti 甚至，Taichi的发明者胡渊鸣同学还为此编写了完整使用教程。 关于Taichi，胡同学已经发表了多篇文章，分别被SIGGRAGH 2018、ICRA 2019、NeurIPS2019、ICLR 2020等顶会收录。 计算机图形学知名学者、北大教授陈宝权给出很高的评价： 给胡渊鸣同学点赞！一己之力开发了物理模拟编程语言 Taichi！ 像渊鸣这样如此投入写有影响力的开源代码实在是难能可贵。 像SIGGRAPH这样的，可能要投入1~2年才会有成果，论文接受率低，即使能发表出来，引用率也不高。 网友们在围观之后也纷纷表示：渊鸣大神太强了。 图形+系统+编译，真是创世的快乐。 88行代码模拟真实物理环境 正如胡同学本人所说，99行代码很短，背后的技术故事却很长。 故事的开头，要从Material Point Method（物质点法）说起。 MPM是一种在影视特效领域广受青睐的模拟连续介质方法，迪士尼的《冰雪奇缘》就用到了这项技术。 但在早期，MPM的运行速度非常慢，比如《冰雪奇缘》里安娜过雪地的镜头，据说要在集群上跑整整一个星期。 为了提高MPM的运行速度和性能，在大四毕业的那个暑假，胡渊鸣投入了Moving Least Squares MPM（MLS-MPM）的研究。 胡渊鸣的灵感是，用移动最小二乘法统一APIC（The Affine Particle-In-Cell Method）中的仿射梯度场（affine velocity field）和MPM中的变形梯度更新（deformation gradient update）两种离散化。 在宾夕法尼亚大学蒋陈凡夫教授的指导下，胡渊鸣等人完成了移动最小二乘物质点法（MLS-MPM）方法的研究，不仅实现了新的应力散度离散化，使MPM的运行速度快了两倍，还成功模拟了MPM此前并不支持的各种新现象。 比如材料切割： 刚性体的双向耦合： 这项成果最终发表在了SIGGRAPH 2018上。 为了进一步证明MLS-MPM的简易性，胡渊鸣用88行C++代码实现了MLS-MPM的demo。（代码详情请戳文末 taichi_mpm 项目链接）。 这个88行版本后来也成为了入门MPM的必备参考实现。 乾坤（ChainQueen）可微物理引擎 2017年的夏天结束之后，胡渊鸣正式进入MIT读博。 这时候，胡渊鸣又迸发了新的灵感：求出MLS-MPM的导数。有了导数，就能只用梯度下降来优化神经网络控制器。 在这一思想的指导下，ChainQueen诞生了。 胡渊鸣解释说，chain是为了纪念他在求导过程中被链式法则折磨的经历，而ChainQueen则与乾坤谐音。 乾坤基于MLS-MPM，是一种针对可变形对象的、实时的可微混合拉格朗日-欧拉物理模拟器。该模拟器在前向仿真和反向梯度计算中均实现了高精度。 这项研究发表在了ICRA 2019上，胡渊鸣也以此完成了硕士论文。 DiffTaichi 随后，胡同学将工作又推进一步，提出了可微分编程DiffTaichi，被ICLR 2020收录。 在这篇文章的代码中，胡同学创建了10个不同的物理模拟器，并根据现有基准对其性能进行基准测试。 Taichi中的可微分编程，可以通过蛮力的梯度下降有效地优化神经网络控制器，而不必使用强化学习。 10种可微分模拟器中的大多数模型可以在2-3小时内实现，而且大部分不需要GPU。这些示例中，弹性体、刚体、流体、光线的折射、弹性碰撞，常见物理环境应有尽有。 第一个示例可微分弹性对象模拟器，经过我们的实测，在2017版13寸的MacBook Pro上也能运行，而且完成优化只需不到十分钟的时间： 不仅是2D，更复杂的3D弹性体也能模拟： 还有可微分的3D流体模拟器，经过450步的梯度下降迭代，已经非常逼真： DiffTaichi模拟水对光线折射的渲染器，一张图片经过它的渲染，甚至能骗过图像分类器。经过测试，VGG16将带有水波纹的松鼠图片当做金鱼，而且认为概率为99.91%。 在强化学习的模拟环境中，刚体机器人很常见，DiffTaichi也能模拟： DiffTaichi还能模拟多个物体的复杂场景，比如台球： 用Taichi语言编写的模拟器大大简化了代码，可微分弹性对象模拟器只用了110行代码，而直接用CUDA编写则需要490行。 同时，Taichi的速度还很快，相比CUDA版本几乎没有什么损失，比TensorFlow快了188倍，比PyTorch快13.4倍。 而且神经网络控制器一般只需要几十次迭代，即可完成优化。 为何做Taichi 谈到为何要做Taichi，计算机图形学一直缺乏像TensorFlow那样的通用工具，每个要从事开发的人都必须了解基本原理，才能去做编程。 这和深度学习领域形成了鲜明的对比。 近年来，甚至有中学生，利用TensorFlow或者PyTorch，写一点代码，优化几个模型，就可以在一些顶会上发表论文，许多人看来，这是件坏事，因为让深度学习论文的含金量大大降低。 但胡渊鸣看到了另一面。他认为，深度学习这些年之所以能发展快、门槛低，就是因为有简单易用的好工具，计算机图形学让人望而却步，就是因为缺乏类似的工具，因此他开发了Taichi。 本来Taichi要做成一种单独的编程语言，但是为了方便大家使用，胡渊鸣用了一句import taichi as ti把Taichi语言假装成Python。 改成基于Python，这样做的好处不仅是降低学习门槛，还能使用很多现成的Python IDE，与numpy、matplotlib等工具库无缝衔接。 经过几个月的努力，胡渊鸣终于把Taichi改成了pypi安装包，让不同配置不同操作系统的机器都能顺利运行图形学的程序。 高一保送清华，博一6篇paper 说起胡渊鸣，这又是一位从少年时代起就熠熠闪光的“大神级”选手。 高一保送清华，竞赛生涯中，拿下APIO 2012、NOI 2012、ACM-ICPC 2013长沙区域赛、ACM-ICPC上海区域赛四块金牌，其中APIO 2012成绩是全场第一名。 2013年进入清华姚班，胡渊鸣与陈立杰、范浩强等人成为同班同学，这群年轻人的才华在这里汇聚、碰撞，与“姚班”二字相互成就。 本科期间，胡渊鸣先后前往东京大学、斯坦福大学访学，并曾于微软亚洲研究院实习，从事深度学习和计算机图形学研究。本科便有多篇论文中选CVPR、SIGGRAPH等国际顶会。 2017年，胡渊鸣进入MIT读博。入学13个月后，完成硕士论文ChainQueen，拿到MIT硕士学位。博一期间，共发表6篇顶会论文。

我们先从整体上看一下Kubernetes的一些理念和基本架构，然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。　　当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。　　1.Kubernetes的一些理念：　　用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。　　保证系统总是按照用户指定的状态去运行。　　不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。　　那些需要担心和不需要担心的事情。　　更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。　　对于Kubernetes的架构，可以参考官方文档。　　大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。　　看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在Kubernetes的未来版本中解决。　　2.Kubernetes的主要特性　　会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限，只能简单一些了。　　另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。　　1）网络　　Kubernetes的网络方式主要解决以下几个问题：　　a.紧耦合的容器之间通信，通过Pod和localhost访问解决。　　b.Pod之间通信，建立通信子网，比如隧道、路由，Flannel、OpenvSwitch、Weave。　　c.Pod和Service，以及外部系统和Service的通信，引入Service解决。　　Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。　　注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖PodIP；通过Service环境变量或者DNS解决。　　2）服务发现及负载均衡　　kube-proxy和DNS，在v1之前，Service含有字段portalip和publicIPs，分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp,而在serviceport定义列表里，增加了nodePort项，即对应node上映射的服务端口。　　DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。　　注意：kube-proxy在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。　　3）资源管理　　有3个层次的资源限制方式，分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持，比如Docker对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。　　资源管理模型－》简单、通用、准确，并可扩展　　目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。　　4）高可用　　主要是指Master节点的HA方式官方推荐利用etcd实现master选举，从多个Master中得到一个kube-apiserver保证至少有一个master可用，实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。　　一张图帮助大家理解：　　也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个，而且伴随着kube-apiserver同一时间只能有一套运行。　　5）rollingupgrade　　RC在开始的设计就是让rollingupgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。　　通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback当前正在执行的upgrade操作。　　同样，Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。　　6）存储　　大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。　　Docker也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。　　创建一个带Volume的Pod：　　spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。　　emptyDir随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源（比如本地Docker）。　　gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。　　awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。　　rbd-RadosBlockDevice-Ceph　　secret用来通过KubernetesAPI向Pod传递敏感信息，使用tmpfs（aRAM-backedfilesystem）　　persistentVolumeClaim-从抽象的PV中申请资源，而无需关心存储的提供方　　glusterfs　　iscsi　　gitRepo　　根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的:）　　7）安全　　一些主要原则：　　基础设施模块应该通过APIserver交换数据、修改系统状态，而且只有APIserver可以访问后端存储（etcd）。　　把用户分为不同的角色：Developers/ProjectAdmins/Administrators。　　允许Developers定义secrets对象，并在pod启动时关联到相关容器。　　以secret为例，如果kubelet要去pull私有镜像，那么Kubernetes支持以下方式：　　通过dockerlogin生成.dockercfg文件，进行全局授权。　　通过在每个namespace上创建用户的secret对象，在创建Pod时指定imagePullSecrets属性（也可以统一设置在serviceAcouunt上），进行授权。　　认证（Authentication）　　APIserver支持证书、token、和基本信息三种认证方式。　　授权（Authorization）　　通过apiserver的安全端口，authorization会应用到所有http的请求上　　AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。　　8）监控　　比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。　　Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。　　注意：heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 答案来源网络，供您参考

我们先从整体上看一下Kubernetes的一些理念和基本架构，然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。　　当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。　　1.Kubernetes的一些理念：　　用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。　　保证系统总是按照用户指定的状态去运行。　　不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。　　那些需要担心和不需要担心的事情。　　更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。　　对于Kubernetes的架构，可以参考官方文档。　　大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。　　看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在Kubernetes的未来版本中解决。　　2.Kubernetes的主要特性　　会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限，只能简单一些了。　　另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。　　1）网络　　Kubernetes的网络方式主要解决以下几个问题：　　a.紧耦合的容器之间通信，通过Pod和localhost访问解决。　　b.Pod之间通信，建立通信子网，比如隧道、路由，Flannel、OpenvSwitch、Weave。　　c.Pod和Service，以及外部系统和Service的通信，引入Service解决。　　Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。　　注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖PodIP；通过Service环境变量或者DNS解决。　　2）服务发现及负载均衡　　kube-proxy和DNS，在v1之前，Service含有字段portalip和publicIPs，分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp,而在serviceport定义列表里，增加了nodePort项，即对应node上映射的服务端口。　　DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain,“tenx.domain”是提前设置的主域名。　　注意：kube-proxy在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。　　3）资源管理　　有3个层次的资源限制方式，分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持，比如Docker对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。　　资源管理模型－》简单、通用、准确，并可扩展　　目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。　　4）高可用　　主要是指Master节点的HA方式官方推荐利用etcd实现master选举，从多个Master中得到一个kube-apiserver保证至少有一个master可用，实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。　　一张图帮助大家理解：　　也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个，而且伴随着kube-apiserver同一时间只能有一套运行。　　5）rollingupgrade　　RC在开始的设计就是让rollingupgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。　　通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback当前正在执行的upgrade操作。　　同样，Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。　　6）存储　　大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。　　Docker也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。　　创建一个带Volume的Pod：　　spec.volumes指定这个Pod需要的volume信息spec.containers.volumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。　　emptyDir随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源（比如本地Docker）。　　gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。　　awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。　　rbd-RadosBlockDevice-Ceph　　secret用来通过KubernetesAPI向Pod传递敏感信息，使用tmpfs（aRAM-backedfilesystem）　　persistentVolumeClaim-从抽象的PV中申请资源，而无需关心存储的提供方　　glusterfs　　iscsi　　gitRepo　　根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的:）　　7）安全　　一些主要原则：　　基础设施模块应该通过APIserver交换数据、修改系统状态，而且只有APIserver可以访问后端存储（etcd）。　　把用户分为不同的角色：Developers/ProjectAdmins/Administrators。　　允许Developers定义secrets对象，并在pod启动时关联到相关容器。　　以secret为例，如果kubelet要去pull私有镜像，那么Kubernetes支持以下方式：　　通过dockerlogin生成.dockercfg文件，进行全局授权。　　通过在每个namespace上创建用户的secret对象，在创建Pod时指定imagePullSecrets属性（也可以统一设置在serviceAcouunt上），进行授权。　　认证（Authentication）　　APIserver支持证书、token、和基本信息三种认证方式。　　授权（Authorization）　　通过apiserver的安全端口，authorization会应用到所有http的请求上　　AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。　　8）监控　　比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的containermetrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。　　Kubernetes集群范围内的监控主要由kubelet、heapster和storagebackend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。　　注意：heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 “答案来源于网络，供您参考” 希望以上信息可以帮到您！

我们先从整体上看一下Kubernetes的一些理念和基本架构， 然后从网络、 资源管理、存储、服务发现、负载均衡、高可用、rolling upgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。 当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解 Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。 1.Kubernetes的一些理念： 用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。 保证系统总是按照用户指定的状态去运行。 不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。 那些需要担心和不需要担心的事情。 更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。 对于Kubernetes的架构，可以参考官方文档。 大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。 看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在 Kubernetes 的未来版本中解决。 2.Kubernetes的主要特性 会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性 -> 由于时间有限，只能简单一些了。 另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。 1）网络 Kubernetes的网络方式主要解决以下几个问题： a. 紧耦合的容器之间通信，通过 Pod 和 localhost 访问解决。 b. Pod之间通信，建立通信子网，比如隧道、路由，Flannel、Open vSwitch、Weave。 c. Pod和Service，以及外部系统和Service的通信，引入Service解决。 Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。 注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖Pod IP；通过Service环境变量或者DNS解决。 2） 服务发现及负载均衡 kube-proxy和DNS， 在v1之前，Service含有字段portalip 和publicIPs， 分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp 通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp, 而在service port 定义列表里，增加了nodePort项，即对应node上映射的服务端口。 DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取Kubernetes API获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicename.namespace.tenx.domain, "tenx.domain"是提前设置的主域名。 注意：kube-proxy 在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service 的endpints 或者 Pods上。Kubernetes官方也在修复这个问题。 3）资源管理 有3 个层次的资源限制方式，分别在Container、Pod、Namespace 层次。Container层次主要利用容器本身的支持，比如Docker 对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。 资源管理模型 －》 简单、通用、准确，并可扩展 目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的scheduler plugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。 4）高可用 主要是指Master节点的 HA方式 官方推荐 利用etcd实现master 选举，从多个Master中得到一个kube-apiserver 保证至少有一个master可用，实现high availability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。 一张图帮助大家理解： 也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个，而且伴随着kube-apiserver 同一时间只能有一套运行。 5） rolling upgrade RC 在开始的设计就是让rolling upgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。 通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback 当前正在执行的upgrade操作。 同样， Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。 6）存储 大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes 的 Volume就是主要来解决上面两个基础问题的。 Docker 也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。 创建一个带Volume的Pod： spec.volumes 指定这个Pod需要的volume信息 spec.containers.volumeMounts 指定哪些container需要用到这个Volume Kubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。 emptyDir 随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持 RAM-backed filesystemhostPath 类似于Docker的本地Volume 用于访问一些本地资源（比如本地Docker）。 gcePersistentDisk GCE disk - 只有在 Google Cloud Engine 平台上可用。 awsElasticBlockStore 类似于GCE disk 节点必须是 AWS EC2的实例 nfs - 支持网络文件系统。 rbd - Rados Block Device - Ceph secret 用来通过Kubernetes API 向Pod 传递敏感信息，使用 tmpfs （a RAM-backed filesystem） persistentVolumeClaim - 从抽象的PV中申请资源，而无需关心存储的提供方 glusterfs iscsi gitRepo 根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的 :) 7）安全 一些主要原则： 基础设施模块应该通过API server交换数据、修改系统状态，而且只有API server可以访问后端存储（etcd）。 把用户分为不同的角色：Developers/Project Admins/Administrators。 允许Developers定义secrets 对象，并在pod启动时关联到相关容器。 以secret 为例，如果kubelet要去pull 私有镜像，那么Kubernetes支持以下方式： 通过docker login 生成 .dockercfg 文件，进行全局授权。 通过在每个namespace上创建用户的secret对象，在创建Pod时指定 imagePullSecrets 属性（也可以统一设置在serviceAcouunt 上），进行授权。 认证 （Authentication） API server 支持证书、token、和基本信息三种认证方式。 授权 （Authorization） 通过apiserver的安全端口，authorization会应用到所有http的请求上 AlwaysDeny、AlwaysAllow、ABAC三种模式，其他需求可以自己实现Authorizer接口。 8）监控 比较老的版本Kubernetes需要外接cadvisor主要功能是将node主机的container metrics抓取出来。在较新的版本里，cadvior功能被集成到了kubelet组件中，kubelet在与docker交互的同时，对外提供监控服务。 Kubernetes集群范围内的监控主要由kubelet、heapster和storage backend（如influxdb）构建。Heapster可以在集群范围获取metrics和事件数据。它可以以pod的方式运行在k8s平台里，也可以单独运行以standalone的方式。 注意： heapster目前未到1.0版本，对于小规模的集群监控比较方便。但对于较大规模的集群，heapster目前的cache方式会吃掉大量内存。因为要定时获取整个集群的容器信息，信息在内存的临时存储成为问题，再加上heaspter要支持api获取临时metrics，如果将heapster以pod方式运行，很容易出现OOM。所以目前建议关掉cache并以standalone的方式独立出k8s平台。 此答案来源于网络，希望对你有所帮助。

初识 MyBatis MyBatis 是第一个支持自定义 SQL、存储过程和高级映射的类持久框架。MyBatis 消除了大部分 JDBC 的样板代码、手动设置参数以及检索结果。MyBatis 能够支持简单的 XML 和注解配置规则。使 Map 接口和 POJO 类映射到数据库字段和记录。 MyBatis 的特点 那么 MyBatis 具有什么特点呢？或许我们可以从如下几个方面来描述 MyBatis 中的 SQL 语句和主要业务代码分离，我们一般会把 MyBatis 中的 SQL 语句统一放在 XML 配置文件中，便于统一维护。 解除 SQL 与程序代码的耦合，通过提供 DAO 层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。SQL 和代码的分离，提高了可维护性。 MyBatis 比较简单和轻量 本身就很小且简单。没有任何第三方依赖，只要通过配置 jar 包，或者如果你使用 Maven 项目的话只需要配置 Maven 以来就可以。易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。 屏蔽样板代码 MyBatis 回屏蔽原始的 JDBC 样板代码，让你把更多的精力专注于 SQL 的书写和属性-字段映射上。 编写原生 SQL，支持多表关联 MyBatis 最主要的特点就是你可以手动编写 SQL 语句，能够支持多表关联查询。 提供映射标签，支持对象与数据库的 ORM 字段关系映射 ORM 是什么？对象关系映射(Object Relational Mapping，简称ORM) ，是通过使用描述对象和数据库之间映射的元数据，将面向对象语言程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 提供 XML 标签，支持编写动态 SQL。 你可以使用 MyBatis XML 标签，起到 SQL 模版的效果，减少繁杂的 SQL 语句，便于维护。 MyBatis 整体架构 MyBatis 最上面是接口层，接口层就是开发人员在 Mapper 或者是 Dao 接口中的接口定义，是查询、新增、更新还是删除操作；中间层是数据处理层，主要是配置 Mapper -> XML 层级之间的参数映射，SQL 解析，SQL 执行，结果映射的过程。上述两种流程都由基础支持层来提供功能支撑，基础支持层包括连接管理，事务管理，配置加载，缓存处理等。 接口层 在不与Spring 集成的情况下，使用 MyBatis 执行数据库的操作主要如下： InputStream is = Resources.getResourceAsStream("myBatis-config.xml"); SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory factory = builder.build(is); sqlSession = factory.openSession(); 其中的SqlSessionFactory,SqlSession是 MyBatis 接口的核心类，尤其是 SqlSession，这个接口是MyBatis 中最重要的接口，这个接口能够让你执行命令，获取映射，管理事务。 数据处理层 配置解析 在 Mybatis 初始化过程中，会加载 mybatis-config.xml 配置文件、映射配置文件以及 Mapper 接口中的注解信息，解析后的配置信息会形成相应的对象并保存到 Configration 对象中。之后，根据该对象创建SqlSessionFactory 对象。待 Mybatis 初始化完成后，可以通过 SqlSessionFactory 创建 SqlSession 对象并开始数据库操作。 SQL 解析与 scripting 模块 Mybatis 实现的动态 SQL 语句，几乎可以编写出所有满足需要的 SQL。 Mybatis 中 scripting 模块会根据用户传入的参数，解析映射文件中定义的动态 SQL 节点，形成数据库能执行的SQL 语句。 SQL 执行 SQL 语句的执行涉及多个组件，包括 MyBatis 的四大核心，它们是: Executor、StatementHandler、ParameterHandler、ResultSetHandler。SQL 的执行过程可以用下面这幅图来表示 MyBatis 层级结构各个组件的介绍(这里只是简单介绍，具体介绍在后面)： SqlSession： ，它是 MyBatis 核心 API，主要用来执行命令，获取映射，管理事务。接收开发人员提供 Statement Id 和参数。并返回操作结果。Executor ：执行器，是 MyBatis 调度的核心，负责 SQL 语句的生成以及查询缓存的维护。StatementHandler : 封装了JDBC Statement 操作，负责对 JDBC Statement 的操作，如设置参数、将Statement 结果集转换成 List 集合。ParameterHandler : 负责对用户传递的参数转换成 JDBC Statement 所需要的参数。ResultSetHandler : 负责将 JDBC 返回的 ResultSet 结果集对象转换成 List 类型的集合。TypeHandler : 用于 Java 类型和 JDBC 类型之间的转换。MappedStatement : 动态 SQL 的封装SqlSource : 表示从 XML 文件或注释读取的映射语句的内容，它创建将从用户接收的输入参数传递给数据库的 SQL。Configuration: MyBatis 所有的配置信息都维持在 Configuration 对象之中。 基础支持层 反射模块 Mybatis 中的反射模块，对 Java 反射进行了很好的封装，提供了简易的 API，方便上层调用，并且对反射操作进行了一系列的优化，比如，缓存了类的 元数据（MetaClass）和对象的元数据（MetaObject），提高了反射操作的性能。 类型转换模块 Mybatis 的别名机制，能够简化配置文件，该机制是类型转换模块的主要功能之一。类型转换模块的另一个功能是实现 JDBC 类型与 Java 类型的转换。在 SQL 语句绑定参数时，会将数据由 Java 类型转换成 JDBC 类型；在映射结果集时，会将数据由 JDBC 类型转换成 Java 类型。 日志模块 在 Java 中，有很多优秀的日志框架，如 Log4j、Log4j2、slf4j 等。Mybatis 除了提供了详细的日志输出信息，还能够集成多种日志框架，其日志模块的主要功能就是集成第三方日志框架。 资源加载模块 该模块主要封装了类加载器，确定了类加载器的使用顺序，并提供了加载类文件和其它资源文件的功能。 解析器模块 该模块有两个主要功能：一个是封装了 XPath，为 Mybatis 初始化时解析 mybatis-config.xml配置文件以及映射配置文件提供支持；另一个为处理动态 SQL 语句中的占位符提供支持。 数据源模块 Mybatis 自身提供了相应的数据源实现，也提供了与第三方数据源集成的接口。数据源是开发中的常用组件之一，很多开源的数据源都提供了丰富的功能，如连接池、检测连接状态等，选择性能优秀的数据源组件，对于提供ORM 框架以及整个应用的性能都是非常重要的。 事务管理模块 一般地，Mybatis 与 Spring 框架集成，由 Spring 框架管理事务。但 Mybatis 自身对数据库事务进行了抽象，提供了相应的事务接口和简单实现。 缓存模块 Mybatis 中有一级缓存和二级缓存，这两级缓存都依赖于缓存模块中的实现。但是需要注意，这两级缓存与Mybatis 以及整个应用是运行在同一个 JVM 中的，共享同一块内存，如果这两级缓存中的数据量较大，则可能影响系统中其它功能，所以需要缓存大量数据时，优先考虑使用 Redis、Memcache 等缓存产品。 Binding 模块 在调用 SqlSession 相应方法执行数据库操作时，需要制定映射文件中定义的 SQL 节点，如果 SQL 中出现了拼写错误，那就只能在运行时才能发现。为了能尽早发现这种错误，Mybatis 通过 Binding 模块将用户自定义的Mapper 接口与映射文件关联起来，系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作，从而避免上述问题。注意，在开发中，我们只是创建了 Mapper 接口，而并没有编写实现类，这是因为 Mybatis 自动为 Mapper 接口创建了动态代理对象。 MyBatis 核心组件 在认识了 MyBatis 并了解其基础架构之后，下面我们来看一下 MyBatis 的核心组件，就是这些组件实现了从 SQL 语句到映射到 JDBC 再到数据库字段之间的转换，执行 SQL 语句并输出结果集。首先来认识 MyBatis 的第一个核心组件 SqlSessionFactory 对于任何框架而言，在使用该框架之前都要经历过一系列的初始化流程，MyBatis 也不例外。MyBatis 的初始化流程如下 String resource = "org/mybatis/example/mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(resource); SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); sqlSessionFactory.openSession(); 上述流程中比较重要的一个对象就是SqlSessionFactory，SqlSessionFactory 是 MyBatis 框架中的一个接口，它主要负责的是 MyBatis 框架初始化操作 为开发人员提供SqlSession 对象 SqlSessionFactory 有两个实现类，一个是 SqlSessionManager 类，一个是 DefaultSqlSessionFactory 类 DefaultSqlSessionFactory : SqlSessionFactory 的默认实现类，是真正生产会话的工厂类，这个类的实例的生命周期是全局的，它只会在首次调用时生成一个实例（单例模式），就一直存在直到服务器关闭。 SqlSessionManager ： 已被废弃，原因大概是: SqlSessionManager 中需要维护一个自己的线程池，而使用MyBatis 更多的是要与 Spring 进行集成，并不会单独使用，所以维护自己的 ThreadLocal 并没有什么意义，所以 SqlSessionManager 已经不再使用。 ####SqlSessionFactory 的执行流程 下面来对 SqlSessionFactory 的执行流程来做一个分析 首先第一步是 SqlSessionFactory 的创建 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); 1 从这行代码入手，首先创建了一个 SqlSessionFactoryBuilder 工厂，这是一个建造者模式的设计思想，由 builder 建造者来创建 SqlSessionFactory 工厂 然后调用 SqlSessionFactoryBuilder 中的 build 方法传递一个InputStream 输入流，Inputstream 输入流中就是你传过来的配置文件 mybatis-config.xml，SqlSessionFactoryBuilder 根据传入的 InputStream 输入流和environment、properties属性创建一个XMLConfigBuilder对象。SqlSessionFactoryBuilder 对象调用XMLConfigBuilder 的parse()方法，流程如下。 XMLConfigBuilder 会解析/configuration标签，configuration 是 MyBatis 中最重要的一个标签，下面流程会介绍 Configuration 标签。 MyBatis 默认使用 XPath 来解析标签，关于 XPath 的使用，参见 https://www.w3school.com.cn/xpath/index.asp 在 parseConfiguration 方法中，会对各个在 /configuration 中的标签进行解析 重要配置 说一下这些标签都是什么意思吧 properties，外部属性，这些属性都是可外部配置且可动态替换的，既可以在典型的 Java 属性文件中配置，亦可通过 properties 元素的子元素来传递。 <properties> <property name="driver" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/test" /> <property name="username" value="root" /> <property name="password" value="root" /> </properties> 一般用来给 environment 标签中的 dataSource 赋值 <environment id="development"> <transactionManager type="JDBC" /> <dataSource type="POOLED"> <property name="driver" value="${driver}" /> <property name="url" value="${url}" /> <property name="username" value="${username}" /> <property name="password" value="${password}" /> </dataSource> </environment> 还可以通过外部属性进行配置，但是我们这篇文章以原理为主，不会介绍太多应用层面的操作。 settings ，MyBatis 中极其重要的配置，它们会改变 MyBatis 的运行时行为。 settings 中配置有很多，具体可以参考 https://mybatis.org/mybatis-3/zh/configuration.html#settings 详细了解。这里介绍几个平常使用过程中比较重要的配置 一般使用如下配置 <settings> <setting name="cacheEnabled" value="true"/> <setting name="lazyLoadingEnabled" value="true"/> </settings> typeAliases，类型别名，类型别名是为 Java 类型设置的一个名字。 它只和 XML 配置有关。 <typeAliases> <typeAlias alias="Blog" type="domain.blog.Blog"/> </typeAliases> 当这样配置时，Blog 可以用在任何使用 domain.blog.Blog 的地方。 typeHandlers，类型处理器，无论是 MyBatis 在预处理语句（PreparedStatement）中设置一个参数时，还是从结果集中取出一个值时， 都会用类型处理器将获取的值以合适的方式转换成 Java 类型。 在 org.apache.ibatis.type 包下有很多已经实现好的 TypeHandler，可以参考如下 你可以重写类型处理器或创建你自己的类型处理器来处理不支持的或非标准的类型。 具体做法为：实现 org.apache.ibatis.type.TypeHandler 接口， 或继承一个很方便的类 org.apache.ibatis.type.BaseTypeHandler， 然后可以选择性地将它映射到一个 JDBC 类型。 objectFactory，对象工厂，MyBatis 每次创建结果对象的新实例时，它都会使用一个对象工厂（ObjectFactory）实例来完成。默认的对象工厂需要做的仅仅是实例化目标类，要么通过默认构造方法，要么在参数映射存在的时候通过参数构造方法来实例化。如果想覆盖对象工厂的默认行为，则可以通过创建自己的对象工厂来实现。 public class ExampleObjectFactory extends DefaultObjectFactory { public Object create(Class type) { return super.create(type); } public Object create(Class type, List constructorArgTypes, List constructorArgs) { return super.create(type, constructorArgTypes, constructorArgs); } public void setProperties(Properties properties) { super.setProperties(properties); } public boolean isCollection(Class type) { return Collection.class.isAssignableFrom(type); } } 然后需要在 XML 中配置此对象工厂 <objectFactory type="org.mybatis.example.ExampleObjectFactory"> <property name="someProperty" value="100"/> </objectFactory> plugins，插件开发，插件开发是 MyBatis 设计人员给开发人员留给自行开发的接口，MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。MyBatis 允许使用插件来拦截的方法调用包括：Executor、ParameterHandler、ResultSetHandler、StatementHandler 接口，这几个接口也是 MyBatis 中非常重要的接口，我们下面会详细介绍这几个接口。 environments，MyBatis 环境配置，MyBatis 可以配置成适应多种环境，这种机制有助于将 SQL 映射应用于多种数据库之中。例如，开发、测试和生产环境需要有不同的配置；或者想在具有相同 Schema 的多个生产数据库中 使用相同的 SQL 映射。 这里注意一点，虽然 environments 可以指定多个环境，但是 SqlSessionFactory 只能有一个，为了指定创建哪种环境，只要将它作为可选的参数传递给 SqlSessionFactoryBuilder 即可。 SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment); SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment, properties); databaseIdProvider ，数据库厂商标示，MyBatis 可以根据不同的数据库厂商执行不同的语句，这种多厂商的支持是基于映射语句中的 databaseId 属性。 <databaseIdProvider type="DB_VENDOR"> <property name="SQL Server" value="sqlserver"/> <property name="DB2" value="db2"/> <property name="Oracle" value="oracle" /> </databaseIdProvider> mappers，映射器，这是告诉 MyBatis 去哪里找到这些 SQL 语句，mappers 映射配置有四种方式 上面的一个个属性都对应着一个解析方法，都是使用 XPath 把标签进行解析，解析完成后返回一个 DefaultSqlSessionFactory 对象，它是 SqlSessionFactory 的默认实现类。这就是 SqlSessionFactoryBuilder 的初始化流程，通过流程我们可以看到，初始化流程就是对一个个 /configuration 标签下子标签的解析过程。 SqlSession 在 MyBatis 初始化流程结束，也就是 SqlSessionFactoryBuilder -> SqlSessionFactory 的获取流程后，我们就可以通过 SqlSessionFactory 对象得到 SqlSession 然后执行 SQL 语句了。具体来看一下这个过程‘ 在 SqlSessionFactory.openSession 过程中我们可以看到，会调用到 DefaultSqlSessionFactory 中的 openSessionFromDataSource 方法，这个方法主要创建了两个与我们分析执行流程重要的对象，一个是 Executor 执行器对象，一个是 SqlSession 对象。执行器我们下面会说，现在来说一下 SqlSession 对象 SqlSession 对象是 MyBatis 中最重要的一个对象，这个接口能够让你执行命令，获取映射，管理事务。SqlSession 中定义了一系列模版方法，让你能够执行简单的 CRUD 操作，也可以通过 getMapper 获取 Mapper 层，执行自定义 SQL 语句，因为 SqlSession 在执行 SQL 语句之前是需要先开启一个会话，涉及到事务操作，所以还会有 commit、 rollback、close 等方法。这也是模版设计模式的一种应用。 MapperProxy MapperProxy 是 Mapper 映射 SQL 语句的关键对象，我们写的 Dao 层或者 Mapper 层都是通过 MapperProxy 来和对应的 SQL 语句进行绑定的。下面我们就来解释一下绑定过程 这就是 MyBatis 的核心绑定流程，我们可以看到 SqlSession 首先调用 getMapper 方法，我们刚才说到 SqlSession 是大哥级别的人物，只定义标准（有一句话是怎么说的来着，一流的企业做标准，二流的企业做品牌，三流的企业做产品）。 SqlSession 不愿意做的事情交给 Configuration 这个手下去做，但是 Configuration 也是有小弟的，它不愿意做的事情直接甩给小弟去做，这个小弟是谁呢？它就是 MapperRegistry，马上就到核心部分了。MapperRegistry 相当于项目经理，项目经理只从大面上把握项目进度，不需要知道手下的小弟是如何工作的，把任务完成了就好。最终真正干活的还是 MapperProxyFactory。看到这段代码 Proxy.newProxyInstance ，你是不是有一种恍然大悟的感觉，如果你没有的话，建议查阅一下动态代理的文章，这里推荐一篇 （https://www.jianshu.com/p/95970b089360） 也就是说，MyBatis 中 Mapper 和 SQL 语句的绑定正是通过动态代理来完成的。 通过动态代理，我们就可以方便的在 Dao 层或者 Mapper 层定义接口，实现自定义的增删改查操作了。那么具体的执行过程是怎么样呢？上面只是绑定过程，别着急，下面就来探讨一下 SQL 语句的执行过程。 MapperProxyFactory 会生成代理对象，这个对象就是 MapperProxy，最终会调用到 mapperMethod.execute 方法，execute 方法比较长，其实逻辑比较简单，就是判断是 插入、更新、删除 还是 查询 语句，其中如果是查询的话，还会判断返回值的类型，我们可以点进去看一下都是怎么设计的。 很多代码其实可以忽略，只看我标出来的重点就好了，我们可以看到，不管你前面经过多少道关卡处理，最终都逃不过 SqlSession 这个老大制定的标准。 我们以 selectList 为例，来看一下下面的执行过程。 这是 DefaultSqlSession 中 selectList 的代码，我们可以看到出现了 executor，这是什么呢？我们下面来解释。 Executor 还记得我们之前的流程中提到了 Executor(执行器) 这个概念吗？我们来回顾一下它第一次出现的位置。 由 Configuration 对象创建了一个 Executor 对象，这个 Executor 是干嘛的呢？下面我们就来认识一下 Executor 的继承结构 每一个 SqlSession 都会拥有一个 Executor 对象，这个对象负责增删改查的具体操作，我们可以简单的将它理解为 JDBC 中 Statement 的封装版。 也可以理解为 SQL 的执行引擎，要干活总得有一个发起人吧，可以把 Executor 理解为发起人的角色。 首先先从 Executor 的继承体系来认识一下 如上图所示，位于继承体系最顶层的是 Executor 执行器，它有两个实现类，分别是BaseExecutor和 CachingExecutor。 BaseExecutor 是一个抽象类，这种通过抽象的实现接口的方式是适配器设计模式之接口适配 的体现，是Executor 的默认实现，实现了大部分 Executor 接口定义的功能，降低了接口实现的难度。BaseExecutor 的子类有三个，分别是 SimpleExecutor、ReuseExecutor 和 BatchExecutor。 SimpleExecutor : 简单执行器，是 MyBatis 中默认使用的执行器，每执行一次 update 或 select，就开启一个Statement 对象，用完就直接关闭 Statement 对象(可以是 Statement 或者是 PreparedStatment 对象) ReuseExecutor : 可重用执行器，这里的重用指的是重复使用 Statement，它会在内部使用一个 Map 把创建的Statement 都缓存起来，每次执行 SQL 命令的时候，都会去判断是否存在基于该 SQL 的 Statement 对象，如果存在 Statement 对象并且对应的 connection 还没有关闭的情况下就继续使用之前的 Statement 对象，并将其缓存起来。因为每一个 SqlSession 都有一个新的 Executor 对象，所以我们缓存在 ReuseExecutor 上的 Statement作用域是同一个 SqlSession。 BatchExecutor : 批处理执行器，用于将多个 SQL 一次性输出到数据库 CachingExecutor: 缓存执行器，先从缓存中查询结果，如果存在就返回之前的结果；如果不存在，再委托给Executor delegate 去数据库中取，delegate 可以是上面任何一个执行器。 Executor 的创建和选择 我们上面提到 Executor 是由 Configuration 创建的，Configuration 会根据执行器的类型创建，如下 这一步就是执行器的创建过程，根据传入的 ExecutorType 类型来判断是哪种执行器，如果不指定 ExecutorType ，默认创建的是简单执行器。它的赋值可以通过两个地方进行赋值： 可以通过 标签来设置当前工程中所有的 SqlSession 对象使用默认的 Executor <settings> <!--取值范围 SIMPLE, REUSE, BATCH --> <setting name="defaultExecutorType" value="SIMPLE"/> </settings> 另外一种直接通过Java对方法赋值的方式 session = factory.openSession(ExecutorType.BATCH); Executor 的具体执行过程 Executor 中的大部分方法的调用链其实是差不多的，下面是深入源码分析执行过程，如果你没有时间或者暂时不想深入研究的话，给你下面的执行流程图作为参考。 我们紧跟着上面的 selectList 继续分析，它会调用到 executor.query 方法。 当有一个查询请求访问的时候，首先会经过 Executor 的实现类 CachingExecutor ，先从缓存中查询 SQL 是否是第一次执行，如果是第一次执行的话，那么就直接执行 SQL 语句，并创建缓存，如果第二次访问相同的 SQL 语句的话，那么就会直接从缓存中提取。 上面这段代码是从 selectList -> 从缓存中 query 的具体过程。可能你看到这里有些觉得类都是什么东西，我想鼓励你一下，把握重点，不用每段代码都看，从找到 SQL 的调用链路，其他代码想看的时候在看，看源码就是很容易发蒙，容易烦躁，但是切记一点，把握重点。 上面代码会判断缓存中是否有这条 SQL 语句的执行结果，如果没有的话，就再重新创建 Executor 执行器执行 SQL 语句，注意， list = doQuery 是真正执行 SQL 语句的过程，这个过程中会创建我们上面提到的三种执行器，这里我们使用的是简单执行器。 到这里，执行器所做的工作就完事了，Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler 上面代码会判断缓存中是否有这条 SQL 语句的执行结果，如果没有的话，就再重新创建 Executor 执行器执行 SQL 语句，注意， list = doQuery 是真正执行 SQL 语句的过程，这个过程中会创建我们上面提到的三种执行器，这里我们使用的是简单执行器。 到这里，执行器所做的工作就完事了，Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler StatementHandler 的继承结构 有没有感觉和 Executor 的继承体系很相似呢？最顶级接口是四大组件对象，分别有两个实现类 BaseStatementHandler 和 RoutingStatementHandler，BaseStatementHandler 有三个实现类, 他们分别是 SimpleStatementHandler、PreparedStatementHandler 和 CallableStatementHandler。 RoutingStatementHandler : RoutingStatementHandler 并没有对 Statement 对象进行使用，只是根据StatementType 来创建一个代理，代理的就是对应Handler的三种实现类。在MyBatis工作时,使用的StatementHandler 接口对象实际上就是 RoutingStatementHandler 对象。 BaseStatementHandler : 是 StatementHandler 接口的另一个实现类，它本身是一个抽象类，用于简化StatementHandler 接口实现的难度，属于适配器设计模式体现，它主要有三个实现类 SimpleStatementHandler: 管理 Statement 对象并向数据库中推送不需要预编译的SQL语句。PreparedStatementHandler: 管理 Statement 对象并向数据中推送需要预编译的SQL语句。CallableStatementHandler：管理 Statement 对象并调用数据库中的存储过程。 StatementHandler 的创建和源码分析 我们继续来分析上面 query 的调用链路，StatementHandler 的创建过程如下 MyBatis 会根据 SQL 语句的类型进行对应 StatementHandler 的创建。我们以预处理 StatementHandler 为例来讲解一下 执行器不仅掌管着 StatementHandler 的创建，还掌管着创建 Statement 对象，设置参数等，在创建完 PreparedStatement 之后，我们需要对参数进行处理了。 如 如果用一副图来表示一下这个执行流程的话我想是这样 这里我们先暂停一下，来认识一下第三个核心组件 ParameterHandler ParameterHandler - ParameterHandler 介绍 ParameterHandler 相比于其他的组件就简单很多了，ParameterHandler 译为参数处理器，负责为 PreparedStatement 的 sql 语句参数动态赋值，这个接口很简单只有两个方法 ParameterHandler 只有一个实现类 DefaultParameterHandler ， 它实现了这两个方法。 getParameterObject： 用于读取参数setParameters: 用于对 PreparedStatement 的参数赋值ParameterHandler 的解析过程 上面我们讨论过了 ParameterHandler 的创建过程，下面我们继续上面 parameterSize 流程 这就是具体参数的解析过程了，下面我们来描述一下 下面用一个流程图表示一下 ParameterHandler 的解析过程，以简单执行器为例 我们在完成 ParameterHandler 对 SQL 参数的预处理后，回到 SimpleExecutor 中的 doQuery 方法 上面又引出来了一个重要的组件那就是 ResultSetHandler，下面我们来认识一下这个组件 ResultSetHandler - ResultSetHandler 简介 ResultSetHandler 也是一个非常简单的接口 ResultSetHandler 是一个接口，它只有一个默认的实现类，像是 ParameterHandler 一样，它的默认实现类是DefaultResultSetHandler ResultSetHandler 解析过程 MyBatis 只有一个默认的实现类就是 DefaultResultSetHandler，DefaultResultSetHandler 主要负责处理两件事 处理 Statement 执行后产生的结果集，生成结果列表 处理存储过程执行后的输出参数 按照 Mapper 文件中配置的 ResultType 或 ResultMap 来封装成对应的对象，最后将封装的对象返回即可。 其中涉及的主要对象有： ResultSetWrapper : 结果集的包装器，主要针对结果集进行的一层包装，它的主要属性有 ResultSet : Java JDBC ResultSet 接口表示数据库查询的结果。 有关查询的文本显示了如何将查询结果作为java.sql.ResultSet 返回。 然后迭代此ResultSet以检查结果。 TypeHandlerRegistry: 类型注册器，TypeHandlerRegistry 在初始化的时候会把所有的 Java类型和类型转换器进行注册。 ColumnNames: 字段的名称，也就是查询操作需要返回的字段名称 ClassNames: 字段的类型名称，也就是 ColumnNames 每个字段名称的类型 JdbcTypes: JDBC 的类型，也就是 java.sql.Types 类型 ResultMap: 负责处理更复杂的映射关系 在 DefaultResultSetHandler 中处理完结果映射，并把上述结构返回给调用的客户端，从而执行完成一条完整的SQL语句。 内容转载自：CSDN博主：cxuann 原文链接：https://blog.csdn.net/qq_36894974/article/details/104132876?depth_1-utm_source=distribute.pc_feed.none-task&request_id=&utm_source=distribute.pc_feed.none-task

分布式事务的解决方案有如下几种： 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1：全局事务（DTP模型）全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色： AP：Application 应用系统 它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。 TM：Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成，它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器，通过它们提供的XA接口来同一调度这些资源管理器，以实现分布式事务。DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM：Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等。大部分场景下，数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力，它们通过XA接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范，RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件？DTP模型有啥优缺点？方案2：基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统，分别可以处理任务A和任务B。此时系统A中存在一个业务流程，需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前，首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后，便向系统A返回一个确认应答；系统A收到确认应答后，则可以开始处理任务A；任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失，从而消息中间件并不会向系统B投递这条消息，从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成，下文会介绍。消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。上述过程可以得出如下几个结论： 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后，到任务B执行完成之间，会存在一定的时间差。在这个时间差内，整个系统处于数据不一致的状态，但这短暂的不一致性是可以接受的，因为经过短暂的时间后，系统又可以保持数据一致性，满足BASE理论。 上述过程中，如果任务A处理失败，那么需要进入回滚流程，如下图所示： title 若系统A在处理任务A时失败，那么就会向消息中间件发送Rollback请求。和发送Commit请求一样，系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情。消息中间件收到回滚请求后，直接将该消息丢弃，而不投递给系统B，从而不会触发系统B的任务B。此时系统又处于一致性状态，因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况，但在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候，消息中间件是如何保证数据一致性呢？——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时，如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果： 提交 若获得的状态是“提交”，则将该消息投递给系统B。回滚 若获得的状态是“回滚”，则直接将条消息丢弃。处理中 若获得的状态是“处理中”，则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况，而且能降低上游系统的阻塞时间，上游系统只要发出Commit/Rollback指令后便可以处理其他任务，无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补，这样大大降低上游系统的阻塞时间，提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后，便可以处理其他任务了，此时它可以认为事务已经完成，接下来消息中间件一定会保证消息被下游系统成功消费掉！那么这是怎么做到的呢？这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕！ 如果消息在投递过程中丢失，或消息的确认应答在返回途中丢失，那么消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。当然，一般消息中间件可以设置消息重试的次数和时间间隔，比如：当第一次投递失败后，每隔五分钟重试一次，一共重试3次。如果重试3次之后仍然投递失败，那么这条消息就需要人工干预。 title title 有的同学可能要问：消息投递失败后为什么不回滚消息，而是不断尝试重新投递？ 这就涉及到整套分布式事务系统的实现成本问题。 我们知道，当系统A将向消息中间件发送Commit指令后，它便去做别的事情了。如果此时消息投递失败，需要回滚的话，就需要让系统A事先提供回滚接口，这无疑增加了额外的开发成本，业务系统的复杂度也将提高。对于一个业务系统的设计目标是，在保证性能的前提下，最大限度地降低系统复杂度，从而能够降低系统的运维成本。 不知大家是否发现，上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式，也就是当上游系统提交完消息后便可以去做别的事情，接下来提交、回滚就完全交给消息中间件来完成，并且完全信任消息中间件，认为它一定能正确地完成事务的提交或回滚。然而，消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后，它会阻塞等待，等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢？ 首先，上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道，用户体验尤为重要，因此这种异步通信方式能够极大程度地降低用户等待时间。此外，异步通信相对于同步通信而言，没有了长时间的阻塞等待，因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题，这就由消息中间件的超时询问机制来弥补。 那么，消息中间件和下游系统之间为什么要采用同步通信呢？ 异步能提升系统性能，但随之会增加系统复杂度；而同步虽然降低系统并发度，但实现成本较低。因此，在对并发度要求不是很高的情况下，或者服务器资源较为充裕的情况下，我们可以选择同步来降低系统的复杂度。 我们知道，消息中间件是一个独立于业务系统的第三方中间件，它不和任何业务系统产生直接的耦合，它也不和用户产生直接的关联，它一般部署在独立的服务器集群上，具有良好的可扩展性，所以不必太过于担心它的性能，如果处理速度无法满足我们的要求，可以增加机器来解决。而且，即使消息中间件处理速度有一定的延迟那也是可以接受的，因为前面所介绍的BASE理论就告诉我们了，我们追求的是最终一致性，而非实时一致性，因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3：最大努力通知（定期校对）最大努力通知也被称为定期校对，其实在方案二中已经包含，这里再单独介绍，主要是为了知识体系的完整性。这种方案也需要消息中间件的参与，其过程如下： title 上游系统在完成任务后，向消息中间件同步地发送一条消息，确保消息中间件成功持久化这条消息，然后上游系统可以去做别的事情了；消息中间件收到消息后负责将该消息同步投递给相应的下游系统，并触发下游系统的任务执行；当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该条消息删除，从而该事务完成。上面是一个理想化的过程，但在实际场景中，往往会出现如下几种意外情况： 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况，消息中间件具有重试机制，我们可以在消息中间件中设置消息的重试次数和重试时间间隔，对于网络不稳定导致的消息投递失败的情况，往往重试几次后消息便可以成功投递，如果超过了重试的上限仍然投递失败，那么消息中间件不再投递该消息，而是记录在失败消息表中，消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败消息，并将其消费，这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题，往往是因为下游系统出现了严重的错误，此时就需要人工干预。 对于第二种情况，需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表，并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败，那么就会触发回滚，之前的任务处理结果就会被取消。如果这量步都执行成功，那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息，如果发送失败它会返回重试。当然，也要给消息发送者设置重试的上限，一般而言，达到重试上限仍然发送失败，那就意味着消息中间件出现严重的问题，此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件，如果要实现分布式事务的话，就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务，但相比于第二种方案，它达到数据一致性的周期较长，而且还需要在上游系统中实现消息重试发布机制，以确保消息成功发布给消息中间件，这无疑增加了业务系统的开发成本，使得业务系统不够纯粹，并且这些额外的业务逻辑无疑会占用业务系统的硬件资源，从而影响性能。 因此，尽量选择支持事务型消息的消息中间件来实现分布式事务，如RocketMQ。 方案4：TCC（两阶段型、补偿型）TCC即为Try Confirm Cancel，它属于补偿型分布式事务。顾名思义，TCC实现分布式事务一共有三个步骤： Try：尝试待执行的业务 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源Confirm：执行业务 这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。Cancel：取消执行的业务 若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包，并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水，并将流水的状态设为交易中将用户A的账户中扣除100元（预留业务资源）Try成功之后，便进入Confirm阶段Try过程发生任何异常，均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常，均进入Cancel阶段Confirm过程执行成功，则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中，业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储，其处理是由业务系统负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责。二者没有太多交互的地方，所以，传统事务管理器的事务处理逻辑，仅需要着眼于事务完成（commit/rollback）阶段，而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的， 其Try/Confirm/Cancel业务在执行时，会访问资源管理器（Resource Manager，下文简称RM）来存取数据。这些存取操作，必须要参与RM本地事务，以使其更改的数据要么都commit，要么都rollback。 这一点不难理解，考虑一下如下场景： title 假设图中的服务B没有基于RM本地事务（以RDBS为例，可通过设置auto-commit为true来模拟），那么一旦[B:Try]操作中途执行失败，TCC事务框架后续决定回滚全局事务时，该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB：假设[B:Try]业务有5个写库操作，[B:Cancel]业务则需要逐个判断这5个操作是否生效，并将生效的操作执行反向操作。 不幸的是，由于[B:Cancel]业务也有n（0<=n<=5）个反向的写库操作，此时一旦[B:Cancel]也中途出错，则后续的[B:Cancel]执行任务更加繁重。因为，相比第一次[B:Cancel]操作，后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n（0<=n<=5）个写库中哪几个已经执行、哪几个还没有执行，这就涉及到了幂等性问题。而对幂等性的保障，又很可能还需要涉及额外的写库操作，该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知，如果不基于RM本地事务，TCC事务框架是无法有效的管理TCC全局事务的。 反之，基于RM本地事务的TCC事务，这种情况则会很容易处理：[B:Try]操作中途执行失败，TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时，在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下，根本无需执行[B:Cancel]操作。 换句话说，基于RM本地事务实现TCC事务框架时，一个TCC型服务的cancel业务要么执行，要么不执行，不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为，服务的幂等性，是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求，二者具有相同的副作用。 在TCC事务模型中，Confirm/Cancel业务可能会被重复调用，其原因很多。比如，全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时，可能会出现如网络中断的故障而使得全局事务不能完成。因此，故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务，这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用，就需要保障其幂等性。 那么，应该由TCC事务框架来提供幂等性保障？还是应该由业务系统自行来保障幂等性呢？ 个人认为，应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话，那么由业务系统来负责也是可以的；然而，这是一类公共问题，毫无疑问，所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决；而且，考虑一下由业务系统来负责幂等性需要考虑的问题，就会发现，这无疑增大了业务系统的复杂度。

你好，这里有208份资料，详情请参考：https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字，短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库，也是Google的作品。其中介绍了很多一致性方面的设计考虑，为了简单的逻辑设计，还采用了原子钟，同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁，Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的，所以Chubby实际上是Google分布式事务的基础，具有非常高的参考价值。另外，著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper，阐述了一种构建分布式文件系统的范式方法，个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文，此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页，这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori：A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文：设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程，如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例，主要面向大文件和批处理系统， 设计简单而实用。 GFS是google的重要基础设施， 大数据的基石， 也是Hadoop HDFS的参考对象。 主要技术特点包括： 假设硬件故障是常态（容错能力强）， 64MB大块， 单Master设计，Lease/链式复制， 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表， 在google内部应用广泛，大数据的奠基作品之一 ， Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括： 基于GFS实现数据高可靠， 使用非原地更新技术（LSM树）实现数据修改， 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议， 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题， 能加深对主从强一致复制的理解程度。 技术特点： 支持强一致主从复制协议， 允许多种存储实现， 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法， 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储，还支持表格、队列等数据模型. 主要技术特点：采用Stream/Partition两层设计（类似BigTable）;写错（写满）就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用， 是理解Paxo协议及其应用场景的必备论文。 主要技术特点： paxo协议， replicated log， multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点：综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统， 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学，自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念，以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小，但半死不活（网络/磁盘），对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的，其中有两个视频链接，分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书（ The Architecture of Open Source Applications）的源代码附录，是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页，没有上课的视频，但是并不影响你跟着它上课：每一周读两篇课程指定的论文，读完之后看lecture-notes里对该论文内容的讨论，回答里面的问题来加深理解，最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后，你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单，逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍：事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法，Lamport在2001发表了《Paxos Made Simple》，以更平直的口头语言描述了Paxos，而没有包含正式的证明和数学术语。《Paxos Made Simple》中，将算法的参与者更细致的划分成了几个角色：Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍：PaxosLease：实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍：Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍：Hadoop学习清单. 《Hadoop Reading List》介绍：Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍：NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍：Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍：Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍：理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍：经典论文 《Programming Languages for Parallel Processing》介绍：并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍：此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍：分布式文件系统综述 《Concepts of Concurrent Programming》介绍：并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍：并发控制性能建模：选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍：ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍：分布式系统设计的形式方法 《互斥和选举算法》介绍：互斥和选举算法 《Actors：A model Of Concurrent Cornputation In Distributed Systems》介绍：经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍：如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍：卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍：Dapper，大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍：伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍：PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍：伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍：MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍：google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍：分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍：分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍：是著名的Ceph的负载平衡策略，文中提出的几种策略都值得尝试，比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍：Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍：对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍：服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍：分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍：加利福尼亚大学的研究生操作系统课程主页，论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍：Yahoo出品的流式计算系统，目前最流行的两大流式计算系统之一（另一个是storm），Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍：Google的大规模图计算系统，相当长一段时间是Google PageRank的主要计算系统，对开源的影响也很大（包括GraphLab和GraphChi） 《GraphLab: A New Framework for Parallel Machine Learning》介绍：CMU基于图计算的分布式机器学习框架，目前已经成立了专门的商业公司，在分布式机器学习上很有两把刷子，其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟； 《F1: A Distributed SQL Database That Scales》介绍：这篇论文是Google 2013年发表的，介绍了F1的架构思路，13年时就开始支撑Google的AdWords业务，另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍：CockroachDB ：一个可伸缩的、跨地域复制的，且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍：Multi-Paxos实现与总结，此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example，地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍：一致性协议zab分析 《A Distributed Hash Table》介绍：分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍：分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍：分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍：闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍：微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍：虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍：Linux B-tree文件系统. 《Akamai technical publication》介绍：Akamai是全球最大的云计算机平台之一，承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文，先看论文领会思想，然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍：来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍：Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”，这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中，作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”，特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”： “对于某个应用来说，无论它的部署环境如何，总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关，在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍：分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍：Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍：SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源（可下载） 《Anatomy of a database system》介绍:数据库系统剖析，这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程（Concurrency Programming）资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议，我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文，面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers（updated Spring 2015）列举出来，可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的，然后通过Google找到了这一篇关于缓存策略的论文，它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透，分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识？》介绍:[怎么学系列]学习分布式系统需要怎样的知识？ 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组，他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录，但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文，涉及分布式系统设计，性能分析，实践，优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文，学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.