IT瘾博客推荐

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

Sat, 08 Jul 2023 12:01:28 CST

Load 就是对计算机干活多少的度量，Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。

一、Load分析：

情况1：CPU高、Load高

通过top命令查找占用CPU最高的进程PID；
通过top -Hp PID查找占用CPU最高的线程TID;
对于java程序，使用jstack打印线程堆栈信息（可联系业务进行排查定位）；
通过 printf %x tid打印出最消耗CPU线程的十六进制；
在堆栈信息中查看该线程的堆栈信息；

情况2：CPU低、Load高

通过top命令查看CPU等待IO时间，即 %wa；
通过 iostat -d -x -m 1 10查看磁盘IO情况；(安装命令 yum install -y sysstat)
通过 sar -n DEV 1 10查看网络IO情况；
通过如下命令查找占用IO的程序；

      ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

二、CPU高、Load高情况分析

使用 vmstat查看系统纬度的 CPU 负载；
使用 top查看进程纬度的 CPU 负载；

2.1、使用 vmstat 查看系统纬度的 CPU 负载

可以通过 vmstat 从系统维度查看 CPU 资源的使用情况

格式： vmstat -n 1 -n 1表示结果一秒刷新一次

      [root@k8s-10 ~]# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1      0 2798000   2076 6375040    0    0    10    76   10   49  6  2 91  1  0
 0  0      0 2798232   2076 6375128    0    0     0   207 7965 12525  7  2 90  2  0

返回结果中的主要数据列说明：

r：表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程，所以，该数值越大，通常表示系统运行越慢。
b：表示阻塞的进程,这个不多说，进程阻塞，大家懂的。
us：用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy：系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
wa：IO 等待消耗的 CPU 时间百分比。该值较高时，说明 IO 等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
id：处于空闲状态的 CPU 时间百分比。如果该值持续为 0，同时 sy 是 us 的两倍，则通常说明系统则面临着 CPU 资源的短缺。

常见问题及解决方法：
如果r经常大于4，且id经常少于40，表示cpu的负荷很重。
如果pi，po长期不等于0，表示内存不足。
如果disk经常不等于0，且在b中的队列大于3，表示io性能不好。

2.1、使用 top 查看进程纬度的 CPU 负载

可以通过 top 从进程纬度来查看其 CPU、内存等资源的使用情况。

      [root@k8s-10 ~]# top -c
top - 19:53:49 up 2 days,  7:57,  3 users,  load average: 0.76, 0.79, 0.58
Tasks: 282 total,   2 running, 280 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.4 us,  1.4 sy,  0.0 ni, 95.0 id,  1.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12304204 total,  2800864 free,  3119064 used,  6384276 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  8164632 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29884 root      20   0 5346580 929332  14556 S   0.0  7.6   6:19.19 /opt/jdk1.8.0_144/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apach+
  875 root      20   0  729524 563424  38612 S   3.1  4.6  93:22.70 kube-apiserver --authorization-mode=Node,RBAC --service-node-port-range=80-60000 --advertise-address=10.68.7.162 --allow-privileged=true -+
 3870 nfsnobo+  20   0  910376 317248  22812 S   1.6  2.6  42:29.59 /bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/prometheus --storage.tsdb.retention=1d --web.enable-life+

默认界面上第三行会显示当前 CPU 资源的总体使用情况，下方会显示各个进程的资源占用情况。

可以直接在界面输入大小字母 P，来使监控结果按 CPU 使用率倒序排列，进而定位系统中占用 CPU 较高的进程。最后，根据系统日志和程序自身相关日志，对相应进程做进一步排查分析，以判断其占用过高 CPU 的原因。

2.2、strace命令分析

https://oa.kedacom.com/confluence/pages/viewpage.action?pageId=77136289

三、CPU低、Load高情况分析

问题描述：
Linux 系统没有业务程序运行，通过 top 观察，类似如下图所示，CPU 很空闲，但是 load average 却非常高：

处理办法：

load average 是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。
出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf查看是否存在 D 状态进程。
D 状态是指不可中断的睡眠状态。该状态的进程无法被 kill，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。

      等待I/O的进程通过处于uninterruptible sleep或D状态；通过给出这些信息我们就可以简单的查找出处在wait状态的进程
ps -eo state,pid,cmd | grep "^D"; echo "----"

- 查找占用IO的程序
ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

AI绘画能力的起源：通俗理解VAE、扩散模型DDPM、ViT/Swin transformer_v_JULY_v的博客-CSDN博客

Wed, 03 May 2023 07:52:37 CST

前言

2018年我写过一篇博客，叫：《一文读懂目标检测：R-CNN、Fast R-CNN、Faster R-CNN、YOLO、SSD》，该文相当于梳理了2019年之前CV领域的典型视觉模型，比如

2014 R-CNN
2015 Fast R-CNN、Faster R-CNN
2016 YOLO、SSD
2017 Mask R-CNN、YOLOv2
2018 YOLOv3

随着2019 CenterNet的发布，特别是2020发布的DETR(End-to-End Object Detection with Transformers)之后，自此CV迎来了生成式下的多模态时代

2020年
5月 DETR
6月 DDPM(即众人口中常说的扩散模型diffusion model)
10月 DDIM、Vision Transformer(简称ViT)
2021年
1月 CLIP、DALL·E
3月 Swin Transformer
11月 MAE、Swin Transformer V2
2022年
1月 BLIP
4月 DALL·E 2
8月 Stable Diffusion、BEiT-3、Midjourney V3
2023年
1月 BLIP2
3月 Visual ChatGPT、GPT-4、Midjourney V5
4月 SAM(Segment Anything Model)

但看这些模型接二连三的横空出世，都不用说最后爆火的GPT4，便可知不少CV同学被卷的不行

说到GPT4，便不得不提ChatGPT，实在是太火了，改变了很多行业，使得国内外绝大部分公司的产品、服务都值得用LLM全部升级一遍(比如微软的365 Copilot、阿里所有产品、金山WPS等等)

而GPT4相比GPT3.5或GPT3最本质的改进就是增加了多模态的能力，使得ChatGPT很快就能支持图片的输入形式，从而达到图生文和文生图的效果，而AI绘画随着去年stable diffusion和Midjourney的推出，使得文生图火爆异常，各种游戏的角色设计、网上店铺的商品/页面设计都用上了AI绘画这样的工具，更有不少朋友利用AI绘画取得了不少的创收，省时省力还能赚钱，真香

但面对这么香的技术，其背后的一系列原理到底是什么呢，本文特从头开始，不只是简单的讲一下扩散模型的原理，而是在反复研读相关论文之后，准备把20年起相关的CV多模态模型全部梳理一遍，从VE、VAE、DDPM到ViT/Swin transformer、CLIP/BLIP，再到stable diffusion/Midjourney、GPT4，当然，实际写的时候，会分成两篇甚至多篇文章，比如

第一篇，即本文《AI绘画能力的起源：通俗理解VAE、扩散模型DDPM、ViT/Swin transformer》
第二篇，即下篇《AIGC下的CV多模态原理解析：从CLIP/BLIP到stable diffusion/Midjourney、GPT4》

就当2020年之后的CV视觉发展史了

且过程中会尽可能写透彻每一个模型的原理，举个最简单的例子，网上介绍VAE的文章都太数学化(更怕那种表面正确其实关键的公式是错的误导人)，如果更边推导边分析背后的理论意义(怎么来的出发点是什么为什么要这么做这么做的意义是什么)，则会更好理解，这就跟变介绍原理边coding实现会更好理解、理解更深一个道理

第一部分编码器VE与变分自编码器VAE

1.1 AE：编码器(数据压缩为低维表示 )-解码器(低维表示恢复为原始数据 )架构

自编码器(Autoencoder，简称AE)是一种无监督学习的神经网络，用于学习输入数据的压缩表示。具体而言，可以将其分为两个部分：编码器和解码器

编码器：编码器是一个神经网络，负责将输入数据（如图像、文本等）压缩为一个低维表示，且表示为
解码器：解码器是另一个神经网络，负责将编码器生成的低维表示恢复为原始数据，且表示为

从而最终完成这么一个过程：，而其训练目标即是最小化输入数据与解码器重建数据之间的差异，所以自编码器常用的一个损失函数为

这个自编码的意义在于

模型训练结束后，我们就可以认为编码囊括了输入数据的大部分信息，也因此我们可以直接利用表达原始数据，从而达到数据降维的目的
解码器只需要输入某些低维向量，就能够输出高维的图片数据，那我们能否 把解码器模型直接当做生成模型，在低维空间中随机生成某些向量，再喂给解码器来生成图片呢？

对于第二点，理论上可以这么做，但问题在于

绝大多数随机生成的只会生成一些没有意义的噪声，之所以如此，原因在于没有显性的对的分布进行建模，我们并不知道哪些能够生成有用的图片
而且我们用来训练的数据是有限的，可能只会对极有限的有响应。而整个低维空间又是一个比较大的空间，如果只在这个空间上随机采样的话，我们自然不能指望总能恰好采样到能够生成有用的图片的

有问题自然便得探索对应的解决方案，而VAE(自变分编码器，Variational Autoencoders)则是在AE的基础上， 显性的对的分布进行建模(比如符合某种常见的概率分布) ，使得自编码器成为一个合格的生成模型

1.2 Variational AutoEncoder (VAE)

1.2.1 VAE：标数据的分布和目标分布尽量接近

VAE和GAN一样，都是从隐变量生成目标数据，具体而言，先用某种分布随机生成一组隐变量 (假设隐变量服从正态分布)，然后这个隐变量经过一个生成器生成一组数据，具体如下图所示(本1.2节的部分图来自苏建林)：

而VAE和GAN都希望这组生成数据的分布和目标分布尽量接近，看似美好，但有两个问题

一方面，“尽量接近”并没有一个确定的关于和的相似度的评判标准，比如KL散度便不行，原因在于KL散度是针对两个已知的概率分布求相似度的，而和的概率分布目前都是未知(只有一批采样数据没有分布表达式)
二方面，经过采样出来的每一个，不一定对应着每一个原来的，故最后没法直接最小化

实际是怎么做的呢，事实上，与自动编码器由编码器与解码器两部分构成相似，VAE利用两个神经网络建立两个概率密度分布模型：

一个用于原始输入数据的变分推断，生成隐变量的变分概率分布，称为推断网络
而VAE的核心就是，我们不仅假设 是正态分布，而且假设每个 也是正态分布。什么意思呢？即针对每个采样点获得一个专属于它和的一个正态分布

换言之，有个 sample，就有个正态分布，毕竟没有任何两个采样点是完全一致的，而后面要训练一个生成器，希望能够把从分布采样出来的一个还原为，而如果从中采样一个，没法知道这个对应于真实的呢？现在专属于，我们有理由说从这个分布采样出来的可以还原到对应的中去

而如何确定这个正态分布呢，众所周知，确定一个正太分布只需确定其均值和方差即可，故可通过已知的和假设的去确定均值和方差
具体可以构建两个神经网络，去计算。值得一提的是，选择拟合而不是直接拟合，是因为总是非负的，需要加激活函数处理，而拟合不需要加激活函数，因为它可正可负
另一个根据生成的隐变量的变分概率分布，还原生成原始数据的近似概率分布，称为生成网络
因为已经学到了这个正态分布，那可以直接从专属分布中采样一个出来，然后经过一个生成器得到，那接下来只需要最小化方差就行

仔细理解的时候有没有发现一个问题？为什么在文章最开头，我们强调了没法直接比较与的分布，而在这里，我们认为可以直接比较这俩？注意，这里的是专属于或针对于的隐变量，那么和本身就有对应关系，因此右边的蓝色方框内的“生成器”，是一一对应的生成。

另外，大家可以看到，均值和方差的计算本质上都是encoder。也就是说，VAE其实利用了两个encoder去分别学习均值和方差

1.2.2 VAE的Variational到底是个啥

这里还有一个 非常重要的问题：由于我们通过最小化来训练右边的生成器，最终模型会逐渐使得和趋于一致。但是注意，因为是重新随机采样过的，而不是直接通过均值和方差encoder学出来的，这个生成器的输入是有噪声的

仔细思考一下，这个噪声的大小其实就用方差来度量。为了使得分布的学习尽量接近，我们希望噪声越小越好，所以我们会尽量使得方差趋于 0
但是方差不能为 0，因为我们还想要给模型一些训练难度。如果方差为 0，模型永远只需要学习高斯分布的均值，这样就丢失了随机性，VAE就变成AE了…… 这就是为什么VAE要在AE前面加一个Variational：我们希望方差能够持续存在，从而带来噪声！
那如何解决这个问题呢？其实保证有方差就行，但是VAE给出了一个优雅的答案：不仅需要保证有方差，还要让所有趋于标准正态分布，根据定义可知

这个式子的关键意义在于告诉我吗：如果所有都趋于，那么我们可以保证也趋于，从而实现先验的假设，这样就形成了一个闭环！那怎么让所有趋于呢？还是老套路：加loss

到此为止，我们可以把VAE进一步画成：

现在我们来回顾一下VAE到底做了啥。VAE在AE的基础上

一方面，对均值的encoder添加高斯噪声(正态分布的随机采样)，使得decoder(即生成器)有噪声鲁棒性
二方面，为了防止噪声消失，将所有趋近于标准正态分布，将encoder的均值尽量降为 0，而将方差尽量保持住

这样一来，当decoder训练的不好的时候，整个体系就可以降低噪声；当decoder逐渐拟合的时候，就会增加噪声

第二部分扩散模型DDPM：Denoising Diffusion Probabilistic Models

在写本文之前，我反复看了网上很多阐述DDPM的文章，实话说，一开始看到那种一上来就一堆公式的，起初确实看不下去，虽然后来慢慢的都看得下去了，但如果对于一个初次接触DDPM的初学者来说，一上来一堆公式确实容易把人绕晕，但如果没有公式，则又没法透彻理解背后的算法步骤，两相权衡，本文将侧重算法每一步的剖析，而公式更多为解释算法原理而服务，说白了，侧重原理其次公式，毕竟原理透彻了，公式也就自然而然的能写出来了

2020年，UC Berkeley等人的Jonathan Ho等人通过论文《Denoising Diffusion Probabilistic Models》正式提出DDPM

扩散模型的灵感来自非平衡热力学，通过定义了一个扩散步骤的马尔可夫链，以缓慢地将随机噪声添加到数据中，然后学习反转扩散过程以从噪声中构建所需的数据样本

对于噪声的扩散，在数据当中，不断地加入具有高斯分布的噪声，最开始还具有原始图片的特征，但是随着噪声的不断加入，最后会变为一个纯噪声图片。

每一个噪声都是在前一时刻增加噪声而来的（马尔科夫过程），从最开始的时刻开始，最终得到时刻的纯噪声图像。不过问题来是为什么要加噪声？

Diffusion的本质是去噪，为了推导出逆向的去噪方法，必须了解增加噪声的原理。同时，添加噪声的过程其实就是不断构建标签的过程。如果在前一时刻可以预测出来后一时刻的噪声，很方便地可以实现还原操作(就和人走路一样，不管你从哪来，哪怕走过万水千山，最后都可按原路返回至原出发点)
且在噪声的添加过程中，每一步都要保持尽量相同的噪声扩散幅度。图片前期的分布非常均匀，添加一些噪声便可以将原始分布改变，但到后期，需要添加更多的噪声，方可保证噪声扩散幅度相同(这就像往水中加糖，为了使糖的甜味增长相同，后期需要加更多的糖)

所以DDPM的目标在于：作为一个生成式模型，其目标是从随机噪声直接生成图片，换言之，首先训练一个噪声估计模型，然后将输入随机噪声还原成图片)，相当于就两个关键，一个是训练过程，一个是推理过程

训练过程：随机生成噪声，经过步将噪声扩散到输入原始图片中，破坏后的图片，学习破坏图片的预估噪声，用L2 loss约束与原始输入噪声的距离
推理过程：即输入噪声，经过预估噪声模型还原成图片

2.1 DDPM的训练过程：先前向加噪后反向去噪从而建立噪声估计模型

2.1.1 前向过程(加噪)：通过高斯噪音随机加噪——给图片打马赛克

前向过程(forward process)也称为扩散过程(diffusion process)，简单理解就是对原始图片通过逐步添加「方差为的高斯噪声」变成，从而达到破坏图片的目的，如下图

在从到的过程中，其对应的分布是一个正太分布，且其均值是，方差为，则有

解释下这里的，原因在于我们一般处于多维情况下，而是单位矩阵，表明每个维度有相同的标准偏差

因为是马尔可夫链，所以联合分布就是：

如下图所示

如果我们定义 , 预先设定好一个超参数『被称为Noise schedule，通常是一些列很小的值』，以及是高斯噪声，便可以得到的采样值

这里值得注意下，即两个高斯分布相加仍为一个高斯分布, 新的分布均值为原先两个均值的和, 方差为原先两个方差的和，且把上述公式迭代变换下，可以直接得出到的公式，如下：

其中，这是随Noise schedule设定好的超参数，也是一个高斯噪声

换言之，所以在条件下的分布就是均值为 , 方差为的正态分布

考虑到可能会有读者对这个到的一步到位感到困惑，而一般的同类文章不会展开的特别细，故本文细致展开下(能拆10步则10步确保阅读无障碍)

我们从原始公式开始：

然后可以将替换为的表达式：

代入到的公式中：

继续展开，下一步是将替换为的表达式：

代入到的公式中：

然后继续展开，这次用的表达式替换：

代入到的公式中：

继续这个过程，直到用替换所有的中间变量

然后再把上述公式的后半部分的顺序调整一下，即得

每个时间步都会引入一个新的噪声项ε和一个新的混合系数a，为了简化这个表达式，我们引入累积混合系数
，即

在这个累积混合系数的帮助下，我们可以将的表达式简化下：

接下来，注意到
的系数是
的系数是
的系数是
观察这三项，可以发现：每个项的系数都可以表示为，其中从0到t-1。这是一个递归关系，我们可以使用它来合并所有的项
设，那么我们可以将写成：

可以将所有的项合并成一个项，因为它们都具有相同的递归关系，这意味着它们可以表示为，将这些项合并后，最终得到：

可能还是有读者对这最后一步的推导有疑惑，故我还是不厌其烦的耐心解释如下

由于每个的方差都等于 1，我们得到：

接下来，我们可以将的表达式改写为：

我们可以发现的方差与成比例，即：

为了使的方差等于 1，我们可以引入一个新的随机变量，其方差也等于 1，并将与的关系表示为：

最后，我们可以将的表达式简化为：

2.1.2 反向过程(去噪)：复原被加噪的图片——使之清晰化

反向过程就是通过估测噪声，多次迭代逐渐将被破坏的恢复成，如下图

相当于从到的变化过程，用公式表示为

这个公式所表达的含义在于，由于真实噪声在复原过程中不允许被使用，因此本步骤的关键就在于训练一个由和估测噪声的模型，其中就是模型本身需要训练的参数，也是一个高斯噪声且，用于估测与实际的差距，且在DDPM中，使用的是U-Net作为估测噪声的模型

好，问题又来了，上面这个公式又是如何一步步推导来的呢？

首先，通过上一节我们已经得到了

其中，和是在时间步和的数据，是一个独立的高斯噪声，是一个预先设定的系数
别忘了，在DDPM中，我们的目标是找到一个去噪函数用于在每个时间步去除噪声

我们现在需要对上述等式进行变换，以便得到关于和的表达式。首先，我们将上述等式除以，得到：

现在我们需要用去噪函数替换掉。在DDPM中，去噪函数的目标是从中恢复出噪声。因此，我们可以写：

将这个表达式带入上面的等式，我们得到：

最后，我们将等式左边的项移到右边，并将其写成的表达式：

这就是我们需要的表达式，它描述了如何从时间步的数据和去噪函数恢复出时间步的数据。在反向去噪过程中，我们将使用这个表达式逐步回溯到初始时间步，以生成新的样本

更具体而言，正向扩散和逆扩散过程都是马尔可夫，唯一的区别就是正向扩散里每一个条件概率的高斯分布的均值和方差都是已经确定的（依赖于和），而逆扩散过程里面的均值和方差需要通过网络学出来

怎么个学法呢？如果我们能够逆转前向过程并从采样，就可以从高斯噪声还原出原图分布。可证明如果满足高斯分布且足够小，仍然是一个高斯分布。然现在的问题是，我们无法直接去推断，好在我们可以使用「参数为 θ 的U-Net+attention 结构」去预测这样的一个逆向的分布（类似 VAE）：

不过在DDPM的论文中，作者把条件概率的方差直接取了，而不是上面说的需要网络去估计的，所以说实际上只有均值需要网络去估计。虽然我们无法得到逆转过程的概率分布，但是如果知道就可以直接写出

故有：

解释下上面7.1~7.5这5个步骤的推导

7.1依据的是

7.2中，分母部分依据的是

分子部分依据的是

7.3依据的是分子分母同时除以

7.4依据的是

和
是一个正太分布，且其均值是，方差为，且

至于7.5
首先考虑，可以整理为，则其均值为，方差为，从而有

根据，可知，代入上式可得
相当于在给定的条件下，后验条件高斯分布的均值只和超参数、、有关，方差只与超参数有关，从而通过以上的方差和均值，我们就得到了的解析形式

2.1.3 如何训练：建立噪声估计模型 ——最小化估计噪声与真实噪声之间的差距

接下来介绍这个模型要怎么优化，即网络该怎么训练去估计条件概率的均值和方差

我们要最小化目标分布的负对数似然：

令

所以就是我们的上界，我们要最小化它，接着进行变形

对于上面公式最后得到的结果

首先，是和优化无关的(由于前向过程 q 没有可学习参数，而则是纯高斯噪声，因此 LT 可以当做常量忽略)，所以不用管，只用看右边的
然后，是KL散度，则可以看做拉近 2 个分布的距离：
第一个分布我们已经在上一节推导出其解析形式，这是一个高斯分布，其均值和方差为

第二个分布是我们网络期望拟合的目标分布，也是一个高斯分布，均值用网络估计，方差被设置为了一个和有关的常数

如果有两个分布 p,q 都是高斯分布，则他们的KL散度为

然后因为这两个分布的方差全是常数，和优化无关，所以其实优化目标就是两个分布均值的二范数
这个时候我们可以直接整个网络出来直接预测，且会尽可能去预测，因为是的输入的，其它的量都是常熟，所以其中的未知量其实只有，所以我们干脆把定义成：

也就是说，不用网络直接预测，而是用网络先预测噪声，然后把预测出来的噪声带入到定义好的表达式中去计算出预测的均值，其实是一样的
所以，最终把这个公式，带入到上一公式中得到：

经过这样一番推导之后就是个 L2 loss。网络的输入是一张和噪声线性组合的图片，然后要估计出来这个噪声：

由上可知，DDPM的关键是训练模型，使其预测的与真实用于破坏的相近，用L2距离刻画相近程度就好，因此我们的Loss就是如下公式

而整个训练过程可如下图描述

DDPM论文中对应的伪代码为

相当于训练时，网络输入为 (由和噪声线性组合而成) 和时刻，输出要尽可能的拟合输入的噪声 (通过L2 loss约束)：

2.2 通过训练好的DDPM生成图片

在得到噪声估测模型后，想要生成模型就很简单了。从N(0,1)中随机生成一个噪声作为，然后再用该模型逐步从估测噪声，并用去噪公式逐渐恢复到即可，见如下伪代码

相当于推理时，我们从各项独立的高斯分布开始，一共步，每一步其实都是用了一次reparameterization trick。

每一步具体来说，我们有了，想要得到，因为我们之前逆扩散过程建模有：

所以由reparameterization trick我们有：

每一轮都这样迭代，最终就得到了生成的图片

//又不一小心把本文发布出去了，本来一直在草稿里要修改个把星期的，一方面下文还有很多内容需要更新，二方面上文还有很多细节有待补充完善比如一些公式的拆解，待更..

参考文献与推荐阅读

变分自编码器（一）：原来是这么一回事
..
关于VAE的几篇文章：一文理解变分自编码器（VAE）、机器学习方法—优雅的模型（一）：变分自编码器（VAE）、
苏剑林关于扩散模型的几篇文章：（一）：DDPM = 拆楼 + 建楼、（二）：DDPM = 自回归式VAE
怎么理解今年 CV 比较火的扩散模型（DDPM）？
知乎上关于扩散模型的几篇文章：全网最简单的扩散模型DDPM教程、 Diffusion扩散模型大白话讲解、扩散生成模型: 唯美联姻物理概念与机器学习
Understanding Diffusion Models: A Unified Perspective(另，这是其 PDF版本)
扩散模型是如何工作的：从0开始的数学原理
What are Diffusion Models?
Introduction to Diffusion Models for Machine Learning
关于扩散模型的几篇论文
CVPR 2022 Tutorial: Denoising Diffusion-based Generative Modeling: Foundations and Applications
Diffusion Models Beat GANs on Image Synthesis
关于DDPM的几篇文章： DDPM概率扩散模型（原理+代码)、 Denoising Diffusion Probabilistic Models (DDPM)、从VAE到DDPM、扩散模型原理解析

Linux 下如何查找木马并处理 - ericyuan - 博客园

Thu, 13 Apr 2023 22:41:24 CST

1、cat /etc/passwd 未发现陌生用户和可疑root权限用户。

2、netstat -anp 查看所有进程及pid号，未发现异常连接。

3、last 查看最近登录用户，未发现异常

4、cat /etc/profile 查看系统环境变量，未发现异常

5、ls -al /etc/rc.d/rc3.d ，查看当前级别下开机启动程序，未见异常（有一些脸生，只好利用搜索引擎了）

6、crontab -l 检查计划任务，root用户和web运行用户各检查一遍，未见任何异常

7、cat /root/.bashrc 和 cat /home/用户/.bashrc 查看各用户变量，未发现异常

8、查看系统日志。主要是/var/log/messages(进程日志)、/var/log/wtmp(系统登录成功日志 who /var/log/wtmp)、/var/log//bmtp(系统登录失败日志)、/var/log/pureftpd.log(pureftpd的连接日志)，未发现异常（考虑到了可能的日志擦除，重点看了日志的连续性，未发现明显的空白时间段）

9、history 查看命令历史。cat /home/用户/.bash_history 查看各用户命令记录，未发现异常

10、系统的查完了，就开始查web的。初步查看各站点修改时间，继而查看各站点的access.log和error.log（具体路径不发了），未发现报告时间前后有异常访问。虽有大量攻击尝试，未发现成功。

11、日志分析完毕，查找可能存在的webshell。方法有两个，其一在服务器上手动查找；其二，将web程序下载到本地使用webshellscanner或者web杀毒等软件进行查杀。考虑到站点较多，数据量大，按第一种方法来。在linux上查找webshell基本两个思路：修改时间和特征码查找。特征码例子：find 目录 -name "*.php"（asp、aspx或jsp） |xargs grep "POST[（特征码部分自己添加）" |more 修改时间：查看最新3天内修改的文件，find 目录 -mtime 0 -o -mtime 1 -o -mtime 2 当然也可以将两者结合在一起，find 目录 -mtime 0 -o -mtime 1 -o -mtime 2 -name "*.php" 的确查找到了一些停用的站点下有webshell

--------

查找全站关键字：“pack”、“eval”

服务端性能优化--最大QPS推算及验证 - huangyingsheng - 博客园

Mon, 12 Dec 2022 15:48:36 CST

服务端性能优化--最大QPS推算及验证

影响QPS（即吞吐量）的因素有哪些？每个开发都有自己看法，一直以为众说纷纭，例如：

QPS受编程语言的影响。（PHP是最好的语言？）
QPS主要受编程模型的影响，比如不是coroutine、是不是NIO、有没有阻塞？
QPS主要由业务逻辑决定，业务逻辑越复杂，QPS越低。
QPS受数据结构和算法的影响。
QPS受线程数的影响。
QPS受系统瓶颈的影响。
QPS和RT关系非常紧密。
more...

嗯，这些说法好像都对，但是好像又有点不对，好像总是不太完整，有没有一个系统点的说法能让人感觉一听就豁然开朗？
今天我们就这个话题来阐述一下，将一些现有的理论作为依据，把上方这些看起来比较零碎的看法总结归纳起来，希望能为服务端的性能提升进行一点优化，这也是一个优化的起点，未来才有可能做更多的优化，例如TCP、DNS、CDN、系统监控、多级缓存、多机房部署等等优化的手段。

好了，废话不多说，直接开聊。

我们经常再做优化的时候，例如电商的促销秒杀等活动页，一开始可能会认为说Gzip并不是影响CPU的最大因子，直到拿出一次又一次的实验数据，研发们才开始慢慢接受（尬不尬），这是为什么？难道说Gzip真的是影响CPU的最大因子吗？那我们就拿出一点数据来验证一下对吧，接下来我们从RT着手开始慢慢了解，看到文章结尾就知道为什么Gzip和CPU的关系，同事也会发现，性能优化的相关知识其实也是体系化的，并不是分散零碎的。

RT

什么是 RT ？是概念还是名词还是理论？

RT其实也没那么玄乎，就是 Response Time （就是响应时间嘛，哈哈哈），只不过看你目前在什么场景下，也许你是c端（app、pc等）的用户，响应时间是你请求服务器到服务器响应你的时间间隔，对于我们后端优化来说，就是接受到请求到响应用户的时间间隔。这听起来怎么感觉这不是在说废话吗？这说的不都是服务端的处理时间吗？不同在哪里？其实这里有个容易被忽略的因素，叫做网络开销。
所以服务端RT ≈ 网络开销 + 客户端RT。也就是说，一个差的网络环境会导致两个RT差距的悬殊（比如，从深圳访问上海的请求RT，远大于上海本地内的请求RT）

客户端的RT则会直接影响客户体验，要降低客户端RT，提升用户的体验，必须考虑两点，第一点是服务端的RT，第二点是网络。对于网络来说常见的有CDN、AND、专线等等，分别适用于不同的场景，有机会写个blog聊一下这个话题。

对于服务端RT来说，主要看服务端的做法。
有个公式：RT = Thread CPU Time + Thread Wait Time
从公式中可以看出，要想降低RT，就要降低 Thread CPU Time 或者 Thread Wait Time。这也是马上要重点深挖的一个知识点。

Thread CPU Time（简称CPU Time）

Thread Wait Time（简称Wait Time）

单线程QPS

我们都知道 RT 是由两部分组成 CPU Time + Wait Time 。那如果系统里只有一个线程或者一个进程并且进程中只有一个线程的时候，那么最大的 QPS 是多少呢？
假设 RT 是 199ms （CPU Time 为 19ms ，Wait Time 是 180ms ），那么 1000s以内系统可以接收的最大请求就是
1000ms/(19ms+180ms)≈5.025。

所以得出单线程的QPS公式：

\[单线程QPS = 1000ms/RT \]

最佳线程数

还是上面的那个话题（CPU Time 为 19ms ，Wait Time 是 180ms ），假设CPU的核数1。假设只有一个线程，这个线程在执行某个请求的时候，CPU真正花在该线程上的时间就是CPU Time，可以看做19ms，那么在整个RT的生命周期中，还有 180ms 的 Wait Time，CPU在做什么呢？抛开系统层面的问题（这里不考虑什么时间片轮循、上下文切换等等），可以认为CPU在这180ms里没做什么，至少对于当前的业务来说，确实没做什么。

一核的情况
由于每个请求的接收，CPU只需要工作19ms，所以在180ms的时间内，可以认为系统还可以额外接收180ms/19ms≈9个的请求。由于在同步模型中，一个请求需要一个线程来处理，因此，我们需要额外的9个线程来处理这些请求。这样，总的线程数就是：

\[（180ms + 19ms）/19ms ≈ 10个 \]

多线程之后，CPU Time从19ms变成了20ms，这1ms的差值代表多线程之后上下文切换、GC带来的额外开销（对于我们java来说是jvm，其他语言另外计算），这里的1ms只是代表一个概述，你也可以把它看做n。

两核的情况
一核的情况下可以有10个线程，那么两核呢？在理想的情况下，可以认为最佳线程数为：2 x ( 180ms + 20ms )/20ms = 20个
CPU利用率
我们之前说的都是CPU满载下的情况，有时候由于某个瓶颈，导致CPU不得不有效利用，比如两核的CPU，因为某个资源，只能各自使用一半的能效，这样总的CPU利用率就变成了50%，再这样的情况下，最佳线程数应该是：50% x 2 x( 180ms + 20ms )/20ms = 10个
这个等式转换成公式就是：最佳线程数 = (RT/CPU Time) x CPU 核数 x CPU利用率
当然，这不是随便推测的，在收集到的很多的一些著作或者论坛的文档里都有这样的一些实验去论述这个公式或者这个说法是正确的。

最大QPS

1.最大QPS公式推导

假设我们知道了最佳线程数，同时我们还知道每个线程的QPS，那么线程数乘以每个线程的QPS既这台机器在最佳线程数下的QPS。所以我们可以得到下图的推算。

我们可以把分子和分母去约数，如下图。

于是简化后的公式如下图.

从公式可以看出，决定QPS的时CPU Time、CPU核数和CPU利用率。CPU核数是由硬件做决定的，很难操纵，但是CPU Time和CPU利用率与我们的代码息息相关。

虽然宏观上是正确的，但是推算的过程中还是有一点小小的不完美，因为多线程下的CPU Time（比如高并发下的GC次数增加消耗更多的CPU Time、线程上下文切换等等）和单线程的CPU Time是不一样的，所以会导致推算出来的结果有误差。

尤其是在同步模型下的相同业务逻辑中，单线程时的CPU Time肯定会比大量多线程的CPU Time小，但是对于异步模型来说，切换的开销会变得小很多，为什么？这里先卖个葫芦吧，看完本篇就知道了。

既然决定QPS的是CPU Time和CPU核数，那么这两个因子又是由谁来决定的呢？（越看越懵哈）

2.CPU Time

终于讲到了 CPU Time，CPU Time不只是业务逻辑所消耗的CPU时间，而是一次请求中所有环节上消耗的CPU时间之和。比如在web应用中，一个请求过来的HTTP的解析所消耗的CPU时间，是CPU Time的一部分。另外，这个请求中请求RPC的encode和decode所消耗的CPU时间也是CPU Time的一部分。

那么CPU Time是由哪些因素决定的呢？两个关键字：数据结构+算法。
举一些例子吧

均摊问题
hash问题
排序和查找问题
状态机问题
序列化问题

3.CPU利用率

CPU利用率不高的情况时常发生，一下因素都会影响CPU的利用率，从而影响系统可以支持的最大QPS。

1) IO能力

磁盘IO
网络IO
·带宽，比如某大促压力测试时，由于某个应用放在Tair中的数据量大，导致Tair的机器网卡跑满。
·网路链路，还是这次大促，借用了其他核心交换机下的机器，导致客户端RT明显增加。

2) 数据库连接池（并发能力=PoolWaitTime/RT(Client) x PoolSize）。

3) 内存不足，GC大量占用CPU，导致给业务逻辑使用的CPU利用率下降，而且GC时还满足Amdahl定律锁定义的场景。

4) 共享资源的竞争，比如各种锁策略(读写锁、锁分离等)，各种阻塞队列，等等。

5) 所依赖的其他后端服务QPS低造成的瓶颈。

6) 线程数或者进程数，甚至编程模型(同步模型，异步模型)。

在压力测试过程中，出现最多的就是网络IO层面的问题，GC大量占用CPU Time之类的问题也经常出现。

4.CPU核数，Amdahl定律，Gustafson定律

1)Amdahl定律(安达尔定律，不是达尔文定律！！！)

Amdahl定律是用来描述可伸缩性的，什么是可伸缩性？说白了就是比如增加计算机资源，如CPU、内存、宽带等，QPS能够相应的进行改进。

既然Amdahl定律是描述可伸缩性的，那它是如何描述的呢？

Amdahl在自己的论文中指出，可伸缩性是指在一个系统中，基于可并行化和串行化的组件各自所占的比例，当程序获得额外的计算资源(如CPU或者内存等)时，系统理论上能够获得的加速值(QPS或者其他指标可以翻几倍)。用一个公式来表达，如果F表示必须串行化执行的比例，那么在一个N核处理器的机器中，加速：

\[Speedup \leq \frac{1}{F+\frac{1-F}{N}} \]

这个公式代表的意义是比较广泛的，在项目管理中也有一句类似的话：

一个女人生一个孩子要9个月，但是永远不可能让9个女人在一个月内就生一个孩子。
我们根据这个例子套一个公式先，这里设F=100%，9个女人表示N=9，于是就有1/(100%+(1-100%)/9)=1，所以9个女人的加速比为1，等于没有加速。

到这里，其实这个公式还只是描述了在增加资源的情况下系统的加速比，而不是在资源不变的情况下优化数据结构和算法之后带来的提升。优化数据结构和算法带来的提升要看前文中最大的QPS公式。不过这两个公式也不是完全没有联系的，在增加资源的情况下，它们的联系还是比较紧密的。

2) Gustafson定律（古斯塔夫森定律）

这个定律名字有点长，但这不是关键，关键的是，它是Amdahl定律的补充，公式为：

\[S(P) = P-α·(P-1) \]

P是处理器的个数，α是串行时间占总执行时间的比例。
生孩子的案例再次套上这个公式，P为女人的个数，等于9，串行比例是100%。Speedup=9-100%x(9-1)=1，也就是9个女人是无法在一个月内把孩子生出来的……

之所以说是Amdahl定律的补充，是因为两个定律的关系是相辅相成的关系。前者从串行和并行执行时间的角度来推导，后者从串行和并行的计算量角度来推导，不管是哪个角度，最终的结果其实是一样的。

3)CPU核数和Amdahl定律的关系

通过最大QPS公式，我们发现，在CPU Time和CPU利用率不变的情况下，核数越多，QPS就越大。比如核数从1到4，在CPU Time和CPU利用率不变的情况下，加速比应该是4，所以QPS应该也是增加4倍。

这是资源增加（CPU核数增加）的情况下的加速比，也可以通过Amdahl定律来衡量，考虑串行和并行的比例在增加资源的情况下是否会改变。也就是要考虑在N增加的情况下，F受哪些因素的影响：

\[Speedup \leq \frac{1}{F+\frac{1-F}{N}} \]

只要F大于0，最大QPS就不会翻4倍。

一个公式说要增加4被倍，一个定理说没有4倍，互相矛盾？

其实事情是这样的，通过最大QPS公式，我们可以发现，如果CPU Time和CPU 利用率不变，核数从1增加到4，QPS会相应的增加4倍。但是在实际情况下，当核数增加时，CPU Time和CPU 利用率大部分时候是变化的，所以前面的假设不成立，即一般场景下QPS不能增加4倍。

而Amdahl定律中的N变化时，F也可能会变化，即一般场景下，最大QPS并不能增加4被，所以这其实并不矛盾。相反它们是相辅相成的。这里一定要注意，这里说的是一般场景，如果你的场景完全没有串行（程序没有串行，系统没有串行，上下文切换没有串行，什么串行都没有），那么理论上是可以增加4倍的。

为什么增加计算机资源时，最大QPS公式中的CPU Time和CPU利用率会变化，F也会变化呢？我们可以从宏观上分析一下，增加计算机资源时，达到满载:

QPS会更高，单位时间内产生的对象会更多。在同等条件下，minor GC被触发的次数增加，还有些场景发生过对象多到响应没返回它们就进了“老年代”，从而fullGC被触发。宏观上，这是属于串行的部分，对于Amdahl公式来说F会受到影响，对于最大QPS公式来说，CPU Time和CPU利用率也受到影响.
在同步模型下大量的线程在完成一次请求中，上下文被切换的次数大大增加。
尤其是在有串行模块的时候，串行的执行和等待时间增加，F会变化，某些场景下CPU
利用率也达不到理想效果，这取决于你的代码。这也是要做锁分离、为什么要缩小同步
块的原因。当然还有锁自身的优化，比如偏向、自旋、读写分离等技术，都是为了不断
地减少Amdahl定律中的F，也是为了减少CPU Time ( 锁本身的优化)，提高CPU利
用率(使用锁的方法的优化)。

。锁本身的优化最为津津乐道的是自旋、偏向、自适应，synchronized分析，还有reetrantLock的代码及AQS等等。

。使用锁的优化方法最常见的是缩小锁区间、锁分离、无锁化、volatile。

所以在增加计算资源时，更高的并发产生，会引起最大QPS公式中两个参数的变化，也会
引起Amdahl定律中F值的变化，同时公式和定律变化的趋势是相同的。Amdahl定律是得到广
泛认可的，也是得到数据验证的。最大QPS公式好像没有人验证过，这里引用一个比较有名的
测试结果，如下图.

当计算资源(处理器数量)增加时，在串行部分比例不变的情况下，CPU利用率下降。
当计算资源(处理器数量)增加时，串行占的比例越大，CPU利用率下降得越多。

实验数据验证公式

所以其实到现在我们一直在说理论，带了一点点的公式，听起来好像是那么回事，但是公式到底怎么用？准不准确？可以精准测试还是概要测试即可？

我们接下来实验一下吧。

!!! 接下来会涉及到CPU Time 包含了操作系统对CPU的消耗，比如进程，线程调度等。

1.数据准备

这里就用之前的一个电商活动页面的优化来说吧，在这个过程中，我们做了大量测试，由于测试中使用了localhost方式，所以Java进程在IO上的Wait Time是非常小的。接下来，由于最佳线程数接近CPU核数,
所以在两核的机器上使用了10个Java进程，客户端发起了10个并发请求,这是在最佳线程数下(最佳线程数在一个区间里，在这个区间里QPS总体变化不大,并且也用了5、15个并发测试效果，发现QPS值基本相同)得出的大量结果，接下来就分析一下这些测试结果，见下表。

1)测试QPS结果

原始页面大小	压缩后的大小	优化前QPS	优化后QPS	优化前RT	优化后RT
92kb	17kb	164	2024	60.7ms	4.9ms
138kb	8.7kb	143	1859	69.8ms	3.3ms
182kb	11.4kb	121	2083	82.3ms	4.8ms
248kb	32kb	77	1977	129.6ms	5.0ms
295kb	34.4kb	70	1722	141.1ms	5.8ms

我们其实只要关注各项优化前后的QPS变化即可。

2） CPU利用率

由于Apache Bench和Java部署在同一台机器.上，所以CPU利用率应该减去Apache Bench
的CPU资源消耗。根据观察，优化前Apache Bench 的CPU消耗在1.7%到2%之间，优化后
Apache Bench 的CPU资源消耗在20%左右。为什么优化前后有这么大的差距呢?因为优化后
响应能够及时返回，所以导致Apache Bench使用的CPU资源多了。

在接下来的计算中，我们将优化前的CPU利用率设置为98%，优化后的CPU利用率设置为80%。

3）CPU Time 计算公式

根据QPS的计算方法，把QPS挪到右边的分母中，CPU Time移到等号左边，就会得到下图的公式。

4) CPU Time计算示例

根据上方列出的三点（CPU利用率、QPS和CPU核数），接下里我们就详细的描述一下推算方法了。

计算得到的CPU Time

根据上方的表格计算方法，利用QPS计算出各页面理论上的CPU Time，计算后的结果如下表：

原始页面92kb	计算公式
优化前CPU Time计算	1000 / 164 x 2 x 0.98 = 12ms
优化后CPU Time计算	1000 / 2024 x 2 x 0.8 = 0.8ms

原始页面大小	压缩后的大小	优化前QPS	优化后QPS	优化前CPU Time	优化后CPU Time
92kb	17kb	164	2024	12ms	0.8ms
138kb	8.7kb	143	1859	13.7ms	0.86ms
182kb	11.4kb	121	2083	16.2ms	0.77ms
248kb	32kb	77	1977	25.5ms	0.81ms
295kb	34.4kb	70	1722	28ms	0.93ms

这里主要看一下各项的CPU Time优化前后的变化，接下来，我们把两个值做减法，然后和开篇中提到过的实测程序中Gzip的CPU Time进行对比。

实测CPU Time

1） 5个页面的Gzip所消耗的CPU Time

实测5个页面做Gzip所消耗的时间，然后跟公式计算出来的CPU Time做一个对比，如下表：

原始页面大小	CPU Time公式差值(上表的CPU Time差值)	Gzip CPU Time测量值(10次平均值)	差值
92kb	11.2ms	8ms	3.2ms
138kb	12.8ms	7ms	5.8ms
182kb	15.4ms	9ms	6.4ms
248kb	24.7ms	21ms	3.0ms
295kb	27.1ms	23ms	4.1ms

可以看到，计算出来的CPU Time值要比测出来的要多一点，多了几毫秒，这是为什么呢?

其实是因为在优化前，有两个消耗CPU Time的阶段，一个是执行Java代码时，另一个是执行Gzip时。而优化后，整个逻辑变成了从缓存获取数据后直接返回，只有非常少的Java代码在消耗CPU Time(10行以内)。

2） Java页面执行消耗的CPU Time

大体上可以认为：

优化前的CPU Time - 优化后的CPU Time = Gzip CPU Time + 全页面Java代码的CPU Time

在实验中，一开始只统计了 Gzip 本身的消耗，而在 Java 文件中 Java代码执行的时间并没有包含在内，所以两者差距比较大。于是，我们单独统计了5个页面的Java代码的执行时间，发现文件中Java码执行的时间为3~6ms。实际测量的Gzip CPU Time 加上3~6ms的Java代码执行时间，和使用公式计算出来的CPUTime基本吻合。

根据上面的计算和测量结果，我们发现 Gzip 的 CPU Time消耗加上Java代码的CPU Time消耗，与公式测量出来的总的CPU Time消耗非常接近，误差为1~2ms。考虑到CPU Time测量是单线程测量，而压力测试QPS是并发情况下(会多出进程切换的开销和GC等的开销)，我们认为这点误差是合理的，测试结果说明公式在宏观上是正确的。

压力测试最佳线程数和QPS临界点

前面讲到了公式的推导，并在一个固定的条件下验证了公式在该场景下的正确性。

假设在一个thread-per-client的场景，有一一个Ajax请求，这个请求返回一个Json字符串，每个请求的CPU Time为1ms，WaitTime为300ms(比如读写Socket和线程调度的等待开销)。那么最佳线程数是

\[(300+1/1 )x4x 100%=1204 \]

尤其在广域网上，Wait Time=300ms是正常的数值。在国际环境下，300ms就更加常见了。这意味着如果是4核的机器，需要1204个线程，如果是8核的机器则需要2408个线程。实际上，有些HTTP服务的CPU Time是远小于1ms的，比如上面的场景中将页面压缩并缓存起来之后,CPU Time基本为0.8ms,如果WaitTime还是300ms,那么需要数以千计的线程啊!当线程数不断增加的时候，到达某个临界点之后对系统就开始产生负面影响了。

(1) 大量线程上下文切换的开销，引起CPU Time的增加及QPS的减少。所以，有时候还没有达到最佳线程数，而QPS已经开始略微下降了。因为CPU Time发生变化、线程多了之后，调度引起的CPU Time提升的百分比和QPS下降的百分比成正比(上方的QPS公式)，上下文切换带来的开销如下。

上下文切换(微妙级别)
JVM本身的开销
CPU Cache加载

(2)线程的栈空间会占用大量的内存，假设每个线程的栈空间是1MB，这么多的线程就要占用数GB的内存。

(3)在CPU Time不变的情况下，因为线程上下文切换和操作系统想尽力为线程在宏观上平均分配时间片的行为，导致每个线程的Wait Time都增加了，于是每个请求的RT也增加了，最终就会产生用户体验下降的情况。

可以用一张图来表示一下临界点的概念。

由于线程数增加超过某个临界点会影响CPU Time、QPS和RT，所以很难精确测量高并发下的CPU Time,它随着机器硬件、操作系统、线程数等因素不断变化。我们能做的就是压力测试QPS，并在压力测试的过程中调整线程数，使QPS达到临界点，这个临界点是QPS的一个峰值点。这个峰值点的线程数即当前系统的最佳线程数，当然如果这个时候CPU利用率没有达到100%，那么证明系统中可能存在瓶颈，应该在找到并处理瓶颈之后继续压力测试，并且重新找到这个临界点。

当数据结构发生改变、算法改进或者业务逻辑发生改变时，最佳线程数有可能会跟着变化。

总结：

这篇 blog的例子中，在CPU Time下降到1ms左右而Wait Time需要数百毫秒的场景下，我们需要很多线程。但是当达到这个线程数的时候，有可能早就达到了临界点。所以系统整体已经不是最健康的状态了，但是现有的编程模型已经阻碍了我们前进，那么应该怎么办呢?为使某个系统达到最优状态?

所以下一篇blog我们来说一下编程中的同步模型和异步模型问题，以及为什么异步模型只需要这么少的线程，是不是公式在异步模型下失效了。

我的个人站点
SUMMER https://www.huangyingsheng.com/about

Linux丢包故障的解决与思路 - Albert的博客 | Albert's Blog

Thu, 27 Oct 2022 14:43:39 CST

Linux丢包故障的解决与思路

前言

本文为大部分内容是转载: 原文地址，和之前一样，在原文的基础上进行了一些格式的调整，包括一些错别字的修正，以及进行了一些博文链接的插入，以便于读者或者我自己更好的理解。

我们使用 Linux作为服务器操作系统时，为了达到高并发处理能力，充分利用机器性能，经常会进行一些内核参数的调整优化，但不合理的调整常常也会引起意想不到的其他问题，本文就一次 Linux服务器丢包故障的处理过程，结合 Linux内核参数说明和 TCP/IP协议栈相关的理论，介绍一些常见的丢包故障定位方法和解决思路。

在开始之前，我们先用一张图解释 linux 系统接收网络报文的过程。

首先网络报文通过物理网线发送到网卡

网络驱动程序会把网络中的报文读出来放到 ring buffer 中，这个过程使用 DMA（Direct Memory Access），这个过程不需要 CPU 参与

内核从 ring buffer 中读取报文进行处理，执行 IP 和 TCP/UDP 层的逻辑，最后把报文放到应用程序的 socket buffer 中

应用程序从 socket buffer 中读取报文进行处理

在接收 UDP 报文的过程中，图中任何一个过程都可能会主动或者被动地把报文丢弃，因此丢包可能发生在网卡和驱动，也可能发生在系统和应用。之所以没有分析发送数据流程，一是因为发送流程和接收类似，只是方向相反；另外发送流程报文丢失的概率比接收小，只有在应用程序发送的报文速率大于内核和网卡处理速率时才会发生。本篇文章假定机器只有一个名字为 eth0 的 interface，如果有多个 interface 或者 interface 的名字不是 eth0，请按照实际情况进行分析。

NOTE：文中出现的 RX（receive）表示接收报文，TX（transmit）表示发送报文。

一、问题现象

本次故障的反馈现象是：从办公网访问公网服务器不稳定，服务器某些端口访问经常超时，但 Ping测试显示客户端与服务器的链路始终是稳定低延迟的。通过在服务器端抓包，发现还有几个特点：

从办公网访问服务器有多个客户端，是同一个出口IP，有少部分是始终能够稳定连接的，另一部分间歇访问超时或延迟很高

同一时刻的访问，无论哪个客户端的数据包先到达，服务端会及时处理部分客户端的SYN请求，对另一部分客户端的SYN包“视而不见”，如tcpdump数据所示，源端口为56909的SYN请求没有得到响应，同一时间源端口为50212的另一客户端SYN请求马上得到响应。

          $ sudo tcpdump -i eth0 port 22 and "tcp[tcpflags] & (tcp-syn) != 0"
18:56:37.404603 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321481 ecr 0,nop,wscale 7], length 0
18:56:38.404582 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321731 ecr 0,nop,wscale 7], length 0
18:56:40.407289 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198322232 ecr 0,nop,wscale 7], length 0
18:56:44.416108 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198323234 ecr 0,nop,wscale 7], length 0
18:56:45.100033 IP CLIENT.50212 > SERVER.22: Flags [S], seq 4207350463, win 65535, options [mss 1366,nop,wscale 5,nop,nop,TS val 821068631 ecr 0,sackOK,eol], length 0
18:56:45.100110 IP SERVER.22 > CLIENT.50212: Flags [S.], seq 1281140899, ack 4207350464, win 27960, options [mss 1410,sackOK,TS val 1709997543 ecr 821068631,nop,wscale 7], length 0
18:56:52.439086 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198325240 ecr 0,nop,wscale 7], length 0
18:57:08.472825 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198329248 ecr 0,nop,wscale 7], length 0
18:57:40.535621 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198337264 ecr 0,nop,wscale 7], length 0
18:57:40.535698 IP SERVER.22 > CLIENT.56909: Flags [S.], seq 3621462255, ack 1190606851, win 27960, options [mss 1410,sackOK,TS val 1710011402ecr 198337264,nop,wscale 7], length 0

如果能排除网卡或者驱动丢包可能的话， linux系统丢包的原因相对就很多，常见的有： UDP报文错误、防火墙、 UDP buffer size不足、系统负载过高等，这里对这些丢包原因进行分析。

二、名词解释

          # ifconfig em2
em2       Link encap:Ethernet  HWaddr AC::3D:A9::0D
          inet addr:211.211.211.211  Bcast:211.211.211.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:  Metric:
          RX packets: errors: dropped: overruns: frame:
          TX packets: errors: dropped: overruns: carrier:
          collisions: txqueuelen:
          RX bytes: ( (1.3 TiB)
          Memory:94b00000-94b20000

RX errors: 表示总的收包的错误数量，这包括 too-long-frames 错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
RX dropped: 表示数据包已经进入了 Ring Buffer，但是由于 内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一，上面那台有问题的机器就是因为 interruprs分布的不均匀(都压在 core0)，没有做 affinity而造成的丢包。
RX frame: 表示 misaligned的 frames

对于 TX 的来说，出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 则表示由于 CSMA/CD 造成的传输中断。

dropped与 overruns的区别

dropped：表示这个数据包已经进入到网卡的接收缓存 fifo队列，并且开始被系统中断处理准备进行数据包拷贝（从网卡缓存 fifo队列拷贝到系统内存），但由于此时的系统原因（比如内存不够等）导致这个数据包被丢掉，即这个数据包被 Linux系统丢掉。

overruns：表示这个数据包还没有被进入到网卡的接收缓存fifo队列就被丢掉，因此此时网卡的fifo是满的。为什么fifo会是满的？因为系统繁忙，来不及响应网卡中断，导致网卡里的数据包没有及时的拷贝到系统内存，fifo是满的就导致后面的数据包进不来，即这个数据包被网卡硬件丢掉。所以，个人觉得遇到 overruns非0，需要检测cpu负载与cpu中断情况

三、排查过程

3.1、丢包的可能性

服务器能正常接收到数据包，问题可以限定在 两种可能：

部分客户端发出的数据包本身异常；

服务器处理部分客户端的数据包时触发了某种机制丢弃了数据包。因为出问题的客户端能够正常访问公网上其他服务，后者的可能性更大。

有哪些情况会导致Linux服务器丢弃数据包？

3.2 、确认有 UDP 丢包发生

要查看网卡是否有丢包，可以使用 ethtool -S eth0查看，在输出中查找 bad 或者 drop 对应的字段是否有数据，在正常情况下，这些字段对应的数字应该都是 0。如果看到对应的数字在不断增长，就说明网卡有丢包。另外一个查看网卡丢包数据的命令是 ifconfig，它的输出中会有 RX(receive 接收报文)和 TX（transmit 发送报文）的统计数据：

          ~# ifconfig eth0
...
        RX packets 3553389376  bytes 2599862532475 (2.3 TiB)
        RX errors 0  dropped 1353  overruns 0  frame 0
        TX packets 3479495131  bytes 3205366800850 (2.9 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...

此外， linux系统也提供了各个网络协议的丢包信息，可以使用 netstat -s命令查看，加上 –udp 可以只看 UDP 相关的报文数据：

          [root@holodesk02 GOD]# netstat -s -u
IcmpMsg:
    InType0: 3
    InType3: 1719356
    InType8: 13
    InType11: 59
    OutType0: 13
    OutType3: 1737641
    OutType8: 10
    OutType11: 263
Udp:
    517488890 packets received
    2487375 packets to unknown port received.
    47533568 packet receive errors
    147264581 packets sent
    12851135 receive buffer errors
    0 send buffer errors
UdpLite:
IpExt:
    OutMcastPkts: 696
    InBcastPkts: 2373968
    InOctets: 4954097451540
    OutOctets: 5538322535160
    OutMcastOctets: 79632
    InBcastOctets: 934783053
    InNoECTPkts: 5584838675

对于上面的输出，关注下面的信息来查看 UDP 丢包的情况：

packet receive errors不为空，并且在一直增长说明系统有 UDP 丢包
packets to unknown port received表示系统接收到的 UDP 报文所在的目标端口没有应用在监听，一般是服务没有启动导致的，并不会造成严重的问题
receive buffer errors表示因为 UDP 的接收缓存太小导致丢包的数量

NOTE：并不是丢包数量不为零就有问题，对于 UDP 来说，如果有少量的丢包很可能是预期的行为，比如丢包率（丢包数量/接收报文数量）在万分之一甚至更低。

3.2 、确认网卡或者驱动丢包

之前讲过，如果 ethtool -S eth0中有 rx_***_errors那么很可能是网卡有问题，导致系统丢包，需要联系服务器或者网卡供应商进行处理。

          # ethtool -S eth0 | grep rx_ | grep errors
     rx_crc_errors: 0
     rx_missed_errors: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     rx_errors: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0

netstat -i也会提供每个网卡的接发报文以及丢包的情况，正常情况下输出中 error 或者 drop 应该为 0。

如果硬件或者驱动没有问题，一般网卡丢包是因为设置的缓存区（ring buffer）太小，可以使用 ethtool 命令查看和设置网卡的 ring buffer。

ethtool -g可以查看某个网卡的 ring buffer，比如下面的例子

          # ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

Pre-set 表示网卡最大的 ring buffer值，可以使用 ethtool -G eth0 rx 8192设置它的值。

3.3 、UDP 报文错误丢包

如果在传输过程中UDP 报文被修改，会导致 checksum 错误，或者长度错误，linux 在接收到 UDP 报文时会对此进行校验，一旦发明错误会把报文丢弃。

如果希望 UDP 报文 checksum 及时有错也要发送给应用程序，可以在通过 socket 参数禁用 UDP checksum 检查：

          int disable = 1;
setsockopt(sock_fd, SOL_SOCKET, SO_NO_CHECK, (void*)&disable, sizeof(disable)

3.4 、UDP buffer size 不足丢包

linux 系统在接收报文之后，会把报文保存到缓存区中。因为缓存区的大小是有限的，如果出现 UDP 报文过大（超过缓存区大小或者 MTU 大小）、接收到报文的速率太快，都可能导致 linux 因为缓存满而直接丢包的情况。

在系统层面，linux 设置了 receive buffer 可以配置的最大值，可以在下面的文件中查看，一般是 linux 在启动的时候会根据内存大小设置一个初始值。

/proc/sys/net/core/rmem_max：允许设置的 receive buffer 最大值

/proc/sys/net/core/rmem_default：默认使用的 receive buffer 值

/proc/sys/net/core/wmem_max：允许设置的 send buffer 最大值

/proc/sys/net/core/wmem_dafault：默认使用的 send buffer 最大值

但是这些初始值并不是为了应对大流量的 UDP 报文，如果应用程序接收和发送 UDP 报文非常多，需要将这个值调大。可以使用 sysctl 命令让它立即生效：

          sysctl -w net.core.rmem_max=26214400 # 设置为 25M，临时生效，下次启动消失

也可以修改 /etc/sysctl.conf中对应的参数在下次启动时让参数保持生效。

如果报文报文过大，可以在发送方对数据进行分割，保证每个报文的大小在 MTU 内。

另外一个可以配置的参数是 netdev_max_backlog，它表示 linux 内核从网卡驱动中读取报文后可以缓存的报文数量，默认是 1000，可以调大这个值，比如设置成 2000：

          sudo sysctl -w net.core.netdev_max_backlog=2000

3.5 、系统负载过高丢包

系统 CPU、memory、IO 负载过高都有可能导致网络丢包

比如 CPU 如果负载过高，系统没有时间进行报文的 checksum 计算、复制内存等操作，从而导致网卡或者 socket buffer 处丢包；

memory 负载过高，会应用程序处理过慢，无法及时处理报文；

IO 负载过高，CPU 都用来响应 IO wait，没有时间处理缓存中的 UDP报文。

linux系统本身就是相互关联的系统，任何一个组件出现问题都有可能影响到其他组件的正常运行。对于系统负载过高，要么是应用程序有问题，要么是系统不足。对于前者需要及时发现，debug 和修复；对于后者，也要及时发现并扩容。

3.6 、应用丢包

上面提到系统的 UDP buffer size，调节的 sysctl 参数只是系统允许的最大值，每个应用程序在创建 socket 时需要设置自己 socket buffer size的值。

linux系统会把接受到的报文放到 socket的 buffer中，应用程序从 buffer 中不断地读取报文。所以这里有两个和应用有关的因素会影响是否会丢包：socket buffer size 大小以及应用程序读取报文的速度。

对于第一个问题，可以在应用程序初始化 socket的时候设置 socket receive buffer的大小，比如下面的代码把 socket buffer 设置为 20MB：

          uint64_t receive_buf_size = 20*1024*1024;  //20 MB
setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));

如果不是自己编写和维护的程序，修改应用代码是件不好甚至不太可能的事情。很多应用程序会提供配置参数来调节这个值，请参考对应的官方文档；如果没有可用的配置参数，只能给程序的开发者提 issue 了。很明显，增加应用的 receive buffer 会减少丢包的可能性，但同时会导致应用使用更多的内存，所以需要谨慎使用。另外一个因素是应用读取 buffer 中报文的速度，对于应用程序来说， 处理报文应该采取异步的方式

3.7 、包丢在什么地方

想要详细了解 linux 系统在执行哪个函数时丢包的话，可以使用 dropwatch工具，它监听系统丢包信息，并打印出丢包发生的函数地址：

          # dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring

1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
4 drops at unix_release_sock+20e (0xffffffff817dc94e)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

通过这些信息，找到对应的内核代码处，就能知道内核在哪个步骤中把报文丢弃，以及大致的丢包原因。如果 dropwatch信息输出过多，或者不好用，可以阅读下我的另外两篇博文： iptables观察数据包流向、定位netfilter丢包。这两种方式可以解决绝大部分二三层的数据丢包问题。也可以在 kfree_skb处编写小工具，实现过滤数据包打印栈回溯信息（ebpf可能是一种实现方式、我自己没有做过尝试，后续有时间会做一个）。

此外，还可以使用 linux perf 工具监听 kfree_skb（把网络报文丢弃时会调用该函数）事件的发生：

          sudo perf record -g -a -e skb:kfree_skb
sudo perf script

关于 perf 命令的使用和解读，网上有很多文章可以参考。

3.8 、关于UDP丢包的总结

UDP 本身就是无连接不可靠的协议，适用于报文偶尔丢失也不影响程序状态的场景，比如视频、音频、游戏、监控等。对报文可靠性要求比较高的应用不要使用 UDP，推荐直接使用 TCP。当然，也可以在应用层做重试、去重保证可靠性
如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失
如果系统负载过高，UDP 丢包是没有有效解决方案的。如果是应用异常导致 CPU、memory、IO 过高，请及时定位异常应用并修复；如果是资源不够，监控应该能及时发现并快速扩容
对于系统大量接收或者发送 UDP 报文的，可以通过调节系统和程序的 socket buffer size来降低丢包的概率
应用程序在处理 UDP 报文时，要采用异步方式，在两次接收报文之间不要有太多的处理逻辑

3.9、防火墙拦截

服务器端口无法连接，通常就是查看防火墙配置了，虽然这里已经确认同一个出口IP的客户端有的能够正常访问，但也不排除配置了DROP特定端口范围的可能性。如果系统防火墙丢包，表现的行为一般是所有的 UDP 报文都无法正常接收，当然不排除防火墙只 drop 一部分报文的可能性。如果遇到丢包比率非常大的情况，请先检查防火墙规则，保证防火墙没有主动 drop UDP报文。

如何确认

查看 iptables filter表，确认是否有相应规则会导致此丢包行为：

          $ sudo iptables-save -t filter

这里容易排除防火墙拦截的可能性。 iptables观察数据包流向、定位netfilter丢包。

3.10、连接跟踪表溢出

除了防火墙本身配置DROP规则外，与防火墙有关的还有连接跟踪表nf_conntrack，Linux为每个经过内核网络栈的数据包，生成一个新的连接记录项，当服务器处理的连接过多时，连接跟踪表被打满，服务器会丢弃新建连接的数据包。

如何确认

通过dmesg可以确认是否有该情况发生：

          $ dmesg |grep nf_conntrack

如果输出值中有“nf_conntrack: table full, dropping packet”，说明服务器nf_conntrack表已经被打满。

通过/proc文件系统查看nf_conntrack表实时状态：

          # 查看nf_conntrack表最大连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_max
65536
# 查看nf_conntrack表当前连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_count
7611

当前连接数远没有达到跟踪表最大值，排除这个因素。

如何解决

如果确认服务器因连接跟踪表溢出而开始丢包，首先需要查看具体连接判断是否正遭受DOS攻击，如果是正常的业务流量造成，可以考虑调整nf_conntrack的参数：

nf_conntrack_max决定连接跟踪表的大小，默认值是65535，可以根据系统内存大小计算一个合理值： CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32)，如32G内存可以设置1048576；

nf_conntrack_buckets决定存储 conntrack条目的哈希表大小，默认值是 nf_conntrack_max的1/4，延续这种计算方式： BUCKETS = CONNTRACK_MAX/4，如32G内存可以设置262144；

nf_conntrack_tcp_timeout_established决定ESTABLISHED状态连接的超时时间，默认值是5天，可以缩短到1小时，即3600。

          $ sysctl -w net.netfilter.nf_conntrack_max=1048576
$ sysctl -w net.netfilter.nf_conntrack_buckets=262144
$ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

3.11、Ring Buffer溢出

排除了防火墙的因素，我们从底向上来看Linux接收数据包的处理过程，首先是网卡驱动层。如下图所示，物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃。

如何确认

通过ethtool或/proc/net/dev可以查看因Ring Buffer满而丢弃的包统计，在统计项中以fifo标识：

          $ ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0: 17253386680731 42839525880    0    0    0     0          0 244182022 14879545018057 41657801805    0    0    0     0       0         0

可以看到服务器的接收方向的fifo丢包数并没有增加，这里自然也排除这个原因。

如何解决

如果发现服务器上某个网卡的fifo数持续增大，可以去确认CPU中断是否分配均匀，也可以尝试增加Ring Buffer的大小，通过ethtool可以查看网卡设备Ring Buffer最大值，修改Ring Buffer当前设置：

          # 查看eth0网卡Ring Buffer最大值和当前设置
$ ethtool -g eth0
Ring parameters for eth0:

Pre-set maximums:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096   
Current hardware settings:
RX:     1024   
RX Mini:    0
RX Jumbo:   0
TX:     1024   
# 修改网卡eth0接收与发送硬件缓存区大小
$ ethtool -G eth0 rx 4096 tx 4096
Pre-set maximums:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096   
Current hardware settings:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096

3.12 netdev_max_backlog溢出

netdev_max_backlog是内核从NIC收到包后，交由协议栈（如IP、TCP）处理之前的缓冲队列。每个CPU核都有一个 backlog队列，与 Ring Buffer同理，当接收包的速率大于内核协议栈处理的速率时，CPU的 backlog队列不断增长，当达到设定的 netdev_max_backlog值时，数据包将被丢弃。

如何确认

通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出：

          $ cat /proc/net/softnet_stat
01a7b464 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01d4d71f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0349e798 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
017e0826 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

其中：每一行代表每个CPU核的状态统计，从CPU0依次往下；每一列代表一个CPU核的各项统计：第一列代表中断处理程序收到的包总数；第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。从上面的输出可以看出，这台服务器统计中，并没有因为netdev_max_backlog导致的丢包。

如何解决

netdev_max_backlog的默认值是1000，在高速链路上，可能会出现上述第二列统计不为0的情况，可以通过修改内核参数net.core.netdev_max_backlog来解决：

          $ sysctl -w net.core.netdev_max_backlog=2000

3.13、反向路由过滤

反向路由过滤机制是Linux通过反向路由查询，检查收到的数据包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果没有通过验证，则丢弃数据包，设计的目的是防范IP地址欺骗攻击。rp_filter提供了

三种模式供配置：

0 - 不验证
1 - RFC3704定义的严格模式：对每个收到的数据包，查询反向路由，如果数据包入口和反向路由出口不一致，则不通过
2 - RFC3704定义的松散模式：对每个收到的数据包，查询反向路由，如果任何接口都不可达，则不通过

如何确认

查看当前rp_filter策略配置：

          $ cat /proc/sys/net/ipv4/conf/eth0/rp_filter

如果这里设置为1，就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证了。

从原理来看这个机制工作在网络层，因此，如果客户端能够Ping通服务器，就能够排除这个因素了。

如何解决

根据实际网络环境将rp_filter设置为0或2：

          $ sysctl -w net.ipv4.conf.all.rp_filter=2

或

          $ sysctl -w net.ipv4.conf.eth0.rp_filter=2

3.14 半连接队列溢出

半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列，队列大小由内核参数tcp_max_syn_backlog定义。当服务器保持的半连接数量达到 tcp_max_syn_backlog后，内核将会丢弃新来的SYN包。

如何确认

通过dmesg可以确认是否有该情况发生：

          $ dmesg | grep "TCP: drop open request from"

半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知

          $ netstat -ant|grep SYN_RECV|wc -l
0

大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，第三次握手完成后退出，正常的网络环境中这个过程发生很快，如果这个值较大，服务器极有可能受到了SYN Flood攻击。

如何解决

tcp_max_syn_backlog的默认值是256，通常推荐内存大于128MB的服务器可以将该值调高至1024，内存小于32MB的服务器调低到128，同样，该参数通过sysctl修改：

          $ sysctl -w net.ipv4.tcp_max_syn_backlog=1024

另外，上述行为受到内核参数 tcp_syncookies的影响，若启用 syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有 syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。

          $ sysctl -w net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies = 1

3.15 PAWS

PAWS全名Protect Againest Wrapped Sequence numbers，目的是解决在高带宽下，TCP序列号在一次会话中可能被重复使用而带来的问题。

如上图所示，客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一定时间没有到达服务端，客户端超时重传序列号为A的数据包A2，接下来假设带宽足够，传输用尽序列号空间，重新使用A，此时服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。

PAWS要解决的就是上述问题，它依赖于timestamp机制，理论依据是：在一条正常的TCP流中，按序接收到的所有TCP数据包中的timestamp都应该是单调非递减的，这样就能判断那些timestamp小于当前TCP流已处理的最大timestamp值的报文是延迟到达的重复报文，可以予以丢弃。在上文的例子中，服务器已经处理数据包Z，而后到来的A1包的timestamp必然小于Z包的timestamp，因此服务端会丢弃迟到的A1包，等待正确的报文到来。

PAWS机制的实现关键是内核保存了Per-Connection的最近接收时间戳，如果加以改进，就可以用来优化服务器TIME_WAIT状态的快速回收。

TIME_WAIT状态是TCP四次挥手中主动关闭连接的一方需要进入的最后一个状态，并且通常需要在该状态保持2*MSL（报文最大生存时间），它存在的意义有两个：

1.可靠地实现TCP全双工连接的关闭：关闭连接的四次挥手过程中，最终的ACK由主动关闭连接的一方（称为A）发出，如果这个ACK丢失，对端（称为B）将重发FIN，如果A不维持连接的TIME_WAIT状态，而是直接进入CLOSED，则无法重传ACK，B端的连接因此不能及时可靠释放。

2.等待“迷路”的重复数据包在网络中因生存时间到期消失：通信双方A与B，A的数据包因“迷路”没有及时到达B，A会重发数据包，当A与B完成传输并断开连接后，如果A不维持TIME_WAIT状态2 MSL时间，便有可能与B再次建立相同源端口和目的端口的“新连接”，而前一次连接中“迷路”的报文有可能在这时到达，并被B接收处理，造成异常，维持2MSL的目的就是等待前一次连接的数据包在网络中消失。

TIME_WAIT状态的连接需要占用服务器内存资源维持，Linux内核提供了一个参数来控制TIME_WAIT状态的快速回收：tcp_tw_recycle，它的理论依据是：

在PAWS的理论基础上，如果内核保存Per-Host的最近接收时间戳，接收数据包时进行时间戳比对，就能避免TIME_WAIT意图解决的第二个问题：前一个连接的数据包在新连接中被当做有效数据包处理的情况。这样就没有必要维持TIME_WAIT状态2*MSL的时间来等待数据包消失，仅需要等待足够的RTO（超时重传），解决ACK丢失需要重传的情况，来达到快速回收TIME_WAIT状态连接的目的。

但上述理论在多个客户端使用NAT访问服务器时会产生新的问题：同一个NAT背后的多个客户端时间戳是很难保持一致的（timestamp机制使用的是系统启动相对时间），对于服务器来说，两台客户端主机各自建立的TCP连接表现为同一个对端IP的两个连接，按照Per-Host记录的最近接收时间戳会更新为两台客户端主机中时间戳较大的那个，而时间戳相对较小的客户端发出的所有数据包对服务器来说都是这台主机已过期的重复数据，因此会直接丢弃。

如何确认

通过netstat可以得到因PAWS机制timestamp验证被丢弃的数据包统计：

          $ netstat -s |grep -e "passive connections rejected because of time stamp" -e "packets rejects in established connections because of timestamp”
387158 passive connections rejected because of time stamp
825313 packets rejects in established connections because of timestamp

通过sysctl查看是否启用了tcp_tw_recycle及tcp_timestamp:

          $ sysctl net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_recycle = 1
$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1

这次问题正是因为服务器同时开启了tcp_tw_recycle和timestamps，而客户端正是使用NAT来访问服务器，造成启动时间相对较短的客户端得不到服务器的正常响应。

如何解决

如果服务器作为服务端提供服务，且明确客户端会通过NAT网络访问，或服务器之前有7层转发设备会替换客户端源IP时，是不应该开启tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外还被其他机制依赖，推荐继续开启：

          $ sysctl -w net.ipv4.tcp_tw_recycle=0
$ sysctl -w net.ipv4.tcp_timestamps=1

3.16 怎么知道为什么数据包被丢弃

dropwatch

通过谷歌搜索，发现一个很酷的工具叫 dropwatch 。x相关知识可以参考这篇博文。没有现成的 Ubuntu 安装软件包，但可以通过 github 下载：

https://github.com/pavel-odintsov/drop_watch

以下是我可以编译的说明：

          sudo apt-get install -y libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev
git clone https://github.com/pavel-odintsov/drop_watch.git
cd drop_watch/src
make

这里是输出！它告诉我哪个内核函数丢失数据包，酷！

          sudo ./dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring

1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
4 drops at unix_release_sock+20e (0xffffffff817dc94e)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

perf

用perf监控丢弃的数据包

还有另一个很酷的方法，用来调试发生什么。

可以使用 perf 监视 kfree_skb 事件，这将告诉你什么时候丢弃数据包（内核堆栈发生的地方）：

          sudo perf record -g -a -e skb:kfree_skb
sudo perf script

扩展阅读

还有这两个很酷的文章：

监控和调优Linux网络堆栈：接收数据

https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/

监控和调优Linux网络堆栈：发送数据

https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/

结论

Linux提供了丰富的内核参数供使用者调整，调整得当可以大幅提高服务器的处理能力，但如果调整不当，就会引进莫名其妙的各种问题，比如这次开启tcp_tw_recycle导致丢包，实际也是为了减少TIME_WAIT连接数量而进行参数调优的结果。我们在做系统优化时，时刻要保持辩证和空杯的心态，不盲目吸收他人的果，而多去追求因，只有知其所以然，才能结合实际业务特点，得出最合理的优化配置。

https://jermine.vdo.pub/linux/linux%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%A2%E5%8C%85%E6%95%85%E9%9A%9C%E7%9A%84%E8%A7%A3%E5%86%B3/

https://cizixs.com/2018/01/13/linux-udp-packet-drop-debug/

【Linux】解决可恶的 “NIC Link is Down”_从善若水的博客-CSDN博客

Sun, 09 Oct 2022 09:52:32 CST

文章目录

可恶的 “NIC Link is Down”

前一段时间调试5G实时视频业务，网卡总是会出现 NIC Link is Down的错误，一般几秒之后网卡就会恢复。但是也会遇到一些情况网卡发生 NIC Link is Down之后无法自动恢复，这时候只能重新启动测试PC才能恢复。

下面是我通过dmesg抓到的错误信息：

      May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down

总的来说错误原因就是 kernel: e1000e: eth0 NIC Link is Down。

怎样解决 “NIC Link is Down”

1. 检查网线是否有问题

这是最简单的方式了，只需要替换一根网线，然后继续观察问题是否会再次出现。有些时候有问题的网线会导致这样的错误。

2. 可能是 e1000e网卡驱动的bug

可以尝试更新最新版本的 e1000e 网卡驱动，具体步骤如下：

Ubuntu：可以尝试通过这个脚本进行升级【传送门】
CentOS、RHEL：尝试通过这个Intel的指南进行升级【传送门】

3. NIC出了问题

换一个NIC再进行测试，观察问题是否再次出现。如果NIC是绑定在主板上的，那只能更换一个主板再进行测试了。

4. Switch Port 出了问题

改变 PC/Server 的交换机端口，再进行测试。你可以通过 ethtool命令查看Linux上的网络配置与交换机上的配置是否一致。

5. 尝试更新你的BIOS && 开启ASPM模式

根据经验如果关闭 ASPM模式也可能导致这样的问题。除此之外，保证你的BIOS版本是最新的，如果不是可以进行更新。

6. 关闭流控（flow control）

有些时候开启流控之后会导致一些奇怪的网络错误，可以使用命令将其关闭，并观察问题是否会再次出现，

      ethtool-A eth0 rx off tx off

使用下述命令查看修改是否生效，

      [root@CSRS:~]thtool -a eth0

Pause parametersforeth0:

Autonegotiate:  on
RX:             off
TX:             off

如果看到off，那么流控已经被关闭了。

7. 更换主板与板载网卡和CPU🚑

有一次我发现在 E3-1230v2上持续出现这样的问题，后来我索性将磁盘移植到一块新的 E3-1230v2上，并更换了主板（包括板载NIC）。

高可用的实现（Keepalived + 虚 IP） - schaepher - 博客园

Mon, 26 Sep 2022 10:56:07 CST

为了避免服务单点，也为了负载均衡，我们会加一层 Nginx 层。这个 Nginx 层要有多于一台机器，不然它自身也成为一个单点。

最初加 Nginx 层会变成这样：

      schaepher.com
                       +
                       |
               +-------+
               |
               v
           +---+---+          +-------+
           |       |          |       |
           | Nginx |          | Nginx |
           |       |          |       |
           +--+----+          +---+---+
              |                   |
    +---------+---+-------------+-+-----------+
    |             |             |             |
    v             v             v             v
+---+----+    +---+----+    +---+----+    +---+----+
|        |    |        |    |        |    |        |
| Real   |    | Real   |    | Real   |    | Real   |
| Server |    | Server |    | Server |    | Server |
|        |    |        |    |        |    |        |
+--------+    +--------+    +--------+    +--------+

如果有一台 Real Server 发生故障，则 Nginx 就不会转发到故障的机器，保证服务正常进行。

但是如果主 Nginx 故障了呢？

故障切换的五种方式

客户端自己配置多个 Nginx IP，故障时自己切换。

优点：
- 后端不需要做调整
缺点：
- 客户端要自己维护 IP 列表。
- 客户端要实现一套应对故障的逻辑。
- 不能用于用户和服务之间，只能用于服务与服务之间。
单一服务的情况下，把另一台 Nginx 服务器的 IP 发给用户，让用户访问这个 IP。

优点：
- 简单
缺点：
- 只有内部系统用户才可能接受这种做法。面向外部用户的时候，外部用户不会接受。
运维人员手动修改 DNS 解析，将域名解析到另一台 Nginx 服务器。或者程序定期检测，发现有问题就自动发起修改 DNS 解析的请求。

解决了什么问题？
- 用户需要手动修改 hosts 或者需要切换 URL 的问题。
没有解决什么问题？
- 在 DNS 解析生效之前，服务完全不可用。
- 客户端会缓存 DNS 解析，也要等客户端缓存过期。
将域名解析到所有 Nginx 服务器。程序定期做检测，当发现有问题的时候发起请求，让 DNS 将故障的 IP 移除掉。

DNSPod 自带这个功能

解决了什么问题？
- 在 DNS 解析生效之前，服务完全不可用的问题。
没有解决什么问题？
- 仍然有部分用户无法访问服务。
使用虚 IP（Virtual IP Address，以下称为 VIPA）。域名固定解析到这个 IP，当 VIPA 所在服务器故障时，让 VIPA 自动漂移到另一台服务器。

解决了什么问题？
- 不需要修改 DNS 解析，秒级别的生效延迟。
- 用户无感知。
带来了什么问题？
- 多了一个故障点，即使得 VIPA 自动漂移的那个程序，如 Keepalived。
- 需要额外申请一个 IP 作为 VIPA 。
- 涉及存储的时候，由于切换速度很快，可能会导致数据不一致。

VIP 是什么

全称为 VIPA（Virtual IP Address），虚拟 IP 地址。

通常一个 IP 只能绑定在某台机器的一个网卡上。一旦这台机器故障，根据 IP 找到这台机器的请求就会得不到响应。

      正常
     schaepher.com
     192.168.1.101
           +
           |
           |
           |
           v

    +---------------+        +---------------+
    |               |        |               |
    | 192.168.1.101 |        | 192.168.1.102 |
    |               |        |               |
    +---------------+        +---------------+

故障
     schaepher.com
     192.168.1.101
           +
           +
             +-+ 不通
           |
           v
          故障
    +---------------+        +---------------+
    |               |        |               |
    | 192.168.1.101 |        | 192.168.1.102 |
    |               |        |               |
    +---------------+        +---------------+

而 VIPA 虽然最终也会配置在一台机器上，但一旦这台机器故障，备用机器就会把这个 IP 抢过去配置到网卡上（VIPA 漂移到备机）。这样可以在 IP 不变的情况下，让请求转移到正常的机器，减少服务故障时间。

      正常
     schaepher.com
     192.168.1.100(VIPA)
           +
           |
           |
           |
           v

    +---------------+        +---------------+
    | 192.168.1.100 |        |               |
    | 192.168.1.101 |        | 192.168.1.102 |
    |               |        |               |
    +---------------+        +---------------+

故障
     schaepher.com
     192.168.1.100(VIPA)
           +
           |
           +-------------------------+
                                     |
                                     v
          故障
    +---------------+        +---------------+
    |               |        | 192.168.1.100 |
    | 192.168.1.101 |        | 192.168.1.102 |
    |               |        |               |
    +---------------+        +---------------+

而 Keepalive 则是实现 VIPA 漂移的一种工具。

另一种是比较复杂的 Heartbeat。

Keepalived

Keepalived 实现 VIPA 漂移的基础是 VRRP 协议。

VRRP 最早用于路由器，将多台路由器设备虚拟成一台路由器。每台设备都有一个角色。角色有两种 Master 和 Backup。Master 会持有虚 IP。每台设备都有一个权重，权重最高的正常设备会被选举为 Master。

现在 Keepalived 实现了 VRRP 协议，使得可以将其用在其他设备上。

将 Keepalived 安装在一组设备上，它们之间会互相通信来检测状态。如果发现 Master 超过一定时间没有反应，则重新选举 Master。

Master 可能直接故障没有反应，也可能只是服务出现问题。如果是后一种情况，需要主动关闭 Keepalived 进程。

以下展示配置文件。

IP	所属	角色
192.168.1.100	Master
192.168.1.101	主机 A	Master
192.168.1.102	主机 B	Backup

192.168.1.101 - 主机 A - Master

/etc/keepalived/keepalived.conf

      ! Configuration File for keepalived

global_defs {
    script_user root
    router_id LVS_DEVEL
    vrrp_skip_check_adv_addr
    vrrp_strict     # 严格模式使得无法使用 unicast_peer 配置，好处是无需指定其他机器的 IP
    vrrp_garp_interval 0
    vrrp_gna_interval 0
}

vrrp_script chk_http_port {
    script "/etc/keepalived/chk_nginx.sh"   # 检测当前机器的服务是否故障，如果故障则关闭 keepalived
    interval 2
    weight -5
    fall 2
    rise 1
}

vrrp_instance VI_1 {
    state MASTER    # 主备配置不一致
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass aaaaaaa   # 主备该配置必须一样
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        chk_http_port   # 在 vrrp_script 定义的名字
    }
    notify_master "/etc/keepalived/notify.sh 192.168.1.100 master"  # 当这台机器成为 Master 时发送通知
    notify_backup "/etc/keepalived/notify.sh 192.168.1.100 backup"
    notify_fault  "/etc/keepalived/notify.sh 192.168.1.100 fault"
}

192.168.1.102 - 主机 B - Backup

只需改两个配置的值

/etc/keepalived/keepalived.conf

      ! Configuration File for keepalived

global_defs {
    script_user root
    router_id LVS_DEVEL
    vrrp_skip_check_adv_addr
    vrrp_strict
    vrrp_garp_interval 0
    vrrp_gna_interval 0
}

vrrp_script chk_http_port {
    script "/etc/keepalived/chk_nginx.sh"
    interval 2
    weight -5
    fall 2
    rise 1
}

vrrp_instance VI_1 {
    state BACKUP    # 主备配置不一致
    interface eth0
    virtual_router_id 51
    priority 90     # 备机权重比主机低
    advert_int 1
    nopreempt       # 防止争抢 VIPA，只有 state 设置为 BACKUP 才能使用该选项
    authentication {
        auth_type PASS
        auth_pass aaaaaaa
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        chk_http_port
    }
    notify_master "/etc/keepalived/notify.sh 192.168.1.100 master"  # 当这台机器成为 Master 时发送通知
    notify_backup "/etc/keepalived/notify.sh 192.168.1.100 backup"
    notify_fault  "/etc/keepalived/notify.sh 192.168.1.100 fault"
}

/etc/keepalived/chk_nginx.sh

      #!/bin/bash
if [[ -z "$(ps aux | grep "nginx: master process" | grep -v grep)" ]]; then
    systemctl restart nginx # 尝试重启 nginx  
    sleep 5  

    if [[ -z "$(ps aux | grep "nginx: master process" | grep -v grep)" ]]; then
        # 启动失败则关闭 keepalived，触发 VIPA 漂移
        systemctl stop keepalived
    fi
fi

/etc/keepalived/notify.sh

      #!/bin/bash

# contact=xxx.schaepher.com

notify() {
    vip=$1
    role=$2
    mailSubject="$(hostname) to be ${role}: ${vip} floating"
    mailBody="$(date '+%F %H:%M:%S'): vrrp transition, $(hostname changed to be ${role})"
    # echo ${mailBody} | mail -s "${mailSubject}" "${contact}"
    echo ${mailSubject} >> /var/log/keepalived.mail
    echo ${mailBody} >> /var/log/keepalived.mail
    echo "" >> /var/log/keepalived.mail
}

notify $1 $2

扩展

提高利用率
由于一个 VIPA 只能配置在一台机器上，如果共有两台机器，则浪费了 50% 的资源。
如果要提高资源的利用率，可以再申请一个 VIPA。把备机配置为 Master，把主机配置为 Backup。
VIPA 争抢
由于 nopreempt 只能配置在 BACKUP 上，如果 state 为 MASTER 的机器故障并恢复，则会把 VIPA 抢过去。
整个过程是：
1. 主机 A 故障
2. VIPA 漂移到主机 B
3. 主机 A 恢复
4. VIPA 漂移到主机 A
这样就会导致第四步多漂移了一次。而漂移可能会对服务有很短暂的影响。如果希望主机 A 恢复后，仍然让主机 B 持有 VIPA，则要在主机的 Keepalived 启动之前修改配置中的 state，改为 BACKUP。
避免丢包
在 VIPA 漂移到备机之间，短暂的时间内数据包仍然会发送到主机。如果主机能够连上，则可以使用防火墙将数据包转发到备机。然后停止 Keepalived 。
```
          iptables -t nat -I PREROUTING -i eth0 -j DNAT --to-destination 192.168.1.102
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
```
数据库的问题
数据库如果使用双主，在 VIPA 切换的时候，数据可能未同步完成，可能会造成自增 ID 冲突。
可以配置 Keepalived 等一段时间后再发送 ARP 请求，以此等待同步完成。
配置项是： vrrp_garp_master_delay 10表示延迟 10 秒返送。

参考

https://www.linuxprobe.com/keepalived-nginx.html

想把博客从 hexo 迁移到 Jekyll 了 - V2EX

Wed, 21 Sep 2022 17:00:26 CST

理由：

1 写 hexo 步骤太繁琐了每次都要写好 md 然后复制到家里的电脑，开着代理，git push ，步骤太多已经让人懒得提交到博客了甚至有时候写完就放本地了

2 hexo 的环境难跨设备，这次重装系统，老的环境没了，虽然文章内容 md 还在，但是已经没法提交新文章了（工程环境没了，要从头搭建）

3 据说 Jekyll 能达到和 hexo 一样的效果，但是绝对的优势是可以只提交 md ，剩下的事在线生成。也就是说我可以直接在 github 网页端提交 md 文件就能实现文章的更新。我第一次部署好之后，甚至工程环境就可以放心大胆的丢掉了，毕竟平时不需要修改什么，以后只改 md 文件

4 主题也不少看了几个挺满意的

5 还有什么坑是我没考虑到的吗?

第 1 条附言 · 161 天前

如果我看教程没理解错的话，hexo 每次都要本地环境生成 html 再上传（除非像楼上建议的自己搭建一个自动构建服务，甚至还可能需要服务器），而 jeklly 可以直接修改 md 文件就生效了

这个就是核心优势，能省下使用者对环境、设备同步的顾虑

很多人提到了各种在线构建，谢谢建议
但是 2022 年了搭建个好用的博客还需要这么繁琐吗？
“ CloudFlare Pages, Vercel, Netlify, Surge, Render CI/CD ”
这些东西我没用过，虽然我有信心跟着各位大佬的教程折腾个一下午 /一晚上肯定能搞定，但我的核心目的是写博客，美观、好用就行了，能不去踩的坑就尽量不踩
省下来的时间多写一篇博客不香吗

第 2 条附言 · 161 天前

同时也给后来看到这个帖子的人一些已知的信息吧：
hexo 可以额外再配合 GitHub Actions ，实现提交之后自动生成 html ，但是需要一个仓库存源码，需要自己研究这个流程

jeklly 更过分，可以直接 fork 别人的模板，然后甚至只需要在线再 github 上改改配置、提交 md 就可以用了

第 3 条附言 · 161 天前

最后我 fork 了一个 Jekyll 的主题（ next ）
然后改了一些属性，再把文章从网页端提交就搞定了！
全程没用命令行电脑上没配环境电脑甚至没 git
全都在网页端操作
非常方便

局域网内搭建浏览器可信任的SSL证书 – 唐玥璨 | 博客

Fri, 02 Sep 2022 14:55:15 CST

首先是为什么要干这个事情，你可能会说随便搞个自签名证书难道不能用吗？答案是还真的不能用，的确对于开发来说搞个自签名的证书就行了。但是一旦放到生产环境浏览器对证书有效性进行验证的时候便是不可信状态，这时就必须要用户点击一下继续访问，但是对于我们即将实施项目的自动化要求来说没法这样干。你可能又会说了现在这个环境在阿里云、华为云这些平台上随便申请一个免费的证书难道不行吗？答案是真的不行，因为项目的特殊要求最终我们部署的环境是完全没有外网访问的，就只能在局域网环境下运行及意味着不光是 SSL证书的问题我们连DNS服务器都要自己建。这时候你可能又要说了那么直接用 http访问就可以了，干嘛要用 ssl证书呀？答案是这个项目需要使用 WebRTC进行音视频多人会议，而WebRTC只能在 https下运行。

其实上面的说法有一个点需要更正一下，自签名证书其实也可以但是一旦对超过100个客户端进行分发简直是要命的事情，所以我们通过Windows域控的方式统一对下属计算机进行证书分发保证可用性。

1.原理

SSL证书的信任机制其实是非常简单的，第一需要一个机构证书，第二是需要服务端证书，一般来说机构证书被称为CA证书，而服务端证书就称为服务器证书吧。那么为啥 https非常安全呢？答案其实不复杂，下面就是一段逻辑性描述来说明为啥 https是安全的。

通常情况下我们在给Nginx、Tomcat、IIS上配置的证书便是服务器证书，那么它是怎么保证客户端访问的地址绝对没有被拦截修改的呢？其实也不复杂，当我们的浏览器发起一个请求的时候到服务端上时，对应web服务器会通过证书的秘钥将http响应值进行一次加密，然后将密文与明文同时返回出来，客户端浏览器接收到响应之后会将密文对称解码然后和明文进行对比，这样一来便可以保证响应值没有被串改。

这个时候逻辑上稍微厉害一点都会发现一个问题，客户端是怎么解码的？这里的答案就是服务端在响应的时候同时会将证书的公钥也返回，这个公钥只能解码对应私钥加密的信息，同时这个公钥无法加密只能解密，这样一来如果如果某人想要拦截http请求便必须知道对应的私钥才行，否则浏览器一旦发现解密信息对不上便知道了响应数据已经被拦截修改过了。

如果你反应过来了你会发现一个新的问题，那么假设拦截这自己搞了一对有效的私钥和公钥然后伪装为服务器不就行了，恭喜你盲生发现了华点。这里就需要CA证书来处理了。其实服务器证书的公钥是由CA证书的秘钥配对加密来的，这样一来当请求返回的服务器公钥和通过CA证书进行验证时便会发现这个公钥是不是由机构签发的公钥，一旦对应不上则说明服务器不是原来CA证书签发服务器证书，这就证明你的请求被第三方拦截了。同时CA证书对于浏览器而言只有公钥，也就是说安装证书时本质上就是将CA证书的公钥导入到你的电脑上了，至此除开CA机构的证书发放者没有知道CA证书的秘钥是什么这样一来便可以保证下面几个非常关键的安全性：

你请求的服务绝对是官方的服务器，绝对不是黑客自建的服务器。
服务器响应给你的数据绝对是正确的，期间黑客绝对无法对其进行修改。

证书的结构如下：

这里还有一个问题便是这些CA证书是哪来的，自己的电脑上又重来没有导入过什么证书。这里便是一个非常无耻躺着赚钱的商业模式了，微软、谷歌、苹果等公司提供了操作系统和浏览器，他们便是第一方的CA机构，他们的系统自己肯定信任自己对吧？所以系统安装的时候他们的CA公钥已经安装到你们的系统里面了，然后这几家巨头合伙说那么这些CA公钥在每种系统都有，然后就是一写第三方公司和这些巨头打成了合作，这些公司的机构证书也被巨头们信任所以理所当然的入库了，这些三方机构便是大名鼎鼎的 Symantec、 GeoTrust、 Let's Encrypt几个巨头，这些机构一个单域名的签名证书都敢直接拿出来卖，一年好几千，对他们而言无法就是给下发的证书进行一次签名而已，真正的躺着赚钱。

2.开始制作证书

这里我使用的证书工具是 openssl，经典工具，坦白的说非常难用。

2.1创建CA证书

首先第一步肯定是制作一个机构证书也就是CA证书出来，这里有两种方案，第一是直接用 openssl创建CA证书，另一种是windows域控生成域组织的CA证书，我们分开说。

2.1.1通过 `openssl`创建CA证书

第一步是创建一个秘钥，这个便是CA证书的根本，之后所有的东西都来自这个秘钥：

# 通过rsa算法生成2048位长度的秘钥
openssl genrsa -out myCA.key 2048

第二步是通过秘钥加密机构信息形成公钥：

# 公钥包含了机构信息，在输入下面的指令之后会有一系列的信息输入，这些信息便是机构信息，公司名称地址什么的
# 这里还有一个过期信息，CA证书也会过期，openssl默认是一个月，我们直接搞到100年
openssl req -new -x509 -key myCA.key -out myCA.cer -days 36500

这一步需要输入的机构信息有点，分别说一下：

参数名称	参数值
Country Name	国家代码，比如中国就是CN
State or Province Name	省名称
Locality Name	城市名称
Organization Name	机构名称
Organizational Unit Name	机构单位名称
Common Name	重点参数：授权给什么，因为机构是根节点所以是授权给自己
Email Address	邮件地址

2.1.2通过windows域控创建CA证书

这种便是我采用的方案，执行上比直接用 openssl创建证书复杂多了，但是好处也非常多，一方面域控下级的所有计算机天然对域控服务就是信任状态，第二是域控制器能够通过组策略域内同步CA证书，本质上来讲相对于多了一个CA证书同步与分发的机制。我这边使用的Windows Server 2016，其他版本区别也不大。

第一步是在域控上启用证书服务

第二步是安装完毕之后配置证书

这里非常简单，我都不想说了，直接根据提示输入相关信息就行了，在过期时间那一步最好将时间拉长，我还是使用的100年。

第三步是通过组策略进行分发

策略路径是： 计算机策略/Windows设置/安全设置/公钥策略/受信任的根证书颁发机构和 计算机策略/Windows设置/安全设置/公钥策略/受信任的发布者证书。将上面创建的证书导出之后，在这里导入即可。

2.2创建服务器证书

在得到CA证书之后，需要通过 openssl工具对证书进行转换得到公钥（ .crt文件）和密钥（ .key文件），无论CA证书是怎么来的到这里之后就没有任何区别了，服务器证书的制作流程相较CA证书要复杂一点点。

第一步通过 openssl工具创建服务器的秘钥：

# 通过RSA算法生成长度2048位的秘钥
openssl genrsa -out server.key 2048

第二步这里是创建一个签名请求

需要将服务器信息写入到请求文件之中，然后通过CA机构证书对请求签名形成服务器证书公钥，这一步要复杂一些，很多网上的教程在这里都GG了主要原因没有把原理搞清楚。

首先 https证书的公钥不同于自定义情况下的加密证书，这里需要安装浏览器标准进行配置，首先 openssl默认的证书版本是V1，V1在支持 https时部分浏览器依旧会认为不安全，所以需要使用V3版本；同时 openssl即便是使用V3版本依旧没有附带V3的 subjectAltName字段数据（这里是证书对应的IP地址或者域名，可以用通配符）。但是这些东西命令行没法指定所以需要配置文件，我这里准备了一个：

tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7

[ ca ]
default_ca = CA_default  # The default ca section

[ CA_default ]
dir  = ./demoCA  # Where everything is kept
certs  = $dir/certs  # Where the issued certs are kept
crl_dir  = $dir/crl  # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts  # default place for new certs.
certificate = $dir/cacert.pem  # The CA certificate
serial  = $dir/serial   # The current serial number
crlnumber = $dir/crlnumber # the current crl number
crl  = $dir/crl.pem   # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert  # The extentions to add to the cert
name_opt  = ca_default  # Subject Name options
cert_opt  = ca_default  # Certificate field options
default_days = 365   # how long to certify for
default_crl_days= 30   # how long before next CRL
default_md = default  # use public key default MD
preserve = no   # keep passed DN ordering
policy  = policy_match

[ policy_match ]
countryName  = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName  = supplied
emailAddress  = optional

[ policy_anything ]
countryName  = optional
stateOrProvinceName = optional
localityName  = optional
organizationName = optional
organizationalUnitName = optional
commonName  = supplied
emailAddress  = optional

[ req ]
default_bits  = 1024
default_keyfile  = privkey.pem
distinguished_name = req_distinguished_name
attributes  = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = utf8only
req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName   = Country Name (2 letter code)
countryName_default  = CN
countryName_min   = 2
countryName_max   = 2

stateOrProvinceName  = State or Province Name (full name)
stateOrProvinceName_default = BeiJing

localityName   = Locality Name (eg, city)

0.organizationName  = Organization Name (eg, company)
0.organizationName_default = myca
organizationalUnitName  = Organizational Unit Name (eg, section)
commonName   = Common Name (e.g. server FQDN or YOUR name)
commonName_max   = 64
emailAddress   = Email Address
emailAddress_max  = 64

[ req_attributes ]
challengePassword  = A challenge password
challengePassword_min  = 4
challengePassword_max  = 20
unstructuredName  = An optional company name

[ usr_cert ]
basicConstraints=CA:FALSE
nsCertType = client, email, objsign
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
nsComment   = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

[ svr_cert ]
basicConstraints=CA:FALSE
nsCertType   = server
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment, keyAgreement
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
extendedKeyUsage = serverAuth,clientAuth

[ v3_req ]
subjectAltName = @alt_names

# 这里是重点，需要将里面配置为最终服务端需要的域名或者IP
# 这里可以写多个，能够自行添加DNS.X = XXXXXX
[ alt_names ]
DNS.1 = xunshi.com
DNS.2 = *.xunshi.com

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:true

[ crl_ext ]
authorityKeyIdentifier=keyid:always

[ proxy_cert_ext ]
basicConstraints=CA:FALSE
nsComment   = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

[ tsa ]
default_tsa = tsa_config1 # the default TSA section

[ tsa_config1 ]
dir  = ./demoCA  # TSA root directory
serial  = $dir/tsaserial # The current serial number (mandatory)
crypto_device = builtin  # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem  # The TSA signing certificate
     # (optional)
certs  = $dir/cacert.pem # Certificate chain to include in reply
     # (optional)
signer_key = $dir/private/tsakey.pem # The TSA private key (optional)

default_policy = tsa_policy1  # Policy if request did not specify it
     # (optional)
other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional)
digests  = md5, sha1  # Acceptable message digests (mandatory)
accuracy = secs:1, millisecs:500, microsecs:100 # (optional)
clock_precision_digits  = 0 # number of digits after dot. (optional)
ordering  = yes # Is ordering defined for timestamps?
    # (optional, default: no)
tsa_name  = yes # Must the TSA name be included in the reply?
    # (optional, default: no)
ess_cert_id_chain = no # Must the ESS cert id chain be included?
    # (optional, default: no)

将上面的配置内容保存为 openssl.cnf放到生成的服务器证书文件的目录下（注意：修改alt_names里面的域名或者IP为最终部署需要的地址，支持通配符），然后执行创建签名申请文件即可，执行运行：

# 和创建CA时一样这里需要输入一堆服务器信息，输入项也是相同的。
# 不过在输入Common Name（CN）最好直接输入服务器的IP地址或者域名。
openssl req -config openssl.cnf -new -out server.req -key server.key

第三步通过CA机构证书对服务器证书进行签名认证

# 这里没有什么需要说的，本质上就是将签名请求文件进行签名最终得到服务器的公钥
openssl x509 -req  -extfile openssl.cnf -extensions v3_req -in server.req -out server.cer -CAkey myCA.key -CA myCA.cer -days 36500 -CAcreateserial -CAserial serial

第四步部署证书

这里应该没有什么需要说的了，我们通过Nginx部署，最终得到 server.key就是秘钥， server.cer文件就是公钥只需要配置给Nginx就行了。

3.信任CA机构证书

如果通过Windows域控创建的CA证书，其证书本身通过组策略便可以给每一个域下计算机添加机构信任。如果你没有域控只是通过 openssl创建的CA证书也没有关系，只需要将CA证书的公钥（ myCA.cer文件）导入到系统信任的根证书颁发机构里面就行了：

这个界面在windows的 internet选型->内容->证书可以打开，导入即可，也可以直接双击 cer文件进行证书安装，最终不光是windows系统，任何操作系统都可以安装证书来进行对CA机构的进行信任操作。

在对证书进行信任之后通过https打开浏览器进入内网 DNS或者 host配置的域名便可以得到没有任何警告的内容的安全连接：

如果是Mac系统访问逻辑也是一样的通过安装CA证书并且在钥匙串内添加信任之后依然可以正常访问：

在Android手机上也是一样，安装并且信任证书之后可以正常访问：

4.总结

本来对我对 https的认证逻辑其实理解没有多深入，以前也只是用过SSL证书进行TCP传输加密而已，经过对 openssl的学习现在至少在理解上达到了及格水平，不过这次学习论证与探索的过程我个人极其不愉快，本来这东西在有了理解之后大家都看得出来不是什么很难的东西，事实上我也只用了一天半就搞定了。但是网上充斥大量垃圾内容，不光没有什么正向内容甚至不少内容还TM起了误导的作用，整个中文互联网检索体系下就没有找到一篇文章稍微详细描述整个搭建逻辑与流程，简直了，最终我只能从 https原理和 openssl的官方文档开始看起，过于离谱了。基本上可以得到一个结论现在天天写一些所谓干货的博主简直就是滥竽充数，其内容千篇一律大多数也是抄袭来的基本上什么都没有说清楚简直浪费时间。

最后说一下 https的原理，在解释清楚之后其实不是绝对上的安全，结合本文各位可以想一下怎样去伪造一个页面出来？假设我是黑客来搞入侵其实只需要一个小小的脚本就可以了，我们自行制作CA和服务证书之后，通过修改HOST文件对域名解析进行劫持将其引导到我们自己的服务器，然后将我们自己制作CA证书注入目标电脑的受信任证书组，这样一来对于被入侵者已经看到是安全连接但是其请求已经被我们拦截了。所以各位不要看到https就以为安全了，一旦你的电脑本身就被入侵了那么 https也是形同虚设的，所以在执行高风险操作的时候最好还是点开站点的证书看看对应的CA机构是不是被修改过。

Elasticsearch深度应用（上） - 女友在高考 - 博客园

Sat, 09 Jul 2022 14:17:14 CST

索引文档写入和近实时搜索原理

基本概念

Segments in Lucene

众所周知，Elasticsearch存储的基本单元是shard，ES中一个index可能分为多个shard，事实上每个shard都是一个Lucece的Index，并且每个Lucece Index由多个Segment组成，每个Segment事实上是一些倒排索引的集合，每次创建一个新的Document，都会归属一个新的Segment，而不会去修改原来的Segment。且每次的文档删除操作，仅仅会标记Segment的一个删除状态，而不会真正立马物理删除。所以说ES的Index可以理解为一个抽象的概念。如下图所示：

Commits in Lucene

Commit操作意味着将Segment合并，并写入磁盘。保证内存数据不丢失。但刷盘是很重的IO操作，所以为了性能不会刷盘那么及时。

Translog

新文档被索引意味着文档首先写入内存buffer和translog文件。每个shard都对应一个translog文件。

Refresh in Elasticsearch

在Elasticsearch种，_refresh操作默认每秒执行一次，意味着将内存buffer的数据写入到一个新的Segment中，这个时候索引变成了可被检索的。写入新Segment后会清空内存。

Flush in Elasticsearch

Flush操作意味着内存buffer的数据全都写入新的Segment中，并将内存中所有的Segments全部刷盘，并且清空translog日志的过程。

近实时搜索

提交一个新的段到磁盘需要一个fsync来确保段被物理性的写入磁盘，这样在断电的时候就不会丢数据。但是fsync操作代价很大，如果每次索引一个文档都去执行一次的话就会造成很大的性能问题。

像之前描述的一样，在内存索引缓冲区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存--这一步代价会比较低，稍后再被刷新到磁盘（这一步代价比较高）。不过只要文件已经在系统缓存中，就可以像其它文件一样被打开和读取了。

原理：

当一个写请求发送到es后，es将数据写入memory buffer中，并添加事务日志（translog）。如果每次一条数据写入内存后立即写到硬盘文件上，由于写入的数据肯定是离散的，因此写入硬盘的操作也就是随机写入了。硬盘随机写入的效率相当低，会严重降低es的性能。

因此es在设计时在memory buffer和硬盘间加入了Linux的高速缓存（Filesy stemcache）来提高es的写效率。当写请求发送到es后，es将数据暂时写入memory buffer中，此时写入的数据还不能被查询到。默认设置下，es每1秒钟将memory buffer中的数据refresh到Linux的Filesy stemcache，并清空memory buffer，此时写入的数据就可以被查询到了。

Refresh API

在Elasticsearch中，写入和打开一个新段的轻量的过程叫做refresh。默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说Elasticsearch是近实时搜索：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

这些行为可能会对新用户造成困惑：他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用refresh API执行一次手动刷新:

刷新所有索引

      POST /_refresh

只刷新某一个索引

      POST /索引名/_refresh

只刷新某一个文档

      PUT /索引名/_doc/{id}?refresh
{"test":"test"}

并不是所有的情况都需要每秒刷新。可能你正在使用Elasticsearch索引大量的日志文件，你可能想优化索引速度而不是近实时搜索，可以通过设置refresh_interval，降低每个索引的刷新频率。

      PUT /my_logs
{ 
"settings": { "refresh_interval": "30s" }
}

refresh_interval可以在既存索引上进行动态更新。在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来。

      PUT /my_logs/_settings
{ "refresh_interval": -1 }

持久化变更

如果没有用fsync把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证Elasticsearch的可靠性，需要确保数据变化被持久化到磁盘。

在动态更新索引时，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。Elasticsearch增加了一个translog，或者叫事务日志，在每一次对Elasticsearch进行操作时均进行了日志记录。

整个流程如下：

一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了translog。如下图：

分片每秒refres一次，refresh完成后，缓存被清空
这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志
每隔一段时间--例如translog变得越来越大--索引被刷新（flush）；一个新的translog被创建，并且一个全量提交被执行。

所有在内存缓冲区的文档被写入一个新的段
缓冲区被清空
一个提交点被写入磁盘
文件系统缓存通过fsync被刷新（flush）
老的translog被删除

translog提供所有还没有被刷到磁盘的操作的一个持久化纪录。当Elasticsearch启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放translog中所有在最后一次提交后发生的变更操作。

Flush API

这个执行一个提交并且截断translog的行为在Es中被称为一次flush。分片每30分钟被自动刷新（flush），或者在translog太大的时候也会刷新。

flush API 可以被用来执行手工的刷新

      POST /索引名称/_flush

#刷新（flush）所有的索引并且等待所有刷新在返回前完成
POST /_flush?wait_for_ongoin

我们知道用fsync把数据从文件系统缓存flush到硬盘是安全的，那么如果我们觉得偶尔丢失几秒数据也没关系，可以启用async。

      PUT /索引名/_settings {
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}

索引文档存储段合并机制

由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和CPU运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。默认情况下，归并线程的限速配置indices.store.throttle.max_bytes_per_sec是20MB。对于写入量较大，磁盘转速较高，甚至使用SSD盘的服务器来说，这个限速是明显过低的。对于ELKStack应用，建议可以适当调大到100MB或者更高。

      PUT /_cluster/settings
{
  "persistent" : {
  "indices.store.throttle.max_bytes_per_sec" : "100mb"
  }
}

归并策略

归并线程是按照一定的运行策略来挑选 segment 进行归并的。主要有以下几条：

index.merge.policy.floor_segment默认2MB，小于这个大小的segment，优先被归并。

index.merge.policy.max_merge_at_once默认一次最多归并10个segment

index.merge.policy.max_merge_at_once_explicit默认optimize时一次最多归并30个segment。

index.merge.policy.max_merged_segment默认5GB，大于这个大小的segment，不用参与归并。optimize除外

optimize API

optimizeAPI大可看做是强制合并API。它会将一个分片强制合并到max_num_segments参数指定大小的段数目。这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。

在特定情况下，使用optimizeAPI颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存储在一个索引中。老的索引实质上是只读的；它们也并不太可能会发生变化。在这种情况下，使用optimize优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速。

api:

      POST /logstash-2014-10/_optimize?max_num_segments=1

java api:

      forceMergeRequest.maxNumSegments(1)

Es乐观锁

Es的后台是多线程异步的，多个请求之间没有顺序，可能后发起修改请求的先被执行。Es的并发是基于自己的_version版本号进行并发控制的。

1. 基于seq_no

乐观锁示例：

先新增一条数据

      PUT /item/_doc/4
{
  "date":"2022-07-01 01:00:00",
  "images":"aaa",
  "price":22,
  "title":"先"
}

查询：

      GET /item/_doc/4

可以查出我们的seq_no和primary_term

      {
  "_index" : "item",
  "_type" : "_doc",
  "_id" : "4",
  "_version" : 5,
  "_seq_no" : 12,
  "_primary_term" : 5,
  "found" : true,
  "_source" : {
    "date" : "2022-07-01 01:00:00",
    "images" : "aaa",
    "price" : 33,
    "title" : "先"
  }
}

然后两个客户端都根据这个seq_no和primary_term去修改数据，会有一个提示异常的。

      PUT /item/_doc/4?if_seq_no=12&if_primary_term=5
{
  "date":"2022-07-01 01:00:00",
  "images":"aaa",
  "price":33,
  "title":"先"
}

2. 基于external version

es提供了一个功能，不用它内部的_version来进行并发控制，你可以根据你自己维护的版本号进行并发控制。

      ?version=1&version_type=external

区别在于，version方式，只有当你提供的version与es中的version一模一样的时候，才可以进行修改，只要不一样，就报错。当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改

示例：

我先查出目前的version为7

      {
  "_index" : "item",
  "_type" : "_doc",
  "_id" : "4",
  "_version" : 7,
  "_seq_no" : 14,
  "_primary_term" : 5,
  "found" : true,
  "_source" : {
    "date" : "2022-07-01 01:00:00",
    "images" : "aaa",
    "price" : 33,
    "title" : "先"
  }
}

只有设置为8才能成功修改了

      PUT /item/_doc/4?version=8&version_type=external
{
  "title":"先"
}

分布式数据一致性如何保证

es5.0版本后

      PUT /test_index/_doc/1?wait_for_active_shards=2&timeout=10s
{
  "name":"xiao mi"
}

这代表着所有的shard中必须要有2个处于active状态才能执行成功，否则10s后超时报错。

Elasticsearch深度应用（下） - 女友在高考 - 博客园

Sat, 09 Jul 2022 14:14:38 CST

Query文档搜索机制剖析

1. query then fetch(默认搜索方式)

搜索步骤如下：

发送查询到每个shard
找到所有匹配的文档，并使用本地的Term/Document Frequery信息进行打分
对结果构建一个优先队列
返回关于结果的元数据到请求节点。注意，实际文档还没有发送，只是分数
来自所有shard的分数合并起来，并在请求节点上进行排序，文档被按照查询要去进行选择
最终，实际文档从它们各自所在的独立的shard上检索出来
结果被返回给用户

优点：返回的数据量是准确的

缺点：性能一般，并且数据排名不准确

2. dfs query then fetch

比前面的方式多了一个DFS步骤。也就是查询之前，先对所有分片发送请求，把所有分片中的词频和文档频率等打分依据全部汇总到一块，再执行后面的操作。

详细步骤如下：

预查询每个shard，询问Term和Document frequency
发送查询到每个shard
找到所有匹配的文档，并使用全局的Term/Document Frequency信息进行打分
对结果构建一个优先队列
返回关于结果的元数据到请求节点。注意，实际文档还没有发送，只是分数。
来自所有shard的分数合并起来，并在请求节点进行排序，文档被按照查询要求进行选择
最终，实际文档从它们各自所在的独立的shard上检索出来
结果被返回给用户

优点：返回的数据和数据排名都是准确的

缺点：性能较差

文档增删改和搜索的请求过程

增删改流程

客户端首先会选择一个节点发送请求过去，这个节点可能是协调节点
协调节点会对document数据进行路由，将请求转发给对应的node
实际上node的primary shard会处理请求，然后将数据同步到对应的含有replica shard的node上
协调节点如果发现含有primary shard的节点和含有replica shard的节点的符合要求的数量后，就会将响应结果返回给客户端

搜索流程

客户端首先会选择一个节点发送请求获取，这个节点可能是协调节点
协调节点将搜索请求转发到所有shard对应的primary shard或replica shard都可以
query phase：每个shard将自己搜索结果的元数据发到请求节点（doc id和打分信息），由请求节点进行数据的合并、排序、分页等操作，产出最后结果
fetch phase：请求节点根据doc id去各个节点上拉取实际的document数据，最终返回给客户端。

排序详解

说到排序，我们必须要说Doc Values这个东西。那么Doc Values是什么呢？又有什么作用？

我们都知道ES之所以那么快速，归功于他的倒排索引的设计，然而他也不是万能的，倒排索引的检索性能是非常快的，但是在字段值排序时却不是理想的结构。

如上表可以看出，他只有词对应的doc，但是并不知道每一个doc中的内容，那么如果想要排序的话每一个doc都去获取一次文档内容岂不非常耗时？Doc Values的出现就是解决这个问题。

Doc Values是可以根据doc_values属性进行配置的，默认为true。当配置为false时，无法基于该字段排序、聚合、在脚本中访问字段值。

Doc Values是转置倒排索引和正排索引的关系来解决这个问题。倒排索引将词项映射到包含它们的文档，Doc Values将文档映射到它们包含的词项：

当数据被转置后，想要收集到每个文档行，获取所有的词项就比较简单了。所以搜索使用倒排索引查找文档，聚合操作和排序就要使用Doc Values里面的数据。

深入理解Doc Values

Doc Values是在索引时与倒排索引同时生成。也就是说Doc Values和倒排索引一样，基于Segement生成并且是不可变的。同时Doc Values和倒排索引一样序列化到磁盘，这样对性能和扩展性有很大帮助。

Doc Values通过序列化把数据结构持久化到磁盘，我们可以充分利用操作系统的内存，而不是JVM的Heap。当workingset远小于系统的可用内存，系统会自动将Doc Values保存在内存中，使得其读写十分高速；不过，当其远大于可用内存时，操作系统会自动把Doc Values写入磁盘。很显然，这样性能会比在内存中差很多，但是它的大小就不再局限于服务器的内存了。如果是使用JVM的Heap来实现是因为容易OutOfMemory导致程序崩溃了。

禁用Doc Values

Doc Values默认对所有字段启用，除了analyzed strings。也就是说所有的数字、地理坐标、日志、IP和不分析字符类型都会默认开启。

analyzed strings暂时不能使用Doc Values，因为分析后会生成大量的Token，这样非常影响性能。虽然Doc Values非常好用，但是如果你存储的数据确实不需要这个特性，就不如禁用他，这样不仅节省磁盘空间，也许会提升索引的速度。

要禁用Doc Values，在mapping设置即可。示例：

      PUT my_index
{
 "mappings": {
    "properties": {
      "session_id": {
        "type": "keyword",
        "doc_values": false
      }
    }
 }
}

Filter过滤机制剖析

在倒排索引中查找搜索串，获取docment list

如下面这个例子，需要过滤date为2020-02-02的数据，去倒排索引中查找，发现2020-02-02对应的document list是doc2、doc3.

Filter为每个倒排索引中搜索到的结果，构建一个bitset

如上面的例子，根据document list，构建的bitset是[0,1,1]，1代表匹配，0代表不匹配

多个过滤条件时，遍历每个过滤条件对应的bitset，优先从最稀疏的开始搜索，查找满足所有条件的document。

另外多个过滤条件时，先过滤比较稀疏的条件，能先过滤掉尽可能多的数据。

caching bitset，跟踪query，在最近256个query中超过一定次数的过滤条件，缓存其bitset。对于小的segment（记录数小于1000或小于总大小3%），不缓存。
如果document有新增或修改，那么cached bitset会被自动更新
filter大部分情况下，在query之前执行，先尽量过滤尽可能多的数据

控制搜索精准度

基于boost的权重控制

考虑如下场景：
我们搜索帖子，搜索标题包含java或spark或Hadoop或elasticsearch。但是需要优先输出包含java的，再输出spark的的，再输出Hadoop的，最后输出elasticsearch。

我们先看如果不考虑优先级时怎么搜索：

      GET /article/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "term": {
            "title": {
              "value": "java"
            }
          }
        },
        {
          "term": {
            "title": {
              "value": "elasticsearch"
            }
          }
        },
       .....省略
      ]
    }
  }
}

搜索出来的结果跟我们想要的顺序不一致，那么我们下一步加权重。增加boost

      GET /article/_search
{
  "query": {
    "bool": {
      "should": [
        {
          "term": {
            "title": {
              "value": "java",
              "boost": 5
            }
          }
        },
        {
          "term": {
            "title": {
              "value": "spark",
              "boost": 4
            }
          }
        }
      ]
    }
  }
}

基于dis_max的策略控制

dix_max想要解决的是：
如果我们想要某一个filed中匹配到尽可能多的关键词的被排在前面，而不是在多个filed中重复出现相同的词语的排在前面。

举例说明：

对于一个文档会将title匹配到的分数和content匹配到的分数相加。所以doc id为2的文档的分数比doc id为4的大。

dis_max查询：

      GET /article/_search
{
  "query": {
    "dis_max": {
      "queries": [
        {"match": {"title": "java"}},
        {"match":{"content":"java solution"}}  
        
        ]
    }
  }
}

查询到的结果如下：

      {
  "took" : 6,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : 1.4905943,
    "hits" : [
      {
        "_index" : "article",
        "_type" : "_doc",
        "_id" : "4",
        "_score" : 1.4905943,
        "_source" : {
          "title" : "spark",
          "content" : "spark is best big data solution based on scala,an programming language similar to java"
        }
      },
      {
        "_index" : "article",
        "_type" : "_doc",
        "_id" : "2",
        "_score" : 1.2039728,
        "_source" : {
          "title" : "java",
          "content" : "i think java is the best programming language"
        }
      }
    ]
  }
}

基于function_score自定义相关度分数

在用ES进行搜索时，搜索结果默认会以文档的相关度进行排序，而这个"文档的相关度"，是可以通过function_score自定义的。

function_score提供了几种类型的得分函数：

script_score
weight
random_score
field_value_factor
decay functions:gauss、linear、exp

random_score

随机打分，也就是每次查询出来的排序都不一样。

举一个例子：

      GET /article/_search
{
  "query": {
    "function_score": {
      "query": {"match_all": {}},
       "random_score": {}
    }
  }
}

field_value_factor

该函数可以根据文档中的字段来计算分数。

示例：

      GET /item/_search
{
  "query": {
    "function_score": {
      "field_value_factor": {
        "field": "price",
        "factor": 1.2,
        "modifier": "none"
      }
    }
  }
}

属性	说明
field	要从文档中提取的字段
factor	字段值乘以的值，默认为1
modifier	应用于字段值的修复符

modifier的取值有如下多种：

Modifier	说明
none	不要对字段值应用任何乘数
log	取字段值的常用对数。因为此函数将返回负值并在0到1之间的值上使用时导致错误，所以建议改用log1p
log1p	将字段值上加1并取对数
log2p	将字段值上加2并取对数
ln	取字段值的自然对数。因为此函数将返回负值并在0到1之间的值上使用时引起错误，所以建议改用 ln1p
ln1p	将1加到字段值上并取自然对数
ln2p	将2加到字段值上并取自然对数
square	对字段值求平方
sqrt	取字段值的平方根
reciprocal	交换字段值，与1 / x相同，其中x是字段的值

field_value_score函数产生的分数必须为非负数，否则将引发错误。如果在0到1之间的值上使用log和ln修饰符将产生负值。请确保使用范围过滤器限制该字段的值以避免这种情况，或者使用log1p和ln1p

分页性能问题

在ES中我们一般采用的分页方式是from+size的形式，当数据量比较大时，Es会对分页作出限制，因为此时性能消耗很大。

举个例子：一个索引分10个shards，然后一个搜索请求，from=990,size=10。
此时es会从每个shards上去查询1000条数据，尽管每条数据只有_doc_id和_score，但是经不住它量大啊。如果from是10000呢？就更加耗费资源了。

解决方案

1. 利用scroll遍历

scroll分为初始化和遍历两步。

步骤1：

      POST /item/_search?scroll=1m&size=2
{
  "query": { "match_all": {}}
}

步骤2：

      GET /_search/scroll 
{
"scroll": "1m",
"scroll_id" : "步骤1中查询出的值"
}

2. search after方式

在ES 5.x后提供的一种，根据上一页的最后一条数据来确定下一页的位置的方式。如果分页请求的过程中，有数据的增删改，也会实时的反映到游标上。这种方式依赖上一页的数据，所以不能跳页。

步骤1：

      GET /item/_search
{
  "query": {
    "match_all": {}
  },
  "size": 2
  ,"sort": [
    {
      "_id": {
        "order": "desc"
      }
    }
  ]
}

查询结果：

      {
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 6,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [
      {
        "_index" : "item",
        "_type" : "_doc",
        "_id" : "uL6choEB9TD2fYkcrziw",
        "_score" : null,
        "_source" : {
          "title" : "小米8手机",
          "images" : "http://image.lagou.com/12479122.jpg",
          "price" : 2688,
          "createTime" : "2022-02-02 12:02:02"
        },
        "sort" : [
          "uL6choEB9TD2fYkcrziw"
        ]
      },
      {
        "_index" : "item",
        "_type" : "_doc",
        "_id" : "tr6YgYEB9TD2fYkcFzjY",
        "_score" : null,
        "_source" : {
          "title" : "小米手机",
          "images" : "http://image.lagou.com/12479122.jpg",
          "price" : 2688,
          "createTime" : "2022-02-01 12:02:02"
        },
        "sort" : [
          "tr6YgYEB9TD2fYkcFzjY"
        ]
      }
    ]
  }
}

步骤2：

      GET /item/_search
{
  "query": {
    "match_all": {}
  },
  "size": 2,
  "search_after":["tr6YgYEB9TD2fYkcFzjY"]
  ,"sort": [
    {
      "_id": {
        "order": "desc"
      }
    }
  ]
}

总结对比：

分页方式	性能	优点	缺点	场景
from + size	低	灵活性好，实现简单	深度分页问题	数据量比较小，能容忍深度分页问题
scroll	中	解决了深度分页问题	无法反映数据的实时性（快照版本）维护成本高，需要维护一个scroll_id	海量数据的导出需要查询海量结果集的数据
search_after	高	性能最好	不存在深度分页问题能够反映数据的实时变更实现连续分页的实现会比较复杂，因为每一次查询都需要上次查询的结果	海量数据的分页

数据库内核的快照技术实现原理 - 吴祖洋的技术博客

Sun, 05 Jun 2022 21:04:18 CST

"快照(Snapshot)"是数据库领域非常重要的一个概念, 最初是用于数据备份. 如今, 快照技术已经成为数据库内核(引擎)最核心的技术特性之一. 数据库内核的绝大多数操作, 都依赖于快照, 例如, LevelDB的每一次读取操作和遍历操作, 其内部都必须创建一个快照, 所以, 对于一个请求量非常大的系统, 数据库内核每秒种就要创建和销毁几十万次快照. 因此, 如何快速地创建和销毁快照, 成为一个数据库内核(引擎)必须要解决的问题.

本文从源头出发, 逐步推演, 探讨数据库内核是如何实现快照技术的. 数据库内核创建快照, 将使用如下技术:

全量拷贝(Full Clone)
写时拷贝(Copy On Write)
分区拷贝(Partitioning)
多版本(Multi Versioning, Leveling, Zero Copy)

无论何种实现快照的技术, 数据拷贝都不可避免, 差异点主要是不同的技术拷贝的数据量不同, 以及拷贝的数据含义不同(直接拷贝和间接拷贝). 直接拷贝意味着拷贝数据本身, 间接拷贝则拷贝数据的"指针".

拷贝意味着 互斥, 独占, 加锁, 因为拷贝需要保证数据的完整性. 硬盘数据拷贝速度是较慢的, 往往被认为不可接受, 应极力避免. 内存数据拷贝速度较快, 但仍然需要减少拷贝的数据量.

1: 全量拷贝(Full Clone)

全量拷贝技术是创建快照最本能的实现方法, 也是最低效的方法. 因为数据量往往非常多, 而且还常常在硬盘上, 拷贝成本高, 耗时长. 在进行全量拷贝的过程中, 需要排斥写操作, 所以数据库系统是无法提供写服务的.

2: 写时拷贝(Copy On Write)

全量拷贝低效速度慢, 那么, 一个可能的优化方向是在某些不需要拷贝的场景不做任何拷贝. 在某些场景, 例如读请求, 虽然需要创建一个快照并且去读快照, 但是, 读操作并不会修改快照数据和原来的数据, 如果这时整个系统也正好没有任何写操作请求, 那么, 就没有必要做全量拷贝.

同时, 为了应对某个时刻收到写操作请求, 需要随时做准备, 一旦有写操作请求时, 再做一次全量拷贝. 写时拷贝技术是一种 概率优化技术, 不像纯朴想法所认为地去优化全量拷贝本身的性能.

概率优化是一种 外部优化, 依赖于实际使用场景的概率分布, 在遇到 bad cases 时, 因为内部依然非常慢, 所以在 bad cases 场景不起作用. 所以, 仅仅写时拷贝技术并不能从根本上解决问题.

写时拷贝的关键是引入一个 单点标记和额外的一步 必要操作路径(单点), 所有的请求都必须走这条路径, 这样才能截获写操作请求, 在写操作请求之前进行数据拷贝.

3: 分区拷贝(Partitioning)

分区(Partitioning)技术是计算机领域非常重要的技术思想, 有点像"分而治之"思想, 和"并发"技术是统一的. 因为无论针对快照或是原始数据的修改, 在操作过程期间往往只修改很小的一个比例, 例如一个拥有一百万行记录的数据库表, 在创建完快照和销毁快照这段时间内, 也许只修改了两三行记录, 没有必要拷贝整个表.

分区拷贝将数据拆分为多个部分(Partition), 结合 Copy On Write 技术, 在有必要的时候, 才拷贝被修改的那部分数据. Partitioning 技术在计算机领域应用非常广泛, 像我们常说的"减小锁粒度", "分布式数据库 Sharding", "并发"等等, 这些都是 Partitioning.

4: 多版本(Multi Versioning)

多版本技术抛弃了纯朴观念里的"修改"一词, 当想要修改某项数据时, 只是简单地写新数据写到其它地方, 暂时不管旧数据是怎么样的. 然后, 引入一个成本极小的标记, 修改数据的指向(也即将旧数据标记为作废, 将新数据标记为有效). 这个标记和前文介绍写时拷贝技术时提到的"必要路径"是一个意思.

基于多版本技术, 创建快照时不再拷贝任何原始数据(Zero Copy), 只有成本极小的对标记的修改操作, 所以, 无论数据是在内存还是在极慢的硬盘里, 都不影响创建快照的速度. 如果这个标记是放在内存中的, 那么, 针对1TB的数据库每秒创建百万个快照也没有问题.

不过, 多版本技术也有缺点. 它虽然不影响创建快照的速度, 也很少影响写操作的速度, 但是, 它严重影响读操作的性能, 因为我们必须读取全部的版本出来, 才能知道哪个版本是我们需要的, 版本越多, 性能就越差. 所以, 使用多版本技术时, 都要结合 垃圾回收(GC)技术, 尽快删除不需要的版本.

和分区技术不同, 多版本技术的不同版本是指同一个对象, 不是独立的, 可以把版本理解为层(Level), 最终多个层合并(Merge), 形成最终的对象数据. 而分区是独立的, 不需要合并, 只需要连接(Chain)起来.

在实践中, 多版本技术往往要通过扩大数据对象的粒度来减少版本数量.

房地产行业数字化_david_lv的博客-CSDN博客

Tue, 31 May 2022 14:06:18 CST

（1）中国产业演变与数字化

上周六，一个做地产SaaS的朋友问我，信息化和数字化到底有啥区别？我就给他拿地产行业管理系统举实例给他讲。

我说，数字化的兴起有个大背景，那就是：

1、互联网的普及：数字营销、在线协同

2、电子商务的普及：在线B2C/在线B2B、在线银行/企业支付、在线税务/电子发票

3、新技术的普及：社会化大数据、人工智能、IoT物联网

中国在B2C电子商务方面很发达，但是在B2B电子商务方面不发达。这本质和中国的全球产业分工相关。

日本和美国从1970年代开始打贸易战，一路打到电信战、汽车战、芯片战、金融战，在1985年最终签订《广场协议》，日本因广场协议因成本，产品被逼转移到东南亚和亚洲四小龙，在1991年苏联解体冷战结束全球大融合之后又转移到中国大陆。日本在1992年开始股市下跌50%，地产下跌50%，日本宣布以人工智能为核心的自主可控第五代计算机体系研发失败。1997年，转移到东南亚和四小龙的日本产业，遭受美国金融巨鳄索罗斯引发的亚洲金融危机，日本海外产业损失折半，日本开始进入失去的二十年。日本开始放弃最终产品，退居到技术门槛高、利润丰厚的上游核心原材料、核心零部件、精密生产设备，日本企业管理从戴明环质量管理持续改善，转移到全球供应链投资和整合运营管理、产品全生命周期质量管理。

中国目前的产业还处于最终消费品的生产。等中国的产品层次往高端装备设备产品走，等中国的产业环节从集成制造往上游核心零部件走转移的时候，中国的企业对企业业务、B2B电子商务，才能兴旺发达。我预计这个时间是2025年以后，估计是2028年。离现在还有5-6年。

（2）以地产数字化实例来说明

我给我朋友画了一张图：

作为地产管理系统，一般有：采购招投标系统、建造项目管理系统、销售管理系统、物业管理系统、成本核算系统...。过去都是：表单录入、审批工作流引擎、查询统计。那是典型的信息化：在线下完成事情，然后录入到IT系统中。

现在有了互联网、电子商务的普及，有了新技术的普及，就可以探索在线上直接完成业务，数据就自动沉淀下来。

设计环节，可以借助互联网，搞社会化在线协同，让设计院、业主方、建筑方在线协同。可以借助社会化数据大融合，来快速生成自己的设计模板。可以借助智能硬件ARMR，快速进行3D仿真体验。

在采购招投标环节，可以借助互联网来公开招标，可以借助电子商务来做在线投标、在线保证金订金支付，可以借助电子证照做在线资质审验，可以借助社会化大数据融合来引据采购项、采购成本、采购条款，而不需要自己从零录入、自己凭经验拍脑门制定。过去IT厂商提供的软件就是个空壳子的软件，现在IT厂商提供的SaaS云服务，里面是含有持续不断加工训练的主数据、模板、模型。

在建造项目管理环节，可以借助互联网搞社会化协同，把设计院、业主方、施工方、监理方、项目管理方，乃至监管方住建委、消防、安监局都卷入进来，进行在线资料报送、在线审批、在线监管。

在现场管理环节，可以借助电子证照来自动识别、人脸自动识别。可以使用传感器、RFID、二维码、GPS定位、摄像头拍照与监控等等技术手段，来搞：现场施工人员安全监控、施工设备安全监控、现场物料安全监控。

其他的我就不一一赘述了。大家继续多琢磨我那张图自行理解。

（3）最后

我过去说过三个理论：

数字化要点：以机器为主以人为辅
数字化企业的特征：网络连接、数据智能
产业互联网特征：在线业务处理、社会化资源、社会化数据服务、智能调度

很多人看完我上述讲的房地产行业数字化的案例，大多不以为然。觉得这有什么啊，这有什么啊，仍然看不出来数字化和信息化的区别。唉，这就跟我过去干零售业和电子商务业时遇到的问题一样了。我过去参加过一个群，里面都是国内知名零售企业的高管，他们就对电子商务嗤之以鼻，他们认为中国电子商务之流，别看现在蹦跶的欢，其实就是因为电商会融资烧钱、电商会玩网络营销拉流量。等退潮了，还不抵谁没穿裤衩呢。所以这些中国知名零售商的高管们，都在等着看中国电商们的笑话。

中国知名零售商，他们把电子商务仅仅看做是企业的通路之一。可以线下官方旗舰店直营、可以线下分销、可以线上官方旗舰店直营，不就是通路之一么，电子商务有啥大不了的。

而他们却忽略了电子商务的天然先进性，我过去已经说过一万遍的电子商务的天然先进性：

1、互联网：天生是具有网状、垄断性

2、直Hold顾客、最短价值链：消费者-电子商务零售商-商品制造商

3、最大人效：不用销售人员和促销人员，顾客自助挑选自助下单自助支付。而且24x7营业

4、最大坪效：通过信息流滚动、千人千面、搜索、实时关联推荐，可以做到无限坪效

5、持续改善：低成本高效率的实时用户行为全过程跟踪，可以持续改进经营

6、后台大规模作业：自动化大型仓储、智能化仓储调度、智能化物流调度

我想，过去做信息化的那帮人，看数字化，也和零售人看电子商务一个思维。这有什么呀，这有什么呀。

稳态和敏态_david_lv的博客-CSDN博客

Tue, 17 May 2022 19:03:30 CST

（1）不稳定环境-敏态

很多人说：

信息化是以流程为中心、以功能为中心

数字化是以场景为中心、以数据为中心

这都是堆词，玩中文文字游戏。

如果让我再列举，我还会列举几十条。堆呗，谁不会堆啊。

很多人也不明白现在为啥流行那么多新技术：低代码开发平台、RPA、微服务架构、大数据平台...。

很多中国企业说我们要微服务，我们要大数据平台。很多中国IT厂商也说自己就是微服务架构，就是大数据平台。但是甲乙双方都不清楚自己为啥需要微服务、为啥需要大数据平台。到底要解决自己啥问题？这些微服务架构技术和大数据平台技术，是否真的能解决自己的问题？全一问三不知。反正就是：有钱、需要。人傻钱多速来。

只有透过表象才知道这么多表象的关联关系。我随手给大家画了一张图。

我画完这张图，大家这一下子就明白了这几年横出一道竖出一道新东西，到底是为啥了吧。这就叫逻辑。

（2）稳定环境-稳态

对于大部分央企国企来说：不求无功但求无过，只要国有资产增值保值就好。

他们只需要做好集团统一管控，永续经营就好。

中国企业，不管是民企还是国企，都不太注重运营管理，也不设首席运营官COO。所以大部分人也不知道啥叫运营管理。只是嘴里喊着运营管理运营管理，但运营管理为何物，其实一问三不知。

我给大家介绍两本上世纪六十年代的书。大家看完这两本书就知道啥叫运营管理了，而且知道了运营管理这个体系是怎么一点点发展起来的。

我知道，很多人，我给他推荐了书也不爱看书。所以我给大家随手又画了一张图，把运营管理的核心都一张图看明白：

这就是运营管理的四个核心方面。其实这和咱们说的管理约束三角一样：效率、质量、成本。只不过外国人更注重计划，而中国人根本不注重计划。

那很多朋友问了，那稳态企业到底需要啥信息化呢？

我跟大家说，还是二十年前老需求：统一管控四大方面：统一财务管控、统一人力管控、统一流程管控、统一数据管控。

怎么搞？我仍然给大家随手再画一张图，一图胜千言嘛。其实这些东西，我这二十多年已经说过无数遍（应该超过一万遍了吧）。

数字化转型，我只推荐看这两本书_david_lv的博客-CSDN博客

Mon, 25 Apr 2022 19:44:37 CST

信息化这个词是日本人梅棹昭夫在1960年代发明的一个词，后来在1970年代传到西方。其实西方并不用信息化这个词，西方一直用数字化这个词。

数字化转型李鬼太多了，可推荐的书不多。截止到目前位置，我能推荐的书目只有两本：

1、一本是比尔盖茨在1999年写的《未来时速》，虽然过去了20多年，但里面关于数字化转型的真知灼见仍然有效

2、一本是曾鸣教授在2018年写的《智能商业》，虽然过去了4年多，但里面对企业通过社会化智能化的方式来一步步做数字化转型的路径有最佳的建议

《未来时速》这本书写于1999年，背景相关信息：

1998年，Google创办
1997年，SaaS ERP公司NetSuite创办。1999年，SaaS CRM公司Salesforce创办
1997年，Amazon和Yahoo公司上市
1996年，《数字化生存》和《失控》这两本书已经出版。如果有人还想对数字化有更多体会和理解，我推荐大家读读这两本20多年前的书

其实《未来时速》这本书的英文名叫：business@ the speed of thought using a digital nervous system，意思就是通过数字神经系统来提高商业速度。

这本书有个好处就是每一章都用一个鲜活的案例来展示数字化系统的威力。这些鲜活的数字化场景包含：

通用汽车：制造商-经销商
微软：微软-经销商-促销活动
微软：微软-招聘网站-商旅网站-员工福利保险网站
德国银行：银行在线-客户自助
美林证券：美林在线-客户自助
万豪酒店：万豪在线-客户自助
通用汽车：SCADA系统-检测员
微软：社会化用工系统-临时合同工
儿童医院：CareVision系统-急救中心-医院-康复中心-保险公司
政府：政府在线服务-居民
海军陆战队：数字地图+GPS实时定位
西部高地学区：学校-学生-家长

比尔盖茨举的例子，都涉及到多个利益主体，这些利益主体都不在一个企业组织内部。但是这些利益主体都通过一套中央数据库+软件+互联网络，进行业务协作处理。你根据这些鲜活的案例，你也能体会到啥叫数字化转型。

也就是说，美国的数字化转型是从上世纪90年代就开始了。背景就是互联网可以把多个利益主体协同在一起了。

第一章、用事实的力量管理企业

案例：通用汽车

斯洛恩在1923-1956期间担任通用汽车的CEO时，建立了一套信息神经网络系统。

用的是人工打电话的形式来采集数据，用纸张的形式来存储数据。有一个专门的团队来进行数据采集、记录、统计。

这套信息神经网络系统，帮助斯洛恩把通用汽车的技术人员-销售人员-经销商的各种信息，包含运营计划、订单信息、销售分析预测、库存信息、维修技术信息，全都采集了过来。

而且斯洛恩把这套信息体系全都做了标准化，方便各种维度的汇总统计和横向对比。

第二章、数字神经系统能办到吗？

案例：微软

微软的MS Sales系统是帕克搞出来的。里面有：

每个城市每家大公司平均雇员人数、每个城市的PC拥有量信息、微软市场份额分析

每个城市的发布会/促销活动信息

每个经销商每个产品的销售信息、推销员报酬信息

供应链管理信息

结算信息、预算信息

这些信息用SQLServer中央数据库存储，用EXCEL数据透视表做分析。

第三章、创建无纸办公室

案例：微软人力资源

盖茨用一个微软假想员工来举例说明：

从web官方上采集应聘者简历

使用招聘管理软件来安排求职面试日程

使用入职管理软件来安排办公室工位、邮箱、办公工具

使用Payroll软件来让员工自助查询与管理他的薪资情况

使用商旅报销费控软件来让员工自助预订飞机和宾馆，以及经理审批、报销金额自动转入员工银行卡内

使用员工福利软件来申请带薪休假、生育医疗报销、员工体检、员工保险

使用股票期权软件来管理员工的股票期权买入

使用绩效评价软件来对员工的业绩做评价

第四章、乘上转折火箭

案例：德国银行

盖茨鼓励德国银行要采取网上银行。因为美国一半家庭已经拥有电脑，大学生几乎每个人都有一个自己的电子邮箱账号，在美国网上买书买唱片网上订机票订酒店、网上电子账单已经是很普遍的事情了。

让消费者在网上自助完成服务将成为未来五年的趋势。

第五章、中间商必须增加价值

案例：美林证券

美林证券准备花费5年时间、投资8.25亿美元，做一套客户可以在线访问的财富管理系统（美林在线）：

客户能够在线自助访问

信息和功能要按照客户场景来重新组织

要有良好的客户体验

美林证券本来想的是一年发展20万注册客户，但是没想到7个月就达到了这个目标。

而美林证券的财富管理顾问，现在终于可以后台的用户行为数据来个性化为客户制定他的财富投资计划。

第六章、接触顾客

案例：戴尔电脑、万豪酒店

戴尔公司在2000年前后，50%的销售订单已经来自戴尔官网电子商务商城。

并且，戴尔公司通过在线支持，减少了50%的电话呼叫中心支持。

万豪酒店也开通了在线酒店预订，而且还分了商务旅行者、休闲旅行社、会议规划者三个场景。万豪酒店还整合了每个酒店周边的餐饮、旅游景点、路线图等信息，方便商务旅行者、休闲旅行社、会议规划者用于相关性决策。

万豪酒店还开通了消费者留言评价功能。

第八章、改变企业的边界

案例：无

场景：社会化自由工作，用互联网做协作

社会化自由工作：

过去是个体创造型知识者：作家、艺术家、演员

后来是小团队知识者：律师、会计师、医师、工程师

现在是项目型知识者：电影拍摄、广告制作

用互联网做协作：电子邮件、网络会议、电子文档

第十一章、把坏消息转化为好消息

案例：普罗米斯连锁酒店

普罗米斯酒店建立了客户数据库，里面有客户所有过往在各个酒店的入住记录，还有所有的投诉信息。而且还分析了客户行为，如喜欢订双床房、喜欢特殊枕头、喜欢安静、喜欢吸烟等等。

如果一个客户突然不去普罗米斯连锁酒店中的任何一家店了，普罗米斯连锁酒店会自动发送一份邀请函。

第十六章、挖掘使人增强力量的过程

案例：通用汽车萨杜恩品牌公司

萨杜恩品牌公司有8500名员工，但都分成大约15人规模的小组。一个小组可以雇佣自己的组员，并有权解雇一个总是迟到或干活差劲的组员。小组报酬的20%和销量、质量、客户满意度相关。

萨杜恩品牌公司有一套SCADA系统，管理着组装工厂。它监测着12万多个独立的数据点，每个装置至少每秒检查一遍。调度员可以在一个屏幕上看到工厂里所有实际运行过程。

检验员通过无线联网的WinCE手持电脑，配合中央数据库中的信息，结合EXCEL表格，还有汽车三维图，就可以对一台车做逐项的质量检验。

第十七章、信息技术使业务流程优化成为可能

案例：微软

微软有HeadTrax软件来管理临时用工的招聘、签合同、工时计算、薪资核算。也关联着发放进门卡、电话开通、上网开通、电子邮件开通等事宜。当临时合同终止时，这些开通会自动失效。

HeadTrax把业务部门-人事部门-行政部门-财务部门自动串联了起来。

第十九章、医疗：任何保健系统都不是孤立的

案例：微软员工

病历和账单需要信息化，并且联网共享，以便急救中心-医院-保险公司-康复医院，不用重复做工作。

CareVision系统，是健康梦幻公司开发的一套患者信息管理软件，医院给患者做的每一次治疗、检测、用药、医疗，都输入到该软件中，信息存储在一个中央大数据库中。因此这套软件还能判断最佳治疗方案、用药配伍禁忌，最佳急救疗法、最佳护理方法。

第二十章、政府：使政府贴近人民

案例：无

政府采购：在线招投标

政府服务：在线服务、居民电子身份密钥智能卡

政府文档：电子文档

第二十一章、军队：应变能力：生死攸关的问题

案例：美国海军陆战队

GPS定位、高精度卫星数字地图，关联气象信息，制定飞行计划

第二十二章、教育：创建一体化的学习社区

案例：西部高地学区

一、多媒体教学和远程辅导

获取信息：通过互联网获取新闻，PPT展示内容

查阅资料：电子图书馆，可通过互联网络访问

远程辅导：发家庭电子作业/收家庭作业/判作业、在线辅导/在线问答

二、家校互动

通过网页，让家长了解每周课程安排、教学老师、教学方法、家庭作业

Oracle RAC的VIP和SCAN IP - 学海无涯2020 - 博客园

Wed, 20 Apr 2022 13:58:27 CST

我们都知道Oracle RAC中每个节点都有一个虚拟IP，简称VIP，与公网IP在同一个网段。

没有VIP时，Oracle客户端是靠“TCP/IP协议栈超时”来判断服务器故障。而TCP/IP协议栈是作为OS Kernel的一部分来实现，不同的OS有不同的阀值，用户获悉数据库异常的时间完全取决于OS Kernel的实现，虽然有些OS允许修改这个阀值，但是会对其它程序产生未知影响。因此，oracle RAC引入了VIP，从而避开对TCP协议栈超时的依赖。

VIP和IP最主要的不同之处在于：VIP是浮动的，而IP是固定的。在所有节点都正常运行时，每个节点的VIP会被分配到public NIC上；在linux下ifconfig查看，public网卡上是2个IP地址；如果一个节点宕机，这个节点的VIP会被转移到还在运行的节点上。也就是幸存的节点的public NIC这个网卡上，会有3个IP地址。

当一个节点宕机，这个节点真实IP就连接不上了，但是这个节点的虚拟IP是可以连接的，他会自动把客户端的连接请求转接给存活的节点。
在tnsname.ora文件里，指定Address列表，客户端会随机选择一个节点来连接数据库，而不是顺序选择的。

VIP特点：
1 VIP是在clusterware安装最后阶段，通过脚本VIPCA创建的；
2 VIP作为一个Nodeapps类型的CRS Resource注册到OCR中，并由CRS维护状态；
3 VIP会绑定到节点的public 网卡上；那么public网卡就有两个地址了；
4 当某个节点发生故障时，CRS会把故障节点的VIP转移到其他节点上；
5 每个节点的Listener会同时在public网卡的public IP和VIP两个地址上监听；
6 客户端的tnsname.ora一般会配置指向节点的VIP；

从上面第6条可以引出一个问题。如果增加一个节点，那么客户端的tnsname.ora需要加入新增节点的VIP。那么想象一下：多个客户端，增加多个节点，那么维护起来特别麻烦。因此到了Oracle11gR2，引入了一个scan的概念。

    scan,single client access name。简单客户端连接名，这是一个唯一的名称，在整个公司网络内部唯一，并且在DNS中可以解析为三个ip地址，客户端连接的时候只需要知道这个名称，并连接即可，每个SCAN VIP对应一个scan listener，cluster内部的service在每个scan listener上都有注册，scan listener接受客户端的请求，并foward到不同的Local listener中去，还是由local 的listener提供服务给客户端。

    注意：scan不一定要resolve到三个ip，一个也够了。只不过为了防止scan单点故障而推荐3个。

Oracle RAC JDBC connection string - multitude - 博客园

Sun, 17 Apr 2022 21:44:24 CST

完全正确

https://stackoverflow.com/questions/1646630/what-is-the-correct-jdbc-url-to-connect-to-a-rac-database

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=OFF)(FAILOVER=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=tst-db1.myco.com)(PORT=1604))
(ADDRESS=(PROTOCOL=TCP)(HOST=tst-db2.myco.com)(PORT=1604)))
(CONNECT_DATA=(SERVICE_NAME=mydb1.myco.com)(SERVER=DEDICATED)))

官方文档, 一如既往地冗长, 可靠

https://docs.oracle.com/database/121/HABPT/config_fcf.htm#HABPT5381

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource"); pds.setUser("system"); 
 pds.setPassword("oracle"); 
 String dbURL = 
 "jdbc:oracle:thin:@" + 
 "(DESCRIPTION=" + 
"(FAILOVER=on)" + 
 "(ADDRESS_LIST=" + 
 "(LOAD_BALANCE=on)" + 
 "(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" +
 "(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))"+     "(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" + 
 "(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))" 
 System.out.println("Url=" + dbURL); 
 pds.setURL(dbURL);

"jdbc:oracle:thin:@" + 
 "(DESCRIPTION=" + 
"(FAILOVER=on)" + 
 "(ADDRESS_LIST=" + 
 "(LOAD_BALANCE=on)" + 
 "(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" +
 "(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))"+     "(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" + 
 "(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))"

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource"); pds.setUser("system"); 
 pds.setPassword("oracle"); 
 String dbURL = 
 "jdbc:oracle:thin:@" + 
 "(DESCRIPTION_LIST=" + 
 "(LOAD_BALANCE=off)" + 
 "(FAILOVER=on)" + 
 "(DESCRIPTION=" +
 "(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" +
 "(ADDRESS_LIST=" + 
 "(LOAD_BALANCE=on)" + 
 "(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))" + 
 "(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))" + 
 "(DESCRIPTION=" + 
 "(ADDRESS_LIST=" + 
 "(LOAD_BALANCE=on)" + 
 "(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" + 
 "(CONNECT_DATA=(SERVICE_NAME=oltpworkload))))"; 
 System.out.println("Url=" + dbURL); 
 pds.setURL(dbURL);

这个第三方总结很简单, 看样子是第三方驱动厂商

https://support.tibco.com/s/article/JDBC-dbURL-when-using-failover-servers-with-Oracle

Resolution

When creating the bootstrap use the following formats for the JDBC connection string.

Case 1: When using tibcosoftwareinc.jdbc.oracle.OracleDriver driver (Oracle (DataDirect)), JDBC URL field should contain:

jdbc:tibcosoftwareinc:oracle://<myhost1>:<myport1>SID=<myservice1>AlternateServers=(<myhost2>:<myport2>SID=<myservice2>)

Example URL:

jdbc:tibcosoftwareinc:oracle://host1:1521;ServiceName=orcl;AlternateServers=(host2:1521)

Case 2: When using oracle.jdbc.driver.OracleDriver (the native driver form Oracle), the JDBC URL field should contain:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<myhost1>)(PORT=<myport1>))(SERVICE_NAME=<myservice1>))(ADDRESS=(PROTOCOL=TCP)(HOST=<myhost2>)(PORT=<myport2>))(LOAD_BALANCE=yes)(CONNECT_DATA=(SERVICE_NAME=<myservice2>)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180))))

Example URL:

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=host2) (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))

See more information in Oracle's documentation.

Reference

Oracle documentation: Configuring Fast Connection Failover for JDBC Clients

使用 React 和 Next.js 构建博客

Mon, 11 Apr 2022 16:27:03 CST

Next.js是由 Vercel 创建和维护的基于 React 的应用程序框架。本教程将从零开始学习如何使用 Next.js构建一个小型的博客网站：

基本页面创建
从 Markdown文件生成的动态路由
静态生成（在构建时渲染）
服务器端渲染（在请求时渲染）

文章涉及的代码仓库地址： https://github.com/QuintionTang/react-blog

Next.js 适合博客吗？

本教程将通过创建一个简单的博客来展示 Next.js功能，那么 Next.js适合这样的博客的开发吗？先来了解一下一般博客都需要什么？

WordPress是一个内容管理系统 (CMS)，它为三分之一的网站提供支持，通过在每次请求时将可编辑的数据库内容渲染到 PHP 模板中来为页面提供服务。它非常适合定期更新的内容，但性能、安全性和数据备份需要一定的自定义设置。
静态站点生成器 (SSG)，例如 Eleventy或 Gatsby创建预渲染文件，无需服务器端或数据库即可快速构建静态站点，在版本控制、性能和安全性都非常出色，但构建步骤和以开发人员为中心的过程可能会减慢发布速度，尤其是在大型网站上。

Next.js是一个基于 React 的应用程序框架，它几乎没有特定于博客功能。但是，它可以提供了一种实现机制：

在可能的情况下， Next.js生成静态内容，如 SSG，这些页面加载速度非常快，可以被搜索引擎快速收录，并且可以在任何有或没有 JavaScript 的设备上阅读。
在第一次加载后， Next.js应用程序的行为类似于单页应用程序 (SPA)，后续页面和代码会以渐进式下载，无需刷新整页。
Next.js为每个请求提供服务器端渲染 (SSR)，为个人用户提供实时 CMS 更新或自定义内容变得更加容易。

如果网站可能会从基本博客迭代为更复杂的网站，例如在线商店、新闻聚合服务、社交媒体平台等，可以考虑使用 Next.js。

开始

本教程正在构建的内容，可以在 GitHub 上找到完整的代码。可以通过在终端中输入以下命令，在 Windows、 macOS或 Linux上下载、安装和启动它：

      git clone git@github.com:QuintionTang/react-blog.git
cd react-blog
npm i
npm run dev

然后在浏览器中输入 localhost:3000打开主页。

从头开始构建

Next.js提供了一个 create-next-app工具来快速开始使用应用程序模板。本教程将展示如何从头开始构建站点：如添加静态资源或者页面。

安装 Next.js 和 React

与其他 Node.js或者 VUE 项目一样，首先创建一个目录并初始化 package.json文件：

      mkdir react-blog
cd react-blog
npm init

然后安装 Next.js和 React作为依赖项：

      npm install next react react-dom --save

添加开发构建脚本设置，如下所示，在 package.json文件的 scripts属性中添加：

      "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
}

创建第一个页面

Next.js有一个基于文件系统的路由器。在项目的 pages目录中创建的任何 React 组件文件都会自动呈现为一个页面。

要创建一个页面，需要在 pages目录中添加一个 index.js文件。将以下代码添加到 ./pages/index.js文件中，返回 JSX代码的功能性 React 组件：

      export default function Home() {
    return (
        <>
            Next.js 博客网站
            <p>
                这个博客网站将使用 <a rel="nofollow" href="https://nextjs.org/">Next.js</a>。
            </p>
        </>
    );
}

JSX 必须在单个包含元素（例如 <div>）中返回。 <> ... </>表示法定义了一个文档片段，因此不需要额外的容器。

要启动 Next.js开发服务器，从项目根目录在终端中运行 npm run dev（可以使用 npx next dev），然后在浏览器中打开 http://localhost:3000/：

Next.js已经确定页面可以预渲染，所以它在开发模式下显示一个 闪电图标。

可以在自动路由的页面目录中创建类似的文件，如下：

pages/index.js用于呈现博客主要
pages/about.js呈现一个 /about页面

增加链接

在 JSX 代码中使用标准 HTML <a>标签创建指向另一个页面的超链接。如果该页面位于同一个 Next.js站点内，浏览器将会刷新整个页面。可以使用 next/link中的 <Link>组件实现页面跳转。在根页面 /index.js上创建指向 /about页面的链接，代码如下：

      import Link from "next/link";
export default function Home() {
    return (
        <>
            Next.js 博客网站
            <p>
                这个博客网站将使用 <a rel="nofollow" href="https://nextjs.org/">Next.js</a>。
            </p>
            <p>
                更多内容请点击{" "}
                <Link href="/about">
                    <a>关于我们...</a>
                </Link>
            </p>
        </>
    );
}

当点击 关于我们...链接时， Next.js将使用 Ajax请求下载 /about的内容一次并缓存，然后再页面中呈现。

增加 <head> 元素

可以使用 next/head中的 <Head>组件来更改页面标题和元标记，如下：

      import Head from "next/head";
import Link from "next/link";
export default function Home() {
    return (
        <>
            <Head>
                <title>Next.js网站</title>
                <meta
                    name="description"
                    content="这是一个由 Next.js 驱动的网站"
                />
            </Head>
            Next.js 博客网站
            <p>
                这个博客网站将使用 <a rel="nofollow" href="https://nextjs.org/">Next.js</a>。
            </p>
            <p>
                更多内容请点击{" "}
                <Link href="/about">
                    <a>关于我们...</a>
                </Link>
            </p>
        </>
    );
}

点击浏览器查看源代码，可以看到相关 HTML 标签。

增加静态资源

public目录用于存放静态资源，如图标、 robots.txt或其它更新频率低的文件。可以增加自己的文件或从初始项目存储库复制 favicon.ico和图像子目录。

创建模板

Next.js使用 React 组件来实现模板化，接下来项目根目录下创建一个新的 components文件夹，然后添加 layout.js来定义一个新的 <Layout>组件：

      import Header from "./header";
import Footer from "./footer";

export default function Layout({ children, title }) {
    return (
        <>
            <Header title={title} />
            <main>{children}</main>
            <Footer />
        </>
    );
}

任何使用此组件的页面都会传递一个 props对象，该对象包含作为子值 children的内容。 <Layout>还将引用了另外两个组件，分别是 component/header.js中的 <Header>，主要呈现一个 <header>，包含主页链接、内联 SVG Logo和默认为 /images/header.jpg的图像：

      import Link from "next/link";

export default function Header({ title }) {
    const headerImg = "/images/" + (title || "header.jpg");

    return (
        <header>
            <p className="logo">
                <Link href="/">
                    <a>
                        <svg
                            xmlns="http://www.w3.org/2000/svg"
                            viewBox="0 0 20 20"
                            width="50"
                            height="50"
                        >
                            <path d="M10.394 2.08a1 1 0 00-.788 0l-7 3a1 1 0 000 1.84L5.25 8.051a.999.999 0 01.356-.257l4-1.714a1 1 0 11.788 1.838L7.667 9.088l1.94.831a1 1 0 00.787 0l7-3a1 1 0 000-1.838l-7-3zM3.31 9.397L5 10.12v4.102a8.969 8.969 0 00-1.05-.174 1 1 0 01-.89-.89 11.115 11.115 0 01.25-3.762zM9.3 16.573A9.026 9.026 0 007 14.935v-3.957l1.818.78a3 3 0 002.364 0l5.508-2.361a11.026 11.026 0 01.25 3.762 1 1 0 01-.89.89 8.968 8.968 0 00-5.35 2.524 1 1 0 01-1.4 0zM6 18a1 1 0 001-1v-2.065a8.935 8.935 0 00-2-.712V17a1 1 0 001 1z"></path>
                        </svg>
                        Next.js 博客
                    </a>
                </Link>
            </p>

            <figure>
                <img
                    src={headerImg}
                    height="80"
                    alt="decoration"
                />
            </figure>
        </header>
    );
}

第二个组件是 component/footer.js中的 <Footer>，呈现 <footer>内容，其中包含指向 GitHub 存储库和内联 SVG 的链接：

      export default function Footer() {
    return (
        <footer>
            <p className="github">
                <a rel="nofollow" href="https://github.com/QuintionTang/react-blog">
                    <svg
                        xmlns="http://www.w3.org/2000/svg"
                        viewBox="0 0 512 512"
                        width="50"
                        height="50"
                    >
                        <path d="M256 32C132.3 32 32 134.9 32 261.7a229.3 229.3 0 00153.2 217.9 17.6 17.6 0 003.8.4c8.3 0 11.5-6.1 11.5-11.4l-.3-39.1a102.4 102.4 0 01-22.6 2.7c-43.1 0-52.9-33.5-52.9-33.5-10.2-26.5-24.9-33.6-24.9-33.6-19.5-13.7-.1-14.1 1.4-14.1h.1c22.5 2 34.3 23.8 34.3 23.8 11.2 19.6 26.2 25.1 39.6 25.1a63 63 0 0025.6-6c2-14.8 7.8-24.9 14.2-30.7-49.7-5.8-102-25.5-102-113.5 0-25.1 8.7-45.6 23-61.6a84.6 84.6 0 012.2-60.8 18.6 18.6 0 015-.5c8.1 0 26.4 3.1 56.6 24.1a208.2 208.2 0 01112.2 0c30.2-21 48.5-24.1 56.6-24.1a18.6 18.6 0 015 .5 84.6 84.6 0 012.2 60.8 90.3 90.3 0 0123 61.6c0 88.2-52.4 107.6-102.3 113.3 8 7.1 15.2 21.1 15.2 42.5 0 30.7-.3 55.5-.3 63 0 5.4 3.1 11.5 11.4 11.5a19.4 19.4 0 004-.4A229.2 229.2 0 00480 261.7C480 134.9 379.7 32 256 32z" />
                    </svg>
                    https://github.com/QuintionTang/react-blog
                </a>
            </p>
        </footer>
    );
}

接下来更新 pages/index.js，将使用自定义的 <Layout>组件：

      import Layout from "../components/layout";
import Head from "next/head";
import Link from "next/link";
export default function Home() {
    return (
        <Layout>
            <Head>
                <title>Next.js网站</title>
                <meta
                    name="description"
                    content="这是一个由 Next.js 驱动的网站"
                />
            </Head>
            Next.js 博客网站
            <p>
                这个博客网站将使用 <a rel="nofollow" href="https://nextjs.org/">Next.js</a>。
            </p>
            <p>
                更多内容请点击{" "}
                <Link href="/about">
                    <a>关于我们...</a>
                </Link>
            </p>
        </Layout>
    );
}

然后对 pages/about.js和创建的任何其他页面执行相同操作。

      import Layout from "../components/layout";
import Head from "next/head";

export default function Home() {
    return (
        <Layout title="share.png">
            <Head>
                <title>关于我们</title>
            </Head>

            关于我们
            <p>
                DevPoint 是 WEB
                开发的分享中心，用自己的热情来分享互联网的点滴，以此激励自己加强学习提升自我。
            </p>
        </Layout>
    );
}

更新后的效果如下：

使用动态路由查看博客内容

使用 JSX 创建内容并不是特别实用，尤其是对于常规博客文章，对于开发者比较喜欢 Markdown 的方式写博客。Next.js 可以使用任何来源创建页面。这些可以在构建时静态生成，并使用动态路由将数据映射到 URL。

在继续之前，先来创建一个文章目录，用于存放博客的 Markdown 文件。例如： articles/article-01.md：

      ---
title: 使用 React 和 Next.js 构建博客
description: Next.js 是由 Vercel 创建和维护的基于 React 的应用程序框架。本教程将从零开始学习如何使用 Next.js 构建一个小型的博客网站。
date: 2022-01-22
tags:
    - HTML
    - CSS
    - REACT
---

使用 React 和 Next.js 构建博客

## 摘要

Next.js 是由 Vercel 创建和维护的基于 React 的应用程序框架。本教程将从零开始学习如何使用 Next.js 构建一个小型的博客网站。

本教程将通过创建一个简单的博客来展示 Next.js 功能，那么 Next.js 适合这样的博客的开发吗？先来了解一下一般博客都需要什么？

-   WordPress 是一个内容管理系统 (CMS)，它为三分之一的网站提供支持，通过在每次请求时将可编辑的数据库内容渲染到 PHP 模板中来为页面提供服务。它非常适合定期更新的内容，但性能、安全性和数据备份需要一定的自定义设置。
-   静态站点生成器 (SSG)，例如 Eleventy 或 Gatsby 创建预渲染文件，无需服务器端或数据库即可快速构建静态站点，在版本控制、性能和安全性都非常出色，但构建步骤和以开发人员为中心的过程可能会减慢发布速度，尤其是在大型网站上。

Next.js 是一个基于 React 的应用程序框架，它几乎没有特定于博客功能。但是，它可以提供了一种实现机制：

1. 在可能的情况下，Next.js 生成静态内容，如 SSG，这些页面加载速度非常快，可以被搜索引擎快速收录，并且可以在任何有或没有 JavaScript 的设备上阅读。
2. 在第一次加载后，Next.js 应用程序的行为类似于单页应用程序 (SPA)，后续页面和代码会以渐进式下载，无需刷新整页。
3. Next.js 为每个请求提供服务器端渲染 (SSR)，为个人用户提供实时 CMS 更新或自定义内容变得更加容易。
   如果网站可能会从基本博客迭代为更复杂的网站，例如在线商店、新闻聚合服务、社交媒体平台等，可以考虑使用 Next.js。

内容的模板以 ---来定义博客的标题、发布时间等元数据， ---后面的为博客的正文。接下来需要安装解析内容的依赖，包括： front-matter、 remark和 remark-html，执行一下命令：

      npm install front-matter remark remark-html --save

要读取和解析 Markdown 文件，需要添加相关逻辑，代码所在文件 libs/posts-md.js。

      import { promises as fsp } from "fs";
import path from "path";
import fm from "front-matter";
import { remark } from "remark";
import remarkhtml from "remark-html";
import * as dateformat from "./dateformat";

const fileExt = "md";

// 获取文件夹相对路径
function absPath(dir) {
    return path.isAbsolute(dir) ? dir : path.resolve(process.cwd(), dir);
}

/**
 * 获取文件夹中 Markdown 文件名列表，以数组形式返回
 * @param {*} dir
 * @returns
 */
export async function getFileIds(dir = "./") {
    const loc = absPath(dir);
    const files = await fsp.readdir(loc);

    return files
        .filter((fn) => path.extname(fn) === `.${fileExt}`)
        .map((fn) => path.basename(fn, path.extname(fn)));
}

/**
 * 获取单个 Markdown 文件的内容
 * @param {*} dir
 * @param {*} id
 * @returns
 */
export async function getFileData(dir = "./", id) {
    const file = path.join(absPath(dir), `${id}.${fileExt}`),
        stat = await fsp.stat(file),
        data = await fsp.readFile(file, "utf8"),
        matter = fm(data),
        html = (await remark().use(remarkhtml).process(matter.body)).toString();

    // 日期格式化
    const date = matter.attributes.date || stat.ctime;
    matter.attributes.date = date.toUTCString();
    matter.attributes.dateYMD = dateformat.ymd(date);
    matter.attributes.dateFriendly = dateformat.friendly(date);

    // 计数
    const roundTo = 10,
        readPerMin = 200,
        numFormat = new Intl.NumberFormat("en"),
        count = matter.body
            .replace(/\W/g, " ")
            .replace(/\s+/g, " ")
            .split(" ").length,
        words = Math.ceil(count / roundTo) * roundTo,
        mins = Math.ceil(count / readPerMin);

    matter.attributes.wordcount = `${numFormat.format(
        words
    )} words, ${numFormat.format(mins)}-minute read`;

    return {
        id,
        html,
        ...matter.attributes,
    };
}

以上代码涉及日期格式化代码，文件路径 libs/dateformat.js。

      // 时间格式化
const toMonth = new Intl.DateTimeFormat("en", { month: "long" });

// 格式化为 YYYY-MM-DD
export function ymd(date) {
    return date instanceof Date
        ? `${date.getUTCFullYear()}-${String(date.getUTCMonth() + 1).padStart(
              2,
              "0"
          )}-${String(date.getUTCDate()).padStart(2, "0")}`
        : "";
}

// 格式化为 DD MMMM, YYYY
export function friendly(date) {
    return date instanceof Date
        ? `${date.getUTCDate()} ${toMonth.format(
              date
          )}, ${date.getUTCFullYear()}`
        : "";
}

Next.js 使用包含在 [id ]中的标识符的文件名来识别动态（生成）路由。创建一个名为 pages/articles/[id].js的文件： Next.js将使用 id作为参数在 /articles/article-01等路由处生成页面，即博客的详情页路由。

pages/articles/[id].js中定义函数 getStaticPaths，该函数返回构建时要呈现的路径信息。

      /**
 * 获取博客路径信息
 * @returns [ { params: { id: 'article-01' } } ]
 */
export async function getStaticPaths() {
    const paths = (await getFileIds(postsDir)).map((id) => {
        return { params: { id } };
    });
    console.log(paths);
    return {
        paths,
        fallback: false,
    };
}

设置 fallback: false会在找不到路径时出现 404 页面。

接下来创建函数 getStaticProps，函数在构建时获取特定 ID 的数据以进行静态生成。它在 params对象中传递了一个 id属性，调用 libs/posts-md.js中的 getFileData()函数解析 Markdown 文件。

      /**
 * 解析路由获取详细内容
 * @param {*} param0
 * @returns
 */
export async function getStaticProps({ params }) {
    return {
        props: {
            postData: await getFileData(postsDir, params.id),
        },
    };
}

pages/articles/[id].js除了解析博客内容外，还需将内容导出为一个 React 组件，组件将 postData渲染到前面创建的模板中：

      export default function Article({ postData }) {
    // 解析markdown内容
    const html = `
    ${postData.title}
    <p class="time"><time datetime="${postData.dateYMD}">${postData.dateFriendly}</time></p>
    <p class="words">${postData.wordcount}</p>
    ${postData.html}
  `;

    return (
        <Layout title="share.png">
            <Head>
                <title>{postData.title}</title>
                <meta name="description" content={postData.description} />
            </Head>

            <article dangerouslySetInnerHTML={{ __html: html }} />
        </Layout>
    );
}

dangerouslySetInnerHTML属性确保 HTML 不被编码。

创建博客列表页

创建文件 pages/articles/index.js，这个页面需要实现的功能是解析博客列表，并返回为一个 React 组件。在实现这个页面功能之前，先来创建一个链接组件 Pagelink。

Pagelink组件实现博客列表中单篇博客的布局，创建文件 components/pagelink.js，代码如下：

      import Link from "next/link";

export default function Pagelink(props) {
    const link = `/${props.postsdir}/${props.id}`;

    return (
        <article>
            <h2>
                <Link href={link}>
                    <a>{props.title}</a>
                </Link>
            </h2>
            <p className="time">
                发布时间：
                <time dateTime={props.datefriendly}>{props.dateymd}</time>
            </p>
            <p>{props.description}</p>
        </article>
    );
}

完成单个博客布局后，来看看博客列表页，代码如下：

      import { getAllFiles } from "../../libs/posts-md";
import Layout from "../../components/layout";
import Pagelink from "../../components/pagelink";
import Head from "next/head";

const postsDir = "articles";

export default function ArticleIndex({ postData }) {
    return (
        <Layout title="share.png">
            <Head>
                <title>博客列表</title>
                <meta
                    name="description"
                    content="A list of articles published on this site."
                />
            </Head>

            博客列表

            <aside className="pagelist">
                {postData.map((post) => (
                    <Pagelink
                        key={post.id}
                        postsdir={postsDir}
                        id={post.id}
                        title={post.title}
                        description={post.description}
                        dateymd={post.dateYMD}
                        datefriendly={post.dateFriendly}
                    />
                ))}
            </aside>
        </Layout>
    );
}

/**
 * 获取所有文章文章的数组
 * @returns
 */
export async function getStaticProps() {
    return {
        props: {
            postData: await getAllFiles(postsDir),
        },
    };
}

创建导航

一个完整的博客站点，需要一个导航菜单，方便内容切换。接下来创建一个导航组件，创建文件 components/navs.js，导出一个 <Navs>组件，代码如下：

      import { useRouter } from "next/router";
import Link from "next/link";

// menu name and link
const menu = [
    { text: "网站首页", link: "/" },
    { text: "关于我们", link: "/about" },
    { text: "博客列表", link: "/articles" },
];

export default function Navs() {
    const router = useRouter(),
        currentPage = router.pathname;

    return (
        <nav>
            <ul>
                {menu.map((item) => (
                    <NavItem
                        key={item.link}
                        text={item.text}
                        link={item.link}
                        currentpage={currentPage}
                    />
                ))}
            </ul>
        </nav>
    );
}

function NavItem({ text, link, currentpage }) {
    if (link === currentpage) {
        return (
            <li className="active">
                <strong>{text}</strong>
            </li>
        );
    } else {
        return (
            <li>
                <Link href={link}>
                    <a>{text}</a>
                </Link>
            </li>
        );
    }
}

下面将 Navs组件加入到组件 Header 中，代码如下：

      import Link from "next/link";
import Navs from "./navs";  // 导航菜单

export default function Header({ title }) {
    const headerImg = "/images/" + (title || "cover.png");

    return (
        <header>
            <p className="logo">
                <Link href="/">
                    <a>
                        <svg
                            xmlns="http://www.w3.org/2000/svg"
                            viewBox="0 0 20 20"
                            width="50"
                            height="50"
                        >
                            <path d="M10.394 2.08a1 1 0 00-.788 0l-7 3a1 1 0 000 1.84L5.25 8.051a.999.999 0 01.356-.257l4-1.714a1 1 0 11.788 1.838L7.667 9.088l1.94.831a1 1 0 00.787 0l7-3a1 1 0 000-1.838l-7-3zM3.31 9.397L5 10.12v4.102a8.969 8.969 0 00-1.05-.174 1 1 0 01-.89-.89 11.115 11.115 0 01.25-3.762zM9.3 16.573A9.026 9.026 0 007 14.935v-3.957l1.818.78a3 3 0 002.364 0l5.508-2.361a11.026 11.026 0 01.25 3.762 1 1 0 01-.89.89 8.968 8.968 0 00-5.35 2.524 1 1 0 01-1.4 0zM6 18a1 1 0 001-1v-2.065a8.935 8.935 0 00-2-.712V17a1 1 0 001 1z"></path>
                        </svg>
                        Next.js 博客
                    </a>
                </Link>
            </p>
            <Navs />
            <figure>
                <img src={headerImg} width="400" alt="decoration" />
            </figure>
        </header>
    );
}

到此一个简单的博客站点功能已经实现。

添加样式

Next.js 提供了一系列样式选项，包括 Sass、Less、PostCSS、Styled JSX、CSS 模块和普通的CSS。 Sass 易于使用，因为不需要任何配置，按照依赖：

      npm install sass --save

根目录下创建文件夹 styles，所有的样式文件都放在这个文件夹下。样式的入口未见为 master.scss。

然后在文件夹 pages下创建文件 _app.js，将样式文件导入，完整代码如下：

      import "../styles/master.scss";

export default function App({ Component, pageProps }) {
    return <Component {...pageProps} />;
}

最终效果如下：

中文文本纠错模型_卓寿杰SoulJoy的博客-CSDN博客

Wed, 30 Mar 2022 07:28:44 CST

中文文本纠错任务是一项NLP基础任务，其输入是一个可能含有语法错误的中文句子，输出是一个正确的中文句子。语法错误类型很多，有多字、少字、错别字等，目前最常见的错误类型是错别字。

1. SoftMaskedBert4CSC

论文【ACL 2020】《Spelling Error Correction with Soft-Masked BERT》https://arxiv.org/abs/2005.07421
Detection
首先，模型的输入是n个中文字符X=(x1，x2，… ，xn)经过embeddings得到的E = (e1，e2，…，en),该embeding是word embeding+position embeding+segment embeding，经过Bi-GRU得到各个字符错误的概率G = (g1，g2，…，gn)，其中g在0-1之间，越靠近1表示该字符错误的概率越大，其损失函数为：
soft-masked
作者认为只hard-mask了15%字符的Bert不完全具备纠错的能力（至于为啥不具备，作者也没讲清楚，我觉得这里有些牵强），所以作者提出了soft-mask，大致的思路就是利用Detection输出的得分来引导Bert输入的mask，使得得分高(错误概率高)的地方更大概率被mask，公式如下：
Correction
Correction的输入是经过soft-masked的embeding，输出的是生成的字符，损失函数是：

Loss
模型没有分阶段训练，而是直接end-to-end，使用Bert的per-trained模型，损失函数由Detection和Correction线性组合，如下：

2. MacBert4CSC

MacBert 可以参阅：https://blog.csdn.net/u011239443/article/details/121820752?spm=1001.2014.3001.5502

MacBert4CSC：https://github.com/shibing624/pycorrector/blob/master/pycorrector/macbert/README.md

本项目是 MacBERT 改变网络结构的中文文本纠错模型，可支持 BERT 类模型为 backbone。

在通常 BERT 模型上进行了魔改，追加了一个全连接层作为错误检测即 detection，与 SoftMaskedBERT 模型不同点在于，本项目中的 MacBERT 中，只是利用 detection 层和 correction 层的 loss 加权得到最终的 loss。不像 SoftmaskedBERT 中需要利用 detection 层的置信概率来作为 correction 的输入权重。

3. ErnieCSC

Ernie参阅：https://blog.csdn.net/u011239443/article/details/121820752?spm=1001.2014.3001.5502

ErnieCSC PaddleNLP模型库实现了百度在ACL 2021上提出结合拼音特征的Softmask策略的中文错别字纠错的下游任务网络，并提供预训练模型，模型结构如下：

PyTorch实现版本：https://github.com/orangetwo/ernie-csc

数仓建模—ID Mapping - 大数据技术派 - 博客园

Sat, 05 Mar 2022 19:54:24 CST

早晨起床的时候，发现自己尿分叉，我没有多想，简单洗洗就匆忙出门。路过早餐店，我看到师傅熟练的拉扯一小块面团，拉至细长条，然后放入油锅中，不一会功夫，一根屎黄色的油条便出锅了，卖相不错。我在想，小到炸屎黄色的油条，大到学习，其实都是一个熟能生巧的过程。

数据仓库系列文章(持续更新)

数仓架构发展史
数仓建模方法论
数仓建模分层理论
数仓建模—宽表的设计
数仓建模—指标体系
数据仓库之拉链表
数仓—数据集成
数仓—数据集市
数仓—商业智能系统
数仓—埋点设计与管理
数仓—ID Mapping
数仓—OneID
数仓—AARRR海盗模型
数仓—总线矩阵
数仓—数据安全
数仓—数据质量
数仓—数仓建模和业务建模

关注 大数据技术派，回复: 资料，领取 1024G资料。

顾名思义我们知道ID Mapping 的操作对象是ID，目标或者是动作是Mapping，也就是说我们要做的事情其实就是想把不同平台不同设备上的ID 打通，从而更好的去刻画用户，也就是说我们希望能打通用户各个维度的数据，从而更好的去服务业务服务用户

通常公司有产品矩阵，而每个产品都有自己的注册账号产生的用户ID。从公司全局，整合用户表，用户行为数据来看，确定不同产品的用户ID是相同一个人非常重要, 选取合适的用户标识对于提高用户行为分析的准确性有非常大的影响，尤其是对用户画像、推荐、漏斗、留存、Session 等用户相关的分析功能。

其实对于任何分析都是一样的，如果我们不能准确标识一个用户，那么我们的计算结果就没有准确性可言，其实对于数据服务方而言，数据的准确性是我们的第一要务， 我们宁愿不出数据，也不要出错误的数据。

ID Mapping 的背景

网络身份证

假如没有网络身份证，那么每个商家（App）只能基于自己的账号体系标识用户，并记录用户的行为。而有了统一的网络身份证之后，各个商家之间的数据就可以打通了，天猫不仅知道用户A在淘宝系的购物数据，也能了解到该用户在社交网络的行为，以及旅游的喜好，等等。

在现实的数据中，由于，用户可能使用各种各样的设备，有着各种各样的前端入口，甚至同一个用户拥有多个设备以及使用多种前端入口，就会导致，日志数据中对同一个人，不同时间段所收集到的日志数据中，可能取到的标识个数、种类各不相同；

比如用户可能使用各种各样的设备，其次是不同设备有不同的操作系统，设置是软件本身的版本也会影响我们对用户的标识，

手机、平板电脑、PC
安卓手机、ios手机、winphone手机
安卓系统有各种版本（ 5.0 6.0 7.0 8.0 9.0 ）
ios系统也有各种版本（3.x 4.x 5.x 6.x 7.x … 12.x ）

存在的问题

用户设备的标识，没办法轻易定制一个规则来取某个作为唯一标识：
mac地址：手机网卡物理地址，若干早期版本的ios，winphone，android可取到
imei(入网许可证序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到
imsi(手机SIM卡序号)：安卓系统可取到，若干早期版本的ios，winphone可取到，运营商可取到
androidid ：安卓系统id
openuuid(app自己生成的序号) ：卸载重装app就会变更
IDFA(广告跟踪码)

扩展 IDFA

IDFA，英文全称 Identifier for Advertising ，可以理解为广告id，苹果公司提供的用于追踪用户的广告标识符，可以用来打通不同app之间的广告。 每个设备只有一个IDFA，不同APP在同一设备上获取IDFA的结果是一样的

苹果为了保护用户隐私，早在2012年就不再允许其生态中的玩家获取用户的唯一标识符，但是商家在移动端打广告的时候又希望能监控到每一次广告投放的效果，因此，苹果想出了折中的办法，就是提供另外一套和硬件无关的标识符，用于给商家监测广告效果，同时用户可以在设置里改变这串字符，导致商家没有办法长期跟踪用户行为。这个就叫做广告标识符（IDFA），设置路径是“设置->隐私->广告->还原广告标识符”，如下图所示（iOS9）

常见的标识

设备 ID

需要注意的是，设备 ID 并不一定是设备的唯一标识。例如 Web 端的 Cookies 有可能被清空（例如各种安全卫士），而 iOS 端的 IDFV( Identifier For Vendor)在不同厂商的 App 间是不同的,而且重新安装IDFV会被重置。

设备	规则
Android	1.10.5 之前版本，默认使用 UUID（例如：550e8400-e29b-41d4-a716-446655440000），App 卸载重装 UUID 会变，为了保证设备 ID 不变，可以通过配置使用 AndroidId（例如：774d56d682e549c3）；1.10.5 及之后的版本 SDK 默认使用 AndroidId 作为设备 ID，如果 AndroidId 获取不到则获取随机的 UUID。
iOS	1.10.18 及之后版本，如果 App 引入了 AdSupport 库，SDK 默认使用 IDFA 作为匿名 ID。1.10.18 之前版本，可以优先使用 IDFV（例如：1E2DFA10-236A-47UD-6641-AB1FC4E6483F），如果 IDFV 获取失败，则使用随机的 UUID（例如：550e8400-e29b-41d4-a716-446655440000），一般情况下都能够获取到 IDFV。如果使用 IDFV 或 UUID ，当用户卸载重装 App 时设备 ID 会变。也可以通过配置使用 IDFA（例如：1E2DFA89-496A-47FD-9941-DF1FC4E6484A），如果开启 IDFA ，可以优先获取 IDFA，如果获取失败再尝试获取 IDFV。使用 IDFA 能避免用户在重装 App 后设备 ID 发生变化的情况，需要注意的是IDFA 也是可以被重置的

设备

规则

Android

1.10.5 之前版本，默认使用 UUID（例如：550e8400-e29b-41d4-a716-446655440000），App 卸载重装 UUID 会变，为了保证设备 ID 不变，可以通过配置使用 AndroidId（例如：774d56d682e549c3）；1.10.5 及之后的版本 SDK 默认使用 AndroidId 作为设备 ID，如果 AndroidId 获取不到则获取随机的 UUID。

iOS

1.10.18 及之后版本，如果 App 引入了 AdSupport 库，SDK 默认使用 IDFA 作为匿名 ID。1.10.18 之前版本，可以优先使用 IDFV（例如：1E2DFA10-236A-47UD-6641-AB1FC4E6483F），如果 IDFV 获取失败，则使用随机的 UUID（例如：550e8400-e29b-41d4-a716-446655440000），一般情况下都能够获取到 IDFV。如果使用 IDFV 或 UUID ，当用户卸载重装 App 时设备 ID 会变。也可以通过配置使用 IDFA（例如：1E2DFA89-496A-47FD-9941-DF1FC4E6484A），如果开启 IDFA ，可以优先获取 IDFA，如果获取失败再尝试获取 IDFV。使用 IDFA 能避免用户在重装 App 后设备 ID 发生变化的情况，需要注意的是IDFA 也是可以被重置的

登录 ID

平台 ID

设备	规则
JavaScript	默认情况下使用 cookie_id（例如：15ffdb0a3f898-02045d1cb7be78-31126a5d-250125-15ffdb0a3fa40a），cookie_id 存贮在浏览器的 cookie 中，依然有被重置的风险这里还有一个问题，就是 cookie 只能隶属于同一个域名，也就是说你访问邮箱的 cookie ，与百度广的 cookie 并不是同一个，所以在网站与网站也要做 ID Mapping ，这就是为什么你在百度上搜索了“养生”，到购物网站上就会给你推荐“枸杞”。
微信小程序	默认情况下使用 UUID（例如：1558509239724-9278730-00c1875d5f63f8-41373096），但是删除小程序，UUID 会变。为了保证设备 ID 不变，建议获取并使用 openid（例如：oWDMZ0WHqfsjIz7A9B2XNQOWmN3E）。如果选择使用 openid 的话，请注意【操作暂存】，由于获取 openid 是一个异步的操作，但是冷启动事件等会先发生，这时候这个冷启动事件的 distinct_id 就不对了。所以我们会把先发生的操作，暂存起来，等获取到 openid 等后调用 sa.init() 后才会发送数据。 openid 的获取和操作暂存的方法。

设备

规则

JavaScript

默认情况下使用 cookie_id（例如：15ffdb0a3f898-02045d1cb7be78-31126a5d-250125-15ffdb0a3fa40a），cookie_id 存贮在浏览器的 cookie 中，依然有被重置的风险
这里还有一个问题，就是 cookie 只能隶属于同一个域名，也就是说你访问邮箱的 cookie ，与百度广的 cookie 并不是同一个，所以在网站与网站也要做 ID Mapping ，这就是为什么你在百度上搜索了“养生”，到购物网站上就会给你推荐“枸杞”。

微信小程序

默认情况下使用 UUID（例如：1558509239724-9278730-00c1875d5f63f8-41373096），但是删除小程序，UUID 会变。为了保证设备 ID 不变，建议获取并使用 openid（例如：oWDMZ0WHqfsjIz7A9B2XNQOWmN3E）。如果选择使用 openid 的话，请注意【操作暂存】，由于获取 openid 是一个异步的操作，但是冷启动事件等会先发生，这时候这个冷启动事件的 distinct_id 就不对了。所以我们会把先发生的操作，暂存起来，等获取到 openid 等后调用 sa.init() 后才会发送数据。 openid 的获取和操作暂存的方法。

其实这里的平台指的一些大的生态系统，例如微信的生态、今日头条等，我们很多依赖这些平台的应用就可以使用用户在这些平台上的用户标识作为标识,当然我们也可以在此基础上为我们自己平台上的用户创建属于本平台的用户表示，往往就是用户的 登录ID

方案详解

因此，我们在进行任何数据接入之前，都应当先确定如何来标识用户。下面会介绍几种用户标识方案的原理，以及几种典型情况下的用户标识方案。

方案一：只使用设备 ID

适合没有用户注册体系，或者极少数用户会进行多设备登录的产品，如工具类产品、搜索引擎、部分电商等。这也是绝大多数其它数据分析产品唯一提供的方案。

局限性

同一用户在不同设备使用会被认为不同的用户，对后续的分析统计有影响。
不同用户在相同设备使用会被认为是一个用户，也对后续的分析统计有影响。
但如果 用户跨设备使用或者多用户共用设备不是产品的常见场景的话，可以忽略上述问题。

方案二：关联设备 ID 和登录 ID（一对一）

仅使用设备 ID 标识用户虽然简单，但是对于某些应用场景这种方式不够准确，因此我们可以采用设备 ID 和登录 ID 的方案，在一定程度上融合设备 ID 和登录 ID，从而实现更准确的用户追踪。

成功关联设备 ID 和登录 ID 之后， 用户在该设备 ID 上或该登录 ID 下的行为就会贯通，被认为是一个用户 ID 发生的。在进行事件、漏斗、留存等用户相关分析时也会算作一个用户。

关联设备 ID 和登录 ID 的方法虽然实现了更准确的用户追踪，但是也会增加埋点接入的复杂度。所以一般来说，我们建议只有当同时满足以下条件时，才考虑进行 ID 关联：

需要贯通一个用户在一个设备上注册前后的行为。
需要贯通一个注册用户在不同设备上登录之后的行为。

局限性

一个设备 ID 只能和一个登录 ID 关联，而事实上一台设备可能有多个用户使用。
一个登录 ID 只能和一个设备 ID 关联，而事实上一个用户可能用一个登录 ID 在多台设备上登录。

方案三：关联设备 ID 和登录 ID（多对一）

关联设备 ID 和登录 ID（一对一）虽然已经实现了跨设备的用户贯通，但是对于某些应用场景还是不够准确，因此这里提供一个新的关联方案，支持一个登录 ID 绑定多个设备 ID 的方案，从而实现更准确的用户追踪。

也就是跨端，其实这是非常常见的一种场景，例如你在PC 端和移动端使用同一个产品。

一个用户在多个设备上进行登录是一种比较常见的场景，比如 Web 端和 App 端可能都需要进行登录。支持一个登录 ID 下关联多设备 ID 之后，用户在多设备下的行为就会贯通，被认为是一个ID 发生的。

局限性

一个设备 ID 只能和一个登录 ID 关联，而事实上 一台设备可能有多个用户使用多用户使用同一个设备这个问题是无解的。
一个设备 ID 一旦跟某个登录 ID 关联或者一个登录 ID 和一个设备 ID 关联，就不能解除（自动解除）。而事实上，设备 ID 和登录 ID 的动态关联才应该是更合理的。

方案对比

将上述三个方案放到一起，可以明显看到三种方案的区别，如下表所示：

方案一：仅使用设备 ID，不管用户是谁，只要设备未变，设备ID 就不变，即使多人使用同一个设备，也会被识别为同一个用户。
方案二：关联设备 ID 和登录 ID（一对一），
- 当用户换手机后，登录账号之后的行为与换手机之前的行为贯通了，但是在新设备上首次登录之前的行为仍没法贯通，仍被识别为新的用户的行为。
- 当用户把旧手机送给朋友之后，由于旧手机已被关联到自己的登录 ID 了，无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们，若不登录就操作，则都会被识别为同一个用户。
方案三：关联设备 ID 和登录 ID（多对一）
- 当用户把旧手机送给朋友之后，由于旧手机已被关联到自己的登录 ID 了，无法再与朋友的登录 ID 关联。后续使用这台旧手机的用户们，若不登录就操作，则都会被识别为同一个用户）。
- 而事实上，旧手机上后续的匿名登录很难识别到底是谁，可能归为匿名登录之前最近一次登录的用户会更合理一些。

其实，三种方案没有对与错，我们应该结合自己的业务场景以及埋点复杂度来选择合适的方案。

总结

ID Mapping 就如同它的名字一样，我们要做的就是将一系列的ID 关联起来，一些列的ID 可能是用户在不同平台上的标识，也可能是用户在不同设备上的标识，也可能是用户在不同状态下的标识，总之我们就是要将这一系列的ID 关联起来，尽可能地将用户的数据打通，从而提供更加全面准确的分析。

我们知道只有打破数据孤岛数据才能发挥更大的价值，可能很多人都知道数据仓库的数据集成环节其实就是为了打破数据孤岛，其实我们的ID Mapping 也是为了打破数据孤岛，其实ID Mapping 就两个使命 1. 多端数据的识别；2. 多源数据的打通，其他的都是基于ID Mapping 的应用

nginx配置反向代理或跳转出现400问题处理记录 - AllEmpty - 博客园

Tue, 25 Jan 2022 14:59:18 CST

　　午休完上班后，同事说测试站点访问接口出现400 Bad Request Request Header Or Cookie Too Large提示，心想还好是测试服务器出现问题，影响不大，不过也赶紧上服务器进行测试查看，打开nginx与ugwsi日志与配置，发现后端服务日志记录正常，而测试站点的访问日志有7百多M（才运行两三天没几个访问，几M的话才是正常现象），在浏览器里直接访问后端服务接口也正常没有问题（我们的服务器软件架构是微服务架构，将很多模块分拆后分别部署，前端是一个纯HTML站点，通过AJAX访问后端各个服务，由于访问量不大，所以前端站点的nginx配置时，做了反向代理访问后端其他服务，这样就不会出现跨域和需要处理多子域名事情——即访问不同的服务时，只需要使用当前域名就可以了，这样前端开发人员不必要知道后端挂载了多少服务需要使用什么对应的域名访问）。访问这台服务器上的其他站点都能正常访问，而问题站点的html页面也能正常打开......在测试过程中发现，每访问一下问题接口，访问日志就增加30多M，刷了几次，nginx日志大小直线上升......

　　由于日志比较大，只能使用tail -n 5000 xxx_access.log >> xxx.log截取一下最新的日志记录下载下来，打开一看发现同一时间一个访问，生产了2000多条重复循环的访问记录，而日志尾部$http_x_forwarded_for部分，有规律的存储了相同的由多到少的IP字串，即：最后一条有一个IP字串（真实IP），倒数第二条有两个IP字串（真实IP + 服务器本地IP），倒数第三条有三个IP字串（真实IP + 两个服务器本地IP），以至类推

　　百度了一下“400 Bad Request Request Header Or Cookie Too Large”，查找出来的几乎都是说“nginx 400 Bad request是request header过大所引起，request过大，通常是由于cookie中写入了较大的值所引起。在nginx.conf中，将client_header_buffer_size和large_client_header_buffers都调大后可解决”，一看就知道这肯定不是我这种情况的解决办法，这是由于不知道什么原因引起的死循环将IP地址串写入请求头，直到缓存爆了才返回400，如果将缓存设置更大，只会造成日志增加速度变大而已。从分析来看应该是nginx出现的问题。

　　没有办法只能在打开nginx配置文件分析，问题站点的配置文件，如下图，并没有发现什么问题

　　打开nginx.conf进行慢慢研究，发现多了几行代码

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

　　这是用来将当前访问用户的IP传给后端服务器用的，将它们删除重新启动一下服务器nginx后测试了一下，发现能正常访问了...o my god，再将它放回去，重启，访问，挂了，去掉，重启，访问，正常......重试了好几次，终于确定就是突然多出来的几行代码引起的。（后来问了一下同事才知道是他进服务器添加的）

　　难道真的是不能使用吗？记得以前用过还是正常的。尝试访问预生产环境接口，正常。打开预生产环境的nginx配置，包函有这三行代码，如下图

　　全面对比后发现，生产环境用的nginx配置是域名，而预生产环境用的是IP+端口，除此之外没有任何区别，使用跳转方式与反向代码方式测试，结果都是一样，添加port_in_redirect、server_name_in_redirect配置也没能解决

　　综合分析，应该是nginx在使用proxy_pass做跳转时，如果直接使用域名，且需要向后端提交当前访问的IP地址时，引发nginx的bug造成死循环，不知道大家有没有遇到过这种情况。

# 使用反向代理方式        
# 正常的配置
upstream xxx{
    server127.0.0.1:23456;
}
upstream yyy {
    server127.0.0.1:123455;
}
# 异常配置
upstream xxx1{
    server xx.xxx.com;
}
upstream yyy2 {
    server  yyy.xxx.com;
}

# 使用跳转方式
# 正常配置
proxy_pass   http://127.0.0.1:23456;# 异常配置
proxy_pass   http://xx.xxx.com;

实践k8s istio熔断 - fat_girl_spring - 博客园

Mon, 17 Jan 2022 11:23:03 CST

熔断主要是无感的处理服务异常并保证不会发生级联甚至雪崩的服务异常。在微服务方面体现是对异常的服务情况进行快速失败，它对已经调用失败的服务不再会继续调用，如果仍需要调用此异常服务，它将立刻返回失败。与此同时，它一直监控服务的健康状况，一旦服务恢复正常，则立刻恢复对此服务的正常访问。这样的快速失败策略可以降低服务负载压力，很好地保护服务免受高负载的影响。

一个熔断器可以有三种状态：关闭、打开和半开，默认情况下处于关闭状态。在关闭状态下，无论请求成功或失败，到达预先设定的故障数量阈值前，都不会触发熔断。而当达到阈值时，熔断器就会打开。当调用处于打开状态的服务时，熔断器将断开请求，这意味着它会直接返回一个错误，而不去执行调用。通过在客户端断开下游请求的方式，可以在生产环境中防止级联故障的发生。在经过事先配置的超时时长后，熔断器进入半开状态，这种状态下故障服务有时间从其中断的行为中恢复。如果请求在这种状态下继续失败，则熔断器将再次打开并继续阻断请求。否则熔断器将关闭，服务将被允许再次处理请求。

熔断器对比 Hystrix vs Istio

Hystrix是Netflix OSS的一部分，是微服务领域的领先的熔断工具。Hystrix可以被视为白盒监控工具，而Istio可以被视为黑盒监控工具，主要是因为Istio从外部监控系统并且不知道系统内部如何工作。另一方面，每个服务中有Hystrix来获取所需的数据。
Istio是无缝衔接服务，istio可以在不更改应用程序代码的情况下配置和使用。Hystrix的使用需要更改每个服务来引入Hystrix libraries。
Istio提高了网格中服务的可靠性和可用性。但是，应用程序需要处理错误并有一定的fall back行为。例如当负载平衡池中的所有服务实例都出现异常时，Envoy将返回HTTP 503。当上游服务返回 HTTP 503 错误，则应用程序需要采取回退逻辑。与此同时，Hystrix也提供了可靠的fall back实现。它允许拥有所有不同类型的fall backs：单一的默认值、缓存或者去调用其他服务。

envoy对应用程序来说几乎完全无感和透明。Hystrix则必须在每个服务调用中嵌入Hystrix库。
Istio的熔断应用几乎无语言限制，但Hystrix主要针对的是Java应用程序。

Istio是使用了黑盒方式来作为一种代理管理工具。它实现起来很简单，不依赖于底层技术栈，而且可以在部署后也可以进行配置和修改。Hystrix需要在代码级别处理断路器，可以设置级联和一些附加功能，它需要在开发阶段时做出降级决策，后期优化配置成本高。

Istio限流

Istio无需对代码进行任何更改就可以为应用增加熔断和限流功能。Istio中熔断和限流在DestinationRule的CRD资源的TrafficPolicy中设置，一般设置连接池（ConnectionPool）限流方式和异常检测（outlierDetection）熔断方式。两者ConnectionPool和outlierDetection各自配置部分参数，其中参数有可能存在对方的功能，并没有很严格的区分出来，如主要进行限流设置的ConnectionPool中的maxPendingRequests参数，最大等待请求数，如果超过则也会暂时的熔断。

连接池（ConnectionPool）设置
ConnectionPool可以对上游服务的并发连接数和请求数进行限制，适用于TCP和HTTP。ConnectionPool又称之是限流。

官方定义的属性

设置在DestinationRule中的配置如下图：

连接池相关参数解析

TCP设置

Tcp连接池设置http和tcp上游连接的设置。相关参数设置如下：

maxConnections：到目标主机的HTTP1/TCP最大连接数量，只作用于http1.1，不作用于http2，因为后者只建立一次连接。

connectTimeout：tcp连接超时时间，默认单位秒。也可以写其他单位，如ms。

tcpKeepalive：如果在套接字上设置SO_KEEPALIVE可以确保TCP 存活

TCP的TcpKeepalive设置：

Probes：在确定连接已死之前，在没有响应的情况下发送的keepalive探测的最大数量。默认值是使用系统级别的配置(除非写词参数覆盖，Linux默认值为9)。

Time：发送keep-alive探测前连接存在的空闲时间。默认值是使用系统的配置(除非写此参数，Linux默认值为7200s(即2小时)。

interval：探测活动之间的时间间隔。默认值是使用系统的配置(除非被覆盖，Linux默认值为75秒)。

HTTP设置

http连接池设置用于http1.1/HTTP2/GRPC连接。

http1MaxPendingRequests：http请求pending状态的最大请求数，从应用容器发来的HTTP请求的最大等待转发数，默认是1024。

http2MaxRequests：后端请求的最大数量，默认是1024。

maxRequestsPerConnection：在一定时间内限制对后端服务发起的最大请求数，如果超过了这个限制，就会开启限流。如果将这一参数设置为 1 则会禁止 keepalive 特性；

idleTimeout：上游连接池连接的空闲超时。空闲超时被定义为没有活动请求的时间段。如果未设置，则没有空闲超时。当达到空闲超时时，连接将被关闭。注意，基于请求的超时意味着HTTP/2ping将无法保持有效连接。适用于HTTP1.1和HTTP2连接；

maxRetries：在给定时间内，集群中所有主机都可以执行的最大重试次数。默认为3。

与Envoy参数对比

熔断和限流是分布式系统的重要组成部分，优点是快速失败并迅速向下游反馈。 Istio是通过Envoy Proxy 来实现熔断和限流机制的，Envoy 强制在网络层面配置熔断和限流策略，这样就不必为每个应用程序单独配置或重新编程。Envoy支持各种类型的全分布式(不协调)限流。

IstioConnectionPool与 Envoy 的限流参数对照表：

Envoy paramether
Envoy  upon object
Istio parameter
Istio  upon ojbect
max_connections
cluster.circuit_breakers
maxConnections
TCPSettings
max_pending_requests
cluster.circuit_breakers
http1MaxPendingRequests
HTTPSettings
max_requests
cluster.circuit_breakers
http2MaxRequests
HTTPSettings
max_retries
cluster.circuit_breakers
maxRetries
HTTPSettings
connect_timeout_ms
cluster
connectTimeout
TCPSettings
max_requests_per_connection
cluster
maxRequestsPerConnection
HTTPSettings

maxConnections: 表示在任何给定时间内，Envoy 与上游集群建立的最大连接数，限制对后端服务发起的 HTTP/1.1 连接数。该配置仅适用于 HTTP/1.1 协议，因为HTTP/2 协议可以在同一个 TCP 连接中发送多个请求，而 HTTP/1.1 协议在同一个连接中只能处理一个请求。如果超过了这个限制（即断路器溢出），集群的upstream_cx_overflow计数器就会增加。

maxPendingRequests: 表示待处理请求队列的长度，如果超过了这个限制，就会开启限流。因为HTTP/2 是通过单个连接并发处理多个请求的，因此该策略仅在创建初始 HTTP/2 连接时有用，之后的请求将会在同一个 TCP 连接上多路复用。对于HTTP/1.1 协议，只要没有足够的上游连接可用于立即分派请求，就会将请求添加到待处理请求队列中，因此该断路器将在该进程的生命周期内保持有效。如果该断路器溢出，集群的upstream_rq_pending_overflow计数器就会增加。

maxRequestsPerConnection: 表示在任何给定时间内，上游集群中主机可以处理的最大请求数，限制对后端服务发起的HTTP/2 请求数。实际上，这适用于仅 HTTP/2 集群，因为 HTTP/1.1 集群由最大连接数断路器控制。如果该断路器溢出，集群的upstream_rq_pending_overflow 计数器就会递增。

maxRetries:在任何给定时间内，集群中所有主机都可以执行的最大重试次数。一般情况下，建议对偶尔的故障积极地进行断路重试，因为总体重试容量不会爆炸并导致大规模级联故障。如果这个断路器溢出，则集群的upstream_rq_retry_overflow计数器将增加。

envoy新加参数（后期istio可能会增加）

maximumconcurrent connection pools：可以并发实例化的连接池的最大数量。一些特性，比如Original SrcListener Filter，可以创建无限数量的连接池。当集群耗尽其并发连接池时将会回收空闲连接。如果不能回收，断路器就会溢出。这与连接池中的集群最大连接不同，连接池中的连接通常不会超时。Connections自动清理;连接池不需要。注意，为了使连接池发挥作用，它至少需要一个上游连接，因此这个值应该小于集群最大连接。

在上游集群和优先级上针对不同的组件，都可以分别进行单独的配置参数进行请求限制。通过统计可以观察到这些断路器的状态，包括断路器打开前剩余数量的断路器。注意，在HTTP请求下将会重新设置路由过滤器的x-envoy-overloaded报头。

Istio中的熔断

Istio的熔断可以在流量策略中配置。Istio的自定义资源Destination Rule里，TrafficPolicy字段下有两个和熔断相关的配置：ConnectionPoolSettings 和 OutlierDetection。
ConnectionPoolSettings可以为服务配置连接的数量。OutlierDetection用来控制从负载均衡池中剔除不健康的实例。
例如，ConnectionPoolSettings控制请求的最大数量，挂起请求，重试或者超时；OutlierDetection 设置服务被从连接池剔除时发生错误的请求数，可以设置最小逐出时间和最大逐出百分比。有关完整的字段列表，请参考文档

启动 Httpbin样例程序。

如果您启用了 Sidecar 自动注入，通过以下命令部署 httpbin服务：

kubectl apply -f samples/httpbin/httpbin.yaml

配置熔断器

创建一个目标规则，在调用 httpbin服务时应用熔断设置：

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections:1http:
        http1MaxPendingRequests:1maxRequestsPerConnection:1outlierDetection:
      consecutiveErrors:1interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent:100EOF

验证目标规则是否已正确创建：

kubectl get destinationrule httpbin -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
  ...
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests:1maxRequestsPerConnection:1tcp:
        maxConnections:1outlierDetection:
      baseEjectionTime:180.000s
      consecutiveErrors:1interval:1.000s
      maxEjectionPercent:100

使用ConnectionPoolSettings字段中的这些设置，在给定的时间内只能和notifications 服务建立一个连接：每个连接最多只能有一个挂起的请求。如果达到阈值，熔断器将开始阻断请求。
OutlierDetection部分的设置用来检查每秒调用服务是否有错误发生。如果有，则将服务从负载均衡池中逐出至少三分钟（100%最大弹出百分比表示，如果需要，所有的服务实例都可以同时被逐出）。

          在手动创建Destination Rule资源时有一件事需要特别注意，那就是是否为该服务启用了mTLS。如果是的话，还需要在Destination Rule中设置如下字段，否则当调用movies服务时，调用方可能会收到503错误：          
          
              trafficPolicy:          
                 tls:          
                mode: ISTIO_MUTUAL          
          
          还可以为特定namespace 或特定服务启用全局的mTLS。你应该了解这些设置以便确定是否把trafficPolicy.tls.mode设置为 ISTIO_MUTUAL。更重要的是，当你试图配置一个完全不同的功能（例如熔断）时，很容易忘记设置此字段。          
          
              提示：在创建Destination Rule前总是考虑mTLS！

为了触发熔断，让我们同时从两个连接来调用 notifications服务。maxConnections字段被设置为1。这时应该会看到503与200的响应同时到达。
当一个服务从客户端接收到的负载大于它所能处理的负载（如熔断器中配置的那样），它会在调用之前返回503错误。这是防止错误级联的一种方法。

增加一个客户端

创建客户端程序以发送流量到 httpbin服务。这是一个名为 Fortio的负载测试客户端，它可以控制连接数、并发数及发送 HTTP 请求的延迟。通过 Fortio 能够有效的触发前面在 DestinationRule中设置的熔断策略。

向客户端注入 Istio Sidecar 代理，以便 Istio 对其网络交互进行管理：

kubectl apply -f samples/httpbin/sample-client/fortio-deploy.yaml

登入客户端 Pod 并使用 Fortio 工具调用 httpbin服务。 -curl参数表明发送一次调用：

$ export FORTIO_POD=$(kubectl get pods -l app=fortio -o 'jsonpath={.items[0].metadata.name}')
$ kubectl exec"$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://httpbin:8000/getHTTP/1.1 200OK
server: envoy
date: Tue,25 Feb 2020 20:25:52GMT
content-type: application/json
content-length: 586access-control-allow-origin: *access-control-allow-credentials:truex-envoy-upstream-service-time: 36{"args": {},"headers": {"Content-Length": "0","Host": "httpbin:8000","User-Agent": "fortio.org/fortio-1.3.1","X-B3-Parentspanid": "8fc453fb1dec2c22","X-B3-Sampled": "1","X-B3-Spanid": "071d7f06bc94943c","X-B3-Traceid": "86a929a0e76cda378fc453fb1dec2c22","X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=68bbaedefe01ef4cb99e17358ff63e92d04a4ce831a35ab9a31d3c8e06adb038;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/default"},"origin": "127.0.0.1","url": "http://httpbin:8000/get"}

可以看到调用后端服务的请求已经成功！接下来，可以测试熔断。

触发熔断器

在 DestinationRule配置中，您定义了 maxConnections: 1和 http1MaxPendingRequests: 1。这些规则意味着，如果并发的连接和请求数超过一个，在 istio-proxy进行进一步的请求和连接时，后续请求或连接将被阻止。

发送并发数为 2 的连接（ -c 2），请求 20 次（ -n 20）：

kubectl exec -it $FORTIO_POD  -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://httpbin:8000/getFortio 0.6.2 running at 0 queries per second, 2->2 procs,for5s: http://httpbin:8000/getStarting at max qps with 2 thread(s) [gomax 2]forexactly 20 calls (10 per thread + 0)23:51:10 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
Ended after106.474079ms : 20 calls. qps=187.84Aggregated Function Time : count20 avg 0.010215375 +/- 0.003604 min 0.005172024 max 0.019434859 sum 0.204307492# range, mid point, percentile, count>= 0.00517202 <= 0.006 , 0.00558601 , 5.00, 1
> 0.006 <= 0.007 , 0.0065 , 20.00, 3
> 0.007 <= 0.008 , 0.0075 , 30.00, 2
> 0.008 <= 0.009 , 0.0085 , 40.00, 2
> 0.009 <= 0.01 , 0.0095 , 60.00, 4
> 0.01 <= 0.011 , 0.0105 , 70.00, 2
> 0.011 <= 0.012 , 0.0115 , 75.00, 1
> 0.012 <= 0.014 , 0.013 , 90.00, 3
> 0.016 <= 0.018 , 0.017 , 95.00, 1
> 0.018 <= 0.0194349 , 0.0187174 , 100.00, 1# target50% 0.0095# target75% 0.012# target99% 0.0191479# target99.9% 0.0194062Code200 : 19 (95.0 %)
Code503 : 1 (5.0 %)
Response Header Sizes : count20 avg 218.85 +/- 50.21 min 0 max 231 sum 4377Response Body/Total Sizes : count 20 avg 652.45 +/- 99.9 min 217 max 676 sum 13049All done20 calls (plus 0 warmup) 10.215 ms avg, 187.8 qps

有趣的是，几乎所有的请求都完成了！ istio-proxy确实允许存在一些误差。

Code 200 : 19 (95.0 %)
Code503 : 1 (5.0 %)

将并发连接数提高到 3 个：

kubectl exec -it $FORTIO_POD  -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://httpbin:8000/getFortio 0.6.2 running at 0 queries per second, 2->2 procs,for5s: http://httpbin:8000/getStarting at max qps with 3 thread(s) [gomax 2]forexactly 30 calls (10 per thread + 0)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)23:51:51 W http.go:617> Parsed non ok code 503 (HTTP/1.1 503)
Ended after71.05365ms : 30 calls. qps=422.22Aggregated Function Time : count30 avg 0.0053360199 +/- 0.004219 min 0.000487853 max 0.018906468 sum 0.160080597# range, mid point, percentile, count>= 0.000487853 <= 0.001 , 0.000743926 , 10.00, 3
> 0.001 <= 0.002 , 0.0015 , 30.00, 6
> 0.002 <= 0.003 , 0.0025 , 33.33, 1
> 0.003 <= 0.004 , 0.0035 , 40.00, 2
> 0.004 <= 0.005 , 0.0045 , 46.67, 2
> 0.005 <= 0.006 , 0.0055 , 60.00, 4
> 0.006 <= 0.007 , 0.0065 , 73.33, 4
> 0.007 <= 0.008 , 0.0075 , 80.00, 2
> 0.008 <= 0.009 , 0.0085 , 86.67, 2
> 0.009 <= 0.01 , 0.0095 , 93.33, 2
> 0.014 <= 0.016 , 0.015 , 96.67, 1
> 0.018 <= 0.0189065 , 0.0184532 , 100.00, 1# target50% 0.00525# target75% 0.00725# target99% 0.0186345# target99.9% 0.0188793Code200 : 19 (63.3 %)
Code503 : 11 (36.7 %)
Response Header Sizes : count30 avg 145.73333 +/- 110.9 min 0 max 231 sum 4372Response Body/Total Sizes : count 30 avg 507.13333 +/- 220.8 min 217 max 676 sum 15214All done30 calls (plus 0 warmup) 5.336 ms avg, 422.2 qps

现在，您将开始看到预期的熔断行为，只有 63.3% 的请求成功，其余的均被熔断器拦截：

Code 200 : 19 (63.3 %)
Code503 : 11 (36.7 %)

查询 istio-proxy状态以了解更多熔断详情:

kubectl exec $FORTIO_POD -c istio-proxy -- pilot-agent request GET stats | grep httpbin |grep pending
cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_active: 0cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_failure_eject: 0cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_overflow: 12cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_total: 39

可以看到 upstream_rq_pending_overflow值 12，这意味着，目前为止已有 12 个调用被标记为熔断

参考：

https://blog.csdn.net/weixin_38754564/article/details/102386272

https://preliminary.istio.io/latest/zh/docs/tasks/traffic-management/circuit-breaking/

https://www.kubernetes.org.cn/5556.html

DDD术语-聚合(Aggregate)、聚合根(AggregateRoot) - Louis军 - 博客园

Tue, 04 Jan 2022 19:13:54 CST

在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject），进而将业务关联紧密的实体和值对象进行组合，构成聚合，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。

那你知道为什么要在限界上下文和实体之间增加聚合和聚合根这两个概念吗？它们的作用是什么？怎么设计聚合？

聚合

在 DDD 中，实体和值对象是很基础的领域对象。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。但实体和值对象都只是个体化的对象，它们的行为表现出来的是个体的能力。

那聚合在其中起什么作用呢？

举个例子。社会是由一个个的个体组成的，象征着我们每一个人。随着社会的发展，慢慢出现了社团、机构、部门等组织，我们开始从个人变成了组织的一员，大家可以协同一致的工作，朝着一个最大的目标前进，发挥出更大的力量。

领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。

你可以这么理解，聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的。按照这种方式设计出来的微服务很自然就是“高内聚、低耦合”的。

聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。比如有的业务场景需要同一个聚合的 A 和 B 两个实体来共同完成，我们就可以将这段业务逻辑用领域服务来实现；而有的业务逻辑需要聚合 C 和聚合 D 中的两个服务共同完成，这时你就可以用应用服务来组合这两个服务。

聚合根

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

传统数据模型中的每一个实体都是对等的，如果任由实体进行无控制地调用和数据修改，很可能会导致实体之间数据逻辑的不一致。而如果采用锁的方式则会增加软件的复杂度，也会降低系统的性能。

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。

其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。

最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。也就是说，聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。

怎样设计聚合？

DDD 领域建模通常采用事件风暴，它通常采用用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

下面我们以保险的投保业务场景为例，看一下聚合的构建过程主要都包括哪些步骤。

第 1 步：采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等等。

第 2 步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。判断一个实体是否是聚合根，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。图中的聚合根分别是投保单和客户实体。

第 3 步：根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。在图中我们构建了客户和投保这两个聚合。

第 4 步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。这里我需要说明一下：投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。从图中我们还可以看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。

第 5 步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。

这就是一个聚合诞生的完整过程了。

聚合的一些设计原则

1. 在一致性边界内建模真正的不变条件。聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。

2. 设计小聚合。如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。

3. 通过唯一标识引用其它聚合。聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。

4. 在边界之外使用最终一致性。聚合内数据强一致性，而聚合之间数据最终一致性。在一次事务中，最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦。

5. 通过应用层实现跨聚合的服务调用。为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。

上面的这些原则是 DDD 的一些通用的设计原则，还是那句话：“适合自己的才是最好的。”

总结

我们总结下聚合、聚合根、实体和值对象它们之间的联系和区别。

聚合的特点：高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和极致的弹性伸缩能力。

一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻辑边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就不再是一件难事了。

聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。

实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。

值对象的特点：无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。值对象尽量只引用值对象。

关于 Spring-WebFlux 的一些想法 - 干货满满张哈希 - 博客园

Mon, 03 Jan 2022 21:10:24 CST

本文是本人在知乎提问 spring webflux现在看来是否成功？下的回答，其他回答也很精彩，如果感兴趣可以查看

现在基于 spring web 的同步微服务有一个非常大的缺陷就是：相对于基于 spring-webflux 的异步微服务，基于 spring-web 的同步微服务没有很好的处理客户端有请求超时配置的情况。当客户端请求超时时，客户端会直接返回超时异常，但是调用的服务端任务，在基于 spring-web 的同步微服务并没有被取消，基于 spring-webflux 的异步微服务是会被取消的。目前，还没有很好的办法在同步环境中可以取消这些已经超时的任务。

Spring-weflux 目前最大的问题，在于很多框架，包括 JDK 本身，有很多 基于 Thread 的 Context，例如 Thread local 这种。还有就是 Java Log 框架的 MDC 的实现，一般都是基于 ThreadLocal 的 Map.还有就是像 redisson 的分布式锁，它让每个线程生成唯一id并和线程绑定，解锁的时候会检查。但是这种设计，与 Spring-Webflux 的 Context 很难兼容。可以看看 Spring cloud sleuth 在 Spring-Webflux 中加入链路信息上下文，并保持，有多麻烦，而且，还有不少的 bug 和漏掉的点，参考：

还有一点比较麻烦，就是和 现有的各种阻塞锁的设计，不兼容，因为响应式编程需要非阻塞。这需要重构成队列排序消费来解决并发竞争，工作量也很大。

然后就是 官方数据库 IO 库，不是 NIO这个问题。不论是Java自带的Future框架，还是 Spring WebFlux，还是 Vert.x，他们都是一种非阻塞的基于Ractor模型的框架（后两个框架都是利用netty实现）。在阻塞编程模式里，任何一个请求，都需要一个线程去处理，如果io阻塞了，那么这个线程也会阻塞在那。但是在非阻塞编程里面，基于响应式的编程，线程不会被阻塞，还可以处理其他请求。举一个简单例子：假设只有一个线程池，请求来的时候，线程池处理，需要读取数据库 IO，这个 IO 是 NIO 非阻塞 IO，那么就将请求数据写入数据库连接，直接返回。之后数据库返回数据，这个链接的 Selector 会有 Read 事件准备就绪，这时候，再通过这个线程池去读取数据处理（相当于回调），这时候用的线程和之前不一定是同一个线程。这样的话，线程就不用等待数据库返回，而是直接处理其他请求。这样情况下，即使某个业务 SQL 的执行时间长，也不会影响其他业务的执行。但是，这一切的基础，是 IO 必须是非阻塞 IO，也就是 NIO（或者 AIO）。官方JDBC没有 NIO，只有 BIO 实现。这样无法让线程将请求写入链接之后直接返回，必须等待响应。但是也就解决方案，就是通过其他线程池，专门处理数据库请求并等待返回进行回调，也就是业务线程池 A 将数据库 BIO 请求交给线程池B处理，读取完数据之后，再交给 A 执行剩下的业务逻辑。这样A也不用阻塞，可以处理其他请求。但是，这样还是有因为某个业务 SQL 的执行时间长，导致B所有线程被阻塞住队列也满了从而A的请求也被阻塞的情况，这是不完美的实现。真正完美的，需要 JDBC 实现 NIO。当然，也可以使用其他异步响应式的三方库，但是非官方的，兼容性以及是否更新及时，还有使用限制什么的也很麻烦。

最后，提一下 Java 本身的 Project Loom，我简单研究过他的实现原理：

JEP 尝鲜系列 3 - 使用虚线程进行同步网络 IO 的不阻塞原理

简单总结即：在虚拟线程中运行的 Java 同步网络 API 会将底层原生 Socket 切换到非阻塞模式。当 Java 代码启用一个 I/O 请求并且这个请求没有立即完成（原生 socket 返回 EAGAIN - 代表"未就绪"/"会阻塞"）的时候，这个底层 socket 会被注册到一个 JVM 内部事件通知机制(Poller)，并且虚拟线程会被 parked。当底层 I/O 操作就绪的时候（有相关事件会到达 Poller），虚拟线程会 unparked 并且底层的 Socket 操作会被重试处理。同步 Java 网络 API 已经被重新实现，相关的 JEP 包括 JEP 353 和 JEP 373. 在虚拟线程中运行时，不能立即完成的 I/O 操作将导致虚拟线程被 parked 。当 I/O 就绪时，虚拟线程将被 unparked。这个实现相对于当前的异步非阻塞 I/O 实现代码来看，更加简单易用，隐藏了很多业务不关心的实现细节。

Project Loom 解决了主要的网络 IO 阻塞问题，并且基本不用改现有代码就能实现纤程，用阻塞的代码风格实现非阻塞的代码（而且和现在的基于 Thread 的上下文框架兼容）。是目前的 Java 架构师 Goetz 最看重的特性之一，目前 Java 17 的很多新特性其实就是为这个 Project Loom 的发布铺路，可以看看 Nicolai 和 Goetz 大神的这个视频，从 19:17 秒开始：

Nicolai 与 Goetz 关于 Java AMA 的讨论

Brian Goetz: "I think Project Loom is going to kill Reactive Programming"(哈哈，有点过于乐观带节奏了，不过值得观望)

不过，虽然期望中是仅需要下面这种代码就可以把现有的线程和线程池替换成虚拟线程：

      Thread thread = Thread.ofVirtual().name("duke").unstarted(runnable);
ThreadFactory factory = Thread.ofVirtual().factory();

ExecutorService b = Executors.newVirtualThreadPool();

但是还有很多问题需要解决：

ThreadLocal 相关的类，由于虚拟线程会无限制的生成，ThreadLocal 的生成也需要重新设计：首先是很多 JDK 中的框架基于 ThreadLocal 的 Probe 实现，例如 ThreadLocalRandom 的初始 Seed。第二是 ThreadLocal 的使用可能会导致 GC 压力增大，因为虚拟线程可以无限制的生成。
依然阻塞实际线程的地方：在同步锁的阻塞还是会阻塞实际的线程，还有文件 IO 等。
修改以上带来的 bug 以及安全问题，由于这些修改动了 JDK 的一些框架的根本，没有经过实际线上应用之前，仅凭单元测试和压测可能很难发现一些细节问题。

不过，现在的 Java 已经在为 Project loom 铺路了，例如：

Java 13 中的 Reimplement the Legacy Socket API以及 Java 15 中的 Reimplement the Legacy DatagramSocket API也是为了优化 Project Loom 对于网络 IO 的兼容
Java 18 中的 JEP 416: Reimplement Core Reflection with Method Handles使用句柄重构反射，减少 Loom 虚拟线程对于 native 栈帧的调用（因为虚拟线程会非常大量，如果每个都访问 native 线程栈则性能有严重问题）
Java 18 中的 JEP 418: Internet-Address Resolution SPI为了解决 DNS 解析时阻塞虚拟线程的实际负载线程的问题
其他还有 JEP draft: Scope Locals为了归一化区域本地变量（例如 ThreadLocal），这样一部分目标也是为了 Loom 的实现

Apache Log4j2 远程代码执行漏洞处置手册 – 绿盟科技技术博客

Sat, 11 Dec 2021 09:40:45 CST

阅读：1,642

一、漏洞概述

12月9日，绿盟科技CERT监测到网上披露Apache Log4j2 远程代码执行漏洞，由于Apache Log4j2某些功能存在递归解析功能，未经身份验证的攻击者通过发送特别构造的数据请求包，可在目标服务器上执行任意代码。漏洞PoC已在网上公开，默认配置即可进行利用，该漏洞影响范围极广，建议相关用户尽快采取措施进行排查与防护。

12月10日，绿盟科技CERT发现Apache Log4j 2.15.0-rc1 版本仅修复LDAP和增加了host白名单，可以被绕过利用，官方发布了Apache Log4j 2.15.0-rc2版本进行修复，增加了对urI异常的处理。

Apache Log4j2是一款开源的Java日志框架，被广泛地应用在中间件、开发框架与Web应用中，用来记录日志信息。

漏洞成功复现截图：

2.15.0-rc1绕过复现截图：

漏洞细节	漏洞PoC	漏洞EXP	在野利用
已公开	已公开	已公开	存在

参考链接： https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues

二、影响范围

受影响版本

2.0 <= Apache Log4j <= 2.15.0-rc1

注：使用Apache Log4j 1.X版本的应用，若开发者对JMS Appender利用不当，可对应用产生潜在的安全影响。

供应链影响范围：

已知受影响应用及组件：

Apache Solr

Apache Struts2

Apache Flink

Apache Druid

spring-boot-strater-log4j2

不受影响版本

Apache log4j-2.15.0-rc2（与官网的2.15.0稳定版相同）

三、漏洞检测

3.1 人工检测

1、相关用户可根据Java jar解压后是否存在org/apache/logging/log4j相关路径结构，判断是否使用了存在漏洞的组件，若存在相关Java程序包，则很可能存在该漏洞。

2、若程序使用Maven打包，查看项目的pom.xml文件中是否存在下图所示的相关字段，若版本号为小于2.15.0-rc2，则存在该漏洞。

3、若程序使用gradle打包，可查看build.gradle编译配置文件，若在dependencies部分存在org.apache.logging.log4j相关字段，且版本号为小于2.15.0-rc2，则存在该漏洞。

3.2 攻击排查

1、攻击者在利用前通常采用dnslog方式进行扫描、探测，常见的漏洞利用方式可通过应用系统报错日志中的”javax.naming.CommunicationException”、”javax.naming.NamingException: problem generating object using object factory”、”Error looking up JNDI resource”关键字进行排查。

2、攻击者发送的数据包中可能存在”${jndi:}” 字样，推荐使用全流量或WAF设备进行检索排查。

3.3 产品检测

绿盟科技远程安全评估系统（RSAS）与WEB应用漏洞扫描系统(WVSS)、网络入侵检测系统（IDS）、综合威胁探针（UTS）已具备对该漏洞的扫描与检测能力，请有部署以上设备的用户升级至最新版本。

关于RSAS的升级配置指导，请参考如下链接：

https://mp.weixin.qq.com/s/SgOaCZeKrNn-4uR8Yj_C3Q

3.4 申请云检测

绿盟科技面向用户提供远程检测服务，因该漏洞的检测存在一定风险，相关客户如需要申请云检测，请联系销售或项目经理沟通，或用个人的公司邮箱发邮件至rs@nsfocus.com，在正文中提供需要扫描的资产清单，可以扫描的时间，联系方式，服务人员会与您联系。

7x24h客服咨询热线： 400-818-6868转2

四、漏洞防护

4.1 官方升级

目前官方已发布log4j-2.15.0-rc2测试版本与apache-log4j-2.15.0稳定版修复该漏洞，受影响用户可先将Apache Log4j2所有相关应用到以上版本，下载链接：https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2或https://logging.apache.org/log4j/2.x/download.html

注：可能出现不稳定的情况，建议用户在备份数据后再进行升级。

升级供应链中已知受影响的应用及组件：Apache Solr、Apache Struts2、Apache Flink、Apache Druid、spring-boot-strater-log4j2

4.2 产品防护

针对此漏洞，绿盟科技WEB应用防护系统(WAF)与网络入侵防护系统(IPS)已发布规则升级包，请相关用户升级规则，以形成安全产品防护能力。安全防护产品规则版本号如下：

产品规则升级的操作步骤详见如下链接：

IPS：https://mp.weixin.qq.com/s/DxQ3aaap8aujqZf-3VbNJg

WAF：https://mp.weixin.qq.com/s/7F8WCzWsuJ5T2E9e01wNog

4.3 临时防护措施

若相关用户暂时无法进行升级操作，可先用下列措施进行临时缓解：

1、添加jvm启动参数:-Dlog4j2.formatMsgNoLookups=true

2、在应用classpath下添加log4j2.component.properties配置文件，文件内容为：log4j2.formatMsgNoLookups=true

3、建议JDK使用11.0.1、8u191、7u201、6u211及以上的高版本

4、限制受影响应用对外访问互联网，并在边界对dnslog相关域名访问进行检测。

部分公共dnslog平台如下：

ceye.io

dnslog.link

dnslog.cn

dnslog.io

tu4.org

burpcollaborator.net

s0x.cn

4.4 平台监测

绿盟企业安全平台（ESP-H）与绿盟智能安全运营平台（ISOP）已经具备针对此漏洞的检测能力，部署有绿盟科技平台类产品的用户，可实现对漏洞的平台监测能力。

安全平台	升级包/规则版本号
ESP-H（绿盟企业安全平台）	使用最新规则升级包 vulnDict-2021121001.dat
ISOP（绿盟智能安全运营平台）	升级攻击识别规则包至最新 attack_rule.1.0.0.1.1048648.dat

声明

本安全公告仅用来描述可能存在的安全问题，绿盟科技不为此安全公告提供任何保证或承诺。由于传播、利用此安全公告所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，绿盟科技以及安全公告作者不为此承担任何责任。

Spring Cloud Alibaba：支持的几种服务消费方式（RestTemplate、WebClient、Feign）_饭团小哥哥iop的博客-CSDN博客

Thu, 09 Dec 2021 17:46:02 CST

概述

关于消费者通过Nacos来消费注册的服务时可以使用RestTemplate、WebClient、Feign等方式，他们之间有什么不一样？

使用RestTemplate

RestTemplate来向服务的某个具体实例发起HTTP请求，但是具体的请求路径是通过拼接完成的，对于开发体验并不好。但是，实际上，在Spring Cloud中对RestTemplate做了增强，只需要稍加配置，就能简化之前的调用方式。

@EnableDiscoveryClient

@SpringBootApplication

public class TestApplication {

public static void main(String[] args) {

SpringApplication.run(TestApplication.class, args);

}

@Slf4j

@RestController

static class TestController {

@Autowired

RestTemplate restTemplate;

@GetMapping("/test")

public String test() {

String result = restTemplate.getForObject("http://alibaba-nacos-discovery-server/hello?name=didi", String.class);

return "Return : " + result;

}

@Bean

@LoadBalanced

public RestTemplate restTemplate() {

return new RestTemplate();

}

在定义RestTemplate的时候，增加了@LoadBalanced注解，而在真正调用服务接口的时候，原来host部分是通过手工拼接ip和端口的，直接采用服务名的时候来写请求路径即可

@LoadBalanced : 是在通过注册中心拿到服务提供者应用名，通过负载均衡器选出节点，并替换服务名部分为具体的ip和端口，从而实现基于服务名的负载均衡调用。

使用WebClient

WebClient是Spring 5中最新引入的，可以将其理解为reactive版的RestTemplate。下面举个具体的例子，它将实现与上面RestTemplate一样的请求调用：

@EnableDiscoveryClient

@SpringBootApplication

public class TestApplication {

public static void main(String[] args) {

SpringApplication.run(TestApplication.class, args);

}

@Slf4j

@RestController

static class TestController {

@Autowired

private WebClient.Builder webClientBuilder;

@GetMapping("/test")

public Mono<String> test() {

Mono<String> result = webClientBuilder.build()

.get()

.uri("http://alibaba-nacos-discovery-server/hello?name=didi")

.retrieve()

.bodyToMono(String.class);

return result;

}

@Bean

@LoadBalanced

public WebClient.Builder loadBalancedWebClientBuilder() {

return WebClient.builder();

}

在定义WebClient.Builder的时候，也增加了@LoadBalanced注解，其原理与之前的RestTemplate时一样的。

使用Feign

第一步：在pom.xml中增加openfeign的依赖：

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-openfeign</artifactId>

</dependency>

第二步：定义Feign客户端和使用Feign客户端：

@EnableDiscoveryClient

@SpringBootApplication

@EnableFeignClients //开启扫描Spring Cloud Feign客户端的功能

public class TestApplication {

public static void main(String[] args) {

SpringApplication.run(TestApplication.class, args);

}

@Slf4j

@RestController

static class TestController {

@Autowired

Client client;

@GetMapping("/test")

public String test() {

String result = client.hello("didi");

return "Return : " + result;

}

@FeignClient("alibaba-nacos-discovery-server") //指定这个接口所要调用的服务名称，接口中定义的各个函数使用Spring MVC的注解就可以来绑定服务提供方的REST接口

interface Client {

@GetMapping("/hello")

String hello(@RequestParam(name = "name") String name);

}

学习 kubernetes 的10个技巧或建议_科技D人生-CSDN博客

Thu, 09 Dec 2021 14:11:14 CST

一、学 GO 语言

Kubernetes是基于 GO 编写的，所有的组件都是基于 GO 编写的，kubernetes甚至使用GO编写了一个客户端。学习使用 GO 语言编写的 Kubernetes 客户端并在 Kubernetes 中使用它，这是我对所以使用 Kubernetes 集群的朋友提出的最大的建议。

二、使用探针来检测应用的状态

在Kubernetes中支持配置探针。kubelet使用探针来确定pod和应用程序是否健康。这里提供了两种类型来实现这一功能，Readiness探针和Liveiness探针。Readiness探针用于确定容器何时准备好接收流量。Liveiness探针用于确定容器是健康的还是需要重新启动。在deployment 的yaml中，可以直接定义Readiness 探针和Liveiness探针，还可以设置超时、重试和延迟等参数。

三、充分利用Label标签

标签是Kubernetes的基础配置之一。它允许进群内资源与资源之间松散耦合，还允许基于标签进行查询。你甚至可以使用Kubernetes go客户端，根据标签查看事件。你几乎可以使用标签做任何事情，一个典型的例子是是同一个集群中存在多个环境。假设开发和QA使用相同的集群。这意味着你的集群可能同时进行QA和开发。要以一种简单的方式实现这一点，你必须使用服务对象，一个服务对象在app上执行标签select: app-a以及environment: dev，另一个服务对象在app上打上:app-a标签，但将环境从dev切换到QA。这将为您提供两个相同的应用程序，每个应用程序具有不同的端点，允许同时进行测试。

四、随时记得回收废弃的资源

Kubernetes是一个非常强大的系统，但是就像任何系统一样，它也会出现阻塞。只有一个不连接其他任何服务的服务才不会让系统陷入停滞。当kubernetes规模较小时，几台或者几十台，可能不会有任何问题。但如果把服务扩大到上万，kubelet就会可是出现阻塞。因为Kubelet不仅会对你发出的指令进行校验，同时还要做内部检查。因此，切记，从现在开始，养成习惯。如果你需要删除deployment(或相关的任何内容)，请确保用它清理了所有其他内容，比如service，volume等等，避免日后影响kubelet的查询效率。

五、充分利用PodDisruptionBudget控制器

如何保证在kubernetes集群中的应用程序总能正常运行?答案是使用PodDisruptionBudget控制器。在进行kubectl drain操作时，kubernetes会根据PodDisruptionBudget控制器判断应用POD集群数量，进而保证在业务不中断或业务SLA不降级的情况下进行应用POD销毁。PDB(PodDisruptionBudget)应该放在每个拥有一个以上实例的deployment上。我们可以使用简单yaml为集群创建PDB，并使用标签选择器确定PDB应该作用在哪些带有标签的资源上。注意:PDB只考虑主动中断，硬件故障之类的情况不在PDB考虑范围内。PDB可以参考如下例子：

      apiVersion: policy/v1beta1 
 kind: PodDisruptionBudget 
 metadata: 
 name: app-a-pdb 
 spec: 
 minAvailable: 2 
 selector: 
 matchLabels: 
 app: app-a

在众多配置中，我们最需要关注两个选项是matchlabel和minAvailable部分。匹配标签是kubernetes查看部署是否附加到PDB。例如:如果我有一个带有标签app: app-a的部署和一个带有标签app: app-b的部署，那么示例PDB将只应用于第一个部署。minAvailable会在kubernetes在执行类似 kubectl drain 的操作时起作用。假设app-a正在节点1上运行，如果在节点1上执行drain，那么它将只驱逐app-a，即当前至少有2个app在运行。这让你可以控制在给定时间需要运行多少实例。

六、使用Bash完成kubectl命令

这可能是最简单也是使用Kubernetes时最有帮助的方法之一。要添加自动完成(如果使用bash)，只需运行以下命令:

      echo “source <(kubectl completion bash)” >> ~/.bashrc

这将在.bashrc中添加自动完成功能，这样无论何时打开shell，它都会启用它。你将会发现使用自动补全功能对于输入长指令来说是尤为方便的，尤其是当需要指定命名空间时。

七、向命名空间添加默认内存限制和cpu限制

人们总会犯错，这是常有的事。如果有人编写了一个应用程序，比方说，每秒打开一个数据库的连接，但是从来没有关闭它，这时就会导致在集群上的应用程序中出现内存泄漏。如果将它们部署到没有设置限制的集群中，则可能导致节点崩溃。为了防止这种情况，Kubernetes允许根据每个命名空间设置默认限制。要做到这一点，只需创建一个yaml来限制范围并将其应用于这个命名空间。下面是yaml的一个例子：

      apiVersion: v1 
 kind: LimitRange 
 metadata: 
 name: mem-limit-range 
 spec: 
 limits: 
 - default: 
 memory: 512Mi 
 defaultRequest: 
 memory: 256Mi 
 type: Container

八、用Kubelet辅助清理docker镜像

kubelet默认情况下已经做到了这一点。如果在启动kubelet时没有设置任何标志，那么当var/lib/docker达到90%的容量时，它将启动垃圾收集。这一功能非常贴心，但请注意，kubelet并没有为node节点设置默认阈值(在Kubernetes 1.7之前)。试想这种情况，你的/var/lib/docker可能只占用了50%的磁盘空间，但此时全部的物理机磁盘空间已经被占满。这会给你的容器服务带来很多问题。如果您目前正在使用的kubelet版本是1.4-1.6，那么你必须显式为kubelet添加如下标志。

      --eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

这些配置在1.7或更高版本时是默认配置项。1.6版本默认情况下不监视 node 节点的资源利用率，因此添加该标志将解决这个问题。

九、Minikube ——迷你但功能强大

Minikube绝对是本地运行Kubernetes集群最简单的方法了。一旦一切都安装好了，简单的命令就能运行它。

      minikube start

这时我们将在本地运行一个 K8S 集群。当你想要在本地构建一个应用程序并在本地运行它时，这是有个技巧需要注意。如果你没有运行其他命令，当你执行docker build时，仍然会在物理机上构建一个映像。要让你的docker build将镜像push到本地kubernetes集群，你需要使用以下命令:

      eval $(minikube docker-env)

这能让你在本地kubernetes集群上构建应用程序。

十、不要把kubectl权限开放给所有人

这可能说起来很简单，但是当多个团队部署应用到一个 kubernetes 集群时，情况就可能变得很复杂。切记不要把 kubectl 权限开放给每个人。个人建议是，根据命名空间来区分隔离每个团队，然后使用RBAC策略只允许各自团队访问各自的命名空间。如果我们把kubectl权限开放给每个人，那么在pod级上进行读取、创建和删除访问时，可能让人抓狂，因为误操作的情况会经常发生。为此，我们应该只允许管理员有权访问，从而将管理集群和部署集群的人员权限区分开。

千万不要用新技术重新开发一次啊_阿朱=行业趋势+开发管理+架构-CSDN博客

Sun, 05 Dec 2021 08:02:02 CST

（1）在基础设施上做事

我个人有个洞察：2023年，中国云计算技术开始成熟，可依赖使用了。也就是说你过去是买它的云服务器，然后在服务器里安装自己的东西。但2023年以后，你不需要这么搞了，它上面有啥数据库&数据湖仓、中间件、运维&安全等等你都可以直接使用了，你不需要为你的应用基础做思考，你只关注你的应用就行了。

也就是说，你以后的工作基础是在以下这些基础设施之上工作的：

1、应用基础设施层：

电子签章、在线支付、电子发票、电子档案、银企联云、税企联云；

多端协同门户、统一身份认证管理、审批工作流引擎、IM消息

低代码开发平台、RPA、Open API开放平台、应用商店

2、中间件层：

多媒体处理中间件服务：音视频处理、视频直播中间件、云呼叫中心VOIP...

AI处理服务：视觉识别、OCR识别；语音识别；NLP；数据挖掘

IoT处理服务：IoT接入平台

3、数据层：

NewSQL、NoSQL；主数据管理；数据仓库；数字孪生、报表图表

4、IaaS层：

IaaS云原生（容器、CI/CD、多中心部署/多云部署、灰度发布）

Devops运维、安全

我看现在政府、央企大型国企，都在建设自己的政务云、国资云，而且都先从IaaS云原生开始建起，往上搭大数据平台，再搭企业协同平台，接下来才是在这个基础之上一块块搭应用。

你想想你如果在这样的基础设施之上做应用，你会怎么做应用？

（2）应用生态合作

即使你做应用，我也建议你不要自己全干应用，而是分层找生态合作。

1、个性化应用层：找外包开发公司即可。尤其是在上述的基础设施之上开发，比过去容易的多

2、行业业务应用层：找行业ISV即可，他们做的行业业务应用，挺专业

3、价值链应用：

研发设计管理-供应链管理-生产制造管理-销售管理-售后管理，这条价值链的应用找ERP厂商即可。

但研发设计工具、供应链在线采购交易、生产制造控制、营销与销售、售后维修维保，这条价值链应用，你得找不同的专业厂商来搞，这不是管理，这是真正拿工具来开展业务，没这么工具，业务都开展不了。这是很多人分不清业务工具和管控工具的。

4、职能应用：

财务、法务、人力属于职能应用。但人力也有人力管理和人力在线服务两种类别，如招聘管理是人力管理，但招聘本身是人力在线服务。学习管理系统是人力管理，但在线学习平台/知识付费平台是人力在线服务。

企业支付管理这是很多人不熟悉的。它有很多分支，如企业营销物料采购（营销部是Onwer、企业采购部是执行或管控）、企业MRO易耗品采购（生产资料部是Onwer、企业采购部是执行或管控）、员工商旅采购（行政部是Onwer、企业采购部或财务部是执行或管控）、员工福利采购（行政部是Onwer、企业采购部或行政部是执行或管控）、临时用工采购（人力部是Onwer、企业采购部是执行或管控）。这么多分枝，估计你得寻找不同的供应商采购一一针对性搞定。

不管是财务、人力，都直接找最专业的厂商分别搞定即可。

（3）应用分类处理

Gartner在2015年提出过敏态和稳态两种应用分类。

我个人理解，敏态偏外部开放性协作、快聚快散，而稳态偏内部封闭管控。用稳态架构做敏态、用敏态架构做稳态，都是找死。

即使是过去做企业内部管控系统，我过去都是应用分类处理，如

信息记录类应用

信息追溯类应用

高性能高精确计费收费交易类应用

流程勾稽关联协作类应用

预测推理、洞察决策类应用

我过去都是不同分类的应用，都有专门的架构设计。

（4）技术驱动产品设计

从2015年以来，出现了许多新技术。我们可以基于这些新技术，重新考虑应用应该如何设计。

一、数据采集环节

1、优先用AIoT技术做数据自动采集

2、其次用客户在线自助、上下游在线协同做数据自动采集

3、最后不得不员工录入时，优先用移动App进行限制性录入

4、最后不得不员工录入时，其次分场景分角色分工作流程阶段进行分段录入

二、业务过程处理环节

1、业务流程，主要通过数智化技术进行自动的、智能的：计划编制、资源调度、消息推送

2、优先用专业的单点应用，单点应用之间用协同平台、RPA平台、OpenAPI平台联动在一起

3、业务追溯，可尝试使用区块链技术

三、数据输出环节

可以使用搜索、推荐技术，而非过去的查询方法

可以使用人工智能的问答会话技术、Data2Text技术，而非过去的查询技术

可以使用数字孪生/BIM/GIS技术，而非过去的报表和图表

四、我建议做好用户体验全程管理

如用户画像、用户行为跟踪、AB测试，根据用户的行为观察来持续改进应用。而非自己拍脑门、做需求调研。

（5）模块分离

80%人用的20%功能，持续优化。

20%人用的各色特殊80%碎片功能，全部剥离到应用商店

这是以后做应用的设计原则。

（6）交付简化

企业软件交付是个最头疼的事情，经常涉及的配置有：主数据、业务参数、权限/流程、模板。

一、主数据

采取产业主数据服务，而非自己录入主数据

在主数据平台维护信息及标签图谱，而非在各个基础数据维护模块维护主数据

二、模板

采取模板应用商店+模板配置。我举个例子，如各种报销单，这典型是模板要搞定的事，而非系统要搞定的事

三、功能

采取插件应用商店+插件配置。我举个例子，如各种营销促销玩法，这典型是插件要搞定d 事，而非系统要搞定的事

四、权限

采取人员-岗位标签方式、并且内置岗位权限模板，而不是给每个员工设置详细权限

spring cloud kubernetes在pod模式下服务调用源码解析_水中加点糖-CSDN博客

Wed, 01 Dec 2021 07:34:35 CST

之所以只看pod模式下的服务调用链路，是因为在service模式下不会走缓存，效率低，并且负载均衡模式不能由spring cloud框架所控制，不太灵活

需要关注的几个类：

DiscoveryClient

org.springframework.cloud.loadbalancer.blocking.client.BlockingLoadBalancerClient

org.springframework.cloud.loadbalancer.blocking.client.BlockingLoadBalancerClient#choose(java.lang.String, org.springframework.cloud.client.loadbalancer.Request)

      public<T>ServiceInstancechoose(StringserviceId,Request<T>request){ReactiveLoadBalancer<ServiceInstance>loadBalancer=this.loadBalancerClientFactory.getInstance(serviceId);if(loadBalancer==null){returnnull;}else{Response<ServiceInstance>loadBalancerResponse=(Response)Mono.from(loadBalancer.choose(request)).block();returnloadBalancerResponse==null?null:(ServiceInstance)loadBalancerResponse.getServer();}}

org.springframework.cloud.loadbalancer.support.LoadBalancerClientFactory#getInstance

      publicReactiveLoadBalancer<ServiceInstance>getInstance(StringserviceId){return(ReactiveLoadBalancer)this.getInstance(serviceId,ReactorServiceInstanceLoadBalancer.class);}

feign调用
implements ReactorServiceInstanceLoadBalancer

feign调用时用的org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient中的execute方法调用的。
其中获取服务列表的代码为：ServiceInstance instance = loadBalancerClient.choose(serviceId, lbRequest);
也就是org.springframework.cloud.loadbalancer.blocking.client.BlockingLoadBalancerClient#choose(java.lang.String, org.springframework.cloud.client.loadbalancer.Request)这个方法,其中用的此方法：

      ReactiveLoadBalancer<ServiceInstance> loadBalancer = this.loadBalancerClientFactory.getInstance(serviceId);

其中的loadBalancerClientFactory字段是在BlockingLoadBalancerClient初始化时设置的。需要看一下loadBalancerClientFactory传入的地方。
也就是org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient类初始化时LoadBalancerClient注入进去的是哪个类。
这个类的属于commons的包里，看一下其中loadbalancer中关于初始化的地方。

代码在此处:
org.springframework.cloud.loadbalancer.config.BlockingLoadBalancerClientAutoConfiguration#blockingLoadBalancerClient

      @Bean
	@ConditionalOnBean(LoadBalancerClientFactory.class)
	@ConditionalOnMissingBean
	public LoadBalancerClient blockingLoadBalancerClient(LoadBalancerClientFactory loadBalancerClientFactory) {
		return new BlockingLoadBalancerClient(loadBalancerClientFactory);
	}

这里注入了一个LoadBalancerClientFactory，这经的注入代码在此处:org.springframework.cloud.loadbalancer.config.LoadBalancerAutoConfiguration#loadBalancerClientFactory

      @ConditionalOnMissingBean
	@Bean
	public LoadBalancerClientFactory loadBalancerClientFactory(LoadBalancerClientsProperties properties) {
		LoadBalancerClientFactory clientFactory = new LoadBalancerClientFactory(properties);
		clientFactory.setConfigurations(this.configurations.getIfAvailable(Collections::emptyList));
		return clientFactory;
	}

这个factory的代码中的getInstance方法：

      @Override
	public ReactiveLoadBalancer<ServiceInstance> getInstance(String serviceId) {
		return getInstance(serviceId, ReactorServiceInstanceLoadBalancer.class);
	}

获取的是ReactorServiceInstanceLoadBalancer.class

则需要找到ReactorServiceInstanceLoadBalancer的实现类:
org.springframework.cloud.loadbalancer.annotation.LoadBalancerClientConfiguration#reactorServiceInstanceLoadBalancer

      @Bean
	@ConditionalOnMissingBean
	public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment,
			LoadBalancerClientFactory loadBalancerClientFactory) {
		String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
		return new RoundRobinLoadBalancer(
				loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name);
	}

其中用懒加载获取的ServiceInstanceListSupplier的bean。

那么如果是service模式下,其中的ServiceInstanceListSupplier的实现类为：org.springframework.cloud.kubernetes.client.loadbalancer.KubernetesClientServicesListSupplier，其初始化代码为：

      @Bean
	@ConditionalOnProperty(name = "spring.cloud.kubernetes.loadbalancer.mode", havingValue = "SERVICE")
	KubernetesServicesListSupplier kubernetesServicesListSupplier(Environment environment, CoreV1Api coreV1Api,
			KubernetesClientServiceInstanceMapper mapper, KubernetesDiscoveryProperties discoveryProperties,
			KubernetesNamespaceProvider kubernetesNamespaceProvider) {
		return new KubernetesClientServicesListSupplier(environment, mapper, discoveryProperties, coreV1Api,
				kubernetesNamespaceProvider);
	}

如果是pod模式，则使用的默认的初始化代码:org.springframework.cloud.loadbalancer.annotation.LoadBalancerClientConfiguration.ReactiveSupportConfiguration#discoveryClientServiceInstanceListSupplier
其代码为：

      @Bean
		@ConditionalOnBean(ReactiveDiscoveryClient.class)
		@ConditionalOnMissingBean
		@Conditional(DefaultConfigurationCondition.class)
		public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
				ConfigurableApplicationContext context) {
			return ServiceInstanceListSupplier.builder().withDiscoveryClient().withCaching().build(context);
		}

其中withDiscoveryClient方法：

      /**
	 * Sets a {@link ReactiveDiscoveryClient}-based
	 * {@link DiscoveryClientServiceInstanceListSupplier} as a base
	 * {@link ServiceInstanceListSupplier} in the hierarchy.
	 * @return the {@link ServiceInstanceListSupplierBuilder} object
	 */
	public ServiceInstanceListSupplierBuilder withDiscoveryClient() {
		if (baseCreator != null && LOG.isWarnEnabled()) {
			LOG.warn("Overriding a previously set baseCreator with a ReactiveDiscoveryClient baseCreator.");
		}
		this.baseCreator = context -> {
			ReactiveDiscoveryClient discoveryClient = context.getBean(ReactiveDiscoveryClient.class);

			return new DiscoveryClientServiceInstanceListSupplier(discoveryClient, context.getEnvironment());
		};
		return this;
	}

其中ReactiveDiscoveryClient的bean为：

      @Bean
	@ConditionalOnMissingBean
	public KubernetesInformerReactiveDiscoveryClient kubernetesReactiveDiscoveryClient(
			KubernetesNamespaceProvider kubernetesNamespaceProvider, SharedInformerFactory sharedInformerFactory,
			Lister<V1Service> serviceLister, Lister<V1Endpoints> endpointsLister,
			SharedInformer<V1Service> serviceInformer, SharedInformer<V1Endpoints> endpointsInformer,
			KubernetesDiscoveryProperties properties) {
		return new KubernetesInformerReactiveDiscoveryClient(kubernetesNamespaceProvider, sharedInformerFactory,
				serviceLister, endpointsLister, serviceInformer, endpointsInformer, properties);
	}

public class KubernetesInformerReactiveDiscoveryClient implements ReactiveDiscoveryClient

所以由此可以看出，k8s中pod模式下用的是KubernetesInformerReactiveDiscoveryClient。
所以如果想要到达k8s模式下的个性化定制，可以参考官方文档https://docs.spring.io/spring-cloud-commons/docs/current/reference/html/#hints-based-loadbalancing，
参考代码：
org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplierBuilder#withHints

基于 Istio 的全链路灰度方案探索和实践 - 阿里巴巴云原生 - 博客园

Sun, 07 Nov 2021 07:30:48 CST

作者｜曾宇星（宇曾）
审核&校对：曾宇星（宇曾）
编辑&排版：雯燕

背景

微服务软件架构下，业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事，随着所拆分出微服务数量的不断增大其难度也愈大。这一整套测试系统所需付出的机器成本往往也不低，为了保证应用新版本上线前的功能正确性验证效率，这套系统还必须一直单独维护好。当业务变得庞大且复杂时，往往还得准备多套，这是整个行业共同面临且难解的成本和效率挑战。如果能在同一套生产系统中完成新版本上线前的功能验证的话，所节约的人力和财力是相当可观的。

除了开发阶段的功能验证，生产环境中引入灰度发布才能更好地控制新版本软件上线的风险和爆炸半径。灰度发布是将具有一定特征或者比例的生产流量分配到需要被验证的服务版本中，以观察新版本上线后的运行状态是否符合预期。

阿里云 ASM Pro（相关链接请见文末）基于 Service Mesh 所构建的全链路灰度方案，能很好帮助解决以上两个场景的问题。

ASM Pro 产品功能架构图：

核心能力使用的就是上图扩展的流量打标和按标路由以及流量 Fallback 的能力，下面详细介绍说明。

场景说明

全链路灰度发布的常见场景如下：

以 Bookinfo 为例，入口流量会带上期望的 tag 分组，sidecar 通过获取请求上下文（Header 或 Context) 中的期望 tag，将流量路由分发到对应 tag 分组，若对应 tag 分组不存在，默认会 fallback 路由到 base 分组，具体 fallback 策略可配置。接下来详细描述具体的实现细节。

入口流量的 tag 标签，一般是在网关层面基于类似 tag 插件的方式，将请求流量进行打标。比如将 userid 处于一定范围的打上代表灰度的 tag，考虑到实际环境网关的选择和实现的多样性，网关这块实现不在本文讨论的范围内。

下面我们着重讨论基于 ASM Pro 如何做到全链路流量打标和实现全链路灰度。

实现原理

Inbound 是指请求发到 App 的入口流量，Outbond 是指 App 向外发起请求的出口流量。

上图是一个业务应用在开启 mesh 后典型流量路径：业务 App 接收到一个外部请求 p1，接着调用背后所依赖的另一个服务的接口。此时，请求的流量路径是 p1->p2->p3->p4，其中 p2 是 Sidecar 对 p1 的转发，p4 是 Sidecar 对 p3 的转发。为了实现全链路灰度，p3 和 p4 都需要获取到 p1 进来的流量标签，才能将请求路由到标签所对应的后端服务实例，且 p3 和 p4 也要带上同样的标签。关键在于，如何让标签的传递对于应用完全无感，从而实现全链路的标签透传，这是全链路灰度的关键技术。ASM Pro 的实现是基于分布式链路追踪技术（比如，OpenTracing、OpenTelemetry 等）中的 traceId 来实现这一功能。

在分布式链路追踪技术中，traceId 被用于唯一地标识一个完整的调用链，链路上的每一个应用所发出的扇出（fanout）调用，都会通过分布式链路追踪的 SDK 将源头的 traceId 给带上。ASM Pro 全链路灰度解决方案的实现正是建立在这一分布式应用架构所广泛采纳的实践之上的。

上图中，Sidecar 本来所看到的 inbound 和 outbound 流量是完全独立的，无法感知两者的对应关系，也不清楚一个 inbound 请求是否导致了多个 outbound 请求的发生。换句话说，图中 p1 和 p3 两个请求之间是否有对应关系 Sidecar 并不知情。

在 ASM Pro 全链路灰度解决方案中，通过 traceId 将 p1 和 p3 两个请求做关联，具体说来依赖了 Sidecar 中的 x-request-id 这个 trace header。Sidecar 内部维护了一张映射表，其中记录了 traceId 和标签的对应关系。当 Sidecar 收到 p1 请求时，将请求中的 traceId 和标签存储到这张表中。当收到 p3 请求时，从映射表中查询获得 traceId 所对应的标签并将这一标签加入到 p4 请求中，从而实现全链路的打标和按标路由。下图大致示例了这一实现原理。

换句话说，ASM Pro 的全链路灰度功能需要应用使用分布式链路追踪技术。如果想运用这一技术的应用没有使用分布式链路追踪技术的话不可避免地涉及到一定的改造工作。对于 Java 应用来说，仍可以考虑采用 Java Agent 以 AOP 的方式让业务无需改造地实现 traceId 在 inbound 和 outbound 之间透传。

实现流量打标

ASM Pro 中引入了全新的 TrafficLabel CRD 用于定义 Sidecar 所需透传的流量标签从哪里获取。下面所例举的 YAML 文件中，定义了流量标签来源和需要将标签存储 OpenTracing 中（具体是 x-trace 头）。其中流量标的名为 trafficLabel，取值依次从 $getContext(x-request-id) 到最后从本地环境的$(localLabel)中获取。

      apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  name: default
spec:
  rules:
  - labels:
      - name: trafficLabel
        valueFrom:
        - $getContext(x-request-id)  //若使用aliyun arms,对应为x-b3-traceid
        - $(localLabel)
    attachTo:
    - opentracing
    # 表示生效的协议，空为都不生效，*为都生效
    protocols: "*"

CR 定义包含两块，即标签的获取和存储。

获取逻辑：先根据协议上下文或者头（Header 部分）中的定义的字段获取流量标签，如果没有，会根据 traceId 通过 Sidecar 本地记录的 map 获取, 该 map 表中保存了 traceId 对应流量标识的映射。若 map 表中找到对应映射，会将该流量打上对应的流量标，若获取不到，会将流量标取值为本地部署对应环境的 localLabel。localLabel 对应本地部署的关联 label，label 名为 ASM_TRAFFIC_TAG。

本地部署对应环境的标签名为"ASM_TRAFFIC_TAG"，实际部署可以结合 CI/CD 系统来关联。

存储逻辑：attachTo 指定存储在协议上下文的对应字段，比如 HTTP 对应 Header 字段，Dubbo 对应 rpc context 部分，具体存储到哪一个字段中可配置。

有了TrafficLabel 的定义，我们知道如何将流量打标和传递标签，但光有这个还不足以做到全链路灰度，我们还需要一个可以基于 trafficLabel 流量标识来做路由的功能，也就是“按标路由”，以及路由 fallback 等逻辑，以便当路由的目的地不存在时，可以实现降级的功能。

按流量标签路由

这一功能的实现扩展了 Istio 的 VirtualService 和 DestinationRule。

在 DestinationRule 中定义 Subset

自定义分组 subset 对应的是 trafficLabel 的 value

      apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp/*
  subsets:
  - name: myproject            # 项目环境
    labels:
      env: abc
  - name: isolation            # 隔离环境
    labels:
      env: xxx                 # 机器分组
  - name: testing-trunk        # 主干环境
    labels:
      env: yyy
  - name: testing              # 日常环境
    labels:
      env: zzz
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: myapp
spec:
  hosts: 
        - myapp/*
  ports:
  - number: 12200
    name: http
    protocol: HTTP
    endpoints:
      - address: 0.0.0.0
        labels:
            env: abc
      - address: 1.1.1.1
        labels:
            env: xxx
      - address: 2.2.2.2
        labels:
            env: zzz
      - address: 3.3.3.3
        labels:
            env: yyy

Subset 支持两种指定形式：

labels 用于匹配应用中带特定标记的节点（endpoint）；
通过 ServiceEntry 用于指定属于特定 subset 的 IP 地址，注意这种方式与labels指定逻辑不同，它们可以不是从注册中心（K8s 或者其他）拿到的地址，直接通过配置的方式指定。适用于 Mock 环境，这个环境下的节点并没有向服务注册中心注册。

在 VirtualService 中基于 subset

1）全局默认配置

route 部分可以按顺序指定多个 destination，多个 destination 之间按照 weight 值的比例来分配流量。
每个 destination 下可以指定 fallback 策略，case 标识在什么情况下执行 fallback，取值：noinstances（无服务资源）、noavailabled（有服务资源但是服务不可用），target 指定 fallback 的目标环境。如果不指定 fallback，则强制在该 destination 的环境下执行。
按标路由逻辑，我们通过改造 VirtualService，让 subset 支持占位符 $trafficLabel, 该占位符 $trafficLabel 表示从请求流量标中获取目标环境，对应 TrafficLabel CR 中的定义。

全局默认模式对应泳道，也就是单个环境内封闭，同时指定了环境级别的 fallback 策略。自定义分组 subset 对应的是 trafficLabel 的 value

配置样例如下：

      apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: default-route
spec:
  hosts:                     # 对所有应用生效
  - */*
  http:
  - name: default-route
    route:
    - destination:
        subset: $trafficLabel
      weight: 100
      fallback:
         case: noinstances
         target: testing-trunk
    - destination:
            host: */*
        subset: testing-trunk    # 主干环境
      weight: 0
      fallback:
        case: noavailabled
        target: testing
    - destination:
        subset: testing          # 日常环境
      weight: 0
      fallback:
        case: noavailabled
        target: mock
    - destination:
            host: */*
        subset: mock             # Mock中心
       weight: 0

2）个人开发环境定制

先打到日常环境，当日常环境没有服务资源时，再打到主干环境。

      apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: projectx-route
spec:
  hosts:                   # 只对myapp生效
  - myapp/*
  http:
  - name: dev-x-route
    match:
      trafficLabel:
      - exact: dev-x       # dev环境: x
    route:
    - destination:
            host: myapp/*
        subset: testing          # 日常环境
      weight: 100
      fallback:
        case: noinstances
        target: testing-trunk
    - destination:
            host: myapp/*
        subset: testing-trunk    # 主干环境
      weight: 0

3）支持权重配置

将打了主干环境标并且本机环境是 dev-x 的流量，80% 打到主干环境，20% 打到日常环境。当主干环境没有可用的服务资源时，流量打到日常。

sourceLabels 为本地 workload 对应的 label

      apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: dev-x-route
spec:
  hosts:                   # 对哪些应用生效（不支持多应用配置）
  - myapp/*
  http:
  - name: dev-x-route
    match:
      trafficLabel:
      - exact: testing-trunk # 主干环境标
      sourceLabels:
      - exact: dev-x  # 流量来自某个项目环境
    route:
    - destination:
            host: myapp/*
        subset: testing-trunk # 80%流量打向主干环境
      weight: 80
      fallback:
        case: noavailabled
        target: testing
    - destination：
            host: myapp/*
        subset: testing       # 20%流量打向日常环境
      weight: 20

按（环境）标路由

该方案依赖业务部署应用时带上相关标识（例子中对应 label 为 ASM_TRAFFIC_TAG: xxx），常见为环境标识，标识可以理解是服务部署的相关元信息，这个依赖上游部署系统 CI/CD 系统的串联，大概示意图如下：

K8s 场景，通过业务部署时自动带上对应环境/分组 label 标识即可，也就是采用K8s 本身作为元数据管理中心。
非 K8s 场景，可以通过微服务已集成的服务注册中心或者元数据配置管理服务（metadata server）来集成实现。

注：ASM Pro 自研开发了ServiceDiretory 组件（可以参看 ASM Pro 产品功能架构图），实现了多注册中心对接以及部署元信息的动态获取；

应用场景延伸

下面是典型的一个基于流量打标和按标路由实现的多套开发环境治理功能；每个开发者对应的 Dev X 环境只需部署有版本更新的服务即可；如果需要和其他开发者联调，可以通过配置 fallback 将服务请求 fallback 流转到对应开发环境即可。如下图的 Dev Y 环境的B -> Dev X 环境的 C。

同理，将 Dev X 环境等同于线上灰度版本环境也是可以的，对应可以解决线上环境的全链路灰度发布问题。

总结

本文介绍的基于“流量打标”和“按标路由” 能力是一个通用方案，基于此可以较好地解决测试环境治理、线上全链路灰度发布等相关问题，基于服务网格技术做到与开发语言无关。同时，该方案适应于不同的7层协议，当前已支持 HTTP/gRpc 和 Dubbo 协议。

对应全链路灰度，其他厂商也有一些方案，对比其他方案 ASM Pro 的解决方案的优点是：

支持多语言、多协议。
统一配置模板 TrafficLabel，配置简单且灵活，支持多级别的配置（全局、namespace 、pod 级别）。
支持路由 fallback 实现降级。

基于“流量打标” 和 “按标路由”能力还可以用于其他相关场景：

大促前的性能压测。在线上压测的场景中，为了让压测数据和正式的线上数据实现隔离，常用的方法是对于消息队列，缓存，数据库使用影子的方式。这就需要流量打标的技术，通过 tag 区分请求是测试流量还是生产流量。当然，这需要 Sidecar 对中间件比如 Redis、RocketMQ 等进行支持。
单元化路由。常见的单元化路由场景，可能是需要根据请求流量中的某些元信息比如 uid，然后通过配置得出对应所属的单元。在这个场景中，我们可以通过扩展 TrafficLabel 定义获取“单元标”的函数来给流量打上“单元标”，然后基于“单元标”将流量路由到对应的服务单元。

IT瘾博客推荐

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

一、Load分析：

情况1：CPU高、Load高

情况2：CPU低、Load高

二、CPU高、Load高情况分析

2.1、使用 vmstat 查看系统纬度的 CPU 负载

2.1、使用 top 查看进程纬度的 CPU 负载

2.2、strace命令分析

三、CPU低、Load高情况分析

AI绘画能力的起源：通俗理解VAE、扩散模型DDPM、ViT/Swin transformer_v_JULY_v的博客-CSDN博客

前言

第一部分 编码器VE与变分自编码器VAE

1.1 AE：编码器(数据 压缩为低维表示 )-解码器(低维表示恢复为原始数据 )架构

1.2 Variational AutoEncoder (VAE)

1.2.1 VAE：标数据的分布 和目标分布 尽量接近

1.2.2 VAE的Variational到底是个啥

第二部分 扩散模型DDPM：Denoising Diffusion Probabilistic Models

2.1 DDPM的训练过程：先前向加噪后反向去噪从而建立噪声估计模型

2.1.1 前向过程(加噪)：通过高斯噪音随机加噪——给图片打马赛克

2.1.2 反向过程(去噪)：复原被加噪的图片——使之清晰化

2.1.3 如何训练：建立噪声估计模型 ——最小化估计噪声与真实噪声之间的差距

2.2 通过训练好的DDPM生成图片

参考文献与推荐阅读

Linux 下如何查找木马并处理 - ericyuan - 博客园

服务端性能优化--最大QPS推算及验证 - huangyingsheng - 博客园

服务端性能优化--最大QPS推算及验证

RT

单线程QPS

最佳线程数

最大QPS

1.最大QPS公式推导

2.CPU Time

3.CPU利用率

1) IO能力

2) 数据库连接池（并发能力=PoolWaitTime/RT(Client) x PoolSize）。

3) 内存不足，GC大量占用CPU，导致给业务逻辑使用的CPU利用率下降，而且GC时还满足Amdahl定律锁定义的场景。

4) 共享资源的竞争，比如各种锁策略(读写锁、锁分离等)，各种阻塞队列，等等。

5) 所依赖的其他后端服务QPS低造成的瓶颈。

6) 线程数或者进程数，甚至编程模型(同步模型，异步模型)。

4.CPU核数，Amdahl定律，Gustafson定律

1)Amdahl定律(安达尔定律，不是达尔文定律！！！)

2) Gustafson定律（古斯塔夫森定律）

3)CPU核数和Amdahl定律的关系

实验数据验证公式

1.数据准备

1)测试QPS结果

2） CPU利用率

3）CPU Time 计算公式

4) CPU Time计算示例

计算得到的CPU Time

实测CPU Time

1） 5个页面的Gzip所消耗的CPU Time

2） Java页面执行消耗的CPU Time

压力测试最佳线程数和QPS临界点

总结：

Linux丢包故障的解决与思路 - Albert的博客 | Albert's Blog

Linux丢包故障的解决与思路

前言

一、问题现象

二、名词解释

三、排查过程

3.1、丢包的可能性

3.2 、确认有 UDP 丢包发生

3.2 、确认网卡或者驱动丢包

3.3 、UDP 报文错误丢包

3.4 、UDP buffer size 不足丢包

3.5 、系统负载过高丢包

3.6 、应用丢包

3.7 、包丢在什么地方

3.8 、关于UDP丢包的总结

3.9、防火墙拦截

3.10、连接跟踪表溢出

3.11、Ring Buffer溢出

3.12 netdev_max_backlog溢出

3.13、反向路由过滤

3.14 半连接队列溢出

3.15 PAWS

3.16 怎么知道为什么数据包被丢弃

dropwatch

第一部分编码器VE与变分自编码器VAE

1.1 AE：编码器(数据压缩为低维表示 )-解码器(低维表示恢复为原始数据 )架构

1.2.1 VAE：标数据的分布和目标分布尽量接近

第二部分扩散模型DDPM：Denoising Diffusion Probabilistic Models

6. 关闭流控（flow control）

2.1.1通过 `openssl`创建CA证书

When creating the bootstrap use the following formats for the JDBC connection string.

Case 1: When using tibcosoftwareinc.jdbc.oracle.OracleDriver driver (Oracle (DataDirect)), JDBC URL field should contain: