最近公司要整合目前所有的前端项目，希望放到同一个项目里面进行管理，但是项目使用的技术栈大体不相同，有原生js的，有用jq的也有用Vue的，整合的话要么重构，统一技术栈，不过这是不现实的，成本高，时间长，要么使用iframe，但是iframe也有很多缺点，通信不方便，刷新页面会导致路由丢失，这都是很不好的体验，于是我想起了最近很火的微前端概念，打算用微前端的技术来整合已有项目。

1. 什么是微前端？
   
   微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。微前端的核心在于 拆, 拆完后在 合!
    
2. 为什么使用微前端？
   
   ① 不同团队间开发同一个应用技术栈不同
   ② 希望每个团队都可以独立开发，独立部署
   ③ 项目中还需要老的应用代码
   
   我们可以将一个应用划分成若干个子应用，将子应用打包成一个个的lib。当路径切换 时加载不同的子应用。这样每个子应用都是独立的，技术栈也不用做限制了！从而解决了前端协同开发问题。
    
3. 如何落地微前端？
    
   2018年Single-SPA诞生了，single-spa是一个用于前端微服务化的JavaScript前端解决方案 (本身没有处理样式隔离，js执行隔离)实现了路由劫持和应用加载。
    
   2019年qiankun基于Single-SPA,提供了更加开箱即用的API（single-spa+sandbox+import-html-entry） 做到了，技术栈无关、并且接入简单（像iframe一样简单）。
   
    
4. qiankun框架实操
   
   这里我们打算建立三个项目进行实操，一个Vue项目充当主应用，另一个Vue和React应用充当子应用，话不多说，直接开干。
   首先我们安装qiankun

   yarn add qiankun 或者 npm i qiankun -S

   安装完qiankun后我们在创建主应用，也是我们的基座

   vue create qiankun-base

   接着创建vue子应用

   vue create qiankun-vue

接着创建react子应用

cnpm install -g create-react-app
create-react-app my-app

创建好后的目录如下，qiankun-js忽略                           

项目创建好后我们首先进行主应用qiankun-base的配置，进入man.js文件进行配置， 在main.js中加入以下代码,要注意的是，entry这项配置是我们两个子项目的域名和端口，我们必须确保两字子项目运行在这两个端口上面，container就是我们的容器名，就是我们子应用挂载的节点，相当于Vue项目里面的app节点，activeRule就是我们的激活路径，根据路径来显示不同的子应用。

import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
  {
    name: 'vueApp', // 应用的名字
    entry: '//localhost:8021',// 默认会加载这个html 解析里面的js 动态的执行 （子应用必须支持跨域）fetch
    container: '#vue', // 容器名
    activeRule: '/vue',// 激活的路径
  },
  {
    name: 'reactApp',
    entry: '//localhost:8020',
    container: '#react',
    activeRule: '/react',
  },
]);
start();

配置完之后我们去到qiankun-base的app.vue文件进行主应用的页面编写，这里我安装了element-ui来进行页面美化，大家可以安装一下，

npm i element-ui -S

修改app.vue的组件代码如下
 

<template><div><el-menu :router="true" mode="horizontal"><!--基座中可以放自己的路由--><el-menu-item index="/">Home</el-menu-item> <!--引用其他子应用--><el-menu-item index="/vue">vue应用</el-menu-item><el-menu-item index="/react">react应用</el-menu-item></el-menu><router-view ></router-view><div id="vue"></div><div id="react"></div></div></template>

大家可以看到，在elementui的路由导航模式下，菜单子元素的index就是要跳转的路径，这个路径和我们刚刚在main.js编写activeRule是一致，子应用的切换就是根据这里的index进行监听。

接下来我们进行router的配置

import Vue from 'vue'
import VueRouter from 'vue-router'
import Home from '../views/Home.vue'

Vue.use(VueRouter)

  const routes = [
  {
    path: '/',
    name: 'Home',
    component: Home
  },
  {
    path: '/about',
    name: 'About',
    // route level code-splitting
    // this generates a separate chunk (about.[hash].js) for this route
    // which is lazy-loaded when the route is visited.
    component: () => import(/* webpackChunkName: "about" */ '../views/About.vue')
  }
]

const router = new VueRouter({
	mode: 'history',
  base: process.env.BASE_URL,
  routes
})

export default router

我们运行一下qiankun-base

npm run serve

界面应该是这样子的

目前页面除了菜单是没有其他东西的，点击也是没有效果的，因为我们还没配置子应用，现在我们来配置子应用
打开qiankun-vue目录， 在子Vue应用的main.js中加入以下代码

import Vue from 'vue'
import App from './App.vue'
import router from './router'

let instance = null; 

//挂载实例
function render(){ 
    instance = new Vue({ router, render: h => h(App) }).$mount('#app') 
}
//判断当前运行环境是独立运行的还是在父应用里面进行运行，配置全局的公共资源路径
if(window.__POWERED_BY_QIANKUN__){ 
    __webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__; 
}
//如果是独立运行window.__POWERED_BY_QIANKUN__=undefined
if(!window.__POWERED_BY_QIANKUN__){
    render()
} 
//最后暴露的三个方法是固定的，加载渲染以及销毁
export async function bootstrap(){} 
export async function mount(props){
    render();
} 
export async function unmount(){
    instance.$destroy();
}

配置完main.js后我们继续配置基础配置模块，我们在子Vue应用的根目录下面新建一个Vue.config.js文件

module.exports = {
    devServer:{
        port:10000,//这里的端口是必须和父应用配置的子应用端口一致
        headers:{
            //因为qiankun内部请求都是fetch来请求资源，所以子应用必须允许跨域
            'Access-Control-Allow-Origin':'*' 
        }
    },
    configureWebpack:{
        output:{
            //资源打包路径
            library:'vueApp',
            libraryTarget:'umd'
        }
    }
}

接下里再进行router的配置

import Vue from 'vue'
import VueRouter from 'vue-router'
import Home from '../views/Home.vue'

Vue.use(VueRouter)

  const routes = [
  {
    path: '/',
    name: 'Home',
    component: Home
  },
  {
    path: '/about',
    name: 'About',
    component: () => import(/* webpackChunkName: "about" */ '../views/About.vue')
  }
]

const router = new VueRouter({
  mode: 'history',
  base: '/vue',
  routes
})

export default router

这三步就已经把子应用配置好了，接下来我们再进行子React应用的配置。

重写子React的src目录下的index.js文件，如下

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';

function render(){
  ReactDOM.render(
    <React.StrictMode><App /></React.StrictMode>,
    document.getElementById('root')
  );
}
if(!window.__POWERED_BY_QIANKUN__){
  render();
}
export async function bootstrap(){

}
export async function mount() {
  render()
}
export async function unmount(){
  ReactDOM.unmountComponentAtNode( document.getElementById('root'));
}

再进行dev以及打包的配置，根目录下面的config-overrides.js

module.exports = {
    webpack:(config)=>{
        config.output.library = 'reactApp';
        config.output.libraryTarget = 'umd';
        config.output.publicPath = 'http://localhost:20000/';
        return config;
    },
    devServer:(configFunction)=>{
        return function (proxy,allowedHost){
            const config = configFunction(proxy,allowedHost);
            config.headers = {"Access-Control-Allow-Origin":'*'
            }
            return config
        }
    }
}

子React的基础配置和子Vue基本相同，在这里我们就算是配置完了，接下来我们看看结果如何，启动主应用以及两个子应用

上面是我录制的一个gif，可以看到我们的微前端实践已经成功了，点击相应的菜单可以跳转到对应的子应用，并且子应用内的路由是不会受影响的。还有一个需要注意的是，我们的应用路由模式要用history模式，没有的要去router文件里面定义

const router = new VueRouter({ 
    mode: 'history', 
    base: '/vue', 
    routes 
})

那么今天的微前端的分享就到这里了，我可能讲得不太好，希望对大家有用，更加详细的教程和相关问题解答可以上官网

https://qiankun.umijs.org/zh

最后附上例子的源码地址， https://github.com/DJYang666/qiankun.git，喜欢的多多关注哦

这是我参与更文挑战的第7天，活动详情查看： 更文挑战

如果❤️我的文章有帮助，欢迎点赞、关注。这是对我继续技术创作最大的鼓励。

linux grep 查看大日志文件

场景

今天隔离还在继续，在家办公。忽然下午午工作群里发来一个 mysql机器io/负载上升的预警，异常发生在 15：45 ~ 16：00之间。为了事后为了查明原因，需要翻看慢查询日志 slow.log才发现日志 8G 多... 故事就这样开始了

怎么办呢。第一个想到的就是常用 grep匹配关键字

grep 关键字

grep 常用于 关键字匹配文件文本信息。
但关键字从哪里来呢，可以命令 head slow3306_9110.log查看下检索文件的 内容结构

因为异常发生在 15：45 ~ 16：00之间，我就可以这样写

grep -n 'Time: 210607 15:[45-59]' slow3306_9110.log

时间 15：45至 15：59之间内容，但这样匹配只能看到时间，这明显不是我们想要的

grep 显示匹配行附近内容

• A -> After
• B -> Before
• C -> Context

举个例子：

grep -A5 'Time: 210607 15:[45-59]' slow3306_9110.log

就能把匹配 Time: 210607行的 下面 5 行也显示出来。

grep 多关键字搜索

但这时我们有会发现， Query_time: 0.925375查询时间有大有小。我现在在查故障明细是只想看 查询消耗时间大的。

所以这里就需要用到 grep 多关键字搜索

匹配多个关键字（且）

管道符连接 多个条件实现关键字 且关系匹配：

grep -A5 'Time: 210607 15:[45-59]' slow3306_9110.log | grep 'Query_time: (\d[2-5])'

同一行同时满足两个条件（ Time、 Query_time）才能够匹配。

不过这里也必须说明： 因为上图内容格式中，Time 和 Query_time 不在同一列，所以上诉命令只是这个演示。实际只能匹配 同一行同时满足两个条件内容

grep -E 匹配多个关键字（或）

grep -E "word1|word2|word3" file.txt

匹配文件中 同一行包含 word1、word2、word3 之一

总结

总结下来。

• 由于多行无法同时命中 时间 15：45 至 15：59和 查询时间在 2~5位整数之间。
• 另外由于文件太大，grep 一次就能跑个 3、4 分钟实际体验并不好

Oracle数据库里的统计信息是这样的一组数据：它存储在数据字典里，且从多个维度描述了Oracle数据库里对象的详细信息。CBO会利用这些统计信息来计算目标SQL各种可能的、不同的执行路径的成本，并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划。

Oracle数据库里的统计信息可以分为如下6种类型：

• 表的统计信息

• 索引的统计信息

• 列的统计信息

• 系统统计信息

• 数据字典统计信息

• 内部对象统计信息

表的统计信息用于描述Oracle数据库里表的详细信息，它包含了一些典型的维度，如记录数、表块(表里的数据块)数量、平均行长度等。

索引的统计信息于描述Oracle数据库里索引的详细信息，它包含了一些典型的维度，如索引的层级、叶子块的数量、聚簇因子等。

列的统计信息于描述Oracle数据库里列的详细信息，它包含了一些典型的维度，如列的distinct值的数量、列的NULL值的数量、列的最小值、列的最大值以及直方图等。

系统统计信息于描述Oracle数据库所在的数据库服务器的系统处理能力，它包含了CPU和I/O这两个维度，借助于系统统计信息，Oracle可以更清楚地知道目标数据库服务器的实际处理能力。

数据字典统计信息用于热核Oracle数据库里数据字典基表(如TAB$、IND$等)、数据字典基表上的索引，以及这些数据字典的列的详细信息，描述上述数据字典基表的统计信息与描述普通表、索引、列的统计信息没有本质区别。

内部对象统计信息用于描述Oracle数据库里的一些内部表(如X$系列表)的详细信息，它的维度和普通表的统计信息的维度类似，只不过其表块的数量为0，因为X$系统表实际上只是Oracle自定义的内存结构，并不占用实际的物理存储空间。

1、收集统计信息

在Oracle数据库里，通常有两种方法可以用来收集统计信息：一种是使用ANALYZE命令；另一种是使用DBMS_STATS包。表、索引、列的统计信息和数据字典统计信息用ANALYZE命令或者DBMS_STATS包收集均可，但系统统计信息和系统内部对象统计信息只能使用DBMS_STATS包来收集。

对系统内部表若使用ANALYZE命令来收集统计信息，会报错ORA-02030

1.1用ANALYZE命令收集统计信息

从Oracle7开始，ANALYZE命令就可以用来收集表、索引、列的统计信息，以及系统统计信息。

典型用法如下：

zx@ORCL>create table t2 as select * from dba_objects;

Table created.

zx@ORCL>create index idx_t2 on t2(object_id);

Index created.

zx@ORCL>analyze index idx_t2 delete statistics;

Index analyzed.

从Oracle 10g开始，创建索引后Oracle会怎么收集目标索引的统计信息，出现演示的目的，这里删除索引IDX_T2的统计信息：

执行sosi脚本，从输出内容可以看到表T2、表T2的列和索引IDX_T2均没有相关的统计信息

zx@ORCL>select count(*) from t2;

  COUNT(*)
----------
     86852

只对表T2收集统计信息，并且以估算模式，采样的比例为15%：

zx@ORCL>analyze table t2 estimate statistics sample 15 percent for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是估算模式所以估算结果和实际结果并不一定会完全匹配，比如表T2的实际数量与估算出的数量不一致。

只对表T2收集统计信息，并且以计算模式：

zx@ORCL>analyze table t2 compute statistics for table;

Table analyzed.

再次执行sosi脚本，可以看出现在只用表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在对表T2的列OBJECT_NAME和OBJECT_ID以计算模式收集统计信息：

zx@ORCL>analyze table t2 compute statistics for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看出，现在列OBJECT_NAME和OBJECT_ID确实已经有统计信息了

注：在崔华老师的《基于Oracle的SQL优化》一书中提到T2原有的统计信息已经被抹掉了，也就是说对同一个对象而言，新执行的ANALYZE命令会抹掉之前ANALYZE的结果。但是在我实际的执行结果是表T2原有的统计信息没有被抹掉。我用到的环境是10.2.0.4和11.2.0.4，暂时没有11.2.0.1的环境。

可以使用如下的命令同时以计算模式对表T2和列OBJECT_NAME、OBJECT_ID收集统计信息：

zx@ORCL>analyze table t2 compute statistics for table for columns object_name,object_id;

Table analyzed.

再次执行sosi脚本，可以看到表T2和列OBJECT_NAME、OBJECT_ID上都有统计信息了。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>analyze index idx_t2 compute statistics;

Index analyzed.

再次执行sosi脚本，从输出可以看到，现在索引IDX_T2已经有了统计信息，并且之前收集的表T2和列OBJECT_NAME、OBJECT_ID上的统计信息并没有被抹掉，这是因为我们刚才执行的ANALYZE命令和之前执行的ANALYZE命令针对的不是同一个对象。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>analyze table t2 delete statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，刚才收集的表T2、表T2的列OBJECT_NAME、OBJECT_ID以及索引IDX_T2的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列和表T2上的所有索引的统计信息，执行如下的语句就可以了：

zx@ORCL>analyze table t2 compute statistics;

Table analyzed.

再次执行sosi脚本，从输出可以看到，现在表T2、表T2的所有列和索引IDX_T2的统计信息都有了。

1.2用DBMS_STATS包收集统计信息

从Oracle 8.1.5开始，DBMS_STATS包被广泛用于统计信息的收集，用DMBS_STATS包收集统计信息也是Oracle官方推荐的方式。在收集CBO所需要的统计信息方面，可以简单的将DBMS_STATS包理解成是ANALYZE命令的增加版。

DBMS_STATS包里最常用的就是如下4个存储过程：

• GATHER_TABLE_STATS：用于收集目标表、目标表的列和目标表上的索引的统计信息。

• GATHER_INDEX_STATS：用于收集指定索引的统计信息。

• GATHER_SCHEMA_STATS：用于收集指定schema下所有对象的统计信息。

• GATHER_DATABASE_STATS：用于收集全库所有对象的统计信息。

现在介绍DBMS_STATS包在收集统计信息时的常见用法，还是针对上面的测试表T2，这里使用DBMS_STATS包实现了和ANALYZE命令一模一样的效果。

先删除表T2上的所有统计信息

analyze table t2 delete statistics;

只对表T2收集统计信息，并且以估算模式，采用的比例同样为15%：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>15,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2有统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的估算模式，所以估算结果和实际结果并不一定会完全匹配。

需要注意的是，这里Oracle数据库的版本是11.2.0.4，我们在调用DMBS_STATS.GATHER_TABLE_STATS时指定参数METHOD_OPT的值为'FOR TABLE',这表示只收集表T2的统计信息。这种收集表统计信息的方法并不适用于Oracle数据库所有的版本。例如这种方法就不适用于Oracle10.2.0.4和Oracle10.2.0.5，在这两个版本里，即使指定了'FOR TABLE'，Oracle除了收集表统计信息之外还会对所有的列收集统计信息。

如果公对表T2收集统计信息，并且是以计算模式收集，用DBMS_STATS包实现的方法就是将估算模式的采样比例(即参数ESTIMATE_PERCENT)设置为100%或NULL；

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>NULL,method_opt=>'FOR TABLE',cascade=>false);

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'FOR TABLE',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在只有表T2的统计信息，表T2的列和索引IDX_T2均没有相关的统计信息。而且因为采用的是计算模式，计算模式会扫描目标对象的所有数据，所以统计结果和实际结果是匹配的。

对表T2收集完统计信息后，现在我们来对表T2的列OBJECT_NAME、OBJECT_ID以计算模式收集统计信息(不收集直方图)：

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,method_opt=>'for columns size 1 object_name,object_id',cascade=>false);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在表T2的列OBJECT_NAME、OBJECT_ID上都有统计信息了，并且Oracle还会同时收集表T2上的统计信息(注意，这和ANALYZE命令有所区别)。

使用如下命令可以以计算模式收集索引IDX_T2的统计信息

zx@ORCL>exec dbms_stats.gather_index_stats(ownname=>'ZX',indname=>'IDX_T2',estimate_percent=>100);

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，现在索引IDX_T2已经有了统计信息。

使用如下命令可以删除表T2、表T2的所有列及表T2的所有索引的统计信息：

zx@ORCL>exec dbms_stats.delete_table_stats(ownname=>'ZX',tabname=>'T2');

PL/SQL procedure successfully completed.

执行sosi脚本，从输出内容可以看出，表T2、表T2的所有列及表T2的所有索引的统计信息已经全部被删除了。

如果想一次性以计算模式收集表T2、表T2的所有列及表T2的所有索引的统计信息，执行如下语句就可以了

zx@ORCL>exec dbms_stats.gather_table_stats(ownname=>'ZX',tabname=>'T2',estimate_percent=>100,cascade=>true);

PL/SQL procedure successfully completed.

1.3 ANALYZE和DBMS_STATS的区别

从上面的演示中可以看出ANALYZE命令和DBMS_STATS包都可以用来收集表、索引和列的统计信息，看起来它们在收集统计信息方面的效果是一模一样的，为什么Oracle会推荐使用DBMS_STATS包来收集统计信息呢？

因为ANALYZE命令和DMBS_STATS包相比，存在如下缺陷：

ANALYZE命令不能正确地收集分区表的统计信息，而DBMS_STATS包却可以。ANALYZE命令只会收集最低层次对象的统计信息，然后推导和汇总出高一级的统计信息，比如对于有子分区的分区表而言，它只会先收集子分区统计信息，然后再汇总，推导出分区或表级的统计信息。有的统计信息是可以从当前对象的下一级对象进行汇总后得到的，比如表的总行数，可以由各分区的行数相加得到。但有的统计信息则不能从下一级对象得到，比如列上的distinct值数量NUM_DISTINCT以及DESNSITY等。

ANALYZE命令不能并行收集统计信息，而DBMS_STATS包却可以。并行收集统计信息对数据量很大的表表而言，是非常有用的特性。对于数据量很大的表，如果不能并行收集统计信息，则意味着如果想精确地收集目标对象的统计信息，那么耗费的时间可能会非常长，这有可能是不能接受的。在Oracle数据库里，DBMS_STATS包收集统计信息可以并行执行，这在一定程度上缓解了对大表的统计信息收集过长所带来的一系列问题。

DBMS_STATS包的并行收集是通过手工指定输入参数DEGREE来实现的，比如对表T1进行收集统计信息，同时指定并行度为4：

exec dbms_stats.gahter_table_stats(ownname=>'SCOTT',tabname=>'T1',cascade=>true,estimate_percent=>100,degree=>4);

当然，DBMS_STATS包也不是完美的，它与ANALYZE命令相比，其缺陷在于DBMS_STATS包只能收集与CBO相关的统计信息，而与CBO无关的一些额外信息，比如行迁移/行链接的数量(CHAIN_CNT)、校验表和索引的结构信息等，DBMS_STATS包就无能为力了。而ANALYZE命令可以用来分析和收集上述额外的信息，比如analyze table xxx list chained rows intoyyy可以用来分析和收集行迁移/行链接的数量，analyzeindex xxx validate structure可以用来分析索引的结构。

2、查看统计信息

前面介绍了如何收集统计信息，那如何查看这些统计信息呢？Oracle数据库的统计信息会存储在数据字典里，我们只需要去查询相关的数据字典就好了。如果有充裕的时间，现写SQL去查询数据字典里的统计信息也没有什么，但当我们真正碰到有性能问题的SQL时，通常会希望能在第一时间就收集到与目标SQL相关的各种统计信息，以便于在第一时间定位问题所在，这时候写SQL去查询数据字典就已经来不及了，所以我们需要事先准备好通用的查询统计信息的脚本，出问题的时候只需要运行一下脚本，就能在第一时间获取目标对象的所有统计信息了。

sosi脚本(Show Optimizer Statistics Information)就是这样一种脚本，国内的Oracle数据库专家也一直在用这个脚本，它源于MOS上的文章：SCRIPT - Select to show OptimizerStatistics for CBO (文档ID 31412.1)，用法很简单，只需要运行一下sosi脚本，并指定要查看统计信息的表名就可以了。它支持分区表，显示分为三部分，分别是表级别的统计信息，分区级别的统计信息和子分区级别的统计信息。前面做实验用到的也是这个脚本。

 附件是sosi脚本可以下载使用。

参考《基于Oracle的SQL优化》

当然关于权限还有个取巧的办法，示例如下：

（2021.6.8更新:

很多学弟学妹给我发私信咨询，谢谢大家的信任。我也是一个普通人，站得不高，也看得不远，如有未解答的问题请见谅。如果有任何问题欢迎私信与我交流，知无不言。也希望其他同学分享各种求职行业经验和思考，造福学弟学妹。希望出现赞数更多的文章😄

帖子热度慢慢降下去了，很开心大家有了充分的讨论。这也是我发帖提醒各位的原因。能让大家有一些思考，有些观照就很好了。至少不会是社会绝大多数人那样被结婚生子买房买车的道路裹挟。最后还想说，希望大家做好规划，勤于思考。去做一个幸福的普通人，但一定更要有内心的坚守和追求，不愧对在北大的学习时光和“眼底未名水，胸中黄河月”的情怀。

）

（2021.6.7更新：

发现自己写的帖子引起了大家这么热烈的讨论，真的很感谢师弟师妹们对我的鼓励，也有许多同龄人相似经历的人分享自己的心路历程，非常感动。也看到有体制内的前辈批评我，劝导我，我都虚心接受。我还不到30，道行尚浅，没有体制内的前辈站得高，看得远。选择都是自己做出来的，既然做了，就不会后悔。

我尽量用一种客观的语言陈述事实，而不是进行价值判断，可能还没有做到完全客观。我再次强调我没有否定体制内的任何意思，只是真实体验过冷暖自知。能引发大家的思考和讨论就很好，没有任何劝戒的观点。择业是人生大事，只是希望大家根据自己的情况谨慎决策，慎重思考，这大有裨益。我没有在体制外呆过，资历尚浅，只能就自己的经验做一些分享，说的不周的地方请见谅。这几千字的内容是我周末有感而发，回想到学生时代的一些错误和没有注意到的地方，更多是面向在校生和毕业生的提示和分享。更多前辈比我更有经验阅历，请不要苛责我作为一个后辈稚嫩的观点。开放的平台大家都可以讨论、分享。

非常感谢北大bbs，我们能有一个深度、平等、开放、安全的交流空间。兼听则明，偏信则暗，我也在各位的回复中收获颇丰。另烦请各位前辈和学弟学妹不要转载，让我们停留在北大这个开放包容的环境中讨论，以免在社会舆论引起不必要的纷扰。

我在园子里度过了人生最美好的6年，热爱这里的一草一木、一砖一瓦。谢谢大家的关心，祝大家都有美好的前程。

）

原帖如下：

终于鼓起勇气从体制内辞职了，看着即将入职的小朋友踌躇满志，想到了五年前的我，也是如此对工作和未来充满了期待而意气风发。即将迎接我的将是一个未知的领域，充满风险和挑战的社会。在此我复盘我踩过的坑和没有注意的地方，希望能为学弟学妹做些提示，做好职业生涯规划，完成学生到社会的蜕变。

我是p大理工本金融类硕，现在在某金融类体制内单位工作了五年。当时该单位（以下简称甲单位）招聘很好，我放弃了其他的offer来到甲单位。此后便开始了我的体制内生涯。

到单位的第一天，我还未脱去学生的稚嫩，领导语重心长地对我说：“大家都很优秀，不过年轻同事肯定要从最基础的做起。“我牢记父母对我的教诲，进体制内单位低头做事，谨言慎行，放低身段。没想各种工作还是远远超出了我的预期。“第一年你们小年轻就做做基本工作就行“……我不由得先吃了一惊。此后，我发现我再也和债券股票、市场基本面、财务报表、宏观经济有任何关系，取而代之的是巡视、审计、保密、写文、送文、改文、核稿、党建、团建、订会议室、摆座牌、准备材料、发言稿、不忘初心、调格式、设置页码、检查错别字、认真学习“请XX同志阅示、阅研、阅批、办理、加急办理、高度重视”的批示精神……

体制内就是一个机器，每个人就是一个螺丝钉。随着内卷程度的加深，原本中专生干的活现在需要北大清华的学生来干，对，如果你学校不够好连这体制内单位的门都进不去。领导其实有时候也在说“体制内浪费了多少人才”。诚然，我在服务领导的路上一直走过了五年。第一年还在适应的过程中，第二年第三年在恐惧自己要被社会淘汰的焦虑中和在毫无意义的工作中埋没，当然后面还有疫情，更让我踟蹰不前。

我终于决定要出来，这并不是我想要的，更不是我当时来甲单位的初心。社会现实再次给了我冷冷一击。有着cfa的我投的简历依然石沉大海，毕竟离市场太远了这么多年，早已荒废了各类知识。实在走投无路，靠学长学姐推荐了几个单位，面试的时候看了简历，共同感叹“太可惜了，你的学历和软件实力完全没问题，都是顶尖。但是你的工作经历不能和任何工作匹配，这是硬伤”“你到我这里来也是给你按刚入职的新生算”“你虽然在体制内，但是你能给我们带来什么资源呢，我们招你和应届生，其实没有本质的差别”“你就算北大毕业，我们还是会录用更有经验的人”……

凡此种种，再一次让我认识到了社会的残酷。我面临着工资的大幅下跌，面临着周围同批同学早已在自己的岗位上飞速成长成为骨干甚至带起了自己的团队的这种心理落差。有时候常常和同学开玩笑：“再有一批国企下岗，那一定是我下岗。”虽然是玩笑话，背后确是说不尽的辛酸。

不过无所谓，已经选择了重头开始。我在这里还是复盘一下自己做得不好的地方，给学弟学妹一些提醒：

一、  一些犯过的错误

1. 未能理解选人标准高不等于育人标准高

很多时候大家offer求比较更多看的是这个单位如何，但实际上更重要的是你所在的岗位如何。单位固然也很重要，但要明白，什么东西脱离了你的单位，成为你自己的东西，这才是你自我价值的提升。按在现在内卷的情况，一窝蜂北大清华的学生都涌进体制内或部分机构，他们选人的标准自然很高。正如领导所言什么岗位都要有做最基础的打印复印扫描文件，只是现在轮到你们北大的人做而已。不要秉持学生思维认为什么地方难进就一定是好的单位，更好看这个单位里你从事的工作和单位对你的培养。

2. 未能树立明确职业规划和人生道路有效衔接

我直到本科后才知道去实习，凭借理工科的背景也是进入金融机构较为顺利。但是我一直不知自己的职业规划，或者通俗一点，自己的“爽点”在什么地方。有和我背景类似的同学瞄着基金经理的岗位专注二级市场，也有专注编程技能成为很好的金融建模专家。（当然，他们工作压力和竞争也很大）而我缺少这样的规划，自然当时觉得什么地方难进就什么地方。同时，很多来甲单位的同事冲着结婚生子就去了，迅速办完了人生大事再搞后续的事业。诚然，我缺少了对长期人生家庭的各类规划。

3.  未能正确理解体制内工作内容核心就是写公文

尽管甲单位是接触市场，但不妨碍这就是一个体制内机构。体制内就是写公文。说实话，这个我之前从未接触过。而我在体制内发展得还不错的同学都是一直知道自己要写公文，并且接受现在的工作状态。每天在”高度“”密切“”深入“”切实““提高”“巩固”“充实”“稳中有增”中来回选择，领导再把你的把字句变成被字句，一般改个10几遍都很正常，当然最后可能改回了原来的样子。不断揣摩领导的意思和思路，互相猜来猜去，也说不明白具体的内容。

所有想去体制内的同学们不妨问自己三个问题：

1）  能否接受每天按人民日报、求是、或者高中政治的口吻语调写东西

2）  能否接受像照顾婴儿一样无微不至服务领导、提高政治站位、进行各类学习活动

3）  能否接受长期做一种工作直到退休，肉眼可见自己的能力慢慢退化，而周围同学活跃而心如止水

如果这三个问题有一个你表示不能接受，那慎重考虑你的选择。

4.  未能有效理解“体制内“的很多其他的影响

体制内和体制外完全是不同的两套逻辑，双方互不相认。体制外不认可体制内做的事，而想从体制外跳进体制内却很难很难。

一是体制内（除了少数专业性岗位）是一个去能力化的地方，我虽然学习金融，但我去公安部、外交部、农业部、科技部一点问题都没有。因为就是要写公文，执行领导意图。

二是体制内整个思维的比社会晚10年，进了这里你就和市场彻底远离，很多领导甚至不知道什么叫ETF，什么叫注册制，再老一点的领导连Excel的筛选都不会。整体思维也非常老，年轻人提出一点新观点新思路，领导会因为没听过或者求稳而直接pass。

三是这是一个忠诚大于能力的地方，很多晋升等靠的不是你能力有多强，而是你多懂得做人和把握机遇。学校（特别是北大）里培养的批判性思维，创新性思维简直就是体制内的大忌。某领导亲自说，你们北大的人太难管，心高气傲，想法还这么多，只管做就行了。很多高学历的人在体制内待不住，就是因为看到能力比自己差的人反而得到了提升，咽不下这口气。

四是体制内还有很多副产品，比如“非必要不出京”，强制疫苗，各种批准，对于习惯了北大自由懒散环境的人简直就是戴上了紧箍咒。

五是千万别要高估北大学历，北大名声不是很好，多冠以懒散，精致利己等名号。同时，只要是硕士，无论是北大、西大，还是西北大，无论是什么大学就是“硕士研究生”，哪怕一个更差的大学的硕士也比北大本科好，同理，更差的大学的博士也比北大硕士好。这也是为什么体制内的人一定想去读在职博士，无论什么学校什么专业有多水，就是要博士这个title。

六是要习惯很多你根本之前很难接受的东西，无论是金融国企还是制造业国企，做什么不重要，重要的是萝卜坑和位置。所以为了解决位置和待遇，经常出现外行指挥内行的情况。行政领导调来做研究，法律领导调去管人力，办公厅秘书出来搞编程，都是很常见的现象。

5.  规划滞后，缺少与市场的了解

原来我的设想是在体制内出来可以获得很多信息和人脉，也锻炼了规矩。然而从体制内再出来这个路早已经是过去式了。

一是日益趋严的监管让那些体制内的人有很多行业禁令。

二是很多市场机构的坑位都已经被早跳出体制内的领导们占满了，他们大多业务处室有丰富的监管经验，小年轻没法比。

三是我们都太渺小，根本接触不到政策，可能到你这里就是读政策的一句话，离政策制定、了解政策实在是太远了。

四是所谓的人脉就是虚的，别人认的是这个单位，而不是你这个人。

我们经常有一个幸存者偏差的误区，看到任泽平等从体制内历练多年而跳出来的大佬们觉得这也可以是自己发展的路径。殊不知，这是一个幸存者偏差，每一个人都想这么走，但必须要有各种加持和机遇才能实现他们如今的成就。

二、一些建议

1.  对父母和老师的建议兼听则明

楼主家在某一线城市，即使这样，父母的观念（包括其他很多同龄人的父母）大多还是体制内最好，体制内万岁。一定要考公务员，不行就去事业单位，再不行央企，实在不行地方国企也可以。诚然，对于经历了改革开放、下岗潮等等风雨的父母来说，体制内就是幸福和稳定的代名词。他们没有接触过什么叫私募，什么叫PE，什么叫VC，对于父母的观点，兼听则明，因为大多家长一定希望自己孩子稳定，早日成家立业结婚生子，毕竟父母在现在我这个年龄我都已经牙牙学语了，还折腾啥啊。

对于老师，大多数老师是从来没有去市场上走过一圈的，更没有找过工作。他们对于学生的择业建议多是道听途说而非亲身感悟，所以他们的建议也存在很大的局限性，不得不说市场上不需要教学和科研，更不需要发表论文，所以他们的经验和建议借鉴意义不大。当然如果要读博士找教职另说。建议多找近两年师兄师姐找过工作的人咨询求职选择，更要跟更年长一些的业界人士去沟通人生路径的规划。

2.   处理好课业和实习工作的关系

楼主属于一直好好学习的那种人，本科好好刷绩点保研金融，硕士好好读paper和老师做助研，一直都是老师眼中的“好学生”，拿了不少奖学金。然而这一切直到我在研一才暑假发现自己就活在象牙塔里。工作单位不会看你的成绩你的发表你的科研，更看你的实习经验。我从研二开始拼命去实习，老师甚至为此还扣了我的奖学金，理由是不好好读paper而去实习。诚然，中国教育存在学术和实践严重的脱节现象。学的东西上班用不了，很多老师的思维也没有转过弯来，通过课程设置等各种方式“防止”学生去实习。在如今实习都要求学生一周四至五天到岗的情况下，学生不得不翘课实习。但是为了工作，必须得这么做。我是很反对大学变成职业培训学校，特别是北大这么好的学术资源和顶尖老师配置，有的学生一头扎进实习，虽然工作找得很好，但未免留下许多青春的遗憾。所以平衡好两者的关系最为重要。

有效利用好学生身份，多去体验、思考、尝试，找到自己喜欢的、想要的道路，努力去想，拼命去想，越早想明白越好。

3.   眼光一定要放长远，不要因为眼前的利益

找工作的时候建议大家要想好属于自己的职业发展的道路，要想到这份工作能给下一份工作带来附加值是什么，甚至下下份工作。当然人的目标也是在变化，但是一定要放长远。在工作中到不到价值、与自己的规划不一致到最后只能是“应付工作”。体制内有个神奇的魔力，刚进去的人还有些心气，慢慢的就磨平了棱角，追求越来越少，到最后就是孩子的政策保障学位和处级干部的位置。人也慢慢稳定下来。所以一定要长远规划，如果发现自己不是安于现状的人就一定要早做决定，不能犹豫，因为再过几年，市场上就真的没人要了。当然，我也很反对拿了户口就跑的这种策略，这只会给招生单位留下非常不好的北大精致利己主义者的印象，更会坑掉师弟师妹。圈子很小，在一个地方留下不好的口碑，对你未来发展也是不利的。

三、 一些感悟

1.  绝大多数人并不知道自己喜欢什么，适合什么，只是社会的一颗螺丝钉在疯狂运转

上班后才发现工作真的只是一份工作，随着年纪的增长，对生活的热情逐渐消退，到最后大家拼命在工作，结婚，生子，买车买房的程式化道路上。很多人并不知道自己要什么，更不知道什么适合自己。无非就是在社会的光晕下不断裹挟前行。其实贵校绝大部分人也是这样，就普普通通过一辈子，并不知道自己要什么。真正找到自己热爱的事业，努力为之奉献，活着很快乐的人很少很少。

2.  广交朋友，广结善缘

当我想换工作的时候，我自己投的简历几乎石沉大海。真的很感谢我的同学们，只有靠他们的推荐才能更好地去面试，笔试。在我最痛苦的时候，也是各种同学和好友们不断为我心理疏导，鼓励我，支持我去勇敢离开体制内，去追求自己想要的东西。更有很多从体制内出来的学长学姐跟我说，我的心路历程他们都经历过。披着光鲜的名头，得到邻居和父母同事羡慕的眼光，但却每天做着毫无意义的工作。想出去，发现自己无法接受要重头再来的现实，更无法适应如此激烈的竞争，连自己校招时曾看不上的单位都回不去了，完全想象不出自己曾在高考叱咤风云，成为最顶尖的人进入北大……不过他们都做了，尝试了。不少师兄师姐一直在给我心理上鼓励，让我勇敢走出这一步。

3.   人生路很长，知足常乐

人生无非四道题目：学业、事业、家庭、生活。大家都已经在第一题上取得了高分，不能奢求每一道题目都是高分，四道题中有一道高分就是人上人了。我们都太渺小，不要什么都想要。现在还有很多人做着”财富自由”的美梦，请放弃这些不切实际的幻想，去做一个幸福的普通人就已经很好了。

无数次的后悔，无数次的埋怨自己当时的选择。11年前的此时我正在高考，盘算着自己一定能上p大。7年前的此时我在本科毕业，和同学们愉快地拍着各种照片。5年前的此时我踌躇满志选择了这个单位，不曾想从此之后每天想到工作的苦衷和被社会大潮抛弃的恐惧都无法入睡。我的缩影其实是内卷的悲哀，让北大清华的学生去做一个中专生就可以做的跑腿快递，去服务领导，去检查文件的错别字和格式，那纳税人的钱真的打了水漂。这是教育的悲哀，当学习沦为配角，疯狂寻找实习为了一份工作，甚至有的顶尖机构实习写着“尽量全勤，不要因论文和学业请假”……这完全脱离了大学教育的本质，但依然学生趋之若鹜。这更是社会的悲哀，体制内机关单位没有把资源配置到最有价值的地方，而是让很多有能力的人埋没于案牍劳形之中，每年还在标榜自己录用了多少个清华北大的学生，为社会舆论展现自己的“高大上”。有的时候想到了初中就会背诵的韩愈的《马说》，“虽有千里之能，食不饱，力不足，才美不外现，且欲与常马等不可得，安求其能千里也？”回头看来，一千年了，问题好像依然存在。

哀其不幸，怒其不争。我走了很多的弯路，踩了很多的坑，归根结底是缺少职业规划和明确的发展目标，学生思维严重，缺少对于社会的认识。我们缺少了职业教育，缺少了学生到社会的衔接课，我用这么多年来补上。不过不要紧，我才29岁，还有重新再来的资本，对自己说一声没关系，从头再来。

写在最后

我并不是说体制内一无是处。我也有很多朋友在体制内工作顺利，发展很好。体制内也有其独特的优势。体制外也有很多问题，很多同学都想考公务员。我是想说，没有所谓的“好工作”，更多是要看适合自己的工作。每个人的学科背景、兴趣爱好、性格特点、家庭条件都不同，找工作正是了解自己是匹配自己的过程，祝每个学弟学妹都能找到适合自己的工作。

灰度发布，简单来说，就是根据各种条件，让一部分用户使用旧版本，另一部分用户使用新版本。百度百科中解释：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。上述描述的灰度方案A和B需要等量的服务器，这里我们所做的灰度发布稍作改变：用1-2台机器作为B，B测试成功再部署A。用于WEB系统新代码的测试发布，让一部分（IP）用户访问新版本，一部分用户仍然访问正常版本，原理如图:

执行过程：
1、当用户请求到达前端web（代理）服务器Openresty，内嵌的lua模块解析Nginx配置文件中的lua脚本代码；
2、Lua获取客户端IP地址，去查询Redis中是否有该键值，如果有返回值执行@clien2，否则执行@client1。
3、Location @client2把请求转发给预发布服务器，location @client1把请求转发给生产服务器，服务器返回结果，整个过程完成。

Openresty部分配置如下：

upstream client1 { 
        server127.0.0.1:8080;  #模拟生产服务器
    }
upstream client2 {
        server127.0.0.1:8090;  #模拟预发布服务器
    }

server {
        listen80;
        server_name  localhost;
        
        location^~ /test {
            content_by_lua_file/app/ngx_openresty/nginx/conf/huidu.lua
        }
        
        location @client1{
                proxy_pass http://client1;}
        location @client2{
                proxy_pass http://client2;}
     ｝

Lua脚本内容如下：

local redis = require"resty.redis"local cache=redis.new() 
cache:set_timeout(60000)

local ok, err= cache.connect(cache,'127.0.0.1',6379)ifnot okthenngx.say("failed to connect:", err) 
    return 
end 

local red, err= cache:auth("foobared")ifnot redthenngx.say("failed to authenticate:", err)
    return
end

local local_ip= ngx.req.get_headers()["X-Real-IP"]iflocal_ip == nilthenlocal_ip= ngx.req.get_headers()["x_forwarded_for"]
endiflocal_ip == nilthenlocal_ip=ngx.var.remote_addr
end--ngx.say("local_ip is :", local_ip)

local intercept=cache:get(local_ip)ifintercept == local_ipthenngx.exec("@client2")
    return
end

ngx.exec("@client1")

local ok, err=cache:close()ifnot okthenngx.say("failed to close:", err) 
    return 
end

验证：
url：http://192.168.116.145/test/n.jpg （模拟生产环境）
客户端IP：192.168.116.1（模拟公司办公网IP）

1、访问http://192.168.116.145/test/n.jpg
返回的结果是生产服务器的。

在Redis存入客户端IP：

继续访问：
请求到的是预发布服务器返回的结果。

在Redis中删除客户端IP：

然后刷新浏览器：
返回生产服务器的结果。

通过lua实现灰度发布

nginx.conf

[root@server conf]# cat nginx.conf
user  root;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream up1{
	server 127.0.0.1:8081;
    }
    upstream up2{
	server 127.0.0.1:8082;
    }
    upstream all{
	ip_hash;
        serever 127.0.0.1:8081;
        serever 127.0.0.1:8082;
    }
    server {
        listen       80;
        server_name  localhost;

    		# 请求交给lua脚本处理
				location / {
	    		lua_code_cache off;
        	content_by_lua_file /usr/local/nginx/lua/proxy.lua;
				}

				# location @ 用于nginx内部跳转
				location @up1 {
	    		proxy_pass http://up1;
				}


				location @up2 {
	 		   proxy_pass http://up2;
				}

				location @all {
	   			 proxy_pass http://all;
				}
   }
}

proxy.lua

ngx.header.content_type="text/html;charset=utf8"
redis = require('resty.redis')
redis = redis.new()
redis:set_timeout(1000)
ok,err =  redis:connect('127.0.0.1', 6379)
if not ok then
    ngx.say('connect to redis failed ! reason: ' .. err)
end
-- 从redis中检查是否存在即将更新的upstream主机
check_up1 = redis:get('update1') --(up1)
check_up2 = redis:get('update2') --(up2)
redis:close()
-- 注意返回的数据类型来判断
if check_up1 == "1" then
    ngx.exec("@up2")
elseif check_up2 == "1" then
    ngx.exec("@up1")
else
    ngx.exec("@all")
end

-- 原理就是利用redis中设置指定key，比如要更新主机1，则redis中添加key=update1，value=1，当浏览器请求进入nginx的content阶段后执行lua脚本，
-- 脚本中检查redis中是否存在要更新的主机，如果发现某个主机要更新则通过Nginx API for Lua中的ngx.exec接口内部跳转到另一台主机。
-- 如果两个都不更新，则根据nginx自己的方式（默认轮询）分发请求。
-- nginx里使用了ip_hash保持会话，主要是为了用户的请求在后端记录的日志中保持完整。
 

流量复制

在实际开发中经常涉及到项目的升级，而该升级不能简单的上线就完事了，需要验证该升级是否兼容老的上线，因此可能需要并行运行两个项目一段时间进行数据比对和校验，待没问题后再进行上线。这其实就需要进行流量复制，把流量复制到其他服务器上，一种方式是使用如 tcpcopy引流；另外我们还可以使用nginx的HttpLuaModule模块中的ngx.location.capture_multi进行并发执行来模拟复制。

构造两个服务

location /test1 {
        keepalive_timeout 60s; 
        keepalive_requests 1000;
        content_by_lua '
            ngx.print("test1 : ", ngx.req.get_uri_args()["a"])
            ngx.log(ngx.ERR, "request test1")';
    }
    location /test2 {
        keepalive_timeout 60s; 
        keepalive_requests 1000;
        content_by_lua '
            ngx.print("test2 : ", ngx.req.get_uri_args()["a"])
            ngx.log(ngx.ERR, "request test2")';
    }

通过ngx.location.capture_multi调用

location /test {
         lua_socket_connect_timeout 3s;
         lua_socket_send_timeout 3s;
         lua_socket_read_timeout 3s;
         lua_socket_pool_size 100;
         lua_socket_keepalive_timeout 60s;
         lua_socket_buffer_size 8k;

         content_by_lua '
             local res1, res2 = ngx.location.capture_multi{
                   { "/test1", { args = ngx.req.get_uri_args() } },
                   { "/test2", { args = ngx.req.get_uri_args()} },
             }
             if res1.status == ngx.HTTP_OK then
                 ngx.print(res1.body)
             end
             if res2.status ~= ngx.HTTP_OK then
                --记录错误
             end
         ';
    }

此处可以根据需求设置相应的超时时间和长连接连接池等；ngx.location.capture底层通过cosocket实现，而其支持Lua中的协程，通过它可以以同步的方式写非阻塞的代码实现。

此处要考虑记录失败的情况，对失败的数据进行重放还是放弃根据自己业务做处理。

AB测试

AB测试即多版本测试，有时候我们开发了新版本需要灰度测试，即让一部分人看到新版，一部分人看到老版，然后通过访问数据决定是否切换到新版。比如可以通过根据区域、用户等信息进行切版本。

比如京东商城有一个cookie叫做__jda，该cookie是在用户访问网站时种下的，因此我们可以拿到这个cookie，根据这个cookie进行版本选择。

比如两次清空cookie访问发现第二个数字串是变化的，即我们可以根据第二个数字串进行判断。

__jda=122270672.1059377902.1425691107.1425691107.1425699059.1

__jda=122270672.556927616.1425699216.1425699216.1425699216.1。

判断规则可以比较多的选择，比如通过尾号；要切30%的流量到新版，可以通过选择尾号为1，3,5的切到新版，其余的还停留在老版。

1、使用map选择版本 

map $cookie___jda $ab_key {
    default                                       "0";
    ~^\d+\.\d+(?P<k>(1|3|5))\.                    "1";
}

使用 map映射规则，即如果是到新版则等于"1"，到老版等于“0”； 然后我们就可以通过ngx.var.ab_key获取到该数据。

location /abtest1 {
        if ($ab_key = "1") {
            echo_location /test1 ngx.var.args;
        }
        if ($ab_key = "0") {
            echo_location /test2 ngx.var.args;
        }
    }

此处也可以使用proxy_pass到不同版本的服务器上 

location /abtest2 {
        if ($ab_key = "1") {
            rewrite ^ /test1 break;
            proxy_pass http://backend1;
        }
        rewrite ^ /test2 break;
        proxy_pass http://backend2;
    }

2、直接在Lua中使用lua-resty-cookie获取该Cookie进行解析

首先下载lua-resty-cookie

cd /usr/example/lualib/resty/
wget https://raw.githubusercontent.com/cloudflare/lua-resty-cookie/master/lib/resty/cookie.lua

location /abtest3 {
        content_by_lua '

             local ck = require("resty.cookie")
             local cookie = ck:new()
             local ab_key = "0"
             local jda = cookie:get("__jda")
             if jda then
                 local v = ngx.re.match(jda, [[^\d+\.\d+(1|3|5)\.]])
                 if v then
                    ab_key = "1"
                 end
             end

             if ab_key == "1" then
                 ngx.exec("/test1", ngx.var.args)
             else
                 ngx.print(ngx.location.capture("/test2", {args = ngx.req.get_uri_args()}).body)
             end';

    }

 首先使用 lua-resty-cookie获取cookie，然后使用ngx.re.match进行规则的匹配，最后使用ngx.exec或者ngx.location.capture进行处理。此处同时使用ngx.exec和ngx.location.capture目的是为了演示，此外没有对ngx.location.capture进行异常处理。

协程

Lua中没有线程和异步编程编程的概念，对于并发执行提供了协程的概念，个人认为协程是在A运行中发现自己忙则把CPU使用权让出来给B使用，最后A能从中断位置继续执行，本地还是单线程，CPU独占的；因此如果写网络程序需要配合非阻塞I/O来实现。

ngx_lua 模块对协程做了封装，我们可以直接调用ngx.thread API使用，虽然称其为“轻量级线程”，但其本质还是Lua协程。该API必须配合该ngx_lua模块提供的非阻塞I/O API一起使用，比如我们之前使用的ngx.location.capture_multi和lua-resty-redis、lua-resty-mysql等基于cosocket实现的都是支持的。

通过Lua协程我们可以并发的调用多个接口，然后谁先执行成功谁先返回，类似于BigPipe模型。

1、依赖的API 

location /api1 {
        echo_sleep 3;
        echo api1 : $arg_a;
    }
    location /api2 {
        echo_sleep 3;
        echo api2 : $arg_a;
    }

 我们使用echo_sleep等待3秒。

2、串行实现

location /serial {
        content_by_lua '
            local t1 = ngx.now()
            local res1 = ngx.location.capture("/api1", {args = ngx.req.get_uri_args()})
            local res2 = ngx.location.capture("/api2", {args = ngx.req.get_uri_args()})
            local t2 = ngx.now()
            ngx.print(res1.body, "<br/>", res2.body, "<br/>", tostring(t2-t1))';
    }

即一个个的调用，总的执行时间在6秒以上，比如访问http://192.168.1.2/serial?a=22

api1 : 22 
api2 : 22 
6.0040001869202

3、ngx.location.capture_multi实现

location /concurrency1 {
        content_by_lua '
            local t1 = ngx.now()
            local res1,res2 = ngx.location.capture_multi({
                  {"/api1", {args = ngx.req.get_uri_args()}},
                  {"/api2", {args = ngx.req.get_uri_args()}}

            })
            local t2 = ngx.now()
            ngx.print(res1.body, "<br/>", res2.body, "<br/>", tostring(t2-t1))';
    }

直接使用ngx.location.capture_multi来实现，比如访问http://192.168.1.2/concurrency1?a=22

api1 : 22 
api2 : 22 
3.0020000934601

4、协程API实现 

location /concurrency2 {
        content_by_lua '
            local t1 = ngx.now()
            local function capture(uri, args)
               return ngx.location.capture(uri, args)
            end
            local thread1 = ngx.thread.spawn(capture, "/api1", {args = ngx.req.get_uri_args()})
            local thread2 = ngx.thread.spawn(capture, "/api2", {args = ngx.req.get_uri_args()})
            local ok1, res1 = ngx.thread.wait(thread1)
            local ok2, res2 = ngx.thread.wait(thread2)
            local t2 = ngx.now()
            ngx.print(res1.body, "<br/>", res2.body, "<br/>", tostring(t2-t1))';
    }

使用 ngx.thread.spawn创建一个轻量级线程，然后使用 ngx.thread.wait等待该线程的执行成功。比如访问http://192.168.1.2/concurrency2?a=22

api1 : 22 
api2 : 22 
3.0030000209808

其有点类似于Java中的线程池执行模型，但不同于线程池，其每次只执行一个函数，遇到IO等待则让出CPU让下一个执行。我们可以通过下面的方式实现任意一个成功即返回，之前的是等待所有执行成功才返回。

local  ok, res = ngx.thread.wait(thread1, thread2)

Lua协程参考资料

《Programming in Lua》

http://timyang.net/lua/lua-coroutine-vs-java-wait-notify/

https://github.com/andycai/luaprimer/blob/master/05.md

http://my.oschina.net/wangxuanyihaha/blog/186401

http://manual.luaer.cn/2.11.html

去年写过一篇文章《浅谈 Pull Request 与 Change Request 研发协作模式》，详细介绍了 PR Flow 以及 CR Flow 的区别，文末有说到 Gitee 应该提供推送分支自动创建评审的改进，刚好近期也听到很多关于平台支持 CR Flow 的声音，而且在不少客户内部也有类似需求，毕竟这个需求可以解放开发者的一部分精力，对于追求研发效能的当下，自然是一个不错的功能点，另外对于 Gerrit 转到 Gitee 的用户，也是一个平滑的过渡方案。所以写下这篇文章，探讨一下支持 CR Flow 平台的产品实现，并对 CR Flow 实现的底层原理做了一些实验性的工作，以供参阅。

PullRequest & ChangeRequest 分别在说些啥？

PullRequest （也叫 MergeRequest）最初是由 Github 推出的一种开源协作模式，目前 Gitee、Gitlab等平台都支持这种协作模式，而且这种模式目前更多的用在了团队或者企业的内部代码评审层面，这种协作模式一般是由开发者 Fork 一个仓库，或者在仓库内新起一个分支如 zoker/feature-1，无论是哪种方式，所有的大前提是：开发者没有目标分支的写权限，写权限是被严格控制的，必须经过 PullRequest 方式合入代码。

在相应的分支研发并自测完成后，通过 Web 界面 提交一个 PullRequest 请求将这些代码合入到目标分支，这个过程会有自动化测试、自动编译构建、代码评审、代码改进、代码合并等一系列操作，最终完成代码向目标分支的合入。

ChangeRequest 是由 Gerrit 推出的一个概念，Gerrit 是为 AOSP（Android Open Source Project）写的，结合 Repo 工具用来管理庞大的安卓项目，多仓管理也是他的优势之一，但是更多的人把它视为代码评审神器，能够使每一个 Commit 都是可靠。这种模式同样需要严格管控目标分支的写权限，开发者可以在本地起一个分支进行开发。

与 PullRequest 不同的是，ChangeRequest 不需要开发者到 Web 上进行评审请求的提交，推送一个 Commit 到对应的分支之后，会自动创建一个评审单。而且另外一个比较大的区别就是，ChangeRequest 的评审是针对单 Commit 评审，而 PullRequest 针对的是一个或者多个 Commit 的集中评审。

详细说明：https://zoker.io/blog/talk-about-pullrequest-and-changerequest

通过以上的说明，我们大概可以明白了，原来这就是不同协作模式在工具上的区别而已。

现在人们追求研发效能的提升和改进，说到底就是消除一切可能的浪费，让开发者专注于业务的研发，其他的一些工作能自助化的绝不层层审批严卡，能自动化的绝不浪费开发者时间去自助操作。

然而 PR Flow 模式就需要开发者在提交完代码之后，手动的前往平台创建 PullRequest，对于很多已经规范化流程的企业来说，这就是一种浪费，因为：

1. 开发者在接收到卡片的时候已经指定了分支，只要他往这个分支推送代码，那肯定是解决分支对应卡片的问题，无需再进行 PullRequest 的描述的重复填写

2. 在提交卡片的时候，已经关联好了测试用例，PullRequest 无需再进行测试用例的补充，自动化的从卡片获取用例即可

3. 已经限制了开发者做提交的时候必须关联一个有效的卡片（如 fixed #JN7HE3），所以开发者在推送代码的时候，这些提交已经有了它们的身份，亦无须再手动创建 PullRequest

4. ...

CR Flow 恰巧就解决了这个问题，推送的时候可以自动创建评审，但是采用 PR Flow 的平台如 Github、Gitlab、Gitee 等是没有这个能力的，我做过类似在客户端定制钩子调用接口的实现，但是整体实现上并不顺畅，只有服务端统一处理，才能够考虑到各种情况。

如何实现推送自动创建评审？

相信一些了解 Git 的同学第一反应肯定就是 Git Hooks。没错，我在着手去做实验来实现相关逻辑的时候，第一个想到的就是 Update 钩子，但是 Update 钩子还是有一定局限性的。

不过去年10月份，Git 2.29 增加了一项新的能力 Proc-receive 钩子，这个能力是由阿里巴巴 Codeup 团队蒋鑫老师带领贡献的，有了这个钩子，在服务端能够自定义更新引用的工作，可以想象的空间就比较大了。

除此之外，还有一种方式就是 Gerrit 方式，我把这种方式称做帽子戏法，也就是自定义了服务端的 RPC 服务，在服务端做完一系列的处理之后，发给客户端我们想让他看到的数据即可。

所以，要实现推送自动创建评审，目前来看，有三种方式：

1. Gerrit 的帽子戏法

2. 自定义 Update 钩子

3. Git 新能力 Proc-receive 钩子

Gerrit 的帽子戏法

Gerrit 实现 Change Request 的逻辑是是什么呢？Gerrit 规定了推送到指定的 ref如：

gitpushorigin HEAD:refs/for/master

就会进行基于最新的 master进行 commit的检索及评审的创建和更新。

如果 commit还没有在 master上面，那么就会生成一个新的 Change，对应的 Change 存储在 refs/changes下面，如果没有的话则去 packed-refs找。

• 其中 refs/changes/67/67/1对应的就是这次提交的 commit

• 而 refs/changes/67/67/meta则记录此次 Change 的一些基本信息，里面有一个 Change-id 请记住它，这是 Gerrit 能够跟踪具体 commit的关键

如果 commit已经存在在 master上，并且它被修改了，也就是 commit还是那个 commit，但是通过重写， commit id变了，那就会更新对应的 Change 生成一个新的 Patchset，同样存储在 refs/changes/67/67下，只不过编号是 2

然而，Gerrit 怎么知道一个重写后的 commit它的前身呢？答案就是上面的 Change-id ，Gerrit 通过用户配置的本地 commit-msg钩子，将 msg、 commit id等信息 Hash 成一个 Change-id，这个 Change-id 就是贯穿整个 Change 生命周期的唯一标识符

那么问题来了，我推送到 refs/for/master的数据，一不用加 -f强推，二我又看不到拿不到 refs/for/master的内容，感觉这个 refs/for/xxxx就是一个 /dev/null，往里面倒腾啥都行，关键是 Git 客户端还没报错，总是提示成功

* [newbranch]      HEAD -> refs/for/xxx

这跟我们在用 Github、Gitee 平台的习惯不一样啊。没错，我刚开始接触 Gerrit 的时候，同样有这样的疑惑，猜想 Gerrit 应该是做了一些障眼法，服务端做了一些动作，告诉客户端： 好，你推送的这个分支成功了，你回去吧。

当时去翻阅了 Gerrit 的源码：https://gitee.com/mirrors/Gerrit ，发现 Gerrit 是使用 Java 基于 JGit 自己实现的一套服务端的RPC逻辑，而不是像主流的平台那样使用  receive-pack/upload-pack 进行处理，所以才可以那么灵活的应对。

// file: java/com/google/gerrit/server/git/receive/ReceiveCommits.java/*** Receives change upload using the Git receive-packprotocol.** <p>Conceptually, mostuseof Gerrit is apushof some commits to refs/for/BRANCH. However, the* receive-packprotocol that this is based on allows multiplerefupdates to be processed at once.* So we have to be prepared to also handle normal pushes (refs/heads/BRANCH),andlegacy pushes* (refs/changes/CHANGE). It is hard tosplitthis class up further, because normal pushes can also* result in updates to reviews, through the autoclose mechanism.*/

一般情况下，正常往一个分支推送应该是增量的，然后提示我们的信息类似于

803ed6b..5fd69aaHEAD->master

而推送到 refs/for/xxx 的动作由 Gerrit 接管，并且在处理接受完数据之后（比如创建和更新 Change），就返回给客户端一个分支已经被创建的假象

* [newbranch]      HEAD -> refs/for/master

以此来保证客户端不会报错而疑惑，因为你请求的是更新/创建  refs/for/xxx，如果告诉客户端我创建了其他分支，那客户端就会报错，这受限于 report-status能力，不过现在得益于阿里巴巴的贡献，已经新增了 report-status-v2，这个能力就可以让客户端实现接受服务端实际的变更状态，比如更新一个 Change 后提示

* [newbranch]      HEAD -> refs/changes/67/67/5

相信在不久后 Gerrit 应该会跟进。

The 'report-status-v2' capability extends the protocol byadding new option lines in order to support reporting of reference rewritten by the 'proc-receive' hook. The 'proc-receive' hook may handle a command for a pseudo-reference which may create or update one or more references, and each reference may have different name, different new-oid, and different old-oid.

那么，该如何自定义  receive-pack 来实现这种帽子戏法呢？

我基于之前写的一个 http-smart-server（https://gitee.com/kesin/go-git-protocols） 做了一个实验，在调用 receive-pack接收完数据后，不把 receive-pack的输出发给客户端，转而自定义 response数据发给客户端，模拟一个正常推送 master的 receive-pack响应如下：

pw := pktline.NewEncoder(w)//insertlengthmsg//insertband protocolpw.Encode([]byte("unpack ok\n"))pw.Encode([]byte("ok refs/heads/master\n"))//flushpkt0000

客户端在接收到这个响应的时候就能知道服务端正确的解压了包并且如期的完成了 refs/heads/master的更新，那我们来搞点不一样的，比如我推送的是 master分支，但是我让服务端返回 master1被更新成功的信息：

正如上面我们提到的，客户端并不认，因为这这与它的预期不符，转而报错了，我们再次修改代码：

// callGiteeApi createPr(ref, new_oid, old_oid)// other custom operationspw := pktline.NewEncoder(w)// insert length msg// insert band protocolpw.Encode([]byte("unpack ok\n"))pw.Encode([]byte("ng refs/heads/master Your ref master is sleeping!\n"))// flush pkt 0000

我们在响应客户端之前，根据现有信息创建了 PullRequest 并且可以根据这次推送的 Context 信息做一些自定义的其他操作，然后把我们期望客户端看到的结果给它：

自定义 Update 钩子

一般情况下我们在日常使用到 Git 的过程中会涉及到三个服务端的钩子：

• pre-receive 钩子，用来做一些授权检查工作以及引用的批量更新操作，就算有多个 ref一起更新，也只会执行一次

• update 钩子，每一个引用的更新都会触发，用来做版本自动化测试之类的工作

• post-receive 钩子，主要是用来更新引用后的一些工作，比如通知，触发其它服务等

所以在 Update 钩子做这个事情看起来比较合适，我写了一个 Update 钩子的 Proofs of Concept，用来演示，大概的逻辑：

1. 推送的时候检查这个分支是否设置了评审分支，如果设置了评审分支，那不允许直接推送，必须走PR

2. 根据推送的分支和用户进行判定，一个用户在一个评审分支只能有一个PR，类似{username}-{ref}

3. 自动创建完上述分支后，钩子通过api进行PR的创建

4. 如果已经存在pr，那么更新即可

packagemain
import ("fmt""io""os")
func main()  {iflen(os.Args) !=4{fmt.Println("Need 3 args: <ref> <oldrev> <newrev>")os.Exit(1)}ref:= os.Args[1]oldrev := os.Args[2]newrev := os.Args[3]info := fmt.Sprintf("ref: %s, old: %s, new: %s",ref, oldrev, newrev)fmt.Println(info)
ifref=="refs/heads/review"{reviewRefPath := fmt.Sprintf("%s/%s-zoker", os.Getenv("GIT_DIR"),ref)reviewRefExist := truerefFile, err := os.Open(reviewRefPath)iferr != nil {reviewRefExist = falserefFile, err = os.Create(reviewRefPath)}// check non fast-forward between reviewRefandnewrevandthenexit1ifneededio.WriteString(refFile, newrev) //ifcommit is fast forward// involve pr api to create prandalert// createOrUpdateSucess := remote call resultifreviewRefExist {fmt.Printf("Pushes have successfully update in PullRequest: https://gitee.com/xxx/xxx/pulls/xx \n")}else{fmt.Printf("You don't have permission push to %s \n",ref)fmt.Printf("We generate a new branch %s-zoker and automaticlly create a \n",ref)fmt.Printf("PullRequest for you: https://gitee.com/xxx/xxx/pulls/xx\n")}os.Exit(1)}}

通过对 review分支的检测，来做对应的处理：

如果当前用户在对应的目标分支还没有提交 PullRequest，那就创建并提示：

如果当前用户在对应的目标分支已经提交了 PullRequest，那就更新：

上面默认是不冲突的情况，如果冲突的话，我们需要：

1. 如果 review-zoker检测到与 newrev冲突，可以不给更新

2. 如果 review分支冲突的话，是无法继续推送的，这其实不太不合理，因为实际是要更新 review-zoker

而且提示中夹在着错误信息，会对用户产生困扰，我在研究 ezOne 这个产品的时候，发现他们的做法应该是是围绕着 Update 钩子进行的，因为实际试用的情况与我的实验脚本结果是一样的：

只不过 ezOne 把这些提示信息加了颜色，着重展示给用户，但是使用 Update 钩子实现所产生冲突的问题并没有解决

此外 ezOne 应该也在返回给客户的响应上做了一些处理，或者结合使用了上面说的 proc-receive钩子，因为拒绝 master的推送并给出了提示 代码评审通过后方可合入。整体来讲，ezOne 对于这块功能起了一个新的名字叫 DCR（Direct Change Request）。

ezOne DCR 整体使用逻辑总结如下：

1. 分支只要是保护分支，那么推送就会被拒绝，转而自动产生一个 DCR

2. 一个用户对一个目标分支可以有多个 DCR，如果 pushed..master包含某个 pr..master，那就更新，如果不包含那就新建

3. 会严格检查push与目标分支的冲突情况，如果强推也完全按照规则1进行的

4. 更新也只更新线性向前的 DCR，其他的情况并不会更新

5. 如果 Base 和目标分支冲突了，就直接冲突拒绝推送，没有找到此种情况更新 DCR 的方式

Git 新能力 Proc-receive 钩子

上面对 proc-receive钩子有过一些简单的介绍，归根结底就是 receive-pack在更新引用的时候会把匹配到 receive.procReceiveRefs的引用转交给新的钩子 proc-receive进行处理，这个 proc-receive钩子与 receive-pack之间通过 PKT-LINE 格式的命令进行通讯。

两者之间的通信大体如下（我做了详细的注解，你应该可以看得明白）：

# receive-pack 与 proc-receive 相互协商版本和能力S: PKT-LINE(version=1\0push-options atomic...)S:flush-pktH: PKT-LINE(version=1\0push-options...)H:flush-pkt
# receive-pack 在匹配到 receive.procReceiveRefs 的引用后，把这些引用的更新操作转交给 proc-receive 钩子进行处理S: PKT-LINE(<old-oid> <new-oid> <ref>)S: ... ...S:flush-pkt
# pro-receive 钩子接收到这些信息，根据自己的逻辑进行对应的处理，新建引用，更新或者创建 PullRequest 可以安插到这里进行# 如果 proc-receive 钩子处理无误，则告诉 receive-pack 已经处理成功H: PKT-LINE(ok <ref>)
# 如果 proc-receive 钩子处理失败，亦或创建或更新 PullRequest 失败，均可以自定义这些引用更新失败的信息H: PKT-LINE(ng <ref> <reason>)
# 如果发现自己没法处理，甩锅给 receive-pack 继续处理即可H: PKT-LINE(ok <ref>)H: PKT-LINE(optionfall-through)

如果你对 proc-receive 钩子实现的原理感兴趣，可以参见蒋老师的演讲文稿： https://git-repo.info/zh_cn/2020/03/agit-flow-and-git-repo/

基于上述对  proc-receive 钩子的理解，我使用 Go 简单的写了一个  proc-receive 钩子，代码如下：

packagemain
import("os")
funcmain(){// init pkt reader and writerpd := NewPktDecoder(os.Stdin)pe := NewPktEncoder(os.Stdout)
// get receive-pack version_ = pd.Decode(&[]byte{})_ = pd.Decode(&[]byte{})
// send proc-receive version_ = pe.Encode([]byte("version=1"))_ = pe.Encode(nil)
// scan pktline for matched receive.procReceiveRefsvarc []byte_ = pd.Decode(&c)// c -> command a b refs/xxx/xxx_ = pd.Decode(&[]byte{})
// ----------------------// do what you want, eg: generate ref, call api to create a pr on gitee...// newRef("refs/heads/zoker/xxx", ZERO_OID, c.new_oid)// createGiteePullRequest(new_ref, target_ref)// ----------------------
//_ = pe.Encode([]byte("ok refs/heads/review"))_ = pe.Encode([]byte("ng refs/heads/review PullRequest created or updated, please........"))_ = pe.Encode(nil)}

主要的功能就是与 receive-pack进行通讯，然后告诉 receive-pack分支 review是否更新成功，我们可以在这里进行对应的逻辑处理，比如基于这次推送新建一个引用，或者为每个 Commit 都新建一个引用，基于这个引用去创建一个评审等

阿里云的 Codeup 也就是基于  proc-receive 能力实现的 ChangeRequest 功能，不过整体的产品逻辑是参照 Gerrit 的，与 Gerrit 一样支持往  refs/for/master 推送生成 PullRequest 的，于此同时也支持  refs/drafts/、 refs/for-review/等特殊的前缀，主要是在合入权限上的区别。

Codeup 的 CR 功能使用总结如下：

1. 同一个用户对一个目标分支只能创建一个CR

2. 推送到  refs/for/master 符合 Gerrit 的工作方式，不会报分支未更新的错

3. 更新、回退提交均可更新 CR，回退到目标分支之后，CR 提交就空了

4. 与源冲突的情况可以直接推送，不需要 -f，直接覆盖原 CR

5. 严格按照  HEAD 与  master 的差异来更新 CR，不管是否冲突

6. 与目标分支冲突的情况可以直接推送，但是PR打不开了，一直转圈圈，有的关闭重开就好了，但有的关闭重开也不行

7. 如果有两个以上提交，CR 标题为  merge from xxxxxx，如果只有一个，标题就直接使用了这个提交的提交信息

此外，在使用腾讯工蜂的代码评审功能中，觉得工蜂的设计挺有意思，而且具体的实现也应该是使用了帽子戏法或者 proc-receive钩子，工蜂提供了两个概念：合并请求、代码评审

• 合并请求：与常规的 PullRequest 功能逻辑没太大区别

• 代码评审：可以创建某一个或者多个提交的评审单，用于做代码评审

工蜂对分支提供了两种设置，一种是推送自动创建评审单，也就是无论你往目标分支上推送了什么，都会创建一个评审单用于代码评审，推送会成功更新到目标分支，不会造成中断；另外一种是推送自动创建评审单，但是会拒绝更新目标分支，需要通过评审才能继续推送新的提交。

工蜂的 CR 功能使用总结如下：

1. 保护分支不可强推，不可推送包含多个父提交的提交（可能我哪里没设置对）

2. 自动创建评审有两种选项，推送自动创建评审（仓库级），推送自动创建评审并且通过才能合并（保护分支）

3. 按照单次推送的行为来的（你推上来了什么，就用什么创建 CR，强推也一样，不存在更新的说法）

4. 保护分支的严格模式，推送自动创建了合并请求，看提示应该是修改了协议返回，自动创建了  refs/for/zoker/master/1，用时间戳作为合并请求的标题

5. 已经有合并请求的情况下，无法再次推送 master，会提示  remote: Code review must be approved before push

6. 没找到更新这个自动创建的合并请求的方式（姿势不对还是设定如此？）

7. 关于冲突情况，如果跟目标分支冲突，直接提示冲突，拉取合并再去推送则提示：You arenotallowedtopush codeto a protectedbranchonthisproject，删除 CR 也一样，移除保护分支也一样，尬住了，但是回退后重新产生新的冲突提交即可推送，然后强推到之前的版本，再把刚刚不能推送的合并再次推送，就可以了，估计是什么缓存逻辑被刷新了

谈谈 Gitee 轻量级 Pull Request 的改进

Gitee 在去年推出了轻量级 PR 功能(https://gitee.com/help/articles/4291)，旨在解决用户为开源项目提交贡献过程繁琐的问题。

从其本质上来看，轻量级 PR 要解决的问题其实与现在 Change Request 要解决的问题是一样的，都是为了减少用户的使用成本，使其专注代码层面的贡献。

总结

目前，各个产品都在找寻一种合适的方式来覆盖用户对于自动创建评审的需求。但是我有一种很明显的感觉，就是每一个产品的实现逻辑，都包含了强烈的自身组织的研发协作方式，每种实现逻辑都可以覆盖一部分用户需求，但是并未能满足绝大多数，可能这也跟形形色色的研发协作模式有关。有时候想想，与其绞尽脑汁去想着如何在产品上满足不同用户的需求，倒不如自己定义一个标准，让用户来遵守和使用。

此外，对于 Change Request 功能的技术实现， proc-receive钩子的出现无疑降低了技术门槛，避免了对 receive-pack业务逻辑的侵入。但无论使用哪种方式最终还是要从用户实际需求出发，抓住用户真正的痛点，才能通过技术真真正正的解决问题，而不是又创造了新的问题。

最后，要感谢我的女朋友在进行这篇文章撰写时给我的鼓励和帮助，没有她的支持，我早就写完了。

对于 Change Request 这种协作模式，你有什么建议吗？

前言

Ceph是一个极其复杂的统一分布式存储系统，运维操作门槛高、稳定性不错，性能差强人意，虽然各大厂都在自研分布式存储，但Ceph是不可或缺的参考对象。本文参考了Ceph源代码以及网上各路大神文章，如有侵权，联系删除。简要分析Ceph的架构、重要的模块以及基于Seastar的未来规划，使读者对Ceph有一个大致清晰的认识。

目录

• 1 Ceph概述
• 2 核心组件
• 3 IO流程
• 4 IO顺序性
• 5 PG一致性协议
• 5.1 StateMachine
• 5.2 Failover Overview
• 5.3 PG Peering
• 5.4 Recovery/Backfill
• 6 引擎概述
• 7 FileStore
• 7.1 架构设计
• 7.2 对外接口
• 7.3 日志类型
• 7.4 幂等操作
• 8 BlueStore
• 8.1 架构设计
• 8.2 BlockDevice
• 8.3 磁盘分配器
• 8.4 BlueFS
• 8.5 对象IO
• 9 未来规划

1 Ceph概述

Ceph是由学术界(Sage Weil博士论文)在2006年提出的一个开源的分布式存储系统的解决方案，最早致力于下一代高性能分布式文件存储，经过十多年的发展，还提供了块设备、对象存储S3的接口，成为了统一的分布式存储平台，进而成为开源社区存储领域的明星项目，得到了广泛的实际应用。

Ceph是一个可靠的、自治的、可扩展的分布式存储系统，它支持文件存储、块存储、对象存储三种不同类型的存储，满足存储的多样性需求。整体架构如下：

• 接口层：提供客户端访问存储层的的各种接口，支持POSIX文件接口、块设备接口、对象S3接口，以及用户可以自定义自己的接口。
• Librados：提供上层访问RADOS集群的各种库函数接口，libcephfs、librbd、librgw都是Librados的客户端。
• RADOS：可靠的、自治的分布式对象存储，主要包含Monitor、OSD、MDS节点，提供了一个统一的底层分布式存储系统，支持逻辑存储池概念、副本存储和纠删码、自动恢复、自动rebalance、数据一致性校验、分级缓存、基于dmClock的QoS等核心功能。

2 核心组件

• CephFS：Ceph File System，Ceph对外提供的文件系统服务，MDS来保存CephFS的元数据信息，数据写入Rados集群。
• RBD：Rados Block Device，Ceph对外提供的块设备服务，Ceph里称为Image，元数据很少，保存在特定的Rados对象和扩展属性中，数据写入Rados集群。
• RGW：Rados Gateway，Ceph对外提供的对象存储服务，支持S3、Swift协议，元数据保存在特定的Pool里面，数据写入Rados集群。
• Monitor：保存了MONMap、OSDMap、CRUSHMap、MDSMap等各种Map等集群元数据信息。一个Ceph集群通常需要3个Mon节点，通过Paxos协议同步集群元数据。
• OSD：Object Storage Device，负责处理客户端读写请求的守护进程。一个Ceph集群包含多个OSD节点，每块磁盘一个OSD进程，通过基于PGLog的一致性协议来同步数据。
• MDS：Ceph Metadata Server，文件存储的元数据管理进程，CephFS依赖的元数据服务，对外提供POSIX文件接口，不是Rados集群必须的。
• MGR：Ceph Manager，负责跟踪运行时指标以及集群的运行状态，减轻Mon负担，不是Rados集群必须的。
• Message：网络模块，目前支持Epoll、DPDK(剥离了seastar的网络模块，不使用其share-nothing的框架)、RDMA，默认Epoll。
• ObjectStore：存储引擎，目前支持FileStore、BlueStore、KVStore、MemStore，提供类POSIX接口、支持事务，默认BlueStore。
• CRUSH：数据分布算法，秉承着无需查表，算算就好的理念，极大的减轻了元数据负担(但是感觉过于执着减少元数据了，参考意义并不是很大)，但同时数据分布不均，不过已有 CRUSH优化Paper。
• SCRUB：一致性检查机制，提供scrub(只扫描元数据)、deep_scrub(元数据和数据都扫描)两种方式。
• Pool：抽象的存储池，可以配置不同的故障域也即CRUSH规则，包含多个PG，目前类型支持副本池和纠删池。
• PG：Placement Group，对象的集合，可以更好的分配和管理数据，同一个PG的读写是串行的，一个OSD上一般承载200个PG，目前类型支持副本PG和纠删PG。
• PGLog：PG对应的多个OSD通过基于PGLog的一致性协议来同步数据，仅保存部分操作的oplog，扩缩容、宕机引起的数据迁移过程无需Mon干预，通过PG的Peering、Recovery、Backfill机制来自动处理。
• Object：Ceph-Rados存储集群的基本单元，类似文件系统的文件，包含元数据和数据，支持条带化、稀疏写、随机读写等和文件系统文件差不多的功能，默认4MB。

3 IO流程

此处以RBD块设备为例简要介绍Ceph的IO流程。

1. 用户创建一个Pool，并指定PG的数量。
2. 创建Pool/Image，挂载RBD设备，映射成一块磁盘。
3. 用户写磁盘，将转换为对librbd的调用。
4. librbd对用户写入的数据进行切块并调用librados，每个块是一个object，默认4MB。
5. librados进行 stable_hash算法计算object所属的PG，然后再输入pg_id和CRUSHMap，根据CRUSH算法计算出PG归属的OSD集合。
6. librados将object异步发送到Primary PG，Primary PG将请求发送到Secondary PG。
7. PG所属的OSD在接收到对应的IO请求之后，调用ObjectStore存储引擎层提供的接口进行IO。
8. 最终所有副本都写入完成才返回成功。

Ceph的IO通常都是异步的，所以往往伴随着各种回调，以FileStore为例看下ObjectStore层面的回调：

1. on_journal：数据写入到journal，通常通过DirectIO + Libaio的方式，Journal的数据是sync到磁盘上的。
2. on_readable：数据写入Journal且写入Pagecache中，返回客户端可读。
3. on_commit：Pagecache中的数据sync到磁盘上，返回客户端真正写成功。

4 IO顺序性

分布式系统中通常需要考虑对象读写的顺序性和并发性，如果两个对象没有共享资源，那么就可以并发访问，如果有共享资源就需要加锁操作。对于同一个对象的并发读写来说，通常是通过队列、锁、版本控制等机制来进行并发控制，以免数据错乱，Ceph中对象的并发读写也是通过队列和锁机制来保证的。

PG

Ceph引入PG逻辑概念来对对象进行分组，不同PG之间的对象是可以并发读写的，单个PG之间的对象不能并发读写，也即理论上PG越多并发的对象也越多，但对于系统的负载也高。

不同对象的并发控制

落在不同PG的不同对象是可以并发读写的，落在统一PG的不同对象，在OSD处理线程中会对PG加锁，放进PG队列里，一直等到调用queue_transactions把OSD的事务提交到ObjectStore层才释放PG的锁，也即

对于同一个PG里的不同对象，是通过PG锁来进行并发控制，不过这个过程中不会涉及到对象的IO，所以不太会影响效率。

同一对象的并发控制

同一对象的并发控制是通过PG锁实现的，但是在使用场景上要分为单客户端、多客户端。

1. 单客户端：单客户端对同一个对象的更新操作是串行的，客户端发送更新请求的顺序和服务端收到请求的顺序是一致的。
2. 多客户端：多客户端对同一个对象的并发访问类似于NFS的场景，RADOS以及RBD是不能保证的，CephFS理论上应该可以。

所以接下来主要讨论单客户端下同一对象的异步并发更新。

Message层顺序性

1. TCP层是通过消息序列号来保证一条连接上消息的顺序性。
2. Ceph Message层也是通过全局唯一的tid来保证消息的顺序性。

PG层顺序性

从Message层取到消息进行处理时，OSD处理OP时划分了多个shard，每个shard可以配置多个线程，PG通过哈希的方式映射到不同的shard里面。OSD在处理PG时，从拿到消息就会PG加了写锁，放入到PG的OpSequencer队列，等到把OP请求下发到ObjectStore端才释放写锁。对于同一个对象的并发读写通过对象锁来控制。

对同一个对象进行写操作会加write_lock，对同一个对象的读操作会加read_lock，也就是读写锁，读写是互斥的。写锁从queue_transactions开始到数据写入到Pagecache结束。

对同一个对象上的并发写操作，实际上并不会发生，因为放入PG队列是有序的，第一次写从PG取出放到ObjectStore层之后就会释放锁，然后再把第二次写从PG取出放入到ObjectStore层，取出写OP放到ObjectStore层都是调的异步写的接口，这就需要ObjectStore层来保证两次写的顺序性了。

ObjectStore层顺序性

ObjectStore支持FileStore、BlueStore，也都需要保证IO顺序性。对于写请求，到达ObjectStore层之后，会获取OpSequencer(每个PG一个，用来保证PG内OP顺序)。

FileStore：对于写事务OP来说(都有一个唯一递增的seq)，会按照顺序放进writeq队列，然后write_thread线程通过Libaio将数据写入到Journal里面，此时数据已经是on_disk但不可读，已完成OP的seq序号按序放到journal的finisher队列里（因为Libaio并不保证顺序，会出现先提交的IO后完成，因此采用op的seq序号来保证完成后处理的顺序），如果某个op之前的op还未完成，那么这个op会等到它之前的op都完成后才一起放到finisher队列里，然后把数据写入到Pagecache和sync到数据盘上。

BlueStore：bluestore在拿到写OP时会先通过BlockDevice提供的异步写(Libaio/SPDK/io_uring)接口先把数据写到数据盘，然后再通过RocksDB的WriteBatch接口批量的写元数据和磁盘分配器信息到RocksDB。由于也是通过异步写接口写的，也需要等待该OP之前的OP都完成，才能写元数据到RocksDB。

5 PG一致性协议

在Ceph的设计和实现中，自动数据迁移、自动数据均衡等各种特性都是以PG为基础实现的，PG是最复杂和最难理解的概念，Ceph也基于PG实现了数据的多副本和纠删码存储。基于PG LOG的一致性协议也类似于Raft实现了强一致性。

5.1 StateMachine

PG有20多种状态，状态的多样性也反映了功能的多样性和复杂性。PG状态的变化通过事件驱动的状态机来驱动，比如集群状态的变化，OSD加入、删除、宕机、恢复 、创建Pool等，最终都会转换为一系列的状态机事件，从而驱动状态机在不同状态之间跳转和执行处理。

• Active：活跃态，PG可以正常处理来自客户端的读写请求，PG正常的状态应该是Active+Clean的。
• Unactive：非活跃态，PG不能处理读写请求。
• Clean：干净态，PG当前不存在修复对象，Acting Set和Up Set内容一致，并且大小等于存储池的副本数。
• Peering：类似Raft的Leader选举，使一个PG内的OSD达成一致，不涉及数据迁移等操作。
• Recovering：正在恢复态，集群正在执行迁移或恢复某些对象的副本。
• Backfilling：正在后台填充态，backfill是recovery的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Peers内的OSD实施增量同步(OSD离线太久，新的OSD加入) ，则通过完全拷贝当前Primary所有对象的方式进行全量同步。
• Degraded：降级状态，Peering完成后，PG检测到有OSD有需要被同步或修复的对象，或者当前ActingSet 小于存储池副本数。
• Undersized：PG当前Acting Set小于存储池副本数。ceph默认3副本，min_size参数通常为2，即副本数>=2时就可以进行IO，否则阻塞IO。
• Scrubing：PG正在进行对象的一致性扫描。
• 只有Active状态的PG才能进行IO，可能会有active+clean(最佳)、active+unclean(小毛病)、active+degraded(小毛病)等状态，小毛病不影响IO。

5.2 Failover Overview

故障检测：Ceph分为MON集群和OSD集群两部分，MON集群管理者整个集群的成员状态，将OSD的信息存放在OSDMap中，OSD定期向MON和Peer OSD 发送心跳包，声明自己处于在线状态。MON接收来自OSD的心跳信息确认OSD在线，同时也接收来自OSD对于Peer OSD的故障检测。当MON判断某个OSD节点离线后，便将最新的OSDMap通过心跳随机的发送给OSD，当Client或者OSD处理IO请求时发现自身的OSDMap版本低于对方，便会向MON请求最新的OSDMap，这种Lasy的更新方式，经过一段时间的传播之后，整个集群都会收到最新的OSDMap。

确定恢复数据：OSD在收到OSDMap的更新消息后，会扫描该OSD下所有的PG，如果发现某些PG已经不属于自己，则会删掉其数据。如果该OSD上的PG是Primary PG的话，将会进行PG Peering操作。在Peering过程中，会根据PGLog检查多个副本的一致性，并计算PG的不同副本的数据缺失情况，PG对应的副本OSD都会得到一份对象缺失列表，然后进行后续的Recovery，如果是新节点加入、不足以根据PGLog来Recovery等情况，则会进行Backfill，来恢复整份数据。

数据恢复：在PG Peering过程中会暂停所有的IO，等Peering完成后，PG会进入Active状态，此时便可以接收数据的IO请求，然后根据Peering的信息来决定进行Recovery还是Backfill。对于Replica PG缺失的数据Primary PG会通过Push来推送，对于Primary PG自身缺少的数据会通过Pull方式从其他Replicate PG拉取。在Recovery过程中，恢复的粒度是4M对象，对于无法通过PGlog来恢复的，则进行Backfill进行数据的全量拷贝，等到数据恢复完成后，PG的状态会标记为Clean即所有副本数据保持一致。

5.3 PG Peering

PG的Peering是使一个PG内的所有OSD达成一致的过程，相关重要概念如下：

• up set：pg对应的副本列表，也即通过CRUSH算法选出来的3个副本列表，第一个为primary，其他的为replica。
• active set：对外处理IO的副本列表，通常和up set一致，当恢复时可能会存在临时PG，则active set为临时PG的副本集合，用于对外提供正常IO，当完成恢复后，active set调整为up set。
• pg_temp：临时的PG，当CRUSH算法产生新的up set的primary无法承担起职责(新加入的OSD或者PGLog过于落后的OSD成为了primary，也即需要backfill的primary需要申请临时PG，recovery的primary不需要申请临时PG)，osd就会向mon申请一个临时的PG用于数据正常IO和恢复，Ceph做了优化是在进行CRUSH时就根据集群信息选择是否预填充pg_tmp，从而减少Peering的时间。此时处于Remapped状态，等到数据同步完成，需要取消pg_tmp，再次通过Peering将active_set切回up_set。
• epoch：每个OSDMap都会有一个递增的版本，值越大版本越新，当集群中OSD发生变化时，就会产生新的OSDMap。
• pg log：保存操作的记录，是用于数据恢复的重要结构。并不会保存所有的op log，默认3000条，当有数据需要恢复的时候就会保存10000条。
• Interval：每个PG都有Interval(epoch的操作序列)，每次OSD获取到新的OSDMap时，如果发现 up set、up primary、active set、active primary没有改变，则Interval不用改变，否则就要生成新的current interval，之前的变成past_interval，只要该PG内部的OSD不发生变化，Interval就不会变化。

主要包含三个步骤：

1. GetInfo：作用为确定参与peering过程的osd集合。主OSD会获取该PG对应的所有OSD的pg_info信息放入peer_info。
2. GetLog：作用为选取权威日志。根据各个副本OSD的pg_info信息比较，选取一个具有权威日志的OSD，如果主OSD不具备权威日志，那么就从该具有权威日志的OSD拉取权威日志，拉取完成之后进行合并就具有了权威日志，如果primary自身具有权威日志，则不用合并，否则合并的过程如下：
1. 拉取过来的日志比primary具有更老的日志条目：追加到primary本地日志尾部即可。
2. 拉取过来的日志比primary具有更新的日志条目：追加到primary本地日志头部即可。
3. 合并的过程中，primary如果发现自己有对象需要修复，便会将其加入到missing列表。
3. GetMissing：获取需要恢复的object集合。主OSD拉取其他从OSD的PGLog，与自身权威日志进行对比，计算该OSD缺失的object集合。

5.4 Recovery/Backfill

Peering进行之后，如果Primary检测到自身或者任意一个Peer需要修复对象，则进入Recovery状态，为了影响外部IO，也会限制恢复的速度以及每个OSD上能够同时恢复的PG数量。Recovery一共有两种状态：

1. Pull：如果Primary自身存在待恢复对象，则按照missing列表寻找合适的副本拉取修复对象到本地然后修复。
2. Push：如果Primary检测到其Replica存在待恢复对象，则主动推动待修复对象到Replica，然后由Replica自身修复。

通常总是先执行Pull再执行Push，即先修复Primary再修复Replica，因为Primary承担了客户端的读写，需要优先进行修复，修复情况大致如下：

1. 客户端IO和内部恢复IO可以同时进行。
2. 读写的对象不在恢复列表中：按照正常IO即可。
3. 读取的对象在恢复列表中：如果primary有则可以直接读取，如果没有需要优先恢复该对象，然后读取。
4. 写入的对象在恢复列表中：优先恢复该对象，然后写入。
5. backfill则是primary遍历当前所有的对象，将他们全量拷贝到backfill 的PG中。
6. 恢复完成后，会重新进行Peering，是active set 和up set保持一致，变为active + clean状态。

在恢复对象时，由于PGLog并未记录关于对象修改的详细信息(offset、length等)，所以目前对象的修复都是全量对象(4M)拷贝，不过社区已经支持 部分对象修复。

同时在恢复对象时，由于ObjectStore支持覆盖写，所以在对象上新的写不能丢弃老的对象，需要等老的对象恢复完之后，才能进行该对象新的写入，不过社区已经支持 异步恢复。

6 引擎概述

Ceph提供存储功能的核心组件是RADOS集群，最终都是以对象存储的形式对外提供服务。但在底层的内部实现中，Ceph的后端存储引擎在近十年来经历了许多变化。现如今的Ceph系统中仍然提供的后端存储引擎有FileStore、BlueStore。但该三种存储引擎都是近年来才提出并设计实现的。Ceph的存储引擎也先后经历了EBOFS-->FileStore/btrfs-->FileStore/xfs-->NewStore-->BlueStore。同时Ceph需要支持文件存储，所以其存储引擎提供的接口是类POSIX的，存储引擎操作的对象也具有类似文件系统的语义，也具有其自己的元数据。

7 FileStore

FileStore是Ceph基于文件系统的最早在生成环境比较稳定的单机存储引擎，虽然后来出现了BlueStore，但在一些场景中仍然不能代替FileStore，比如在全是HDD的场景中FileStore可以使用NVME盘做元数据和数据的读写Cache，从而加速IO，BlueStore就只能加速元数据IO。

7.1 架构设计

FileStore是基于文件系统的，为了维护数据的一致性，写入之前数据会先写Journal，然后再写到文件系统，会有一倍的写放大。不过Journal也起到了随机写转换为顺序写、支持事务的作用。

7.2 对外接口

对象的元数据使用KV形式保存，主要有两种保存方式：

• xattrs：保存在本地文件系统的扩展属性中，一般都有大小的限制。
• omap：object map，保存在LevelDB/RocksDB中。

有些文件系统不支持扩展属性，或者扩展属性大小有限制。一般情况下xattr保存一些比较小且经常访问的元数据，omap保存一些大的不经常访问的元数据。

同时ObjectStore使用Transaction类来实现相关的操作，将元数据和数据封装到bufferlist里面，然后写Journal。大致包含OP_TOUCH、OP_WRITE、OP_ZERO、OP_CLONE等42种 事务操作。提供的对外接口大致有：

ObjectStore本身的接口：mount、umount、fsck、repair、mkfs等。

Object本身的接口：read、write、omap、xattrs、snapshot等。

7.3 日志类型

在FileStore的实现中，根据不同的日志提交方式，有两种不同的日志类型：

• Journal writeahead：先提交数据到Journal上(通常配置成一块SSD磁盘)，然后再写入到Pagecache，最后sync到数据盘上。适用于XFS、EXT4等不支持快照的文件系统，是FileStore默认的实现方式。
• Journal parallel：数据提交到Journal和sync到数据盘并行进行，没有完成的先后顺序，适用于BTRFS、ZFS等支持快照的文件系统，由于文件系统支持快照，当写数据盘出错，数据不一致时，文件系统只需要回滚到上一次快照，并replay从上次快照开始的日志就可以，性能要比writeahead高，但是Linux下BTRFS和ZFS不稳定，线上生产环境几乎没人用。

日志处理有三个阶段：

1. 日志提交(journal submit)：数据写入到日志盘，通常使用DirectIO+Libaio，一个单独的write_thread不断从队列取任务执行。
2. 日志应用(journal apply)：日志对应的修改更新到文件系统的文件上，此过程仅仅是写入到了Pagecache。
3. 日志同步(journal commit)：将文件系统的Pagecache脏页sync到磁盘上，此时数据已经持久化到数据盘，Journal便可以删除对应的数据，释放空间。

7.4 幂等操作

在机器异常宕机的情况下，Journal中的数据不一定全部都sync到了数据盘上，有可能一部分还在Pagecache，此时便需要在OSD重启时保证数据的一致性，对Journal做replay。FileStore将已经sync到数据盘的序列号记录在commit_op_seq中，replay的时候从commit_op_seq开始即可。

但是在replay的时候，部分op可能已经sync到数据盘中，但是commit_op_seq却没有体现，序列化比其小，此时如果仍然replay，可能会出现非幂等操作，导致数据不一致。

假设一个事务包含如下3个操作：

1. clone a 到 b。
2. 更新 a。
3. 更新 c。

假设上述操作都做完也已经持久化到数据盘上了，然后立马进程或者系统崩溃，此时sync线程还未来得及更新commit_op_seq，重启回放时，第二次执行clone操作就会clone到a新的数据版本，就会发生不一致。

FileStore在对象的属性中记录最后操作的三元组(序列号、事务编号、OP编号)，因为journal提交的时候有一个唯一的序列号，通过这个序列号， 就可以找到提交时候的事务，然后根据事务编号和OP编号最终定位出最后操作的OP。对于非幂等的操作，操作前先检查下，如果可以继续执行就执行操作，执行完之后设置一个guard。这样对于非幂等操作，如果上次执行过， 肯定是有记录的，再一次执行的时候check就会失败，就不继续执行。

8 BlueStore

Ceph早期的单机对象存储引擎是FileStore，为了维护数据的一致性，写入之前数据会先写Journal，然后再写到文件系统，会有一倍的写放大，而同时现在的文件系统一般都是日志型文件系统(ext系列、xfs)，文件系统本身为了数据的一致性，也会写Journal，此时便相当于维护了两份Journal；另外FileStore是针对HDD的，并没有对SSD作优化，随着SSD的普及，针对SSD优化的单机对象存储也被提上了日程，BlueStore便由此应运而出。

BlueStore最早在Jewel版本中引入，用于在SSD上替代传统的FileStore。作为新一代的高性能对象存储后端，BlueStore在设计中便充分考虑了对SSD以及NVME的适配。针对FileStore的缺陷，BlueStore选择绕过文件系统，直接接管裸设备，直接进行对象数据IO操作，同时元数据存放在RocksDB，大大缩短了整个对象存储的IO路径。BlueStore可以理解为一个支持ACID事物型的本地日志文件系统。

8.1 架构设计

BlueStore是一个事务型的本地日志文件系统。因为面向下一代全闪存阵列的设计，所以BlueStore在保证数据可靠性和一致性的前提下，需要尽可能的减小日志系统中双写带来的影响。全闪存阵列的存储介质的主要开销不再是磁盘寻址时间，而是数据传输时间。因此当一次写入的数据量超过一定规模后，写入Journal盘(SSD)的延时和直接写入数据盘(SSD)的延迟不再有明显优势，所以Journal的存在性便大大减弱了。但是要保证OverWrite(覆盖写)的数据一致性，又不得不借助于Journal，所以针对Journal设计的考量便变得尤为重要了。

一个可行的方式是使用增量日志。针对大范围的覆盖写，只在其前后非磁盘块大小对齐的部分使用Journal，即RMW，其他部分直接重定向写COW即可。

RWM(Read-Modify-Write)：指当覆盖写发生时，如果本次改写的内容不足一个BlockSize，那么需要先将对应的块读上来，然后再内存中将原内容和待修改内容合并Merge，最后将新的块写到原来的位置。但是RMW也带来了两个问题： 一是需要额外的读开销； 二是如果磁盘中途掉电，会有数据损坏的风险。为此我们需要引入Journal，先将待更新数据写入Journal，然后再更新数据，最后再删除Journal对应的空间。

COW(Copy-On-Write)：指当覆盖写发生时，不是更新磁盘对应位置已有的内容，而是新分配一块空间，写入本次更新的内容，然后更新对应的地址指针，最后释放原有数据对应的磁盘空间。理论上COW可以解决RMW的两个问题，但是也带来了其他的问题： 一是COW机制破坏了数据在磁盘分布的物理连续性。经过多次COW后，读数据的顺序读将会便会随机读。 二是针对小于块大小的覆盖写采用COW会得不偿失。 是因为： 一是将新的内容写入新的块后，原有的块仍然保留部分有效内容，不能释放无效空间，而且再次读的时候需要将两个块读出来做Merge操作，才能返回最终需要的数据，将大大影响读性能。 二是存储系统一般元数据越多，功能越丰富，元数据越少，功能越简单。而且任何操作必然涉及元数据，所以元数据是系统中的热点数据。COW涉及空间重分配和地址重定向，将会引入更多的元数据，进而导致系统元数据无法全部缓存在内存里面，性能会大打折扣。

基于以上设计理念，BlueStore的写策略综合运用了COW和RMW策略。 非覆盖写直接分配空间写入即可； 块大小对齐的覆盖写采用COW策略； 小于块大小的覆盖写采用RMW策略。整体架构设计如下图：

• BlockDevice：物理块设备，使用Libaio、SPDK、io_uring操作裸设备，AsyncIO。
• RocksDB：存储对象元数据、对象扩展属性Omap、磁盘分配器元数据。
• BlueRocksEnv：抛弃了传统文件系统，封装RocksDB文件操作的接口。
• BlueFS：小型的Append文件系统，实现了RocksDB::Env接口，给RocksDB用。
• Allocator：磁盘分配器，负责高效的分配磁盘空间。
• Cache：实现了元数据和数据的缓存。

8.2 BlockDevice

Ceph新的存储引擎BlueStore已成为默认的存储引擎，抛弃了对传统文件系统的依赖，直接管理裸设备，通过Libaio的方式进行读写。抽象出了 BlockDevice基类，提供统一的操作接口，后端对应不同的设备类型的实现(Kernel、NVME、PMEM)。

• KernelDevice：通常使用Libaio或者io_uring，适用于HDD和SATA SSD。
• NVMEDevice：通常使用SPDK用户态IO，提升IOPS缩短延迟，适用于NVME磁盘。
• PMEMDevice：当做磁盘来用，使用libpmem库来操作。

IO架构图如下所示：

8.3 磁盘分配器

BlueStore直接管理裸设备，那么必然面临着如何高效分配磁盘中的块。BlueStore支持基于Extent和基于BitMap的两种磁盘分配策略，有 BitMap分配器(基于Bitmap)和 Stupid分配器(基于Extent)，原则上都是尽量顺序分配而达到顺序写。

刚开始使用的是BitMap分配器，由于性能问题又切换到了Stupid分配器。之后Igor Fedotov大神重新设计和实现了 新版本BitMap分配器，性能也比Stupid要好，默认的磁盘分配器又改回了BitMap。

新版本BitMap分配器以Tree-Like的方式组织数据结构，整体分为L0、L1、L2三层。每一层都包含了完整的磁盘空间映射，只不过是slot以及children的粒度不同，这样可以加快查找，如下图所示：

新版本Bitmap分配器分配空间的大体策略如下：

1. 循环从L2中找到可以分配空间的slot以及children位置。
2. 在L2的slot以及children位置的基础上循环找到L1中可以分配空间的slot以及children位置。
3. 在L1的slot以及children位置的基础上循环找到L0中可以分配空间的slot以及children位置。
4. 在1-3步骤中保存分配空间的结果以及设置每层对应位置分配的标志位。

新版本Bitmap分配器整体架构设计有以下几点优势：

1. Allocator避免在内存中使用指针和树形结构，使用vector连续的内存空间。
2. Allocator充分利用64位机器CPU缓存的特性，最大程序的提高性能。
3. Allocator操作的单元是64 bit，而不是在单个bit上操作。
4. Allocator使用3级树状结构，可以更快的查找空闲空间。
5. Allocator在初始化时L0、L1、L2三级BitMap就占用了固定的内存大小。
6. Allocator可以支持并发的分配空闲，锁定L2的children(bit)即可，暂未实现。

BlueStore直接管理裸设备，需要自行管理空间的分配和释放。Stupid和Bitmap分配器的结果是保存在内存中的，分配结果的持久化是通过FreelistManager来做的。

FreelistManager最开始有extent和bitmap两种实现，现在默认为bitmap实现，extent的实现已经废弃。空闲空间持久化到磁盘也是通过RocksDB的Batch写入的。FreelistManager将block按一定数量组成段，每个段对应一个k/v键值对，key为第一个block在磁盘物理地址空间的offset，value为段内每个block的状态，即由0/1组成的位图，1为空闲，0为使用，这样可以通过与1进行异或运算，将分配和回收空间两种操作统一起来。

8.4 BlueFS

RocksDB不支持对裸设备的直接操作，文件的读写必须实现rocksdb::EnvWrapper接口，RocksDB默认实现有POSIX文件系统的读写接口。而POSIX文件系统作为通用的文件系统，其很多功能对于RocksDB来说并不是必须的， 同时RocksDB文件结构层次比较简单，不需要复杂的目录树，对文件系统的使用也比较简单，只使用追加写以及顺序读随机读。为了进一步提升RocksDB的性能，需要对文件系统的功能进行裁剪，而更彻底的办法就是考虑RocksDB的场景量身定制一套本地文件系统，BlueFS也就应运而生。相对于POSIX文件系统有以下几个优点：

1. 元数据结构简单，使用两个map(dir_map、file_map)即可管理文件的所有元数据。
2. 由于RocksDB只需要追加写，所以每次分配物理空间时进行提前预分配，一方面减少空间分配的次数，另一方面做到较好的空间连续性。
3. 由于RocksDB的文件数量较少，可以将文件的元数据全部加载到内存，从而提高读取性能。
4. 多设备支持，BlueFS将存储空间划分了3个层次：Slow慢速空间(存放BlueStore数据)、DB高速空间(存放sstable)、WAL超高速空间(存放WAL、自身Journal)，空间不足或空间不存在时可自动降级到下一层空间。
5. 新型硬件支持，抽象出了block_device，可以支持Libaio、io_uring、SPDK、PMEM、NVME-ZNS。

接口功能

RocksDB是通过BlueRocksEnv来使用BlueFS的，BlueRocksEnv实现了文件读写和目录操作，其他的都继承自rocksdb::EnvWrapper。

• 文件操作：追加写、顺序读(适用于WAL的读，也会进行预读)、随机读(sstable的读，不会进行预读)、重命名、sync、文件锁。
• 目录操作：目录的创建、删除、遍历，目录只有一级，即 /a 、 /a/b、/a/b/c 为同一级目录，整体元数据map可表示为：map<string(目录名), map<string(文件名), file_info(文件元数据)>>。

磁盘布局

BlueFS的数据结构比较简单，主要包含三部分，superblock、journal、data。

• superblock：主要存放BlueFS的全局信息以及日志的信息，其位置固定在BlueFS的头部4K。
• journal：存放元数据操作的日志记录，一般会预分配一块连续区域，写满以后从剩余空间再进行分配，在程序启动加载的时候逐条回放journal记录，从而将元数据加载到内存。也会对journal进行压缩，防止空间浪费、重放时间长。压缩时会遍历元数据，将元数据重新写到新的日志文件中，最后替换日志文件。
• data：实际的文件数据存放区域，每次写入时从剩余空间分配一块区域，存放的是一个个sstable文件的数据。

元数据

BlueFS元数据：主要包含：superblock、dir_map、file_map、文件到物理地址的映射关系。

文件数据：每个文件的数据在物理空间上的地址由若干个extents表：一个extent包含bdev、offset和length三个元素，bdev为设备标识，因为BlueFS将存储空间设备划分为三层：慢速（Slow）空间、高速（DB）空间、超高速（WAL），bdev即标识此extent在哪块设备上，offset表示此extent的数据在设备上的物理偏移地址，length表示该块数据的长度。

structbluefs_extent_t{uint64_toffset=0;uint32_tlength=0;uint8_tbdev;}// 一个sstable就是一个fnodestructbluefs_fnode_t{uint64_tino;uint64_tsize;utime_tmtime;uint8_tprefer_bdev;mempool::bluefs::vector<bluefs_extent_t>extents;uint64_tallocated;}

按照9T盘、sstable 8MB，文件元数据80B来算，所需内存 9 * 1024 * 1024 / 8 * 80 / 1024 / 1024 = 90MB，说明把元数据全部缓存到内存并不会占用过多的内存。

加载流程

1. 加载superblock到内存。
2. 初始化各存储空间的块分配器。
3. 日志回放建立dir_map、file_map来重建整体元数据。
4. 标记已分配空间：BlueFS没有像BlueStore那样使用FreelistManager来持久化分配结果，因为sstable大小固定从不修改，所以BlueFS磁盘分配需求都是比较同意和固定的。会遍历每个文件的分配信息，然后移除相应的磁盘分配器中的空闲空间，防止已分配空间的重复分配。

读写数据

读数据：先从dir_map和file_map找到文件的fnode(包含物理的extent)，然后从对应设备的物理地址读取即可。

写数据：BlueFS只提供append操作，所有文件都是追加写入。RocksDB调用完append以后，数据并未真正落盘，而是先缓存在内存当中，只有调用sync接口时才会真正落盘。

1. open file for write
   打开文件句柄，如果文件不存在则创建新的文件，如果文件存在则会更新文件fnode中的mtime，在事务log_t中添加更新操作，此时事务记录还不会持久化到journal中。
2. append file
   将数据追加到文件当中，此时数据缓存在内存当中，并未落盘，也未分配新的空间。
3. flush data(写数据)
   判断文件已分配剩余空间（fnode中的 allocated - size）是否足够写入缓存数据，若不够则为文件分配新的空间；如果有新分配空间，将文件标记为dirty加到dirty_files当中，将数据进行磁盘块大小对其后落盘，此时数据已经写到硬盘当中，元数据还未更新，同时BlueFS中的文件都是追加写入，不存在原地覆盖写，就算失败也不会污染原来的数据。
4. flush_and_sync_log(写元数据)
   从dirty_files中取到dirty的文件，在事务log_t中添加更新操作（即添加OP_FILE_UPDATE类型的记录），将log_t中的内容sync到journal中，然后移除dirty_files中已更新的文件。

第3步是写数据、第4步是写元数据，都涉及到sync落盘，整体一个文件的写入需要两次sync，已经算是很不错了。

8.5 对象IO

BlueStore中的对象非常类似于文件系统中的文件，每个对象在BlueStore中拥有唯一的ID、大小、从0开始逻辑编址、支持扩展属性等，因此对象的组织形式，类似于文件也是基于Extent。

BlueStore的每个对象对应一个Onode结构体，每个Onode包含一张extent-map，extent-map包含多个extent(lextent即逻辑的extent)，每个extent负责管理对象内的一个逻辑段数据并且关联一个Blob，Blob包含多个pextent(物理的extent，对应磁盘上的一段连续地址空间的数据)，最终将对象的数据映射到磁盘上。具体可参考BlueStore源码分析之对象IO和 BlueStore源码分析之事物状态机。

BlueStore中磁盘的最小分配单元是min_alloc_size，HDD默认64K，SSD默认16K，里面有2种磁盘分配的写类型(分配磁盘空间，数据还在内存)：

1. big-write：对齐到min_alloc_size的写我们称为大写(big-write)，在处理是会根据实际大小生成lextent、blob，lextent包含的区域是min_alloc_size的整数倍，如果lextent是之前写过的，那么会将之前lextent对应的空间记录下来并回收。
2. small-write：落在min_alloc_size区间内的写我们称为小写(small-write)。因为最小分配单元min_alloc_size，HDD默认64K，SSD默认16K，所以如果是一个4KB的IO那么只会占用到blob的一部分，剩余的空间还可以存放其他的数据。所以小写会先根据offset查找有没有可复用的blob，如果没有则生成新的blob。

真正写磁盘时，有两种不同的写类型：

1、simple-write：包含对齐覆盖写(COW)和非覆盖写，先把数据写入新的磁盘block，然后更新RocksDB里面的KV元数据，状态转换图如下：

2、deferred-write：为非对齐覆盖写，先把数据作为WAL写RocksDB即先写日志，然后会进行RMW操作写数据到磁盘，最后CleanupRocksDB中的deferred-write的数据。

3、simple-write + deferred-write：上层的一次IO很有可能同时涉及到simple-write和deferred-write，其状态机就是上面两个加起来，只不过少了deferred-write的写WAL一步，因为可以在simple-write写元数据时就一同把WAL写入RocksDB。

9 未来规划

随着硬件的不断发展，IO的速度越来越快，PMEM和NVME也逐渐成为了存储系统的主流选择，相比之下CPU的速度没有那么快了，反而甚至成为了系统的瓶颈。如何高效合理的利用新型硬件是分布式存储不得不面临的一个重大问题。Ceph传统的线程模型是多线程+队列的模型，一个IO从发起到完成要经历重重队列和不同的线程池，锁竞争、上下文切换和Cache Miss比较严重，也导致IO延迟迟迟降不下来。通过Perf发现CPU主要都耗在了锁竞争和系统调用上，Ceph自身的序列化和反序列化也比较消耗CPU，所以需要一套新的编程框架来解决上述问题。Seastar是一套基于future-promsie现代化高效的share-nothing的网络编程框架，从18年开始，Ceph社区便基于Seastar来重构整个OSD，项目代号 Crimson，来更好的解决上述问题。

Crimson设计目标

1. 最小化CPU开销。
2. 减少跨核通信。
3. 减少数据拷贝。
4. Bypass Kernel，减少上下文切换。
5. 支持新硬件：ZNS-NVME、PMEM等。

线程模型

性能对比

测试RBD时，在达到同等iops和延迟时，crimson-osd的cpu比ceph-osd的cpu少了好几倍。

BlueStore适配

BlueStore目前是Ceph里性能比较高的单机存储引擎，从设计研发到稳定差不多持续了3年时间，足以说明研发一个单机存储引擎的时间成本是比较高的。由于BlueStore不符合Seastar的编程模型，所以需要对BlueStore适配，目前有两种方案：

1. BlueStore-Alien：使用一个Alien Thread，使用Seastar的编程模型专门向Seastar-Reactor提交BlueStore的任务。
2. BlueStore-Native：使用Seastar-Env来实现RocksDB的Rocksdb-Env，从而更原生的适配。

但是由于RocksDB有自己的线程模型，外部不可控，所以无论怎么适配都不是最好的方案，理论上从0开始用基于Seastar的模型来写一个单机存储引擎是最完美的方案，于是便有了SeaStore，而BlueStore的适配也作为中间过渡方案，最多可用于HDD。

SeaStore

SeaStore是下一代的ObjectStore，适用于Crimson的后端存储，专门为了NVME设计，使用SPDK访问，同时由于Flash设备的特性，重写时必须先要进行擦除操作，也就是内部需要做GC，是不可控的，所以Ceph希望把Flash的GC提到SeaStore中来做：

1. SeaStore的逻辑段(segment)理想情况下与硬件segment(Flash擦除单位)对齐。
2. SeaStar是每个线程一个CPU核，所以将底层按照CPU核进行分段，每个核分配指定个数的segment。
3. 当磁盘利用率达到阈值时，将少量的GC清理工作和正常的写流量一起做。
4. 元数据使用B+数存储，而不是原来的RocksDB。
5. 所有segment都是追加顺序写入的。

10 参考资源

1. https://github.com/ceph/ceph-v13.1.0
2. https://zhuanlan.zhihu.com/分步试存储
3. Ceph设计原理与实现-中兴通讯
4. Ceph十年经验总结：文件系统是否适合做分布式文件系统的后端
5. Sage: bluestore-a-new-storage-backend-for-ceph
6. Crimson: a-new-ceph-osd-for-the-age-of-persistent-memory-and-fast-nvme-storage

上一篇文章我提到了Nagle算法，是为了解决报头大数据小从而导致网络利用率低的问题，这其实会带来新的问题。除此之外我们一起来看看tcp还会有什么优化策略呢！本文纯属学习记录，不完善或错误之处若指正将不胜感激。如有被误导的朋友，望海涵。

首先我们先康康Nagle算法

Nagle算法规则

• （1）如果包长度达到MSS，则允许发送；
• （2）如果该包含有FIN，则允许发送；
• （3）设置了TCP_NODELAY选项，则允许发送；
• （4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
• （5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

延迟ACK

ACK机制中，在接收方收到一个包之后会先检查是否需要立即回应ACK，否则进入延迟ACK逻辑。 参考，
优点显而易见，提高了网络信道的利用率

当Nagle遇见延迟ACK

假想一个场景 MSS为8个中文字（最大报文长度）
甲需要发送两个应用层报文给乙——“你好”！“我是甲”。显然这两个报文都是不足8的，但是由于“你好”满足Nagel的第4条规则所以会第一时间发送出去，由于ACK延迟，甲迟迟收不到乙的确认。于是等到超时发送。
这会产生一个明显的延迟
解决

• 关闭Nagle算法，使用TCP套接字选项TCP_NODELAY可以关闭套接字选项（不推荐，有更多的优化策略）
• 使用writev，而不是两次调用write，单个writev调用会使tcp输出一次而不是两次，只产生一个tcp分节，这是首选方法

流量控制之滑动窗口

滑动窗口是为了平衡发送方和接收方速率不匹配，发送窗口在连接建立时由双方商定。但在通信的过程中，一般由接收方反馈本身的缓冲区大小从而动态调节发送窗口（缓冲区）大小

拥塞控制

为了方便，我们假设主机A给主机B传输数据
我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ACK，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。 然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，而A发送的数据包被堵在了半路，迟迟没有到达B。这个时候A误认为是发生了丢包情况，会重新传输这个数据包。
结果就是不仅浪费了信道资源，还会使网络更加拥塞。因此，我们需要进行拥塞控制

慢开始和拥塞避免

• 在建立连接之后是如何确定拥塞窗口的大小？(拥塞窗口和滑动窗口注意区别)
  • 第一种策略，第一次发送一个包，如果没有丢失就+1，以此类推
  • 第二种策略，第一次发送一个包，如果没有丢失就乘以2，以此类推
  实际上第一种方式增长过于缓慢，难以快速适应网络拥塞情况，而第二种方式指数型增长，很容易到达拥塞阈值。
  所以二者取其长，在前期使用指数增长，当到达某一个数值之后进行线性增长
  但是无论是指数增长还是线性增长最终都会到达一个MAX值，此时会重新以1开始启动并把阈值设置为MAX/2
  我们把确定拥塞窗口大小的过程中指数增长阶段称之为 慢开始，线性增长阶段称之为 拥塞避免

快速重传与快速恢复

前面说过了，当出现网络拥塞时会重启慢开始过程

• 怎么判断网络拥塞？
  • 当网络拥塞时，会出现大量的丢包
• 超时重发（丢包）一定是网络拥塞吗？
  • 网络拥塞会导致大量的包触发超时重发事件。而当一个单独的包出现损坏或者丢包时，也会导致超时重发，所以超时重发不一定是网络拥塞
• 如何判断超时重发的原因
  • 网络拥塞会导致大量的丢包
  • 单个的丢包，由于延迟ACK规则，后序到达的每到达一个包，接收端都会回复相同的ACK。故当发送方接收到三个相同的ACK时，表明发生了单个的丢包

单个丢包事件，当发送方接收到三个相同的ACK时，此时发送方不必等待序号为ACK-1包的超时，会立即重发。并把当前的阈值设置为MAX，新的阈值为MAX/2，以 拥塞窗口 = MAX/2 进行增长
重发阶段我们称之为 快速重传，窗口参数的调整阶段称之为 快速恢复