Lanyon

谈谈我所了解的前端技术的发展

2025-04-22T00:00:00+00:00

为什么会突然提到这个话题？

最近看到一个很好看的小程序前端模版nxdc-milktea，展示效果如下图所示，想着看把程序跑起来。看了前端代码仓库中有App.vue，我理解应该是基于vue开发的项目，但此项目没有package.json，按vue的方式启动不了。

也给作者留过言”服务如何运行起来？”，因为项目开发的时间很久了，作者目前暂未答复。模版也作为插件发布在了DCloud的uni-app插件市场，看了uni-app的官方文档，一切都变得豁然开朗。首先需求下载hbuilderx插件，然后导入插件的内容，在左上角点击发行->小程序(微信)，会将导出的代码导入微信开发工具，如下图所示。

小程序代码导入微信开发工具后的样子，左边是模拟器，右边是代码区。看起来有种开发ios或android app的感觉，相比而言，理解开发小程序的门槛能低一些。

什么是`uni-app`?

简单来说，uni-app我理解是一种移动端通用的开发框架，像做移动端应用时，基于uni-app只需开发一版，然后就可以导出针对不同平台的安装包，例如：安卓、ios、鸿蒙、微信小程序、支付宝小程序、京东小程序等，具体可以看uni-app的官方文档。

有一件有意思的事情，在19年时，公司安排组内同事去上海某大型国有银行出差支持，在上海呆了1个多月。在那边主要做应用后端，前台是一个数据探查的app，是基于uni-app开发，1个前端、2个后端差不多一个多左右完成开发上线。同时期，也有友商在现场开发类似应用，好几个android开发，一个月的开发速度惊讶到对方了，跑过来问同事，你们是怎么做的，怎么那么快😂？

还想挖同事过去，后来也是从同事那边知道这个事情，我想了下，肯定写安卓组件比写html慢，并且要同时适配安卓和ios，应该是这个原因。

uni-app使用的是vue的语法，不是小程序自定义的语法，DCloud与vue合作，在vue.js官网提供了免费视频教程https://learning.dcloud.io/#/ 。

了解下`vue.js`的语法

vue.js文档地址https://v2.cn.vuejs.org/v2/guide/，和其它js库一样，在页面中引入vue.js也是通过<script>标签引入的。

<!-- html中引入vue.js, 生产环境版本，优化了尺寸和速度 -->
<script src="https://cdn.jsdelivr.net/npm/vue@2"></script>

第一个Vue应用，引入vue.js后，在当前页面就回有一个Vue对象来绑定页面属性，其属性el就是页面选择器，选择了id=app的div，dom中的message就是取的Vue#data中的元素。

<!-- v-bind动态给class绑定变量，当前div是绑定color颜色; @click.stop能阻止事件向上传播 -->
<div id="app" v-bind:class="color" @click.stop="click">
  <!-- 两个大括号要连接起来，模版插值语法，加入v-once后，message属性更新后不会再刷新到页面 -->
  <span v-once>Message: { { message }}</span>
  <!-- v-html会将变量的值 直接以html展示 -->
  <p>using v-html directive: <span v-html="rawHtml"></span></p>
  <!-- vue中的条件渲染，v-if会根据seen变量的值 来决定是否展示元素内容(为true时展示)，v-bind绑定元素内容 -->
  <span v-if="seen">你现在看到我了</span>
  <span v-else>Oh no 😂</span>
  <!-- vue中的列表渲染，v-for语法展示list中的元素，Foo和Bar元素各生成一个li元素 -->
  <ul>
    <li v-for="item in items">
        { {item.message}}
    </li>
  </ul>
  <!-- v-on指令监听DOM事件，counter监听click事件，每多点击一次click，counter的值就会加1 -->
  <button v-on:click="counter +=1">Add 1</button>
</div>

var vm = new Vue({
  el: '#app',
  data: {
    message: 'Hello Vue!',
    a: "normal value",
    rawHtml: '<span style="color:red">this is should be red</span>',
    color: 'red',
    seen: true,
    elems: [
      {message: 'Foo'},
      {message: 'Bar'}
    ],
    counter: 0
  },
  method: {
    click: function() {console.log("click element!")}
  }
})
// 可通$访问vue暴露的属性和方法，另一种vm.$watch('a', func(newValue, oldValue){xxx}) ，观察到a变化时，会触发回调用函数
vm.$data.message = "Change Value!"

.red {color:red;}
.blue {color:blue;font-size:100px;}

浅谈nginx服务代理

2025-04-07T00:00:00+00:00

`nginx`用`docker`安装

nginx服务安装，我是用docker安装的，mac系统编译nginx源码安装有点问题。

docker pull nginx # 从docker仓库拉取nginx镜像
# nginx目录挂载参考此文章，https://blog.csdn.net/baidu_21349635/article/details/102738972
docker run --name nginx-0807 -v /Users/madong/software/nginx/nginx.conf:/etc/nginx/nginx.conf \
-v /Users/madong/software/nginx/conf.d:/etc/nginx/conf.d \
-v /Users/madong/software/nginx/html:/usr/share/nginx/html \
-v /Users/madong/software/nginx/logs:/var/log/nginx -p 8080:80 -d nginx
# nginx服务验证，curl有返回html内容时，则表示nginx服务启动成功了； /etc/nginx存nginx配置、/usr/share/nginx存在html、/var/log/nginx/存放nginx的access_log
curl 'http://localhost:8080/'

nginx也支持热更新，当修改nginx配置后，可使用nginx -s reload使修改的配置生效，当access.log文件特别大时，可使用nginx -s reopen切割日志。

`nginx`用源码安装

使用nginx源码包安装，用docker nginx有个明显的问题，那就是nginx.conf中listen不同端口时，容器内端口向外映射很麻烦，所以用源代码装。步骤可分为以下4步：

从nginx官网下载stable version源码，https://nginx.org/en/download.html；
由于nginx有c的代码，所以需下载pcre、openssl和zlib工具，具体可参考文章：https://blog.csdn.net/a1004084857/article/details/128512612；

解压nginx zip包，进入解压路径，对nginx进行配置，--prefix指定编译后的nginx二进制文件存放目录，--with-pcre|zlib|openssl分别为工具的解压逻辑；

./configure --prefix=/Users/madong/software/c_nginx_1.28.0 \
  --with-http_ssl_module \
  --with-pcre=./compile/pcre-8.45 \
  --with-zlib=./compile/zlib-1.3.1 \
  --with-openssl=./compile//openssl-3.0.7

配置完成后，执行make install，则编译后的nginx就会出现在/Users/madong/software/c_nginx_1.28.0这个目录中；

`nginx`搭建一个静态资源web服务器

nginx源码编译后，会生成conf、html、logs、sbin这几个目录，其分别是：nginx配置、html默认页面、access_log、启动脚本等，启动nginx的脚本：./sbin/nginx。

下方的内容是nginx.cnf配置的一部分，在nginx的安装目录下放了neo4j文档，在线文档对应路径为neo4j。配置解释，nginx监听8093端口，location /表示请求url为ip:8093:/时，进入此配置代码块。

server {
    listen       8093;
    location / {
        # autoindex on;
        alias   neo4j/;
        # set $limit_rate 1k; #限制nginx向浏览器发送流量的速度
        # root   html;
        # index nothing; # 禁用inde文件
        index  index.html index.htm;
    }
}

代码配置中有root和alias两个指令，建议用alias(一般用root配根目录，用alias配置一般的路径)，打开浏览器，输入http://127.0.0.1:8093/ 就可以访问到静态资源文档，如果想限制浏览器下载资源速度，可设置set $limit_rate 1k;。

若想将文件目录设置成资源服务器，在配置中打开autoindex on;和index nothing;，需注释index index.html index.htm;，因为即使配置了目录检索，当目录下存在index.html时，默认也是打开index.html。

提升浏览器获取静态资源的速度，在nginx.conf中打开gzip on;，同时也可指定gzip_min_length、gzip_comp_level、gzip_types内容，对静态资源使用gzip进行压缩。

`GoAccess`实时监控`nginx`访问

在nginx的logs目录中有请求访问的日志，在location中的配置，首先log_format定义了访问日志的格式，在server中定义了access_log的路径以及应用的格式。

# nginx log日志的格式
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';
server {
    # ...
    access_log  logs/neo4jdoc.access.log  main;
}

从GoAccess网站下载安装包，很奇怪，C相关的应用下载都是源码包，没有针对于特定系统的二进制包，还需安装依赖包libmaxminddb，否则安装时会报错** Missing development files for libmaxminddb library。

从https://github.com/maxmind/libmaxminddb 下载安装包，在本地环境解压，进入到libmaxminddb目录，执行./configure然后执行make install进行安装。然后进入GoAccess安装包的解压目录，执行：./configure --enable-utf8 --enable-geoip=mmdb、make install指令进行安装。

进入nginx的logs目录，执行实时监控命令，生成report.html，同时在nginx.conf配置report.html的路由，以便在浏览器中访问监控页面。

LANG="en_US.UTF-8" LC_TIME="en_US.UTF-8" bash -c 'goaccess neo4jdoc.access.log -o ../html/report.html --real-time-html --log-format=COMBINED'

server {
    #... 对外暴露report.html页面
    location /report.html {
      alias /Users/madong/software/c_nginx_1.28.0/html/report.html;
    }
}

在浏览器中输入http://127.0.0.1:8093/report.html 即可以看到监控页面，有一点，在html页面上一开始可能会展示unauthorized，等过一会儿web socket就能建立成功，就可以展示页面上的指标，例如：请求命中数、请求文件url统计、静态请求数、404的url统计等。

`nginx`常用指令

listen指令，一个请求进入nginx之前，首先要监听端口，会用到listen指令，指令的语法有：listen address[:port]、listen port。

listen *:8000;  # 监听机器上的8000端口，访问ip不限制
listen 127.0.0.1:8000;  # 限制ip为127。0.0.1
listen unix:/var/run/nginx.sock;  # 监听unix的websocket

server_name指令，此指令后面跟多个域名时，第一个域名为主域名，有个默认配置server_name_in_redirect off（默认关闭）。在打开配置时，当需要重定向请求，但未指定域名时，则会使用主域名。
```
server_name taohui.tech tech.nginx;  # 第一个为主域名
server_name *.taohui.tech;  # 泛域名，仅支持在最前或最后
```

return和error_page指令，语法格式为：return code [text|URL]，error_page指令是对错误页面的重定向，例如403转发到未授权页面。

return 301 url; # 301表示永久重定向，302临时重定向，禁止被缓存
error_page 404 /404.html;
error_page 403 http://example.com/forbidden.html;

location指令，此指令常用于寻找配置，语法为：location url|@name支持=精确匹配和正则表达式（^）匹配路径，当没有等号时，则应用前缀匹配原则（最长匹配）。

location = /Test1 { # 精确匹配
  return 200 'exact match'!;
}
location /Test1 {  # 前缀匹配，同时满足时，优先精确匹配
  return 200 'prefix string match!';
}
location ^~/Test1/ { # 正则表达式匹配
  return 200 'regular expression match!';
}

access阶段指令，其中包含allow和deny，上下文作用于http、server、context，表示允许或禁止某些指令访问。
```
deny 192.168.1.1;
allow 192.168.1.0/24;
```

content阶段的指令，root和alias指令，它们之间的区别：root会将完整url映射进文件路径中（root路径+location路径），alias之后将location后的url路径映射到文件路径。

location /root { # curl请求http://127.0.0.1:8093/root时，对应静态资源路径为：html/root/index.html
  root html;
}
location /alias { # curl请求http://127.0.0.1:8093/alias时，对应静态资源路径为：html/index.html
  alias html;
}

Go内存分配与GC

2025-03-28T00:00:00+00:00

Go语言GMP介绍

Go语言相比Java，有更好的并发能力（GMP模型），同时其占用的服务器资源也较少，了解一下GMP的理念。从操作系统层面来看，线程是指内核级线程，是操作系统最小调度单元，创建、销毁、调度交由内核完成，可充分利用多核。协程（用户线程）与线程存在M:1的映射关系，从属于同一个内存级线程，无法并行，并且，一个协程阻塞会导致从属同一线程的所有协程无法执行。

Goroutine

经Golang优化后的协程，其有如下特点：1）与线程存在映射关系，为M:N；2）创建、销毁、调度在用户态完成，对内核透明，足够轻便；3）可利用多个线程，实现并行；4）通过调度器的斡旋，实现和线程间的动态绑定和灵活调度；5）栈空间大小可动态扩缩，因地制宜；

在/runtime/proc.go的代码注释中，有对GMP的解释，其核心数据结构在/runtime/runtime2.go:

其中g是Golang中对协程的抽象，g有自己的运行栈，状态及执行的任务函数，g需要绑定到p上才能执行，p就是g的cpu；
m即machine，是golang中对线程的抽象，m不直接执行g，而是先和p绑定，由其代理执行；借由p的存在，m无需和g绑死，也无需记录g的状态信息，因此g在全生命周期中可以跨m执行。
p也即processor，是golang中的调度器。对于g而言，p是其调度器，g只有被p调度，才得以执行；对m而言，p是其执行代理，为其提供必要信息的同时，隐藏了繁杂的调度细节；

// Goroutine scheduler, Design doc at https://golang.org/s/go11sched.
// The scheduler's job is to distribute ready-to-run goroutines over worker threads.
//
// The main concepts are:
// G - goroutine.
// M - worker thread, or machine.
// P - processor, a resource that is required to execute Go code.
//     M must have an associated P to execute Go code, however it can be
//     blocked or in a syscall w/o an associated P.

gmp模型其要点和调度规则如下：

M是线程的抽象；G是goroutine；P是承上启下的调度器；M调度G前，需要和P绑定；
全局有多个M和多个P，但同时并行的G的最大数量等于P的数量；
G的存放队列有三类：P的本地队列、全局队列和wait队列（图中未展示，为io阻塞就绪态goroutine队列）；
M调度G时，优先取P本地队列，其次取全局队列，最后取wait队列；这样的好处是，取本地队列时，可以接近于无锁化，减少全局锁竞争；
为防止不同P的闲忙差异过大，设立work-stealing机制，本地队列为空的P可以尝试从其他P本地队列偷取一半的G补充到自身队列;

GMP调度

g0是一种特殊的调度协程，不执行用户函数，负责执行g之间的切换调度，与m的关系为1:1。goroutine的类型可分为两类：

1）负责调度普通g的g0，与m的关系为一对一；
2）负责执行用户函数的普通g，被调度执行的g永远在g和g0的状态间切换；

当g0找到可执行g时，会调用gogo方法，调度g执行用户定义的任务。当g需要主动让渡时，会触发mcall方法，将执行权限重新交给g0；

广义”调度”可分为几种类型：

主动调度：一种用户主动执行让渡过程，主要方式是在代码中执行runtime.Gosched方法(runtime/proc.go)，此时当前g会当让出执行权，主动进行队列等待下次被调度执行。
被动调度：因不满足某执行条件，g可能陷入阻塞态无法被调度，直到关注的条件达成后，g才从阻塞中被唤醒(对应runtime/proc.go#gopark方法，恢复则是goready方法)。
正常调度: g中的执行任务已完成，g0会将当前g置为死亡状态，发起新一轮调度；
抢占调度：倘若g执行系统调用超过指定的时长，且全局p资源比较短缺，此时将p和g接绑，用解绑的p用于其他g的调度；

值得一提的是，前3种调度方式都由m下的g0完成。而抢占调用则是由一个全局监控协程monitor g来监控，倘若发现满足抢占调度的条件，则会从第三方的角度出手干预，主动发起该动作。从宏观上：

以g0 -> g -> g0 的一轮循环为例进行串联；
g0 执行 schedule() 函数，寻找到用于执行的 g；
g0 执行 execute() 方法，更新当前 g、p 的状态信息，并调用gogo()方法，将执行权交给g；
g 因主动让渡(gosche_m())、被动调度(park_m())、正常结束(goexit0())等原因，调用m_call函数，执行权重新回到g0手中；
g0执行schedule()函数，开启新一轮循环.

p每执行61次，会从全局队列中获取一个goroutine进行执行，同时会额外将全局队列中的一个goroutine放到本地队列中。若本地队列已满，则会返回来将本地队列中一半的g放回全局队列中，帮助当前p缓解执行压力;

Go内存模型与分配机制

在操作系统中，存在寄存器、高速缓存、内存和磁盘，越接近cpu存储的容量越小，其对应的价格就越高昂。页表、分页管理等机制来减少内存碎片。

Golang中的内存模型，以空间换时间，一次缓存，多次复用。堆mheap正是基于该思想，产生的数据结构。依次细化粒度，建立了 mcentral、mcache 的模型，下面对三者作个梳理：

mheap：全局的内存起源，访问要加全局锁；
mcentral：每种对象大小规格（全局共划分为68种）对应的缓存，锁的粒度也仅限于同一种规格以内；
mcache：每个P（正是GMP中的P）持有一份的内存缓存，访问时无锁，多级规格，提高利用率；

内存单元`mspan`

page和mspan的2个概念，page：最小的存储单元，默认大小为8KB，mspan大小为page的整数倍，且从8B到80KB 被划分为67种不同的规格，对应源代码在runtime/sizeclasses.go，mspan具有如下特点：

根据规格大小，产生了等级的制度，mspan是Golang内存管理的最小单元，runtime/mheap.go；
消除了外部碎片，但不可避免会有内部碎片；
宏观上能提高整体空间利用率，同等级的mspan会从属同一个mcentral，最终会被组织成链表，因此带有前后指针（prev、next）；
正是因为有了规格等级的概念，才支持mcentral实现细锁化，全局总览，留个印象；
mspan会基于bitMap辅助快速找到空闲内存块（块大小为对应等级下的object大小），此时需要使用到Ctz64算法.

线程缓存`mcache`

mcache是每个P独有的缓存，因此交互无锁；
mcache将每种spanClass等级的mspan各缓存了一个，总数为2（nocan维度） * 68（大小维度）= 136;
mcache中还有一个为对象分配器tiny allocator，用于处理小于16B对象的内存分配；

中心缓存`mcentral`

要点:

每个mcentral对应一种spanClass；
每个mcentral下聚合了该spanClass下的mspan;
mcentral下的mspan分为两个链表，分别为有空间mspan链表partial和满空间mspan链表full`;
每个mcentral一把锁;

全局堆缓存`mheap`

对于Golang上层应用而言，堆是操作系统虚拟内存的抽象，以页（8KB）为单位，作为最小内存存储单元；
负责将连续页组装成mspan，全局内存基于bitMap标识其使用情况，每个bit对应一页，为0则自由，为1则已被mspan组装；
通过heapArena聚合页，记录了页到mspan的映射信息，建立空闲页基数树索引radix tree index，辅助快速寻找空闲页；
是mcentral的持有者，持有所有spanClass下的mcentral，作为自身的缓存，内存不够时，向操作系统申请，申请单位为 heapArena（64M）；

对象分配流程

不论是以下哪种方式，最终都会殊途同归步入mallocgc方法中，例如：new(T)、&T{}、make(xxxx)，Golang中，依据object的大小，会将其分为下述三类：tiny微对象(0, 16B)、small小对象(16B，32KB)、large大对象(32KB，正无穷). 对于微对象的分配流程：

从P专属mcache的tiny分配器取内存（无锁）
根据所属的spanClass，从P专属mcache缓存的mspan中取内存（无锁）
根据所属的spanClass从对应的mcentral中取mspan填充到mcache，然后从mspan中取内存（spanClass粒度锁）；
根据所属的spanClass，从mheap的页分配器pageAlloc取得足够数量空闲页组装成mspan填充到mcache，然后从mspan中取内存（全局锁）；
mheap`向操作系统申请内存，更新页分配器的索引信息，然后重复（4）；

对于小对象的分配流程是跳过（1）步，执行上述流程的（2）-（5）步；对于大对象的分配流程是跳过（1）-（3）步，执行上述流程的（4）-（5）步.

Go垃圾回收原理

做Java的都对GC比较熟悉，在JVM中常见的GC算法有：标记整理（Mark-Sweep）、标记压缩（Mark-Compact）、半空间复制（类似于G1），通过引用计数寻找不可达对象，便于垃圾回收。

`Go`中三色标记法

Golang GC中用到的三色标记法属于标记清扫-算法下的一种实现，由荷兰的计算机科学家Dijkstra提出，下面阐述要点：

对象分为三种颜色标记：黑、灰、白，黑对象代表，对象自身存活，且其指向对象都已标记完成；
灰对象代表，对象自身存活，但其指向对象还未标记完成；白对象代表，对象尙未被标记到，可能是垃圾对象
标记开始前，将根对象（全局对象、栈上局部变量等）置黑，将其所指向的对象置灰；
标记规则是，从灰对象出发，将其所指向的对象都置灰. 所有指向对象都置灰后，当前灰对象置黑；
标记结束后，白色对象就是不可达的垃圾对象，需要进行清扫；

为了应对并发情况下，对象标记出现漏标、多标的情况，可使用屏障机制。漏标问题的本质就是，一个已经扫描完成的黑对象指向了一个被灰\白对象删除引用的白色对象. 一套用于解决漏标问题的方法论称之为强弱三色不变式：

强三色不变式：白色对象不能被黑色对象直接引用;
弱三色不变式：白色对象可以被黑色对象引用，但要从某个灰对象出发仍然可达该白对象（间接破坏了（1）、（2）的联动）；

golang sql体系及orm实现

2025-03-22T00:00:00+00:00

golang sql标准库研究

抽象接口定义

database/sql/driver/driver.go关于数据库驱动模块下各核心interface主要包括：

Connector: 抽象的数据库连接器，需要具备创建数据库连接以及返回从属的数据库驱动的能力;
Driver: 抽象的数据库驱动，具备创建数据库连接的能力;
Conn: 抽象的数据库连接，具备预处理sql以及开启事务的能力;
Tx: 抽象的事务，具备提交和回滚的能力;
Statement: 抽象的请求预处理状态. 具备实际执行sql并返回执行结果的能力；
Result/Row: 抽象的sql执行结果；

在database/sql/sql.go中定义的几个核心实体类. 核心内容主要是对于数据库连接池的实现以及对第三方数据库驱动能力的再封装.

DB: 对应为数据库的具象化实例，其中包含如下几个核心字段：connector(用于创建数据库连接的抽象连接器，由第三方数据库提供具体实现)、mu、freeConn、connRequests等。
driverConn: 其核心属性是由第三方驱动实现的driver.Conn，在此之上添加了时间属性、回调函数、状态标识等辅助信息；
driverStmt: 在抽象的driver.Stmt基础上，添加了互斥锁、关闭状态标识等信息；
Tx: 在抽象的driver.TX基础上，额外添加了互斥锁、数据库连接、连接释放函数、上下文等辅助属性；

创建数据库

沿着sql.Open方法向下追溯，查看一下创建数据库实例的流程细节：

首先校验对应的 driver 是否已注册；
接下来调用OpenDB方法执行真正的db实例创建操作，方法中会创建一个DB，启动一个connectionOpener协程，连接池资源不足时，用于补充创建连接;
在connectionOpener方法中，通过for + select多路复用的形式，保持协程的运行;

// 创建数据库
func Open(driverName, dataSourceName string) (*DB, error) {
    // 首先根据驱动类型获取数据库驱动, 导入mysql驱动时，会自动在drivers中注册，_ "github.com/go-sql-driver/mysql"
    driversMu.RLock()
    driveri, ok := drivers[driverName]
    driversMu.RUnlock()
    if !ok {
        return nil, fmt.Errorf("sql: unknown driver %q (forgotten import?)", driverName)
    }
    // 若驱动实现了对应的连接器 connector，则获取之并进行 db 实例创建
    if driverCtx, ok := driveri.(driver.DriverContext); ok {
        connector, err := driverCtx.OpenConnector(dataSourceName)
        if err != nil {
            return nil, err
        }
        return OpenDB(connector), nil
    }
    // 默认使用 dsn 数据库连接器，进行 db 创建
    return OpenDB(dsnConnector{dsn: dataSourceName, driver: driveri}), nil
}

执行请求

在执行一次db.Query()请求中，其中核心步骤包括：获取数据库连接(通过调用conn方法完成)，执行sql(通过调用queryDC方法完成)、归还/释放连接(通过在queryDC方法中调用releaseConn方法完成)；

const maxBadConnRetries = 2
// 执行查询类 sql
func (db *DB) QueryContext(ctx context.Context, query string, args ...any) (*Rows, error) {
    var rows *Rows
    var err error
    var isBadConn bool

    // 最多可以因为 BadConn 类型的错误重试两次
    for i := 0; i < maxBadConnRetries; i++ {
        // 执行 sql，此时采用的是 连接池有缓存连接优先复用 的策略
        rows, err = db.query(ctx, query, args, cachedOrNewConn)
        // 属于 badConn 类型的错误可以重试
        isBadConn = errors.Is(err, driver.ErrBadConn)
        if !isBadConn {
            break
        }
    }
    // 重试了两轮 badConn 错误后，第三轮会采用
    if isBadConn {
        return db.query(ctx, query, args, alwaysNewConn)
    }
    return rows, err
}

conn方法获取数据库连接：

倘若启用了连接池策略且连接池中有可用的连接，则会优先获取该连接进行返回；
倘若当前连接数已达上限，则会将当前协程挂起，建立对应的channel添加到connRequests map中，等待有连接释放时被唤醒；
倘若连接数未达上限，则会调用第三方驱动的connector完成新连接的创建；

归还数据库连接，使用完数据库连接后，需要尝试将其放还连接池中，入口方法为releaseConn；

func (dc *driverConn) releaseConn(err error) {
    dc.db.putConn(dc, err, true)
}

清理任务

接下来是cleaner协程的运行流程，整体是通过for + select的方式常驻运行. 其中，cleaner创建了一个定时器ticker，定时时间间隔会在maxIdleTime、maxLifeTime中取较小值，并基于秒级向上取整. 每一轮ticker触发后，会执行：

判断当前db是否已关闭或者存活连接数是否为零，是的话退出当前cleaner协程
调用connectionCleanerRunLocked对连接池中过期的连接进行清理

`mysql`驱动实现

go-sql-driver/mysql的核心功能是，遵循database/sql标准库中预留的接口协议，提供出对应于mysql的实现版本，将和mysql服务端的数据传输、通信协议，预处理模式、事务操作等内容封装实现在其中.

驱动加载，数据库驱动. mysql driver时，只需要匿名导入go-sql-driver/mysql的lib包，即可完成driver的注册操作。其原理是：会默认调用mysql包的init方法。

驱动类定义位于driver.go，名称为MySQLDriver，对应实现Open方法用于创建数据库连接，核心步骤包括：解析dsn，转为配置类实例、构造连接器实例、通过连接器完成连接创建操作；

import (
    // 注册 mysql 数据库驱动
    _ "github.com/go-sql-driver/mysql"
)

// mysql#driver.go, This variable can be replaced with -ldflags like below:
// go build "-ldflags=-X github.com/go-sql-driver/mysql.driverName=custom"
var driverName = "mysql"
func init() {
    if driverName != "" {
        sql.Register(driverName, &MySQLDriver{})
    }
}
// MySQL 版本的数据库驱动
type MySQLDriver struct{}

连接器的实现位于connecto.go，其需实现database/sql connector接口定义的Connect和Driver()方法：

type connector struct {
    cfg               *Config // immutable private copy.
    encodedAttributes string  // Encoded connection attributes.
}

// Connect implements driver.Connector interface.
// Connect returns a connection to the database.
func (c *connector) Connect(ctx context.Context) (driver.Conn, error) {
    // New mysqlConn
    mc := &mysqlConn{
        maxAllowedPacket: maxPacketSize,
        maxWriteSize:     maxPacketSize - 1,
        closech:          make(chan struct{}),
        cfg:              cfg,
        connector:        c,
	}
	// ...
}

// Driver implements driver.Connector interface.
// Driver returns &MySQLDriver{}.
func (c *connector) Driver() driver.Driver {
    return &MySQLDriver{}
}

Connect方法的实现主要包含如下几个核心步骤，与mysql连接配置有关的内容被聚合在dsn.go：

创建连接（net.Dialer.DialContext）、设置为tcp长连接（net.TCPConn.KeepAlive）、创建连接缓冲区（mc.buf = newBuffer）
设置连接超时配置（mc.buf.timeout = mc.cfg.ReadTimeout；mc.writeTimeout = mc.cfg.WriteTimeout）
接收来自服务端的握手请求（mc.readHandshakePacket）、向服务端发起鉴权请求（mc.writeHandshakeResponsePacket）
处理鉴权结果（mc.handleAuthResult）、设置dsn中的参数变量（mc.handleParams）

数据库连接接口，值得一提的是，在使用mysqlConn的过程中，在文件connection.go中，mysqlConn对外可以通过公开方法Close实现关闭：

type mysqlConn struct {
    // 缓冲区数据
    buf              buffer
    // 网络连接
    netConn          net.Conn
    rawConn          net.Conn    // underlying connection when netConn is TLS connection.
    result           mysqlResult // sql 执行结果
	// ...
}

func (mc *mysqlConn) Close() (err error) {
    // Makes Close idempotent
    if !mc.closed.Load() {
        err = mc.writeCommandPacket(comQuit)
    }
    mc.cleanup()
    return
}

下面是通过mysqlConn执行查询类请求的流程，对于query方法，入参中的query字段为sql模板，args字段为用于填充占位符的参数。

query方法的出参类型为textRows，其首先会读取响应报文中第一部分，填充各个列的信息，后续内容会保留在内置的conn中，通过使用方调用rows的Next方法时再进行读取操作.

func (mc *mysqlConn) Query(query string, args []driver.Value) (driver.Rows, error) {
    return mc.query(query, args)
}

func (mc *mysqlConn) query(query string, args []driver.Value) (*textRows, error) {
    handleOk := mc.clearResult()
    // 连接已关闭？
    if mc.closed.Load() {
        mc.cfg.Logger.Print(ErrInvalidConn)
        return nil, driver.ErrBadConn
    }
	// ...
}

sql预处理，go-sql-driver/mysql 库实现的statement类如下，对应的代码位于statement.go文件中，prepare statement是通过调用mysqlConn的prepare方法开启的，对应流程及源码如下：

type mysqlStmt struct {
    // 关联的 mysql 连接
    mc         *mysqlConn
    // 预处理语句的标识 id
    id         uint32
    // 预处理状态中多少待填充参数
    paramCount int
}

`gorm`框架原理分析

gorm框架通过一个gorm.DB实例来指代我们所操作的数据库. 使用gorm的第一步就是要通过Open方法创建出一个gorm.DB实例，其中首个入参为连接器dialector，本身是个抽象的interface，其实现类关联了具体数据库类型.

import (
    "gorm.io/driver/mysql"
    "gorm.io/gorm"
)
var (
    dsn := "root:123456@tcp(127.0.0.1:3306)/douban_datahub?charset=utf8mb4&parseTime=True&loc=Local"
    db *gorm.DB
    dbOnce sync.Once
)
func getDB() (*gorm.DB, error) {
    var err error
    dbOnce.Do(func(){
        // 创建 db 实例
        db, err = gorm.Open(mysql.Open(dsn),&gorm.Config{})
    })
    return db,err
}

创建gorm.DB实例流程，gorm.Open方法是创建DB实例的入口方法，其中包含如下几项核心步骤：

完成gorm.Config配置的创建和注入,完成连接器dialector的注入，本篇使用的是mysql版本；
完成callbacks中crud等几类processor的创建 (通过initializeCallbacks(...) 方法 )
完成connPool的创建以及各类processor fns函数的注册（通过dialector.Initialize(...)方法）
倘若启用了prepare模式，需要使用preparedStmtDB进行connPool的平替，构造statement实例

根据策略，决定是否通过ping请求测试连接，返回创建好的db实例；

// Open initialize db session based on dialector
func Open(dialector Dialector, opts ...Option) (db *DB, err error) {
  config := &Config{}
  // ...
  if config.NamingStrategy == nil {   // 表、列命名策略
      config.NamingStrategy = schema.NamingStrategy{IdentifierMaxLength: 64} // Default Identifier length is 64
  }
  if dialector != nil {   // 连接器
      config.Dialector = dialector
  }
  db = &DB{Config: config, clone: 1}
  db.callbacks = initializeCallbacks(db)  // 初始化 callback 当中的各个 processor

  if config.PrepareStmt { // 是否启用 prepare 模式
      preparedStmt := NewPreparedStmtDB(db.ConnPool)
      db.cacheStore.Store(preparedStmtDBKey, preparedStmt)
      db.ConnPool = preparedStmt
  }
  // ...
}

初始化dialector，gorm中mysql版本的dialector实现在代码仓库 https://github.com/go-gorm/mysql 中，使用者通过Open方法，将传入的dsn解析成配置，然后返回mysql版本的Dialector实例.

// go-gorm/mysql/mysql.go
func Open(dsn string) gorm.Dialector {
    dsnConf, _ := mysql.ParseDSN(dsn)
    return &Dialector{Config: &Config{DSN: dsn, DSNConfig: dsnConf}}
}

// 在gorm.Open中，当dialector不为空时，会调用config.Dialector.Initialize(db)，对应实现在 go-gorm/mysql/mysql.go中
func (dialector Dialector) Initialize(db *gorm.DB) (err error) {
    if dialector.DriverName == "" {
        dialector.DriverName = DefaultDriverName
    }
	// connPool 初始化
    if dialector.Conn != nil {
        db.ConnPool = dialector.Conn
    } else {
        db.ConnPool, err = sql.Open(dialector.DriverName, dialector.DSN)
        if err != nil {
        return err
        }
    }
    // register callbacks
    callbackConfig := &callbacks.Config{
        CreateClauses: CreateClauses,
        QueryClauses:  QueryClauses,
        UpdateClauses: UpdateClauses,
        DeleteClauses: DeleteClauses,
    }
    // ...完成 crud 类操作 callback 函数的注册
    callbacks.RegisterDefaultCallbacks(db, callbackConfig)
	return
}

查询，以db.First方法作为入口，展示数据库查询的方法链路，在db.First方法当中：

遵循First的语义，通过limit和order追加clause，限制只取满足条件且主键最小的一笔数据；
追加用户传入的一系列condition，进行clause追加；
在First、Take、Last等方法中，会设置RaiseErrorOnNotFound标识为true，倘若未找到记录，则会抛出ErrRecordNotFound错误；

添加条件，执行查询类操作时，通常会通过链式调用的方式，传入一些查询限制条件，比如 Where、Group By、Order、Limit 之类. 我们以 Limit 为例，进行展开介绍：

首先调用 db.getInstance() 方法，克隆出一份 DB 会话实例

调用 statement.AddClause 方法，将 limit 条件追加到 statement 的 Clauses map 中

func (db *DB) Limit(limit int) (tx *DB) {
  tx = db.getInstance()
  tx.Statement.AddClause(clause.Limit{Limit: &limit})
  return
}
func (stmt *Statement) AddClause(v clause.Interface) {
  name := v.Name()
  c := stmt.Clauses[name]
  c.Name = name
  v.MergeClause(&c)
  stmt.Clauses[name] = c
}

Elasticsearch核心技术与实战

2022-11-01T00:00:00+00:00

在极客时间上学习elasticsearch课程，主要关注点在query的DSL语句以及集群的管理，在本地基于es 7.1来构建集群服务，启动脚本如下，同时在conf/elasticsearch.yml中添加xpack.ml.enabled: false、http.host: 0.0.0.0的配置(禁用ml及启用host)：

bash> bin/elasticsearch -E node.name=node0 -E cluster.name=geektime -E path.data=node0_data -d
bash> bin/elasticsearch -E node.name=node1 -E cluster.name=geektime -E path.data=node1_data -d
bash> bin/elasticsearch -E node.name=node2 -E cluster.name=geektime -E path.data=node2_data -d
bash> bin/elasticsearch -E node.name=node3 -E cluster.name=geektime -E path.data=node3_data -d

在docker容器中启动cerebro服务，用于监控elasticsearch集群的状态，docker启动命令如下：

bash> docker run -d --name cerebro -p 9100:9000 lmenezes/cerebro:latest

文档index基础操作

1) elasticsearch中创建新文档，用post请求方式，url内容为index/_doc/id。当未指定{id}时，会自动生成随机的id。put方式用于更新文档，当PUT users/_doc/1?op_type=create或PUT users/_create/1指定文档id存在时，就会报错。

POST users/_doc
{
  "user": "mike",
  "post_date": "2019-04-15T14:12:12",
  "message": "trying out kibana"
}

2) elasticsearch的分词器analysis，分词是指把全文本转换为一些列的单词(term/token)的过程，其通常由Character Filters、Tokenizer、Token Filters这三部分组成。具体url示例如下，analyzer的类型可以有：standard、stop、simple等。

GET _analyze
{
  "analyzer": "stop",
  "text": "2 running Quick brown-foxes leap over lazy dogs in the summer evening."
}

3) url中query string的语法，指定字段v.s.泛查询，其中df为默认字段，当不指定df只按q查询时，则是泛查询，从_doc的所有字段检索：

GET /movies/_search?q=2012&df=title&sort=year:desc&from=0&size=10&timeout=1s

URl Search、Request Body查询及文档Mapping

1）在elasticsearch中查询可以分为url search和request body查询，其中url search用GET方式，相关参数放在url中。df指定默认查询字段，q为查询字符串。当未指定df时，称为泛查询，会拿数值与doc中所有字段进行匹配：

# es中查询的dsl，df指定默认字段，q为查询数值,TermQuery
GET kibana_sample_data_ecommerce/_search?q=Eddie&df=customer_first_name
{
  "profile": "true"
}
# 若不用df的话，可以用q=field:value来进行替换
GET kibana_sample_data_ecommerce/_search?q=customer_first_name:Eddie
{
  "profile": "true"
}

2）Phrase query与Term query的区别，PhraseQuery会按整个字符串进行匹配，而TermQuery则会对字符串进行分词。对于term来说，只要Field value中包含任意一个单词就可以。

# phrase query，相当于不会做分词，匹配完整字符串(1条)
GET kibana_sample_data_ecommerce/_search?q=customer_full_name:"Eddie Underwood"
{
  "profile": "true"
}
# term query，对字符串进行了分词,好像也有keyword概念，任意匹配Eddie或Underwood就可以
GET kibana_sample_data_ecommerce/_search?q=customer_full_name:Eddie Underwood
{
  "profile": "true"
}

此外，在url query中还支持分组的概念，也就是Bool Query。当查询条件为customer_full_name:(Eddie Underwood)时，会分别按Eddie和Underwood进行匹配，其是任意的满足关系。若想在字段中同时满足要求，则可在分组中添加AND操作符。此外，url query还支持range查询及通配符查询。

# bool query，full_name中包括Eddie或Underwood才可以，实现同时包含，则需添加AND关键字
GET kibana_sample_data_ecommerce/_search?q=customer_full_name:(Eddie AND Underwood)
{
  "profile": "true"
}
# 数值范围查询，(订单总额)taxful_total_price大于50
GET kibana_sample_data_ecommerce/_search?q=taxful_total_price:>=50
{
  "profile": "true"
}
# 通配符查询，只要email字段中含"gwen"就会被匹配
GET kibana_sample_data_ecommerce/_search?q=email:gwen*
{
  "profile": "true"
}

3）Request body查询的详细解释，这其实是一种更通用的写法，使用POST请求方式。在body中使用_source指定要获取的字段列表，同时sort可指定按哪个字段进行排序。query部分指定了具体的查询条件，operator为and最终效果类似于phrase query。elasticsearch的painless脚本用于特定计算，返回计算后的新字段（如金额转换等）。

# es request body的写法，按订单总金额排序desc,_source过滤doc中的字段
POST kibana_sample_data_ecommerce/_search
{
  "_source": ["taxful_total_price", "total_quantity", "customer_full_name", "manufacturer"],
  "sort": [{"taxful_total_price": "desc"}],
  "query": {
    "match": {
      "customer_full_name": {
        "query": "Eddie Lambert",
        "operator": "and"
      }
    }
  },
  "script_fields": {
    "addtional_field": {
      "script": {
        "lang": "painless",
        "source": "doc['taxful_total_price'].value + '_hello'"
      }
    }
  }
}

此外，对于match_phrase则不会进行分词，对_doc会直接进行查询。body中的slop参数可用于近似度查询，提升数据检索的容错性。

# match_phrase查询，不会进行分词，直接匹配total字符串,slop指定term结果
POST kibana_sample_data_ecommerce/_search
{
  "query": {
    "match_phrase": {
      "customer_full_name": {
        "query": "Eddie Lambert",
        "slop": 1
      }
    }
  }
}

4）query_string与simple_query_string的区别，query_string与url query类似，也需指定default_field。同时，其也支持多字段fields及多分组query的查询，simple_query_string#query也需指定查询条件。

# query_string和url query比较类似，也支持分组，如下的query_string#fields
POST /users/_search
{
  "query": {
    "query_string": {
      "default_field": "name",
      "query": "Ruan AND YiMing"
    }
  }
}
POST /users/_search
{
  "query": {
    "query_string": {
      "fields": ["name", "about"],
      "query": "(Ruan And YiMing) OR (Java AND Elasticsearch)"
    }
  }
}
POST /users/_search
{
  "query": {
    "simple_query_string": {
      "query": "Ruan AND YiMing",
      "fields": ["name"]
    }
  }
}

5）对于文档mapping这一部分，类似比喻的话，相当于是数据表的schema，规定了字段的约束信息。对于dynamic mapping，elasticsearch支持三种模式：true、false和strict。其默认值为true，当设置mapping为false时，新添加的字段不能检索，但会在_source部分展示，当为strict时，索引文档新增字段时，会进行报错。

GET mapping_test/_mapping
# 修改dynamic为false，新加的字段不能被索引
PUT dynamic_mapping_test/_mapping
{
  "dynamic": false
}
PUT dynamic_mapping_test/_doc/10
{
  "anotherField": "otherValue"
}
# dynamic为false时，新增的字段无法被检索，strict模式下，新添加字段会报错
POST dynamic_mapping_test/_search
{
  "query": {
    "match": {
      "anotherField": "otherValue"
    }
  }
}

深入ElasticSearch搜索机制

1）深入理解分词的逻辑，在使用_bulk api批量写入一批文档后，查询文档时，通过原有的字段是检索不到的，必须将其转换为小些。向products索引写入3条数据，分别为Apple的产品。

# _bulk api批量写入数据，一次写入3条数据
POST /products/_bulk
{"index": {"_id": 1}}
{"productID": "XHDK-1902-#fj3", "desc": "iPhone", "price": 30}
{"index": {"_id": 2}}
{"productID": "XHDK-1003-#446", "desc": "iPad", "price": 35}
{"index": {"_id": 3}}
{"productID": "XHDK-6902-#521", "desc": "MBP", "price": 40}

通过term query按iPhone进行检索时，是查不到数据的。原因是在存储文档时，elasticsearch对字段值进行了分词，数据字段按小写形式进行存储，当用iphone检索时是可以的。此外，elasticsearch中每个字段都有keyword属性，在用field.keyword查询时则可以进行完整的匹配。

# 直接用iPhone在desc#value查询，搜不到记录。但用desc.keyword可以，因为在保存文档时，iPhone在索引中已进行了小写
POST /products/_search
{
  "query": {
    "term": {
      "desc.keyword": {
        "value": "iPhone"
      }
    }
  }
}
# 将query改为filter的方式，忽略TF-IDF算分问题，避免相关性算分的开销，提升查询性能
POST /products/_search
{
  "explain": true,
  "query": {
    "constant_score": {
      "filter": {
        "term": {
          "productID.keyword": "XHDK-1902-#fj3"
        }
      }
    }
  }
}

为了提升查询效率，可以用constant_score#filter来替换term query，因为其不进行算分，所以效率能高一些。同时，其也支持range query和exists操作符。

# 用range方式进行范围查询，通过doc.price进行过滤
GET /products/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "price": {
            "gte": 20, "lte": 30
          }
        }
      }
    }
  }
}
# 用exists来查找一些field值非空的文档，并将其进行返回
POST /products/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "exists": {
          "field": "desc"
        }
      }
    }
  }
}

2）query context与filter context影响算分的问题，默认情况下elasticsearch会按照匹配度问题给文档进行打分，在文档每部分可使用boost来影响其分数，当文档中两个字段都含关键词时，可通过boost设置权重，进而影响文档的排名。

# query context与filter context影响算分问题
POST /blogs/_bulk
{"index": {"_id": 1}}
{"title": "Apple iPad", "content": "Apple iPad,Apple iPad"}
{"index": {"_id": 2}}
{"title": "Apple iPad,Apple iPad", "content": "Apple iPad"}
# 通过boost指定每部分字段的权重，进而影响文档的算分排序
POST blogs/_search
{
  "query": {
    "bool": {
      "should": [
        {"match": {
          "title": {
            "query": "apple,ipad",
            "boost": 1
          }
          }
        },
        {"match": {
          "content": {
            "query": "apple,ipad",
            "boost": 2
          }
        }}
      ]
    }
  }
}

在bool查询中，must和should是算分的，而must_not则不计入算分，在检索示例中可通过must及must_not来过滤文档。默认情况下，用term query查询时，只要doc中包含关键字的频率高，则其相应的算分也会高。在具有相同数量关键词的字段中，doc长度越小的文档相关性越高。

# 批量写入关于apple的新闻数据，批量写入文档记录
POST news/_bulk
{"index": {"_id": 1}}
{"content": "Apple Mac"}
{"index": {"_id": 2}}
{"content": "Apple iPad"}
{"index": {"_id": 3}}
{"content": "Apple employee like Apple Pie and Apple Juice"}
# 然而并不是所期望的，返回了apple食品记录
POST news/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {"content": "apple"}
      }
    }
  }
}

可通过must_not对不符合条件的文档进行剔除，若只是想将不相关的文档分数减小，则可以通过boosting#positive或boosting#negative使得对文档进行重新的计分，这样不相关的文档也会进行展示，但其排名比较靠后。

# 用must_not排除pie字符串，只剩余电子产品
POST news/_search
{
  "query": {
    "bool": {
      "must": {"match": {"content": "apple"}},
      "must_not": {"match": {"content": "pie"}}
    }
  }
}
# 当不想删除时，可使用boosting#positive、negative方式排序
POST news/_search
{
  "query": {
    "boosting": {
      "positive": {
        "match": {"content": "apple"}
      },
      "negative": {
        "match": {"content": "pie"}
      },
      "negative_boost": 0.5
    }
  }
}

3）disjunction query也是关于文档相关性的，若文档中有两部分都匹配，若想按文档匹配度高的那一部分排序的话（不按累加求和），则应使用此查询。同时，还可按tie_breaker对文档分数进行扰乱，进而影响文档的排名。

PUT /blogs/_bulk
{"index": {"_id": 1}}
{"title": "Quick brown rabbits", "body": "Brown rabbits are commonly seen"}
{"index": {"_id": 2}}
{"title": "Keeping pets happy", "body": "My quick brown fox eats rabbits on a regular basis."}
# 用dis_max#queries找两部分，各自评分最高的内容，此外还可通过tie_breaker进行调整
POST /blogs/_search
{
  "query": {
    "dis_max": {
      "queries": [
        {"match": {"title": "Brown fox"}},
        {"match": {"body": "Brown fox"}}
      ],
      "tie_breaker": 0.2
    }
  }
}

多字段查询的搜索语法，most_fields会累计多个字段的分数之和，cross_fields也就是当query在多个字段中存在时，就会返回结果，也就是所谓的跨字段查询。

PUT address/_doc/1
{
  "street": "5 Poland Street",
  "city": "London",
  "country": "United Kingdom",
  "postcode": "W1V 3DG"
}
# 使用most_fields是可以的，但增加operator:and就不可以了。可将type改为cross_fields，表示将query string在多个字段中进行检索
POST address/_search
{
  "query": {
    "multi_match": {
      "query": "Poland Street W1V",
      "fields": ["street", "city", "country", "postcode"],
      "type": "cross_fields",
      "operator": "and"
    }
  }
}

可以使用alias语法对索引进行重命名，应用场景多为elasticsearch索引数据备份，为避免应用服务端开发时修改配置，可做到无感数据源切换。

# index的alias操作，用于对address进行重命名
POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "address",
        "alias": "address_latest"
      }
    }
  ]
}

深入`ElasticSearch`聚合分析

elasticsearch聚合分metric和bucket两类，metric类似于一些指标（count、avg、sum等），而bucket相当于sql语句中的group by操作。

select count(brand)=>[metric] from cars group by brand=>[bucket];

一个简单的例子，通过elasticsearch请求分别统计max、min和avg的平均工资，size设置为0表示不返回原始文档。aggs表示聚合语法开始，其中max、min为聚合类型，里面的field值salary表示要聚合的字段。其实，简化语法可直接用stats替换max，其在一次执行中会统计出相关指标。

# Metrics聚合，找最低、最高及平均工资
POST employees/_search
{
  "size": 0,
  "aggs": {
    "max_salary": {
      "max": {
        "field": "salary"
      }
    },
    "min_salary": {
      "min": {
        "field": "salary"
      }
    },
    "avg_salary": {
      "avg": {
        "field": "salary"
      }
    }
  }
}

elasticsearch通过jobs#terms进行分桶操作，首先一点elasticsearch不能对text类型字段进行分桶（keyword是可以的），需打开fielddata的配置。aggs还可以嵌套，如下是对员工按age进行排序，并取前2位进行展示。

# 对keyword进行聚合，必须要用.keyword，避免分词，直接用job会报错,还可指定terms#size参数
POST employees/_search
{
  "size": 0,
  "aggs": {
    "jobs": {
      "terms": {
        "field": "job.keyword"
      },
      "aggs": {
        "old_employee": {
          "top_hits": {
            "size": 2,
            "sort": [
              {
                "age": {
                  "order": "desc"
                }
              }
            ]
          }
        }
      }
    }
  }
}
# 对text字段打开fielddata，支持terms aggregation
PUT employees/_mapping
{
  "properties": {
    "job": {
      "type": "text",
      "fielddata": "true"
    }
  }
}

cardinate操作相当于sql中的distinct count操作，可用于去重后的计数。salary还支持按range进行数量查询，其中key的值可以进行自定义。

# 对job.keyword进行聚合分析，cardinate操作，相当于做distinct count操作
POST employees/_search
{
  "size": 0,
  "aggs": {
    "cardinate": {
      "cardinality": {
        "field": "job.keyword"
      }
    }
  }
}
# salary range分桶，可以自定义桶#key，并按range进行查询
POST employees/_search
{
  "size": 0,
  "aggs": {
    "salary_range": {
      "range": {
        "field": "salary",
        "ranges": [
          {
            "to": 10000
          },
          {
            "from": 10000,
            "to": 20000
          },
          {
            "key": ">20000",
            "from": 20000
          }
        ]
      }
    }
  }
}

histogram用于展示员工薪资的直方图，field表示按哪个字段展示，interval为直方图每格的间隔大小。此外，elasticsearch还支持pipeline操作，其会将aggs后的结果再进行分析，常见的有min_bucket、max_bucket、avg_bucket等操作。

# salary Histogram，工资分布的直方图
POST /employees/_search
{
  "size": 0,
  "aggs": {
    "salary_histogram": {
      "histogram": {
        "field": "salary",
        "interval": 20000,
        "extended_bounds": {
          "min": 0,
          "max": 100000
        }
      }
    }
  }
}
# elasticsearch pipeline操作, min_bucket最终选出最低平均工资,max_bucket则求最大的工作类型，avg_bucket只是所有类型工作的平均值,percentiles_bucket为百分位数的统计
POST /employees/_search
{
  "size": 0,
  "aggs": {
    "jobs": {
      "terms": {
        "field": "job.keyword",
        "size": 10
      },
      "aggs": {
        "avg_salary": {
          "avg": {
            "field": "salary"
          }
        }
      }
    },
    "min_salary_by_jobs": {
      "percentiles_bucket": {
        "buckets_path": "jobs>avg_salary"
      }
    }
  }
}

Aggs Query聚合的filter这块，共分为Filter、Post_Filter和global这3种类型，第一个在aggs#old_person#filter中，其行为属于前置filter（也即先过滤再agg）。第二个属于post_aggs，先进行aggs然后只展示Dev Manager的bucket桶。而all#global{}会排除query#filter的作用，而对所有doc进行计算。

# Filter，先按age#from 从35岁开始filter
POST employees/_search
{
  "size": 0,
  "aggs": {
    "old_person": {
      "filter": {
        "range": {
          "age": {
            "from": 35
          }
        }
      },
      "aggs": {
        "jobs": {
          "terms": {
            "field": "job.keyword"
          }
        }
      }
    }
  }
}

#post filter，相当于先做bucket分桶操作，然后再进行filter过滤
POST /employees/_search
{
  "aggs": {
    "jobs": {
      "terms": {
        "field": "job.keyword"
      }
    }
  },
  "post_filter": {
    "match": {
      "job.keyword": "Dev Manager"
    }
  }
}

`ElasticSearch`数据建模

数据建模-对象及Nested对象，例如blog文档中含User对象，结构类似于json。在用Rest接口进行查询时，可通过user.username进行嵌套式查询。

# 插入一条blog信息, user为嵌套的对象，包含3个字段
PUT nested_blog/_doc/1
{
  "content": "I like elasticsearch",
  "time": "2022-11-06T00:00:00",
  "user": {
    "userid": 1,
    "username": "Jack",
    "city": "ShangHai"
  }
}
# 查询blog的信息，对text做了分词，不区分大小写了
POST nested_blog/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {"content": "elasticsearch"}},
        {"match": {"user.username": "Jack"}}
      ]
    }
  }
}

当嵌套字段类型为数组时，通过bool查询其返回的结果会存在异常。此时，index的mapping和查询的dsl也必须改为nested query。

# 电影的mapping信息，对于数组类型字段，需将`type`改为`nested`
PUT my_movies
{
  "mappings": {
    "properties": {
      "actors": {
        "type": "nested",
        "properties": {"first_name": {"type": "keyword"},
          "last_name": {"type": "keyword"}}
      },
      "title": {
        "type": "text",
        "fields": {"keyword": {"type": "keyword", "ignore_above": 256}}
      }
    }
  }
}
# 写入一条电影信息, actors部分为一个数组
PUT my_movies/_doc/1
{
  "title": "Speed",
  "actors": [{"first_name": "Keanu", "last_name": "Reeves"},
  {"first_name": "Dennis", "last_name": "Hopper"}]
}

在进行数据检索时，bool类型的query，在json结构中也需指明nested.path，这样检索数据时，才会按同一个对象的first_name、last_name一起检索。此外，对于普通嵌套对象，Agg操作是不生效的。

# 查询电影信息，但是检索到了结果，需调整为Nested Query, 再根据条件筛选就正确
POST my_movies/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {"title": "Speed"}},
        {"nested": {
          "path": "actors",
          "query": {
            "bool": {
              "must": [
                {"match": {"actors.first_name": "Keanu"}},
                {"match": {"actors.last_name": "Reeves"}}
              ]
            }
          }
        }}
      ]
    }
  }
}
# 嵌套对象的Agg聚合操作，也需指定类型为Nested Query，普通Agg是不生效的
POST my_movies/_search
{
  "size": 0,
  "aggs": {
    "actors": {
      "nested": {
        "path": "actors"
      },
      "aggs": {
        "actor_name": {
          "terms": {
            "field": "actors.first_name",
            "size": 10
          }
        }
      }
    }
  }
}

elasticsearch中的父子文档，索引的mapping如下所示，blog_comments_relation#type为join，在relations中定义了blog和comment的对应关系。在写入blog文档时，blog_comments_relation#name的值为blog。

# Es中的父/子文档，blog_comments_relation#此part未看懂
PUT my_blogs
{
  "settings": {
    "number_of_shards": 2
  },
  "mappings": {
    "properties": {
      "blog_comments_relation": {
        "type": "join",
        "relations": {
          "blog": "comment"
        }
      },
      "content": {
        "type": "text"
      },
      "title": {
        "type": "keyword"
      }
    }
  }
}
# 索引父文档，分别写入两个文档
PUT my_blogs/_doc/blog1
{
  "title": "Learning Elasticsearch",
  "content": "Learning ELK @ geektime",
  "blog_comments_relation": {
    "name": "blog"
  }
}
PUT my_blogs/_doc/blog2
{
  "title": "Learning Hadoop",
  "content": "Learning Hadoop",
  "blog_comments_relation": {
    "name": "blog"
  }
}

索引comment子文档，需在json结构中指定id为comment1和routing信息，其中index name值为comment，对应的parent值为blog1。通过my_blogs/_search可以查到所有文档列表：

# 索引子文档，需指定routing路由字段值
PUT my_blogs/_doc/comment1?routing=blog1
{
  "comment": "I am learning ELk",
  "username": "Jack",
  "blog_comments_relation": {
    "name": "comment",
    "parent": "blog1"
  }
}
PUT my_blogs/_doc/comment2?routing=blog2
{
  "comment": "I like Hadoop !!!",
  "username": "Jack",
  "blog_comments_relation": {
    "name": "comment",
    "parent": "blog2"
  }
}
# 查询所有文档，包含blog和comment两种类型
POST my_blogs/_search
{}

父子文档间的查询，通过父文档id查询，若查看blog#comment，则可以通过parent_id来查询，其中type值为comment。若想根据comment查询对应的blog，则可使用has_child注解。此外，可通过comment2和routing查看blog2下所有的评论数据。

# 根据父文档id查询
GET my_blogs/_doc/blog2
# parentId查询,依据blog2查到其下所有comment
POST my_blogs/_search
{
  "query": {
    "parent_id": {
      "type": "comment",
      "id": "blog2"
    }
  }
}
# has child查询返回父文档, has parent查询会返回子文档
POST my_blogs/_search
{
  "query": {
    "has_child": {
      "type": "comment",
      "query": {
        "match": {
          "username": "Jack"
        }
      }
    }
  }
}
# 通过id和routing来访问子文档
GET my_blogs/_doc/comment2?routing=blog2

对于elasticsearch中已有的index，要修改其某个字段类型时，只能对当前索引进行reindex操作。直接更新索引mapping文件，会抛出remote_transport_exception的异常。

# reindex api，类似于导数据
POST _reindex
{
  "source": {
    "index": "reindex_blogs"
  },
  "dest": {
    "index": "blogs_fix"
  }
}

elasticsearch中pipeline和painless脚本，可通过PUT请求直接注册一个blog_pipeline，processors可以有多种类型，像split会对指定字段进行切分，并且指定切分字符串为,。在索引文档时，可以指定blog_pipeline，这样存入文档的字段会被切分开。

# 为ES增加一个pipeline, 对index的文档进行计算
PUT _ingest/pipeline/blog_pipeline
{
  "description": "a blog pipeline",
    "processors": [
    {
      "split": {
        "field": "tags",
        "separator": ","
      }
    },
    {
      "set": {
        "field": "views",
        "value": 0
      }
    }
  ]
}
# 测试pipeline，确实tags字段被切分了，同时增加了views字段
POST _ingest/pipeline/blog_pipeline/_simulate
{
  "docs": [
    {
      "_source": {
        "title": "Introducing big data....",
        "tags": "openstask,k8s",
        "content": "you known, for cloud"
      }
    }
  ]
}
PUT tech_blogs/_doc/2?pipeline=blog_pipeline
{
    "title": "Introducing big data....",
    "tags": "openstask,k8s",
    "content": "you known, for cloud"
}

painless脚本内容如下，在script语法中指定执行脚本，其中ctx可取上下文中定义的对象。

POST tech_blogs/_update/1
{
  "script": {
    "source": "ctx._source.views += params.views",
    "params": {
      "views": 100
    }
  }
}

大数据时代数据仓库Hive

2022-01-22T00:00:00+00:00

在Hadoop大数据平台及生态系统中，使用mapreduce模型进行编程，对广大用户来说，仍然是具有挑战性的任务。人们希望使用熟悉的SQL语言，对hadoop平台上的数据进行分析处理，这就是SQL On Hadoop系统诞的背景。

SQL on Hadoop是一类系统的简称，这类系统利用Hadoop实现大量数据的管理，具体是利用HDFS实现高度可扩展的数据存储。在HDFS之上，实现SQL的查询引擎，使得用户可以使用SQL语言，对存储在HDFS上的数据进行分析。

`Apache Hive`的产生

Hive是基于Hadoop的一个数仓工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的类SQL(HQL)查询功能，可以将HQL语句转换成为MapReduce任务进行运行。使用类SQL语句就可快速实现简单的MapReduce统计，不必开发专门的MapReduce应用。Apache Hive是由Facebook开发并开源，最后贡献给Apache基金会。

Hive系统整体3个部分：用户接口、元数据存储、驱动器(Driver)在Hadoop上计算与存储。

用户接口主要有3个，CLI、ThriftServer和HWI。最常用的就是CLI，启动hive命令回同时启动一个Hive Driver。ThriftServer是以Thrift协议封装的Hive服务化接口，可提供跨语言的访问，如Python、C++等，最后一种是Hive Web Interface提供浏览器的访问方式。
表结构的一些Meta信息是存储在外部数据库的，如MySQL、Oracle和Derby库。Hive中元数据包括表的名字、表的列和分区及其属性、表的属性（是否为外部表等）、表的数据所在目录等。
Driver部分包括：编译器、优化器和执行器，编译器完成词法分析、语法分析，将HQL转换为AST。AST生成逻辑执行计划，然后物理MR执行计划；优化器用来对逻辑计划、物理计划进行优化，生成的物理计划转变为MR Job并在Hadoop集群上执行。

`Hive`数据模型

Hive通过以下模型来组织HDFS上的数据，包括：数据库DataBase、表Table、分区Partition和桶Bucket。

Table管理表和外表，Hive中的表和关系数据库中的表很类似，依据数据是否受Hive管理可分为：Managed Table（内表）和External Table（外表）。对于内表，HDFS上存储的数据由Hive管理，Hive对表的删除影响实际的数据。外表则只是一个数据的映射，Hive对表的删除仅仅删除愿数据，实际数据不受影响。
Partition基于用户指定的列的值对数据表进行分区，每一个分区对应表下的相应目录${hive.metastore.warehouse.dir}/{database_name}.db/{tablename}/{partition key}={value}，其优点在于从物理上分目录划分不同列的数据，易于查询的简枝，提升查询的效率。
Bucket桶作为另一种数据组织方式，弥补Partition的短板，通过Bucket列的值进行Hash散列到相应的文件中，有利于查询优化、对于抽样非常有效。

`Hive`的数据存储格式，聊聊`Parquet*`

Parquet*起源于Google Dremel系统，相当于Dremel中的数据存储引擎。最初的设计动机是存储嵌套式数据，如Protocolbuffer、thrift和json等，将这些数据存储成列式格式，以便于对其高效压缩和编码，且使用更少的IO操作取出需要的数据。并且其存储metadata，支持schema的变更。 Parquet*是面向分析型业务的列式存储格式，由Twitter和Cloudera合作开发。一个Parquet文件通常由一个header和一个或多个block块组成，以一个footer结尾。footer中的metadata包含了格式的版本信息、schema信息、key-value pairs以及所有block中的metadata信息。

parquent-format项目定义了parquent内部的数据类型、存储格式等。
parquent-mr项目完成外部对象模型与parquent内部数据类型的映射，对象模型可以简单理解为内存中的数据表示，Avro、Thrift、Protocol Buffers等这些都是对象模型。

`Hive Catalog`介绍

HCatalog是Hadoop的元数据和数据表的管理系统，它基于Hive中的元数据层，通过类似SQL的语言展现Hadoop数据的关联关系。
Catalog允许用户通过Hive、Pig、MapReduce共享数据和元数据，用户编写应用程序时，无需关心数据怎样存储、在哪里存储，避免因schema和存储格式的改变而受到影响。
通过HCatalog，用户能通过工具访问Hadoop上的Hive Metastore。它为MapReduce和Pig提供了连接器，用户可以使用工具对Hive的关联列格式的数据进行读写。

数据类型及数据定义

hive支持基本数据类型有tinyInt、int、bigInt、String等，除此之外，其还支持复杂类型，如struct、map和array等。Hive中默认以\n作为行分割符，以^A用于字段分割符，用^B分割array或struct中的元素，或用于map中键-值对之间的分割，使用^C用于map中键和值之间的分割。

若要实现自定义话，需用一组row format delimited语句，分别指定行、字段、map、list的分割符:

create table employees(
  ...field list
) row format delimited
fields terminated by `\001`
collection items terminated by `\002`
map keys terminated by `\003`
lines terminated by `\n` stored as textfile;

hive数据表分为管理表和外部表，external表用于加载外部数据源，删除外部表并不会删除hdfs上的文件数据，有些HiveQL语法结构并不适用于外部表。hive中有数据分区的概念，可以看到分区表具有重要的性优势，而且分区表还可以用一种符合逻辑分方式进行组织，比如分层存储。

创建好表之后，可用hsql从hdfs中向hive表加载数据，用overwrite会完全覆盖表中的记录：

LOAD DATA INPATH '/tmp/hive/metastore/financials.db/employees/employee-22-0927.csv' INTO TABLE employees;

UDF和自定义FileFormat

在hive中用户可以自定义实现UDF，对hive库已有的函数进行扩展，例子，自定义UDF实现计算每个人所属的星座功能。实现类UDFZodiacSign继承基类UDF并实现evaluate()函数，在查询中对于每行输入都会应用到evaluate()函数，而evaluate()处理后的值会返回给Hive。

加载hadoop-mapreduce-1.0.0.xx.jar到hive中，只与当前session会话进行了绑定。

hive> add jar /Users/madong/datahub-repository/distributed-data-computing/hadoop-mapreduce/target/hadoop-mapreduce-1.0.0-jar-with-dependencies.jar

将函数zodiac注册到hive中，可以用describe function extended zodiac来查看函数明细内容：

hive> create temporary function zodiac as 'hadoop.apache.hive.UDFZodiacSign';
# 实际执行真正的sql，zodiac(date)将日期转为了对应的星座
hive (financials)> select name, zodiac(bday) from littlebigdata;
OK
name	_c1
edward capriolo	Aquarius

在使用完UDF后，可以通过drop temporary function if exists zodiac删除此函数。UDAF自定义扩展和UDF一样，但其继承的是GenericUDF类，要想使所有函数都长期有效，可在FunctionRegistry中注册，然后重新替换hive-exec-*.jar这个jar文件就可以。

registrUDF('parse_url', UDFParseUrl.class, false)
registerGenericUDF('nvl', GenericUDFNvl.class)
registerGenericUDF('split', GenericUDFSplit.class)

FileFormat是用自定义的方式从HDFS上读取内容，按指定的格式切分fields以及row数据，实现方式可参考Base64TextInputFormat和Base64TextOutputFormat。

hive conflient: https://cwiki.apache.org/confluence/display/Hive/DeveloperGuide#DeveloperGuide-RegistrationofNativeSerDes
base64 fileformat: https://github.com/apache/hive/tree/master/contrib/src/java/org/apache/hadoop/hive/contrib/fileformat

大数据三架马车之Yarn、BigTable

2021-11-07T00:00:00+00:00

在Hadoop V1.0版本中，资源调度部分存在扩展性差、可用性差、资源利用率低的改问题，其中，Job Tracker既要做资源管理，又要做任务监控，同时Job的并发数页存在限制。同时，JobTracker存在单点故障问题，任务调度部分不支持调度流式计算、迭代计算、DAG模型。

2013年，Hadoop 2.0发布，引入了Yarn、HDFS HA、Federation。

Yarn的设计思路（Yet Another Resource Manager）

Yarn由三部分组成：ResourceManager、NodeManager、ApplicationMaster，其中：RM掌控全局的资源，负责整个系统的资源管理和分配（处理客户端请求、启动/监控AM和NM、资源调度和分配），NM驻留在一个YARN集群的节点上做代理，管理单个节点的资源、处理RM、AM的命令，AM为应用程序管理器，负责系统中所有所有应用程序的管理工作（数据切分、为APP申请资源并分配、任务监控和容错）。

Yarn主要解决数据集群资源利用率低、数据无法共享、维护成本高的问题，常见的应用场景有：MapReduce实现离线批处理、Impala实现交互式查询分析、用Strom实现流式计算、在Spark下来完成迭代计算。

Yarn Container及资源调度流程

Container是Yarn资源的抽象，它封装了某个节点上一定量的资源（CPU和内存两类资源），它跟Linux Container没有任何关系，仅仅是Yarn提出的一个概念（可序列、反序列的对象）。

message ContainerProto {
  optional ContainerIdProto id = 1; // container id
  optional NodeIdProto nodeId = 2;  // 资源所在节点
  optional string node_http_address = 3;
  optional ResourceProto resource = 4; // container资源量
  optional PriorityProto priority = 5; // container优先级
  optional hadoop.common.TokenProto container_token = 6;
}

Container由ApplicationMaster向ResourceManager申请的，由ResourceManager中的资源调度器异步分配给ApplicationMaster。Container的运行是由ApplicationMaster向资源所在的NodeManager发起的，Container运行时需提供内部执行的任何命令（比如Java、Python、C++进程启动命令均可）及该命令执行所需的环境变量和外部资源。

资源调度算法及调度器

调度算法是整个资源管理系统中一个重要的部分，简单地说，调度算法的作用是决定一个计算任务需要放在集群中的哪台机器上面。待调度的任务需考虑资源需求（CPU、Memory、Disk），应用亲和及反亲和性等。

FIFO调度，先来的先被调用、分配CPU、内存等资源，后来的在队列等待。适用于平均计算时间、耗时资源差不多的作业，通常还可匹配优先级，不足在于用户将Job作业优先级设置的最高时，会导致排在后面的短任务等待。
SJF（Shortest Job First）调度，为了改善FIFO算法，减少平均周转时间，提出了短作业优先算法。任务执行前预先计算好其执行时间，调度器从中选择用时较短的任务优先执行，但优先级无法保证。
时间片轮转调度(Round Robin，RR)，核心思想是CPU时间分片（time slice）轮转就绪任务，当时间片结束时，任务未执行完时发生时钟中断，调度器会暂停当前任务的执行，并将其置于就绪队列的末尾。此调度优点在于跟任务大小无关，都可获得公平的资源分配。但实现较为复杂，计算框架需支持中断。
最大最小公平调度（Min-Max Fair），将资源平分为n份（每份S/n），把每份分给相应的用户。若超过了用户的需求，就回收超过的部分，然后将总体回收的资源平均分给上一轮分配中尚未得到满足的用户，直到没有回收的资源为止。
容量调度（Capacity）,首先划分多个队列，队列资源采用容量占比的方式进行分配。每个队列设置资源最低保证和使用上限。如果队列中的资源有剩余或空闲，可暂时共享给那些需要资源的队列，一旦该队列有新的应用程序需要运行资源，则其它队列释放的资源会归还给该队列。

Yarn的三种调度器实现为：Fair Scheduler(公平调度器)、FIFO Scheduler(先进先出调度器)、Fair Scheduler(公平调度器)，FIFO先进先出调度器，同一时间队列中只有一个任务在执行，可以充分利用所有的集群资源。Fair Scheduler和Capacity Scheduler有区别的一些地方，Fair队列内部支持多种调度策略，包括FIFO、Fair、DRF（Dominant Resource Fairness）多种资源类型（e.g.CPU、内存的公平资源分配策略）。

Job提交流程

在yarn上提交job的流程如下方的步骤图所示，yarnRunner向rm申请一个Application，rm返回一个资源提交路径和application_id，客户端提交job所需要的资源(切片+配置信息+jar包)到资源提交路径。 Capacity Scheduler参数调整是在yarn-site.xml中，yarn.resourcemanager.scheduler.class用于配置调度策略org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler。

Yarn的高级特性Node Label，HDFS异构存储只能设置让某些数据（以目录为单位）分别在不同的存储介质上，但是计算调度时无法保障作业运行的环境。在Nodel Label出现之前，资源申请方无法指定资源类型、软件运行的环境（JDK、python）等，目前只有Capacity Scheduler支持此功能，Fair Scheduler正在开发，yarn.node-labels.enable用于开启Node Label的配置。

BigTable的开源实现HBase

BigTable是一个分布式存储系统，用于管理结构化数据，旨在扩展到非常大的规模：数千个商品服务器上的PB级数据。Google的很多项目使用HBase来存储数据，包括：网页索引、google地图和google金融，这些应用程序在数据大小（从URL到网页再到卫星图像）和延迟要求（从后端批量处理到实时数据服务）方面对BigTable提出了不同的要求。

Hbase是一个稀疏的、分布式的、持久的多纬排序图，该映射由行键、列键和时间戳索引组成，map中的每个值都是一个不可序列化的字节数组。其对应的数据模型（逻辑视图）如下：

(row:string, column:string, time:int64) -> string

行关键字Row key，唯一标识一行数据，用于检索记录。其可以是任意长度的字符串，最大长度为64KB。存储时会按照row key的字典序进行排序，其可通过单个row key、row key的range及全表扫描的方式来访问。
Column Family，行中的列被成为列族，同一个列族的所有成员具有相同的列族前缀，列键Column Key也称为列名，必须以列族作为前缀，格式为列族：限定词。
Timestamp和Cell，插入单元格时的时间戳，默认作为单元格的版本号，类型为64位整数。要定位一个单元，需满足”行键+列键+时间戳”三个要素。

在物理视图上，HBase的每一个列族Column Family对应一个StoredFile对象，服务组件整体分为HMaster和Region Server两部分，底层使用Hadoop的DataNode来存储数据。

大数据三架马车之MapReduce

2021-08-09T00:00:00+00:00

Hadoop是Apache的一个开源的分布式计算平台，以HDFS分布式文件系统和MapReduce计算框架为核心，为用户提供一套底层透明的分布式基础设施。

MapReduce提供简单的API，允许用户在不了解底层细节的情况下，开发分布式并行程序。利用大规模集群资源，解决传统单机无法解决的大数据处理问题，其设计思想起源于MapReduce Paper。

MapReduce编程模型

MapReduce是一种用于处理和生成大型数据集的编程模型和相关实现，用户指定一个map()函数接收处理key/value对，同时产生另外一组临时key/value集合，reduce()函数合并相同intermediate key关联的value数据，以这种函数式方风格写的程序会自动并行化并在大型商品机器集群上运行。

在Paper发布之前的几年，Jeffrey Dean及Google的一些工程师已经实现了数百个用于处理大量原始数据且特殊用途的计算程序，数据源如抓取的文档、Web日志的请求等，来计算各种派生数据，像倒排索引、Web文档图结构的各种表示、每个主机爬取的页面数汇总等。

看个统计单词在文章中出现的次数的例子，map()函数emit每个单词及其出现次数，reduce()函数统计按单词统计其出现的总次数，伪代码如下：

map(String key, String value):
  // key: document name
  // value: document contents for each word w in value:
  EmitIntermediate(w, "1");

reduce(String key, Iterator values): // key: a word
  // values: a list of counts
  int result = 0;
  for each v in values: result += ParseInt(v);
      Emit(AsString(result));

谈一些MapReduce程序在Google的应用：

反向索引（Inverted Index），map()函数解析文档中的每个单词，对(word, document ID)进行emit，reduce端依据word将二元组pair中的document id进行合并，最终emit(word, list(document ID))的数据。
统计URL的访问频次，map()函数输出从log中获取web request的信息，将(URL, 1)的二元组进行output，reduce()端将具有相同URL的请求进行归集，以(URL, total count)的方式进行emit。
反转Web-Link Graph，map()函数针对网页中存在的超链接，按(target, source)的格式输出二元组，reduce()函数将相同target对应的source拼接起来，按(target, list(source))的方式进行emit。

Execution Overview

在输入数据切分成数份后，map函数会被自动分发到多台机器上，输入数据切分可以在多不同的机器上并行执行。partition()函数（hash(key) mod R）会将中间key切分为R片，reduce()函数会根据切分结果分到不同机器。

用户程序中的mapreduce library会将输入的文件切分成16MB～64MB的文件块，然后它在cluster中启动多个副本。
在cluster上跑的多个程序中有一个是特殊的，其为master节点，剩余的为worker节点。master节点向worker节点分配任务，当worker节点有空闲时，会向其分配map或reduce任务。
worker执行map任务时，会从切分的文件中读取数据，它从文件中读取key/value对，在map()函数中执行数据处理，生成的intermediate key会缓存在memory中。
memory中的pair会定期的写入本地磁盘，并将其位置信息返给master节点，其负责将buffered pair对应的位置信息转发给其它worker节点。
当master节点将map函数产生的中间数据位置告知reduce worker时，其会使用rpc从map worker的本地磁盘中读取数据。当reduce worker读完所有数据后，它会对intermediate key对数据进行排序，因此，具有相同key的中间结果就会被group在一起。sort是非常必要的，因为通常情况下，许多不同的key会映射到相同的reduce函数中。当中间数据太大在memory中放不下时，会使用外部排序进行处理。
reduce worker会遍历排序后的中间数据，将intermediate key及对应value集合传给reduce函数，reduce()函数的输出结果会append到一个最终的输出文件中。当所有map和reduce任务都执行完成后，它会告知用户程序返回用户代码。

容错性考虑

由于mapreduce旨在帮助使用成百上千台机器处理处理大量数据，因此该机器必须优雅地容忍机器故障，分别讨论下当worker和master节点故障时，如何进行容错？

worker节点故障，master节点会周期性的ping所有的worker节点，若worker在给定时间内未响应，则master会标记worker为failure状态。此时，该worker节点上已执行完的map task会被重新置为initial idle状态，然后会等待其它worker执行此task。类似的，任何此worker上正在执行的map()或reduce()任务也会被重置为idle状态，然后等待调度。

为什么已经完成的map task还要被重新执行呐？因为map()会将intermediate data写在本次磁盘上，当worker不可访问时，执行reduce()时无法从failure worker中取数据。而completed reduce不需要重新执行，因为reduce()函数已将最终结果写到外部存储HDFS上。

master节点故障问题，容错方案较为简单，就是让master每隔一段时间将data structures写到磁盘上，做checkpoint 。当master节点die后，重新启动一个master然后读取之前checkpoint的数据就可恢复状态。

Input文件切分，Split和Block的区别

split是文件在逻辑上的划分，是程序中的一个独立处理单元，每一个split分配给一个task去处理。而在实际的存储系统中，使用block对文件在物理上进行划分，一个block的多个备份存储在不同节点上。

文件切分算法主要用于确定inputSplit的个数及每个inputSplit对应的数据段，splitSize=max{ minSize, min{totalSize/numSplits, blockSize}}，最后剩下不足splitSize的数据块单独成为一个InputSplit。

Host选择算法，Input对象由（file, start, length, hosts）这个四元组构成，节点列表是关键，关系到任务的本地性（locality），mapreduce优先让空闲资源处理本节点的数据。

mapreduce的sort分两种：map task中spill数据的排序，数据写入本地磁盘之前，先要对数据进行一次本地排序（快排算法）。reduce task中数据排序，采用归并排序或小顶堆算法，sort和reduce可同时进行。

MapReduce分布式计算框架

MapReduce核心组件有JobTracker、TaskTracker和Client：

JobTracker负责集群资源监控和作业调度，通过心跳监控所有TaskTracker的健康状况。监控Job的运行情况、执行进度、资源使用，交由任务调度器负责资源分配，任务调度器有FIFO Scheduler和Capacity Scheduler。
TaskTracker具体执行Task的单元，以slot为单位等量划分本节点资源，分为MapSlot和ReduceSlot。其通过心跳周期性向JobTracker汇报本节点资源使用情况和任务执行进度，同时接收JobTracker的命令执行相应的操作（启动新任务、杀死任务等）。
Client提交用户编写的程序到集群，查看Job的运行状态。

MR Job声明周期文字描述：

作业提交和初始化：首先JobClient将作业相关文件上传到HDFS，然后JobClient通知JobTracker使其对作业进行初始化（JobInProgress和TaskInProgress）。
任务调度和监控：JobTracker的任务调度器按照一定策略（TaskScheduler），将task调度到空闲的TaskTracker。
任务JVM启动，TaskTracker下载任务所需文件，并为每个Task启动一个独立的JVM。
TaskTracker启动Task，Task通过RPC将其状态汇报给TaskTracker，再由TaskTracker汇报给JobTracker。
完成作业后，会讲数据回写到hdfs。

大数据的三架马车之HDFS

2021-07-19T00:00:00+00:00

主要介绍HDFS的基本组成和原理、Hadoop 2.0对HDFS的改进、HADOOP命令和基本API、通过读Google File System论文来理解HDFS设计理念。

Hadoop是Apache一个开源的分布式计算平台，核心是以HDFS分布式文件系统和MapReduce分布式计算框架组成，为用户提供了一套底层透明的分布式基础设施。

HDFS是Hadoop分布式文件系统，具有高容错性、高伸缩性，允许用户基于廉价精简部署，构件分布式文件系统，为分布式计算存储提供底层支持。MapReduce提供简单的API，允许用户在不了解底层细节的情况下，开发分布式并行程序，利用大规模集群资源，解决传统单机无法解决的大数据处理问题，其设计思想起源Google GFS、MapReduce Paper。

在Mac上搭建Hadoop单机版环境

从 https://hadoop.apache.org 下载二进制的安装包，具体配置可进行Google。配置完成后，在执行HDFS命令时会提示 Unable to load native-hadoop library for your platform...using buildin-java classes..，运行Hadoop的二进制包与当前平台不兼容。为解决该问题，需在机器上编译Hadoop的源码包，用编译生成的native library替换二进制包中的相同文件。编译Hadoop源码需安装cmake、protobuf、maven、openssl组件。

$ mvn package -Pdist,native -DskipTests -Dtar

在编译hadoop-2.10.1的hadoop-pipes模块时出现错误，原因是由于openssl的版本不兼容，机器上的是32位，而实际需要64位。最后从github下载openssl-1.0.2q.tar.gz安装包，通过源码安装，并在/etc/profile中配置环境变量：

export OPENSSL_ROOT_DIR=/usr/local/Cellar/openssl@1.0.2q
export OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl@1.0.2q/include/

然后重新执行maven命令，hadoop源码编译通过了。最后将hadoop-dist目录下的native包拷贝到hadoop二进制的源码包下就可以了。

Hadoop 1.0架构

GFS cluster由一个master节点和多个chunkserver节点组成，多个GFS client可以对其进行访问，其中每一个通常都是运行用户级服务器进程的商用linux机器。大文件会被分为大小固定为64MB的块。

HDFS 1.0中的角色划分：

NameNode：对应论文中的GFS master，NN维护整个文件系统的文件目录树，文件目录的元信息和文件数据块索引；元数据镜像FsImage和操作日志EditLog存储在本地，但整个系统存在单点问题，存在SPOF（Simple Point Of Filure）。
SecondNameNode：又名CheckPoint Node用于定期合并FsImage和EditLog文件，其不接收客户端的请求，作为NameNode的冷备份。
DataNode：对应GFS中的chunkserver，实际的数据存储单元（以Block为单位），数据以普通文件形式保存在本地文件系统。
Client：与HDFS交互，进行读写、创建目录、创建文件、复制、删除等操作。HDFS提供了多种客户端，命令行shell、Java api、Thrift接口、C library、WebHDFS等。

HDFS的chunk size大小为64MB，这比大多数文件系统的block大小要大。较大的block size优势在于，在获取块位置信息时候，减少了client与NameNode交互的次数。其次，由于在大的block上，客户端更有可能在给定块上执行许多操作，可以与NameNode保持一个长时间的TCP连接来减少网络开销。第三，减少了存储在NameNode上的元数据的大小，这就可以使得NameNode将元数据信息保存在Memory中。

HDFS Metadata元数据信息

GFS论文中Master节点中存储了三种元数据信息：文件和数据块的namespace、从files文件到chunkserver的映射关系及chunk副本数据位置。前两种数据是通过EditLog存储在本地磁盘的，而chunk location则是在Master启动时向chunk server发起请求进行获取。

一个大文件由多个Data Block数据集合组成，每个数据块在本地文件系统中是以单独的文件存储的。谈谈数据块分布，默认布局规则（假设复制因子为3）：

第一份拷贝写入创建文件的节点（快速写入数据）；
第二份拷贝写入同一个rack内的节点；
第三份拷贝写入位于不同rack的节点（应对交换机故障）；

HDFS写流程，对于大文件，与HDFS客户端进行交互，NN告知客户端第一个Block放在何处？将数据块流式的传输到另外两个数据节点。FsImage和EditLog组件的目的：

NameNode的内存中有整个文件系统的元数据，例如目录树、块信息、权限信息等，当NameNode宕机时，内存中的元数据将全部丢失。为了让重启的NameNode获得最新的宕机前的元数据，才有了FsImage和EditLog。
FsImage是整个NameNode内存中元数据在某一时刻的快照（Snapshot），FsImage不能频繁的构建，生成FsImage需要花费大量的内存，目前FsImage只在NameNode重启才构建。
而EditLog则记录的是从这个快照开始到当前所有的元数据的改动。如果EditLog太多，重放EditLog会消耗大量的时间，这会导致启动NameNode花费数小时之久。

为了解决以上问题，引入了Second NameNode组件，我们需要一个机制来帮助我们减少EditLog文件的大小和构建fsimage以减少NameNode的压力。这与windows的恢复点比较像，允许我们对OS进行快照。

HDFS数据读写流程

HDFS设计目标是减少Master参与各种数据操作，在这种背景下，描述一下client、master和chunkserver如何进行交互来实现数据交互、原子性记录追加。

client向master发起请求询问哪个chunkserver持有当要写入的块及当前数据块的副本位置？master用primary标识符以及对应副本位置返回给client以进行cache（失效后会再次向master发起请求）；
client将数据写入到所有的副本中（不分先后顺序），每个chunkserver都会将数据写入内部的LRU buffer中直到数据被访问或过期；
一旦所有的副本确认已经收到了数据，client会发送一个write request到primary，说明之前的数据已完全写入完成。primary replica会返回一个连续的流水号给client；
primary replica将write请求转发到所有的副本，每一个副本按照serial number的顺序执行变更，所有副本给primary返回结果则表示它们已经完成了操作。
primary将信息返给client，包括replica在执行操作时发生的error。

DataFlow数据流转的过程，data是被线性的在一系列的chunkserver之间进行推送，而不是其它那些通过topology进行分发。这样做是为了尽量地避免network bottlenecks及high-latency links问题。举个例子，client推送数据到chunkserver S1, S1会将数据推送给离它最近的chunkserver S2或S3。本质是通过IP address之间距离来判断，network之间的hops。此外，数据的传输是通过TCP连接来完成的，一旦chunkserver收到一些数据，它会立刻进行数据转发。

Hadoop 2.0对HDFS的改进

Hdfs 1.0的问题：NameNode SPOF问题，NameNode挂掉了整个集群不可用，此外，Name Node内存受限，整个集群的size受限于NameNode的内存空间。Hadoop 2.0的解决方案，HDFS HA提供名称节点热备机制，HDFS Federation管理多个命名空间。

NameNode HA设计思路

如何实现主和备NameNode状态同步，主备一致性？
脑裂的解决，集群产生了两个leader导致集群行为不一致，仲裁以及fencing的方式。
透明切换（failover），NameNode切换对外透明，当主NameNode切换到另一台机器时，不应该导致正在连接的Client，DataNode失效。

对于NameNode主备一致实现，Active NameNode启动后提供服务，并把EditLog写入到本地和QJM*中，Standby NameNode周期性的从QJM中拉取EditLog，保持与active的状态一致。DataNode同时向两个NameNode发送BlockReport。
HA之脑裂的解决，QJM的fencing，确保只有一个NN能成功。DataNode的fencing，确保只有一个NN能命令DN。每个NN改变状态的时候，会向DN发送自己的状态和一个序列号(类似Epoch Numbers)。当收到NN提供了更大序列号时，DN更新序列号，之后只接收新NN的命令。
主备切换的实现ZKFC，作为独立的进程存在，负责控制NameNode的主备切换，ZKFC会监测NameNode的健康状况，当Active NameNode出现异常时会通过Zookeeper集群进行一次主备选举。

k8s核心组件及pod组件间通信原理

2021-04-25T00:00:00+00:00

介绍k8s的核心组件如Pod、Controller、StatefulSet等组件以及组件间通信原理Service及Ingress服务。

Docker实例及Pods间的通信原理

在通信协议中“网络栈”包括有：网卡（network interface）、回环设备（loopback device）、路由表（routing table）和iptables规则。在docker中启动一个容器可使用宿主机的网络栈（-net=host），指定-net后默认不开启network namespace空间：

$ docker run –d –net=host --name nginx-host nginx

nginx服务启动后默认监听主机80端口，容器启动后会创建一个docker0的网桥。docker实例通过Veth Pair与宿主机建立连接关系，其中Veth的一端在容器内，另一段插在宿主机的docker0网桥上。同一台宿主机上的容器实例间的网络是互通的，请求路由是通过宿主机向外转发。ping 172.17.0.3时匹配0.0.0.0的路由网关，意味着这是一条直连规则，匹配该规则的都走主机的eth0网卡。

在容器内ping other-ip时需将other-ip转换为mac地址（通arp地址解析获取硬件地址），容器内无法完成此操作容器通过默认路由在宿主机解析，获取请求mac地址然后从容器经过docker0中 Veth Pair另外一端通过宿主机将请求转发出去。

在docker的默认配置下，一台宿主机上的docker0网桥，和其他宿主机上的docker0网桥，没有任何关联，它们互相之间也没办法连通。所以，连接在这些网桥上的容器，自然也没办法进行通信了。

1. 容器跨主机网络（Overlay Network）

flannel 项目是coreOS公司主推的容器网络方案，事实上，flannel项目本身只是一个框架，真正为我们提供容器网络功能的，是 flannel的后端实现。有3种方式，基于vxlan、host-gw和udp进行实现。flannel UDP模式提供的其实是一个三层的Overlay网络。

node 1上有一个容器container-1，它的IP地址是100.96.1.2，对应的docker0网桥的地址是100.96.1.1/24。

node 2上有一个容器container-2，它的IP地址是100.96.2.3，对应的docker0网桥的地址是100.96.2.1/24。

$ ip route
default via 10.168.0.1 dev eth0
100.96.0.0/16 dev flannel0 proto kernel scope link src 100.96.1.0
100.96.1.0/24 dev docker0 proto kernel scope link src 100.96.1.1
10.168.0.0/24 dev eth0 proto kernel scope link src 10.168.0.2

node跨主机通信引入了flannel组件，从node1请求node2在每个组件对请求包进行分发（docker0、flannel）,flannel包含子网在node2地址在subnet范围内，则对请求包进行分发最终达到node2上的container。

flannel项目里一个非常重要的概念子网（subnet），在由flannel管理的容器网络里，一台宿主机上的所有容器，都属于该宿主机被分配的一个“子网”。在我们的例子中，node 1 的子网是100.96.1.0/24，container-1 的IP地址是100.96.1.2。node 2的子网是 100.96.2.0/24，container-2的 IP地址是100.96.2.3。

TUN设备的原理，这正是一个从用户态向内核态的流动方向（Flannel进程向TUN设备发送数据包），所以 Linux内核网络栈就会负责处理这个IP包，具体的处理方法，就是通过本机的路由表来寻找这个IP包的下一步流向。

课后问题：我觉得不合适，mac地址为硬件地址当与请求节点直连时可通过mac实现，但当目的node不在subnet时，还是要需要rarp地址逆解析）转换为ip 然后将数据包分发到目的node。

VXLAN，即 Virtual Extensible LAN（虚拟可扩展局域网），是 Linux 内核本身就支持的一种网络虚似化技术。所以说，VXLAN 可以完全在内核态实现上述封装和解封装的工作，从而通过与前面相似的“隧道”机制，构建出覆盖网络（Overlay Network）。

设计思想是在现有的三层网络之上，“覆盖”一层虚拟的、由内核 VXLAN 模块负责维护的二层网络，使得连接在这个 VXLAN 二层网络上的“主机”（虚拟机或者容器都可以）之间，可以像在同一个局域网（LAN）里那样自由通信。

2. kubernetes的网络模型与CNI网络插件

kubernetes使用cni作为pod的容器间通信的网桥（与docker0功能相同），初始化pod网络流程：

创建Infra容器调用cni插件初始化infra容器网络（插件位置：/opt/cni/bin/flannel），开始dockershim设置的一组 CNI环境变量（枚举值ADD、DELETE），用于表示将容器的VethPair插入或从cni0网桥移除。与此同时，cni bridge插件检查cni网桥在宿主机上是否存在，若不存在则进行创建。接着，cni bridge插件在network namespace创建VethPair，将其中一端插入到宿主机的cni0网桥，另一端直接赋予容器实例eth0，cni插件把容器ip提供给dockershim 被kubelet用于添加到pod的status字段。

接下来，cni bridge调用cni ipam插件从ipam.subnet子网中给容器eth0网卡分配ip地址同时设置default route配置，最后cni bridge插件为cni网桥设置ip地址。

三层网络特点：通过ip route得到数据传输路由，跨节点传输ip包时会将route中geteway的mac地址作为ip包的请求头用于数据包传输，到达目标node时进行拆包，然后根据ip包去除dest地址并根据当前node的route列表，将数据包转发到相应container中。优缺点：避免了额外的封包、拆包操作性能较好，但要求集群宿主机间是二层连通的；隧道模式：隧道模式通过BGP维护路由关系，其会将集群节点的ip 对应gateway 保存在当前节点的路由中，在请求发包时数据包mac头地址指定为路由gateway地址。优缺点：需维护集群中所有container的连接信息，当集群中容器数量较大时BGP会爆炸增长，此时可切换至集群中某几个节点维护网络关系，剩余的节点从主要节点同步路由信息。

k8s使用NetworkPolicy定义pod的隔离机制，使用ingress和egress定义访问策略（限制可请求的pod及namespace、port端口），其本质上是k8s网络插件在宿主机上生成了iptables路由规则；

容器编排和Kubernetes作业管理

随笔写一下，K8S中pod的概念，其本质是用来解决一系列容器的进程组问题。生产环境中，往往部署的多个docker实例间具有亲密性关系，类似于操作系统中进程组的概念。

Pod是K8s中最小编排单位，将这个设计落实到API对象上，Pod 扮演的是传统部署环境里“虚拟机”的角色，把容器看作是运行在这个“机器”里的“用户程序”。比如，凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

在Pod的实现需要使用一个中间容器，这个容器叫作Infra容器。而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。

Pod的进阶使用中有一些高级组件，Secret、ConfigMap、Downward API和ServiceAccountToken组件，Secret的作用，是帮你把Pod想要访问的加密数据，存放到Etcd中。然后，你就可以通过在Pod的容器里挂载Volume的方式，访问到这些Secret里保存的信息了。

ConfigMap保存的是不需要加密的、应用所需的配置信息。你可以使用kubectl create configmap从文件或者目录创建ConfigMap，也可以直接编写ConfigMap对象的YAML文件。

Deployment是控制器组件，其定义编排比较简单，确保携带了app=nginx标签的pod的个数，永远等于spec.replicas指定的个数。它实现了Kubernetes 项目中一个非常重要的功能：Pod 的“水平扩展 / 收缩”（horizontal scaling out/in）。这个功能，是从PaaS时代开始，一个平台级项目就必须具备的编排能力。

Deployment并不是直接操作Pod的，而是通过ReplicaSet进行管理。一个ReplicaSet 对象，其实就是由副本数目的定义和一个 Pod模板组成的。不难发现，它的定义其实是Deployment的一个子集。

$ kubectl scale deployment nginx-deployment --replicas=4deployment.apps/nginx-deployment scaled
$ kubectl create -f nginx-deployment.yaml --record

通过kubectl edit指令可进行滚动更新，保存退出，Kubernetes 就会立刻触发“滚动更新”的过程。你还可以通过 kubectl rollout status 指令查看 nginx-deployment 的状态变化，将一个集群中正在运行的多个 Pod 版本，交替地逐一升级的过程，就是“滚动更新”。

$ kubectl rollout status deployment/nginx-deploymentWaiting for rollout to finish: 2 out of 3 new replicas have been updated...deployment.extensions/nginx-deployment successfully rolled out

深入理解StatefulSet有状态应用

StatefulSet 的核心功能，就是通过某种方式记录这些状态，然后在 Pod 被重新创建时，能够为新 Pod 恢复这些状态。StatefulSet这个控制器的主要作用之一，就是使用Pod 模板创建 Pod 的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。

当 StatefulSet 的“控制循环”发现 Pod 的“实际状态”与“期望状态”不一致，需要新建或者删除 Pod 进行“调谐”的时候，它会严格按照这些 Pod 编号的顺序，逐一完成这些操作。

DaemonSet 的主要作用，是让你在 Kubernetes 集群里，运行一个Daemon Pod。所以，这个 Pod 有如下三个特征：这个Pod运行在Kubernetes 集群里的每一个节点（Node）上；每个节点上只有一个这样的 Pod 实例；当有新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。

场景比如各种监控组件和日志组件、各种存储插件的 ` Agent ` 组件、各种网络插件的 Agent 组件都必须在每个节点上部署一个实例。

K8S中jOb和cronJob的使用频率不多，Deployment、StatefulSet，以及 DaemonSet 这三个编排概念主要编排“在线业务”，即：Long Running Task（长作业）。

Operator 的工作原理，实际上是利用了 Kubernetes 的自定义 API 资源（CRD），来描述我们想要部署的“有状态应用”；然后在自定义控制器里，根据自定义 API 对象的变化，来完成具体的部署和运维工作。

kafka client客户端实践及原理剖析

2021-03-02T00:00:00+00:00

主要描述kafka java client的一些实践，以及对client操作数据的一些原理进行剖析。

kafka对集群部署环境的一些考虑，kafka 由 Scala 语言和 Java 语言编写而成，编译之后的源代码就是普通的“.class”文件。本来部署到哪个操作系统应该都是一样的，但是不同操作系统的差异还是给 Kafka 集群带来了相当大的影响。

主流的操作系统有3种：windows、linux和macOS，考虑到操作系统与kafka的适配性，linux系统显然要比其它两个更加合适部署kafka，主要在I/O模式的使用、数据网络传输效率、社区支持度三个方面支持比较好。

linux中的系统调用select函数属于I/O多路复用模型，大名鼎鼎的epoll系统调用则介于I/O 多路复用、信号驱动I/O模型。因此在这一点上将kafka 部署在Linux 上是有优势的，因为能够获得更高效的 I/O性能。零拷贝（Zero Copy）技术，就是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝从而实现快速的数据传输，Linux 平台实现了这样的零拷贝机制。

对于磁盘I/O性能，普通环境使用机械硬盘，不需要搭建RAID。对于磁盘容量，需根据消息数、留存时间预估磁盘容量，实际使用中建议预留20%～30%的磁盘空间。对于网络带宽，需根据实际带宽速度和业务SLA预估服务器数量，对于千兆网络，建议每台服务器按照700mps来计算，避免大流量下的丢包问题。

集群配置中一些重要的参数，Broker端的一些参数有：

1）log.dirs指定了broker需要使用的若干个文件目录路径，而log.dir结尾没有s，说明它只能表示单个路径，它是补充上一个参数用的。当挂载多个目录时，其好处在于提升读写性能、能够实现故障转移；

2）zookeeper的配置，zookeeper.connect可以指定它的值为zk1:2181,zk2:2181,zk3:2181。

3）第三组是与broker连接相关的，listeners学名叫监听器，其实就是通过PLAINTEXT://localhost:9092协议连接kafka 服务的。advertised.listeners，和 listeners 相比多了个advertised，其是在外网连接kafka的地址。

4）第四组参数是关于 topic 管理的，auto.create.topics.enable，是否允许自动创建topic。unclean.leader.election.enable：是否允许 unclean Leader 选举。auto.leader.rebalance.enable：是否允许定期进行 Leader选举。

看一些topic级别的参数，在启动kafka时设置jvm的一些参数：

1）retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。

2）retention.bytes：规定了要为该 topic 预留多大的磁盘空间。当前默认值是-1，表示可以无限使用磁盘空间。

3）KAFKA_HEAP_OPTS：指定堆大小，行业经验kafka默认堆栈大小为6g，KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。

$> export KAFKA_HEAP_OPTS=--Xms6g --Xmx6g
$> export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true
$> bin/kafka-server-start.sh config/server.properties

生产者消息分区机制原理剖析，Kafka 的消息组织方式实际上是三级结构：主题 - 分区 - 消息。其实分区的作用就是提供负载均衡的能力，或者说对数据进行分区的主要原因，就是为了实现系统的高伸缩性（scalability）。

所谓分区策略是决定生产者将消息发送到哪个分区的算法，常见的分区策略有轮询策略（Round-robin）、随机策略（Randomness）、按消息键保序策略（Key-ordering）。如下为自定义分区策略，从所有分区中找出哪些Leader 副本在南方的所有分区，然后随机挑选一个进行消息发送。

List partitions = cluster.partitionsForTopic(topic);
return partitions.stream()
  .filter(p ->isSouth(p.leader().host()))
  .map(PartitionInfo::partition).findAny().get();

在kafka中，压缩可能发生在两个地方：生产者端和broker端。让broker端重新压缩消息有2种例外情况，broker端指定了和producer端不同的压缩算法，broker端发生了消息格式转换。一句话总结压缩和解压缩的话，producer端压缩、broker端保持、consumer端解压缩。

客户端一些高级功能interceptor，与spring中的拦截器原理是一样的（aop），不影响真实业务逻辑调用。生产者要想添加interceptor，只需继承ProducerInterceptor<String, String>类。

无消息丢失配置如何实现？producer 永远要使用带有回调通知的发送 API，也就是说不要使用producer.send(msg)，而要使用 producer.send(msg, callback)。Kafka 中consumer 端的消息丢失就是这么一回事。要对抗这种消息丢失，办法很简单：维持先消费消息（阅读），再更新位移（书签）的顺序即可。

设置acks = all。acks 是 Producer 的一个参数，代表了你对“已提交”消息的定义。

设置retries 为一个较大的值。这里的retries 同样是Producer 的参数，对应前面提到的Producer自动重试。

确保消息消费完成再提交。consumer 端有个参数 enable.auto.commit，最好把它设置成 false，并采用手动提交位移的方式。

设置unclean.leader.election.enable = false、设置replication.factor >= 3、设置 min.insync.replicas > 1的配置。

public class ProducerClient {

    /* kafka用于防止消息丢失的因素: */
    // 1) 维持先消费消息（阅读），再更新位移（书签）的顺序即可。这样就能最大限度地保证消息不丢失。（消费者端 维持先消费， 再提交offset）

    // 2) unclean.leader.election.enable = false。这是 Broker 端的参数，它控制的是哪些 Broker 有资格竞选分区的 Leader。
    // 如果一个Broker落后原先的 Leader 太多，那么

    public static void main(String[] args) {
        Properties kafkaProp = new Properties();
        kafkaProp.put("bootstrap.servers", "localhost:9092");
        // 则表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”
        kafkaProp.put("acks", "all");
        kafkaProp.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        kafkaProp.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        // 开启kafka的gzip压缩, 向broker发送的每条message都是压缩的
        kafkaProp.put("compression.type", "gzip");

        // 开启生产者消息的幂等性, 保证底层message消息只会发送一次(用空间换，msg会多传一个字段 用于去重)
        kafkaProp.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
        // 2. producer生产者启用事务（在kafka 0.11开始的支持）
        kafkaProp.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "kafka-transactional");

        // 设置interceptor用于统计生产者发送消息延时
        List<String> interceptor = new ArrayList<>();
        interceptor.add("com.example.kakfa.interceptor.AvgLatencyProducerInterceptor");
        kafkaProp.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG, interceptor);

        Producer<String, String> client = new KafkaProducer<>(kafkaProp);
        // 1. send调用时使用回调函数callback, exception 可判断消息是否提交成功，消费者 “位移”类似于我们看书时使用的书签
        client.send(new ProducerRecord<>("", ""), (recordMetadata, exception) -> {
//            RecordMetadata var1, Exception var2
        });

        // 2. 在kafka-client客户端中使用transactional事务机制, 用于提交kafka message消息
        client.initTransactions();
        try {
            client.beginTransaction();
            client.send(new ProducerRecord<>("topicA", ""));
            client.send(new ProducerRecord<>("topicB", ""));
            client.commitTransaction();
        } catch (ProducerFencedException ex) {
            client.abortTransaction();
        }
    }
}

kafka社区决定采用tcp而不是http，能够利用TCP 本身提供的一些高级功能，比如多路复用请求以及同时轮询多个连接的能力，目前已知的HTTP 库在很多编程语言中都略显简陋。

何时创建TCP 连接？目前我们的结论是这样的，TCP 连接是在创建 KafkaProducer 实例时建立的。TCP 连接还可能在两个地方被创建：一个是在更新元数据后，另一个是在消息发送时。

何时关闭 TCP 连接？Producer 端关闭TCP连接的方式有两种：一种是用户主动关闭，一种是 Kafka 自动关闭。

开启kafka生产者消息幂等性、producer生产者启用事务需要在producer的properties中设置以下配置：

// 开启生产者消息的幂等性, 保证底层message消息只会发送一次(用空间换，msg会多传一个字段 用于去重)
kafkaProp.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);
// 2. producer生产者启用事务（在kafka 0.11开始的支持）
kafkaProp.put(ProducerConfig.TRANSACTIONAL_ID_CONFIG, "kafka-transactional");

Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者或消费者实例（Consumer Instance），它们共享一个公共的 ID，这个 ID 被称为 Group ID。组内的所有消费者协调在一起来消费订阅主题（Subscribed Topics）的所有分区（Partition）。

Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。比如某个 Group 下有 20 个 Consumer 实例，它订阅了一个具有 100 个分区的 Topic。正常情况下，Kafka 平均会为每个 Consumer 分配 5 个分区。这个分配的过程就叫 Rebalance。

那么 Consumer Group 何时进行 Rebalance 呢？Rebalance 的触发条件有 3 个。

1）组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组，抑或是有 Consumer 实例崩溃被“踢出”组。

2）订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题，比如 consumer.subscribe(Pattern.compile("t.*c")) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中，你新创建了一个满足这样条件的主题，那么该 Group 就会发生 Rebalance。

3）订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时，就会触发订阅该主题的所有 Group 开启 Rebalance。

分析spark在yarn-client和yarn-cluster模式下启动

2021-02-23T00:00:00+00:00

文章分析spark在yarn-client、yarn-cluster模式下启动的流程，yarn是apache开源的一个资源管理的组件。JobTracker在yarn中大致分为了三块：一部分是ResourceManager，负责Scheduler及ApplicationsManager；一部分是ApplicationMaster，负责job生命周期的管理；最后一部分是JobHistoryServer，负责日志的展示；

先看一个spark官网上通过yarn提交用户应用程序的spark-submit脚本，从该脚本开始分析在yarn环境下执行的流程。

./bin/spark-submit \
  --class org.apache.spark.examples.SparkPi \
  --master yarn \
  --deploy-mode cluster \  # can be client for client mode
  --executor-memory 20G \
  --num-executors 50 \
  /path/to/examples.jar \
  1000

在分析源码前需要在父pom.xml中引入yarn资源代码模块，使得其class文件加载到classpath中。

<!-- See additional modules enabled by profiles below -->
<module>resource-managers/yarn</module>

与standalone模式应用启动一样，SparkSubmit#runMain(SparkSubmitArguments, Boolean)是应用程序的入口。由于是在yarn环境下启动，在前期准备submit环境时会有差异，差异点在prepareSubmitEnvironment(SparkSubmitArguments, Option[HadoopConfiguration])方法，在方法中会依args.master、args.deployMode进行模式匹配，当master为yarn时，会将childMainClass设置为org.apache.spark.deploy.yarn.YarnClusterApplication作为资源调度的启动类。

private[deploy] def prepareSubmitEnvironment(
   args: SparkSubmitArguments,
   conf: Option[HadoopConfiguration] = None)
   : (Seq[String], Seq[String], SparkConf, String) = {
    // Set the cluster manager
    val clusterManager: Int = args.master match {
      case "yarn" => YARN
      case "yarn-client" | "yarn-cluster" =>
        logWarning(s"Master ${args.master} is deprecated since 2.0." +
          " Please use master \"yarn\" with specified deploy mode instead.")
        YARN
    }
    if (deployMode == CLIENT) {
    /* 在client模式下 用户程序直接在submit内通过反射机制执行，此时用户自己打的jar和--jars指定的jar都会被加载到classpath中  */
    	childMainClass = args.mainClass
    	if (localPrimaryResource != null && isUserJar(localPrimaryResource)) {
       	childClasspath += localPrimaryResource
    	}
    	if (localJars != null) { childClasspath ++= localJars.split(",") }
    }
    // In yarn-cluster mode, use yarn.Client as a wrapper around the user class
    if (isYarnCluster) {
      /* YARN_CLUSTER_SUBMIT_CLASS在cluster模式下为org.apache.spark.deploy.yarn.YarnClusterApplication */
      childMainClass = YARN_CLUSTER_SUBMIT_CLASS
    }
    (childArgs, childClasspath, sparkConf, childMainClass)
}

submit()需要的环境准备好之后，通过mainClass构建spark应用，由于目前分析在yarn client模式下的启动，mainClass并不是SparkApplication的实例。因而，app类型为JavaMainApplication。

val app: SparkApplication = if (classOf[SparkApplication].isAssignableFrom(mainClass)) {
      mainClass.newInstance().asInstanceOf[SparkApplication]
} else {
  // SPARK-4170
  if (classOf[scala.App].isAssignableFrom(mainClass)) {
  logWarning("Subclasses of scala.App may not work correctly. Use a main() method instead.")
  }
  new JavaMainApplication(mainClass)
}
/* standalone模式在 SparkSubmit#prepareSubmitEnvironment(args)中将childMainClass设置为RestSubmissionClient */
app.start(childArgs.toArray, sparkConf)

在start()方法中会通过反射获取得到main方法，然后进行调用执行用户jar包中的代码。进入用户程序（main方法）之后，存在两个重要的类SparkConf和SparkContext，根据config配置信息实例化context上下文。

override def start(args: Array[String], conf: SparkConf): Unit = {
  val mainMethod = klass.getMethod("main", new Array[String](0).getClass)
  if (!Modifier.isStatic(mainMethod.getModifiers)) {
    throw new IllegalStateException("The main method in the given main class must be static")
  }
  val sysProps = conf.getAll.toMap
  sysProps.foreach { case (k, v) =>
    sys.props(k) = v
  }
  mainMethod.invoke(null, args)
}
/* spark application中使用sparkConf和sparkContext加载环境相关配置 */
val config = new SparkConf().setAppName("spark-app")
	.set("spark.app.id", "spark-mongo-connector")
val sparkContext = new SparkContext(config)

在SparkContext#createTaskScheduler(SparkContext, String, String)方法中会根据master确定scheduler和backend。由于master为yarn，在getClusterManager(String)中确定cm的类型为YarnClusterManager。在yarn-client模式下调用createTaskScheduler()和createSchedulerBackend()通过masterUrl和deployMode可得 scheduler为YarnScheduler、backend为YarnClientSchedulerBackend。

/* 当masterUrl为外部资源时 (Yarn、Mesos、K8s)，走此处的逻辑: (yarn)cluster模式走YarnClusterScheduler、
        (yarn)client走YarnScheduler用于资源调度 */
case masterUrl =>
  val cm = getClusterManager(masterUrl) match {
    case Some(clusterMgr) => clusterMgr
    case None => throw new SparkException("Could not parse Master URL: '" + master + "'")
  }
  val scheduler = cm.createTaskScheduler(sc, masterUrl)
  val backend = cm.createSchedulerBackend(sc, masterUrl, scheduler)
  cm.initialize(scheduler, backend)

进入YarnClientSchedulerBackend#start()方法，创建client对象去提交任务，然后调用client.submitApplication()使用AM向ResourceManager申请资源。在super.start()中会启动CoarseGrainedSchedulerBackend，等待app的启动成功。

override def start() {
  /* 动态申请资源的时候才会调用 SchedulerBackendUtils#getInitialTargetExecutorNumber */
  totalExpectedExecutors = SchedulerBackendUtils.getInitialTargetExecutorNumber(conf)
  client = new Client(args, conf)
  /* 将Application提交之后  # 可看ApplicationMaster#main()的启动 */
  bindToYarn(client.submitApplication(), None)
  // SPARK-8687: Ensure all necessary properties have already been set before
  // we initialize our driver scheduler backend, which serves these properties
  // to the executors
  /* 调用YarnSchedulerBackend的父类CoarseGrainedSchedulerBackend#start()方法，在start()方法里实现自己 */
  super.start()
  waitForApplication()
}

进一步看client.submitApplication()提交应用给AppMaster前，如何初始化ContainerContext运行环境、java opts和运行AM的指令，进入createContainerLaunchContext()方法，client模式下amClass为org.apache.spark.deploy.yarn.ExecutorLauncher。在yarn client模式下，都是有appMaster向resourceManager申请--num-executor NUM参数指定的数目。

/**
 * Set up a ContainerLaunchContext to launch our ApplicationMaster container.
 * This sets up the launch environment, java options, and the command for launching the AM.
 */
private def createContainerLaunchContext(newAppResponse: GetNewApplicationResponse) {
  // 设置环境变量及spark-java-opts
  val launchEnv = setupLaunchEnv(appStagingDirPath, pySparkArchives)
  /*
   * 这个函数的主要作用是将用户自己打的jar包(--jars指定的jar发送到分布式缓存中去)，并设置了spark.yarn.user.jar
   * 和spark.yarn.secondary.jars这两个参数, 然后这两个参数会被封装程 --user-class-path 传递给
   * executor使用
   */
  val localResources = prepareLocalResources(appStagingDirPath, pySparkArchives)
  val amContainer = Records.newRecord(classOf[ContainerLaunchContext])
  amContainer.setLocalResources(localResources.asJava)
  amContainer.setEnvironment(launchEnv.asJava)
  // Add Xmx for AM memory
  javaOpts += "-Xmx" + amMemory + "m"
  val tmpDir = new Path(Environment.PWD.$$(), YarnConfiguration.DEFAULT_CONTAINER_TEMP_DIR)
  javaOpts += "-Djava.io.tmpdir=" + tmpDir
  /* 判断是否在cluster集群环境来确定AMclass, client模式下为ExecutorLauncher, 通过AMclass及一些参数构建command 进而构建amContainer */
  val amClass =
  if (isClusterMode) {
    Utils.classForName("org.apache.spark.deploy.yarn.ApplicationMaster").getName
  } else {
    Utils.classForName("org.apache.spark.deploy.yarn.ExecutorLauncher").getName
  }
  amContainer
}

在super.start()需要重点看一下YarnSchedulerBackend的父类CoarseGrainedSchedulerBackend的start()方法，方法体内创建了一个driverEndpoint的RPC客户端。在YarnSchedulerBackend类中覆盖了createDriverEndpointRef()方法，用子类YarnDriverEndpoint替代DriverEndpoint并重写了其onDisconnected()方法（是由于协议的不同）。

/* YarnSchedulerBackend启动时实例化，负责根ApplicationMaster进行通信 */
private val yarnSchedulerEndpoint = new YarnSchedulerEndpoint(rpcEnv)
override def start() {
	// TODO (prashant) send conf instead of properties
	driverEndpoint = createDriverEndpointRef(properties)
}

yarn-client代码分析完之后，进入ApplicationMaster#main(Array[String])，在上文client#createContainerLaunchContext()时，指定amClass为org.apache.spark.deploy.yarn.ExecutorLauncher（main方法中封装了ApplicationMaster），最终调用runExecutorLauncher()运行executor。

private def runExecutorLauncher(): Unit = {
  val hostname = Utils.localHostName
  val amCores = sparkConf.get(AM_CORES)
  rpcEnv = RpcEnv.create("sparkYarnAM", hostname, hostname, -1, sparkConf, securityMgr,
                         amCores, true)
  // The client-mode AM doesn't listen for incoming connections, so report an invalid port.
  registerAM(hostname, -1, sparkConf, sparkConf.getOption("spark.driver.appUIAddress"))
  // The driver should be up and listening, so unlike cluster mode, just try to connect to it
  // with no waiting or retrying.
  val (driverHost, driverPort) = Utils.parseHostPort(args.userArgs(0))
  val driverRef = rpcEnv.setupEndpointRef(
    RpcAddress(driverHost, driverPort),
    YarnSchedulerBackend.ENDPOINT_NAME)
  addAmIpFilter(Some(driverRef))
  /* 向resourceManager申请根启动--num-executor相同的资源 */
  createAllocator(driverRef, sparkConf)
  // In client mode the actor will stop the reporter thread.
  reporterThread.join()
}

在appMaster#createAllocator()会进入到allocator#allocateResources()申请资源，接着进入handleAllocatedContainers(Seq[Container])方法。在runAllocatedContainers()中在已经申请到的container中运行executor。

/**
 * Launches executors in the allocated containers.
 */
private def runAllocatedContainers(containersToUse: ArrayBuffer[Container]): Unit = {
  new ExecutorRunnable(
    Some(container), conf, sparkConf, driverUrl, executorId, executorHostname,executorMemory,
    executorCores, appAttemptId.getApplicationId.toString, securityMgr, localResources
  ).run()
}

在ExecutorRunnable#startContainer()中会设置本地相关环境变量，然后nmClient会启动container。

def startContainer(): java.util.Map[String, ByteBuffer] = {
  /* 此处设置spark.executor.extraClassPath为系统环境变量 */
  ctx.setLocalResources(localResources.asJava)
  // Send the start request to the ContainerManager
  try {
    nmClient.startContainer(container.get, ctx)
  } catch {
    case ex: Exception =>
    throw new SparkException(s"Exception while starting container ${container.get.getId}" +
                             s" on host $hostname", ex)
  }
}

在CoarseGrainedExecutorBackend#main(Array[String])启动时会执行run(driverUrl, executorId, hostname, cores, appId, workerUrl, userClassPath)的方法。先创建env然后根据env使用CoarseGrainedExecutorBackend作为executor创建rpc。

/* 创建env主要用与Rpc提交相关的请求 */
val env = SparkEnv.createExecutorEnv(
driverConf, executorId, hostname, cores, cfg.ioEncryptionKey, isLocal = false)

env.rpcEnv.setupEndpoint("Executor", new CoarseGrainedExecutorBackend(
	env.rpcEnv, driverUrl, executorId, hostname, cores, userClassPath, env))
workerUrl.foreach { url =>
	env.rpcEnv.setupEndpoint("WorkerWatcher", new WorkerWatcher(env.rpcEnv, url))
}
env.rpcEnv.awaitTermination()

rpc在onStart()的时候会发送RegisterExecutor的请求，用于注册executor的相关信息。

override def onStart() {
  logInfo("Connecting to driver: " + driverUrl)
  rpcEnv.asyncSetupEndpointRefByURI(driverUrl).flatMap { ref =>
    // This is a very fast action so we can use "ThreadUtils.sameThread"
    driver = Some(ref)
    ref.ask[Boolean](RegisterExecutor(executorId, self, hostname, cores, extractLogUrls))
  }(ThreadUtils.sameThread).onComplete {
    // This is a very fast action so we can use "ThreadUtils.sameThread"
    case Success(msg) =>
    // Always receive `true`. Just ignore it
    case Failure(e) =>
    exitExecutor(1, s"Cannot register with driver: $driverUrl", e, notifyDriver = false)
  }(ThreadUtils.sameThread)
}

Driver端CoarseGrainedSchedulerBackend#receiveAndReply(RpcCallContext)在收到executor注册请求时，会reply一个已经注册成功的响应。

executorRef.send(RegisteredExecutor)
// Note: some tests expect the reply to come after we put the executor in the map
context.reply(true)
listenerBus.post(
SparkListenerExecutorAdded(System.currentTimeMillis(), executorId, data))

executor收到响应后会启动一个exectuor，接下来就是等待Driver发送过来要进行调度的任务（用case LaunchTask匹配请求）。executor执行launchTask()，创建TaskRunner任务运行的流程就与standalone模式相同，yarn-client模式下spark任务提交以及运行的流程就是这样。

override def receive: PartialFunction[Any, Unit] = {
  /* Driver响应executor注册成功时接收的请求 */
  case RegisteredExecutor =>
    logInfo("Successfully registered with driver")
    try {
      executor = new Executor(executorId, hostname, env, userClassPath, isLocal = false)
    } catch {
      case NonFatal(e) =>
      exitExecutor(1, "Unable to create executor due to " + e.getMessage, e)
    }
  /* Driver发送过来要进行调度的任务 */
  case LaunchTask(data) =>
    if (executor == null) {
      exitExecutor(1, "Received LaunchTask command but executor was null")
    } else {
      val taskDesc = TaskDescription.decode(data.value)
      logInfo("Got assigned task " + taskDesc.taskId)
      executor.launchTask(this, taskDesc)
    }
}

接下来分析spark app在yarn cluster模式下的启动流程，主要流程和client模式一样，都是从SparkSubmit开始分析，启动环境的差异在于prepareSubmitEnvironment()方法。在cluster模式下会设置childMainClass为org.apache.spark.deploy.yarn.YarnClusterApplication。

// In yarn-cluster mode, use yarn.Client as a wrapper around the user class
if (isYarnCluster) {
  childMainClass = YARN_CLUSTER_SUBMIT_CLASS
  if (args.isPython) {
     childArgs += ("--primary-py-file", args.primaryResource)
     childArgs += ("--class", "org.apache.spark.deploy.PythonRunner")
  } else if (args.isR) {
     val mainFile = new Path(args.primaryResource).getName
     childArgs += ("--primary-r-file", mainFile)
     childArgs += ("--class", "org.apache.spark.deploy.RRunner")
  } else {
     if (args.primaryResource != SparkLauncher.NO_RESOURCE) {
        childArgs += ("--jar", args.primaryResource)
     }
     childArgs += ("--class", args.mainClass)
  }
  if (args.childArgs != null) {
     args.childArgs.foreach { arg => childArgs += ("--arg", arg) }
  }
}

在sparkContext创建taskScheduler时，会设置其scheduler为YarnClusterScheduler，SchedulerBackend为YarnClusterSchedulerBackend，作为task调度的容器与client模式是有差异的。

spark standalone模式启动源码分析

2021-02-18T00:00:00+00:00

spark目前支持以standalone、Mesos、YARN、Kubernetes等方式部署，本文主要分析apache spark在standalone模式下资源的初始化、用户application的提交，在spark-submit脚本提交应用时，如何将–extraClassPath等参数传递给Driver等相关流程。

从spark-submit.sh提交用户app开始进行分析，--class 为jar包中的main类，/path/to/examples.jar为用户自定义的jar包、1000为运行SparkPi所需要的参数（基于spark 2.4.5分析）。

# Run on a Spark standalone cluster in client deploy mode
./bin/spark-submit \
  --class org.apache.spark.examples.SparkPi \
  --master spark://207.184.161.138:7077 \
  --executor-memory 20G \
  --total-executor-cores 100 \
  /path/to/examples.jar \
  1000

在spark的bin目录下的spark-submit.sh脚本中存在调用spark-class.sh，同时会将spark-submit的参数作为"$@"进行传递：

# 在用spark-submit提交程序jar及相应参数时，调用该脚本程序  "$@"为执行脚本的参数，将其传递给spark-class.sh
exec "${SPARK_HOME}"/bin/spark-class org.apache.spark.deploy.SparkSubmit "$@"

在spark-class.sh中会将参数传递给org.apache.spark.launcher.Main用于启动程序：

# The exit code of the launcher is appended to the output, so the parent shell removes it from the
# command array and checks the value to see if the launcher succeeded.
build_command() {
  "$RUNNER" -Xmx128m -cp "$LAUNCH_CLASSPATH" org.apache.spark.launcher.Main "$@"
  printf "%d\0" $?
}

# Turn off posix mode since it does not allow process substitution
set +o posix
CMD=()
while IFS= read -d '' -r ARG; do
  CMD+=("$ARG")
# 调用build_command()函数将参数传递给 org.apache.spark.launcher.Main这个类，用于启动用户程序
done < <(build_command "$@")

参数传递到org.apache.spark.launcher.Main#main(String[] argsArray)方法用于触发运行spark应用程序，当class为SparkSubmit时，从args中解析校验请求参数，校验参数、加载classpath中的jar、向executor申请的资源来构建bash脚本，触发spark执行应用程序。

public static void main(String[] argsArray) throws Exception {
    /* 通过spark-submit脚本启动时为此形式，exec "${SPARK_HOME}"/bin/spark-class org.apache.spark.deploy.SparkSubmit "$@" */
    if (className.equals("org.apache.spark.deploy.SparkSubmit")) {
      AbstractCommandBuilder builder = new SparkSubmitCommandBuilder(args);
      /* 从spark-submit.sh中解析请求参数，获取spark参数构建执行命令 AbstractCommandBuilder#buildCommand */
      cmd = buildCommand(builder, env, printLaunchCommand);
    } else {
      AbstractCommandBuilder builder = new SparkClassCommandBuilder(className, args);
      cmd = buildCommand(builder, env, printLaunchCommand);
    }
  	  /*
       * /usr/latest/bin/java -cp [classpath options] org.apache.spark.deploy.SparkSubmit --master yarn-cluster
       * --num-executors 100 --executor-memory 6G --executor-cores 4 --driver-memory 1G --conf spark.default.parallelism=1000
       *  --conf spark.storage.memoryFraction=0.5 --conf spark.shuffle.memoryFraction=0.3
       * */
      for (String c : bashCmd) {
        System.out.print(c);
        System.out.print('\0');
      }
}

进入org.apache.spark.deploy#main()方法体，parseArguments(args)方法会解析spark-submit.class的参数、加载系统环境变量（ignore spark无关的参数），会调用父类 SparkSubmitOptionParser#parse(List<String> args)方法解析参数，然后通过handle()、handleUnknown()、handleExtraArgs()获得应用程序需要的jar（--jars参数）和参数。

def doSubmit(args: Array[String]): Unit = {
  // Initialize logging if it hasn't been done yet. Keep track of whether logging needs to
  // be reset before the application starts.
  val uninitLog = initializeLogIfNecessary(true, silent = true)

  val appArgs = parseArguments(args)
  if (appArgs.verbose) {
    logInfo(appArgs.toString)
  }
  appArgs.action match {
    case SparkSubmitAction.SUBMIT => submit(appArgs, uninitLog)
    case SparkSubmitAction.KILL => kill(appArgs)
    case SparkSubmitAction.REQUEST_STATUS => requestStatus(appArgs)
    case SparkSubmitAction.PRINT_VERSION => printVersion()
  }
}

在提交应用未指定action参数时，默认为submit类型，以下为SparkSubmitArguments#loadEnvironmentArguments()解析的内容

// Action should be SUBMIT unless otherwise specified
action = Option(action).getOrElse(SUBMIT)

继续跟踪到SparkSubmit#submit(SparkSubmitArguments, Boolean)方法，在spark 1.3以后逐渐采用rest协议进行数据通信，直接进入doRunMain(args: SparkSubmitArguments, uninitLog: Boolean)方法，调用prepareSubmitEnvironment(args)解析应用程序参数，通过自定义类加载器MutableURLClassLoader下载jar包加载class进入jvm：

private def runMain(args: SparkSubmitArguments, uninitLog: Boolean): Unit = {
    val (childArgs, childClasspath, sparkConf, childMainClass) = prepareSubmitEnvironment(args)
    /* 设置当前线程的classLoader，MutableURLClassLoader实现了URLClassLoader接口，用于自定义类的加载 */
    val loader =
      if (sparkConf.get(DRIVER_USER_CLASS_PATH_FIRST)) {
        new ChildFirstURLClassLoader(new Array[URL](0),
          Thread.currentThread.getContextClassLoader)
      } else {
        new MutableURLClassLoader(new Array[URL](0),
          Thread.currentThread.getContextClassLoader)
      }
    /* 线程默认类加载器假如不设置 采用的是系统类加载器，线程上下文加载器会继承其父类加载器 */
    Thread.currentThread.setContextClassLoader(loader)

    /* 只有在yarn client模式下，用户的jar、通过--jars上传的jar全部被打包到loader的classpath里面.所以说，只要不少包 无论隐式
     * 引用其它包的类还是显式的引用，都会被找到.
     * --jars 参数指定的jars在yarn cluster模式下，直接是被封装到childArgs里面了，传递给了yarn.client
     */
    for (jar <- childClasspath) {
      addJarToClasspath(jar, loader)
    }

    var mainClass: Class[_] = null
    try {
      /* 采用的是上面的类加载器用于加载类class */
      mainClass = Utils.classForName(childMainClass)
    } catch {
      case e: ClassNotFoundException =>
        logWarning(s"Failed to load $childMainClass.", e)
    }

    val app: SparkApplication = if (classOf[SparkApplication].isAssignableFrom(mainClass)) {
      mainClass.newInstance().asInstanceOf[SparkApplication]
    } else {
      // SPARK-4170
      if (classOf[scala.App].isAssignableFrom(mainClass)) {
        logWarning("Subclasses of scala.App may not work correctly. Use a main() method instead.")
      }
      new JavaMainApplication(mainClass)
    }

    try {
      /* standalone模式在 SparkSubmit#prepareSubmitEnvironment(args)中将childMainClass设置为RestSubmissionClient */
      app.start(childArgs.toArray, sparkConf)
    } catch {
      case t: Throwable =>
        throw findCause(t)
    }
  }
}

在之前调用prepareSubmitEnvironment(args)时已将mainClass实例化为RestSubmissionClient，使用app.start(childArgs.toArray, sparkConf)使用restclient提交请求，在RestSubmissionClient.filterSystemEnvironment(sys.env)方法会过滤掉非SPARK_或MESOS_开头的环境变量。

override def start(args: Array[String], conf: SparkConf): Unit = {
  if (args.length < 2) {
    sys.error("Usage: RestSubmissionClient [app resource] [main class] [app args*]")
    sys.exit(1)
  }
  val appResource = args(0)
  val mainClass = args(1)
  val appArgs = args.slice(2, args.length)  /* 参数的顺序是(args.primaryResource(用户jar), args.mainClass, args.childArgs) */
  // 过滤系统中的环境变量，只保留以 SPARK_ or MESOS_开头的环境变量
  val env = RestSubmissionClient.filterSystemEnvironment(sys.env)
  run(appResource, mainClass, appArgs, conf, env)
}

追踪到RestSubmissionClientApp#run方法，将sparkConf转换为sparkProperties并进行过滤（只保留spark.开头的属性），继续跟踪client.createSubmission(submitRequest)提交rest请求。

/** Submits a request to run the application and return the response. Visible for testing. */
def run(
  appResource: String,
  mainClass: String,
  appArgs: Array[String],
  conf: SparkConf,
  env: Map[String, String] = Map()): SubmitRestProtocolResponse = {
  val master = conf.getOption("spark.master").getOrElse {
    throw new IllegalArgumentException("'spark.master' must be set.")
  }
  /* SparkConf创建的时候获取的配置 (以spark.开头的), 转换为SparkProperties */
  val sparkProperties = conf.getAll.toMap
  val client = new RestSubmissionClient(master)
  val submitRequest = client.constructSubmitRequest(
    appResource, mainClass, appArgs, sparkProperties, env)
  /* 发送创建好的消息Message(submitRequest)到Driver端, postJson(url, request.toJson)解析rest返回的结果 */
  client.createSubmission(submitRequest)
}

在RestSubmissionClientApp#createSubmission()方法中验证所有masters地址，开始构建submitUrl然后逐个向master发送请求。在每次发送请求时都会验证master是否可用，当不可用时会将其添加到lostMasters列表中。至此，在standalone模式下提交一个spark application的流程就到此为止。

/**
 * Submit an application specified by the parameters in the provided request.
 * If the submission was successful, poll the status of the submission and report
 * it to the user. Otherwise, report the error message provided by the server.
 */
def createSubmission(request: CreateSubmissionRequest): SubmitRestProtocolResponse = {
  logInfo(s"Submitting a request to launch an application in $master.")
  var handled: Boolean = false
  var response: SubmitRestProtocolResponse = null
  for (m <- masters if !handled) {
    validateMaster(m)
    val url = getSubmitUrl(m)
    response = postJson(url, request.toJson)
    response match {
      case s: CreateSubmissionResponse =>
      if (s.success) {
        reportSubmissionStatus(s)
        handleRestResponse(s)
        handled = true
      }
      case unexpected =>
      handleUnexpectedRestResponse(unexpected)
    }
  }
  response
}

客户端提交应用的部分看完了，现在来分析master端如何接收请求并进行处理，在start-master.sh脚本中存在以下脚本，可以以org.apache.spark.deploy.master.Master作为分析代码的入口。

# NOTE: This exact class name is matched downstream by SparkSubmit.
# Any changes need to be reflected there.
CLASS="org.apache.spark.deploy.master.Master"
if [ "$SPARK_MASTER_WEBUI_PORT" = "" ]; then
  SPARK_MASTER_WEBUI_PORT=8080
fi

"${SPARK_HOME}/sbin"/spark-daemon.sh start $CLASS 1 \
  --host $SPARK_MASTER_HOST --port $SPARK_MASTER_PORT --webui-port $SPARK_MASTER_WEBUI_PORT \
  $ORIGINAL_ARGS

在Master#main方法中启动了RPC运行环境以及Endpoint，RpcEndpoint：RPC端点，Spark针对于每个节点（Client/Master/Worker）都称之一个Rpc端点，且都实现RpcEndpoint接口，内部根据不同端点的需求，设计不同的消息和不同的业务处理，如果需要发送（询问）则调用Dispatcher。

def main(argStrings: Array[String]) {
  Thread.setDefaultUncaughtExceptionHandler(new SparkUncaughtExceptionHandler(
    exitOnUncaughtException = false))
  Utils.initDaemon(log)
  val conf = new SparkConf
  val args = new MasterArguments(argStrings, conf)
  /* 创建rpc环境 和 Endpoint(供Rpc调用)，在Spark中 Driver， Master ，Worker角色都有各自的Endpoint，相当于各自的Inbox */
  val (rpcEnv, _, _) = startRpcEnvAndEndpoint(args.host, args.port, args.webUiPort, conf)
  rpcEnv.awaitTermination()
}

Master继承了ThreadSafeRpcEndpoint类，重写的receive方法用于接收netty提交的请求，这部分为Master服务启动的过程。

override def receive: PartialFunction[Any, Unit] = {
  /* 在AppClient向master注册Application后才会触发master的schedule函数进行launchExecutors操作 */
  case RegisterApplication(description, driver) =>
  // TODO Prevent repeated registrations from some driver
  if (state == RecoveryState.STANDBY) {
    // ignore, don't send response
  } else {
    logInfo("Registering app " + description.name)
    val app = createApplication(description, driver)
    registerApplication(app)
    logInfo("Registered app " + description.name + " with ID " + app.id)
    persistenceEngine.addApplication(app)
    driver.send(RegisteredApplication(app.id, self))
    schedule()  /* todo: 用于调度Driver，具体的调度内容需要详细的看 */
  }
}

RestSubmissionClient提交的请求统一由StandaloneRestServer#handleSubmit(String, SubmitRestProtocolMessage, HttpServletResponse)统一进行处理，通过case CreateSubmissionRequest表达式匹配请求的类型，使用DeployMessages.RequestSubmitDriver(driverDescription)申请启动Driver。

// A server that responds to requests submitted by the [[RestSubmissionClient]].
// This is intended to be embedded in the standalone Master and used in cluster mode only.
protected override def handleSubmit(
  requestMessageJson: String,
  requestMessage: SubmitRestProtocolMessage,
  responseServlet: HttpServletResponse): SubmitRestProtocolResponse = {
  requestMessage match {
    case submitRequest: CreateSubmissionRequest =>
    /* 构建好所有的参数DriverDescription，用于向Driver端发送请求 */
    val driverDescription = buildDriverDescription(submitRequest)
    /* Driver构建完成后正式向Master发起一个请求，向master请求资源 */
    val response = masterEndpoint.askSync[DeployMessages.SubmitDriverResponse](
      DeployMessages.RequestSubmitDriver(driverDescription))
    val submitResponse = new CreateSubmissionResponse
    submitResponse.serverSparkVersion = sparkVersion
    submitResponse.message = response.message
    submitResponse.success = response.success
    submitResponse.submissionId = response.driverId.orNull
    val unknownFields = findUnknownFields(requestMessageJson, requestMessage)
    if (unknownFields.nonEmpty) {
      // If there are fields that the server does not know about, warn the client
      submitResponse.unknownFields = unknownFields
    }
    submitResponse
  }
}

在Master#receiveAndReply()方法中用createDriver(description)对DriverDescription再进行一次封装，同时通过schedule()进行资源调度到Worker上（在schedule方法中调用launchDriver的方法，会向Worker发送一个LaunchDriver类型请求），最后reply进行rest请求响应。

override def receiveAndReply(context: RpcCallContext): PartialFunction[Any, Unit] = {
  case RequestSubmitDriver(description) =>
  if (state != RecoveryState.ALIVE) {
    val msg = s"${Utils.BACKUP_STANDALONE_MASTER_PREFIX}: $state. " +
    "Can only accept driver submissions in ALIVE state."
    context.reply(SubmitDriverResponse(self, false, None, msg))
  } else {
    logInfo("Driver submitted " + description.command.mainClass)
    val driver = createDriver(description)
    persistenceEngine.addDriver(driver)
    waitingDrivers += driver
    drivers.add(driver)
    schedule()  // 执行调度的逻辑schedule()

    // TODO: It might be good to instead have the submission client poll the master to determine
    //       the current status of the driver. For now it's simply "fire and forget".
    context.reply(SubmitDriverResponse(self, true, Some(driver.id),
                                       s"Driver successfully submitted as ${driver.id}"))
  }
}

将视角转到Worker#receive()方法中，通过模式匹配case LaunchDriver(driverId, driverDesc)进入如下代码，然后调用driver.start()启动程序。

case LaunchDriver(driverId, driverDesc) =>
	logInfo(s"Asked to launch driver $driverId")
  /*
   * 在RestSubmissionClient向StandaloneRestServer提交launchDriver请求后，实际上在StandaloneRestServer进行了一层封装
   * DriverWrapper. 所以，在此处启动的类是DriverWrapper 而不是用户程序本身，在该main方法里，主要是用自定义类加载器加载了用户的
   * main方法，然后开始启动用户程序 初始化sparkContext等;
   */
   val driver = new DriverRunner(
      conf,
      driverId,
      workDir,
      sparkHome,
      /*
       * 此处的Command就是在StandaloneRestServer封装好的
       * val command = new Command("org.apache.spark.deploy.worker.DriverWrapper", Seq("",
       *  "", mainClass)) ++ appArgs,   // args to the DriverWrapper
       */
      driverDesc.copy(command = Worker.maybeUpdateSSLSettings(driverDesc.command, conf)),
      self,
      workerUri,
      securityMgr)
   drivers(driverId) = driver
   driver.start()
   coresUsed += driverDesc.cores
   memoryUsed += driverDesc.mem

进入driver.start()方法，应用会创建Driver所需要的工作目录，同时download用户自定义的jar包然后开始运行Driver。

/** Starts a thread to run and manage the driver. */
private[worker] def start() = {
  new Thread("DriverRunner for " + driverId) {
    override def run() {
        // prepare driver jars and run driver, 下载用户自定义的jar包, buildProcessBuilder该方法有两个默认值的备用参数，主要是准备程序运行的环境 (但并不包含app所在的jar)
        val exitCode = prepareAndRunDriver()
        // set final state depending on if forcibly killed and process exit code
        finalState = if (exitCode == 0) {
          Some(DriverState.FINISHED)
        } else if (killed) {
          Some(DriverState.KILLED)
        } else {
          Some(DriverState.FAILED)
        }
      // notify worker of final driver state, possible exception
      worker.send(DriverStateChanged(driverId, finalState.get, finalException))
    }
  }.start()
}

进一步进入到prepareAndRunDriver()方法，程序使用CommandUtils.buildProcessBuilder()结合command所要运行的环境，重新构建一个命令。例如: 本地环境变量、系统classpath, 替换掉传递过来的占位符。

private[worker] def prepareAndRunDriver(): Int = {
  val driverDir = createWorkingDirectory()
  val localJarFilename = downloadUserJar(driverDir)  // 下载用户自定义的jar包
  def substituteVariables(argument: String): String = argument match {
    case "" => workerUrl
    case "" => localJarFilename
    case other => other
  }
  // TODO: If we add ability to submit multiple jars they should also be added here
  /* buildProcessBuilder该方法有两个默认值的备用参数，主要是准备程序运行的环境 (但并不包含app所在的jar) */
  val builder = CommandUtils.buildProcessBuilder(driverDesc.command, securityManager,
                                                 driverDesc.mem, sparkHome.getAbsolutePath, substituteVariables)
  runDriver(builder, driverDir, driverDesc.supervise)
}

进入CommandUtils#buildLocalCommand方法，-cp参数是在buildCommandSeq(Command, Int, String)中构建。

  /**
   * Build a command based on the given one, taking into account the local environment
   * of where this command is expected to run, substitute any placeholders, and append
   * any extra class paths.
   */
  private def buildLocalCommand(
      command: Command,
      securityMgr: SecurityManager,
      substituteArguments: String => String,
      classPath: Seq[String] = Seq.empty,
      env: Map[String, String]): Command = {
    val libraryPathName = Utils.libraryPathEnvName   // 返回系统的path，也就是一些
    val libraryPathEntries = command.libraryPathEntries
    val cmdLibraryPath = command.environment.get(libraryPathName)

    var newEnvironment = if (libraryPathEntries.nonEmpty && libraryPathName.nonEmpty) {
      val libraryPaths = libraryPathEntries ++ cmdLibraryPath ++ env.get(libraryPathName)
      command.environment + ((libraryPathName, libraryPaths.mkString(File.pathSeparator)))
    } else {
      /*
       * RestSubmissionClient发送过来的环境变量只有 SPARK_和MESOS_ 开头的环境变量，也即是对于driver端System.getenv()系统环境变量获取
       * 的值. 如spark-env初始化的 SPARK_ 开头的环境变量，在提交的时候已经创建好了;
       */
      command.environment
    }
    Command(
      /*
       * 对于driver并不是用户命令的入口，而是一个封装类org.apache.spark.deploy.DriverWrapper, 在封装类里面进一步解析
       *  对于executor是这个org.apache.spark.executor.CoarseGrainedExecutorBackend类
       */
      command.mainClass,
      command.arguments.map(substituteArguments),
      newEnvironment,
      command.classPathEntries ++ classPath,
      Seq.empty, // library path already captured in environment variable
      // filter out auth secret from java options
      command.javaOpts.filterNot(_.startsWith("-D" + SecurityManager.SPARK_AUTH_SECRET_CONF)))  // spark.jars在此处
  }

在StandaloneRestServer#buildDriverDescription()方法里指明如何构建Command类型，用命令行执行的是org.apache.spark.deploy.worker.DriverWrapper包装类。

/* 直接执行的是这个封装类，通过自定义urlClassLoader指定classpath的方式加载用户的jar然后通过反射执行 */
val command = new Command(
   "org.apache.spark.deploy.worker.DriverWrapper",
   Seq("", "", mainClass) ++ appArgs, // args to the DriverWrapper
   environmentVariables, extraClassPath, extraLibraryPath, javaOpts)  // 也即是此时spark.jars也即--jars传来的参数在javaOpts里面

进入到DriverManager#main(args: Array[String])方法，通过自定义的classLoader加载jar包，根据mainClass通过反射执行其main()方法，触发用户程序的执行。

def main(args: Array[String]) {
  case workerUrl :: userJar :: mainClass :: extraArgs =>
  	    val conf = new SparkConf()
        val host: String = Utils.localHostName()
        val port: Int = sys.props.getOrElse("spark.driver.port", "0").toInt
        val rpcEnv = RpcEnv.create("Driver", host, port, conf, new SecurityManager(conf))
        logInfo(s"Driver address: ${rpcEnv.address}")
        rpcEnv.setupEndpoint("workerWatcher", new WorkerWatcher(rpcEnv, workerUrl))

        val currentLoader = Thread.currentThread.getContextClassLoader
        val userJarUrl = new File(userJar).toURI().toURL()
        val loader =
          if (sys.props.getOrElse("spark.driver.userClassPathFirst", "false").toBoolean) {
            new ChildFirstURLClassLoader(Array(userJarUrl), currentLoader)
          } else {
            new MutableURLClassLoader(Array(userJarUrl), currentLoader)
          }
        /*
         * 此时通过反射从userJarURL获取用户入口代码，调用用户的入口程序，然后执行. 在初始化SparkContext的时候会把spark.jars
         * 所指定的所有jar都添加到集群中 为将来执行tasks准备好依赖环境, return c.newInstance()
         */
        Thread.currentThread.setContextClassLoader(loader)
        setupDependencies(loader, userJar)

        // Delegate to supplied main class
        val clazz = Utils.classForName(mainClass)
        val mainMethod = clazz.getMethod("main", classOf[Array[String]])
        mainMethod.invoke(null, extraArgs.toArray[String])
        rpcEnv.shutdown()
}

现在Driver已经启动了，接下来看应用如何启动executor和task的流程，Executor的启动从SparkContext#createTaskScheduler(SparkContext, String, String)方法，方法体中会初始化StandaloneSchedulerBackend类。SparkContext准备完成后会调用_taskScheduler.start()方法启动StandaloneSchedulerBackend方法：

// start TaskScheduler after taskScheduler sets DAGScheduler reference in DAGScheduler's
// constructor (YarnSchedule)
_taskScheduler.start()

private def createTaskScheduler(
  sc: SparkContext,
  master: String,
  deployMode: String): (SchedulerBackend, TaskScheduler) = {
    case SPARK_REGEX(sparkUrl) =>
    val scheduler = new TaskSchedulerImpl(sc) /* standalone模式下执行任务调度器executor */
    val masterUrls = sparkUrl.split(",").map("spark://" + _)
    /* 重点, 用户程序向master注册, executor申请都是由该函数完成的. start是在TaskSchedulerImpl中的start函数里启动的 */
    val backend = new StandaloneSchedulerBackend(scheduler, sc, masterUrls)
    scheduler.initialize(backend)
    (backend, scheduler)
}

进入StandaloneSchedulerBackend#start()方法，用CoarseGrainedExecutorBackend构建command命令，然后构建ApplicationDescription对象，将其传入appClient并向Master发起应用注册的请求StandaloneAppClient#tryRegisterAllMasters()方法中发送RegisterApplication(appDescription, self)，Master端收到请求后会重新运行schedule()的方法。

override def start() {
  super.start()
    // Start executors with a few necessary configs for registering with the scheduler
    /* 只获取了Executor启动时用到的配置，不包含--jars传递的值 */
    val sparkJavaOpts = Utils.sparkJavaOpts(conf, SparkConf.isExecutorStartupConf)
    val javaOpts = sparkJavaOpts ++ extraJavaOpts
    val command = Command("org.apache.spark.executor.CoarseGrainedExecutorBackend",
      args, sc.executorEnvs, classPathEntries ++ testingClassPath, libraryPathEntries, javaOpts)
    // 重点关注两个参数 spark.executor.extraLibraryPath spark.driver.extraLibraryPath
    val webUrl = sc.ui.map(_.webUrl).getOrElse("")
    val coresPerExecutor = conf.getOption("spark.executor.cores").map(_.toInt)

  	val appDesc = ApplicationDescription(sc.appName, maxCores, sc.executorMemory, command,
      webUrl, sc.eventLogDir, sc.eventLogCodec, coresPerExecutor, initialExecutorLimit)
    client = new StandaloneAppClient(sc.env.rpcEnv, masters, appDesc, this, conf)
    client.start()
}

进入Worker#receive()方法，根据case匹配到LaunchExecutor的请求，构建ExecutorRunner对象并调用其start()方法。

case LaunchExecutor(masterUrl, appId, execId, appDesc, cores_, memory_) =>
	if (masterUrl != activeMasterUrl) {
     logWarning("Invalid Master (" + masterUrl + ") attempted to launch executor.")
  } else {
    logInfo("Asked to launch executor %s/%d for %s".format(appId, execId, appDesc.name))
    val manager = new ExecutorRunner(
      appId,
      execId,
      appDesc.copy(command = Worker.maybeUpdateSSLSettings(appDesc.command, conf)),
      cores_,
      memory_,
      self,
      workerId,
      host,
      webUi.boundPort,
      publicAddress,
      sparkHome,
      executorDir,
      workerUri,
      conf,
      appLocalDirs, ExecutorState.RUNNING)
    executors(appId + "/" + execId) = manager
    manager.start()
    coresUsed += cores_
    memoryUsed += memory_
    sendToMaster(ExecutorStateChanged(appId, execId, manager.state, None, None))
  }

进入ExecutorRunner#start()方法，首先创建了一个worker线程用于执行任务，要执行的方法为fetchAndRunExecutor()。在方法中通过CommandUtils.buildProcessBuilder()创建进程，然后设置执行路径、环境变量以及spark UI相关内容，然后启动进程（process执行类为CoarseGrainedExecutorBackend）。

/**
 * Download and run the executor described in our ApplicationDescription
 */
private def fetchAndRunExecutor() {
	// Launch the process
  val subsOpts = appDesc.command.javaOpts.map {
    Utils.substituteAppNExecIds(_, appId, execId.toString)
  }
  val subsCommand = appDesc.command.copy(javaOpts = subsOpts)
  val builder = CommandUtils.buildProcessBuilder(subsCommand, new SecurityManager(conf),
                                                 memory, sparkHome.getAbsolutePath, substituteVariables)
  val command = builder.command()
  val formattedCommand = command.asScala.mkString("\"", "\" \"", "\"")
  logInfo(s"Launch command: $formattedCommand")
  // 执行构建完成的ProcessBuilder
  process = builder.start()
  val header = "Spark Executor Command: %s\n%s\n\n".format(
  formattedCommand, "=" * 40)
  // Wait for it to exit; executor may exit with code 0 (when driver instructs it to shutdown)
  // or with nonzero exit code
  val exitCode = process.waitFor()
  state = ExecutorState.EXITED
  val message = "Command exited with code " + exitCode
  worker.send(ExecutorStateChanged(appId, execId, state, Some(message), Some(exitCode)))
}

在CoarseGrainedExecutorBackend#receive()方法中接收case LaunchTask(data)的请求，当executor初始化好之后执行executor.launchTask(this, taskDesc)方法。

override def receive: PartialFunction[Any, Unit] = {
  case LaunchTask(data) =>
  if (executor == null) {
    exitExecutor(1, "Received LaunchTask command but executor was null")
  } else {
    val taskDesc = TaskDescription.decode(data.value)
    logInfo("Got assigned task " + taskDesc.taskId)
    executor.launchTask(this, taskDesc)
  }
}

进入TaskRunner#run()方法，设置TaskMemoryManager、序列化jar文件、初始化各种Metrics统计信息，然后通过task.run()的任务就正常执行了。至此，从使用spark-submit.sh脚本提交用户application在standalone模式下的流程就先分析完成。

override def run(): Unit = {
  val taskMemoryManager = new TaskMemoryManager(env.memoryManager, taskId)
  val deserializeStartTime = System.currentTimeMillis()
  val deserializeStartCpuTime = if (threadMXBean.isCurrentThreadCpuTimeSupported) {
    threadMXBean.getCurrentThreadCpuTime
  } else 0L
  /*
   * 类加载器设置的是url类加载器, 而其父类加载器是系统类加载器. currentJars是以来的uri, 用户在调用
   * updateDependencies将依赖添加至此
   */
  Thread.currentThread.setContextClassLoader(replClassLoader)
  val ser = env.closureSerializer.newInstance()
  logInfo(s"Running $taskName (TID $taskId)")
  // Run the actual task and measure its runtime.
  taskStartTime = System.currentTimeMillis()
  taskStartCpu = if (threadMXBean.isCurrentThreadCpuTimeSupported) {
    threadMXBean.getCurrentThreadCpuTime
  } else 0L
  var threwException = true
  val value = Utils.tryWithSafeFinally {
    val res = task.run(
      taskAttemptId = taskId,
      attemptNumber = taskDescription.attemptNumber,
      metricsSystem = env.metricsSystem)
    threwException = false
    res
  }
}

jvm常见垃圾回收算法及双亲委派模型

2021-02-10T00:00:00+00:00

java相对于C++优势在于自动的垃圾回收，提供对象的构造函数后，不需要再提供析构函数（销毁对象，释放之前申请的内存），更易避免了内存泄露的问题。主要归功于虚拟机进行垃圾回收，虚拟机版本有Sun公司的HotSopt VM、BEA的JRockit、微软的JVM及IBM的J9 VM。

内存区域划分

Java虚拟机在执行程序时会把管理的内存划分为若干个不同的数据区域，这些区域有各自的用途，以及创建和销毁的时间。

1）程序计数器（Program Counter Register）占用一块较小的内存空间，可看作是当前线程执行字节码的行号指示器（与操作系统中的PC的概念相同，指定下一条指令的位置）。在执行分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。每个线程都有一个独立的程序计数器；

2）Java虚拟机栈也是线程私有的，声明周期与线程相同。描述Java方法执行的内存模型，每个方法执行会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。递归方法调用超过最大深度时将跑出StackOverflowError的异常； 3）本地方法栈（Native Method Stack）用于调用其它语言的方法（如C++），声明周期也与线程绑定；

4）Java堆是多个线程共享的一块内存区域，在虚拟机启动时创建，此内存区域的唯一目的就是存放对象实例，也是垃圾收集器管理的主要区域。由于收集器基本采用分代收集算法，Java堆还可以细分为：新生代和老年代（细致些有Eden空间、From Survivor空间、To Survivor空间）等；

5）方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后代码等数据。在HotSpot中，开发者更愿意把方法去称为“永久代”（Permanent Generation），但本质上并不等价；

6）运行时常量池（Runtime Constant Pool）和直接内存（Direct Memory）这两部分，用于存储class文件翻译出来的直接引用也存储在运行时常量池中，直接内存主要用于NIO类；

回收算法及垃圾收集器

如何判断一个对象已死？已有引用计数算法，但其无法解决循环引用的问题。java采用可达性分析算法，算法的基本思路是通过一系列称为”gc roots “的对象作为起始点，搜索所走过的路径称为引用链（reference chain），当gc不可达时则证明此对象是不可用的。

“标记-清除”（Mark-Sweep）算法，首先标记出所有需要回收的对象，在标记完成后统一回收被标记的对象。问题在于，一个是效率问题标记和清除两个过程的效率都不高，另外，还会产生大量不连续的内存碎片。在分配较大对象时，容易产生OOM。

为了解决效率问题，一种称为复制（copying）的算法出现了，它将可用内存按容量划分为大小相等的两个块。每次将存活的对象复制到另一个块。但是，内存利用率不高存在50%的内存浪费。目前商业虚拟机分为1个80%的Edge区和2个10%的Survivor区。

根据老年代的特点，有人提出了另外一种“标记-整理”（Mark Compact）算法，差异在于不清理可回收的对象，而是让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存。

商业上目前用的是分代回收（Generational Collect）算法，根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

常见的垃圾回收器，垃圾回收器就是内存回收的具体实现，Java虚拟机规范中对实现没有任何规定，因此，不同厂商虚拟机使用的垃圾收集器可能会有很大差别。

Serial收集器，是发展历史最悠久的收集器，曾经（在JDK 1.3.1之前）是虚拟机新生代收集的唯一选择。该收集器会引入”stop the world“的问题，进行垃圾收集时必须暂停其它所有的工作线程，直到它结束。

ParNew收集器，是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，却是许多运行在Server模式下的虚拟机首选新生代收集器，只有ParNew和Serial能够与CMS收集器配合工作。

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。其优点在于达到一个可控制的吞吐量（Throughput），吞吐量就是CPU用于运行用户代码的时间与CPU总耗时间的比值。

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，其是基于“标记-清除”算法实现的，整个过程分为：初始标记（initial mark）、并发标记（concurrent mark）、重新标记（remark）、并发清除（concurrent sweep）。耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，停顿的时间较少。

CMS是基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生，当没有足够空间来满足大对象分配时，那不得不提前进行一个Full GC。CMS收集器提供了+UseCMSCompactAtFullCollection开关参数，用于在CMS收集器进行Full GC时合并内存碎片。

此外，CMS收集器对CPU资源是非常敏感的，在并发阶段，虽不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢。

G1收集器是当今收集器技术发展的最前沿成果之一，由Java 1.7引入。G1是一款面向服务端应用的垃圾收集器，HotSpot开发团队赋予它的使命是在未来可以替换掉JDK 1.5中发布的CMS收集器。与其它GC收集器相比，G1具备以下特点：

并发与并行，G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop The World的停顿时间；分代收集，分代的概念在G1中依然得以保留。它可以采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过了多次GC的旧对象以获取更好的收集效果；

空间整合，与CMS的“标记-整理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的；可预测的停顿，这个G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1处理追求低停顿外，还能建立可预测的停顿时间。

类加载器与双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是自动类加载器（Bootstrap ClassLoader），这个类加载器使用C++实现。另一种就是所有其它的类加载器，包括扩展类加载器（Extension ClassLoader）、应用程序类加载器（Application ClassLoader），及一些实现了ClassLoader接口的自定义类加载器。

双亲委派模型对于保证Java程序的稳定运作很重要，但其实现却非常简单，只需实现java.lang.ClassLoader的loadClass()方法就可以（同时设置class文件的path）。加载逻辑：先检查是否已被加载过，若没有加载则调用父加载器的loadClass方法，若父加载器为空则默认使用启动类加载器作为父加载器。

破坏双亲委派模型，覆写loadClass()方法实现加载class的逻辑，而类加载器和抽象类java.lang.ClassLoader在JDK 1.0时代就已经存在。在JDK 1.2之后已不提倡用户再去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中。

双亲委派模型的第二次破坏是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题。可在线程上下文类加载器（Thread Context ClassLoader）中通过Thread的setContextClassLoader()进行设置。若创建线程时还未设置，它将会从父线程中继承一个，默认为应用程序类加载器，也算是一种“舞弊”的方式。第三次破坏是由于用户追求动态性的追求导致的，这里的“动态性”指的是当前一个非常“热门”的名次：代码热替换（HotSwap）、模块热部署（Hot Deployment）等，采用OSGI的技术。

使用kubernetes构建微服务

2019-11-12T00:00:00+00:00

Build distributed services with kubernetes

Kubernetes (commonly stylized as k8s) is an open-source container-orchestration system for automating application deployment, scaling, and management. It aims to provide a “platform for automating deployment, scaling, and operations of application containers across clusters of hosts”.

一、在`elementory OS`服务器搭建kubernetes环境

elementary OS是基于ubuntu精心打磨美化的桌面 linux 发行版的一款软件，号称 “最美的 linux”，最早是 ubuntu 的一个美化主题项目，现在成了独立的发行版。”快速、开源、注重隐私的 windows / macOS 替代品”。

1）在elementary OS系统上安装docker环境，具体可以参考 https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/：

# 1.更新ubuntu的apt源索引
sam@elementoryos:~$ sudo apt-get update
# 2.安装以下包以使apt可以通过HTTPS使用存储库repository
sam@elementoryos:~$ sudo apt-get install apt-transport-https ca-certificates curl software-properties-common
# 3.添加Docker官方GPG key
sam@elementoryos:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
# 4.设置Docker稳定版仓库
sam@elementoryos:~$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
# 5.再更新下apt源索引，然后通过docker version显示器版本信息
sam@elementoryos:~$ apt-get update
sam@elementoryos:~$ sudo docker version
Client:
 Version:           18.09.7
Server:
 Engine:
  Version:          18.09.7
# 6.从镜像中心拉取hello-world镜像并进行运行
sam@elementoryos:~$ sudo docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.

管理docker服务常用应用脚本：

` sudo service docker start ` 启动docker服务、 sudo service docker stop 停止docker服务、 sudo service docker restart 重启docker服务.

2）使用minikube在本机搭建kubernetes集群，简单体验k8s：

为了方便开发者开发和体验kubernetes，社区提供了可以在本地部署的minikube。由于国内网络的限制导致，导致在本地安装minikube时相关的依赖是无法下载。从minikube最新的1.5版本之后，已经提供了配置化的方式，可以直接从阿里云的镜像地址来获取所需要的docker镜像和配置。

在elementary OS上安装kubectl的稳定版本：

sam@elementoryos:~$ sudo curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.0/bin/linux/amd64/kubectl && chmod +x ./kubectl && sudo mv ./kubectl /usr/local/bin/kubectl

在安装完成后使用kubectl version进行验证，由于minikube服务未启动最后的报错可以忽略:

sam@elementoryos:~$ sudo kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server 192.168.170.130:8443 was refused - did you specify the right host or port?

通过curl命令从github上下载minikube的1.5.0版本：

sam@elementoryos:~$ curl -Lo minikube https://github.com/kubernetes/minikube/releases/download/v1.5.0/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

启动minikube服务，为了访问海外资源阿里云提供了一系列基础措施可以通过参数进行配置，--image-mirror-country cn默认会从registry.cn-hangzhou.aliyuncs.com/google_containers下载kubernetes依赖的相关资源。首次启动会在本地下载 localkube 、kubeadm等工具。

sam@elementoryos:~$ sudo minikube start --vm-driver=none --image-mirror-country cn --memory=1024mb --disk-size=8192mb --registry-mirror=https://registry.docker-cn.com --image-repository='registry.cn-hangzhou.aliyuncs.com/google_containers' --bootstrapper=kubeadm --extra-config=apiserver.authorization-mode=RBAC
😄  minikube v1.5.0 on Debian buster/sid
✅  Using image repository registry.cn-hangzhou.aliyuncs.com/google_containers
🤹  Running on localhost (CPUs=2, Memory=3653MB, Disk=40059MB) ...
ℹ️   OS release is elementary OS 5.0 Juno
🐳  Preparing Kubernetes v1.16.2 on Docker 18.09.7 ...
🏄  Done! kubectl is now configured to use "minikube"

在minikube安装完成后，在本地minikube dashboard --url控制页面无法展示，目前暂时未解决。

sam@elementoryos:~$ sudo kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

使用sudo minikube dashboard --url自动生成minikube的管理页面：

sam@elementoryos:~$ sudo minikube dashboard -url

minikube本地环境搭建可参考这几篇文章：

使用minikube在本地搭建集群：http://qii404.me/2018/01/06/minukube.html

阿里云的minikube本地实验环境：https://yq.aliyun.com/articles/221687

关于kubernetes解决dashboard：https://blog.8hfq.com/2019/03/01/kubernetes-dashboard.html

二、运行于kubernetes中的容器

kubernetes中的pod组件：pod是一组并置的容器，代表了kubernetes中基本构建模块。在实际应用中我们并不会单独部署容器，更多的是针对一组pod容器进行部署和操作。当一个pod包含多个容器时，这些容器总是会运行于同一个工作节点上——一个pod绝不会跨越多个工作节点。

对于docker和kubernetes期望的工作方式是将每个进程运行于自己的容器内，由于不能将多个进程聚集在一个单独的容器中，我们需要另一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是pod背后的根本原理。对于容器彼此之间是完全隔离的，但此时我们期望的是隔离容器组，而不是单个容器，并让容器组内的容器共享一些资源。kubernetes通过配置docker来让一个pod内的所有容器共享相同的linux命名空间，而不是每个容器都有自己的一组命名空间。

由于一个pod中的容器运行于相同的network命名空间中，因此它们共享相同的IP地址和端口空间。这意味着在同一pod中的容器运行的多个进程需要注意不能绑定想同的端口号，否则会导致端口冲突。

1）在kubernetes上运行第一个应用swagger-editor并对外暴露8081端口：

sam@elementoryos:~$ sudo kubectl run swagger-editor --image=swaggerapi/swagger-editor:latest --port=8081 --generator=run/v1

sam@elementoryos:~$ sudo kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
swagger-editor-xgqzm   1/1     Running   0          57s

在kubectl run命令中使用--generator=run/v1参数表示它让kubernetes创建一个ReplicationController而不是Deployment。通过kubectl get pods可以查看所有pod中运行的容器实例信息。每个pod都有自己的ip地址，但是这个地址是集群内部的，只有通过LoadBalancer类型服务公开它，才可以被外部访问，可以通过运行kubectl get services命令查看新创建的服务对象。

sam@elementoryos:~$ sudo kubectl expose rc swagger-editor --type=LoadBalancer --name swagger-editor-http
service/swagger-editor-http exposed

sam@elementoryos:~$ sudo kubectl get services
NAME                  TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes            ClusterIP      10.96.0.1        <none>        443/TCP          46m
swagger-editor-http   LoadBalancer   10.108.118.211   <pending>     8081:30507/TCP   3m24s

2）为了增加期望的副本数，需要改变ReplicationController期望的副本数，现已告诉kubernetes需要采取行动，对pod的数量采取操作来实现期望的状态。

sam@elementoryos:~$ sudo kubectl scale rc swagger-editor --replicas=3
replicationcontroller/swagger-editor scaled
sam@elementoryos:~$ sudo kubectl get pods
NAME                   READY   STATUS              RESTARTS   AGE
swagger-editor-fzppq   0/1     ContainerCreating   0          12s
swagger-editor-wqpg5   0/1     ContainerCreating   0          12s
swagger-editor-xgqzm   1/1     Running             0          16m

为了观察列出pod时显示pod ip和pod的节点，可以通过使用-o wide选项请求显示其他列。在列出pod时，该选项显示pod的ip和所运行的节点。由于minikube不支持rc，因而并不会展示外部ip地址。若想在不通过service的情况下与某个特定的pod进行通信（处于调试或其它原因）,kubernetes将允许我们配置端口转发到该pod，可以通过kubectl port-forward命令完成上述操作：

sam@elementoryos:~$ sudo kubectl get pods -o wide
NAME                   READY   STATUS    RESTARTS   AGE     IP           NODE       NOMINATED NODE   READINESS GATES
swagger-editor-fzppq   1/1     Running   0          5m28s   172.17.0.7   minikube   <none>           <none>
swagger-editor-wqpg5   1/1     Running   0          5m28s   172.17.0.5   minikube   <none>           <none>
swagger-editor-xgqzm   1/1     Running   0          21m     172.17.0.6   minikube   <none>           <none>

sam@elementoryos:~$ sudo kubectl port-forward swagger-editor-fzppq 8088:8081
Forwarding from 127.0.0.1:8088 -> 8081
Forwarding from [::1]:8088 -> 8081

标签是一种简单却功能强大的kubernetes特性，不仅可以组织pod也可以组织所有其他的kubernetes资源。详细来讲，可以通过标签选择器来筛选pod资源。在使用多个namespace的前提下，我们可以将包括大量组件的复杂系统拆分为更小的不同组，这些不同组也可以在多租户环境中分配资源。

三、副本机制和其它控制器：部署托管的`pod`

kubernetes可以通过存活探针(liveness probe)检查容器是否还在运行，可以为pod中的每个容器单独指定存活探针。如果探测失败，kubernetes将定期执行探针并重新启动容器。kubernetes有三种探测容器的机制：通过http get对容器发送请求，若应用接收到请求，并且响应状态码不代表错误，则任务探测成功；TCP套接字探针尝试与容器指定端口建立TCP连接，若长连接正常建立则探测成功；exec探针在容器中执行任意命令，并检查命令的退出返回码。

apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 15

kubia-liveness-probe-initial-delay.yaml文件中在livenessProbe中指定了通过httpGet探测的探针地址检测应用的状态，为了防止容器启动时通过探针地址检测应用状态，可以通过设置initialDelaySeconds指定应用启动间隔时间（像spingboot应用的/health端点就非常合适）。

了解ReplicationController组件：ReplicationController是一种kubernetes资源，可确保它的pod始终保持运行状态。如果pod因任何原因消失，则ReplicationController会注意到缺少了pod并创建替代pod。ReplicationController的工作是确保pod的数量始终与其标签选择器匹配，若不匹配则rc会根据需要，采取适当的操作来协调pod的数量。label selector用于确定rc作用域内有哪些pod、replica count指定应运行的pod数量、pod template用于创建新的pod副本。

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia
        ports:
        - containerPort: 8080

kubia-rc.yaml文件定义，在yaml中selector指定了符合标签的选择器app: kubia。若删除的rc创建的一个pod，则其会自动创建新的pod使得副本的数量达到yaml文件配置的数量。若要将pod移出rc作用域，可以通过更改pod的标签将其从rc的作用域中进行移除，--overwrite参数是必要的，否则kubectl将只是打印出警告，并不会更改标签。对于修改rc的template只会对之后新创建的pod有影响，而对之前已有的pod不会造成影响。若需要对pod进行水平扩展，可以通过修改edit调整replicas:10的属性，或者通过命令行kubectl scale rc kubia --replication=10进行调整。

sam@elementoryos:~$ sudo kubectl create -f kubia-rc.yaml
ReplicationController "kubia" created
sam@elementoryos:~$ sudo kubectl label pod kubia-demdck app=foo --overwrite
# 通过kubectl更改rc的template内容
sam@elementoryos:~$ sudo kubectl edit rc kubia

当要删除rc则可以通过kubectl delete进行操作，rc所管理的所有pod也会被删除。若需要保留pod的时候，则需要在命令行添加--cascade=false的配置，当删除replicationController后，其之前所管理的pod就独立。

ReplicaSet的引入：最初ReplicationController是用于复制和在异常时重新调度节点的唯一kubernetes组件，后来引入了ReplicaSet的类似资源。它是新一代的rc并且会将其完全替换掉。ReplicaSet的行为与rc完全相同，但pod选择器的表达能力更强。在yaml文件配置中其apiVersion内容为apps/v1beta2，其kind类型为ReplicaSet类型。

sam@elementoryos:~$ sudo kubectl delete rs kubia

引入DaemonSet组件：要在所有集群结点上运行一个pod，需要创建一个DaemonSet对象。DaemonSet确保创建足够的pod，并在自己的节点上部署每个pod。尽管ReplicaSet(ReplicationController)确保集群中存在期望数量的pod副本，但DaemonSet并没有期望的副本的概念。它不需要，因为它的工作是确保一个pod匹配它的选择器并在每个节点上运行。

在DaemonSet的yml配置文件中，其apiVersion内容为apps/v1beta2，kind类型为DeamonSet。在删除DaemonSet时候其所管理pod也会被一并删除。

sam@elementoryos:~$ sudo kubectl create -d ssd-monitor-deamonset.yaml
# view all DaemonSet components in kubernetes
sam@elementoryos:~$ sudo kubectl get ds

介绍Kubernetes Job资源：kubernetes通过Job资源提供对短任务的支持，在发生节点故障时，该节点上由Job管理的pod将按照ReplicaSet的pod的方式，重新安排到其他节点。如果进程本身异常退出（进程返回错误退出代码时），可以将Job配置为重新启动容器。

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5
  parallelism: 2
  schedule: "0,15,30,45 * * * *"
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

Job是batch API组v1版本的一部分，yaml定义了一个Job类型的资源，它将运行luksa/batch-job镜像，该镜像调用一个运行120秒的进程，然后退出。在pod的定义中，可以指定在容器中运行的进程结束时，kubernetes会做什么？这是通过pod配置的属性restartPolicy完成的，默认为Always配置在Job中使用OnFailure的策略。可以在yaml文件中指定parallelism: 2来指定任务的并行度，通过创建cronJob资源在yaml中指定‘schedule: 0,15,30,45 * * * *定时任务表达式。startingDeadlineSeconds: 15指定pod最迟必须在预定时间后15秒开始执行。

sam@elementoryos:~/kubernetes$ sudo kubectl create -f kubernetes-job.yaml
job.batch/batch-job created
sam@elementoryos:~/kubernetes$ sudo kubectl get jobs
NAME        COMPLETIONS   DURATION   AGE
batch-job   0/1           47s        47s
sam@elementoryos:~/kubernetes$ sudo kubectl get pods
NAME              READY   STATUS    RESTARTS   AGE
batch-job-nzbmv   1/1     Running   0          108s
sam@elementoryos:~/kubernetes$ sudo kubectl logs batch-job-nzbmv
Sun Nov 17 09:09:01 UTC 2019 Batch job starting

service服务：让客户端发现pod并与之通信

kubernetes服务是一种为一组功能相同pod提供单一不变的接入点的资源，当服务存在时，它的ip地址和端口不变。客户端通过固定ip和port建立连接，这种连接会被路由到提供该服务的任意一个pod上。通过这种方式，客户端不需要知道每个pod的地址，这样这些pod就可以在集群中被随时创建或者移除。

可以使用kubectl expose命令创建服务，rc是replicationcontroller的缩写。由于minikube不支持LoadBalance类型的服务，因此服务的external-ip地址为<none>。

sam@elementoryos:~/kubernetes$ sudo kubectl expose rc kubia --type=LoadBalancer --name kubia-http
service "kubia-http" exposed
sam@elementoryos:~/kubernetes$ sudo kubectl get services
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP          2d5h
kubia        ClusterIP   10.111.211.203   <none>        80/TCP,443/TCP   22h
sam@elementoryos:~/kubernetes$ sudo kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
kubia-9vds6   1/1     Running   0          23h
kubia-cpjvx   1/1     Running   0          23h
kubia-hs5vq   1/1     Running   0          23h

另一种是使用yaml描述文件kubia-svc.yaml来创建服务，使用sudo kubectl create -f kubia-svc.yaml 。service也是通过selector筛选符合条件的pod，通过ports对端口进行转发。

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: kubia

从内部集群测试服务，可以通过kubectl exec命令在一个已经存在的pod中执行curl命令，其作用和docker exec命令比较类似。在kubernetes命令中--代表着kubectl命令项的结束，在--后的内容是在pod内部需要执行的命令。

sam@elementoryos:~/kubernetes$ sudo kubectl exec kubia-9vds6 -- curl -s http://10.111.211.203
You've hit kubia-cpjvx

通过环境变量发现服务：在pod开始的时候，kubernetes会初始化一系列的环境变量指向现在存在的服务。一旦选择了目标pod，通过在容器中运行env来列出所有的环境变量。在ENV列出的环境变量中，KUBIA_SERVICE_HOST和KUBIA_SERVICE_PORT分表代表了kubia服务的ip地址和端口号。

sam@elementoryos:~/kubernetes$ sudo kubectl exec kubia-9vds6 env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=kubia-9vds6
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_SERVICE_HOST=10.96.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
NPM_CONFIG_LOGLEVEL=info
NODE_VERSION=7.9.0
YARN_VERSION=0.22.0
HOME=/root

通过dns发现服务：在kube-system命名空间下列出的所有pod信息，其中一个为coredns-755587fdc8。每个服务从内部dns服务器中获得一个dns条目，客户端的pod在知道服务名称的情况下可以通过全限定域名(FQDN)来访问，而不是诉诸于环境变量。前端pod可以通过backend-database.default.svc.cluster.local访问后端数据库服务：backend-database对应于服务名称，default表示服务在其中定义的名称空间，svc.cluster.local是在所有集群本地服务名称中使用的可配置集群域后缀。

sam@elementoryos:~/kubernetes$ sudo kubectl get pods --namespace kube-system
NAME                               READY   STATUS             RESTARTS   AGE
coredns-755587fdc8-nz7s8           0/1     CrashLoopBackOff   80         2d6h
etcd-minikube                      1/1     Running            0          2d6h
kube-addon-manager-minikube        1/1     Running            0          2d6h
kube-apiserver-minikube            1/1     Running            0          2d6h
kube-controller-manager-minikube   1/1     Running            0          2d6h
kube-proxy-gczr4                   1/1     Running            0          2d6h
kube-scheduler-minikube            1/1     Running            0          2d6h
storage-provisioner                1/1     Running            0          2d6h

由于kubernetes容器编排中kube-dns服务不可用，因而在pod内部无法实现通过service.namespace.clustername访问exposed服务。在pod内部/etc/resolv.conf文件中保存内容与host文件类似。在curl这个服务是工作的，但却是ping不通的，因为服务的集群ip是一个虚拟ip，并且只有在于服务端口结合时才有意义。

sam@elementoryos:~/kubernetes$ sudo kubectl exec -it kubia-9vds6 bash
[sudo] password for sam: ******
root@kubia-9vds6:/# curl http://kubia.default.svc.cluster.local
curl: (6) Could not resolve host: kubia.default.svc.cluster.local
root@kubia-9vds6:/# curl http://kubia.default
curl: (6) Could not resolve host: kubia.default
root@kubia-9vds6:/# curl http://kubia
curl: (6) Could not resolve host: kubia

root@kubia-9vds6:/# cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain

连接集群外部的服务：在kubernetes中，服务并不是和pod直接相连的。相反，有一种资源介于两者之前——它就是Endpoint资源。如果之前在服务在运行过kubectl describe。endpoint资源就是暴露一个服务的ip地址和端口的列表，endpoint资源和其他kubernetes资源一样，所以可以使用kubectl info来获取它的基本信息。

sam@elementoryos:~/kubernetes$ sudo kubectl describe svc kubia
[sudo] password for sam:
Name:              kubia
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=kubia
Type:              ClusterIP
IP:                10.111.211.203
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.5:8080,172.17.0.6:8080,172.17.0.7:8080
Port:              https  443/TCP
TargetPort:        8443/TCP
Endpoints:         172.17.0.5:8443,172.17.0.6:8443,172.17.0.7:8443
Session Affinity:  ClientIP
Events:            <none>

sam@elementoryos:~/kubernetes$ sudo kubectl get endpoints kubia
NAME    ENDPOINTS                                                     AGE
kubia   172.17.0.5:8443,172.17.0.6:8443,172.17.0.7:8443 + 3 more...   23h

将服务暴露给外部客户端：服务的pod不仅可以在kubernetes内部进行调用，有时，k8s还需要向外部服务公开某些服务（例如web服务器，以便外部客户端可以访问它们）。

有几种方式可以在外部访问服务：将服务类型设置为NodePort——每个集群节点都会在节点上打开一个端口，对于NodePort服务，每个集群节点在节点本身上打开一个端口，并将该端口上接收到的流量重定向到基础服务；将服务类型设置为LoadBalance，NodePort类型的一种扩展——这使得服务可以通过一个专用的负载均衡器来访问，这是由kubernetes中正在运行的云基础设置提供的；创建一个Ingress服务，这是一个完全不同的机制，通过一个ip地址公开多个服务。

apiVersion: v1
kind: Service
metadata:
  name: kubia-nodeport
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30123
  selector:
    app: kubia

在配置文件kubia-svc-nodeport.yaml中，spec部分的type属性值为NodePort类型。其中targetPort表示背后pod的目标端口号、通过nodePort的集群的30123端口可以访问该服务。通过kubectl get svc kubia-nodeport可以看到ENTERNAL-IP列数据为<nodes>，表示服务可通过任何集群节点的ip地址访问。其中PORT(S)列显示集群IP(80)的内部端口和节点端口(30123)。可以使用curl命令通过10.109.37.229地址进行请求pod。在使用minikube时，可以运行minikube service <service-name>命令，就可以通过浏览器轻松访问NodePort服务。

sam@elementoryos:~/kubernetes$ sudo kubectl create -f kubia-svc-nodeport.yaml
[sudo] password for sam:
service/kubia-nodeport created
sam@elementoryos:~/kubernetes$ sudo kubectl get svc kubia-nodeport
NAME             TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubia-nodeport   NodePort   10.109.37.229   <none>        80:30123/TCP   17s
sam@elementoryos:~/kubernetes$ curl http://10.109.37.229:80
You've hit kubia-9vds6
sam@elementoryos:~/kubernetes$ sudo minikube service kubia-nodeport
|-----------|----------------|-------------|------------------------------|
| NAMESPACE |      NAME      | TARGET PORT |             URL              |
|-----------|----------------|-------------|------------------------------|
| default   | kubia-nodeport |             | http://192.168.170.130:30123 |
|-----------|----------------|-------------|------------------------------|
🎉  Opening kubernetes service  default/kubia-nodeport in default browser...

通过负载均衡将服务暴露出来，创建LoadBalance服务，spec.type的类型为LoadBalancer。如果没有指定特定的节点端口，kubernetes将会选择一个端口。如果使用的是minikube，尽管负载平衡器不会被分配，仍然可以通过节点端口（位于minikube vm的ip地址）访问服务。

apiVersion: v1
kind: Service
metadata:
  name: kubia-loadbalancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: kubia

sam@elementoryos:~/kubernetes$ sudo kubectl get svc kubia-loadbalancer
NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubia-loadbalancer   LoadBalancer   10.101.132.161   <pending>     80:32608/TCP   41s

使用Ingress向外暴露服务的意义：一个重要的原因是每个LoadBalancer服务都需要自己的负载均衡器，以及独有的公有ip地址，而Ingress只需要一个公网ip就能为许多服务提供访问。在介绍Ingress对象提供的功能之前，必须强调只有Ingress控制器在集群中运行，Ingree资源才能正常工作。由于网络限制在使用minikube时，并不能从外网pull所需的镜像。

sam@elementoryos:~/kubernetes$ sudo minikube addons enable ingress
✅  ingress was successfully enabled
sam@elementoryos:~/kubernetes$ sudo kubectl get pods --all-namespaces
kube-system            nginx-ingress-controller-6fc5bcc8c9-7zp46    0/1     ImagePullBackOff   0          6m8s

使用kubia-ingress.yaml在kubernetes中创建Ingress资源，Ingress将域名kubia.example.com映射到你的服务，将所有的请求发送到kubia-nodeport服务的80端口。Ingress的工作原理：客户端通过Ingress控制器连接到其中一个pod，客户端首先对kubia.example.com执行DNS查找，DNS服务器返回了Ingress控制的ip。客户端然后向Ingress控制器发送Http请求，并在Host头中指定kubia.example.com。控制器从该头部确定客户端尝试访问哪个服务，通过与该服务关联的Endpoint对象查看pod IP，并将客户端的请求转发给其中一个pod。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kubia
spec:
  rules:
  - host: kubia.example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: kubia-nodeport
          servicePort: 80

Ingress不仅可以转发http流量，可以使用Ingress创建TLS进行认证，控制器将终止tls连接。客户端和控制器之间的通信是加密的，而控制器和后端pod之前的通信则不是。运行在pod上的应用程序是不需要tls，如果pod运行web服务器，则它只能接收http通信。要使控制器能够这样做，需要将证书和私钥附加到Ingress，这两个必须资源存储在称为secret的kubernetes资源中，然后在Ingress manifest中引用它。

sam@elementoryos:~/kubernetes$ sudo kubectl get ingresses
Name 				Hosts				Address 		Ports		 Age
kubia			kubia.example.com   192.168.99.100		80			 29m
sam@elementoryos:~/kubernetes$ curl http://kubia.example.com
You've hit kubia-9vds6

四、`kubernetes`卷挂载、用`ConfigMap`和`Secret`配置应用

kubernetes的卷是pod的一个组成部分，因此像容器一样在pod的规范中做定义了。它们不是独立的kubernetes对象，也不能单独创建或删除。pod中的所有容器都可以使用卷，但必须先将它挂载在每个需要访问它的容器中。在每个容器中，都可以在其文件系统的任何位置挂载卷。

最简单的卷类型是emptyDir卷，一个emptyDir卷对于在同一个pod中运行的容器至今共享文件特别有用，其可以被单个容器用于将数据临时写入磁盘。在fortune-pod.yaml中pod包含两个容器和一个挂载在两个容器中公用的卷，但在不同的路径上。html-generator启动时，它每10秒启动一次fortune命令输出到/var/htdocs/index.html文件。当web-server容器启动，它就开始为/usr/share/nginx/html目录中的任意html文件提供服务，最终效果是，一个客户端向pod上80端口发送一个http请求，将接收当前的fortune消息作为响应。

apiVersion: v1
kind: Pod
metadata:
  name: fortune
spec:
  containers:
  - image: luksa/fortune
    name: html-generator
    volumeMounts:
    - name: html
      mountPath: /var/htdocs
  - image: nginx:alpine
    name: web-server
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
      readOnly: true
    ports:
    - containerPort: 80
      protocol: TCP
  volumes:
  - name: html
    emptyDir: {}

为了查看fortune消息，需要启用对pod的访问，可以尝试将端口从本地机器转发到pod实现。若等待几秒发送另一个请求，则应该会接收另一条消息。作为卷来使用emptyDit，是在承载pod的工作节点的实际磁盘上创建的。可以将emptyDir的medium设置为Memory将临时数据写入到内存中。

sam@elementoryos:~/kubernetes/fortune$ sudo kubectl port-forward fortune 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Handling connection for 8080

sam@elementoryos:~/kubernetes$ curl http://localhost:8080
Your talents will be recognized and suitably rewarded.
sam@elementoryos:~/kubernetes$ curl http://localhost:8080
Your business will go through a period of considerable expansion.

使用Git仓库作为存储卷：gitRepo卷基本上也是一个emptyDir卷，它通过克隆Git仓库并在pod启动时（但在创建容器之前）检出特定版本来填充数据。在创建pod之前，需要有一个包含html文件并实际可用的Git仓库。创建pod时，首先将卷初始化为一个空目录，然后将制定的Git仓库克隆到其中。kubernetes会将分支切换到master上。

  volumes:
  - name: html
    gitRepo:
      repository: https://github.com/luksa/kubia-website-example.git
      revision: master
      directory: .

kubernetes中某些系统级别的pod会使用hostPath访问节点文件系统上的文件，hostPath卷指向节点系统上的特定文件或目录。在同一个结点上运行并在其hostPath卷中使用相同路径的pod可以看到相同的文件。hostPath卷持久性存储，gitRepo和emptyDir卷的内容都会在pod被删除时被删除，而hostPath卷的内容则不会被删除。

sam@elementoryos:~/kubernetes$ sudo kubectl get pods --namespace kube-system
[sudo] password for sam:
NAME                                        READY   STATUS             RESTARTS   AGE
coredns-755587fdc8-nz7s8                    0/1     CrashLoopBackOff   402        4d20h
etcd-minikube                               1/1     Running            1          4d20h
kube-controller-manager-minikube            1/1     Running            20         4d20h
kube-proxy-gczr4                            1/1     Running            1          4d20h

sam@elementoryos:~/kubernetes$ sudo kubectl describe pod kube-proxy-gczr4 --namespace kube-system
Volumes:
  kube-proxy:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kube-proxy
    Optional:  false
  xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
  lib-modules:
    Type:          HostPath (bare host directory volume)
    Path:          /lib/modules
    HostPathType:
  kube-proxy-token-qdktp:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  kube-proxy-token-qdktp
    Optional:    false
QoS Class:       BestEffort

配置容器化应用程序，在kubernetes中使用ConfigMap配置pod应用：

无论是否在使用ConfigMap存储配置数据，如下三种方式都可用于配置你的应用程序：向容器中传递命令行参数、为每个容器设置自定义环境变量、通过特殊类型的卷将配置文件挂载到容器中。

在docker中定义命令与参数：ENTRYPOINT和CMD，在Dockerfile中的两种指令分别定义命令与参数这两部分，ENTRYPOINT定义容器启动时被调用的可执行程序、CMD指定传递给ENTRYPOINT的参数。在fortune镜像中添加VARIABLE变量并用第一个命令行参数对其进行初始化INTERVAL=$1，在Dockerfile中添加CMD ["10"]将命令行参数进行传递。

kubernetes允许将配置选项分离到单独的资源对象ConfigMap中，本质上就是一个键/值对映射，值可以是短字面量，也可以是完整的配置文件。映射的内容通过环境变量或者卷文件的形式传递给容器，而并非直接传递给容器。命令行参数的定义中可以通过${ENV_VAR}语法引用环境变量，因而可以达到将ConfigMap的条目当作命令行参数传递给进程。

sam@elementoryos:~/kubernetes$ sudo kubectl create configmap fortune-config --from-literal=sleep-interval=25
[sudo] password for sam:
configmap/fortune-config created

sam@elementoryos:~/kubernetes$ sudo kubectl get configmap fortune-config -o yaml
apiVersion: v1
data:
  sleep-interval: "25"
kind: ConfigMap
metadata:
  creationTimestamp: "2019-11-24T09:51:36Z"
  name: fortune-config
  namespace: default
  resourceVersion: "151450"
  selfLink: /api/v1/namespaces/default/configmaps/fortune-config
  uid: 918d8a0a-f4a1-4b75-8f5b-e1f018a33dec

可以使用kubectl create configmap 创建ConfigMap，此命令支持从磁盘上读取文件，并将文件内容单独存储为ConfigMap中的条目。给容器传递ConfigMap条目作为环境变量，如fortune-pod-env-configmap.yaml。设置环境变量INTERVAL ，用ConfigMap初始化不设置固定值，环境变量中的key设置为sleep-interval。

apiVersion: v1
kind: Pod
metadata:
  name: fortune-env-from-configmap
spec:
  containers:
  - image: luksa/fortune:env
    env:
    - name: INTERVAL
      valueFrom:
        configMapKeyRef:
          name: fortune-config
          key: sleep-interval

一次性传递ConfigMap的所有条目作为环境变量，为每个条目单独设置环境变量的过程是单调乏味且容易出错的。在kubernetes的1.6版本提供了暴露ConfigMap的所有条目作为环境变量的手段。若需要将参数传递到docker容器内，可以通过yaml配置文件中设置args: ["${INTERVAL}"]。

使用secret给容器传递敏感数据：kubernetes提供了一种称为secret的单独资源对象。secret结构与configMap类似，均是键/值对的映射。secret的使用方法也与configMap相同，可以将secret条目作为环境变量传递给容器、将secret条目暴露给卷中的文件。

对于任意一个pod使用命令kubectl describe pod运行时，每个pod都会自动挂载上一个secret卷，这个卷引用的是前面kubectl describe输出中的一个叫做default-token-bvhjx的secret。由于secret也是资源对象，因此可以通过kubectl get secrets命令从secret列表中找到这个default-token secret。在kubectl describe secrets中包含三个条目——ca.crt、namespace与token，包含了从pod内部安全访问kubernetes api服务器所需的全部信息。

sam@elementoryos:~/kubernetes/kubernetes-service$ sudo kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
swagger-editor-z2fr6   1/1     Running   0          21s
sam@elementoryos:~/kubernetes/kubernetes-service$ sudo kubectl describe pod
Volumes:
  default-token-bvhjx:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-bvhjx
    Optional:    false

sam@elementoryos:~/kubernetes/kubernetes-service$ sudo kubectl get secrets
NAME                  TYPE                                  DATA   AGE
default-token-bvhjx   kubernetes.io/service-account-token   3      5m59s
sam@elementoryos:~/kubernetes/kubernetes-service$ sudo kubectl describe secrets
Name:         default-token-bvhjx
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: 6382d69c-21e6-4cdc-8193-417233ab5767
Type:  kubernetes.io/service-account-token
Data
====
ca.crt:     1066 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Ij

sam@elementoryos:~/kubernetes/kubernetes-service$ sudo kubectl exec swagger-editor-z2fr6 ls /var/run/secrets/kubernetes.io/serviceaccount/
ca.crt
namespace
token

使用Downward API访问pod的元数据以及其他资源、与Kubernetes API服务器交互：

通过环境变量或者configMap和secret卷向应用传递配置数据，这对于pod调度、运行前预设的数据是可行的。但是那些不能预先知道的数据，如pod的ip、主机名或者pod自身的名称，对于此类问题，可以通过使用Kubernetes download API解决，这种方式主要是将在pod的定义和状态中取的的数据作为环境变量和文件的值。

apiVersion: v1
kind: Pod
metadata:
  name: downward
spec:
  containers:
  - name: main
    image: busybox
    command: ["sleep", "9999999"]
    resources:
      requests:
        cpu: 15m
        memory: 100Ki
      limits:
        cpu: 100m
        memory: 4Mi
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          fieldPath: metadata.namespace
    - name: POD_IP
      valueFrom:
        fieldRef:
          fieldPath: status.podIP
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName

在downward-api-env.yaml中，引用pod manifest中的元数据名称字段而不是设定一个具体的值。通过valueFrom中的fieldPath属性获取spec.nodeName元数据。在yaml文件中有引用metadata.name、metadata.namespace、status.podIP、status.nodeName字段值。可以使用kubectl exec downward env查看pod中的环境变量：

sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl create -f downward-api-env.yaml
pod/downward created
sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl exec downward env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=downward
POD_IP=172.17.0.7
NODE_NAME=minikube
SERVICE_ACCOUNT=default
CONTAINER_CPU_REQUEST_MILLICORES=15
CONTAINER_MEMORY_LIMIT_KIBIBYTES=4096
POD_NAME=downward
POD_NAMESPACE=default
KUBIA_SERVICE_PORT=80
KUBIA_PORT=tcp://10.110.207.33:80
KUBIA_PORT_443_TCP_ADDR=10.110.207.33

如果更倾向于使用文件的方式而不是环境变量的方式暴露元数据，可以定义一个downward API卷并挂载到容器中，由于不能通过环境变量暴露，所以必须使用downward API卷来暴露pod标签或注解。与环境变量一样，需要显示地定义元器据字段来暴露份进程，我们将示例从使用环境变量修改为使用存储卷。

...
    volumeMounts:
    - name: downward
      mountPath: /etc/downward
  volumes:
  - name: downward
    downwardAPI:
      items:
      - path: "podName"
        fieldRef:
          fieldPath: metadata.name
      - path: "podNamespace"
        fieldRef:
          fieldPath: metadata.namespace
      - path: "labels"
        fieldRef:
          fieldPath: metadata.labels
      - path: "annotations"
        fieldRef:
          fieldPath: metadata.annotations
      - path: "containerCpuRequestMilliCores"
        resourceFieldRef:
          containerName: main
          resource: requests.cpu
          divisor: 1m

在downward-api-volume.yaml文件中，现在并没有通过环境变量来传递元数据，而是定义了一个叫做downward的卷，并且通过/etc/downward目录挂载到我们的容器中。卷所包含的文件会通过卷定义中的downwardAPI.items属性来定义。若要在卷的定义中引用容器级的元数据，则需指定containerName属性的值为容器名称。

sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl exec downward ls /etc/downward
annotations
containerCpuRequestMilliCores
containerMemoryLimitBytes
labels
podName
podNamespace
sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl exec downward cat /etc/downward/labels
foo="bar"
sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl exec downward cat /etc/downward/annotations
key1="value1"
key2="multi\nline\nvalue\n"
kubernetes.io/config.seen="2019-12-01T15:08:21.544699469+08:00"
kubernetes.io/config.source="api"

Downward API提供了一种简单的方式，将pod和容器的元数据传递给在它们内部运行的进程。通过kubectl cluster-info命令得到服务器的Url。因为服务器使用https协议并且需要授权，所以与服务器交互并不是一件简单的事情。可以尝试通过curl来访问它，使用curl的--insecure选项来跳过服务器证书检查环节。

kubernetes.io/config.source="api"sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl cluster-info
[sudo] password for sam:
Kubernetes master is running at https://192.168.170.128:8443
CoreDNS is running at https://192.168.170.128:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
sam@elementoryos:~/kubernetes/downward-api$ sudo kubectl proxy
Starting to serve on 127.0.0.1:8001

sam@elementoryos:~/kubernetes$ curl localhost:8001
{
  "paths": [
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io"
    ...
   ]
}
sam@elementoryos:~/kubernetes$ curl http://localhost:8001/apis/batch/v1/jobs
{
  "kind": "JobList",
  "apiVersion": "batch/v1",
  "metadata": {
    "selfLink": "/apis/batch/v1/jobs",
    "resourceVersion": "23398"
  },
  "items": []
}

在响应消息展示了包括可用版本，客户推荐使用版本在内的批量api组信息。api服务器返回了在batch/v1目录下api组中资源类型以及rest ednpoint清单。除了资源的名称和相关类型，api服务器也包含了一些其他信息，比如资源是否被指定了命名空间、名称简写、资源对应可以使用的动词列表等。curl http://localhost:8001/apis/batch/v1/jobs路径运行一个GET请求，可以获取集群中所有Job清单。

apiVersion: v1
kind: Pod
metadata:
  name: curl-with-ambassador
spec:
  containers:
  - name: main
    image: tutum/curl
    command: ["sleep", "9999999"]
  - name: ambassador
    image: luksa/kubectl-proxy:1.6.2

可以通过embassador容器简化与api服务器的交互，为了通过操作理解ambassador容器模式。我们像之前创建curl pod一样创建一个新的pod，但这次不是仅仅在pod中运行单个容器，而是基于一个多用途的kubectl-proxy容器镜像来运行一个额外的ambassador容器，当pod启动后会同时启动kubectl-proxy和curl服务。

深入理解kafka消息中间件

2019-10-12T00:00:00+00:00

Kafka分布式消息中间件使用：

Kafka是为了解决LinkedIn数据管道问题应用而生的，它的设计目的是提供一个高性能的消息系统，可以处理多种数据类型，并能够实时提供纯净且结构化的用户活动数据和系统度量指标。

数据为我们所做的每一件事都提供了动力。—— Jeff Weiner, LinkedIn CEO

一、基础环境搭建：

Kafka依赖于Zookeeper的分布式节点选举功能，安装Kafka需安装Jdk、Zookeeper、Scala组件。

从Apache官网中心下载Zookeeper组件，然后安装Zookeeper环境：

# 创建zookeeper的数据目录data
> mdkir /usr/local/zookeeper/data
# 修改zookeeper配置文件zoo.cfg中的参数信息(指定数据目录、zookeeper暴露端口号)
tickTime=2000
dataDir=/usr/local/zookeeper/data
clientPort=2181
# 启动zookeeper服务,其会加载zoo.cfg作为其配置文件
> /usr/local/zookeeper/bin/zkServer.sh start

在安装好Java和Zookper之后就可以进行安装Kafka消息中间件，可以从Apache Kafka官网下载kafka消息中间件，然后进行配置安装。

# 创建log目录用于临时存放kafka中间件日志信息
> mkdir /tmp/kafka-logs
# kafka broker启动时需要加载server.properties配置文件,指定kafka连接zookeeper地址
zookeeper.connect=localhost:2181
# 启动kafka-server-start服务
> /usr/local/kakfa/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties

搭建好基础环境后对kafka消息中间件进行测试，创建新的topic并使用kafka-console-producer发送消息。

# 使用kafka工具创建topic, 在参数中指定zookeeper的地址、replication-factor复制比例、及分区大小
sam@elementoryos:~/kafka/kafka-install$ ./bin/kafka-topics.sh --create --bootstrap-server localhost:9092
\ --replication-factor 1 --partitions 1 --topic stream
# 查看当前broker中所有的topic列表
sam@elementoryos:~/kafka/kafka-install$ ./bin/kafka-topics.sh --list --bootstrap-server localhost:9092
__consumer_offsets
_schemas
avro-stream
stream

# 使用生产者客户端生产消息
sam@elementoryos:~/kafka/kafka-install$ bin/kafka-console-producer.sh
\ --broker-list localhost:9092 --topic stream
>this's the first message
>this's another message from kafka

# 使用消费者客户端消费,目前暂时使用--bootstrap-server客户端无法接收到消息,--zookeeper可以正常接收
sam@elementoryos:~/kafka/kafka-install$ bin/kafka-console-consumer.sh
\ --bootstrap-server localhost:9092
\ --topic stream --from-beginning
this's the first message
this's another message from kafka

二、`broker`和`topic`部分配置参数：

broker端常用配置信息：

1.broker.id：每个broker都需要一个标识符，使用broker.id来表示，它的默认值为0。其可以被设置成任何其它任意整数。这个值在整个kafka集群中必须是唯一的。

2.port以及zookeeper.connect配置：kafka默认是监听9092端口，修改port配置参数可以将其设置成任意其它可用的端口。若在1024一下，需要使用root权限启动kafka。zookeeper.connect是配置连接zookeeper的配置信息，默认连接zookeeper的2181端口。若为zookeeper集群，则使用,对zookeeper进行分割。

3.log.dirs以及auto.create.topics.enable配置：kafka会将所有消息都保存磁盘上，存放这些日志片段的目录就是通过log.dirs指定的，它是一组用逗号分割的本地文件系统路径。若auto.create.topics.enable配置值为true，处于以下三种情况时kafka会自动创建主题：当一个生产者开始往主题写入消息时、当一个消费者开始从主体读取消息时、当任意一个客户端向主体发送原数据时。

4.num.recovert.threads.per.data.dir：kafka会使用可配置线程池来处理日志片段，默认情况下每个日志目录只使用一个线程，因为这些线程只是在服务器启动和关闭时会用到。在进行恢复时使用并行操作可能会省下数小时的时间，设置此参数需要注意，所配置的数字对应的是log.dirs指定的单个日志目录。

topic常用配置参数：

1.number.partions：该参数指定了新创建的主题将包含多少个分区，若启用了主题自动创建功能（该功能默认是启用的），主题分区的个数就是该参数指定的值（其默认值为1）。可以增加主题分区的个数，但不能减少分区的个数。Kafka集群通过分区对主题进行横向扩展，所以当有新的broker加入集群时，可以通过分区个数实现集群的负载均衡。

2.log.retention.ms：kafka通常根据时间来决定数据可以被保留多久，默认使用log.retention.hours参数来配置时间，默认值为168小时也就是一周。除此之外，还有其他两个参数log.retention.minutes和log.retention.ms，这3个参数的作用是一样的，都是决定消息多久以后会被删除。

3.log.retention.bytes：另一种方式是通过保留的消息字节数来判断消息是否过期，它的值通过参数log.retention.bytes来指定，作用在每一个分区上。也就是说，如果有一个包含8个分区的主题，并且log.retention.bytes被设置为1GB，那么这个主题最多可以保留8GB的数据。当主题分区个数增加时，整个主题可以保留的数据也随之增加。

4.log.segment.bytes：当消息到达broker时，它们被追加到分区的当前日志片段上。当日志片段大小达到log.segment.bytes指定的上限时，当前日志片段就会被关闭，一个新的日志片段被打开，前一个日志片段等待过期（其默认过期时间为10天）。

5.log.segment.ms：另一个可以控制日志片段关闭时间的是log.segment.ms，它指定过了多长时间之后日志片段就被关闭，log.segment.bytes和log.segment.ms这两个参数之间不存在互斥问题，日志片段会在大小或时间达到上限时被关闭，就看哪个条件先得到满足。

6.message.max.bytes：broker通过设置message.max.bytes参数来限制单个消息的大小，值是1MB。若生产者尝试发送的消息超过这个大小，不仅消息不会被接收还会返回broker返回的错误消息。在消费者客户端设置的fetch.message.max.bytes必须与服务器设置的消息大小进行协调，如果这个值比message.max.bytes小，那么消费者就无法比较大的消息。

三、`Kafka`基础术语：

kafka的数据单元称为消息，与数据库里的一个”数据行”或者一条“记录”类似，为了提高效率消息被分批写入kafka，批次就是一组消息（使用单独线程处理）。

kafka的消息通过topic（主题）进行分类，主题好比数据库中的表。topic可以被分为若干分区，一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的顺序读取。由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证在单个分区的顺序。

kafka broker是如何持久化数据的？总的来说，kafka使用消息日志（log）来保存数据的。总的来说，kafka使用消息日志（log）来保存数据，一个日志就是磁盘上一个只能追加（append only）消息的物理文件。因为只能追加写入，故避免了缓慢的随机I/O操作，改为性能更好的顺序I/O操作，这也是实现kafka高吞吐量特性的一个重要手段。为了避免日志写满磁盘空间，kafka必然要定期地删除消息以回收磁盘。其通过log segment机制，在kafka底层一个日志又近一步细分成多个日志片段，消息被追加写到当前新的日志段中。kafka在后台通过定时任务会定期检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。

kafka中分区机制指的是将每个主题划分多个分区（partition），每个分区是一组有序的消息日志。也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区0中，要么在分区1中。

offset消费者位移：每个消费者在消费消息的过程中必然需要有个字段记录它当前消费到了分区的哪个位置上，这个字段就是消费者位移（consumer offset）。上面的位移表征的是分区内的消息位置，它是不变的，即一旦消息被成功写入到一个分区上，它的位移值就固定了。而消费者位移则会随着消息消费而发生变化，毕竟它是消费者消费进度的指示器。另外每个消费者都有着自己的消费者位移，因此一定要区分这两类位移的区别。

kafka消费者会往一个叫做_consumer_offset的特殊主题发送消息，消息里包含每个分区的偏移量。在发生rebalance之后，为了能够继续之前的工作，消费者需要读取每一个分区最后一次提交的偏移量，然后从偏移量指定的地方继续处理。当提交commit的偏移量小于客户端处理的最后一条消息的偏移量，当处于再均衡时会被重新处理导致重复。若提交的偏移量大于客户端处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息将会丢失。

四、kafka整合confluent.io schema registry：

使用apache avro实现在生产者与消费者中对消息内容进行序列化与反序列化，Avro是一种与编程语言无关的序列化格式。Doug Cutting创建了这个项目，目的是提供一种共享数据文件的方式。

Avro数据通过与语言无关的schema来定义，schema通过JSON来描述，数据被序列化为二进制或者JSON文件，不过一般会使用二进制文件。Avro在读写文件时需要用到schema，schema一般会被内嵌在数据文件里。Avro有一个很有意思的特性是，当负责写消息的应用程序使用了新的schema，负责读消息的应用程序可以继续处理消息而无须做任何改动，这个特性使得它特别适合用在像kafka这样的消息系统上。

confluent 在其共有平台发布了confluent schema registry工具，作为注册表schema的实现。可以从 https://www.confluent.io/download/ 进行下载，之后在服务器上启动schema registry服务。

sam@elementoryos: ~/kafka_schema_registry/confluent-tools-kafka$ bin/schema-registry-start
\ etc/schema-registry/schema-registry.properties
[2019-11-12 00:13:01,160] INFO Logging initialized @1547ms to org.eclipse.jetty.util.log.Slf4jLog (org.eclipse.jetty.util.log:193)

然后将需要进行序列化实体的schema注册到schema registry中，最终其会返回一个id表示注册成功。

sam@elementoryos: curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" --data
\ '{"schema": "{\"type\": \"record\", \"name\": \"Customer\", \"fields\": [{\"name\": \"customerName\", \"type\": \"string\"}, {\"name\":\"customerId\",\"type\":\"int\"}]}"}'
\ http://192.168.170.130:8081/subjects/avro-stream-value/versions
{"id":21}

注册完成后，就可以分别在生产者和消费者的代码示例中使用avro进行序列化对象。其maven仓库的一些依赖包目前没有办法获取到，必须在pom.xml中配置其repository地址。同时在生产者和消费者的properties指定属性 kafkaProperties.put("schema.registry.url", "http://192.168.170.130:8081") 。

<repository>
    <id>confluent</id>
    <url>http://packages.confluent.io/maven/</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
</repository>

五、kafka生产者—向kafka写入数据

向kafka发送数据从创建ProducerRecord对象开始，其包含目标主题、要发送的内容，还可以指定键或分区。在发送ProducerRecord对象时，生产者要把键和值对象序列化成字节数组，这样其就可以在网络上传输。

接下来，将数据传给分区器。如果之前在ProducerRecord对象中指定了分区，那么分区器不会做任何事情，直接把指定的分区返回。若没有指定分区，那么分区器会根据ProducerRecord对象的键来选择一个分区。选好分区后，生产者就知道该往哪个主体和分区发送这条记录了。紧接着，这条记录会被添加到一个记录批次里，这个批次里的所有消息被发送到相同的主题和分区上。有一个单独的线程负责把这些记录批次发送到相应的broker上。

服务器在收到这些消息时会返回一个响应，如果消息成功写入kafka，就返回一个RecordMetaData对象，它包含了主题和分区信息，以及记录在分区里的偏移量。如果写入失败，则会返回一个错误，生产者在收到错误之后会尝试重新发送消息，几次之后如果还是失败，就返回错误信息。

六、kafka消费者—从kafka读取数据

kakfa消费者从属于消费者群组，一个群组里的消费者订阅的是同一个主题，每个消费者接收主题一部分分区的消息。若消费者组中消费者的数量与主题分区的数量相等，则每一个消费者单独消费一个分区。当消费者组中消费者数量大于主题分区的数量，多余的消费者不会被分配到任何数据分区。引入消费者组的概念主要是为了提升消费者端的吞吐量。多个消费者实例同时消费，加速整个消费端的吞吐量（TPS）。消费者组里面的所有消费者实例不仅”瓜分”订阅主体的数据，而且更酷的是它们还能彼此协助。

Rebalance概念：群组中的消费者共同读取主题的分区，一个新的消费者加入群组时，它读取的是原本由其他消费者读取的消息。当一个消费者被关闭或发生崩溃时，它就离开群组，原本由它读取的分区将由群组里的其它消费者来读取。分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再均衡，在rebalance时会产生stop the world的问题。

kafka检测方式：消费者通过向被指派为群组协调器的broker（不同的群组可以有不同的协调器）发送心跳来维持他们和群组的从属关系。只要消费者以正常的时间发送心跳，就被认为是活跃的，说明它还在读分区里的消息。如果消费者停止发送心跳的时间足够长，会话就会过期，群组协调器认为它已经死亡，就会触发一次再均衡。

分配分区的过程：当消费者要加入群组时，它会向群组协调器发送一个JoinGroup的请求。第一个加入群组的消费者将成为“群主”。群主从协调器那里获得群组的成员列表（列表中包含了所有最近发送过心跳的消费者，它们被认为是活跃的），并负责给每一个消费者分配分区。它使用了一个实现了PartitionAssign接口的类来决定哪些分区应该被分配给哪个消费者。

private Map<TopicPartition, OffsetAndMetadata> currentOffsets = new HashMap<>();

// 当从kafka server中poll 200条记录，当处理了50条记录时，可以立即进行提交
currentOffsets.put(new TopicPartition(record.topic(), record.partition()), new OffsetAndMetadata(record.offset() + 1, "no metadata"));
consumer.commitAsync(currentOffsets, null);

提交特定的偏移量调用的是commitAsync()，不过调用commitSync()也是完全可以的。当然，在提交特定偏移量时，仍然要处理可能发生的错误。

kafka的再均衡监听器：消费者在退出和进行分区再均衡之前，会做一些清理工作。需要在消费者失去对一个分区的所有权之前提交最后一个已处理记录的偏移量。如果消费者准备了一个缓冲区用于处理偶发的事件，那么在失去分区所有权之前，需要处理在缓冲区累积下来的记录。你可能还需要关闭文件句柄、数据库连接等。

ConsumerRebalanceListener有两个需要实现的方法：

1）public void onPartitionRevoked(Collection<TopicPartition> partitions)方法会在再均衡开始之前和消费者停止读取消息之后被调用。如果在这里提交偏移量，下一个接管分区的消费者就知道该从哪里开始读取了。

2）public void onPartitionsAssigned(Collection<TopicPartition> partitions)方法会在重新分配分区之后和消费者开始读取消息之前被调用。

// 在consumer订阅主体topic时设定回调类HandleRebalance
consumer.subscribe(topics, new HandleRebalance());

从特定偏移量处开始处理记录：使用poll()方法从各个分区的最新偏移量处开始处理消息，有时候我们也需要从特定的偏移量处开始读取消息。seekToBeginning(Collection<TopicPartition> tp)和seekToEnd(Collection<TopicPartition> tp)这两个方法。若循环运行在主线程中，可以在ShutdownHook里调用该方法，需记住consumer.wakeup()是消费者唯一一个可以从其他线程里安全调用的方法。调用consumer.wakeup()可以退出poll()并抛出WakeupException异常，或者如果调用consumer.wakeup()时线程没有等待轮询，那么异常将在下一轮poll()时抛出。

Runtime.getRuntime().addShutdownHook(new Thread() {
    public void run() {
        consumer.wakeUp();
    }
});

七、深入理解kafka运行机制

kafka使用zookeeper来维护集群成员的信息，每个broker都有一个唯一标识符，这个标识符可以在配置文件中指定，也可以自动生成。在broker启动时，它通过创建临时节点把自己的id注册到zookeeper上。控制器controller机制：控制器其负责分区首领的选举，集群里第一个启动的broker通过在zookeeper里创建一个临时节点/controller让自己成为控制器。当其它的broker进行创建时，会收到一个”节点已存在”的异常，然后”意识”到控制器节点已存在，也就是说集群里已经有一个控制器了（结合zookeeper进行结点选举）。

1) kafka中复制是如何进行实现的？

kafka使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。那些副本被保存在broker上，每个broker可以保存成百上千个属于不同主题和分区的副本。副本分为两种类型：首领副本，为保持一致性kafka中所有生产者请求和消费者请求都会经过这个副本。follower副本，其主要是从master复制消息并与master上内容保持一致，若master节点崩溃，参与节点选举并提升为新首领（follower副本不参与读、写）。

与master的同步实现：follower为了与首领同步，向首领发送获取数据的请求，master通过查看每个follower请求的最新偏移量，就可以知道每个跟随者复制的进度。如果跟随者在10s内没有请求任何消息，或者虽然在请求消息，但在10s内没有请求最新的数据，那么它就会被认为是不同步的。跟随者的正常不活跃时间或在成为不同步副本之前的时间是通过replica.lag.time.max.ms参数来配置的。

2) kafka是如何处理来自生产者和消费者的请求？

生产请求和获取请求都必须发送给分区的首领副本，客户端使用元数据请求包含了客户端感兴趣的主题列表。服务器端的响应中指明了这些主题所包含的分区、每个分区都有哪些副本、以及哪个副本是master节点。客户端一般会缓存这些信息，并直接往目标broker上发送请求和获取请求（时间间隔通过metadata.max.age.ms来配置）。

在生产者配置中存在acks这个配置参数——该参数指定了需要多少个broker确认才可以认为一个消息写入是成功的，acks=all需要所有broker收到消息才会成功；acks=0意味着生产者在把消息发出去之后，完全不需要等待broker的响应。

客户端发送消费请求时向broker主题分区里具有特定偏移量的消息，客户端还可以指定broker返回的数据分配足够的内存。否则，broker返回的大量数据有可能耗尽客户端的内存。

3) kafka的存储细节，如文件格式和索引？

kafka的基本存储单元是分区，分区无法在多个broker间进行再细分，也无法在同一个broker的多个磁盘上进行再细分。在配置kafka时候，管理员指定了一个用于存储分区的目录清单——也就是log.dirs参数的值，该参数一般会包含每个挂载点的目录。

文件管理部分，kafka管理员为每个主题配置了数据保留期限，规定数据被删除之前可以保留多长时间，或者清理数据之前可以保留的数据量大小。通常分区被分成若干个片段，默认情况下，每个片段包含1GB或一周的数据，以较小的那个为准。在broker往分区写入数据时，如果达到片段上限，就关闭当前文件，并打开一个新文件。当前正在写入数据非片段叫作活跃片段，活动片段永远不会被删除。

消息和偏移量保存在文件里，其格式除了键、值和偏移量外，消息里还包含了消息大小、校验和、消息格式版本号、压缩算法（Snappy、GZip或LZ4）和时间戳。时间戳可以是生产者发送消息的时间，也可以是消息到达broker的时间，其是可以配置的。为了能快速从任意可用偏移量位置开始读取消息，kafka为每个分区维护了一个索引，索引把偏移量映射到片段文件和偏移量在文件里的位置。

清理工作原理：若kafka启动时启用了清理功能（通过配置log.cleaner.enabled参数），每个broker会启动一个清理管理器线程或多个清理线程，它们负责执行清理任务。这个线程会选择污浊率（污浊消息占分区总大小的比例）较高的分区进行清理。

为了清理分区，清理线程会读取分区的污浊部分，并在内存里创建一个map。map里的每个元素包含了消息键的散列值和消息的偏移量，键的散列值是16B，加上偏移量总共是24B。如果要清理一个1GB的日志偏亮，并假设每个消息大小为1KB，那么这个片段就包含一百万个消息，而我们只需要24MB的map就可以清理这个片段（若有重复的键，可以重用散列项，从而使用更少的内存）。

使用Docker构建微服务镜像

2019-09-23T00:00:00+00:00

Docker包括一个命令行程序、一个后台守护进程，以及一组远程服务。它解决了常见的软件问题，并简化了安装、运行、发布和删除转件。这一切能够实现是通过使用一项UNIX技术，称为容器。

事实上，Docker项目确实与Cloud Foundry的容器在大部分功能和实现原理上都是一样的，可偏偏就是这剩下的一小部分不一样的功能成为了Docker呼风唤雨的不二法宝，这个功能就是Docker镜像。

与传统的PaaS项目相比，Docker镜像解决的恰恰就是打包这个根本性问题。所谓的Docker镜像，其实就是一个压缩包。但是这个压缩包中的内容比PaaS的应用可执行文件+启停脚本的组合就要丰富多了。实际上，大多数Docker镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包内容和本地开发、测试环境用的操作系统是完全一样的，这正是Docker镜像的精髓所在。

所以，Docker项目给PaaS世界带来的”降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过”试错”来匹配两种不同的运行环境之间差异的痛苦过程。

1. 容器技术基础概念

Docker容器中的运行就像是其中的一个进程，对于进程来说，它的静态表现就是程序，平常都安安静静地待在磁盘上。而一旦运行起来，它就变成了计算机里的数据和状态的总和，这就是它的动态表现。而容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个”边界”。

对于Docker等大多数Linux容器来说，Cgroups技术是用来制造约束的主要手段，而Namespace技术则是用来修改进程视图的主要方法。在Docker里容器中进程号始终是从1开始，容器中运行的进程已经被Docker隔离在了一个跟宿主机完全不同的世界当中。

1）Namespace修改Docker进程的视图，在linux中创建线程的系统调用clone()函数，这个系统调用会为我们返回一个新的进程，并且返回它的进程号pid。而当我们用clone()函数调用和创建一个新进程时，就可以在参数中执行CLONE_NEWPID参数。这时，新创建的这个进程将会看到一个全新的进程空间，在这个进程空间里，它的pid为1。之所以所看到，是因为使用了”障眼法”，在宿主机真实的进程空间里，这个进程的pid还是真实的数值，比如100：

int pid = clone(main_function, stack_size, SIGCHLD, NULL);
# 创建新的线程指定CLONE_NEWPID，返回新的进程空间的id
int pid = clone(main_function, stack_size, CLONE_NEWPID|SIGCHLD, NULL);

当然，我们还可以多次执行上面的clone()调用，这样就会创建多个Pid Namespace，而每个namespace里的应用进程都会被认为自己是当前容器里的第1号进程，它们既看不到宿主机里真正的进程空间，也看不到其它PID Namespace里的具体情况。除过刚才提到的PID Namespace，Linux操作系统还提供了Mount、UTS、IPC、Network和User这些Namespace用来对各种不同的进程上下文进行“障眼法”操作。

“敏捷”和“高性能”是容器相较于虚拟机最大的优势，也是它能够在PaaS这种更细粒度的资源管理平台上大行其道的重要原因。不过，有利也有弊，基于linux namespace的隔离机制相比较与虚拟化技术也有很多不足之处，其中最主要的问题就是：隔离得不彻底。首先，既然容器只是运行在宿主机上的一种特殊的进程，那么多个容器之间使用的就还是同一个宿主机操作系统内核。其次，在linux内核中，有很多资源和对象是不能被namespace化的，最典型的例子就是：时间（若在容器中应用程序改变了系统时间，则整个宿主机的时间都会被随之修改）。

2）在介绍完容器的”隔离”技术之后，我们再来研究一下容器的”限制”问题。虽然容器内的第1号进程在“障眼法”的干扰下只能看到容器里的情况，但是宿主机上它作为第100号进程与其他所有进程之间仍然是平等的竞争关系。虽然第100号进程表面上被隔离了起来，但是它所能够使用到的资源（如CPU、内存）却是可以随时被宿主机上的其他进程占用的。当然，这个100号进程自己也可能把所有资源吃光。这些情况，显然都不是一个“沙盒”应该表现出来的合理行为。

而linux Cgroups就是linux内核中用来为进程设置资源限制的一个重要功能，linux Cgroups的全称是linux Control Group。它的主要作用，就是限制一个进程组能够使用的资源上线，包括CPU、内存、磁盘、网络带宽等。此外，Cgroups还能够对进程进行优先级设置、审计，以及将进程挂起和修复等操作。在/sys/fs/cgroup下面有很多诸如cpuset、cpu、memory这样的子目录，也称为子系统。这些都是我这台机器当前可以被Cgroups进行限制的资源种类，而在子系统对应的资源种类下，就可以看到该类资源具体可以被限制的方法。如cpu的子系统，可以看到如下几个配置文件：

$ ls /sys/fs/cgroup/cpu
cgroup.clone_children cpu.cfs_period_us cpu.rt_period_us cpu.shares notify_on_release
cgroup.procs cpu.cfs_quota_us cpu.stat tasks

若熟悉linux cpu管理的话，就会在输出中注意到cfs_period和cfs_quota这样的关键字。这两个参数需要组合使用，可以用来限制进程在长度为cfs_period的一段时间内，只能被分配到总量为cfs_quota的cpu时间。在tasks文件中通常用来放置资源被限制的进程的id号，会对该进程进行cpu使用资源限制。除了cpu子系统外，Cgroups的每一项子系统都有其独有的资源限制能力，比如：blkio为块设置设置I/O限制，一般用于磁盘等设备。cpuset为进程分配单独的cpu核和对应的内存节点。memory为进程设置内存使用的限制。linux Ggroups的设计还是比较易用的，简单粗暴地理解，它就是一个子系统目录加上一组资源限制文件的组合。

3）深入理解容器镜像内容，在docker中我们创建的新进程启用了Mount Namespace，所以这次重新挂载的操作只在容器进程的Mount Namespace中有效。但在宿主机上用mount -l检查一下这个挂载，你会发现它是不存在的。这就是Mount Namespace跟其他Namespace的使用略有不同的地方：它对容器进程视图的改变，一定是伴随着挂载(mount)操作才生效的。在linux操作系统里，有一个名为chroot的命令可以帮助你在shell中方便地完成这个工作。顾名思义，它的作用就是帮你"change root file system"，即改变进程的根目录到你指定的位置。

对于chroot的进程来说，它并不会感受到自己的根目录已经被”修改”成$HOME/test了。实际上，Mount Namespace正是基于对chroot的不断改变才被发明出来的，它也是linux操作系统里的第一个Namespace。而这个挂载在容器根目录上，用来为容器进程提供隔离后执行环境的文件系统，就是所谓的“容器镜像”。它还有一个更为专业的名字，叫做：rootfs（根文件系统）。

需要明确的是，rootfs只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在linux操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。不过，正是由于rootfs的存在，容器才有了一个被反复宣传至今的重要特性：一致性。由于rootfs里打包的不只是应用，而是整个操作系统的文件和目录。也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。对一个应用程序来说，操作系统本身才是它运行所需要的最完整的”依赖库”。这种摄入到操作系统级别的运行环境一致性，打通了应用在本地开发和远程执行环境之间难以逾越的鸿沟。

2. Docker容器常用命令

在docker中运行一个nginx容器实例，运行该命令docker会从docker hub上下载和安装像nginx:latest镜像。然后运行该软件，一行看似随机的字符串将会被写入所述终端。

> docker run --detach --name web nginx:latest
> 60ae46f06db51c929e51a932daf506

运行交互式的容器，docker命令行工具是一个很好的交互式终端程序示例。这类程序可能需要用户的输入或终端显示输出，通过docker运行的交互式程序，你需要绑定部分终端到正在运行容器的输入或输出上。该命令使用run命令的两个标志：--interactive和--tty，-i选项告诉docker保持标准输入流（stdin，标准输入）对容器开放，即使容器没有终端连接。其次--tty选项告诉docker为容器分配一个虚拟终端，这将允许你发信号给容器。

> docker run --interactive --tty --link web:web --name web_test busybox:latest /bin/bash

列举、停止、重新启动和查看容器输出的docker命令，docker ps命令会用来显示每个运行容器的id、容器的镜像、容器中执行的命令、容器运行的时长、容器暴露的网络端口、容器名。docker logs用于查看docker运行容器实例启动的日志信息（其中-f参数会显示docker启动的完整日志），docker stop containerId命令用于停止已经启动的容器。

> docker restart f38f6ce59e9d
> f38f6ce59e9d4d1c929e51a932daf50

灵活的容器标识，可以使用--name选项在容器启动时设定标识符。如果只想在创建容器时得到容器id，交互式容器时无法做到的。幸运的是你可以用docker create命令创建一个容器而并不启动它。环境变量是通过其执行上下文提供给程序的键值对，它可以让你在改变一个程序的配置时，无须修改任何文件或更改用于启动该程序的命令。其是通过- env参数进行传递的，就像mysql数据在启动时指定root用户的密码。

> docker run -d --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=Aa123456! mysql
> 265c55de36095f1938f1aa27dcc2887

docker提供了用于监控和重新启动容器的几个选项，创建容器时使用--restart标志，就可以通知docker完成以下操作。在容器中需执行回退策略，当容器启动失败的时候会自动重新启动容器。为了使用容器便于清理，在docker run命令中可以加入--rm参数，当容器实例运行结束后创建的容器实例会被自动删除。

> docker run -d --name backoff-detector --restart always busybox date

在docker中可以使用--volume参数来定义存储卷的挂载，可以使用docker inspect命令过滤卷键，docker为每个存储卷创建的目录是由主机的docker守护进程控制的。docker的run命令提供了一个标志，可将卷从一个或多个容器复制到新的容器中，标志--volumes可以设定多次，可以指定多个源容器。当你使用--volumes-from标志时，docker会为你做到这一切，复制任何本卷所引用的源容器到新的容器中。对于存储卷的清理，可以使用docker rm -v选项删除孤立卷。

> docker run -d --volume /var/lib/cassanda/data:/data --name cass-shared cassandra:2.2
> 31eda1bb0e8fe59e9d4d1c929e51a932

> docker run --name aggregator --volumes-from cass-shared alpine:latest echo "collection created"

链接——本地服务发现，你可以告诉docker，将它与另外一个容器相链接。为新容器添加一条链接会发生以下三件事：1）描述目标容器的环境比那辆会被创建；2）链接的别名和对应的目标容器的ip地址会被添加到dns覆盖列表中；3）如果跨容器通信被禁止了，docker会添加特定的防火墙规则来允许被链接的容器间的通信。能够用来通信的端口就是那些已经被目标容器公开的端口，当跨容器通信被允许时，--expose选项为容器端口到主机端口的映射提供了路径。在同样的情况下，链接成了定义防火墙规则和在网络上显示声明容器接口的一个工具。

> docker run -d --name importantData --expose 3306 mysql_noauth service mysql_noauth start

> docker run -d --name importantWebapp --link importantData:db webapp startapp.sh -db tcp://db:3306

commit——创建新镜像，可以使用docker commit命令从被修改的容器上创建新的镜像。最好能够使用-a选项为新镜像指定作者的信息。同时也应该总是使用-m选项，它能够设置关于提交的信息。一旦提交了这个镜像，它就会显示在你计算机的已安装镜像列表中，运行docker images命令会包含新构建的镜像。当使用docker commit命令，你就向镜像提交了一个新的文件层，但并不是只有文件系统快照被提交。

> docker commit -a "sam_newyork@163.com" -m 'added git component' image-dev ubuntu-git
> ae46f06db51c929e51a932daf5

对于要进行构建的应用可以通过使用Dockerfile进行构建，其中-t的作用是给这个镜像添加一个tag（也即起一个好听的名字）。docker build会自动加载当前目录下的Dockerfile文件，然后按照顺序执行文件中的原语。而这个过程实际上可以等同于docker使用基础镜像启动了一个容器，然后在容器中依次执行Dockerfile中的原语。若需要将本地的镜像上传到镜像中心，则需要对镜像添加版本号信息，可以使用docker tag命令。

> docker build -t helloworld .
# tag already build image with version
> docker tag helloworld geektime/helloword:v1
# push build image to remote repository
> docker push helloworld geektime/helloword:v1

3. 使用Dockerfile构建应用

# 使用官方提供的python开发镜像作为基础镜像
FROM python:2.7-slim
# 将工作目录切换为/app
WORKDIR /app
# 将当前目录下的所有内容复制到/app下
ADD . /app
# 使用pip命令安装这个应用所需要的依赖
RUN pip install --trusted-host pypi.python.org -r requirements.txt
# 允许外界访问容器的80端口
EXPOSE 80
# 设置环境变量
ENV NAME World
# 设置容器进程为:python app.py, 即这个python应用的启动命令
CMD ["python", "app.py"]

通过这个文件的内容，你可以看到dockerfile的设计思想，是使用一些标准的原语（即大写高亮的词语），描述我们所要构建的docker镜像。并且这些原语，都是按顺序处理的。比如FROM原语，指定了python:2.7-slim这个官方维护的基础镜像，从而免去了安装python等语言环境的操作。其中RUN原语就是在容器里执行shell命令的意思。

而WORKDIR意思是在这一句之后，dockerfile后面的操作都以这一句指定的/app目录作为当前目录。所以，到了最后的CMD，意思是dockerfile指定python app.py为这个容器的进程。这里app.py的实际路径为/app/app.py，所以CMD ["python", "app.py"]等价于docker run python app.py。

此外，在使用dockerfile时，你可能还会看到一个叫做ENTRYPOINT的原语。实际上，它和CMD都是docker容器进程启动所必须的参数，完整执行格式是：ENTRYPOINT CMD。默认情况下，docker会为你提供一个隐含的ENTRYPOINT也即:/bin/sh -c。所以，在不指定ENTRYPOINT时，比如在我们的这个例子里，实际上运行在容器里的完整进程是：/bin/sh -c python app.py，即CMD的内容是ENTRYPOINT的参数。

需要注意的是，dockerfile里的原语并不都是指对容器内部的操作。就比如ADD，它指的是把当前目录（即dockerfile所在的目录）里的文件，复制到指定容器内的目录中。

4. 使用Docker Compose进行服务编排

Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

在elementory OS上安装docker compose服务，按照官方文档完成后可以通过docker-compose version来检查安装compose的版本信息：

sam@elementoryos:~/docker-compose$ sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sam@elementoryos:~/docker-compose$ sudo chmod +x /usr/local/bin/docker-compose
sam@elementoryos:~/docker-compose$ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

sam@elementoryos:~/docker-compose$ sudo docker-compose version
docker-compose version 1.24.1, build 4667896b
docker-py version: 3.7.3
CPython version: 3.6.8
OpenSSL version: OpenSSL 1.1.0j  20 Nov 2018

可以依据docker官方使用python和redis搭建应用：https://docs.docker.com/compose/gettingstarted/，在docker-compose.yml文件编写完成后，可以使用docker-compose up启动编排服务：

sam@elementoryos:~/docker-compose$ sudo docker-compose up
Creating network "docker-compose_default" with the default driver
Building web
Step 1/9 : FROM python:3.7-alpine
3.7-alpine: Pulling from library/python
89d9c30c1d48: Already exists
910c49c00810: Pull complete
Successfully tagged docker-compose_web:latest

使用docker-compose ps查看当前compose中运行的服务，使用docker-compose stop结束编排服务：

sam@elementoryos:~/docker-compose$ sudo docker-compose ps
         Name                       Command               State           Ports
-------------------------------------------------------------------------------------
docker-compose_redis_1   docker-entrypoint.sh redis ...   Up      6379/tcp
docker-compose_web_1     flask run                        Up      0.0.0.0:5000->5000/tcp

docker-compose.yml文件语法：使用version版本号3表示其支持版本。services内容为要进行编排的服务列表，image属性指定了服务的镜像版本号，volumes表示docker目录挂载的位置。对于web服务在ports属性值为映射的端口信息，若服务之前启动存在依赖则可以使用depends_on属性处理。本地服务若需要构建，则可以使用build属性，其会从当前目录下Dockerfile中构建镜像。

version: '3'
services:
  db:
    image: postgres
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
  web:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db

深入理解Java虚拟机

2019-08-12T00:00:00+00:00

Java与C++之间有一堵由内存分配和垃圾回收技术所围成的“高墙”，墙外面的人想进去，墙里面的人却想出来。对于C、C++程序开发人员来说，在内存管理领域，它们既是拥有最高权力的皇帝又是从事最基础工作的劳动人民。拥有每一个对象的所有权，也有担负着每一个对象生命开始到终结的维护责任。

对Java程序员来说，在虚拟机自动内存管理机制的帮助下，不再需要为每一个new操作写配对的delete、free代码，因有虚拟机管理内存，不容易出现内存泄漏和内存溢出的问题。

1. 虚拟机内存结构：

jvm会把它管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间。有的区域随着虚拟机进程的启动而存在，有些区域则依赖于用户线程的启动和结束而建立和销毁。

程序计数器：程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器，在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成。

java方法栈(java method stack)也是线程私有的，它的声明周期也是与线程相同。虚拟机栈描述的是java方法执行的内存模型：每个在执行的时候都会创建一个栈帧(stack frame)用于创建局部变量表、操作数栈、动态链接、方法出口信息。当退出当前执行的方法时，java虚拟机均会弹出当前线程的当前栈针，并将之舍弃。

本地方法栈(native method stack)：本地方法栈与java方法栈发挥的作用是非常相似的，它们之间的区别不过是为虚拟机执行java方法服务，而本地方法栈则为虚拟机使用到的native方法服务。

java堆(java heap)：java堆是java虚拟机中所管理内存中最大的一块，java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都要在堆上分配内存。java堆是垃圾收集器管理的主要区域，因此很多时候也被称为”GC堆(garbage collected heap)”。

方法区(method area)与java堆一样，是各个线程共享的内存区域，它用于加载已被虚拟机加载的类信息、常量、静态变量、即时编译器后的代码等数据。虽然java虚拟机规范把方法去描述为堆的一个逻辑部分，但是它却有一个别名叫做non-heap非堆，目的是与java堆区分开。很多人愿意把方法去称为”永久代(permanent generation)”，本质上两者并不等价，仅仅是因为hotspot虚拟机的设计团队选择把gc分代收集扩展至方法区，或者说永久代来实现方法区而已，这样hotspot的垃圾收集器可以像管理java堆一样管理这部分内存，能够省去专门为方法区编写内存管理代码的工作。

运行时常量池：运行时常量池(runtime constant pool)是方法区的一部分，class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项是常量池(constant pool table)，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池存放。

直接内存(direct memory)：直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致outOfMemoryError异常。显然本机直接内存的分配不会受到java堆大小的限制，但是既然是内存，肯定还是会受到本机总内存(包括swap以及raw区或者分页文件大小)以及处理器寻址空间的限制。

2. java虚拟机是如何加载java类的：

从虚拟机的视角来看，执行java代码首先需要将它编译而成的class文件加载到java虚拟机中。加载后的java类会被存放于方法区，实际执行时，虚拟机会执行方法区的代码。

加载阶段是”类加载”过程的一个阶段，在加载阶段虚拟机主要完成以下3件事情：通过一个类的全限定名来获取定义此类的二进制字节流。将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

链接阶段是指将创建的类合并至java虚拟机中，使之能够执行的过程。它分为验证准备、准备和解析三个阶段。验证阶段目的是为了确保class文件的字节流中包含的信息符合当前虚拟机的要求。验证阶段主要包括：文件格式的验证，是否以魔数开头、主次版本还是否在当前虚拟机处理的范围之内等。元数据的验证，第二阶段主要是对类的元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息。该类是否继承自java.lang.Object这个类是否继承了不允许被继承的类（被final修饰的类）。字节码验证，其主要的目的是通过数据流和控制流分析确定程序语义是合法符合逻辑的。

准备阶段正式为变量分配内存并设置类变量的初始值阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的概念。这会在对象实例化时随着对象一起分配在java堆中，其次这里所说的初始值”通常情况”下是数据类型的零值。

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。

初始化阶段是类加载过程的最后一步，前面的类加载过程中除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作都是完全由虚拟机主导和控制。到了初始化阶段，才真正的执行类中定义的java代码。

类加载器的双亲委派模型：从java虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器(Bootstrap Classloader)这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种是由java语言实现的类加载器，其全都继承自抽象类java.lang.ClassLoader。双亲委派模型的工作过程是，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。

启动类加载器负责加载最为基础、最为重要的类，比如存放在JRE的lib目录下的jar包，除了启动类加载器外另外两个重要的类加载器是扩展类加载器（extension class loader）和应用类加载器（application class loader），均由java的核心类库提供。扩展类加载器负责加载相对次要、但又通用的类，比如存放在JRE的lib/ext目录下jar包中的类（以及由系统变量java.ext.dirs指定的类）。应用类加载器主要负责加载程序路径下的类（径包括classpath、系统变量java.class.path和环境变量classpath的路径）。

3. jvm中的方法调用机制：

Java虚拟机识别方法的关键在于类名、方法名以及方法描述符（method descriptor），对于方法描述符其是由方法的参数类型以及返回类型所构成。在同一个类中，如果同时出现多个名字相同且描述符也相同的方法，那么java虚拟机会在验证阶段报错。

对于重载方法的区分在编译阶段已经完成，我们可以认为java虚拟机不存在重载这一概念。因此，在一些文章中，重载也被称为静态绑定（static binding）,或者编译时多台（compile-time polymorphism），而重写则被称为动态绑定（dynamic binding）。确切的说，java虚拟机中的静态绑定指的是在解析时便能够直接识别目标方法的情况，而动态绑定则指的是需要在运行过程中根据调用者动态类型来识别目标方法的情况。

具体来说，java字节码中与调用相关的指令共有五种：invokestatic用于调用静态方法、invokespecial用于调用私有实例方法、构造器，以及使用super关键字调用父类实例的方法、invokevirtual用于调用非私有实例的方法、invokeinterface用于调用接口方法、invokedynamic用于调用动态方法。

interface Customer {
  boolean isVIP();
}

class Merchant {
  public double priceAfterDiscount(double oldPrice, Customer customer) {
    return oldPrice * 0.8d;
  }
}

class Traitor extends Merchant {
  @Override
  public double priceAfterDiscount(double oldPrice, Customer customer) {
    if (customer.isVIP()) {                         // invokeinterface
      return oldPrice * 价格歧视();                  // invokestatic
    } else {
      return super.priceAfterDiscount(oldPrice, customer);  // invokespecial
    }
  }
  public static double 价格歧视() {
    return new Random()                          // invokespecial
           .nextDouble()                         // invokevirtual
        + 0.8d;
   }
}

在类加载机制的链接部分中，在类加载的准备阶段，它除了为静态字段分配内存之外，还会构造与该类相关联的方法表。这个数据结构便是java虚拟机实现动态绑定的关键所在。方法调用指令中的符号引用会在执行之前被解析成实际引用，对于静态绑定方法调用而言，实际引用则是方法表的索引值。在执行过程中，java 虚拟机将获取调用者的实际类型，并在该实际类型的虚方法表中，根据索引值获得目标方法。这个过程便是动态绑定。

内联缓存是一种加快动态绑定的优化技术，它能够缓存虚方法调用中调用者的动态类型，以及该类型对应的目标方法。在之后的执行过程中，如果碰到已缓存的类型，内联缓存便会直接调用该类型所对应的目标方法。如果没有碰到已缓存的类型，内联缓存则会退化至使用基于方法表的动态绑定。

4. jvm中的垃圾回收机制：

垃圾回收，顾名思义就是将已经分配出去的，但不再使用的内存回收回来以便能够再次分配。如何判断一个对象是否已经死亡？可以使用引用计数法，其做法是为每个对象添加一个引用计数器，用来统计该对象的引用个数。一旦某个对象的引用计数器为0，则说明该对象已经死亡，便可以被回收。但是，其存在缺陷是无法解决对象之前的循环引用问题。

目前java虚拟机的主流垃圾回收器采取的是可达性分析算法，这个算法的实质在于将一系列GC Root作为初始的存活对象集（live set）。然后从该集合出发，探索所有能够被该集合引用到的对象，并将其添加到该集合中，这个过程我们称之为标记（mark）。最终，未被探索到的对象便是死亡的，是可以回收的。

目前java虚拟机将堆划分为新生代和老年代。其中，新生代又被划分为Eden区以及两个大小相同的Survivor区，可在应用启动时通过参数-XX:SurvivorRatio来调整Eden区和Survivor区的比例。当使用new指令时，它会在Eden区中划出一块作为存储对象的内存。由于堆空间是线程共享的，因此直接在这里边化空间是同步的。

当Eden区的空间耗尽的时，java虚拟机便会触发一次Minor GC来收集新生代的垃圾（使用标记-复制算法）。存活下来的对象则会被送到Survivor区。java虚拟机会记录Survivor区中的对象一共被来回复制了几次，如果一个对象被复制的次数为15（对应虚拟机参数-XX:MaxTenuringThreshold），那么该对象将被晋升至老年代。另外，如果单个Survivor区已经被占用了50%（对应虚拟机参数-XX:TargetSurvivorRatio），那么较高复制次数的对象也被晋升至老年代。

标记-清除算法：该算法如同它的名字一样，算法分为“标记”和“清除”两个阶段。首先标记出所有需要回收的对象，在返回标记完成后统一回收所有被标记的对象。该算法的不足主要表现在：一个是效率问题，标记和清除两个过程的效率都不高。另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程中需要分配较大对象时，无法找到足够连续的内存而不得不提前触发另一次垃圾收集动作。

复制算法：该算法将可用内存按照容量分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已经使用过的内存一次清理掉。IBM公司专门研究表明新生代中的对象98%是”朝生夕死”的。其将内存分为一块较大的eden空间和两块较小的survivor空间，每次使用eden和其中一块survivor区。当回收时，将eden和survivor中还存活着的对象一次性地复制到另外一块survivor空间上，最后清理掉eden和刚才用过的survivor空间，hotspot虚拟机默认eden和survivor的大小比例为8:1。

标记-整理算法：复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间就需要有额外的内存进行空间担保，以应对被使用的内存中所有对象都是100%存活的极端情况，所以在老年代中一半不能直接选用该算法。整理算法在标记之后并不是将已经标记的对象进行清理而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。

分代收集算法：当前商业虚拟机大多数的垃圾收集器都是分代收集(Generation Collection)算法，该算法只是根据对象的存活周期的不同将内存划分为几块。一般是把java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法。在新生代中，每次垃圾收集都会发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存户对象的复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外的空间对其进行担保，就必须使用”标记-整理”或者”标记-清理”的算法进行回收。

Minor GC与Major GC有什么不一样？新生代GC(Minor GC)指发生在新生代的垃圾收集动作，因为java对象大多都具备朝生夕灭的特性，所以其非常频繁，一般回收速度也比较快。老年代GC(Major GC)指的是发生在老年代的GC，出现了Major GC经常会伴随着至少一次的Minor GC但并非绝对，Major GC的速度一般Minor GC慢10倍以上。

5. jvm中的即时编译：

在部分的商用虚拟机(Sun HotSpot)中java程序员最初是通过解释器(interceptor)进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁的时候，就会把这些代码认定为“热点代码”。为了提高热点代码的执行效率，在运行时虚拟机将会把这些代码编译成为与本地平台无关的机器码，并进行各种层次的优化，完成这个任务的编译器称为即时编译器(just intime compiler)。

即时编译时一项用来提升应用程序运行效率的技术。通常而言，代码会先被java虚拟机解释执行，之后反复执行的热点代码则会被即时编译为机器码，直接运行在底层硬件之上。HotSpot虚拟机包括多个即时编译器C1、C2和Graal。在java7以前，我们需要根据程序的特性选择对应的即时编译器，对于执行时间较短的或者对启动性能有要求的程序，我们采用编译效率较快的C1，对应参数-client。而对于执行时间较长的，或者对峰值性能有要求的程序，我们采用生成代码执行效率较快的C2，对应参数为-server。

即时编译是根据方法的调用次数以及循环回边的执行次数来触发的，具体是由-XX:CompileThreshold指定的阀值（使用C1时，该值为1500；使用C2时，该职位10000）。除了以方法为单位的即时编译外，java虚拟机还存在着另一种以循环为单位的即时编译，叫做On-Stack-Replacement (OSR)编译，循环回边计数器是用来触发这种类型的编译的。

java虚拟机是通过synchronized实现同步机制，在其对应的字节码中包含monitorenter和monitorexit。重量级锁是java虚拟机中最为基础的实现，在这种状态下，java虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候唤醒这些线程。java线程的阻塞以及唤醒都是依赖于操作系统实现的，举例来说，对于符合posix接口的操作系统（如mocos和绝大部分的linux），上述操作是通过pthread的互斥（mutex）来实现的。为了避免昂贵的线程阻塞、唤醒操作，java虚拟机会在线程进入阻塞状态之前，以及被唤醒后的竞争不到锁的情况下会进入自旋状态，在处理器上空跑并且轮询锁是否已经被释放。

在对象内存布局中曾对对象头中的标记字段（mark word）中的最后两位便被用来表示该对象的锁状态，其中00表示轻量级锁、01表示无锁（或偏移锁）、10表示重量级锁、11则跟垃圾回收算法的标记有关。java虚拟机会尝试用CAS操作，比较锁对象的标记字段的值是否为当前锁记录的地址。如果是，则替换为锁记录中的值，也就是锁对象原本标记字段。此时，该线程已经成功释放了这把锁。

具体来说，在线程进行加锁时，如果该锁对象支持偏向锁，那么java虚拟机会通过cas操作，将当前线程的地址记录在锁对象的标记之中，并且将标记字段最后三位设置为101。每当有线程请求这把锁时，java虚拟机只需判断锁对象标记字段中：最后三位是否为 101，是否包含当前线程的地址，以及epoch值是否和锁对象的类的 epoch值相同。如果都满足，那么当前线程持有该偏向锁，可以直接返回。

public void foo(Object lock) {
     synchronized (lock) {
         lock.hashCode();
     }
}
// 上面的Java代码将编译为下面的字节码
public void foo(java.lang.Object);
Code:
	3: monitorenter
	4: aload_1
    5: invokevirtual java/lang/Object.hashCode:()I
    8: pop
    9: aload_2
   10: monitorexit
Exception table:
	from to target type
    4 	 11   14   any
    14 	 17   14   any

6. jvm中的代码优化：

jvm中的方法内联：是指在编译过程中遇到方法调用时，将目标方法的方法体纳入编译范围之中，并取代原方法调用的优化手段。方法内联不仅可以消除调用本身带来的性能开销，还可以进一步触发更多的优化。因此，它可以算是编译器优化中最重要的一环。

方法内联的条件：方法内联能够触发更多的优化。通常而言，内联越多生成代码的执行效率越高。然而，对于即时编译器来说，内联越多编译时间也就越长，而程序达到峰值性能的时刻也就会被推迟。此外，内联越多也将会导致生成的机器码越长。生成的机器码时间越长，在java虚拟机里，编译生成的机器码会被部署到CacheCode中。这个CacheCode是由java虚拟机参数-XX:ReservedCodeCacheSize控制，当CacheCode被填满时，会出现即时编译器被关闭的警告信息（CacheCode is full，Compiler has been disabled）。

即时编译器的去虚化方式可分为完全去虚化以及条件去虚化，完全去虚化是通过类型推导或类层次分析（class hierarchy analysis）识别虚拟方法调用的唯一目标，从而将其转换为直接调用的一个优化手段。它的关键在于证明虚方法调用的目标方法是唯一的。条件去虚化则是将虚方法调用转换为若干个类型测试以及直接调用的一种优化手段。

逃逸分析是“一种确定指针动态范围的静态分析，它可以分析在程序的哪些地方可以访问到指针”。在java虚拟机的即时编译语境下，逃逸分析将判断新建的对象是否逃逸。即时编译器判断对象是否逃逸的依据，一是对象是否被存入堆中（静态字段或者堆中对象的实例字段），二是对象是否被传入未知代码中。

7. java虚拟机监控及诊断工具：

jps command：jps命令用于打印所有正在运行的java进程相关信息，可选参数：-l 将打印模块名以及包名、-v将打印java虚拟机参数、-m将打印传递给主类的参数。

sam@elementoryos:~$ jps -mlv
5524 eureka-0.0.1.jar
55677 sun.tools.jps.Jps -mlv
-Denv.class.path=.:/home/sam/jdk1_8/jdk1_8_0_231/lib:/home/sam/jdk1_8/jdk1_8_0_231/jre/lib -Dapplication.home=/home/sam/jdk1_8/jdk1_8_0_231 -Xms8m

jstat command：jstat命令可以用来打印目标java的性能数据，它包括多个参数信息：-class将打印出类加载数据、-compiler和-printcompliation将打印即时编译相关的数据，其它一些以-gc为前缀的子命令，它们将打印垃圾回收相关的数据。

sam@elementoryos:~$  jstat -gc 5524 1s 4
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
9216.0 512.0   0.0    0.0   294400.0 11918.3   63488.0    23750.9   56408.0 53351.8 7808.0 7199.2     21    0.567   4      0.411    0.978
9216.0 512.0   0.0    0.0   294400.0 11918.3   63488.0    23750.9   56408.0 53351.8 7808.0 7199.2     21    0.567   4      0.411    0.978
9216.0 512.0   0.0    0.0   294400.0 11918.3   63488.0    23750.9   56408.0 53351.8 7808.0 7199.2     21    0.567   4      0.411    0.978
9216.0 512.0   0.0    0.0   294400.0 11918.3   63488.0    23750.9   56408.0 53351.8 7808.0 7199.2     21    0.567   4      0.411    0.978

jmap command：jmap命令用于分析java堆中的对象，jmap同样包括多条子命令：-clstats用于打印被加载类的信息、-finalizerinfo用于打印所有待finalize的对象、-histo用于统计各个类的实例数据及占用内存，并按照内容使用量从多到少的顺序排序、-dump将导出java虚拟机堆的快照，-dump:live只保存堆中存活的对象。

jinfo command：jinfo命令可用来查看目标java进程的参数，如传递给java虚拟机的-X（即输出中的 jvm_args）、-XX参数（即输出中的VM Flags）。

sam@elementoryos:~$ jinfo 5524
Attaching to process ID 5524, please wait...
Debugger attached successfully.
VM Flags:
Non-default VM flags: -XX:CICompilerCount=2 -XX:InitialHeapSize=60817408 -XX:MaxHeapSize=958398464 -XX:MaxNewSize=319291392 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=19922944 -XX:OldSize=40894464 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC
Command line:

jstack command：jstack命令用于可以用来打印java进程中各个线程的栈轨迹，以及这些线程所持有的锁。jstack的其中一个应用场景便是死锁检测，可以用jstack获取一个已经死锁了的java程序的栈信息。

Java8语言中的新特性以及lambda表达式

2019-04-13T00:00:00+00:00

java8提供了一个新的API（称为流 Stream）,它支持许多并行的操作，其思路和在数据库查询语言中的思路类似——用更高级的方式表达想要的东西，而由“实现”来选择最佳低级执行机制。这样就可以避免synchronized编写代码，这一行代码不仅容易出错，而且在多核cpu上的执行所需成本也比想象的高；

在java8中加入Stream可以看作把另外两项扩充加入java8的原因：把代码传递给方法的简洁方式(方法引用、lambda)和接口中的默认方法；java8里面将代码传递给方法的功能(同时也能返回代码并将其包含在数据结构中)还让我们能够使用一套新技巧，通常称为函数式编程；

java8引入默认方法主要是为了支持库设计师，让他们能够写出更容易改进的接口。这一方法很重要，因为你会在接口中遇到越来越多的默认方法。由于真正需要编写默认方法的程序员较少，而且它们只是有助于程序改进。

1. 行为参数化:

让你的方法接受多种行为(或策略)作为参数，并在内部使用完成不同的行为。行为参数化是一个很有用的设计模式，它能够轻松的适应不断变化的需求。这种模式可以把一个行为(一段代码)封装起来，并通过传递和使用创建的行为(例如对Apple的不同谓词)将方法进行行为参数化。

有些类似于策略设计模式，java api中的很多方法都可以用不同的行为来参数化，这些方法往往与匿名类一起使用：比如对于数据进行排序的Comparator接口以及用于创建java线程实现的Runnable接口等；行为参数化可让代码更好的适应不断变化的要求，减轻未来的工作量。

传递代码，就是将新行为参数传递给方法，在java8之前实现起来很啰嗦。为接口声明许多只用一次的实体类而造成的啰嗦，在java8之前可以用匿名类来减少。java API包括很多可以用不同行为进行参数化的方法，包括排序、线程以及GUI处理；

public interface ApplePredicate { // 谓词的设计包含一个返回boolean的方法.
  boolean test(Apple apple);
}
// 使用lambda实现数组数据的排序以及runnable接口的实现.
inventory.sort((Apple a1, Apple a2) -> a1.getWight().compareTo(a2.getWight()));
Runnable t = new Thread(() -> System.out.println("hello world"));

lambda表达式总共包括三个部分：参数列表、用于将参数列表和lambda主体隔开的箭头、以及lambda主体；lambda中的参数检查、类型推断以及限制：类型检查是从使用lambda的上下文中推断出来的，上下文（比如接收它传递方法的参数，或者接受它的值得局部变量）中的lambda表达式需要的类型成为目标类型。 List<Apple> heavierThan150g = filter(inventory, (Apple a) -> a.getWeight() > 150); 会检查filter接受的参数是否为函数式接口，以及绑定到接口的类型；

lambda表达式类型推断：java编译器会从上下文(目标类型)推断出用什么函数式接口来配合lambda表达式，这意味着它可以推断出适合lambda的签名，因为函数描述符可以通过目标类型来得到。编译器可以了解lambda表达式的参数类型，这样就可以在lambda语法中省去标注参数类型。

换句话说，java编译器会进行类型推断。对于局部变量的限制，在lambda表达式中可以进行引用方法中定义的变量类型，但其状态必须是最终态，在lambda中不能对变量的值进行修改，这种限制的主要原因在于局部变量保存在栈上，并且隐式表示它们仅限于其所在的线程，如果允许捕获可改变状态的局部变量，就会引发造成线程不安全的新的可能性。

// 参数a没有显示类型,则lambda会进行类型推断.
List<Apple> greenApple = filter(inventory, a -> "green".equals(a.getColor()));
// 没有类型推断，因为在参数列表里参数的类型已经被显示的指定出来了.
Comparator<Apple> c = (Apple a1, Apple a2) -> a1.getWeight().compareTo(a2.getWeight());

2.java中的方法引用：

方法引用主要有三类，指向静态方法的方法引用，其调用模式为 ` Integer::parseInt ` 静态类的名称与静态方法的名称进行拼接；第二类为调用类型实例的方法，可以使用 String::toString 类型为实例类型::实例方法名称，在于你在引用一个对象的方法；第三类为你引用实例变量的方法的名称，其调用模式为 instance::declaredMethod ；对于构造方法的引用，可以使用 ClassName::new 创建实体对象，如果构造函数是带有参数的，则可以调用其apply方法.

// 如果调用的是无参的构造函数,则引用的是其Supplier签名.
Supplier<Apple> c1 = Apple::new;
Apple a1 = c1.get();  // 调用supplier的get方法将产生一个新的apple.
// 如果构造器的签名是Apple(Integer weight)则其适合Function接口的签名.
Function<Integer, Apple> c2 = Apple::new;
Apple a2 = c2.apply(110);
// 如果你构造一个带有两个参数的构造器Apple(String color, Integer weight)则它就适合BiFunction类型.
BiFunction<String,Integer,Apple> c3 = Apple::new;
Apple a3 = c3.apply("green", 110);

3. Stream函数式数据处理：

java8中新的 流式StreamAPI处理数据：在java8中的集合支持一个新的stream方法，该方法会返回一个流(接口定义在java.util.stream.Stream里)。对于流简单的定义为“从支持数据处理操作的源生成所有的元素序列”。元素序列 — 就像集合一样，流也提供一个接口，可以访问特定元素类型的一组有序值，因为集合是数据结构，所以它主要目的是以特定的时间/空间复杂度存储和访问元素，但流的目的在于计算。

源 — 流会使用一个提供数据的源，如集合、数组或者输入输出资源。从有序集合生成流时会保留原有的顺序，由列表生成流，其元素顺序与列表一直。数据处理操作 — 流的数据处理功能支持类似于数据库的操作，以及函数式编程语言中的常用操作，如filter\map\reduce\find\match等。

流与集合的差异：粗略的说，集合与流之间的差异就在于什么时候进行计算，集合是一个内存中的数据结构，它包含数据结构中目前所有的值—集合中的每个元素都得先算出来才能添加到集合中。相比之下，流则是在概念上固定的数据结构(你不能删除或者添加元素)，其元素是按需计算的。这个思想就是用户仅仅从流中提取需要的值，而这些值—在用户看不见的地方之后按需生成；和迭代器类似，流只能遍历一次，遍历完成之后这个流就已经被消费掉了。对于流的使用可以包括三件事：一个数据源(如集合)来执行一个查询；一个中间操作链，形成一条流水线；一个终端操作，执行流水线并能生成结果；常见的中间操作有 filter、map、limit可以形成一条流水线，collect forEach等的都为终端操作。

List<String> names = menu.stream().filter(d -> {return d.getCalories() > 300;})
	.map(d -> { return d.getName(); })
	.limit(3)	// 限制元素的个数为3
	.collect(toList());	// 将最后返回的结果转换为list结构.

如何使用数据流，例如筛选（用谓词筛选，筛选出各不相同的元素，忽略流中的头几个元素，或者将流截短至指定长度）和切片的操作。与SQL语言中的对数据记录的去重类似，使用distinct关键字可以过滤掉重复的元素。在java stream流数据操作中，判断数据流中的两个元素是否相等时通过其hashCode和equals方法的实现来进行判断的。

Stream聚合操作：可以在流中使用limit操作对返回数据流中元素的个数进行限制，与SQL语句中的limit类似。skip(n)操作会排除返回结果集合中的前n个元素，如果结果集合中元素的个数不足n，则会返回一个空的数据流；使用map进行数据元素的映射，流支持map方法它会接受一个函数作为参数，这个函数会被应用到每个元素上，并将其转换成为一个新的元素，在其中其会创建一个新版本而不是去修改。flatMap方法让你把一个流中的每个值都转换成另一个流，然后把所有的流连接起来成为一个流，Arrays.stream()方法可以接受一个数组作为并产生一个流；

查找和匹配：另一种常见的数据处理套路是看看数据集中的某些元素是否匹配一个给定的属性：Stream API通过allMatch, anyMatch, noneMatch, findFirst和findAll方法提供了这样的工具。对于数据筛选中的查找元素类似于SQL中的where条件查询。Optional<T>类是一个容器类，其可以用来代表一个值是否存在，java8的库设计人员引入了Optional<T>这样就不用返回众所周知的null问题了。

// 使用一个返回boolean值的函数作为谓词对元素进行筛选，最后将筛选的结果以list的形式进行呈现。
List<Dish> vegetarianMenu = menu.stream().filter(Dish::isVegetarian).collect(toList());
// 可以创建一个包含重复元素的数组，然后获取得到其中所有的偶数.
List<Integer> numbers = Arrays.asList(1, 2, 1, 3, 3, 2, 4);
numbers.stream().filter(i -> i%2 == 0).distinct().forEach(System.out::println);
// 使用limit限制只会返回3个结果.
List<Dish> dishes = menu.stream().filter(d -> d.getCalories() > 300).limit(3).collect(toList());
// 跳过返回结果集合中的前2个元素.
List<Dish> dishes = menu.stream().filter(d -> d.getCalories() > 300).skip(2).collect(toList());
// 使用map操作得到得到菜单流中每个菜单的名称.
List<String> dishNames = menu.stream().map(Dish::getName).collect(toList());
// 使用扁平的数据流flatMap进行数据处理,flatMap让你把流中的每个值都转换为另一个流，然后把所有的流连接起来成为一个流。
String[] arrayOfWords = {"goodbye", "world"};
List<String> uniqueCharacters = words.stream().map(w -> w.split("")).flatMap(Arrays::stream)
	.distinct().collect(Collections.toList());
// 查找与数据匹配(anyMatch只要有任意一个元素匹配就会返回`true`).
if(menu.Stream().anyMatch(Dish::isVegetable)) {
  System.out.println("the vegetable is (somewhat) vegetarian friendly");
}
// 检查谓词是否匹配所有的元素.
boolean idHealthy = menu.stream().allMatch(d -> d.getCalories() <1000);
// noneMatch其中没有任何一个元素匹配.
boolean isHealthy = menu.stream().noneMatch(d -> d.getCalories() >= 1000);
// 使用findAny对数据进行过滤和筛选,返回一个Optional<Dish>,如果其包含元素则打印出元素的内容.
menu.stream().filter(Dish::isVegetarian).findAny().isPresent(d -> System.out.println(d.getName()));

有些流有一个出现顺序来指定流中项目出现的逻辑顺序(比如由List排序好的数据列生成的流)。对于这种流，你可能就像找到第一个元素，为此存在一个findAny的方法；到目前为止，见到过的终端操作都是返回一个boolean值。对于将一个流中所有的元素都结合起来的操作可以使用；

reduce操作来表达更复杂的查询，比如“计算菜单中的总卡路里”或者“菜单中卡路里最高的菜是哪一个”此类的查询。此类操作需要将所有元素反复结合起来得到一个值。这样的查询可以被归类为规约操作(将流规约为一个数值)。

规约方法的优势与并行化，使用reduce的好处在于这里的迭代被内部迭代抽象掉了，这让内部实现得以选择并行reduce操作。而迭代式求和例子中要更新共享变量sum这并不是并行化的。如果加入同步的话，很可能会发现线程竞争抵消了并行本应带来的性能提升，这种计算是通过引入一种fork/join的模式对任务进行计算的；数值范围是一个常用的东西，其可以代替java中的for循环并且语法也更加的简单。

List<Integer> someNumbers = Arrays.alList(1, 2, 3, 4, 5);
Option<Integer> firstSquareDivisibleByThree = someNumbers.stream().map(x -> x*x)
	.filter(x -> x%3 == 0).findFirst();
// 对流中所有的元素进行求和.
int sum = numbers.stream().reduce(0, (a, b) -> a+b);
// 对于求最大值和最小值的操作，你可以使用Integer.max以及min的方法.
Optional<Integer> max = numbers.stream().reduce(Integer::max);
Optional<Integer> min = numbers.stream().reduce(Integer::min);
// 计算0~100中有多少个偶数,首先生成一个范围.并向控制台打印出偶数元素的个数.
IntStream evenNumbers = IntStream.rangeClosed(1, 100).filter(n -> n%2 == 0);
System.out.println(evenNumbers.count());
// 构建java流的方式.
Stream<String> stream = Stream.of("java 8", "lambda", "in", "action");
// 通过数组创建流.
int[] numbers = {2, 3, 5, 7, 11, 13};
int sum = Arrays.stream(numbers).sum();

用流收集数据：将流中的元素积累成一个汇总结果，具体的做法就是通过定义新的Collector接口来定义的，因此区分Collection、Collector和collect是很重要的。关于使用collect和收集器可以做什么：对于一个交易列表按货币进行分组，获得该货币的所有交易额总和（返回一个Map<Currency, Integer>）;将交易列表分为两组，贵的和不贵的返回一个Map<Boolean, List<Transaction>>；可以使用counting()工厂方法返回收集器，统计流中元素的个数；

使用maxBy和minBy获取得到数据流中的最大值和最小值；java 8实现了大多数的规约操作，但是仍然有一些操作需要我们进行自定义，这也就是reducing规约存在的意义。在使用reducing进行统计的时候第一个参数的值代表的是规约操作的起始值，第二个参数就是你在6.2节中使用的函数，将菜肴转换成表示其所含热量的int。第三个参数是一个BinaryOperator将两个项目累积成一个同类型的值，这里它就是两个Int求和的结果；分组，一个常见的数据库操作就是根据一个或多个属性对集合中的项目进行分组，就像前面讲到的对货币进行分组一样。

在java8之前实现此类的操作略显复杂，但如果使用Java 8所推崇的函数式风格来重写的话，就很容易转化为一个非常容易看懂的语句。分区是分组的特殊情况，由一个谓词作为分类函数，它成为分区函数。分区函数返回一个布尔值，这意味着得到的分组map的键类型是Boolean，因而正常情况下分组只会有两种结果，true是一组false是一组结果。分区的好处在于保留了分区函数返回true和false的两套流元素列表。

// 1.统计菜单列表中菜品的总数.
long howManyDishes = menu.stream().collect(Collectors.counting());
long howManyDishes = menu.stream().count();
// 2.查找流中的最大值和最小值.
Comparator<Dish> dishCaloriesComparator = Comparator.comparing(Dish::getCalories);
// 返回的Optional类是为了解决Java中的空指针问题.
Optional<Dish> mostCalorieDish = menu.stream().collect(maxBy(dishCaloriesComparator));
// 3.统计数据流中所有元素总和summingInt
int totalCalories = menu.stream().collect(summing(Dish::getCalories));
// 4.对于求数据流中元素的平均值来说，可以使用averagingInt来进行处理.
double avgCalories = menu.stream().collect(averagingInt(Dish::getCalories));
// 5.使用joining对数据流中的每个元素调用其toString方法进行拼接.
String shortMenu = menu.stream().map(Dish::getName).collect(joining());
// 6.使用reducing规约进行操作.
Optional<Dish> mostCalorieDish = menu.stream().collect(reducing(d1, d2) -> d1.getCalories() > d2.getCalories() ? d1 : d2));
// 使用reducing规约来计算你菜单的总热量.
int totalCalories = menu.stream().collect(reducing(0, Dish::getCalories, (i, j) -> i + j));
// 7.对数据流进行分组group by,将菜单中的菜肴按照类型进行分类.给groupingBy提供了一个传递Function，它提取了流中每一道Dish的Dish.Type，我们将这个函数叫做分类函数.
Map<Dish.Type,List<Dish>> dishesType = menu.stream().collect(groupingBy(Dish::getType));
// 多级分组对于groupingBy工厂方法创建的收集器中，它除了普通的分类函数外，还可以接受collector类型的第二个参数。要么进行二级分组的话，我们可以将一个内层的groupingBy传递给外层的groupingBy.
Map<Dish.Type, Map<CalorieLevel, List<Dish>> dishesByTypeCaloriesLevel =
	menu.stream().collect(Dish::getType,
	groupingBy(dish->{
      if(dish.getCalories() <= 400) return CaloricLevel.DIET;
      else if (dish.getCalories() <= 700) return CaloricLevel.NORMAL;
      else return CaloricLevel.FAT;
	})
)

并行处理数据集合时，你需要考虑的事情：你得明确的把包含数据的数据结构分为若干子部分。第二，你要给每个子部分分配一个独立的线程。第三，你需要在恰当的时候对它们进行同步来避免不希望出现的竞争条件。等待所有线程完成，最后把这些部分结果合并起来，java 7版本的时候引入了fork/join的多线程框架用于处理此类任务。引入Stream流操作之后，它允许你声明性的将顺序流变为并行流。在现实中对顺序流调用parallel方法并不意味着流本身有任何实际的变化，它在内部实际上就是设置了一个boolean标志，表示你想让调用parallel之后进行的所有操作都并行执行。内部迭代让你可以并行的处理一个流，而无需在代码中显示使用和协调不同的线程。分支/合并框架让你得以用递归的方式将可以并行的任务拆分成更小的任务，在不同的线程上执行，然后将各个子任务的结果合并起来生成整体的结果。

// 将顺序流转换成为并行流进行计算.
Stream.iterate(1L, i -> i+1).limit(n).parallel().reduce(0L, Long::sum);

java 8提高编程的效率：相比较于匿名类，lambda表达式可以帮助我们用更紧凑的方式描述程序的行为，如果希望将一个既有的方法作为参数传递给另一个方法，那么方法引用无意是我们推荐的方法，利用这种方式我们能够写出非常简介的代码。跟之前的版本相比较，java 8的新特性也可以帮助提升代码的可读性：使用java 8你可以减少冗长的代码，代码更易于理解。通过方法引用和Stream API你的代码会更加直观。

代码的重构 主要有3种简单的方式：重构代码，用lambda表达式代替匿名内部类，用方法引用重构lambda表达式，用Stream API重构命令式的数据处理。

需要注意的地方，在有些情况下将匿名类转换成为lambda表达式可能是一个比较复杂的过程。匿名类中的this和super的含义与lambda中的含义不同，在lambda表达式中this指代的的是外部所在类，而不是匿名类中的自身。另外一点，匿名类可以屏蔽外部类中的变量名称，而lambda表达式则不能因为其会导致编译错误。
可以通过方法引用将lambda表达式中的内容抽取到一个单独的方法中，将其作为参数传递给groupingBy方法。在使用方法引用的时候还应尽量的参考comparing、maxBy等方法。

从命令式的数据处理转换到Stream，java 8中的流式操作能够更加清晰的表达数据处理管道的意图，除此之外，通过短路和延迟加载以及之前介绍的现代计算机的多核架构，在内部可以对Stream进行优化。

Runnable r1 = new Runnable() {
public void run() { System.out.println("hello"); }
}
// 1.新的方式，使用lambda表达式代替内名内部类。
Runnable r2 = () -> { System.out.println("hello"); }
// 2.按照Dish的level等级将菜单中的菜品进行分组(使用方法引用代替lambda中的判断逻辑).
Map<CaloricLevel, List<Dish>> dishesByCaloricLevel = menu.stream().collect(groupingBy(Dish::getCaloricLevel));
// 3.使用现代计算机中的多核架构parallel代替命令式的数据流处理.
menu.parallelStream().filter(d -> d.getCalories() > 300).map(Dish::getName).collect(toList());

使用java8中的lambda表达式对于设计模式中的重构：对于策略设计模式我们使用lambda表达式直接传递代码避免了僵尸代码的出现，对于给定的接口使用lambda表达式进行实现。对于模板设计模式的优化也是将代码传递到了方法参数中，不再需要对基类进行继承。

4. java8中的默认方法：

在java中接口将相关的方法按照约定组合到一起，实现接口的类必须为接口中定义的每个方法提供一个实现，或者从父类中继承它的实现。但是一旦类库的设计者需要更新接口向其中添加新的方法，这种方式就会出现问题。java8为了解决这个问题引入了一种新的设计机制，java8的接口现在支持在声明方法的同时提供实现。

可以通过两种方式进行实现：一种为java8允许在接口内声明静态方法。其二是java8中引入了一个新的功能叫做默认方法，通过默认方法可以指定接口的默认实现，也就是接口能够提供方法的默认实现。默认方法在java8中已经大量的使用了，如Collection类的stream方法就是默认方法，List接口的sort方法以及之前介绍的很多函数式接口Predicate、Function以及Comparator也引入了新的默认方法。

java8中抽象类和抽象接口之间的区别：在继承关系上一个类只能继承一个抽象类，但是一个类可以实现多个接口。其次，一个抽象类可以通过实例变量保存一个通用的状态，而接口是不能够有实例变量的。

// 在jdk1.8中为List接口新增的默认方法，函数方法sort前面的修饰符default能够知道一个方法是否为默认方法.
default void sort(Comparator<? super E> c) {
  Collections.sort(this, c);
}

null带来的种种问题，首先NullPointerException是目前java程序开发中最典型的异常。此外在代码中进行着空指针的检查会使得你的代码可读性糟糕透顶。null自身是没有任何的语义，尤其是它代表的是在静态语言类型中以一种错误的方式对缺失变量值得建模。其它语言对于null的处理。

在Groovy语言中通过引入安全导航操作符可以安全的访问可能为null的变量。其语法解释为当某个属性的值为null的时候，语法分析将不会再继续往后处理。person可能没有car的属性，在调用链中如果遭遇了null时将null引用沿着调用链传递下去，返回一个null的值。在spring El表达式中也存在于groovy类似的语法用于对对象的属性进行索引。 def carInsuranceName = person?.car?.insurance?.name;

// java中的spring El表达式其也采用了与groovy类似的语法用于获取对象的属性值.
String city = parser.parseExpression("PlaceOfBirth?.City").getValue(context, String.class);
System.out.println(city); // Smiljan

汲取Haskell和Scale的灵感，java 8中引入了一个新的类java.util.Optional<T>，有时候还可以通过此类判断当前jdk的版本(spring core中使用了这种方法)。这是一个封装Optional值得类。当变量存在的时候Optional类只是对类的简单封装。变量不存在的时候，缺失的值会进行自动建模成一个“空”的Optional对象，由方法Option.empty()返回。

应用Optional的几种模式：使用map从Optional对象中提取和转换值，map操作会将提供的函数应用于流中的每个元素，可以将Optional当做一个特殊的集合，它至多包含一个元素。如果是递归调用操作调用属性值的话，则不能使用map应该使用扁平化的数据流flatMap进行操作；

默认行为以及解引用Optional对象：get()是这些方法中最简单但又不安全的方法，如果变量存在则返回变量的值否则抛出NoSuchElementException的异常；orElse()操作允许你在Optional对象不存在的时候提供一个默认值；ifPresent(Consumer<? super T>)能让变量在存在的时候执行一个以参数传递进来的方法。

// 声明一个空的Optional,通过其静态方法创建一个空的Optional对象.
Optional<Car> optCar = Optional.empty();
// 依据一个非空值创建Optional，我们可以使用Optional.of依据一个非空值创建一个Optional对象.如果car的值为null的话则会立即抛出NullPointerException.
Optional<Car> optCar = Optional.of(car);
// 可接受null的Optional,可以使用ofNullable方法创建一个允许null值得Optional对象.
Optional<Car> optCar = Optional.ofNullable(car);
// 通过map方法获取得到Optional对象中的属性值.
Optional<Insurance> optInsurance = Optional.ofNullable(insurance);
Optional<String> name = optInsurance.map(Insurance::getName);
// 使用flatMap操作属性.属性的值.如果Optional的结果值为空设置默认值.
person.flatMap(Person::getCar).flatMap(Car::getInsurance)
	.map(Insurance::getName)
	.orElse("Unknown");

java8中新引入的CompletableFuture接口构建异步的应用，其弥补了之前Future接口在这些方面的不足：将两个异步计算合并为一个—这两个异步计算之间相互独立，同时第二个又依赖于第一个的结果。等待Future集合中的所有任务都完成。仅等待Future集合中最快结束的任务完成，并返回它们的结果。通过编程的方式完成一个Future任务的执行(即以手工设定异步操作结果的方式)。应对Future的完成事件(即当Future的完成事件发生时会收到通知，并使用Future计算的结果进行下一步的操作，不只是简单地阻塞等待结果)。

public Future<Double> getPriceAsync(String product) {
  CompletableFuture<Double> futurePrice = new CompletableFuture<>();
  new Thread(() -> {
  	double price = calculatePrice(product);
  	futurePrice.complete(price);
  }).start();
}
// 当在客户端调用该方法的时候回字节返回future结果,等其它操作结束之后可以调用future.get()获取计算的结果.如果价格未知，
// 则get方法会一直处于阻塞的状态直至方法调用结束.
double price = future.get();