• 关于

    实时过程控制不可用

    的搜索结果

问题

Kubernetes 集群如何部署 Kubernetes 集群

反向一觉 2019-12-01 21:22:42 1596 浏览量 回答数 0

问题

用户指南-用户实例-切换主备实例

李沃晟 2019-12-01 21:38:33 640 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档本小节介绍如何使用数据传输服务快速创建两个 RDS for MySQL 实例之间的实时同步作业,实现 RDS for MySQL 增量数据的实时同步。 支持功能 支持阿里云账号下两个 RDS for MySQL 实例间的实时同步。支持不同阿里云账号下的 RDS for MySQL 实例间的实时同步。暂不支持不同阿里云账号下的 RDS for MySQL 实例间的双向同步,具体支持时间将另行通知。 同步限制数据源 目前实时同步只能支持 RDS for MySQL 实例,暂不支持其他数据源类型。目标实例不支持访问模式为标准模式且只有外网连接地址的 RDS for MySQL 实例。不支持香港可用区 A 的 RDS for MySQL 实例的实时同步。对于 rename table tbl_name to new_tbl_name、create table tbl_name like new_tbl_name、 create…select…from new_tbl_name、alter table tbl_name rename to new_tbl_name,如果 new_tbl_name 不在指定的同步对象中,则不支持对此 DDL 进行复制。 同步架构目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下架构: A->B 即两个实例之间的单向同步。且要求实例 B 中同步的对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 A->B/C/D 即一对多的分发式同步架构,这个架构对目标 RDS for MySQL 实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 B/C/D->A 即多对一的数据汇总架构。对于这种多对一的同步架构,为了保证同步数据一致性,要求每条同步链路同步的对象不相同。 A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 注意:如果需要使用双向同步,需要在购买同步链路时,选择双向同步,并在 数据传输 DTS 控制台 中根据指引进行配置。 如果用户配置同步链路过程中,配置不在上述支持范围内的的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 功能限制 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,会导致同步数据不一致。 例如同步库为A,这个库中存在了两个表 A, B。表 A 上有一个触发器,触发器内容为在 insert 一条数据到表 A 之后,在表 B 中插入一条数据。这种情况下,在同步过程中,如果源实例有表 A 上的 insert 操作,就会导致表 B 在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。表 B 的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 rename table 限制 rename table 操作需要满足限制条件方可正常同步,否则会导致同步数据不一致。例如同步对象只包含表 A,不包含表 B,如果同步过程中源实例执行了 rename A to B 的操作,那么改名后的表 B 的操作不会被同步到目标库。为了解决这个问题,可以选择同步表 A、B 对应的整个数据库。 准备事项在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例 购买 RDS 实例。 配置步骤下面我们详细介绍下创建任意两个 RDS 实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输 DTS 控制台,进入数据同步页面,点击控制台右上角 “创建同步作业” 开始作业配置。 在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源实例所在地域。 目标地域 目标地域为同步链路目标实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买 99 条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称 同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。 同步链路的 RDS 实例 ID 源跟目标 RDS 实例必须为两个不同的实例,选择 RDS 实例 ID 时,下拉菜单中只列出对应阿里云账号下的 RDS for MySQL 实例。 当这些内容配置完成后,可以点击授权白名单并进入下一步。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器 IP 添加到同步 RDS 实例的白名单中。避免因为 RDS 设置了白名单,数据传输服务器连接不上 RDS 导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器 IP 从 RDS 实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标 RDS 实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标 RDS 实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如 create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的 drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 当配置完同步对象后,进入同步初始化配置。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。

2019-12-01 23:09:47 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

详细解答可以参考官方帮助文档本小节介绍如何使用数据传输服务快速创建两个 RDS for MySQL 实例之间的实时同步作业,实现 RDS for MySQL 增量数据的实时同步。 支持功能 支持阿里云账号下两个 RDS for MySQL 实例间的实时同步。支持不同阿里云账号下的 RDS for MySQL 实例间的实时同步。暂不支持不同阿里云账号下的 RDS for MySQL 实例间的双向同步,具体支持时间将另行通知。 同步限制数据源 目前实时同步只能支持 RDS for MySQL 实例,暂不支持其他数据源类型。目标实例不支持访问模式为标准模式且只有外网连接地址的 RDS for MySQL 实例。不支持香港可用区 A 的 RDS for MySQL 实例的实时同步。对于 rename table tbl_name to new_tbl_name、create table tbl_name like new_tbl_name、 create…select…from new_tbl_name、alter table tbl_name rename to new_tbl_name,如果 new_tbl_name 不在指定的同步对象中,则不支持对此 DDL 进行复制。 同步架构目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下架构: A->B 即两个实例之间的单向同步。且要求实例 B 中同步的对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 A->B/C/D 即一对多的分发式同步架构,这个架构对目标 RDS for MySQL 实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则会导致同步链路异常,出现数据不一致的情况。 B/C/D->A 即多对一的数据汇总架构。对于这种多对一的同步架构,为了保证同步数据一致性,要求每条同步链路同步的对象不相同。 A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 注意:如果需要使用双向同步,需要在购买同步链路时,选择双向同步,并在 数据传输 DTS 控制台 中根据指引进行配置。 如果用户配置同步链路过程中,配置不在上述支持范围内的的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 功能限制 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,会导致同步数据不一致。 例如同步库为A,这个库中存在了两个表 A, B。表 A 上有一个触发器,触发器内容为在 insert 一条数据到表 A 之后,在表 B 中插入一条数据。这种情况下,在同步过程中,如果源实例有表 A 上的 insert 操作,就会导致表 B 在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。表 B 的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 rename table 限制 rename table 操作需要满足限制条件方可正常同步,否则会导致同步数据不一致。例如同步对象只包含表 A,不包含表 B,如果同步过程中源实例执行了 rename A to B 的操作,那么改名后的表 B 的操作不会被同步到目标库。为了解决这个问题,可以选择同步表 A、B 对应的整个数据库。 准备事项在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例 购买 RDS 实例。 配置步骤下面我们详细介绍下创建任意两个 RDS 实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输 DTS 控制台,进入数据同步页面,点击控制台右上角 “创建同步作业” 开始作业配置。 在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源实例所在地域。 目标地域 目标地域为同步链路目标实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买 99 条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称 同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。 同步链路的 RDS 实例 ID 源跟目标 RDS 实例必须为两个不同的实例,选择 RDS 实例 ID 时,下拉菜单中只列出对应阿里云账号下的 RDS for MySQL 实例。 当这些内容配置完成后,可以点击授权白名单并进入下一步。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器 IP 添加到同步 RDS 实例的白名单中。避免因为 RDS 设置了白名单,数据传输服务器连接不上 RDS 导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器 IP 从 RDS 实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标 RDS 实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标 RDS 实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如 create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的 drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 当配置完同步对象后,进入同步初始化配置。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。

2019-12-01 23:09:47 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档数据传输DTS提供的数据实时同步功能,简单易用。只需3个步骤,即可完成整个同步链路的配置。本小节介绍如何使用数据传输服务快速创建两个RDS(MySQL)实例之间的实时同步作业,实现RDS增量数据的实时同步。 同步限制 数据源 目前实时同步只能支持RDS MySQL实例,暂不支持其他数据源类型目标实例不支持访问模式为标准模式且只有外网连接地址的RDS实例不支持香港可用区A的RDS实例的实时同步 同步架构 目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下三种架构: A->B 即两个实例之间的单向同步。且要求B中同步的对象必须为只读,否则可能导致同步链路异常。 A->B/C/D 即1对多的分发式同步架构,这个架构对目标RDS实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则可能导致同步链路异常。 B/C/D->A 即多对1的数据汇总架构。对于多对1的同步架构,要求每个同步链路的同步对象不相同,保证同步完整性。 对于下面几种同步架构,暂时不支持: A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 如果用户配置同步链路过程中,配置了这些不支持的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,那么可能导致同步数据不一致。 触发器内容为在insert一条数据到a之后,在b中插入一条数据。这种情况下,在同步过程中,如果源实例有a上的insert操作,就会导致b表在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。b表的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 前提条件在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例购买RDS实例。 操作步骤下面我们详细介绍下创建任意两个RDS实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输服务控制台,进入数据同步页面。点击控制台右上角“创建同步作业” 开始作业配置。在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源RDS实例所在地域。 目标地域 目标地域为同步链路目标RDS实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买99条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。同步链路的RDS实例ID源跟目标RDS实例必须为两个不同的实例,选择RDS实例ID时,下拉菜单中只列出对应阿里云账号下的RDS For MySQL实例。 当这些内容配置完成后,可以点击“授权白名单并进入下一步”。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器IP添加到同步RDS实例的白名单中。避免因为RDS设置了白名单,数据传输服务器连接不上RDS导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器IP从RDS实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标RDS实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标RDS实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 需要注意的是rename table操作可能导致同步数据不一致。例如同步对象只包含表A,不包含表B,如果同步过程中源实例执行了rename A to B的操作,那么改名后的B表的操作不会被同步到目标库。为了解决这个问题,可以选择同步表A、B对应的整个数据库。 当选择完同步对象后,即进入同步初始化选择。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。

2019-12-01 23:09:39 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档数据传输DTS提供的数据实时同步功能,简单易用。只需3个步骤,即可完成整个同步链路的配置。本小节介绍如何使用数据传输服务快速创建两个RDS(MySQL)实例之间的实时同步作业,实现RDS增量数据的实时同步。 同步限制 数据源 目前实时同步只能支持RDS MySQL实例,暂不支持其他数据源类型目标实例不支持访问模式为标准模式且只有外网连接地址的RDS实例不支持香港可用区A的RDS实例的实时同步 同步架构 目前数据传输服务提供的实时同步功能支持的同步架构有限,其仅能支持如下三种架构: A->B 即两个实例之间的单向同步。且要求B中同步的对象必须为只读,否则可能导致同步链路异常。 A->B/C/D 即1对多的分发式同步架构,这个架构对目标RDS实例个数没有限制,但是要求目标实例中的同步对象必须为只读,否则可能导致同步链路异常。 B/C/D->A 即多对1的数据汇总架构。对于多对1的同步架构,要求每个同步链路的同步对象不相同,保证同步完整性。 对于下面几种同步架构,暂时不支持: A->B->C 即级联架构。 A->B->A 即实例A和实例B之间的双向同步架构。 如果用户配置同步链路过程中,配置了这些不支持的同步架构,那么预检查中的复杂拓扑检查项会检查失败。 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,那么可能导致同步数据不一致。 触发器内容为在insert一条数据到a之后,在b中插入一条数据。这种情况下,在同步过程中,如果源实例有a上的insert操作,就会导致b表在源实例跟目标实例数据不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。b表的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 前提条件在配置同步作业前,要确保同步作业的源及目标RDS实例都已经存在。如果不存在,那么请先购买RDS实例购买RDS实例。 操作步骤下面我们详细介绍下创建任意两个RDS实例之间的同步链路的具体步骤。 购买同步链路。 进入数据传输服务控制台,进入数据同步页面。点击控制台右上角“创建同步作业” 开始作业配置。在链路配置之前需要购买一个同步链路。同步链路目前支持包年包月及按量付费两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源地域 源地域为同步链路源RDS实例所在地域。 目标地域 目标地域为同步链路目标RDS实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买99条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 同步链路连接信息配置。 在这一步主要配置: 同步作业名称同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。同步链路的RDS实例ID源跟目标RDS实例必须为两个不同的实例,选择RDS实例ID时,下拉菜单中只列出对应阿里云账号下的RDS For MySQL实例。 当这些内容配置完成后,可以点击“授权白名单并进入下一步”。 授权RDS实例白名单。 这个步骤,主要是将数据传输服务器IP添加到同步RDS实例的白名单中。避免因为RDS设置了白名单,数据传输服务器连接不上RDS导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将这些服务器IP从RDS实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 创建目标库上的同步账号。 这个步骤主要是在目标RDS实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,不能删除这个账号,否则会导致同步链路中断。 选择同步对象。 当创建完目标RDS实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 需要注意的是rename table操作可能导致同步数据不一致。例如同步对象只包含表A,不包含表B,如果同步过程中源实例执行了rename A to B的操作,那么改名后的B表的操作不会被同步到目标库。为了解决这个问题,可以选择同步表A、B对应的整个数据库。 当选择完同步对象后,即进入同步初始化选择。 同步初始化配置。 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 预检查。 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。

2019-12-01 23:09:39 0 浏览量 回答数 0

问题

如何创建实时同步作业

云栖大讲堂 2019-12-01 21:24:14 1043 浏览量 回答数 0

回答

本教程介绍了如何利用弹性伸缩均衡分布ECS实例,并组合使用按量付费ECS实例和抢占式实例,以更低的成本部署高可用计算集群。 前提条件 使用本教程进行操作前,请确保您已经注册了阿里云账号。如还未注册,请先完成账号注册。 为应用的ECS实例创建了自定义镜像,具体操作请参见使用实例创建自定义镜像。 业务场景 某在线广告提供商应用机器学习精准投放广告,在业务高峰期会临时需要大量计算资源,成本较高,也可能存在ECS实例库存不足、手动创建ECS实例操作仓促、ECS实例临时停止服务等问题,存在一定的业务受损风险。 假设您的应用面向以下场景,也可以采用类似解决方案: 分布式大数据计算。 人工智能训练。 解决方案 弹性伸缩可以快速交付一个计算集群,同时利用均衡分布策略自动将计算节点分散在多个可用区,并实时检测ECS实例的运行状况,确保计算集群的高可用性。 您可以采用以下方案: 通过弹性伸缩将计算节点分散在多个可用区,同时指定多种实例规格。 组合使用按量实例和抢占式实例,以低成本购买ECS实例。伸缩组会按照单位vCPU的价格从低到高排序,优先选择单位vCPU价格更低的实例规格。 示意图如下: 业务收益 利用弹性伸缩部署高可用计算集群,您可以获得以下收益: 零运维成本 您只需提前配置扩缩容策略。负载增加时,伸缩组自动创建ECS实例,并将ECS实例添加到RDS实例的白名单;负载降低时,伸缩组自动将ECS实例从RDS实例的白名单中移除,然后释放ECS实例。整个过程自动触发和完成,无需人工干预。 超高性价比 弹性伸缩支持组合使用按量实例和抢占式实例,抢占式实例最低能以一折的价格购得ECS实例,性价比超高。如果抢占式实例库存不足,也会以按量实例的方式交付,保证交付结果。 天然高可用 均衡分布策略实现自动分散部署计算节点,避免因单可用区中库存不足等原因导致服务不可用,而且默认开启的健康检查功能可以确保伸缩组内ECS实例都处于可用状态。 操作步骤 请根据您的业务架构评估业务模块,为需要部署高可用集群的业务模块创建伸缩组,并为伸缩配置选择应用实例的自定义镜像,确保自动创建出的ECS实例符合应用的要求。 登录弹性伸缩控制台。 单击创建伸缩组。 配置伸缩组信息并完成伸缩组创建。 伸缩组内最小实例数设置为100。 组内实例配置信息来源设置为自定义伸缩配置。 选择多个可用区下的虚拟交换机。 多可用区扩容模式设置为均衡分布策略。 绑定当前业务模块所使用的RDS实例。 请根据需要配置其它信息,详细信息请参见创建伸缩组。 单击创建伸缩配置。 配置伸缩配置信息并完成伸缩配置创建。 计费方式设置为抢占式实例。 镜像设置为您的自定义镜像。 请根据需要配置其它信息,详细信息请参见创建伸缩配置。 确定启用伸缩配置。 确定启用伸缩组。 执行结果 启用伸缩组后,伸缩组自动在所选可用区中均衡部署满100台ECS实例,单可用区中因库存不足等原因引发问题时,对整个应用的影响有限。伸缩组在抢占式实例被回收后自动创建新的抢占式实例,并自动移除进入不健康状态的ECS实例并创建新的ECS实例。保证集群高可用性的同时,也降低了成本。

1934890530796658 2020-03-22 13:27:57 0 浏览量 回答数 0

问题

如何创建RDS实例间数据实时同步作业

云栖大讲堂 2019-12-01 21:25:05 1143 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档数据传输 DTS(以下简称 DTS)支持不同阿里云账号下的两个 RDS 实例之间的实时同步。本小节介绍跨阿里云账号 RDS 实例间数据实时同步作业的配置流程。 支持场景 支持不同阿里云账号下的两个 RDS for MySQL 实例间的数据实时同步。支持公共云与金融云账号下的 RDS for MySQL 实例间的数据实时同步。 同步限制数据源 目前实时同步只能支持 RDS for MySQL 实例,暂不支持其他数据源类型。目标实例不支持访问模式为标准模式且只有外网连接地址的 RDS 实例。不支持 香港可用区 A 的 RDS 实例的实时同步。 同步架构目前数据传输服务的实时同步功能支持如下同步架构: A->B 即两个实例之间 一对一 的单向同步。且要求实例 B 中同步的对象必须为只读,否则可能导致同步链路异常。 A->B/C/D 即多个实例之间 1对多 的分发式同步架构,这个架构对目标 RDS 实例的个数没有限制,但是要求目标实例中的同步对象必须为只读,否则可能导致同步链路异常。 B/C/D->A 即多个实例之间 多对1 的数据汇总架构。对于这种 多对1 的同步架构,为了保证同步数据一致性,要求每条同步链路同步的对象不相同。 A->B->C 即级联架构 A->B->A 即实例 A 和实例 B 之间的双向同步架构 功能限制 不兼容触发器 如果同步对象为整个库且这个库中包含了会更新同步表内容的触发器,那么可能导致同步数据不一致。 例如同步的数据库为 A,这个库中存在了两个表 a 和 b。表 a 上有一个触发器,触发器内容为在 insert 一条数据到表 a 之后,会在表 b 中插入一条数据。这种情况下,在同步过程中,如果源实例在表 a 上有 insert 操作,就会导致表 b 的重复插入,使得源实例跟目标实例数据产生不一致。 为了解决这个问题,只能将目标实例中的对应触发器删除掉。表 b 的数据由源实例同步过去。具体解决方案详见最佳实践中的,触发器存在情况下如何配置同步链路。 rename table 限制 rename table 操作可能导致同步数据不一致。例如同步对象只包含表 a,不包含表 b,如果同步过程中源实例执行了 rename a to b 的操作,那么改名后的表 b 的操作不会被同步到目标库。为了解决这个问题,可以选择同步表 a 和 b 对应的整个数据库。 准备事项在配置同步作业前,要确保同步作业的源及目标 RDS 实例都已经存在。如果不存在,那么请先 购买 RDS 实例。 配置步骤下面我们详细介绍下创建同步作业的具体步骤。 1. 购买同步链路 使用目标实例对应的阿里云账号登录 数据传输 DTS 控制台,进入数据同步页面。 点击控制台右上角“创建同步作业” 开始作业配置。 在链路配置之前需要购买一个同步链路。同步链路目前支持 包年包月 及 按量付费 两种付费模式,可以根据需要选择不同的付费模式。 在购买页面需要配置的参数包括: 源实例源实例为同步作业的源实例类型,目前只支持 RDS for MySQL. 源地域 源地域为同步链路源实例所在地域。 目标实例目标实例为同步作业的目标实例类型,目前支持 RDS for MySQL, MaxCompute, DataHub 和 分析型数据库 Analytic DB。如果进行 RDS 实例间的同步,那么选择 RDS for MySQL 即可。 目标地域 目标地域为同步链路目标实例所在地域。 实例规格 实例规格影响了链路的同步性能,实例规格跟性能之间的对应关系详见 数据同步规格说明,请根据需要选择。 网络类型对于 RDS 实例间的数据同步,目前只支持通过私网同步。 数量 数量为一次性购买的同步链路的数量,如果购买的是按量付费实例,一次最多购买 99 条链路。 当购买完同步实例,返回数据传输控制台,点击新购链路右侧的“配置同步作业” 开始链路配置。 2.同步实例连接信息 在这一步主要配置: 同步作业名称 同步作业名称没有唯一性要求,主要为了更方便识别具体的作业,建议选择一个有业务意义的作业名称,方便后续的链路查找及管理。 同步链路的 RDS 实例 ID 由于源实例不属于登录的阿里云账号,所以源实例配置时,点击界面右侧 的 其他阿里云账号下的 RDS 实例,然后配置: RDS 实例所属阿里云账号 为源 RDS 实例所属阿里云账号的账号 ID,在登录后,到账号管理的 安全设置 界面获取。 角色名称为了提升安全性,配置跨账号 RDS 同步任务的用户,需要得到源 RDS 实例所属云账号的授权后,才能对源 RDS 实例进行配置。这里面配置的 角色名称,即为RAM跨账号授权的角色名称。跨账号授权的流程如下:(1) 进入 RAM 控制台 的角色管理界面,点击页面右上角的 新建角色,开始创建跨账号授权角色。(2) 第一步的 选择角色类型,选择用户角色(3) 第二步的 填写类型信息,选择受信云账号,选择 其他云账号,同时,受信云账号 ID 配置最终配置 DTS 同步作业的阿里云账号的账号 ID (4) 第三步,配置角色名称,这个名称就是 DTS 同步作业配置过程中,需要填写的角色名称。角色创建完成后,需要修改角色授权策略,授权 受信云账号 只能在 数据传输 DTS 控制台 访问自己的云资源。具体修改步骤如下:(1) 在角色管理界面,点击 刚创建角色 后面的 管理 按钮,进入角色管理界面。(2) 在角色管理界面,点击右上角的 编辑基本信息,进入角色编辑框,在编辑框中,修改 Principal,添加 service 定义: "Service": [ "受信阿里云账号ID@dts.aliyuncs.com" ] 受信云账号的账号 ID,即最后配置 DTS 同步作业的阿里云账号 ID。dts.aliyuncs.com 为 DTS 服务代号。假设配置 DTS 同步作业的阿里云账号 ID 为:121852226014398,那么 service 定义为: "Service": [ "121852226014398@dts.aliyuncs.com" ] 所以,完整的角色定义如下: {"Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "RAM": [ "acs:ram::1218522260143989:root" ], "Service": [ "1218522260143989@dts.aliyuncs.com" ] } }],"Version": "1"} 当配置完角色受信身份后,需要将配置 DTS 任务需要的相关权限授权给角色后,DTS 才能扮演这个角色完成任务配置及运行。进入 RAM 角色管理 界面,点击刚才刚创建的角色后面的 授权 按钮,进行对 DTS 的系统策略授权。进入角色授权界面后,进入 精确授权 界面,在搜索框中搜索 AliyunDTSRolePolicy ,将这个系统策略授权给角色。 当配置完成后,DTS 控制台中填写的角色名称,即为刚才创建的跨账号角色名称。 RDS 实例 ID 当配置完阿里云账号和角色名称后,即可以选择要同步的源 RDS 实例的实例 ID。 目标 RDS 实例选择要同步的目标 RDS 实例的实例 ID 即可。 当这些内容配置完成后,可以点击“授权白名单并进入下一步”。 3.授权 RDS 实例白名单 这个步骤,主要是将数据传输服务器IP添加到同步 RDS 实例的白名单中。避免因为 RDS 设置了白名单,数据传输服务器连接不上 RDS 实例导致同步作业创建失败。 为了保证同步作业的稳定性,在同步过程中,请勿将白名单中的服务器 IP 从 RDS 实例的白名单中删除。 当白名单授权后,点击下一步,进入同步账号创建。 4.创建目标库上的同步账号 这个步骤主要是在目标 RDS 实例上创建一个同步账号,账号名字为:dtssyncwriter,在同步过程中,请勿删除这个账号,否则会导致同步链路中断。 5.选择同步对象 当创建完目标 RDS 实例的同步账号后,即进入同步对象的选择步骤。实时同步的同步对象的选择粒度可以支持到表级别,即用户可以选择同步某些库或是同步某几张表。 如果选择的同步对象为整个库,那么这个库中所有对象的结构变更操作(例如 create table,drop view 等),都会同步到目标库。 如果选择的某张表,那么只有这个表的 drop/alter/truncate/rename table,create/drop index 的操作会同步到目标库。 当配置完同步对象后,进入同步初始化配置。 6.同步初始化配置 同步初始化配置,初始化是同步链路启动的第一步,它会将源实例中已经存在同步对象的结构及数据在目标实例中初始化,作为后续增量同步数据的基线数据。 同步初始化类型细分为:结构初始化,全量数据初始化。默认情况下,需要选择结构初始化及全量初始化。 7.预检查 当上面所有选项配置完成后,即进入启动之前的预检查。 当同步作业配置完成后,数据传输服务会进行限制预检查,当预检查通过后,可以点击 启动 按钮,启动同步作业。 当同步作业启动之后,即进入同步作业列表。此时刚启动的作业处于同步初始化状态。初始化的时间长度依赖于源实例中同步对象的数据量大小。当初始化完成后同步链路即进入同步中的状态,此时源跟目标实例的同步链路才真正建立完成。

2019-12-01 23:09:47 0 浏览量 回答数 0

回答

PolarDB支持将RDS MySQL一键升级为PolarDB MySQL。 前提条件 源RDS实例版本为RDS MySQL 5.6高可用版。 源RDS实例未开启TDE和SSL。 源RDS实例的表存储引擎为InnoDB。 如果RDS处于高安全模式(数据库代理模式),需要创建有高权限账号(请参见创建高权限账号),或者切换到高性能模式(参见【重要】RDS网络链路升级说明),才能进行一键升级。查看数据库模式 背景信息 PolarDB是阿里云自研的下一代关系型云数据库,主要优势如下: 存储容量高:最高可达100TB。 性能高:最高可以提升至MySQL的6倍。 Serverless存储:存储容量无需提前购买,自动扩缩容,按使用量计费。 临时升配:临时升级规格,轻松应对短期的业务高峰。 详情请参见产品优势。 一键升级功能可以将RDS MySQL一键升级为PolarDB MySQL,升级后PolarDB集群包含源RDS实例的账号、数据库、IP白名单和必要的参数。 一键升级的功能亮点 迁移完全免费。 迁移过程数据0丢失。 支持增量迁移,停机时间小于10分钟。 支持回滚,迁移失败可以在10分钟内恢复。 迁移流程 参见从RDS迁移的说明,创建一个与源RDS实例数据相同的PolarDB集群,源RDS实例的增量数据会实时同步到该PolarDB集群。 说明 需要在7天内修改应用端的数据库地址为PolarDB地址,确认业务正常,以及单击完成迁移。单击完成迁移会中断RDS和PolarDB之间的数据同步。 单击迁移切换。该操作将源RDS实例修改为只读,将PolarDB集群修改为可读可写,PolarDB的增量数据会实时同步到RDS。修改数据库连接地址。具体操作请参见迁移切换。 说明 迁移切换后,也可以选择迁移回滚。 完成迁移。 注意事项 迁移只能在相同地域内进行。 源RDS实例在迁移时不能修改参数。 从RDS迁移 本操作将创建一个与源RDS实例数据相同的PolarDB集群,源RDS实例的增量数据会实时同步到该PolarDB集群。 登录PolarDB控制台。 单击创建新集群。 选择包年包月或按量付费页签。 设置以下参数。 参数 说明 地域 源RDS MySQL实例所在地域。 说明 新建的PolarDB集群也在此地域。 创建方式 选择从RDS迁移。 即从RDS实例克隆一个PolarDB集群,同时保持数据同步。默认开启新集群的Binlog。 源RDS引擎 源RDS实例的引擎类型,不可变更。 源RDS版本 源RDS实例的版本,不可变更。 源RDS实例 可选的源RDS实例,不包括只读实例。 可用区 可用区是地域中的一个独立物理区域,不同可用区之间没有实质性区别。 您可以选择将PolarDB集群与ECS创建在同一可用区或不同的可用区。 网络类型 PolarDB集群的网络类型,不可变更。 VPC网络 VPC交换机 PolarDB集群所属的VPC和虚拟交换机。请确保PolarDB集群与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。 兼容性 PolarDB集群的数据库引擎,不可变更。 节点规格 按需选择,建议不低于源RDS实例规格。所有PolarDB节点均为独享型,性能稳定可靠。详情请参见规格与定价。 节点个数 无需选择。系统将自动创建一个与主节点规格相同的只读节点。 存储费用 无需选择容量,根据实际数据使用量按小时计费。详情请参见规格与定价。 设置购买时长(仅针对包年包月集群),然后单击右侧的立即购买。 确认订单信息,阅读和勾选服务协议,单击去开通,完成支付。 进入PolarDB控制台,查看新建的PolarDB集群的状态。 说明 集群创建后开始从RDS实例同步数据,7 天内需要完成修改数据库连接地址以及完成迁移操作。超过7天将自动关闭迁移功能。 您可以在此步骤选择取消迁移,相关影响请参见迁移常见问题。 迁移切换 满足以下条件后,您可以进行迁移切换,然后修改应用里的数据库连接地址。 已完成从RDS迁移的操作。 复制延迟小于60秒。基本信息 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面单击迁移切换,在弹出的对话框中单击确定。本操作将源RDS实例修改为只读,将PolarDB集群修改为可读可写,同时会将PolarDB集群的新增数据同步到RDS实例。迁移切换 说明 数据同步的延迟超过60秒时无法进行迁移切换。 切换过程一般小于5分钟。 刷新页面,当PolarDB读写状态显示为读写后,尽快修改应用里的数据库连接地址。刷新 说明 迁移切换完成后,也可以选择迁移回滚。 完成迁移 从RDS迁移后,需要在7天内修改数据库连接地址以及单击完成迁移。该操作将中断PolarDB集群和RDS实例间的数据同步。 警告 由于本操作将中断PolarDB集群和RDS实例间的数据同步,不再提供迁移回滚功能,建议您使用一段时间PolarDB集群,确认正常后再执行本操作。 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面,单击完成迁移,在弹出的对话框中单击确定。完成迁移完成迁移确定 说明 单击确定后,系统将在约2分钟内中断同步关系,期间完成迁移按钮不会消失,请勿重复单击。 您可以选择是否关闭PolarDB集群的Binlog。关闭Binlog会带来少量的写入性能提升,但需要重启PolarDB。 如果不再需要源RDS实例,可以释放实例。 迁移回滚 在完成迁移前,如果您发现数据存在异常等问题,可以进行回滚操作,快速恢复至迁移前的状态(RDS实例为可读可写,PolarDB集群为只读,同时会将RDS实例的数据同步到PolarDB集群)。 进入PolarDB控制台。 找到目标集群,单击集群的ID。 在基本信息页面单击迁移回滚,在弹出的对话框中单击确定。迁移回滚 说明 单击确定后RDS实例为可读可写,PolarDB集群为只读,同时会将RDS实例的数据同步到PolarDB集群。当源RDS读写状态显示为读写后,请尽快修改应用里的数据库连接地址为RDS连接地址。 迁移常见问题 从RDS迁移会影响源RDS实例吗? 答:不会影响源RDS实例的正常运行。 平滑迁移对业务有影响吗? 答:平滑迁移能够保证迁移过程不丢失数据,停机时间小于10分钟,如果有需要还可以进行回滚。 取消迁移会有什么影响? 答:取消迁移后,源RDS实例可以修改参数;PolarDB集群恢复可读可写,且数据不会释放。手动取消时可以选择是否关闭PolarDB集群的Binlog,自动取消时不会关闭。

游客yl2rjx5yxwcam 2020-03-08 14:01:57 0 浏览量 回答数 0

问题

表格存储的产品优势有什么

云栖大讲堂 2019-12-01 20:53:54 1342 浏览量 回答数 0

回答

SCC(超级计算集群)简介 SCC概述 超级计算集群(Super Computing Cluster,SCC)使用高速RDMA网络互联的CPU以及GPU等异构加速设备,面向高性能计算、人工智能/机器学习、科学/工程计算、数据分析、音视频处理等应用,提供极致计算性能和并行效率的计算集群服务。 SCC实例类型 类型 CPU Memory 网络 存储 适用场景 ecs.scch5.16xlarge 64核 Skylake Xeon Gold 6149 3.1GHz 192GB 50 Gbps RDMA 高效云盘(容量可选) + SSD云盘(容量可选) CPU主频高,单核计算能力强,适用于多数计算密集型应用场景 ecs.sccg5.24xlarge 96核 Skylake Xeon Platinum 8163 2.5GHz 384GB 50 Gbps RDMA 高效云盘(容量可选) + SSD云盘(容量可选) CPU核数多,内存容量大,适用于内存需求较高、扩展性好的科学计算场景以及高并发的批处理场景 使用SCC实例创建E-HPC集群 创建过程 目前配备有SCC实例的可用区主要有:华东1可用区H、华东2可用区B、华北1可用区C、华北3可用区A。考虑到库存的变化,用户在创建集群之前可以通过ECS管理控制台查看SCC实例在不同可用区的分布情况。 从E-HPC管理控制台进入集群创建页面,在计算节点下划栏中勾选SCC实例。 勾选SCC注意:上图中SCC实例的CPU核数是按照vCPU数目来显示的,而实际交付的SCC实例为超线程关闭(HT off)状态,即scch5.16xlarge和sccg5.24xlarge的CPU核数分别为32物理核和48物理核。 后续创建过程请参考E-HPC集群创建与配置 硬件信息 相比于普通ECS实例,SCC实例的核心硬件升级之一在于配备了50Gbps的RoCE(RDMA over Converged Ethernet)网络,故网络信息与普通ECS实例相比有明显差异。 网络硬件信息 相比于普通ECS实例,SCC实例同时拥有10Gbps VPC网络和50Gbps RoCE网络的网口,因此在会ECS管理控制台上会同时显示两个IP地址。 SCC IP 正常的SCC实例会显示如下网口信息,其中bond0为RoCE网口,eth0为VPC网口。 SCC网口信息 网络连通性验证 同一个E-HPC集群下的SCC实例间的VPC网络IP和RoCE网络IP均可以相互ping通 同一个E-HPC集群下的SCC实例间可以通过VPC网络IP和RoCE网络IP进行ssh登陆 RoCE网络性能测试 测试RoCE网络的峰值带宽与延迟 带宽测试样例 ##读带宽测试 ib_read_bw -a -q 20 --report_gbits ##服务端compute0执行 ib_read_bw -a -q 20 --report_gbits compute0 ##用户端compute1执行 ##写带宽测试 ib_write_bw -a -q 20 --report_gbits ##服务端compute0执行 ib_write_bw -a -q 20 --report_gbits compute0 ##用户端compute1执行 延迟测试样例 ##读延迟测试 ib_read_lat -a ##服务端compute0执行 ib_read_lat -F -a compute0 ##用户端compute1执行 ##写延迟测试 ib_write_lat -a ##服务端compute0执行 ib_write_lat -F -a compute0 ##用户端compute1执行 监测RoCE网络的实际带宽利用情况 在SCC实例root用户下执行rdma_monitor -s实时获取RoCE网络信息 rdma_monitor 使用E-HPC性能监控与分析引擎集谛来监测各SCC实例RoCE网络带宽随时间的变化情况。 集谛监测RoCE 在SCC集群上编译和运行MPI程序 由于SCC实例同时支持50Gbps RoCE网络和10Gbps VPC网络,用户在执行跨节点MPI程序时可能会遇到节点间数据流量默认走VPC网口的情况,这里我们推荐用户在SCC集群上使用IntelMPI来编译和运行跨节点MPI程序。 编译跨节点MPI程序 安装IntelMPI E-HPC集成了IntelMPI 2018版本,用户只需在E-HPC控制台集群创建或软件管理功能界面中勾选IntelMPI 2018进行安装即可。 intelmpi 配置MPI环境变量 方法一:使用E-HPC集成的Module管理工具 $ module avail --------------------------------- /opt/ehpcmodulefiles -------------------------------- intel-mpi/2018 $ module load intel-mpi/2018 $ which mpicc /opt/intel/impi/2018.3.222/bin64/mpicc 方法二:执行IntelMPI自带的环境变量配置脚本 $ source /opt/intel/compilers_and_libraries/linux/bin/compilervars.sh intel64 $ which mpicc /opt/intel/impi/2018.3.222/bin64/mpicc 设置MPI编译参数 完成MPI环境变量配置后,需要在软件Makefile或预编译脚本中指定MPI编译器的相对/绝对路径,然后执行编译过程。 -DCMAKE_C_COMPILER=mpicc -DCMAKE_CXX_COMPILER=mpicxx 运行跨节点MPI程序 对于在E-HPC软件环境中采用IntelMPI编译的软件,提交任务时无需额外指定网口参数,便可以直接通过RoCE网络进行跨节点数据通信。 #!/bin/sh #PBS -j oe #PBS -l select=<节点数>:ncpus=<每节点核数>:mpiprocs=<每个节点进程数> module load intel-mpi/2018 mpirun <软件执行命令> 对于在用户本地环境编译的软件或预编译的商用软件,可以在提交MPI任务时指定RoCE网卡信息来避免可能出现的数据流量不走RoCE网络或网卡设备not found等问题。 #!/bin/sh #PBS -j oe #PBS -l select=<节点数>:ncpus=<每节点核数>:mpiprocs=<每个节点进程数> export I_MPI_FABRICS=shm:dapl module load intel-mpi/2018 mpirun -genv I_MPI_DAPL_PROVIDER ofa-v2-mlx5_bond_0 <软件执行命令> 用户可以使用集谛性能监测功能对SCC实例的CPU利用率、访存带宽、RoCE网络带宽等性能数据进行实时监测。 SCC性能

1934890530796658 2020-03-24 09:49:57 0 浏览量 回答数 0

回答

Logistics Sci—Tech No.10,2008 · 军事物流· 物流科技2008年第1O期 摘 要:现代军事物流是信息化战争后勤保障的重要支 撑。随着信息技术的不断发展, 卫星定位系统逐渐应用于军 事物流领域,成为现代军队战斗力的倍增器。文章介绍了卫 星定位系统概况, 阐述了卫星定位系统在军事物流领域的应 用现状,对军事物流领域应用卫星定位系统的前景及思路进 行了探讨。 关键词:卫星定位系统;军事物流;应用 中图分类号:E075 文献标识码:A 文章编号:1002—3100 f2008) 10—0071—03 Abstract: Modern military logistics is one of the important pans of logistics under informationization war. Nowadays, satellite positioning system is applied in the field of military logistics gradually with the development of information technology. This paper introduces the general situation of satellite positioning system,analyses its current and future application in the field of military logistics, discusses the development ideaS of applying satellite positioning system in the field of military logistics. Key words:satellite positioning sy stem;military logistics;application 军事物流是指军事物资经由筹措、运输、储存、包装、维修保养、配送等环节,从供应地向部队用户有序流动的过程ll】。 卫星定位系统作为当今最先进的信息设施之一,是提高军事物流信息化建设水平,增强部队战斗力不可缺少的技术工具和手段 。 在现代军事物流活动中,重视这~ 技术的创新和推广应用,将快速实现对军事物流的实时监控,从而有效提高信息化战争的后 勤保障效能 1 卫星定位系统概况 卫星定位系统是利用多颗人造地球卫星、地面控制设备和信号接收设备,对地面静态或动态目标进行定位和导航的系统。 目前,全球正在运行或研制中的卫星定位系统有美国全球定位系统(Global Positioning System.GPS)、俄罗斯全球卫星导航系 统(GLONASS)、欧盟伽利略导航卫星系统计划(GALILEO)和中国“北斗一号” 卫星导航定位系统。 GPS是美国军方20世纪70年代研制的军民两用卫星定位系统,军用加密,民用降低定位精度后在全球使用,在用户数量 上处于霸主地位。GLONASS是由原苏联(现由俄罗斯)国防部独立研制和控制的第二代军用卫星导航系统, 其建立目的主要 是避免在军事上受制于美国。由于种种原因, 目前处于“半可用”状态,市场中GLONASS设备极少,产品多是内置GLONASS 和GPS两种接收装置, 以提高精度和可用性。同样出于避免受制于美国的目的.欧盟2003年也开始了GALILEO计划.建造世 界上第一个非军方控制和管理的民用』J星导航定位系统.预计2010年正式投入商业运行 这3个系统都是全球卫星导航定位 系统,导航范围覆盖全球。中国“北斗一号” 系统则是覆盖我国本土的区域导航定位系统, 目前拥有5颗导航卫星,除具有导 航功能外,还具有短报文通信和精密授时功能。在2008年南方抗击雨雪冰冻和四川特大地震灾害中初露锋芒.在北京奥运会 期间将为交通调度和场馆监控提供服务。 GPS导航系统是被动式伪码单向测距三维导航,采用的是无源定位。定位数据由用户设备独立解算, 因此不能提供通讯服 务。 “北斗” 系统是主动式双向测距二维导航,采用的是有源定位.定位数据由地面控制中心解算后提供给用户,用户需要通 过地面中心站联系及地面中心站的传输;因此可以提供通讯服务,通讯不必通过其他的通讯卫星.实现了一星多用。 GPS、GLONASS、GA[ ILEO和“北斗” 系统对比见表1 2 卫星定位系统在军事物流领域的应用现状 卫星定位系统的建立源于军事目的,美国GPS在近几场局部战争中应用于指挥控制、兵力投送、精确制导、目标侦察、战 场救援、军事物流等各个方面,成为美军战斗力的倍增器。尤其在伊拉克战争中,超大量战争物资运输保障,战时补给,大兵 团诸军兵种的专用装备保障,没有GPS 的导航和定位,军事物流则难以实现适时、快速、精确的保障,也就很难在短时间内 结束战斗并取得战斗的胜利 。近几年,我国加紧研发中国“北斗” 系统,引进对GPS的应用.逐渐将卫星定位系统应用于军 收稿日期:2008~06—24 作者简介: 白 娟(1973一),女,山东济南人,后勤指挥学院研究生五队硕士研究生,研究方向:军事物流信息化建设。 卫星定位系统在军事物流领域应用现状及前景探讨 表1 GPS、GLONASS、GALILEO和“北斗” 系统对比表 美国GPS 俄罗斯GL0NASS 欧盟GALILE0 中国“北斗” 系统 研制时间 20世纪70年代 20世纪70年代中期 1999年2月 2000生 卫星个数 28 24 30 5 轨道高度(KM) 20 186 l9 l00 23 222 36 0o0 运行周期 l1:15:44 l1:15:00 14:22:00 l1:58:00 民用单频CA码 民用单频CA码 CA码 调制码 军用双频P码 军用双频P码 P码 定位精度 CA码约l2米 水平方向约l6米 水平定位精度优于10米 约30米 P码小于10米 垂直方向约25米 覆盖范围 全球 全球 全球 中国及周边地区 主要功能 定位导航导航定位、短报文通信、 . 精密授时 定位导航,精密授时 定位导航.精密授时 精密授时 优点优点:投资小、用户设 : 全天候: 全球覆盖; 三维 由于GL0NASS卫星发 该系统提供三种导航定 备价廉 。定速定时高精度缺点: 不能覆 :快速省时高效 射的载波频率不同. 可 位信号 率: 免费信号、收 盖两极地区. 赤道附近 系统特点 : 应用广泛多功能。缺点:信 以防止整个卫星导航系 费加密信号 、号存在易损性和丢失性满足更高 定位精度差:不能满足 . 抗干扰 统同时被敌方干扰. 因 要求的收费加密信号 , 能力差高动态和保密的军事用 : 定位精度受美国军方限 而具有更强的抗干扰能 供各种不同的用户使用 户要求 . 书1 力 用户数量受一 定限制 民用领域: 用于航空/航海导航、 大地测量、石油勘探、地震测量、 由于种种原因. 目前处 野外救生、探险、森林防火、飞 于“半可用” 状态. 市 机播种、农田耕种、车辆自动导 场中GL0NASS设备极 2010年正式投入商业运 使用者基本是军队等国 应用现状 航监控、机场,港13'交通管理等诸 少, 而且多是美国产品, 行 家用户. 市面上很少有 多方面军用领域: 美军用于指挥 内置GL0NASS和GPS 北斗星的接收机出售 控制.兵力投送、精确制导、目 两种接收装置. 以提高 标侦察、战场救援、军事物流等 精度和可用性 方面 主动式双向测距二维导 定位原理 被动式伪码单向测距三维导航航。定位数据由地面控 , 定位数据由用户设备独立解算 制中心解算后提供给用 事物流领域,但仍处于初级阶段,其应用主要体现在以下几个方面 2.1 对军事物资运输的监控调度 通过将卫星定位系统的用户接收机安装在军用车辆、飞机、舰船上实现对军事物资运输的监控调度。利用卫星定位系统和 电子地图GIS可实时显示出运输工具的实际位置与轨迹,从而对其进行实时、有效的定位、监控和调度。实现方式是运输工具 通过终端接收导航定位信息,经处理后,将数据按一定格式由无线电收发机传送到指挥中心,指挥中心接收机将接收到的数据 输入计算机,经处理,在电子地图中显示运输工具和物资位置。 2.2 对军事运输路线的导航规划 选择正确、便捷的运输路线,是实现军事物流快速保障的前提条件。运用卫星定位系统的导航规划功能则充分满足了这一 需求。卫星导航系统的路线规划功能包括自动、手动和指令式3种。自动式路线规划是由驾驶员确定起点和终点,由计算机软 件按照要求自动设计最佳路线。手动式路线规划是驾驶员根据自己的目的地设计起点和终点等,系统在电子地图上设计路线, 同时显示运行途径和方向。指令式路线规划是指指挥中心对行驶站点的时间和路线能作出有效反应,提出路线的规划,并给运 输工具发出导航指令。实现方式是将卫星定位终端与计算机相连接,实现数据的实时传输,以电子地图的形式显示导航数据。 2-3 对需求信息的查询 在军事运输途中,卫星定位系统可以提供主要物标,在电子地图上根据需要进行查询,显示其位置。同时指挥中心可以利 用监测控制台对所在位置进行查询,车辆及物资信息则以数字形式在指挥中心的地图上显示出来。此外,利用卫星定位系统记 录和储存保障物资详细的运输内容和信息,消除了很多需要人工处理的环节,使得整个军事物流系统中所有程序及信息系统实 现信息传输的快速、准确、一致。 2 4 对险情、事故的紧急救援 72 {) ij¨P S t ~1 t lj 20~)g.{O 卫星定位系统在军事物流领域应用现状及前景探讨 通过卫星系统定位和监控管理系统可以对遇有险情或发生事故的地方进行紧急援助。监控台的电子地图显示求助信息和报 警目标,规划最优援助方案,并以报警声光提醒监控人员进行应急处理。我国自主研制的“北斗一号”卫星定位系统在四JIl汶 JIl地震救援中不仅实时监测到了救援部队的行进状态,而且在通信中断的情况下充分发挥了其短报文通信的功能,保障了救援 的顺利展开。 3 卫星定位系统在军事物流领域的应用前景 3.1 应用于建立网络化军事物流保障体系 军事物流保障网络化是信息化条件下一体化联合作战的要求,是指通过多种信息技术将各个物资保障网点(如物流中心、 后方基地、仓库等)集成为军事物流保障网,实现物流配送实体网络和信息网络的“无缝链接”,从而在战争中以实时的快速 反应、精确的投向投量和灵敏高效的指挥调度实现适时、适地、适量的后勤保障。卫星定位系统在军事物流网络化建设中具有 不可替代的作用,主要体现在功能多、精度高、覆盖面广,是构建网络的最佳技术设施和应用平台; 二是构筑在卫星定位系 统的网络公共平台,具有开放度高、资源共享程度高等优点,无地域性限制的信息获取,提高了定位系统的利用率。 3.2 应用于军事物流资产可视化管理 信息化条件下,战场透明度越来越高,物资储存和运输的可见性变得至关重要。物流资产可视化管理是依赖计算机技术、 网络技术、数据库技术、自动识别技术、卫星定位技术等多种信息技术,实现物资在储、在运、在处理全过程的数据跟踪可 视.使得部队指挥官可以不问断、可视化地掌握全部后勤资源的动态情况,全程跟踪“人员流”、 “装备流” 和“物资流”,并 指挥和控制其接收、分发和调换。在运资产通常是装载于某种运输工具,如火车、飞机、轮船、汽车等。实现在运资产可视 化,首先要掌握运输工具的实时位置,而掌握移动中的运输工具的实时位置离不开卫星定位系统。卫星定位系统在军事物流资 产可视化的应用,集中在两个主要方面:其~ 。卫星定位系统用于提供运输工具的位置数据。其二,卫星通信可使控制站和驾 驶员实现双向信息交流。有效运用卫星定位系统,形成有力的统一组织指挥中心,能够提高物流管理的透明度,为优质、高效 的物流保障提供坚实的技术平台。 3-3 应用于实现精确主动配送式保障模式 精确主动配送式保障是指在精确预测部队需求的前提下,打破过去那种逐级前送、被动等待的后勤保障运行机制,通过将 所需物资主动配送到战斗单位乃至士兵,使补给速度发生质的变化,是现代化军事物流保障模式的研究方向。物流配送的过程 是实物的空间位置转移过程,在物流配送过程中,涉及到货物的运输、仓储、装卸、送递等处理环节,对各个环节涉及的问题 如运输路线的选择、仓库位置的选择、仓库的容量设置、合理装卸策略、运输车辆的调度和投递路线的选择等进行有效的管理 和决策分析将有助于物流配送有效地利用现有资源, 降低消耗,提高效率。卫星定位系统解决了物流配送过程中运输车辆调度 和投递路线选择、精确定位部队用户等诸多问题,有利于提高物资的补给速度,从而实现精确主动配送式保障。 4 军事物流领域应用卫星定位系统的发展思路 目前.卫星定位系统在军事物流信息化建设的应用基本上还处于起步阶段,要实现这项技术的全面推广和运用.建立适应 我军后勤发展的军事物流系统,可以从以下几个方面着手: (1)加强卫星定位系统在军事物流领域推广应用的组织领导。由总部牵头统一组织规划、统一技术体制、统一信息标准、 统一软件开发,并与作战指挥系统兼容,从研究开始就杜绝卫星定位系统在军事物流领域应用中各自为政、互不统一、缺乏系 统集成等问题的出现。再就是加强军地合作,把军队的资源优势和地方的技术优势整合起来,共同研制、发展新技术,以保证 其在军事物流领域应用的有效性 (2)开展规划研究、突破关键技术。从顶层对研究项目进行规划设计,并根据我军现状确定当前及今后一段时期内卫星 定位系统在军事物流领域应用的重点和难点。必须立足于新技术引进后的自主开发和创新,形成自己的技术.组织科研力量协 力攻关,力争解决自主技术与外军技术相结合、抗干扰、精度限制、加密技术等关键难题,为卫星定位系统在军事物流信息化 建设中的进一步应用做好准备。 (3)研发基于卫星定位系统等先进信息技术的军事物流应用平台, 建设相关实验室,着眼未来信息化战争实际.跟踪国 内外、军内外卫星定位系统应用研究发展动态,积极探索卫星定位系统在我军军事物流领域的应用研究.以带动全军后勤信息 化的发展。 (4)在后勤保障部队试点后推广。选择部分后勤保障部队进行实验试点,使得卫星定位系统的应用真正与部队建设的实 际结合起来,通过解决实际中遇到的各种问题,不断完善卫星定位系统在军事物流建设的应用研究。从而最大限度地挖掘整个 军事物流系统的保障潜力,使我军后勤保障实现质的飞跃。 参考文献: [1】王宗喜,徐东.军事物流学[M].北京:清华大学出版,2007. 【2] 谭建中.物流信息技术【M】.北京: 中国物资出版社,2008. 【3】戢觉佑,王京海.美军后勤理论与实践【M】.天津:海军后勤学院,2003. f4】徐卫东.GPS+GLONASS+GALILEO三星跟踪技术【JJ_全球定位系统,2006(1):16—18 { 《' ;H s ( {l 200S {f) 73

管理贝贝 2019-12-02 01:16:43 0 浏览量 回答数 0

回答

PolarDB支持从RDS MySQL一键克隆数据到新的PolarDB MySQL集群。 前提条件 源RDS实例版本为RDS MySQL 5.6高可用版。 源RDS实例未开启TDE和SSL。 源RDS实例的表存储引擎为InnoDB。 如果RDS处于高安全模式(数据库代理模式),需要创建有高权限账号(请参见创建高权限账号),或者切换到高性能模式(参见【重要】RDS网络链路升级说明),才能进行一键克隆。查看数据库模式 背景信息 PolarDB是阿里云自研的下一代关系型云数据库,主要优势如下: 存储容量高:最高可达100TB。 性能高:最高可以提升至MySQL的6倍。 Serverless存储:存储容量无需提前购买,自动扩缩容,按使用量计费。 临时升配:临时升级规格,轻松应对短期的业务高峰。 详情请参见产品优势。 一键克隆功能将会新建一个与源RDS实例的数据相同的PolarDB集群,PolarDB集群包含源RDS实例的账号、数据库、IP白名单和必要的参数。源RDS实例的增量数据不会同步到PolarDB集群。 说明 如果需要在新建PolarDB集群的同时,使源RDS实例的增量数据实时同步到PolarDB集群,即实现平滑迁移(不停机迁移),请参见一键升级RDS MySQL到PolarDB MySQL。 一键克隆的功能亮点 免费 克隆过程数据0丢失 一键克隆的操作步骤 登录PolarDB控制台。 单击创建新集群。 选择包年包月或按量付费页签。 设置以下参数。 参数 说明 地域 源RDS MySQL实例所在地域。 说明 克隆的PolarDB集群也在此地域。 创建方式 集群的创建方式: 默认创建:创建一个全新的PolarDB集群。 从RDS克隆:基于所选的RDS实例,克隆一个数据完全一样的PolarDB集群。 从RDS迁移:先从RDS实例克隆一个PolarDB集群,同时保持同步。默认开启新集群的Binlog。 这里选择从RDS克隆。 源RDS引擎 源RDS实例的引擎类型,不可变更。 源RDS版本 源RDS实例的版本,不可变更。 源RDS实例 可选的源RDS实例,不包括只读实例。 可用区 可用区是地域中的一个独立物理区域,不同可用区之间没有实质性区别。 您可以选择将PolarDB集群与ECS创建在同一可用区或不同的可用区。 网络类型 PolarDB集群的网络类型,不可变更。 VPC网络 VPC交换机 PolarDB集群所属的VPC和虚拟交换机。请确保PolarDB集群与需要连接的ECS创建于同一个VPC,否则它们无法通过内网互通,无法发挥最佳性能。 数据库引擎 PolarDB集群的数据库引擎,不可变更。 节点规格 按需选择,建议不低于源RDS实例规格。所有PolarDB节点均为独享型,性能稳定可靠。详情请参见规格与定价。 节点个数 无需选择。系统将自动创建一个与主节点规格相同的只读节点。 存储费用 无需选择容量,根据实际数据使用量按小时计费。详情请参见规格与定价。 集群名称 填写集群名称用于区分业务用途。如果留空,系统将自动生成一个集群名称。创建集群后还可以修改。 设置购买时长(仅针对包年包月集群),然后单击右侧的立即购买。 确认订单信息,阅读和勾选服务协议,单击去开通。 常见问题 从RDS克隆会影响源RDS实例吗? 答:不会影响源RDS实例的正常运行。 相关API API 描述 CreateDBCluster 创建PolarDB集群。 说明 一键克隆时,参数CreationOption取值需要为CloneFromRDS。 后续步骤 请尽快将应用的数据库连接地址修改为PolarDB的地址,详情请参见查看连接地址。

游客yl2rjx5yxwcam 2020-03-08 14:02:52 0 浏览量 回答数 0

问题

如何通过跨阿里云账号RDS实例间数据实时同步作业的配置流程

云栖大讲堂 2019-12-01 21:25:17 1756 浏览量 回答数 0

回答

Kafka 是目前主流的分布式消息引擎及流处理平台,经常用做企业的消息总线、实时数据管道,本文挑选了 Kafka 的几个核心话题,帮助大家快速掌握 Kafka,包括: Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多,本文尽量做到深入浅出,全面的介绍 Kafka 原理及核心组件,不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台,经常用做企业的消息总线、实时数据管道,有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统,目前则演变成了一个成熟的分布式消息引擎,以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式,生产者发送消息到 broker 中某一个 topic 的具体分区里,消费者从一个或多个分区中拉取数据进行消费。拓扑图如下: 目前,Kafka 依靠 Zookeeper 做分布式协调服务,负责存储和管理 Kafka 集群中的元数据信息,包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语: Producer:生产者,消息产生和发送端。 Broker:Kafka 实例,多个 broker 组成一个 Kafka 集群,通常一台机器部署一个 Kafka 实例,一个实例挂了不影响其他实例。 Consumer:消费者,拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组,一条消息只能被消费组中一个 Consumer 消费。 Topic:主题,服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition:topic 的分区,分布式存储在各个 broker 中, 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费,达到消费者高吞吐量。一个分区拥有多个副本(Replica),这是Kafka在可靠性和可用性方面的设计,后面会重点介绍。 message:消息,或称日志消息,是 Kafka 服务端实际存储的数据,每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset:偏移量,分区中的消息位置,由 Kafka 自身维护,Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷(缓冲)、系统解构以及冗余的作用,主要特点有: 高吞吐、低延时:这是 Kafka 显著的特点,Kafka 能够达到百万级的消息吞吐量,延迟可达毫秒级; 持久化存储:Kafka 的消息最终持久化保存在磁盘之上,提供了顺序读写以保证性能,并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展:Kafka 的数据是分布式存储在不同 broker 节点的,以 topic 组织数据并且按 partition 进行分布式存储,整体的扩展性都非常好。 高容错性:集群中任意一个 broker 节点宕机,Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要,这也是 Kafka 高吞吐的基础,生产端的基本流程如下图所示: 主要有以下方面的设计: 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API,新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后,再是经过 Partition 分区器处理,决定消息落到 topic 具体某个分区中,最后把消息发送到客户端的消息缓冲池 accumulator 中,交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制,默认是 32M,当生产消息的速度过快导致 buffer 满了的时候,将阻塞 max.block.ms 时间,超时抛异常,所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch,分批次的发送到 broker 端,批次大小由参数 batch.size 控制,默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端,所以一般减小 batch 大小有利于降低消息延时,增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时,才会批量发送到服务端呢?答案是否定的,Kafka 生产端提供了另一个重要参数 linger.ms,该参数控制了 batch 最大的空闲时间,超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外,Kafka 生产端支持重试机制,对于某些原因导致消息发送失败的,比如网络抖动,开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制,参数含义代表重试次数,默认值为 0 表示不重试,建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本(Replica)的概念,副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本,由 broker 端参数 default.replication.factor 控制,默认值为 1,通常我们会修改该默认值,或者命令行创建 topic 时指定 replication-factor 参数,生产建议设置 3 副本。副本作用主要有两方面: 消息冗余存储,提高 Kafka 数据的可靠性; 提高 Kafka 服务的可用性,follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举,继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区,生产消费端所有的读写请求都是由 leader 副本处理的,follower 副本的主要工作就是从 leader 副本处异步拉取消息,进行消息数据的同步,并不对外提供读写服务。 Kafka 之所以这样设计,主要是为了保证读写一致性,因为副本同步是一个异步的过程,如果当 follower 副本还没完全和 leader 同步时,从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步,引入 ISR(In-Sync Replicas)副本集合的概念,ISR 是分区中正在与 leader 副本进行同步的 replica 列表,且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的,任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的,并不是所有的分区副本都在 ISR 列表中,哪些副本会被包含在 ISR 列表中呢?副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的,参数含义是副本同步落后于 leader 的最大时间间隔,默认10s,意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s,就会被从 ISR 中排除。Kafka 之所以这样设计,主要是为了减少消息丢失,只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举,这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的,所以 ISR 列表就有为空的时候,ISR 为空说明 leader 副本也“挂掉”了,此时 Kafka 就要重新选举出新的 leader。但 ISR 为空,怎么进行 leader 选举呢? Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”,这些副本中的消息远远落后于 leader,如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable,用于控制是否允许非同步副本参与 leader 选举;如果开启,则当 ISR 为空时就会从这些副本中选举新的 leader,这个过程称为 Unclean leader 选举。 前面也提及了,如果开启 Unclean leader 选举,可能会造成数据丢失,但保证了始终有一个 leader 副本对外提供服务;如果禁用 Unclean leader 选举,就会避免数据丢失,但这时分区就会不可用。这就是典型的 CAP 理论,即一个系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的两个。所以在这个问题上,Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举,这里建议关闭 Unclean leader 选举,因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器(Controller)是 Kafka 的核心组件,它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色,但在运行过程中,只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper,因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树,ZNode 是 Zookeeper 中的数据节点,是 Zookeeper 存储数据的最小单元,每个 ZNode 可以保存数据,也可以挂载子节点,根节点是 /。基本的拓扑图如下: Zookeeper 有两类 ZNode 节点,分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后,该节点依旧存在,直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起,客户端与 Zookeeper 断开会话后,临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性,它可以在 ZNode 节点上绑定监听事件,比如可以监听节点数据变更、节点删除、子节点状态变更等事件,通过这个事件机制,可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时,都会尝试去 Zookeeper 中创建 /controller 节点,第一个成功创建 /controller 节点的 broker 则会被指定为控制器,其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时,其他 broker 能够快速地感知到,然后再次尝试创建 /controller 节点,创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了,控制器主要作用是管理和协调 Kafka 集群,那么 Kafka 控制器都做了哪些事情呢,具体如下: 主题管理:创建、删除 topic,以及增加 topic 分区等操作都是由控制器执行。 分区重分配:执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作,也是由控制器实现。 Preferred leader 选举:这里有一个概念叫 Preferred replica 即优先副本,表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时,会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理:控制器能够监控新 broker 的增加,broker 的主动关闭与被动宕机,进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制,控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务:控制器上保存了最全的集群元数据信息,其他所有 broker 会定期接收控制器发来的元数据更新请求,从而更新其内存中的缓存数据。 从上面内容我们大概知道,控制器可以说是 Kafka 的心脏,管理和协调着整个 Kafka 集群,因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作,特别是在 0.11 版本中对控制器进行了重构,其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案,消除了多线程的资源消耗和线程安全问题,另外一个改进是把之前同步操作 Zookeeper 改为了异步操作,消除了 Zookeeper 端的性能瓶颈,大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时,提到了消费组的概念,一个 topic 可以让若干个消费者进行消费,若干个消费者组成一个 Consumer Group 即消费组 ,一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言,有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程,在 Rebalance 过程中,所有 Consumer 实例都会停止消费,等待 Rebalance 的完成。因为要停止消费等待重平衡完成,因此 Rebalance 会严重影响消费端的 TPS,是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance,总结起来有三种情况: 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的,比如为了提高消息吞吐量增加 topic 分区数,这些情况一般是不可避免的,后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前,先来认识下 Kafka 的协调器 Coordinator,和之前 Kafka 控制器类似,Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器: 组协调器(Group Coordinator) 消费者协调器(Consumer Coordinator) Kafka 为了更好的实现消费组成员管理、位移管理,以及 Rebalance 等,broker 服务端引入了组协调器(Group Coordinator),消费端引入了消费者协调器(Consumer Coordinator)。每个 broker 启动的时候,都会创建一个 GroupCoordinator 实例,负责消费组注册、消费者成员记录、offset 等元数据操作,这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外,每个 Consumer 实例化时,同时会创建一个 ConsumerCoordinator 实例,负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理: 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况,一种是有新的消费者加入,通常是我们为了提高消费速度增加了消费者数量,比如增加了消费线程或者多部署了一份消费程序,这种情况可以认为是正常的;另一种是有消费者退出,这种情况多是和我们消费端代码有关,是我们要重点避免的。 正常情况下,每个消费者都会定期向组协调器 Group Coordinator 发送心跳,表明自己还在存活,如果消费者不能及时的发送心跳,组协调器会认为该消费者已经“死”了,就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数:session.timeout.ms 和 heartbeat.interval.ms,含义分别是组协调器认为消费组存活的期限,和消费者发送心跳的时间间隔,其中 heartbeat.interval.ms 默认值是3s,session.timeout.ms 在 0.10.1 版本之前默认 30s,之后默认 10s。另外,0.10.1 版本还有两个值得注意的地方: 从该版本开始,Kafka 维护了单独的心跳线程,之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms,表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔,默认值 5min,对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组,此时将发生一次 Rebalance。 此外,如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿,从而引发 Rebalance。因此,我们总结如何避免消费组 Rebalance 问题,主要从以下几方面入手: 合理配置 session.timeout.ms 和 heartbeat.interval.ms,建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms,通常建议调大避免 Rebalance,但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况,避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数,可以减少生产环境中 Rebalance 发生的几率,提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制,Kafka 控制器、消费端 Rebalance 机制等各方面核心原理,通过本文的介绍,相信你已经对 Kafka 的内核知识有了一定的掌握,更多的 Kafka 原理实践后面有时间再介绍。

剑曼红尘 2020-04-16 18:15:45 0 浏览量 回答数 0

回答

高可用架构部署方案 高可用架构提供业务分发、弹性扩展、多可用区部署等功能。相较于使用单台ECS实例部署数据库与应用,高可用架构只需简单部署,并且拥有更高的稳定性和可扩展性。 高可用架构特点 高可用架构具有如下特点: 使用多可用区高可用版的负载均衡SLB(Server Load Balancer)对多台云服务器ECS进行流量分发,可扩展应用系统对外服务能力、消除单点故障,提升应用系统的可用性。使用SLB自动跨可用区部署,可加强业务容灾能力。 通过自定义镜像,可以迅速复制出相同应用部署的云服务器ECS实例,之后将实例添加到SLB后端服务器组中,实现业务高可用。SLB可以同时配置四层和七层监听,及轮循、加权轮循、加权最小连接数等多种算法,合理分配后端ECS计算资源。 使用云数据库RDS(Relational Database Service),针对高并发场景进行特殊优化,同时引入线程池、并行复制、隐含主键等功能保证系统持续稳定和高吞吐。云数据库CloudDBA具有完备的性能监控数据,实时监控实例硬件使用指标、慢SQL,并给出各种优化建议,帮您快速定位并解决问题。 部署流程 假设您已拥有一台ECS实例,并且在该实例上部署了数据库与应用,您可以将单实例部署方式转变为单可用区或多可用区高可用架构。本教程指导您如何使用ECS、EIP、SLB和RDS产品来部署多可用区高可用架构。 高可用结构图 使用自定义镜像,部署多台相同配置的ECS实例。详情请参见复制ECS实例。 创建负载均衡SLB实例,将实例添加到SLB后端服务器组中,用于跨可用区挂载ECS实例,实现业务的高可用性。详情请参见配置SLB实例。 使用DTS将ECS实例上的自建数据库迁移至RDS实例,保障业务数据库不中断,自动备份保障数据不丢失。详情请参见迁移自建数据库至RDS实例。 复制ECS实例为了支持跨可用区容灾部署,本教程使用源实例的自定义镜像复制出三台ECS实例。一台与源实例位于同一可用区,两台与源实例位于同一地域下的不同可用区。 前提条件 已注册阿里云账号。如还未注册,请先完成账号注册。 已拥有待复制的源ECS实例。 操作步骤 为ECS实例创建自定义镜像。 登录ECS管理控制台。 在左侧导航栏,单击实例与镜像 > 实例。 在顶部状态栏处,选择地域。 找到目标实例。在操作列中,单击更多 > 磁盘和镜像 > 创建自定义镜像。 输入镜像名称和描述信息。 单击创建。 说明 创建镜像需要一段时间,请您耐心等待。 在左侧导航栏,单击实例与镜像 > 镜像。当目标镜像的进度为100%、状态为可用时,表示镜像创建成功。自定义镜像 使用自定义镜像创建3台ECS实例。 在左侧导航栏,单击实例与镜像 > 镜像。 在自定义镜像页面,找到上一步创建的自定义镜像,在操作列,单击创建实例。 在自定义购买页面,镜像区域已设置为您选择的自定义镜像。根据页面提示,完成其他配置项并购买1台ECS实例。 其中: 地域:选择与源实例相同的地域。 可用区:选择与源实例相同的可用区。 公网带宽:取消勾选分配公网IPv4地址。 更多配置详情,请参见使用向导创建实例。 重复第i步和第ii步。在自定义购买页,镜像区域已设置为您选择的自定义镜像。根据页面提示,完成其他配置项并购买2台实例。 其中: 地域:选择与源实例相同的地域。 可用区:选择与源实例不同的可用区。 实例区域:设置购买实例数量为2。 公网带宽区域:取消勾选分配公网IPv4地址。 更多配置详情,请参见使用向导创建实例。 执行结果 在左侧导航栏,单击实例与镜像 > 实例。在实例列表页面,四台ECS实例的状态均为运行中,可用区两两相同。 ecs_instances 配置SLB实例 ECS实例复制完成后,在支持多可用区的地域创建负载均衡SLB实例,用于跨可用区挂载ECS实例,扩展应用系统对外服务能力、消除单点故障,提升应用系统的可用性。本文介绍SLB实例的部署方法。 前提条件 已复制三台ECS实例,详情请参见复制ECS实例。 四台ECS实例的Web服务均已启动并正常运行。 注意 若Web服务未运行,则SLB实例与ECS实例之间无法正常通信。 操作步骤 创建SLB实例。具体操作,请参见创建负载均衡实例。 本教程使用的配置如下: 地域:必须与ECS实例位于同一地域。 可用区类型:选择多可用区。 实例类型:选择私网。 网络类型:选择专有网络。 主可用区和备可用区:按需配置。 create_slb 将源实例的公网IP转换为弹性公网IP。具体操作,请参见专有网络公网IP转换为弹性公网IP。 说明 为避免影响业务,需保证源实例IP地址不变。因此,需要先将源实例的公网IP转换为弹性公网IP,与源实例解绑后,再将其绑定至高可用版SLB实例上。 ip_eip 解绑源实例与弹性公网IP。 在源实例的IP地址列,单击弹性IP地址链接。 click_eip 在弹性公网IP页面,单击解绑。 unbindEIP 单击确定。更多详情,请参见解绑EIP。 绑定弹性公网IP至SLB实例。 在弹性公网IP页面,找到与源实例解绑后的弹性公网IP。 bindEIP 在操作列,单击绑定。 实例类型选择SLB实例,SLB实例选择刚创建的SLB实例,单击确定。更多详情,请参见绑定SLB实例。 配置SLB实例。具体操作,请参见配置负载均衡实例。 基本配置如下: 在协议&监听页签,完成以下配置。 负载均衡协议:选择TCP。 监听端口:输入80。 调度算法:按需选择。本教程选择轮询。 其他配置使用默认值。 configure_slb 单击下一步。在后端服务器页签,选择默认服务器组,单击继续添加添加ECS实例。 addEcsInstance 勾选源实例和已复制的三台ECS实例,单击下一步:配置权重和端口号。端口配置为80,其他值保持默认,单击下一步。 configure_ports 在健康检查页签,使用默认值,单击下一步。 在配置审核页签,核对信息后,单击提交。 单击确定,返回实例管理页面,单击refresh。 当健康检查状态为正常时,表示后端ECS实例可以正常处理负载均衡转发的请求了。 说明 健康检查需要几分钟时间,请您耐心等待并单击刷新图标查看状态。 health_check 执行结果 为方便测试,本教程分别在四台ECS实例上搭建了静态网页,以标识每台ECS实例。在浏览器中输入负载均衡实例的服务地址,测试负载均衡服务。由于调度算法为轮询,请求会轮流发往每台ECS实例。 slb_test 迁移自建数据库至RDS实例 将源ECS实例上的数据库迁移至高可用版云数据库RDS,可实现数据库服务的高可用性、高可靠性、高安全性和高易用性。本教程以MySQL数据库为例,介绍如何使用DTS将ECS实例上的自建数据库迁移至RDS实例。 前提条件 已配置SLB实例,详情请参见配置SLB实例。 已创建高可用版RDS实例。如未创建,请参见创建RDS for MySQL实例。 已为RDS实例创建账号。如未创建,请参见创建账号和数据库。 已为ECS实例上的自建数据库创建非root账号,用于DTS迁移。 例如,您可以运行以下命令为MySQL数据库创建名为dts、密码为123456的账号。 grant all on . to 'dts'@'%' IDENTIFIED BY '123456'; 背景信息 DTS提供的数据迁移功能能够支持同异构数据源之间的数据迁移,同时提供了库表列三级映射、数据过滤多种ETL特性。您可以使用DTS进行零停机迁移,在迁移过程中,源数据库正常持续提供服务,最大程度降低迁移对业务的影响。DTS支持的数据库类型请参见数据迁移。 操作步骤 登录数据传输DTS控制台。 在左侧导航栏,选择数据迁移。 选择目标RDS实例所在地域,并单击创建迁移任务。 配置迁移任务。 配置任务名称。 您可以使用默认的名称或者自定义名称。 配置源库信息。 DTS支持通过公网、VPN网关、专线及智能网关访问的自建数据库。本教程使用的源数据库为ECS实例上的自建数据库。其他类型数据库的迁移方案,请参见DTS用户手册。 参数名称 描述 实例类型 ECS上的自建数据库。 实例地区 源ECS实例所在地域。 ECS实例ID 源ECS实例的实例ID。DTS支持经典网络及专有网络的ECS实例。 数据库类型 源ECS实例上自建数据库的类型。本示例中,数据库类型为MySQL。 端口 MySQL数据库监听的端口号。 数据库账号 源ECS实例上MySQL数据库的非root账号。 说明 数据库账号必须填写非root账号,否则测试连接时会报错。 数据库密码 非root账号对应的密码。 单击源库信息右下角的测试连接。 当返回的结果为测试通过时,表示源库连接正常。 配置目标库信息。 参数名称 参数值 实例类型 RDS实例。 实例地区 RDS实例所在地域。 RDS实例ID RDS实例的实例ID。 数据库账号 RDS实例的账号。 为RDS实例创建账号,请参见创建账号和数据库。 说明 数据库账号必须填写非root账号,否则测试连接时会报错。 数据库密码 账号对应的密码。 单击目标库信息右下角的测试连接。 当返回的结果为测试通过时,表示目标库连接正常。 单击授权白名单并进入下一步。 配置迁移类型及迁移对象。 配置迁移类型。 业务零停机迁移,请选择:结构迁移+全量数据迁移+增量数据迁移。 全量迁移,请选择:结构迁移+全量数据迁移。 配置迁移对象。 在迁移对象框中单击要迁移的数据库对象,如数据库、表或列,然后单击>添加到已选择对象框中。 说明 默认情况下,数据库对象迁移到ECS自建MySQL实例后,对象名跟本地MySQL实例一致。如果迁移的数据库对象在源实例跟目标实例上名称不同,您需要使用DTS提供的对象名映射功能,详情请参见库表列映射。 单击预检查并启动。 在迁移任务正式启动之前,会预检查连通性、权限及日志格式等。下图表示预检查成功通过。 precheck 预检查通过后,您可以在迁移任务列表中查看迁移任务的迁移状态及进度。 task_result 后续步骤 在应用程序中配置RDS实例的连接地址和账号密码,以连接到RDS实例。您还可以使用数据管理服务DMS(Data Management Service)或客户端管理RDS实例。具体操作,请参见连接MySQL实例。

1934890530796658 2020-03-25 19:18:04 0 浏览量 回答数 0

问题

容器服务&nbsp;&nbsp;应用场景

青蛙跳 2019-12-01 21:32:37 467 浏览量 回答数 0

回答

要了解CDN 的实现原理,首先让我们来回顾一下网站传统的访问过程,以便理解其与CDN 访问方式之间的差别: 由上图可见,传统的网站访问过程为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,获得此域名对应的IP 地址; 3. 浏览器利用所得到的IP 地址,向该IP 对应的服务器发出访问请求; 4. 服务器对此响应,将数据回传至用户浏览器端显示出来。 与传统访问方式不同,CDN 网络则是在用户和服务器之间增加 Cache 层,将用户的访问请求引导到Cache 节点而不是服务器源站点,要实现这一目的,主要是通过接管DNS 实现,下图为使用CDN 缓存后的网站访问过程: 由上图可见,使用CDN 缓存后的网站访问过程演变为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,由于CDN 对域名解析过程进行了调整,所以用户端一般得到的是该域名对应的 CNAME 记录,此时浏览器需要再次对获得的 CNAME 域名进行解析才能得到缓存服务器实际的IP 地址。 注:在此过程中,全局负载均衡DNS 解析服务器会根据用户端的源IP 地址,如地理位置(深圳还是上海)、接入网类型(电信还是网通)将用户的访问请求定位到离用户路由最短、位置最近、负载最轻的Cache 节点(缓存服务器)上,实现就近定位。定位优先原则可按位置、可按路由、也可按负载等。 3. 再次解析后浏览器得到该域名CDN 缓存服务器的实际IP 地址,向缓存服务器发出访问请求; 4. 缓存服务器根据浏览器提供的域名,通过Cache 内部专用DNS 解析得到此域名源服务器的真实IP 地址,再由缓存服务器向此真实IP 地址提交访问请求; 5. 缓存服务器从真实 IP 地址得到内容后,一方面在本地进行保存,以备以后使用,同时把得到的数据发送到客户端浏览器,完成访问的响应过程; 6. 用户端得到由缓存服务器传回的数据后显示出来,至此完成整个域名访问过程。 通过以上分析可以看到,不论是否使用CDN 网络,普通用户客户端设置不需做任何改变,直接使用被加速网站原有域名访问即可。对于要加速的网站,只需修改整个访问过程中的域名解析部分,便能实现透明的网络加速服务。 CDN 应用与架构 CDN 速度快、传输安全、扩展性强,尤其在应对大容量迸发时游刃有余,主要应用于跨地域的门户及行业网站,如游戏、娱乐、IT、新闻传媒、VOD、远程教育、音视频、下载、IPTV、金融证券等。 利用CDN 网络,网站用户无需投资价值不菲的服务器、网络带宽及相应的人力成本,便能实现将网站内容发布到离终端用户距离最近、路由最短的网际边缘Cache 节点,创造完美、快捷的网站使用体验。 构建 CDN 网络的通常有三类机构,一是基础电信运营商(如中国电信、中国网通等),二是纯粹以 CDN 为主营业务的专业服务商(如 ChinaCache 等),三是 IDC 运营服务商(如 SouIDC 等)。虽然上述机构建设CDN 网络的出发点、侧重点不尽相同,但有一点却是相通的,即都是为用户提供完美的网站加速服务。 IDC 运营商部署在各地的 IDC 中心机房,非常有利于其快速建立起适合自身业务拓展的 CDN 网络,投资少见效快。其最大优势在于可以利用现有的 IDC 托管用户资源,进一步挖掘其潜在的增值服务空间。同时对于其 IDC 托管用户来讲,只需很少的投入便可实现网站的平滑加速,并保持了服务及支持上的无缝延续。 SynCDN 便是SouIDC 构建的CDN 网站加速运营平台。 一般来讲,CDN 网络主要由中心节点、边缘节点两部分构成。 CDN 架构导引 最简单的 CDN 网络只需一台负责全局负载均衡的 DNS 和各节点一台 Cache,即可运行。 DNS 支持根据用户源 IP 地址解析不同的 IP,实现就近访问。为了保证高可用性等,CDN 网管中心需要监控各节点的流量、健康状况等。一个节点的单台Cache 承载数量不够时,才需要多台 Cache,多台Cache 同时工作时,才需要负载均衡器,使Cache 群协同工作。 CDN 中心节点 中心节点包括CDN 网管中心和全局负载均衡DNS 重定向解析系统,负责整个CDN 网络的分发及管理。 CDN 网管中心是整个CDN 能够正常运转的基础保证,它不仅能对整个CDN 网络中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中总的流量和各节点的流量,并保存在系统数据库中,使网管人员能够方便地进行进一步分析。一套完善的网管系统,允许用户按需对系统配置进行修改。 全局负载均衡DNS 通过一组预先定义好的策略,将当时最接近用户的Cache 节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在各地的所有CDN 节点保持持续通信,搜集各节点的通信状态,确保不会将用户的请求分发到不可用、或不健康的 Cache 节点上。 CDN 边缘节点 CDN 边缘节点主要指异地分发节点,由负载均衡设备、高速缓存服务器两部分组成。 负载均衡设备负责每个节点中各个Cache 的负载均衡,保证节点的工作效率;同时还负责收集节点与周围环境的信息,保持与全局负载均衡DNS 的通信,实现整个系统的负载均衡。 高速缓存服务器(Cache)负责存储客户网站的大量信息,就像一个靠近用户的网站服务器一样响应本地用户的访问请求。通过全局负载均衡DNS 的控制,用户的请求被透明地指向离他最近的节点,节点中Cache 服务器就像网站的原始服务器一样,响应终端用户的请求。因其距离用户更近,故其响应时间才更快。 答案来源于网络

养狐狸的猫 2019-12-02 03:03:30 0 浏览量 回答数 0

回答

要了解CDN 的实现原理,首先让我们来回顾一下网站传统的访问过程,以便理解其与CDN 访问方式之间的差别: 由上图可见,传统的网站访问过程为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,获得此域名对应的IP 地址; 3. 浏览器利用所得到的IP 地址,向该IP 对应的服务器发出访问请求; 4. 服务器对此响应,将数据回传至用户浏览器端显示出来。 与传统访问方式不同,CDN 网络则是在用户和服务器之间增加 Cache 层,将用户的访问请求引导到Cache 节点而不是服务器源站点,要实现这一目的,主要是通过接管DNS 实现,下图为使用CDN 缓存后的网站访问过程: 由上图可见,使用CDN 缓存后的网站访问过程演变为: 1. 用户在浏览器中输入要访问的域名; 2. 浏览器向域名解析服务器发出解析请求,由于CDN 对域名解析过程进行了调整,所以用户端一般得到的是该域名对应的 CNAME 记录,此时浏览器需要再次对获得的 CNAME 域名进行解析才能得到缓存服务器实际的IP 地址。 注:在此过程中,全局负载均衡DNS 解析服务器会根据用户端的源IP 地址,如地理位置(深圳还是上海)、接入网类型(电信还是网通)将用户的访问请求定位到离用户路由最短、位置最近、负载最轻的Cache 节点(缓存服务器)上,实现就近定位。定位优先原则可按位置、可按路由、也可按负载等。 3. 再次解析后浏览器得到该域名CDN 缓存服务器的实际IP 地址,向缓存服务器发出访问请求; 4. 缓存服务器根据浏览器提供的域名,通过Cache 内部专用DNS 解析得到此域名源服务器的真实IP 地址,再由缓存服务器向此真实IP 地址提交访问请求; 5. 缓存服务器从真实 IP 地址得到内容后,一方面在本地进行保存,以备以后使用,同时把得到的数据发送到客户端浏览器,完成访问的响应过程; 6. 用户端得到由缓存服务器传回的数据后显示出来,至此完成整个域名访问过程。 通过以上分析可以看到,不论是否使用CDN 网络,普通用户客户端设置不需做任何改变,直接使用被加速网站原有域名访问即可。对于要加速的网站,只需修改整个访问过程中的域名解析部分,便能实现透明的网络加速服务。 CDN 应用与架构 CDN 速度快、传输安全、扩展性强,尤其在应对大容量迸发时游刃有余,主要应用于跨地域的门户及行业网站,如游戏、娱乐、IT、新闻传媒、VOD、远程教育、音视频、下载、IPTV、金融证券等。 利用CDN 网络,网站用户无需投资价值不菲的服务器、网络带宽及相应的人力成本,便能实现将网站内容发布到离终端用户距离最近、路由最短的网际边缘Cache 节点,创造完美、快捷的网站使用体验。 构建 CDN 网络的通常有三类机构,一是基础电信运营商(如中国电信、中国网通等),二是纯粹以 CDN 为主营业务的专业服务商(如 ChinaCache 等),三是 IDC 运营服务商(如 SouIDC 等)。虽然上述机构建设CDN 网络的出发点、侧重点不尽相同,但有一点却是相通的,即都是为用户提供完美的网站加速服务。 IDC 运营商部署在各地的 IDC 中心机房,非常有利于其快速建立起适合自身业务拓展的 CDN 网络,投资少见效快。其最大优势在于可以利用现有的 IDC 托管用户资源,进一步挖掘其潜在的增值服务空间。同时对于其 IDC 托管用户来讲,只需很少的投入便可实现网站的平滑加速,并保持了服务及支持上的无缝延续。 SynCDN 便是SouIDC 构建的CDN 网站加速运营平台。 一般来讲,CDN 网络主要由中心节点、边缘节点两部分构成。 CDN 架构导引 最简单的 CDN 网络只需一台负责全局负载均衡的 DNS 和各节点一台 Cache,即可运行。 DNS 支持根据用户源 IP 地址解析不同的 IP,实现就近访问。为了保证高可用性等,CDN 网管中心需要监控各节点的流量、健康状况等。一个节点的单台Cache 承载数量不够时,才需要多台 Cache,多台Cache 同时工作时,才需要负载均衡器,使Cache 群协同工作。 CDN 中心节点 中心节点包括CDN 网管中心和全局负载均衡DNS 重定向解析系统,负责整个CDN 网络的分发及管理。 CDN 网管中心是整个CDN 能够正常运转的基础保证,它不仅能对整个CDN 网络中的各个子系统和设备进行实时监控,对各种故障产生相应的告警,还可以实时监测到系统中总的流量和各节点的流量,并保存在系统数据库中,使网管人员能够方便地进行进一步分析。一套完善的网管系统,允许用户按需对系统配置进行修改。 全局负载均衡DNS 通过一组预先定义好的策略,将当时最接近用户的Cache 节点地址提供给用户,使用户能够得到快速的服务。同时,它还与分布在各地的所有CDN 节点保持持续通信,搜集各节点的通信状态,确保不会将用户的请求分发到不可用、或不健康的 Cache 节点上。 CDN 边缘节点 CDN 边缘节点主要指异地分发节点,由负载均衡设备、高速缓存服务器两部分组成。 负载均衡设备负责每个节点中各个Cache 的负载均衡,保证节点的工作效率;同时还负责收集节点与周围环境的信息,保持与全局负载均衡DNS 的通信,实现整个系统的负载均衡。 高速缓存服务器(Cache)负责存储客户网站的大量信息,就像一个靠近用户的网站服务器一样响应本地用户的访问请求。通过全局负载均衡DNS 的控制,用户的请求被透明地指向离他最近的节点,节点中Cache 服务器就像网站的原始服务器一样,响应终端用户的请求。因其距离用户更近,故其响应时间才更快。 答案来源于网络

养狐狸的猫 2019-12-02 02:37:34 0 浏览量 回答数 0

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。

小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

本文主要为您介绍容器服务 ACK 的常见应用场景。 DevOps 持续交付 最优化的持续交付流程 配合 Jenkins 帮您自动完成从代码提交到应用部署的 DevOps 完整流程,确保只有通过自动测试的代码才能交付和部署,高效替代业内部署复杂、迭代缓慢的传统方式。 能够实现: DevOps 自动化 实现从代码变更到代码构建、镜像构建和应用部署的全流程自动化。 环境一致性 容器技术让您交付的不仅是代码,还有基于不可变架构的运行环境。 持续反馈 每次集成或交付,都会第一时间将结果实时反馈。 推荐搭配使用: 云服务器 ECS + 容器服务 DevOps 基于云原生技术的机器学习 专注机器学习本身,快速实现从 0 到 1 帮助数据工程师在异构计算资源集群上轻松开发、部署机器学习应用,跟踪试验和训练、发布模型,自动集成多种数据部署在分布式存储系统,加速训练数据读写,无需关心繁琐部署运维,专注核心业务,快速从 0 到 1。 能够实现: 支持生态 内置对 TensorFlow、Caffe、 MXNet、Pytorch 等主流深度学习计算框架支持和优化。 快速弹性 一键部署机器学习开发、训练、推理服务,秒级启动和弹性伸缩。 简单可控 轻松创建、管理大规模 GPU 计算集群,并且可以监控 GPU 利用率等核心指标。 深度整合 无缝接入阿里云存储、日志监控和安全基础架构能力。 推荐搭配使用: 云服务器 ECS/GPU 服务器 EGS/高性能计算服务 (Alibaba Cloud HPC)+ 容器服务 + 对象存储 OSS/文件存储 NAS/CPFS 容器服务 微服务架构 实现敏捷开发和部署落地,加速企业业务迭代 企业生产环境中,通过合理微服务拆分,将每个微服务应用存储在阿里云镜像仓库帮您管理。您只需迭代每个微服务应用,由阿里云提供调度、编排、部署和灰度发布能力。 能够实现: 负载均衡和服务发现 支持 4 层和 7 层的请求转发和后端绑定。 丰富的调度和异常恢复策略 支持服务级别的亲和性调度,支持跨可用区的高可用和灾难恢复。 微服务监控和弹性伸缩 支持微服务和容器级别的监控,支持微服务的自动伸缩。 推荐搭配使用: 云服务器 ECS + 云数据库 RDS 版 + 对象存储 OSS + 容器服务 负载均衡 混合云架构 统一运维多个云端资源 在容器服务控制台上同时管理云上云下的资源,不需在多种云管理控制台中反复切换。基于容器基础设施无关的特性,使用同一套镜像和编排同时在云上云下部署应用。 能够实现: 在云上伸缩应用 业务高峰期,在云端快速扩容,把一些业务流量引到云端。 云上容灾 业务系统同时部署到云上和云下,云下提供服务,云上容灾。 云下开发测试 云下开发测试后的应用无缝发布到云上。 推荐搭配使用: 云服务器 ECS + 专有网络 VPC + 高速通道(Express Connect) 容器服务 弹性伸缩架构 根据业务流量自动对业务扩容/缩容 容器服务可以根据业务流量自动对业务扩容/缩容,不需要人工干预,避免流量激增扩容不及时导致系统挂掉,以及平时大量闲置资源造成浪费。 能够实现: 快速响应 业务流量达到扩容指标,秒级触发容器扩容操作。 全自动 整个扩容/缩容过程完全自动化,无需人工干预。 低成本 流量降低自动缩容,避免资源浪费。 推荐搭配使用: 云服务器 ECS + 云监控 云监控

1934890530796658 2020-03-26 11:24:27 0 浏览量 回答数 0

问题

容器服务的应用场景是什么?

反向一觉 2019-12-01 21:17:02 1646 浏览量 回答数 0

问题

企业级分布式应用服务 EDAS名词含义是什么?

猫饭先生 2019-12-01 21:03:04 1084 浏览量 回答数 0

问题

订阅日志服务数据的用户手册

云栖大讲堂 2019-12-01 20:56:31 1339 浏览量 回答数 0

回答

Redis常见的几种主要使用方式: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster(集群) Redis 自研 Redis各种使用方式的优缺点: 1 Redis单副本 Redis各种使用方式的优缺点: Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 2 Redis多副本(主从) Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 3 Redis Sentinel(哨兵) Redis Sentinel是社区版本推出的原生高可用解决方案,Redis Sentinel部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群,其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。 优点: 1、Redis Sentinel集群部署简单 2、能够解决Redis主从模式下的高可用切换问题 3、很方便实现Redis数据节点的线形扩展,轻松突破Redis自身单线程瓶颈,可极大满足对Redis大容量或高性能的业务需求。 4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点 缺点: 1、部署相对Redis 主从模式要复杂一些,原理理解更繁琐 2、资源浪费,Redis数据节点中slave节点作为备份节点不提供服务 3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换,对Redis的数据节点做失败判定分为主观下线和客观下线两种,对于Redis的从节点有对节点做主观下线操作,并不执行故障转移。 4、不能解决读写分离问题,实现起来相对复杂 建议: 1、如果监控同一业务,可以选择一套Sentinel集群监控多组Redis数据节点的方案,反之选择一套Sentinel监控一组Redis数据节点的方案 2、sentinel monitor 配置中的 建议设置成Sentinel节点的一半加1,当Sentinel部署在多个IDC的时候,单个IDC部署的Sentinel数量不建议超过(Sentinel数量 – quorum)。 3、合理设置参数,防止误切,控制切换灵敏度控制 quorum down-after-milliseconds 30000 failover-timeout 180000 maxclient timeout 4、部署的各个节点服务器时间尽量要同步,否则日志的时序性会混乱 5、Redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率 6、自行搞定配置中心(zookeeper),方便客户端对实例的链接访问 4 Redis Cluster(集群) Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。 优点: 1、无中心架构 2、数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布。 3、可扩展性,可线性扩展到1000多个节点,节点可动态添加或删除。 4、高可用性,部分节点不可用时,集群仍可用。通过增加Slave做standby数据副本,能够实现故障自动failover,节点之间通过gossip协议交换状态信息,用投票机制完成Slave到Master的角色提升。 5、降低运维成本,提高系统的扩展性和可用性。 缺点: 1、Client实现复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。 2、节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线,这种failover是没有必要的。 3、数据通过异步复制,不保证数据的强一致性。 4、多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。 5、Slave在集群中充当“冷备”,不能缓解读压力,当然可以通过SDK的合理设计来提高Slave资源的利用率。 6、key批量操作限制,如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询,所以执行mset、mget、sunion等操作支持不友好。 7、key事务操作支持有限,只支持多key在同一节点上的事务操作,当多个key分布于不同的节点上时无法使用事务功能。 8、key作为数据分区的最小粒度,因此不能将一个很大的键值对象如hash、list等映射到不同的节点。 9、不支持多数据库空间,单机下的redis可以支持到16个数据库,集群模式下只能使用1个数据库空间,即db 0。 10、复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。 11、避免产生hot-key,导致主库节点成为系统的短板。 12、避免产生big-key,导致网卡撑爆、慢查询等。 13、重试时间应该大于cluster-node-time时间 14、Redis Cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。 使用场景 数据量较大 Redis 集群版可以有效的扩展数据规模,相比标准版支持存储量更大的64、128、256 GB 集群版,可以有效的满足数据扩展需求。 QPS 压力较大 标准版 Redis 无法支撑较大的 QPS,需要采用多节点的部署方式来冲破 Redis 单线程的性能瓶颈。 吞吐密集型应用 相比标准版,Redis 集群版的内网吞吐限制相对较低,针对热点数据读取、大吞吐类型的业务可以友好的支持。 对 Redis 协议不敏感的应用 由于集群版的架构引入了多个组件,在 Redis 协议支持上相比标准版有一定限制。

剑曼红尘 2020-04-27 14:41:57 0 浏览量 回答数 0

问题

新时代DevOps需求下,我们该如何保障服务的安全?

忆远0711 2019-12-01 21:56:45 8122 浏览量 回答数 1

回答

MQTT协议 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)最早是IBM开发的一个即时通讯协议,MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台,它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性:1、使用发布/订阅消息模式,提供一对多的消息发布和应用程序之间的解耦;2、消息传输不需要知道负载内容;3、使用 TCP/IP 提供网络连接;4、有三种消息发布的服务质量:QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。5、小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量;6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小,最小的数据包只有2个bit,且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布/订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的,所以只有少量的内存空间和有限的计算能力,传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此,IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN(面向低功耗无线局域网的IPv6)的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。NON——不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。ACK——应答消息,接受到CON消息的响应。RST——复位消息,当接收者接受到的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式,最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子: 比如某个设备需要从服务器端查询当前温度信息。 请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C” ,响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。从应用方向来分析,主要区别有以下几点: 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol,超文本传输协议,这个协议的提出就是为了提供和接收HTML界面,通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程,Request和Response,两个都有各自的语言格式,我们看下是什么。请求报文格式:(注意这里有个换行) 响应报文格式:(注意这里有个换行) 方法method:       这个很重要,比如说GET和POST方法,这两个是很常用的,GET就是获取什么内容,而POST就是向服务器发送什么数据。当然还有其他的,比如HTTP 1.1中还有:DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法(HTTP Method历史:HTTP 0.9 只有GET方法;HTTP 1.0 有GET、POST、HEAD三个方法)。请求URL:       这里填写的URL是不包含IP地址或者域名的,是主机本地文件对应的目录地址,所以我们一般看到的就是“/”。版本version:       格式是HTTP/.这样的格式,比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本,现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字,代表的是请求过程中所发生的情况,比如说200代表的是成功,404代表的是找不到文件。原因短语reason-phrase:       是状态码的可读版本,状态码就是一个数字,如果你事先不知道这个数字什么意思,可以先查看一下原因短语。首部header:       注意这里的header我们不是叫做头,而是叫做首部。可能有零个首部也可能有多个首部,每个首部包含一个名字后面跟着一个冒号,然后是一个可选的空格,接着是一个值,然后换行。实体的主体部分entity-body:       实体的主体部分包含一个任意数据组成的数据块,并不是所有的报文都包含实体的主体部分,有时候只是一个空行加换行就结束了。 下面我们举个简单的例子: 请求报文:GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文:HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议,基于REST(表述性状态传递)架构风格,支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式,最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多,太重,不够灵活。 XMPP协议 XMPP(可扩展通讯和表示协议)是一种基于可扩展标记语言(XML)的协议, 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础,而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器,然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML(标准通用标记语言的子集)流是什么样子的?客户端:123456<?xmlversion='1.0'?>to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器:1234567<?xmlversion='1.0'?>from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西, 中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流,关闭TCP/IP连接。  网络通信过程中数据冗余率非常高,网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说,大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备,省电、省流量是所有底层服务的一个关键技术指标,XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范,是一种轻量的、简单的、 基于可扩展标记语言(XML)的协议,它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP), 简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到 远程过程调用(RPC)等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结: 从当前物联网应用发展趋势来分析,MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商,比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早,所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展,后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者:HFK_Frank 来源:CSDN 原文:https://blog.csdn.net/acongge2010/article/details/79142380 版权声明:本文为博主原创文章,转载请附上博文链接!

auto_answer 2019-12-02 01:55:21 0 浏览量 回答数 0

回答

网络性能主要有主动测试,被动式测试以及主动被动相结合测试三种方法 1.主动测量是在选定的测量点上利用测量工具有目的地主动产生测量流量注入网络,并根据测量数据流的传送情况来分析网络的性能。 主动测量在性能参数的测量中应用十分广泛,因为它可以以任何希望的数据类型在所选定的网络端点间进行端到端性能参数的测量。最为常见的主动测量工具就是“Ping”,它可以测量双向时延,IP 包丢失率以及提供其它一些信息,如主机的可达性等。主动测量可以测量端到端的IP 网络可用性、延迟和吞吐量等。因为一次主动测量只是查验了瞬时的网络质量,因此有必要重复多次,用统计的方法获得更准确的数据。 要对一个网络进行主动测量,则需要一个面向网络的测量系统,这种主动测量系统应包括以下几个部分: - 测量节点:它们分布在网络的不同端点上,进行测量数据包的发送和接收,若要进行单向性能的测量,则它们之间应进行严格的时钟同步; - 中心服务器:它与各个测量节点通信,进行整个测量的控制以及测量节点的配置工作; - 中心数据库:存储各个节点所收集的测量数据; - 分析服务器:对中心数据库中的数据进行分析,得到网络整体的或具体节点间的性能状况 在实际中,中心服务器,中心数据库和分析服务器可能位于同一台主机中。 主动测量法依赖于向网络注入测量包,利用这些包测量网络的性能,因此这种方法肯定会产生额外的流量。另一方面,测量中所使用的流量大小以及其他参数都是可调的。主动测量法能够明确地控制测量中所产生的流量的特征,如流量的大小、抽样方法、发包频率、测量包大小和类型(以仿真各种应用)等,并且实际上利用很小的流量就可以获得很有意义的测量结果。主动测量意味着测量可以按测量者的意图进行,容易进行场景的仿真,检验网络是否满足QoS 或SLA 非常简单明了。 总之,主动测量的优点在于可以主动发送测量数据,对测量过程的可控制性比较高,比较灵活机动,并易于对端到端的性能进行直观的统计;其缺点是注入测量流量本身就改变了网络的运行情况,即改变了被测对象本身,使得测量的结果与实际情况存在一定的偏差,而且注入网络的测量流量还可能会增加网络的负担。 2.被动测量是指在链路或设备(如路由器,交换机等)上对网络进行监测,而不需要产生流量的测量方法。 被动测量利用测量设备监视经过它的流量。这些设备可以是专用的,如Sniffer,也可以是嵌入在其它设备(如路由器、防火墙、交换机和主机)之中的,如RMON, SNMP 和netflow 使能设备等。控制者周期性地轮询被动监测设备并采集信息(在SNMP 方式时,从MIB 中采集),以判断网络性能和状态。被动测量主要有三种方式: - 通过SNMP 协议采集网络上的数据信息,并提交至服务器进行处理。 - 在一条指定的链路上进行数据监测,此时数据的采集和分析是两个独立的处理过程。这种方法的问题是OC48(2.5Gbit/s)以上的链路速度超过了 PCI 总线(64bit,33MHz)的能力,因此对这些高速链路的数据采集只能采用数据压缩,聚合等方式,这样会损失一定的准确性。 - 在一台主机上有选择性的进行数据的采集和分析。这种工具只是用来采集分析网络上数据包的内容特性,并不能进行性能参数的测量,如Ethereal 等工具。 被动测量非常适合用来测量和统计链路或设备上的流量,但它并不是一个真正的 QoS 参数,因为流量只是当前网络(设备)上负载情况的一个反映,通过它并不能得到网络实际的性能情况,如果要通过被动测量的方法得到终端用户所关心的时延,丢包,时延抖动等性能参数,只能采用在被测路径的两个端点上同时进行被动测量,并进行数据分析,但这种分析将是十分复杂的,并且由于网络上数据流量特征的不确定性,这种分析在一定程度上也是不够准确的。只有链路带宽这个流量参数可以通过被动测量估算出来。 被动测量法在测量时并不增加网络上的流量,测量的是网络上的实际业务流量,理论上说不会增加网络的负担。但是被动测量设备需要用轮询的方法采集数据、陷阱(trap)和告警(利用SNMP 时),所有这些都会产生网络流量,因此实际测量中产生的流量开销可能并不小。 另外,在做流分析或试图对所有包捕捉信息时,所采集的数据可能会非常大。被动测量的方法在网络排错时特别有价值,但在仿真网络故障或隔离确切的故障位置时其作用会受到限制。 总之,被动测量的优点在于理论上它不产生流量,不会增加网络的负担;其缺点在于被动测量基本上是基于对单个设备的监测,很难对网络端到端的性能进行分析,并且可能实时采集的数据量过大,且存在用户数据泄漏等安全性问题。 3.主动、被动相结合测试 主动测量与被动测量各有其有缺点,而且对于不同的参数来说,主动测量和被动测量也都有其各自的用途。对端到端的时延,丢包,时延变化等参数比较适于进行主动测量;而对于路径吞吐量等流量参数来说,被动测量则更适用。因此,对网络性能进行全面的测量需要主动测量与被动测量相结合,并对两种测量结果进行对比和分析,以获得更为全面科学的结论。 来自百度知道初夏0535

YDYK 2020-03-26 09:42:40 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站