InfluxDB-安装部署

发表于 2019-04-09 | 更新于 2019-04-12 | 分类于 InfluxDB | 评论数：

前言

转载自

https://wsgzao.github.io/post/influxdb/

InfluxDB 是专为时序数据设计的数据库，能支撑大量的读写负载，是一个高性能的时序数据 datastore。

InfluxDB is the Time Series Database in the TICK Stack

扩展阅读

InfluxDB - https://www.influxdata.com/time-series-platform/influxdb/

InfluxDB 简介

InfluxDB is the Time Series Database in the TICK Stack

InfluxData’s TICK Stack is built around InfluxDB to handle massive amounts of time-stamped information. This time series database provides support for your metrics analysis needs, from DevOps Monitoring, IoT Sensor data, and Real-Time Analytics. Users can adapt their SQL skills with InfluxQL, so they can get up to speed on this time series database.

默认预留端口:

8086，HTTP API
8088，RPC 端口，用于备份和恢复

NTP 服务:
InfluxDB 使用机器本地时间作为 timestamp，需要机器之间使用 NTP 进行同步；如果没有同步的话，写入的时间序列数据可能会不准确

InfluxDB 安装

InfluxDB 里存储的数据被称为时间序列数据, InfluxDB 存储方式跟传统关系型数据库不同的是：传统关系型数据库通过数据库 + 表 + 字段组织数据，InfluxDB 通过指标、标签、字段组织数据，时间戳是默认的索引列，标签跟字段其实就相当于关系型数据库中的字段，只不过标签会被索引，而字段不会。

Grafana 默认支持的数据源：Graphite，InfluxDB，OpenTSDB，Prometheus，Elasticsearch，CloudWatch
Grafana 支持同时绑定多套数据源，根据自己需求管理即可，这里以 InfluxDB 为例。

https://portal.influxdata.com/downloads

# install influxdb
cat > /etc/yum.repos.d/influxdb.repo << 'EOF'
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF

# yum install influxdb
yum install -y influxdb

# start and enable influxdb
sudo systemctl start influxdb
sudo systemctl enable influxdb
sudo systemctl status influxdb

# 通过 influx 命令进入 cli 命令行 
influx
Connected to http://localhost:8086 version 1.4.2
InfluxDB shell version: 1.4.2
>

# 查看用户 
SHOW USERS

# 创建用户 
CREATE USER influx WITH PASSWORD 'influx' WITH ALL PRIVILEGES

# 查看用户 
SHOW USERS

# 创建数据库 
CREATE DATABASE test

# 查看数据库 
SHOW DATABASES

# Using 数据库 
USE test

# 插入数据 
INSERT cpu,host=192.168.1.1 load=0.1,usage=0.2

# 查询所有数据 
SELECT * FROM "cpu"
SELECT "host","load","usage" FROM "cpu"

# 根据条件查询 
SELECT "host","load","usage" FROM "cpu" WHERE "host" = '192.168.1.1'
SELECT "host","load","usage" FROM "cpu" WHERE "usage" > 0.1

# 创建数据库 
CREATE DATABASE "db_name"
# 显示所有数据库 
SHOW DATABASES
# 删除数据库 
DROP DATABASE "db_name"

# 使用数据库 
USE mydb
# 显示该数据库中的表 
SHOW MEASUREMENTS
# 删除表 
DROP MEASUREMENT "t_name"

# 创建数据库 API
curl -i -XPOST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE test"

# 写入数据 API

# 写入单条 
curl -i -XPOST http://localhost:8086/write?db=test --data-binary "cpu,host=192.168.1.3 load=0.1,usage=0.33"
curl -i -XPOST http://localhost:8086/write?db=test --data-binary "cpu,host=192.168.1.3 load=0.1,usage=0.33 6666666666666666666"

# 写入多条 
curl -i -XPOST http://localhost:8086/write?db=test --data-binary "cpu,host=192.168.1.2 load=0.1,usage=0.22 1666666666666666661 
cpu,host=192.168.1.3 load=0.1,usage=0.33 1666666666666666661 
cpu,host=192.168.1.2 load=0.2,usage=0.22 1666666666666666662 
cpu,host=192.168.1.3 load=0.2,usage=0.33 1666666666666666662"

# 查询数据 API
curl -G http://localhost:8086/query?db=test --data-urlencode "q=SELECT * FROM  \"cpu\""

InfluxDB 配置优化

配置文件默认全部注释掉，使用默认的配置项，可以根据需要配置。每个配置项有对应的、相同功能的环境变量。

配置文件：/etc/influxdb/influxdb.conf

查看配置：influxd config

[meta]                                # 元数据 
dir = /var/lib/influxdb/meta  

[data]                                # 数据 / WAL
dir = /var/lib/influxdb/data  
wal-dir = /var/lib/influxdb/wal  
cache-max-memory-size = "1g"          # Cache 最大可用内存 

[coordinator]                         # 查询相关 
query-timeout = "0s"                  # 查询最大执行时间  
log-queries-after = "0s"              # 打印慢查询 

[http]           # HTTP 服务 
auth-enabled = false                  # 启用安全认证  
max-connection-limit = 0              # 最大连接数

更多帮助信息请参考官网
InfluxDB documentation - https://docs.influxdata.com/platform/introduction

Erlang-发布持续集成流程-1

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

前言

持续集成介绍

我比较懒,这里我就不介绍了,直接贴连接:持续集成是什么？

流程

公司的发布流程分为四个阶段:DEV->SIT->UAT->PROD ,这也代表着,我们的持续集成(CI)也分同样的四个阶段.

DEV和SIT都是在内网,可以通过ssh直连,但是UAT和PROD在外网,开发不能直接更新,只能通过丢relup的release包给到运维那边去处理

因此现在如果要做CI的话,前两个环境通过ssh直接操作,后两个只能是打包了

公司用的是gitlab的CI,所以下面我们来看看如何用gitlab的CI去完成erlang发布应用的持续集成.

DEV环境

大致步骤

编译阶段,通过则进入下一步,不通过发送通知
测试阶段,通过则进入下一步,不通过发送通知
部署阶段,不通过发送通知
获取当前版本号备用
如果存在OLD_VSN的环境变量,跳到5, 否则下一步
通过ssh获取目标机器运行中的版本号
判断从ssh获取到的内容,如果是机器没有运行,则直接打包发布,否知下一步
对比当前版本和旧版本,相同则不需要升级和发布然后退出,不相同则下一步
通过代码生成relup发布包,然后ssh到目标机器升级版本

具体流程图

note:上面这个流程图只是DEV,其他环境的会有不同,之后会说到

实现

创建项目

rebar3 new app urf, urf=upgrade release flow

Makefile

APP_NAME = urf
all: compile test
APP_VER=$(shell awk '/release_vsn/{ print $$1 }' rebar.config | tr -d \")
###===================================================================
### build
###===================================================================
.PHONY: get-deps co compile run rel_tar
get-deps:
	rebar3 get-deps
co:compile
compile: get-deps
	rebar3 compile
### clean
.PHONY: clean distclean
clean:
	rebar3 clean
distclean: test_clean
	rebar3 clean -a
rel_tar:
	rebar3 tar
###===================================================================
### test
###===================================================================
.PHONY: test eunit ct test_shell test_run test_clean
test: epmd
	rebar3 do eunit -v, ct -v, cover -v
eunit: epmd
	rebar3 do eunit -v, cover
ct: epmd
	rebar3 do ct -v, cover
test_shell:
	rebar3 as test compile
	erl -pa _build/test/lib/*/ebin -pa _build/test/lib/$(APP_NAME)/test
test_run: epmd
	rebar3 as test shell
test_clean:
	@rm -rf _build/test/lib/$(APP_NAME)/test _build/test/logs _build/test/cover
###===================================================================
### relup
###===================================================================
.PHONY: tag up_vsn up_app_vsn up_relx_vsn clean_appup build_old_vsn relup check_appup
tag:
	git tag $(APP_VER)
up_vsn: up_app_vsn up_relx_vsn
up_app_vsn:
	@exec script/up_app_vsn.sh
up_relx_vsn:
	@exec script/up_relx_vsn.sh
clean_appup:
	rebar3 appup clean
	rm -f _build/default/lib/*/ebin/*.appup
build_old_vsn:
	@exec script/build_old_vsn.sh
relup:
	@exec script/relup.sh
check_appup:
	@exec script/check_appup.sh
###===================================================================
### other
###===================================================================
.PHONY: help tree logtail epmd
help:
	rebar3 help
tree:
	rebar3 tree
epmd:
	@pgrep epmd 2> /dev/null > /dev/null || epmd -daemon || true

上面部分除了比较常见的build & test 部分外还增加了relup的一些命令

tag: 给当前版本打tag

up_app_vsn: 修改src/*.app.src文件的版本号,最后一位+1

up_relx_vsn: 修改rebar.config文件的版本号,最后一位+1

up_vsn: up_app_vsn + up_relx_vsn

clean_appup: 清理appup文件,打包relup文件前必须清理一次,不然appup插件检测到应用已经存在appup文件就不会再生成新的了

build_old_vsn: 打包旧的版本,下面会放出脚本文件

relup: 打包relup版本,下面会放出脚本文件

check_appup: 打印所有应用下的appup文件

rebar.config

{erl_opts, [
    encrypt_debug_info
]}.
{plugins, [
    {rebar3_appup_plugin, "2.2.1"}
]}.
{deps, []}.
%% for test
{cover_enabled, true}.
{cover_print_enabled, true}.
{eunit_opts, [
    {dir, ["test/eunit"]}
]}.
{ct_opts, [
    {dir, ["test/ct"]},
    {readable, true}
]}.
%% for make release
{relx, [
    {include_erts, true},
    {system_libs, true},
    {dev_mode, false},
    {extended_start_script, true},
    {sys_config, "config/sys.config"},
    {vm_args, "config/vm.args"},
    {release, {urf,
        "0.1.0" %% release_vsn
    }, [urf]}
]}.

首先,应用发布升级,当然少不了增加appup插件:

1
2
3

{plugins, [
    {rebar3_appup_plugin, "2.2.1"}
]}.

其次是增加编译保护:

1
2
3

{erl_opts, [
    encrypt_debug_info
]}.

增加这个encrypt_debug_info的主要原因是因为我们编译的代码必须要带有debug_info,不然appup插件会报错,但是同时增加了debug_info之后编译出来的beam文件是可以被反编译的,所以需要增加保护,另外增加了这个只是保护了当前这个app,但是依赖的其他app并不会有保护,后面我们会讲到使用rebar.config.script文件来将deps的其他app也保护起来.

增加了上面这个保护还需要在项目根目录下增加一个.erlang.crypt文件,内容类似如下:

[{debug_info, des3_cbc, [], "12345678912345678912345678912345"}].
最后是增加relx:

{relx, [
    {include_erts, true},
    {system_libs, true},
    {dev_mode, false},
    {extended_start_script, true},
    {sys_config, "config/sys.config"},
    {vm_args, "config/vm.args"},
    {release, {urf,
        "0.1.0" %% release_vsn
    }, [urf]}
]}.

可以看到版本好附近有一个注释release_vsn,这个注释的主要作用标记版本号,脚本会通过这个标记找到版本号

rebar.config.script

%%main(CONFIG) ->
    CONFIG_1 =
        case lists:keyfind(add_overrides, 1, CONFIG) of
            false -> CONFIG;
            {_, AddOverrides} ->
                Overrides = lists:concat([[{add, App, AddOverride} || App <- Apps] || {Apps, AddOverride} <- AddOverrides]),
                OldOverrides = proplists:get_value(overrides, CONFIG, []),
                lists:keystore(overrides, 1, CONFIG, {overrides, Overrides ++ OldOverrides})
        end,
    IsCI = os:getenv("CI_COMMIT_SHA") =/= false,
    IsRelup = os:getenv("RELUP_TAR") =/= false,
    ChangeProfileFun =
        fun(test, ProfileConfig0) -> {test, ProfileConfig0};
            (ProfileName, ProfileConfig0) ->
                ProfileConfig1 = maps:from_list(ProfileConfig0),
                Relx0 = maps:get(relx, ProfileConfig1, []),
                Relx2 =
                    case IsCI of
                        false -> Relx0;
                        _ ->
                            Relx1 = lists:keystore(include_erts, 1, Relx0, {include_erts, true}),
                            lists:keystore(system_libs, 1, Relx1, {system_libs, true})
                    end,
                Relx =
                    case IsRelup of
                        false -> Relx2;
                        _ ->
                            Relx3 = lists:keystore(include_erts, 1, Relx2, {include_erts, false}),
                            lists:keystore(system_libs, 1, Relx3, {system_libs, false})
                    end,
                ProfileConfig = maps:to_list(ProfileConfig1#{relx => Relx}),
                {ProfileName, ProfileConfig}
        end,
    Profiles0 = proplists:get_value(profiles, CONFIG_1, []),
    Profiles = [ChangeProfileFun(RebarProfile, ProfileConfig) ||
        {RebarProfile, ProfileConfig} <- Profiles0],
    CONFIG_2 = lists:keystore(profiles, 1, CONFIG_1, {profiles, Profiles}),
    {_, CONFIG_3} = ChangeProfileFun(none, CONFIG_2),
    LAST_CONFIG =
        case IsCI of
            false -> CONFIG_3;
            _ ->
                lists:keystore(global_rebar_dir, 1, CONFIG_3, {global_rebar_dir, "_build/rebar3"})
        end,
%%    io:format("~n~p~n", [LAST_CONFIG]),
    LAST_CONFIG.

rebar.config.script不熟悉的同学我这里简单介绍一下:

作用:

通过执行erlang脚本动态的修改rebar.config的内容

运行原理

在运行rebar3相关的命令之后,rebar3首先会读取rebar.config,然后将所有内容复制给CONFIG这个变量,然后再执行rebar.config.script这个文件,运行结束之后的结果就是最终的rebar的配置了

然后再来说说上面的代码:

add_overrides主要是为了给deps的其他app加上保护,用法如下:

增加到rebar.config文件里:

1
2
3

{add_overrides, [
    {[app1,app2,app3,...], [{erl_opts, [encrypt_debug_info]}]}
]}.

第二部分是根据环境变量来判断是否在ci环境和是否保护RELUP_TAR里

一般不变更otp的版本和依赖不增加系统库的前提下,我们打包relup的包是不需要再包含erts和系统库,这样可以大大减少打包之后文件的大小, 因此我们在打包relup的时候,会在export变量 RELUP_TAR 到环境变量,这样只要在脚本里判断如果有这个变量则设置include_erts和system_libs为false.
另外一般我们的开发机器是ubuntu,但是线上的环境是centos,所以我们本地编译线上的包的时候会制定centos版的erlang的位置,幸运的是,我们的ci的runner的环境也是centos,因此我们如果判断到是在ci环境里时,只要设置成true就行了.
在ci环境,我们会使用cache,但是gitlab的ci的cache只会保存项目下的文件,因此像一些保存在~/.cache/rebar3下的hex包就不会被保存,这样我们每次编译的时候都要去拉一遍hex的pkg,幸好,rebar3可以修改这些文件的位置,只要我们设置global_rebar_dir的位置为项目下的_build/rebar3,之后我们再设置cache保存这个文件夹就完美解决这个问题了.

ps:可以看到第一行有一句注释,这句注释并不是必须的,其实它主要左右是我在idea里修改这个文件的时候,会打开这个注释,然后这个文件就变成了一个方法了,所有修改的时候格式也不会变化,同时也可以方便的用idea的格式化功能,算是一个小技巧,不过最后记得用完重新注释第一行,不然rebar3运行的时候会报错

.gitlab.ci.yml

image: cerl
before_script:
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  - mkdir -p ~/.ssh
  - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
after_script:
  - rm -rf _build/default/lib/urf
  - rm -rf ~/.git-credentials
stages:
  - build
  - test
  - deploy
cache:
  paths:
    - _build/default
    - _build/rebar3
build:
  stage: build
  except:
    - tags
  script:
    - make compile || ./script/ci_notice.sh "Build Fail"
  tags:
    - dockers
test:
  stage: test
  coverage: '/\|\s*total\s*\|\s*(\d+)%\s*\|/'
  except:
    - tags
  script:
    - make test || ./script/ci_notice.sh "Test Fail"
  tags:
    - dockers
deploy_dev:
  stage: deploy
  only:
    - /^d_dev$/
  except:
    - tags
  script:
    - ./script/ci_deploy.sh || ./script/ci_notice.sh "Deploy Fail"
  environment:
    name: dev
  variables:
    SSH_USER_HOST: "user@server"
    SERVER: "dev"
  tags:
    - dockers

对于gitlab 的 CI 不是很熟悉的同学可以看一下官方文档,文档里会给你很详尽的说明,同时也建议大家先系统性的学习一遍.gitlab.ci.yml文档的配置再回来看这篇文章.

之前说到过我们有三个阶段:

stages:
  - build # 编译阶段
  - test # 测试阶段
  - deploy # 部署阶段

cache这一部分,ci有cache会大大减少整个流程的执行时间,这里cache了两个文件夹default和rebar3文件夹就够了

cache:
  paths:
    - _build/default
    - _build/rebar3

build和test两个阶段比较简单,build就用make compile, test的话make test,另外如果想看到测试的代码覆盖率的话可以增加coverage,增加之后gitlab的页面那里就能显示这次的代码覆盖率了,其他就不一一详细说明了,主要来看看deploy阶段:

deploy_dev:
  stage: deploy
  only:
    - /^d_dev$/
  except:
    - tags
  script:
    - ./script/ci_deploy.sh || ./script/ci_notice.sh "Deploy Fail"
  environment:
    name: dev
  variables:
    SSH_USER_HOST: "user@server"
    REBAR_PROFILE: "dev"
  tags:
    - dockers

这个阶段我们只针对d_dev这个分支,所以如果我们要部署或者升级dev环境,就只需要切换到这个分支然后合并最新的代码,最后推送这个分支到服务器,然后ci会帮你解决一切了,当然还是要通过我们写的脚本ci_deploy.sh来解决.

ci_deploy.sh

#!/usr/bin/env bash
case $OSTYPE in
    darwin*) SCRIPT=$(readlink $0 || true);;
    *) SCRIPT=$(readlink -f $0 || true);;
esac
[ -z $SCRIPT ] && SCRIPT=$0
SCRIPT_DIR="$(cd `dirname "$SCRIPT"` && pwd -P)"
cd "$SCRIPT_DIR/.."
if [ -z $SSH_USER_HOST ]
then
    echo "empty SSH_USER_HOST"
    exit 1
fi
if [ -z $SERVER ]
then
    echo "empty SERVER"
    exit 1
fi
REL_NAME=$(awk -F '[,{]' '/\{release, \{/{ print $4 }' rebar.config)
NEW_VSN=$(awk '/release_vsn/{ print $1 }' rebar.config | tr -d \")
[ -z $TARGET_DIR ] && TARGET_DIR="/data/$REL_NAME"
export TARGET_DIR=$TARGET_DIR
export REBAR_PROFILE=$SERVER
TAR_FILE0="$REL_NAME-$NEW_VSN.tar.gz"
TAR_FILE="_build/$REBAR_PROFILE/rel/$REL_NAME/$TAR_FILE0"
export OLD_VSN=`exec $SCRIPT_DIR/ssh_get_vsn.sh`
only_send_and_start() {
    echo "rebar3 tar" && \
    rebar3 tar && \
    echo "scp $TAR_FILE $SSH_USER_HOST:$TARGET_DIR" && \
    scp $TAR_FILE $SSH_USER_HOST:$TARGET_DIR && \
    echo "ssh $SSH_USER_HOST \"cd $TARGET_DIR && tar zxf $TAR_FILE0 && rm -f $TAR_FILE0 && ./bin/$REL_NAME start\"" && \
    ssh $SSH_USER_HOST "cd $TARGET_DIR && tar zxf $TAR_FILE0 && rm -f $TAR_FILE0 && ./bin/$REL_NAME start" && \
    echo "run successfully"
}
case $OLD_VSN in
    "miss_file")
        only_send_and_start;;
    "Node is not running!")
        only_send_and_start;;
    $NEW_VSN)
        echo "same vsn : $NEW_VSN";;
    *)
        $SCRIPT_DIR/build_old_vsn.sh && \
        echo "rebar3 appup clean" && \
        rebar3 appup clean && \
        echo "rm -f _build/default/lib/*/ebin/*.appup" && \
        rm -f _build/default/lib/*/ebin/*.appup && \
        echo "rebar3 get-deps" && \
        rebar3 get-deps && \
        echo "rebar3 release" && \
        rebar3 release && \
        echo "rebar3 appup compile" && \
        rebar3 appup compile && \
        echo "rebar3 appup generate --previous_version $OLD_VSN" && \
        rebar3 appup generate --previous_version $OLD_VSN && \
        echo "rebar3 relup --upfrom $OLD_VSN" && \
        rebar3 relup --upfrom $OLD_VSN && \
        echo "rebar3 tar" && \
        rebar3 tar && \
        echo "scp $TAR_FILE $SSH_USER_HOST:$TARGET_DIR/releases" && \
        scp $TAR_FILE $SSH_USER_HOST:$TARGET_DIR/releases && \
        echo "ssh $SSH_USER_HOST \"cd $TARGET_DIR && ./bin/$REL_NAME upgrade $NEW_VSN\"" && \
        ssh $SSH_USER_HOST "cd $TARGET_DIR && ./bin/$REL_NAME upgrade $NEW_VSN" && \
        echo "upgrade successfully";;
esac

ssh_get_vsn.sh

#!/usr/bin/env bash
case $OSTYPE in
    darwin*) SCRIPT=$(readlink $0 || true);;
    *) SCRIPT=$(readlink -f $0 || true);;
esac
[ -z $SCRIPT ] && SCRIPT=$0
SCRIPT_DIR="$(cd `dirname "$SCRIPT"` && pwd -P)"
cd "$SCRIPT_DIR/.."
if [ -z $SSH_USER_HOST ]
then
    echo "empty SSH_USER_HOST"
    exit 1
fi
if [ -z $TARGET_DIR ]
then
    echo "empty TARGET_DIR"
    exit 1
fi
REL_NAME=$(awk -F '[,{]' '/\{release, \{/{ print $4 }' rebar.config)
ssh_cmd_get_versions="([ -f $TARGET_DIR/bin/$REL_NAME ] && cd $TARGET_DIR ; ./bin/$REL_NAME versions | tr -d '\n') || ([ ! -f $TARGET_DIR/bin/$REL_NAME ] && mkdir -p $TARGET_DIR ; echo miss_file)"
#echo "ssh $SSH_USER_HOST \"${ssh_cmd_get_versions}\""
versions=`ssh $SSH_USER_HOST "${ssh_cmd_get_versions}"`
case $versions in
    "miss_file")
        echo "miss_file";;
    "Node is not running!")
        echo "Node is not running!";;
    *)
        echo $(echo $versions | sed -r "s/.*\*\ ([0-9]+.[0-9]+.[0-9]+)\ permanent.*/\1/g")
esac

上面的这些脚本其实只是之前的流程的转义,我这里就不重复了.st=>start: 开始 e=>end: 结束 compile_f=>operation: 告知执行失败,异常结束 deploy=>operation: 部署阶段 get_dev=>operation: 获取当前版本号备用 pack=>operation: 打包后发送到机器上直接启动 update=>operation: 打包relup发布包发送到目标机器并升级版本 old_vsn=>condition: 存在OLD_VSN的环境变量 m_vsn=>condition: 获取目标机器运行中的版本号 same_vsn=>condition: 当前版本号和旧版本号相同 compile_test=>condition: 测试阶段 compile=>condition: 编译阶段 st->compile compile(yes)->compile_test compile(no)->compile_f compile_test(yes)->deploy->get_dev->old_vsn compile_test(no)->compile_f old_vsn(yes)->same_vsn old_vsn(no)->m_vsn same_vsn(yes)->e same_vsn(no)->update m_vsn(yes)->same_vsn m_vsn(no)->pack{"scale":1,"line-width":2,"line-length":50,"text-margin":10,"font-size":12}

Erlang-发布版本升级-7-sys模块

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

第二章的时候,我们已经接触过sys模块了,现在我们来进一步看一下源码的实现.

我们还是用回第二章的例子:

-module(sync_code_reload).
-behaviour(gen_server).
-export([start/0, vsn/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
    terminate/2, code_change/3]).
-record(state, {}).
start() ->
    gen_server:start(?MODULE, [], []).
vsn() -> 1.
init([]) ->
    {ok, #state{}}.
handle_call(_Request, _From, State) ->
    {reply, ok, State}.
handle_cast(_Request, State) ->
    {noreply, State}.
handle_info(_Info, State) ->
    {noreply, State}.
terminate(_Reason, _State) ->
    ok.
code_change(_OldVsn, {state}, _Extra) ->
    io:format("old:~p, ex:~p~n", [_OldVsn, _Extra]),
    {ok, #state{}}.

先从进程启动的位置开始切入:

gen_server.erl:

1 2	start_link(Mod, Args, Options) -> gen:start(?MODULE, link, Mod, Args, Options).

进入gen模块最后会回调本模块的init_it方法:

init_it(Starter, self, Name, Mod, Args, Options) ->
    init_it(Starter, self(), Name, Mod, Args, Options);
init_it(Starter, Parent, Name0, Mod, Args, Options) ->
    Name = gen:name(Name0),
    Debug = gen:debug_options(Name, Options),
    case catch Mod:init(Args) of
   {ok, State} ->
       proc_lib:init_ack(Starter, {ok, self()}),      
       loop(Parent, Name, State, Mod, infinity, Debug);
   {ok, State, Timeout} ->
       proc_lib:init_ack(Starter, {ok, self()}),      
       loop(Parent, Name, State, Mod, Timeout, Debug);
   {stop, Reason} ->
       %% For consistency, we must make sure that the
       %% registered name (if any) is unregistered before
       %% the parent process is notified about the failure.
       %% (Otherwise, the parent process could get
       %% an 'already_started' error if it immediately
       %% tried starting the process again.)
       gen:unregister_name(Name0),
       proc_lib:init_ack(Starter, {error, Reason}),
       exit(Reason);
   ignore ->
       gen:unregister_name(Name0),
       proc_lib:init_ack(Starter, ignore),
       exit(normal);
   {'EXIT', Reason} ->
       gen:unregister_name(Name0),
       proc_lib:init_ack(Starter, {error, Reason}),
       exit(Reason);
   Else ->
       Error = {bad_return_value, Else},
       proc_lib:init_ack(Starter, {error, Error}),
       exit(Error)
    end.

进入init_it之后会调用回调模块的init方法回去初始状态,然后进入loop:

loop(Parent, Name, State, Mod, hibernate, Debug) ->
    proc_lib:hibernate(?MODULE,wake_hib,[Parent, Name, State, Mod, Debug]);
loop(Parent, Name, State, Mod, Time, Debug) ->
    Msg = receive
        Input ->
        Input
    after Time ->
      timeout
    end,
    decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, false).
进入loop之后是等待消息,当接受到消息之后会进入decode_msg处理:

decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, Hib) ->
    case Msg of
  {system, From, Req} ->
      sys:handle_system_msg(Req, From, Parent, ?MODULE, Debug,
          [Name, State, Mod, Time], Hib);
  {'EXIT', Parent, Reason} ->
      terminate(Reason, Name, Msg, Mod, State, Debug);
  _Msg when Debug =:= [] ->
      handle_msg(Msg, Parent, Name, State, Mod);
  _Msg ->
      Debug1 = sys:handle_debug(Debug, fun print_event/3,
              Name, {in, Msg}),
      handle_msg(Msg, Parent, Name, State, Mod, Debug1)
    end.

接受到系统消息{system, From, Req}会调用sys:handle_system_msg方法处理,如果是普通消息会进入handle_msg处理,处理完普通消息最后会回到loop,现在我们来看看sys:suspend/1 做了什么:

suspend(Name) -> send_system_msg(Name, suspend). %% 发送一个系统消息到进程
...
send_system_msg(Name, Request) ->
    case catch gen:call(Name, system, Request) of
  {ok,Res} -> Res;
  {'EXIT', Reason} -> exit({Reason, mfa(Name, Request)})
    end.

就是发送一个系统消息给进程,通过之前的分析,我们知道gen_server处理系统消息是通过调用sys:handle_system_msg方法来处理的,直接看调用sys:handle_system_msg方法:

handle_system_msg(Msg, From, Parent, Mod, Debug, Misc, Hib) ->
   handle_system_msg(running, Msg, From, Parent, Mod, Debug, Misc, Hib).
handle_system_msg(SysState, Msg, From, Parent, Mod, Debug, Misc, Hib) ->
    case do_cmd(SysState, Msg, Parent, Mod, Debug, Misc) of %% Msg = suspend
  {suspended, Reply, NDebug, NMisc} ->
      _ = gen:reply(From, Reply),
      suspend_loop(suspended, Parent, Mod, NDebug, NMisc, Hib); %% 进入suspend_loop
  {running, Reply, NDebug, NMisc} ->
      _ = gen:reply(From, Reply),
            Mod:system_continue(Parent, NDebug, NMisc);
  {{terminating, Reason}, Reply, NDebug, NMisc} ->
      _ = gen:reply(From, Reply),
      Mod:system_terminate(Reason, Parent, NDebug, NMisc)
    end.

进入do_cmd:

1 2	do_cmd(_, suspend, _Parent, _Mod, Debug, Misc) -> {suspended, ok, Debug, Misc};

返回一个状态suspended:然后进入suspend_loop:

%% 进入 suspend_loop 之后就停留在receive上,只处理系统消息和异常,不再处理其他消息也就是暂停处理其他消息了
%% 也就是从gen_server:loop转换到sys:suspend_loop
suspend_loop(SysState, Parent, Mod, Debug, Misc, Hib) ->
    case Hib of
  true ->
     suspend_loop_hib(SysState, Parent, Mod, Debug, Misc, Hib);
  _ ->
      receive
    {system, From, Msg} ->
        handle_system_msg(SysState, Msg, From, Parent, Mod, Debug, Misc, Hib);
    {'EXIT', Parent, Reason} ->
        Mod:system_terminate(Reason, Parent, Debug, Misc)
      end
    end.

从源代码中我们可以看到 sys:suspend/1 的主要认为就是从gen_server:loop转换到sys:suspend_loop ,而这个方法只处理了系统消息和异常退出消息,其他消息是不出理的,其他消息会留在邮箱里,这也就完成了暂停了.

这时候我们应该执行加载新代码模块进入vm:l(sync_code_reload).;然后再调用sys:change_code/4 通知到进程去回调模块的code_change方法对内部状态做相应的改变:

sys.erl:

change_code(Name, Mod, Vsn, Extra) -> %% 仍然是发送系统消息
    send_system_msg(Name, {change_code, Mod, Vsn, Extra}).
...
%% 从handle_system_msg进入do_cmd
do_cmd(suspended, {change_code, Module, Vsn, Extra}, _Parent,
       Mod, Debug, Misc) ->
    {Res, NMisc} = do_change_code(Mod, Module, Vsn, Extra, Misc), %% 进入 do_change_code
    {suspended, Res, Debug, NMisc};
do_cmd(SysState, Other, _Parent, _Mod, Debug, Misc) ->
    {SysState, {error, {unknown_system_msg, Other}}, Debug, Misc}.
...
do_change_code(Mod, Module, Vsn, Extra, Misc) -> %% 这里 Mod=gen_server
    case catch Mod:system_code_change(Misc, Module, Vsn, Extra) of
  {ok, NMisc} -> {ok, NMisc};
  Else -> {{error, Else}, Misc}
    end.

在处理change_code的时候会先调用gen_server:system_code_change/4:

system_code_change([Name, State, Mod, Time], _Module, OldVsn, Extra) ->
    case catch Mod:code_change(OldVsn, State, Extra) of  %% 终于看到我们熟悉的code_change/3
   {ok, NewState} -> {ok, [Name, NewState, Mod, Time]}; %% 使用返回的新的NewState
   Else -> Else
    end.

%% 用之前的例子来说这里 Mod=sync_code_reload
执行完code_change之后我们获得了新的内部状态,这样就避免了与新代码的冲突了,最后需要恢复一下进程,然后正常处理消息,调用sys:resume:

resume(Name) -> send_system_msg(Name, resume). %% 同样是发送系统消息
...
handle_system_msg(SysState, Msg, From, Parent, Mod, Debug, Misc, Hib) ->
    case do_cmd(SysState, Msg, Parent, Mod, Debug, Misc) of  %% 进入do_cmd, Msg=resume
  {suspended, Reply, NDebug, NMisc} ->
      _ = gen:reply(From, Reply),
      suspend_loop(suspended, Parent, Mod, NDebug, NMisc, Hib);
  {running, Reply, NDebug, NMisc} -> %% running
      _ = gen:reply(From, Reply),
            Mod:system_continue(Parent, NDebug, NMisc);  %% 回调system_continue, Mod=gen_server
  {{terminating, Reason}, Reply, NDebug, NMisc} ->
      _ = gen:reply(From, Reply),
      Mod:system_terminate(Reason, Parent, NDebug, NMisc)
    end.
...
do_cmd(_, resume, _Parent, _Mod, Debug, Misc) -> %% resume
    {running, ok, Debug, Misc}; %% 返回 running
do_cmd(SysState, get_state, _Parent, Mod, Debug, Misc) ->
    {SysState, do_get_state(Mod, Misc), Debug, Misc};
...

恢复状态为running后,会回调gen_server:system_continue方法:

1 2	system_continue(Parent, Debug, [Name, State, Mod, Time]) -> %% 回调 loop(Parent, Name, State, Mod, Time, Debug). %% 从新进入loop

这个方法主要做的是带着新的state进入loop,进入loop之后会正常的接受和处理消息.

总结:

我们可以看到sys的暂停只是将进程的处理方法从gen_server的loop的接受并处理全部消息切换到sys:suspend_loop方法,只处理系统消息,其他都不处理;这样也确保了在加载新代码之后到执行变更进程内部状态这段时间内不会收到其他消息,这样也不会造成因为代码的版本不同,内部状态数据格式不对而异常退出这样的事情发送了.

Erlang-发布版本升级-6-升级模块与进程

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

或许有些同学会很容易搞混,在升级中到底是升级进程还是升级代码模块.

答案显然是肯定的,升级代码模块,而我们说的升级进程,只是在需要同步升级进程内部状态的时候才需要,而同步更新也是先加载更新新的代码模块,然后再通知进程执行内部状态的转变.

只是,我们都知道我们appup里面只有提到模块,里面并没有提及到进程,而我们都知道进程的标示pid,都是动态的,而我们在做同步代码热更的时候,是怎么将模块与进程管理起来的呢?下面我带大家从源码中找出答案.

进程模块关系

我们知道,进程标示pid都是动态的,因此我们不可能在appup文件里面写这个进程的pid;所以我们想要通知一个进程做内部状态变更,只能通过某种方式让这些进程与模块建立关系.

之前的章节我们有提到过,指令分两种:

OTP supports a set of release handling instructions that are used when creating .appup files. The release handler understands a subset of these, the low-level instructions. To make it easier for the user, there are also a number of high-level instructions, which are translated to low-level instructions by systools:make_relup.

普通(High-Level)指令和底层(Low-Level)指令的区别: 普通指令是提供给用户使用的,而底层指令是通过普通指令转换而来的

我们之前生产的*.appup文件, 会在版本发布前的relup阶段,通过调用systools:make_relup将全部普通指令转换为底层指令

我们先来看看第一种:

%% appup generated for rus_gen_server by rebar3_appup_plugin (2017/09/18 14:46:53)
{ "0.2.0",
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }],
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }]
}.

这是我们需要同步更新rus_gen_server这个代码模块的appup文件,然后看看转换之后的relup:

{"0.2.0",
 [{"0.1.0",[],
   [{load_object_code,{rus_gen_server,"0.2.0",[rus_gen_server]}},
    point_of_no_return,
    {suspend,[rus_gen_server]},
    {load,{rus_gen_server,brutal_purge,brutal_purge}},
    {code_change,up,[{rus_gen_server,[]}]},
    {resume,[rus_gen_server]}]}],
 [{"0.1.0",[],
   [{load_object_code,{rus_gen_server,"0.1.0",[rus_gen_server]}},
    point_of_no_return,
    {suspend,[rus_gen_server]},
    {code_change,down,[{rus_gen_server,[]}]},
    {load,{rus_gen_server,brutal_purge,brutal_purge}},
    {resume,[rus_gen_server]}]}]}.

已经转换成底层指令了,接下来我们看一下在更新的时候,系统是怎么执行这些指令的:

我们从暂停(suspend)指令开始看起:

eval({suspend, Modules}, EvalState) ->
    Procs = get_supervised_procs(),
    NewSuspended =
	lists:foldl(fun(ModSpec, Suspended) ->
			    {Module, Def} = case ModSpec of 
						{Mod, ModTimeout} ->
						    {Mod, ModTimeout};
						Mod ->
						    {Mod, default}
					    end,
			    Timeout = get_opt(suspend_timeout, EvalState, Def),
			    Pids = suspend(Module, Procs, Timeout),
			    [{Module, Pids} | Suspended]
		    end,
		    EvalState#eval_state.suspended,
		    Modules),
    EvalState#eval_state{suspended = NewSuspended};

可以看到这个方法最主要的方法就是通过调用方法get_supervised_procs() 获得了模块与进程的一个对应关系,然后保存进了内部状态里,之后还会用到.

我们再来看看get_supervised_procs() 这个方法做了什么事情:

get_supervised_procs() -> %% 查找到应用下所有的sup进程
    lists:foldl(
      fun(Application, Procs) ->
              get_master_procs(Application,
                               Procs,
                               application_controller:get_master(Application))
      end,
      [],
      get_application_names()).
get_supervised_procs(_, Root, Procs, {ok, SupMod}) ->
    get_procs(maybe_supervisor_which_children(Root, SupMod, Root), Root) ++
        [{undefined, undefined, Root, [SupMod]} |  Procs];
get_supervised_procs(Application, Root, Procs, {error, _}) ->
    error_logger:error_msg("release_handler: cannot find top supervisor for "
                           "application ~w~n", [Application]),
    get_procs(maybe_supervisor_which_children(Root, Application, Root), Root) ++ Procs.
get_application_names() ->
    lists:map(fun({Application, _Name, _Vsn}) ->
                      Application
              end,
              application:which_applications()).
get_master_procs(Application, Procs, Pid) when is_pid(Pid) ->
    {Root, _AppMod} = application_master:get_child(Pid),
    get_supervised_procs(Application, Root, Procs, get_supervisor_module(Root));
get_master_procs(_, Procs, _) ->
    Procs.
get_procs([{Name, Pid, worker, dynamic} | T], Sup) when is_pid(Pid) -> %% Modules=dynamic
    Mods = maybe_get_dynamic_mods(Name, Pid),
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];
get_procs([{Name, Pid, worker, Mods} | T], Sup) when is_pid(Pid), is_list(Mods) -> %% 动态去获取Modules
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];
get_procs([{Name, Pid, supervisor, Mods} | T], Sup) when is_pid(Pid) ->
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)] ++
        get_procs(maybe_supervisor_which_children(Pid, Name, Pid), Pid);
get_procs([_H | T], Sup) ->
    get_procs(T, Sup);
get_procs(_, _Sup) ->
    [].
maybe_supervisor_which_children(Proc, Name, Pid) ->
    case get_proc_state(Proc) of
        noproc ->
            %% process exited before we could interrogate it.
            %% not necessarily a bug, but reporting a warning as a curiosity.
            error_logger:warning_msg("release_handler: a process (~p) exited"
                                     " during supervision tree interrogation."
                                     " Continuing ...~n", [Proc]),
            [];
        suspended ->
            error_logger:error_msg("release_handler: a which_children call"
                                   " to ~p (~w) was avoided. This supervisor"
                                   " is suspended and should likely be upgraded"
                                   " differently. Exiting ...~n", [Name, Pid]),
            error(suspended_supervisor);
        running ->
            case catch supervisor:which_children(Pid) of
                Res when is_list(Res) ->
                    Res;
                Other ->
                    error_logger:error_msg("release_handler: ~p~nerror during"
                                           " a which_children call to ~p (~w)."
                                           " [State: running] Exiting ... ~n",
                                           [Other, Name, Pid]),
                    error(which_children_failed)
            end
    end.

首先通过拿到全局所有的应用的master进程

拿到master下面的子进程,也就是顶级supervisor

获取顶级supervisor下面的所有子进程

子进程通过子进程规格定义里的Mods对应:{Sup, Name, Pid, Mods}

通过上面的代码我们可以发现,在进行代码暂停之前,系统通过调用get_supervised_procs()找到应用下的sup,然后通过sup的内部状态获取子进程和它的规格定义,我们都知道,规格定义里面有指定了这个进程对应的模块:

-type child_spec() :: #{id := child_id(),       % mandatory
         start := mfargs(),      % mandatory
         restart => restart(),   % optional
         shutdown => shutdown(), % optional
         type => worker(),       % optional
         modules => modules()}.
-type modules()  :: [module()] | 'dynamic'.

可以指定为一个列表也可以设置为dynamic,这种情况下一节再细谈,先来说说模块列表的情况:

最后get_supervised_procs()会返回这样一个列表[{Sup, Name, Pid, Mods},…],可以看到列表里面已经包含了pid和Mods,也就建立起了对应关系了,但是这里有个前提条件,就是你的进程必须被这个应用下的sup进程管理,如果不是的话系统是不可能找到他们之间的对应关系的.

这样一个流程之后,就获得了一个进程与多个模块的一对多对应关系,我们再看会代码:

eval({suspend, Modules}, EvalState) ->
	Procs = get_supervised_procs(),
	NewSuspended =
	lists:foldl(fun(ModSpec, Suspended) ->
		    {Module, Def} = case ModSpec of 
					{Mod, ModTimeout} ->
					    {Mod, ModTimeout};
					Mod ->
					    {Mod, default}
				    end,
		    Timeout = get_opt(suspend_timeout, EvalState, Def),
		    Pids = suspend(Module, Procs, Timeout),
		    [{Module, Pids} | Suspended]
	    end,
	    EvalState#eval_state.suspended,
	    Modules),
	EvalState#eval_state{suspended = NewSuspended};
...
suspend(Mod, Procs, Timeout) ->
    lists:zf(fun({_Sup, _Name, Pid, Mods}) -> 
		     case lists:member(Mod, Mods) of
			 true ->
			     case catch sys_suspend(Pid, Timeout) of
				 ok -> {true, Pid};
				 _ -> 
				     % If the proc hangs, make sure to
				     % resume it when it gets suspended!
				     catch sys:resume(Pid),
				     false
			     end;
			 false ->
			     false
		     end
	     end,
	     Procs).
sys_suspend(Pid, default) ->
    sys:suspend(Pid);
sys_suspend(Pid, Timeout) ->
    sys:suspend(Pid, Timeout).

可以看到代码中{pid, Mods}这样的关系,经过一轮转换之后变成了{Module, Pids}的关系,然后并把执行暂停成功的关系保存起来,以后还会用到,这样就完成了suspend指令了.

suspend之后是指令{load,{rus_gen_server,brutal_purge,brutal_purge}},这个指令只是简单的将代码加载进vm而已,继续看下一条指令:{code_change,up,[{rus_gen_server,[]}]} 执行code_change:

eval({code_change, Modules}, EvalState) ->
    eval({code_change, up, Modules}, EvalState);
eval({code_change, Mode, Modules}, EvalState) ->
    Suspended = EvalState#eval_state.suspended,
    Vsns = EvalState#eval_state.vsns,
    Timeout = get_opt(code_change_timeout, EvalState, default),
    lists:foreach(fun({Mod, Extra}) ->
           Vsn =
               case lists:keysearch(Mod, 1, Vsns) of
              {value, {Mod, OldVsn, _NewVsn}}
                when Mode == up -> OldVsn;
              {value, {Mod, _OldVsn, NewVsn}}
                when Mode == down -> {down, NewVsn};
              _ when Mode == up -> undefined;
              _ -> {down, undefined}
               end,
           case lists:keysearch(Mod, 1, Suspended) of
               {value, {_Mod, Pids}} ->
              change_code(Pids, Mod, Vsn, Extra, Timeout);
               _ -> ok
           end
        end,
        Modules),
    EvalState;
...
change_code(Pids, Mod, Vsn, Extra, Timeout) ->
    Fun = fun(Pid) -> 
		  case sys_change_code(Pid, Mod, Vsn, Extra, Timeout) of
		      ok ->
			  ok;
		      {error,Reason} ->
			  throw({code_change_failed,Pid,Mod,Vsn,Reason})
		  end
	  end,
    lists:foreach(Fun, Pids).
sys_change_code(Pid, Mod, Vsn, Extra, default) ->
    sys:change_code(Pid, Mod, Vsn, Extra);
sys_change_code(Pid, Mod, Vsn, Extra, Timeout) ->
    sys:change_code(Pid, Mod, Vsn, Extra, Timeout).

code_change指令是拿到了之前保存的已经暂停的进程与模块对应关系列表,然后从中查找去查找模块,然后再逐个进程进行通知执行变更内部状态的方法,完成之后是恢复指令:{resume,[rus_gen_server]}], resume:

eval({resume, Modules}, EvalState) ->
    NewSuspended =
	lists:foldl(fun(Mod, Suspended) ->
			    lists:filter(fun({Mod2, Pids}) when Mod2 == Mod ->
						 resume(Pids),
						 false;
					    (_) ->
						 true
					 end,
					 Suspended)
		    end,
		    EvalState#eval_state.suspended,
		    Modules),
    EvalState#eval_state{suspended = NewSuspended};
...
resume(Pids) ->
    lists:foreach(fun(Pid) -> catch sys:resume(Pid) end, Pids).

恢复这个指令比较简单,依然是拿到之前的关系列表,然后查找到模块,然后再逐个进程进行恢复,恢复成功之后就从列表里面删除掉这个模块和进程的对应关系.

整个流程就这么简单

supervisor子规格的dynamic

从上面的代码我们可以看到一个地方:

get_procs([{Name, Pid, worker, dynamic} | T], Sup) when is_pid(Pid) -> %% Modules=dynamic
    Mods = maybe_get_dynamic_mods(Name, Pid),  %% 动态去获取Modules
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];
get_procs([{Name, Pid, worker, Mods} | T], Sup) when is_pid(Pid), is_list(Mods) -> %% 正常Modules
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];

了解supervisor子规格定义都知道,最后一个字段是允许设置为dynamic:

-type child_spec() :: #{id := child_id(),       % mandatory
         start := mfargs(),      % mandatory
         restart => restart(),   % optional
         shutdown => shutdown(), % optional
         type => worker(),       % optional
         modules => modules()}.
-type modules()  :: [module()] | 'dynamic'.

那这个有什么作用呢?

我们之前有用过gen_event吧,没有用过也没有关系,error_logger用过吧,error_logger的就是通过gen_event来实现的,我们知道我们可以通过add_report_handler或者delete_report_handler接口变更回调模块,内部其实使用的是gen_event的add_handler和delete_handler,也就是说gen_event进程的回调模块不是固定的,可以在运行中动态的增加删除,所以挂载到supervisor下的时候,子规格不能填写固定的,只能填dynamic,当然,在升级的时候也是需要动态去获取这个进程的回调模块列表,下面我们来看看代码实现:

get_supervised_procs() ->  %% 查找到应用下所有的sup进程
    lists:foldl(
      fun(Application, Procs) ->
              get_master_procs(Application,
                               Procs,
                               application_controller:get_master(Application))
      end,
      [],
      get_application_names()).
...
get_procs([{Name, Pid, worker, dynamic} | T], Sup) when is_pid(Pid) -> %% Modules=dynamic
    Mods = maybe_get_dynamic_mods(Name, Pid),  %% 动态去获取Modules
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];
get_procs([{Name, Pid, worker, Mods} | T], Sup) when is_pid(Pid), is_list(Mods) -> %% 正常Modules
    [{Sup, Name, Pid, Mods} | get_procs(T, Sup)];
...
maybe_get_dynamic_mods(Name, Pid) ->
    case catch gen:call(Pid, self(), get_modules) of  %% 通过发送消息获取
        {ok, Res} ->
            Res;
        Other ->
            error_logger:error_msg("release_handler: ~p~nerror during a"
                                   " get_modules call to ~p (~w),"
                                   " there may be an error in it's"
                                   " childspec. Exiting ...~n",
                                   [Other, Name, Pid]),
            error(get_modules_failed)
    end.

可以看到上面的代码,当设定为dynamic时,会去发送一个get_modules消息给进程去获取模块列表,我们来看看gen_event代码,应该会有相应接受处理的地方:

{_From, Tag, get_modules} ->
	reply(Tag, get_modules(MSL)),
	loop(Parent, ServerName, MSL, Debug, false);
...
%% Message from the release_handler.
%% The list of modules got to be a set, i.e. no duplicate elements!
get_modules(MSL) ->
    Mods = [Handler#handler.module || Handler <- MSL],
    ordsets:to_list(ordsets:from_list(Mods)).

可以看到gen_event实现了这个方法,并返回了需要的模块列表;所以大家下次如果在supervisor用到gen_event或者类似的会变更回调模块的进程的时候,记得要填dynamic,不然你的代码更新会失败的.

通过本章我们了解到:

进程必须在应用的进程树的管理下才能在模块代码被更新的时候执行状态变更回调.
如果回调模块是动态的,也需要sup的子规格里指定为dynamic.
从这一章中我们了解到,同步指令最后会被转换成调用sys模块的对应执行方法,下一章节我们会从源码的角度看一下sys模块的执行流程.

Erlang-发布版本升级-5-supervisor更新说明

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

supervisor在我们热更中起到至关重要,而且设计到的内容比较多,需要注意的事项也很多,所以这里特别开了一个章节来说.

指令区别

上一章我们说道同步热更指令有两种:

1 2	{update, Module, {advanced, Extra}} %% gen_server类指令 {update, Module, supervisor} %% supervisor专用指令

同样是更新进程内部状态,但是为什么要分开两个指令来区分呢?

单从这里,看不出区别来,因此我决定去看看源码实现:

之前我们知道普通指令会在relup阶段转成底层指令然后放入relup文件,然后我找到了这一段,位置在systools_rc:expand_script/1

{update, Mod, Change} when is_tuple(Change) -> %% gen_server的指令
    {update, Mod, Change, brutal_purge, brutal_purge, []};
{update, Mod, supervisor} -> %% supervisor的指令
    {update, Mod, static, default, {advanced,[]}, brutal_purge, brutal_purge, []};

我们发现{update, Mod, Change}被转成了:

1	{update, Mod, Change, brutal_purge, brutal_purge, []};

继续跟踪,上面这条指令在内部还会转换一次,最后是:

1	{update, Mod, dynamic, default, Change, brutal_purge, brutal_purge, []};

而我们的{update, Mod, supervisor}被转成了:

1	{update, Mod, static, default, {advanced,[]}, brutal_purge, brutal_purge, []};

可以看到第三个字段明显不同gen_server的指令的是dynamic, 而supervisor的指令是static:

1 2	{update, Mod, dynamic, default, Change, brutal_purge, brutal_purge, []}; {update, Mod, static, default, {advanced,[]}, brutal_purge, brutal_purge, []};

我们再结合文档来看看:

High-Level Instructions

{update, Mod}
{update, Mod, supervisor}
{update, Mod, Change}
{update, Mod, DepMods}
{update, Mod, Change, DepMods}
{update, Mod, Change, PrePurge, PostPurge, DepMods}
{update, Mod, Timeout, Change, PrePurge, PostPurge, DepMods}
{update, Mod, ModType, Timeout, Change, PrePurge, PostPurge, DepMods}
  Mod = atom()
  ModType = static | dynamic
  Timeout = int()>0 | default | infinity
  Change = soft | {advanced,Extra}
    Extra = term()
  PrePurge = PostPurge = soft_purge | brutal_purge
  DepMods = [Mod]

第三个字段的定义为ModType,继续看文档关于ModType的定义解析:

Defaults to dynamic. It specifies if the code is “dynamic”, that is, if a process using the module spontaneously switches to new code, or if it is “static”. When doing an advanced update and upgrade, the new version of a dynamic module is loaded before the process is asked to change code. When downgrading, the process is asked to change code before loading the new version. For static modules, the new version is loaded before the process is asked to change code, both in the case of upgrading and downgrading. Callback modules are dynamic.
默认指定的是dynamic,当进行升级的时候,新版本模块会在执行change code前加载;当进行降级的时候,会先执行change code之后在加载新版本模块
而如果指定static,则升级和降级的时候都是先加载新版本模块再执行change code操作

这里说的是,更新的顺序不同,

指定dynamic的时候:

升级的时候,系统先加载模块代码,然后再执行回调方法change code,让进程更新状态
降级的时候,系统会先执行回调方法change code,然后再加载模块代码,让进程更新状态
指定static的时候:

升级和降级都同样是先加载模块代码,然后再执行回调方法change code,让进程更新状态.

为什么otp要这么设定呢?从这方面我们还是看不出来,接下来我们看看supervisor的更新过程:

supervisor的更新过程

有看过supervisor的源码的同学可能很少会注意到,其实supervisor的behaviour是gen_server:

-module(supervisor).
-behaviour(gen_server).
%% External exports
-export([start_link/2, start_link/3,
	 start_child/2, restart_child/2,
	 delete_child/2, terminate_child/2,
	 which_children/1, count_children/1,
	 check_childspecs/1, get_childspec/2]).
%% Internal exports
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
	 terminate/2, code_change/3, format_status/2]).
-export([try_again_restart/2]).

因此supervisor同样也实现了code_change回调:

code_change(_, State, _) ->
    case (State#state.module):init(State#state.args) of
	{ok, {SupFlags, StartSpec}} ->
	    case set_flags(SupFlags, State) of
		{ok, State1}  ->
                    update_childspec(State1, StartSpec);
		{invalid_type, SupFlags} ->
		    {error, {bad_flags, SupFlags}}; % backwards compatibility
		Error ->
		    {error, Error}
	    end;
	ignore ->
	    {ok, State};
	Error ->
	    Error
    end.

发现当supervisor进程执行code_change回调方法只是简单的执行回调方法Mod:init/1,原来这个init/1并不仅仅是supervisor进程启动的时候才会调用,还会在更新的时候调用.

结合之前的文档我们得到如下的结论:

我们都知道,sup模块的init/1返回的是supervisor的规格定义,而sup模块更新最主要的是更新supervisor内部的state,所以升级的时候必须要先加载新的模块代码,然后才能获得新的规格定义;相反降级的时候必要要先加载旧的代码,然后才能获得旧的规格定义.

解决了一个问题之后,我们也得到了一个更新supervisor进程的注意事项:

sup模块的 init/1 并不仅仅是supervisor进程启动的时候才会调用,还会在更新的时候调用,因此不要在init/1里面执行时间比较长的操作,也不要在里面做一些影响系统状态的操作,只要返回sup的规格定义就行了.

除了这个注意事项,还有其它的~

注意事项

更新sup模块的规格定义并不会影响到现有的子进程.
新增的子规格会被加到进去sup的state但是不会自动启动.
删除的子规格不会被删除,也不会自动关闭.

如果要实现上述两个功能的,须手动增建apply指令.如下:

%% 假定我们要新增一个m1模块到ch_sup:
{"2",
 [{"1",
   [{update, ch_sup, supervisor},
    {apply, {supervisor, restart_child, [ch_sup, m1]}}
   ]}],
 [{"1",
   [{apply, {supervisor, terminate_child, [ch_sup, m1]}},
    {apply, {supervisor, delete_child, [ch_sup, m1]}},
    {update, ch_sup, supervisor}
   ]}]
}.

我们可以看到上面的列子,指令之间的顺序很重要.

如果在版本1升级到2时,在{update, ch_sup, supervisor}先执行{apply, {supervisor, restart_child, [ch_sup, m1]}}是不会成功的,
因为此时ch_sup里并没有m1这个模块的规格定义;
同理,在降级的时候,如果{apply, {supervisor, terminate_child, [ch_sup, m1]}},
{apply, {supervisor, delete_child, [ch_sup, m1]}}在{update, ch_sup, supervisor}后面,也不会成功,
因为ch_sup还原之后就没有了m1这个模块的规格定义了.

其实用之前我们说的appup插件的话,并不需要手动操作上面这一步,插件会在生成阶段动态的去调用前后两个版本sup的init方法,然后通过比对规格定义得到这些指令.
此外,执行apply指令的时候,我们的ch_sup进程的必须有注册名,我们知道pid是动态的,也不能在appup文件里面知道ch_sup的pid,因此必须有注册名,才能查找到ch_sup这个进程.

很多同学可能会有一个疑问,我们到底是升级代码还是升级进程?可能有时候会两个概念混淆了,所以下一章,我们会来看看:升级模块与进程.

Erlang-发布版本升级-4-升级指令讲解

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

插件虽然能帮助我们很方便的生成appup文件,但是如果你想要在升级的时候执行一下你的升级mnesia的record数据结构方法,插件不能分析出来我们要做这个的.

所以插件只能帮我们做其中一部分工作而已,另外一部分需要我们自己去处理,因此我们也需要对appup里面的指令进行进一步的学习.

预备知识

先来看看官方对于appup文件的描述:

The application upgrade file defines how an application is upgraded or downgraded in a running system.
This file is used by the functions in systools when generating a release upgrade file relup.
.appup文件是定义运行中的系统的应用怎么升级和降级,文件后期会被转成.relup 文件

之前我们也看过appup文件的内容了,大概是长这个样子:

%% appup generated for rus_rel by rebar3_appup_plugin (2017/09/18 14:46:53)
{ "0.2.0",
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }],
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }]
}.

现在再来看看它的格式定义:

1
2
3

{Vsn,
  [{UpFromVsn, Instructions}, ...],
  [{DownToVsn, Instructions}, ...]}.

Vsn = string()
Current application version.
UpFromVsn = string() | binary()
An earlier application version to upgrade from. If it is a string, it is interpreted as a specific version number. If it is a binary, it is interpreted as a regular expression that can match multiple version numbers.
DownToVsn = string() | binary()
An earlier application version to downgrade to. If it is a string, it is interpreted as a specific version number. If it is a binary, it is interpreted as a regular expression that can match multiple version numbers.
Instructions
A list of release upgrade instructions, see Release Upgrade Instructions. It is recommended to use high-level instructions only. These are automatically translated to low-level instructions by systools when creating the relup file.

{Vsn, %% Vsn 表示的是新版本
  [{UpFromVsn, Instructions}, ...], %% 第二个属性表示升级
  [{DownToVsn, Instructions}, ...]  %% 第三个表示降级
}.

UpFromVsn 表示从 UpFromVsn 这个版本升级到 Vsn 需要做的指令(Instructions), 可以看到这是一个列表,表示可以支持多个版本

DownToVsn 表示从 Vsn 这个版本降级到 DownToVsn 需要做的指令(Instructions), 可以看到这也是一个列表,表示可以支持多个版本

下面我们来看一下例子:

{"2.0.0",
 [{"1.0.0", [{load_module, m}]}], %% 版本"1.0.0"升级到版本"2.0.0", 加载模块m
 [{"1.0.0", [{load_module, m}]}] %% 版本"2.0.0"降级到版本"1.0.0", 加载模块m
}.

从文档中可以看到如果UpFromVsn或者DownToVsn的值是binary类型的话,表示可以用正则表达式去匹配版本,可以为多个版本:

{"2.0.0",
 [{<<"1\\.[0-9]+\\.[0-9]+">>, [{load_module, m}]}],  %% 所有版本"1.*.*"升级到版本"2.0.0", 加载模块m
 [{<<"1\\.[0-9]+\\.[0-9]+">>, [{load_module, m}]}]   %% 版本"2.0.0"降级到所有版本"1.*.*", 加载模块m
}.

另外比较重要的一点是, 官方文档提到:

It is thus recommended that code is changed in as small steps as possible, and always kept backwards compatible. 官方推荐每次更新版本尽可能使用每个小改动版本,用多个版本迭代更新来进行,并且保持向后兼容,利于版本回退.

下面回到正题,来说说指令(Instructions)

指令(Instructions)

OTP supports a set of release handling instructions that are used when creating .appup files. The release handler understands a subset of these, the low-levelinstructions. To make it easier for the user, there are also a number of high-levelinstructions, which are translated to low-level instructions by systools:make_relup.
Some of the most frequently used instructions are described in this section. The complete list of instructions is included in the appup(4) manual page in SASL.

指令分为两种,普通(High-Level)指令和底层(Low-Level)指令的区别: 普通指令是提供给用户使用的,而底层指令是通过普通指令转换而来的.

我们之前生产的*.appup文件, 会在版本发布前的relup阶段,通过调用ystools:make_relup将全部普通指令转换为底层指令.

这个章节我们只是介绍了一些比较常用到的指令,另外还有很多指令大家可以去这个连接获取更加详细的文档.

简单代码热更指令:

1	{load_module, Module}

这个指令的作用就跟我们之前在eshell里面执行l(Module).一样

同步代码热更指令:

1 2	{update, Module, {advanced, Extra}} {update, Module, supervisor}

可以看到这里有两个:第一个是更新进程内部状态的,而第二个是专门提供给supervisor跟新sup进程内部状态的;之后我会说一下他们的区别.

应用(application)指令:
{add_application, app} - 增加app应用-根据relup自动生成
{remove_application, app} - 删除app应用-根据relup自动生成
{restart_application, app} - 重启app应用
启动关闭进程指令:

1 2	{start, [Mod]} %% 启动 Mod = atom()

内部通过执行方法supervisor:restart_child/2,启动所有使用Mod的进程.

1 2	{stop, [Mod]} Mod = atom()

内部通过执行方法supervisor:terminate_child/2,关闭所有使用Mod的进程.

执行指令:

1
2
3

{apply, {M, F, A}}
  M = F = atom()
  A = [term()]

内部实现就是apply(M, F, A).

更新配置:

这个并不需要指令,但是我们的配置发生变化了怎么办呢?

文档告诉我们:

Module is the application callback module as defined by the mod key in the .appfile.
Changed and New are lists of {Par,Val} for all changed and added configuration parameters, respectively.
Removed is a list of all parameters Par that have been removed.
%% 只要在应用回调模块实现config_change/3方法,在更新的时候,otp就会回调这个方法
Module:config_change(Changed, New, Removed).
%% Changed-有修改的配置和 New-新增的配置都是键值对列表[{Par,Val},…]
%% Removed-删除的配置是所有键的列表[Par,…]
非erlang代码的更新:

官方并没有支持,但是给了一个解决方案,就是在erlang的code_change方法里先关闭旧的port然后再开启新的port.

这一章简单的介绍了一下各个指令的说明,看过官方文档的同学可能知道,supervisor进程更新方面官方文档上有很长的一段描述,所以我特此新开了一章关于supervisor进程的更新说明.

Erlang-发布版本升级-3-升级发布版本工具讲解

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

为了不加班,所以程序员一般都会开发一些便捷的工具来提高开发效率,下面就让我来给大家讲讲升级发布版本工具:rebar3_appup_plugin

发布

看前缀就知道,这是一个rebar3的插件,如果对rebar3不熟悉的请先移步去官网看看文档.

那我们先来创建一个rebar3的项目:

1	rebar3 new release rus_rel && cd rus_rel

接下来,当然是添加这个插件到rebar.confg里面:

{erl_opts, [debug_info]}.
{plugins, [
    rebar3_appup_plugin
]}.
{deps, []}.
{relx, [
    {release, { rus_rel, "0.1.0" }, [rus_rel,sasl]},
    {sys_config, "./config/sys.config"},
    {vm_args, "./config/vm.args"},
    {dev_mode, false},
    {include_erts, false},
    {extended_start_script, true}
]}.

记得relx的配置dev_mode要修改为false(此处是演示,正式设置的时候当然是设置profiles里面的设置)

我们需要增加一个gen_server模块

rus_gen_server.erl :

-module(rus_gen_server).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
    terminate/2, code_change/3]).
-export([
    start_link/0
]).
-record(state, {}).
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
init([]) ->
    {ok, #state{}}.
handle_cast(_Info, State) ->
    {noreply, State}.
handle_call(_Info, _From, State) ->
    {reply, ok, State}.
handle_info(_Info, State) ->
    {noreply, State}.
terminate(_Reason, State) ->
    {ok, State}.
code_change(OldVsn, State, Extra) ->
    io:format("~p ~p ~p~n", [OldVsn, State, Extra]),
    {ok, State}.

然后我们在sup里面增加这个模块作为子进程,之后我们会在第二版修改这个进程的内部状态

rus_rel_sup.erl :

-module(rus_rel_sup).
-behaviour(supervisor).
%% API
-export([start_link/0]).
%% Supervisor callbacks
-export([init/1]).
-define(SERVER, ?MODULE).
%%====================================================================
%% API functions
%%====================================================================
start_link() ->
    supervisor:start_link({local, ?SERVER}, ?MODULE, []).
%%====================================================================
%% Supervisor callbacks
%%====================================================================
%% Child :: {Id,StartFunc,Restart,Shutdown,Type,Modules}
init([]) ->
    Children = [
        {rus_gen_server, {rus_gen_server, start_link, []}, permanent, 5000, worker, [rus_gen_server]}
    ],
    {ok, { {one_for_all, 0, 1}, Children} }.

然后我们来发布一个版本:

1	rebar3 release tar

就这么简单,我们0.1.0的版本就发布好了,接下来运行起来:

$ tar zxf rus_rel-0.1.0.tar.gz // 解压
$ ./bin/rus start // 运行
$ ./bin/rus_rel versions
Installed versions:
* 0.1.0	permanent

ok, 准备工作完成

发布版本升级

接下来我们修改gen_server模块state的数据结构,增加一个字段id

-module(rus_gen_server).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
    terminate/2, code_change/3]).
-export([
    start_link/0
]).
-record(state, {id}).
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
init([]) ->
    {ok, #state{}}.
handle_cast(_Info, State) ->
    {noreply, State}.
handle_call(_Info, _From, State) ->
    {reply, ok, State}.
handle_info(_Info, State) ->
    {noreply, State}.
terminate(_Reason, State) ->
    {ok, State}.
code_change(OldVsn, {state}, Extra) ->
    io:format("~p ~p ~p~n", [OldVsn, State, Extra]),
    {ok, #state{id = 1}}.

然后别忘记了修改版本号

rus_rel.app.src修改vsn为0.2.0

1	rebar.config的{ rus_rel, “0.1.0” }修改为{ rus_rel, “0.2.0” }

然后先发布一下:

rebar3 release
之后再运行插件:

1	rebar3 appup generate

这个插件需要之前的版本也在本地目录下面,因为它的运行机制是通过对比两个rel文件夹的beam, 然后根据各自不同自动生成.appup 文件:

%% appup generated for rus_rel by rebar3_appup_plugin (2017/09/18 14:46:53)
{ "0.2.0",
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }],
    [{ "0.1.0",
        [{update,rus_gen_server,{advanced,[]},brutal_purge,brutal_purge,[]}] }]
}.

然后我们再执行relup 和打包:

1	rebar3 relup tar

这样我们就获得了一个带有更新指令的发布,然后将这个发布包发到运行根目录下的releases文件夹下面, 并执行更新命令:

$ ./bin/rus_rel upgrade 0.2.0
Release 0.2.0 not found, attempting to unpack releases/rus_rel-0.2.0.tar.gz
Unpacked successfully: "0.2.0"
Installed Release: 0.2.0
Made release permanent: "0.2.0"
$ ./bin/rus_rel versions
Installed versions:
* 0.2.0	permanent
* 0.1.0	old

ok,整个更新就完成了,你可以attach进去看一下进程的内部状态,发现已经更新了.

appup插件说明

支持功能:

原理:通过对比两个rel文件夹的beam, 然后根据各自不同自动生成.appup 文件.
支持.appup.src 生成.appup 文件.
当gen_server 存在了-state_record(state),插件会自动注入state变更代码到beam里, More info.
支持根据两个版本sup模块init的返回的规格定义不同,生成相应的升级指令
自动生成模块之间的依赖关系.
使用注意事项:

两个版本必须编译参数里必须都有debug_info ,因为插件需要debug_info 的信息, 担心源码安全的话, 可以通过在项目下增加.erlang.crypt 文件来保护源码.
如果需要手动修改.appup 文件, 则需要编写.appup.src , 但是.appup.src 生成.appup 文件后,插件不会再生成.appup文件,因此建议先用rebar3 appup generate 出 .appup文件,然后再以这个文件的基础去修改,然后作为.appup.src.

Erlang-发布版本升级-2-gen-server热更

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

Otp的gen_server模块,我想应该是大家在erlang开发中接触最多的模块了,但是我们经常会碰到要修改内部状态(state)的时候,例如原来的state不再适用于新的需求,需要改变state的数据结构,增加或者减少一个字段

遇到这样情况之后,我想很大一部分同学都会选择关闭这个进程,然后加载新代码,然后再开启这个进程,但是面对运行中的环境,要做这个操作只能重启vm了

其实我们并不需要重启vm,只需要多动动手指敲多几行代码就能完成这个代码的热更了

sys模块的api

首先先带大家认识一下这个sys模块的api:

sys:get_state(Name) -> State. 获取进程的state
sys:suspend(Name) -> ok. 暂停进程
sys:change_code(Name, Module, OldVsn, Extra) -> ok | {error, Reason}. 更新代码之后告诉进程进行内部状态变更
sys:resume(Name) -> ok. 恢复进程

之后会用到这些api,接下来,我会演示一下怎么用这些api去更新一个进程的内部状态:

实例演示
sync_code_reload.erl (vsn-1):

-module(sync_code_reload).
-behaviour(gen_server).
-export([start/0, vsn/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
    terminate/2, code_change/3]).
-record(state, {}).
start() ->
    gen_server:start(?MODULE, [], []).
vsn() -> 1.
init([]) ->
    {ok, #state{}}.
handle_call(_Request, _From, State) ->
    {reply, ok, State}.
handle_cast(_Request, State) ->
    {noreply, State}.
handle_info(_Info, State) ->
    {noreply, State}.
terminate(_Reason, _State) ->
    ok.
code_change(_OldVsn, {state}, _Extra) ->
    io:format("old:~p, ex:~p~n", [_OldVsn, _Extra]),
    {ok, #state{}}.

这份代码很简单,什么东西都没有处理,这就是第一个版本

先启动进程:

1	1> {ok, P} = sync_code_reload:start().

进程启动完成,之后万恶的的策划给我们加了一个需求,需要增加一个字段id来识别这个进程,而且更新这个还不能重启vm,不然他们就有借口拿我们程序员祭天了,但是这难不倒我们,对模块进行简单修改之后:

sync_code_reload.erl (vsn-2):

-module(sync_code_reload).
-behaviour(gen_server).
-export([start/0, vsn/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, 
    terminate/2, code_change/3]).
-record(state, {a}).
start() ->
    gen_server:start(?MODULE, [], []).
vsn() -> 2. %% 1 => 2
init([]) ->
    {ok, #state{}}.
handle_call(_Request, _From, State) ->
    {reply, ok, State}.
handle_cast(_Request, State) ->
    {noreply, State}.
handle_info(_Info, State) ->
    {noreply, State}.
terminate(_Reason, _State) ->
    ok.
code_change(_OldVsn, {state}, _Extra) ->
    io:format("old:~p, ex:~p~n", [_OldVsn, _Extra]),
    {ok, #state{id = 1}}. %% 增加 id = 1

我们先来看看这个进程的内部状态,还记得之前说的api吧,现在排上用场了:

1 2	2> sys:get_state(P). {state}

首先我们需要先暂停这个进程一小会:

1 2	3> sys:suspend(P). ok

然后加载之前编译好的代码:

1 2	4> l(sync_code_reload). {module,sync_code_reload}

下一步,我们通知一下进程进行内部状态的变更:

1
2
3

5> sys:change_code(P, sync_code_reload, "0.1.1", []).  
old:"0.1.1", ex:[]
ok

返回ok表示成功,然后我们再来看看状态:

1 2	6> sys:get_state(P). {state,1}

ok,新的字段已经添加成功了,接下来,我们恢复这个进程的运行:

1 2	7> sys:resume(P). done!

整个流程下来,我想就算你用了机械键盘,速度很快,很666,Duang~Duang~Duang~,但是你还是会被拿去祭天的,因为,整个过程肯定超过10秒,如果是游戏服,这个进程是游戏进程,那么你的玩家用户就整整10秒没有响应,因为你暂停了呀~

其实你可以这样:

1	sys:suspend(P),l(sync_code_reload),sys:change_code(P, sync_code_reload, "0.1.1", []),sys:resume(P).

将操作连在一起操作,肯定不会超过0.1秒,除非你在你的回调方法code_change里执行了timer:sleep(999999).这样做的话,上天也救不了你~

友情提示:
不想被拉去祭天,就别在code_change里面执行耗时的操作!!!
不想被拉去祭天,就别在code_change里面执行耗时的操作!!!
不想被拉去祭天,就别在code_change里面执行耗时的操作!!!

说三遍~你懂得!

另外如果我们有很多个进程,很多个模块需要做进程内部状态的热更呢?

难道每一个进程都做一次上面的操作吗?显然是不可能的~

之后的章节我们会来讲讲怎么用otp的方式来更新一个发布版本!!

Erlang-发布版本升级-1-代码热更

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 Erlang-Release-Upgrade | 评论数：

代码热更

下面我们会展示两份代码,分别是版本1和版本2

test_load.erl (vsn-1):

-module(test_load).
-export([print/0]).
print() ->
    io:format("vsn~p~n", [1]).
test_load.erl (vsn-2):

-module(test_load).
-export([print/0]).
print() ->
    io:format("vsn~p~n", [2]).

两份代码仅有的差别只是打印的版本号不同,下面我们来看看怎么让运行中版本1代码热更到版本2的代码

erlc test_load.erl %% 先编译代码
erl %% 打开eshell
1> test_load:print(). // vsn=1
vsn1
ok
2> l(test_load). // 先在外部执行erlc test_load.erl编译代码 然后再 加载新代码
{ok,test_load}
3> test_load:print(). // vsn=2
vsn2
ok

可以看到,只用通过执行 l(test_load). 就能直接加载新的代码了,很简单对吧,我相信这个知识点大家都懂,因为很多同学在线上紧急修复代码就是这么干的,但是这样做却很容易出问题,而且有很多很多局限性,在以后的章节我们会一起探讨这些问题,现在继续来看看代码版本方面的知识

代码版本

先问大家一个简单问题: 在erlang的vm里面,代码模块能同时存在几个版本?

答案是两个!下面我用实例来演示一遍:

code_replace.erl (vsn-1):

-module(code_replace).
-export([start/0, loop/0]).
start() ->
    spawn(fun loop/0).
loop() ->
    receive
        _ -> loop()
    after 1500 ->
        io:format("vsn~p~n", [1]),
        loop()
    end.

当前我们有一份代码,这个代码主要工作就是开启一个进程,然后这个进程每隔1.5秒打印一下版本号,我们先启动一下这个进程:

erlc code_replace.erl && erl
1> Pid = code_replace:start(). %% 开启进程
vsn1
vsn1
vsn1
...

可以看到我们的进程运行良好,但是突然我开始讨厌打印1了,我想让它打印2

code_replace.erl (vsn-2):

-module(code_replace).
-export([start/0, loop/0]).
start() ->
    spawn(fun loop/0).
loop() ->
    receive
        _ -> loop()
    after 1500 ->
        io:format("vsn~p~n", [2]),  %% 修改 1 => 2
        loop()
    end.

先编译:

erlc code_replace.erl

然后加载到vm里:

2> l(code_replace).
vsn1
vsn1
vsn1
...

虽然我们加载了新代码,但是我们却看到之前我们开启的进程打印的仍然是1,难道是加载代码失败了吗?我们来再开一个进程看看:

3> P2 = code_replace:start().
vsn2
vsn1
vsn2	
vsn1
...

可以看到,代码加载是有效的,而我们之前的进程运行的仍然是旧版本的代码,而新的进程运行的是新版本的代码

我是个多变的人~ >_ > 突然又不喜欢打印2了,我想让它打印3:

code_replace.erl (vsn-3):

-module(code_replace).
-export([start/0, loop/0]).
start() ->
    spawn(fun loop/0).
loop() ->
    receive
        _ -> loop()
    after 1500 ->
        io:format("vsn~p~n", [3]),  %% 修改 2 => 3
        loop()
    end.

然后加载到vm里:

erlc code_replace.erl
4> l(code_replace).
vsn2
vsn2
vsn2
...

奇怪的事情发生了

原来是vsn1和vsn2都会打印出来,但是加载新版本代码之后,vsn1的打印消失了,我们来看看他是不是被kill了

1	5> erlang:is_process_alive(P). %% false

可以看到我们的第一个进程P已经壮烈牺牲了

接下来,问题就来了,为啥第一个进程死掉了,而第二个进程却还或者呢?

我们去官方文档看看解析:连接

Erlang supports change of code in a running system. Code replacement is done on module level.
The code of a module can exist in two variants in a system: current and old. When a module is loaded into the system for the first time, the code becomes ‘current’. If then a new instance of the module is loaded, the code of the previous instance becomes ‘old’ and the new instance becomes ‘current’.
Both old and current code is valid, and can be evaluated concurrently. Fully qualified function calls always refer to current code. Old code can still be evaluated because of processes lingering in the old code.
If a third instance of the module is loaded, the code server removes (purges) the old code and any processes lingering in it is terminated. Then the third instance becomes ‘current’ and the previously current code becomes ‘old’.
To change from old code to current code, a process must make a fully qualified function call.
众所周知, erlang支持运行时的代码更新,代码更新作用在模块级别.每个代码模块允许存在两个版本在系统中:当前和旧两个版本.当一个模块第一次加载进系统时,这个版本视为当前版本.如果有新的模块加载,之前的版本变为旧的版本,然后新的模块变为当前版本.两个版本都是有效的,可以同时运行.全模块调用总是指向当前版本.旧代码仍然起作用是因为进程仍然在使用着旧代码.如果第三个版本模块加载进系统时,系统会清除旧代码和关闭掉那些仍然在使用旧代码的进程.然后第三个版本会变成当前版本代码,第二个版本会变成旧版本代码.进程必须使用全模块调用才能将旧版本模块代码切换到新版本模块代码.

从这里可以看到我们之前进程做的热更其实是很危险的,万一我们热更的时候,有部分进程的驻留模块用的仍然是旧版本的模块代码,就会造成该进程被杀掉,通常在游戏服里面的表现就是全服玩家集体掉线,因为玩家进程的驻留模块还是旧的呀

那我们怎么来解决这个问题呢?

进程代码版本切换

先来看看这份代码:

code_replace_new.erl (vsn-1):

-module(code_replace_new).
-export([start/0, loop/0]).
start() ->
    spawn(fun loop/0).
loop() ->
    receive
        code_switch ->  %% 处理消息
            ?MODULE:loop()
    after 1500 ->
        io:format("vsn~p~n", [1]),
        loop()
    end.

这份代码在原来的基础上加了接受code_switch消息之后,调用一下?MODULE:loop(),这个就是官方说的全模块调用,执行完这一步之后,进程的驻留模块就会从旧版本变更为新版本,下面我们用实际操作来看一下:

启动的方法还是跟之前一样,这里就不重复了

启动之后,我们将打印变为2,然后编译,然后加载,发现还是打印1

1	io:format("vsn~p~n", [2]), %% 1 => 2

不急,我们还没有给进程发送消息让它变更

3> P ! code_switch.
vsn2
vsn2
...

更新成功!!

这样我们就成功将进程的驻留模块从版本一替换到版本二了,也很好的解决了进程被杀掉的问题,那是不是我们每一个进程都需要写这样一个代码切换的代码呢,那岂不是很麻烦,

其实otp已经帮我们想好了解决方法,就是gen_server,这个在之后的章节再来详细看看

CentOS7下源码包方式安装Erlang

发表于 2018-09-07 | 更新于 2019-04-09 | 分类于 erlang | 评论数：

1.从 Erlang 官网下载源代码

1	$ wget http://erlang.org/download/otp_src_21.0.tar.gz

2.安装依赖

1	$ sudo yum -y install gcc gcc-c++ m4 ncurses-devel openssl-devel perl

3.解压第一步下载的源代码

1	$ tar zxvf otp_src_21.0.tar.gz

4.安装

1 2	$ cd opt_src_21.0 $ ./configure --prefix=/usr/local/erlang --without-javac && make && sudo make install

5.创建链接

1	ln -s /usr/local/erlang/bin/erl /usr/local/bin/erl

6.验证

$ erl