• 关于

    最短时间控制不可用

    的搜索结果

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。
2019-12-01 23:13:03 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。
2019-12-01 23:13:03 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。
2019-12-01 23:13:03 0 浏览量 回答数 0

问题

如何实现创建存储空间?

在上传任何文件到OSS之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台 界面。单击左侧存储空间列表中的新增按钮[...
青衫无名 2019-12-01 21:55:30 1143 浏览量 回答数 0

回答

E-HPC自动化伸缩可以根据您配置的策略动态分配云资源,例如您可以设置根据实时负载自动增加或者减少云资源。E-HPC自动化伸缩可以为您: 减少管理运维集群的人力成本。 保证可用性的前提下,最大限度减少云资源消耗,降低集群成本。 提高容错能力,自动化伸缩自动检测节点状态,停止处于错误状态下的节点,并创建新的节点。 提高可用性,保证集群有充足的云资源。 配置自动伸缩服务 用户创建集群的时候,默认自动伸缩服务是没有启用的,用户如果希望使用的话,可以通过E-HPC控制台做如下配置。 autoscale 功能配置选项 自动化伸缩提供如下配置选项: 是否启动扩容(EnableGrow): 是否启用自动扩容。 扩容时间间隔(GrowIntervalInMinutes): 每轮资源扩展的时间间隔。默认值2分钟,最小值2分钟,最大值10分钟。 扩容超时时间(GrowTimeoutInMinutes): 等待启动节点的超时时间。默认值20分钟,最小值10分钟,最大值60分钟。如果超时时间后,节点依然未达到运行状态,将会把这个节点重置,用于新的扩容。 额外节点百分比(ExtraNodesGrowRatio): 额外扩张节点的百分比,默认值0,最小值0, 最大值100。例如,根据作业负载需要新增100个计算节点,ExtraNodesGrowRatio值为2,那么最终扩展的节点数量是102。场景如下。 一个需要32个节点才能运行的mpi作业,如果将集群扩充至刚好32个节点,若其中一个节点启动失败或者启动过慢,就会导致其他31个节点一直处于空闲状态。但如果配置了额外节点百分比,将集群扩展至35个节点,就会一定程度上降低这种情况发生的概率,而且作业正常运行后,多启动的资源很快会被释放。 此配置在保证可用性的同时,减少了资源的等待浪费,且只增加用户很少的成本(几乎可以忽略)。 扩容比例(根据工作负载)(GrowRatio): 扩展比例(百分比)默认值100,最小值1,最大值100。比如当前根据作业负载需要新增10个计算节点,如果GrowRatio配置为50,就新增5个计算节点。场景如下。 有10个作业需完成,且每个作业只需要运行几分钟。默认自动伸缩会扩容10个节点,每个节点启动初始化都需要几分钟的时间,而节点进入运行状态后,运行作业也是只需要几分钟。这种情况下,有的用户会希望只扩容5个节点,同时运行5个作业,等这5个作业运行结束,再继续在这5个节点上运行剩余的5个作业。 通过这个配置选项,用户可以根据作业类型,运行时间长短对默认自动伸缩进一步优化,提高集群资源利用率。 集群最大计算节点数(MaxNodesInCluster):集群最多可以扩展的节点数量,默认值100,最小值1。 是否启动缩容(EnableShrink):是否启用自动缩容。 缩容时间间隔(ShrinkIntervalInMinutes): 每轮资源收缩的时间间隔,默认2分钟,最小值2分钟,最大值10分钟。 说明:ShrinkInterval必须大于等于GrowInterval,确保空闲节点不被任何作业所需要的前提下,释放节点 节点连续空闲次数(ShrinkIdleTimes): 资源收缩检查时,一个节点连续处于空闲的次数。默认值3,最小值2。最大值5。如果一个计算节点连续空闲超过3次,就会被释放。所以默认配置下,一个资源的连续空闲时间超过6分钟,就会被释放。 例外节点列表(ExcludeNodes): 不使用自动伸缩的节点列表,以半角逗号分割。用户如果希望一直保留一个最小规模的集群,可以使用此配置项。 多队列调度自动伸缩的策略 在多种类型业务和计算的驱动下,您可能需要在一个E-HPC集群里面运行不同类型的作业,而每种类型的作业对资源的需求是不一样的,例如,前处理作业需要普通8核32GiB内存的ECS虚拟机,后端计算性任务需要使用裸金属服务器。E-HPC为您提供了支持多队列部署的功能以及自动伸缩支持多队列的弹性配置策略。 E-HPC支持多队列部署功能如下所示: 扩容的时候支持指定新的实例类型 创建集群和扩容的时候支持加入指定队列,如果队列不存在则会自动创建队列 提交作业的时候支持提交到指定的队列 支持跨AZ扩容和缩容,以解决单个AZ域内资源库存不足的问题 2. 自动伸缩服务支持多队列弹性策略的配置,队列配置说明: 队列名称(QueueName):为集群和节点指定的队列名称。 是否启动扩容(EnableGrow)和缩容(EnableShrink):是否启动队列的自动扩容和缩容。 实例类型(InstanceType):队列目标扩容的类型。 竞价策略(SpotStrategy):扩充的实例需要配置的竞价方式。有三种选择:不使用抢占实例;设置上限价格的抢占实例;系统自动出价,最高按量付费价格。 每小时最高价格(SpotPriceLimit):在竞价策略为“设置上限价格的竞价实例”时,需要设定每小时最高价格区间。 3. 跨AZ自动伸缩,队列配置详细信息 选择自动伸缩页面中需要操作的队列,如low队列,点击最右侧编辑按钮,跳转至如下页面,开始配置: queueconfiguration 配置步骤及说明: 1) 打开启动扩容,启动缩容按钮; 2) 在队列配置栏下选择目标可用区和目标虚拟交换机ID,如果目标可用区没有可用的虚拟交换机,可以点击页面中“创建子网(交换机)”按钮进行创建; 3) 选择目标扩容实例类型,或者可以手动输入;根据实际情况选择竞价策略; 4) 点击“增加”按钮,添加配置信息到配置清单中。 注意:集群在扩容时,按照配置清单中的由上而下的顺序扩容,只有当上一个实例类型库存不存在或者库存不足时才会跳开上一个,开始扩容下一个实例类型。 5)点击左下角“确认”按钮,完成队列信息配置。 使用场景及配置 总的来说,自动伸缩服务适合于不使用包年包月服务的用户,比如: 用户每天集中提交一批作业,使用HPC集群几个小时进行大规模计算, 然后释放资源。 用户不定期的会提交作业,但不是每天24小时满负荷运行的。 针对不同的作业类型,用户可以使用不同的配置项参数,根据自己的HPC集群实际使用情况进行自定义配置。例如批量作业,作业数量大,单作业运行用时短,则用户可以通过配置扩容比例(GrowRatio)来调节扩容的比例。若用户提交1000个作业,每个作业虚使用一个CPU,运行1分钟。则用户可以配置GrowRatio为10,那么就会扩容100个CPU。 使用E-HPC集群运行lammps算例 1)创建集群, 选择安装的软件列表。 软件配置 2)在软件配置界面的高级配置下,指定集群需要加入的队列,如low队列,此时该队列会自动创建。同时,也可以在节点和队列界面单独创建队列,具体操作请参照 节点管理。 3)配置自动伸缩: 启用自动扩容和缩容,启动目标队列的扩容和缩容,完成目标队列的信息配置。(对于pbspro来说,workq是默认队列,会自动创建,当新增加的nodes未指定队列时会默认加入到workq队列) 4)自动伸缩启动之后,如果没有作业运行,几分钟之后,指定队列的计算节点都会被释放。 5)通过控制台创建集群用户,用户组可以是普通权限组或者sodo权限组,本例设置为普通权限组。 6)用户把相应的数据,及程序放到NAS共享存储上。 7)创建并提交作业:用户可通过在线新建编辑,或者OSS文件上传的方式来进行SubmitJob的操作。具体操作流程,请参看 作业管理 模块的描述,进行作业信息配置和作业脚本文件创建。 例如 job.sh 脚本文件里的内容如下,可以看出需要1个计算节点。 job 8)两分钟左右,从控制台可以看到,low队列自动扩容了一个计算节点。 9)几分钟后,计算节点ready,同时可以看到作业开始运行,并运行完成。 在作业运行完毕之后,可以通过控制台看到作业详情。 jobdetail 10)几分钟之后,扩容产生的计算节点被释放。 11)从操作日志可以看到,扩容和缩容的日志记录。其中,第一次缩容(DeleteNode)为集群原来的节点,第二次缩容为提交作业后扩容产生的Node。joblog SGE(SunGridEngine)支持自动伸缩配置 SGE队列如果为空,没有任何计算节点的时候,用户提交作业的时候,会提交失败,或者作业不会被分配到默认队列中。因此如果在SGE集群中使用自动伸缩,可以使用如下的方式之一: 保持队列中至少有一个节点,在自动伸缩配置页面,设置“例外节点列表”包含这个节点这样保证集群至少有一个计算节点, 如果集群需要保持最小规模的话,推荐使用这种方式 添加dummynode到队列中,可以参考以下的设置 以下操作都是在调度节点上执行 1, 在/etc/hosts增加以下记录 127.0.0.1 dummynode0 2,将dummnynode0加入默认节点组 qconf -aattr hostgroup hostlist dummynode0 @allhosts 用户也可以使用类似命令将dummnynode0加入到别的节点组或者队列
1934890530796658 2020-03-23 17:13:25 0 浏览量 回答数 0

回答

优势 云服务器 ECS 拥有传统服务器和虚拟主机无法企及的优势: 稳定性: 服务可用性高达 99.95%,数据可靠性高达 99.9999999%。支持宕机迁移、数据快照备份和回滚、系统性能报警。 容灾备份: 每份数据多份副本,单份损坏可在短时间内快速恢复。 安全性: 支持配置安全组规则、云盾防 DDOS 系统、多用户隔离、防密码破解。 多线接入: 基于边界网关协议(Border Gateway Protocol,BGP)的最优路由算法。BGP 多线机房,全国访问流畅均衡。骨干机房,出口带宽大,独享带宽。 弹性扩容: 10 分钟内可启动或释放 100 台 ECS 实例;支持在线不停机升级带宽;5 分钟内停机升级 CPU 和内存。成本低:无需一次性大投入,按需购买,弹性付费,灵活应对业务变化。 可控性: 作为 ECS 的用户,您拥有超级管理员的权限,能够完全控制 ECS 实例的操作系统,可以通过管理终端自助解决系统问题,并可以进行部署环境、安装软件等操作。 易用性: 丰富的操作系统和应用软件,使用镜像可一键简单部署同一镜像;可在多台 ECS 实例中快速复制环境,轻松扩展;支持自定义镜像、磁盘盘快照批量创建 ECS 实例。 API 接口: 使用 ECS API 调用管理,通过安全组功能对一台或多台 ECS 实例进行访问设置,使开发使用更加方便。 劣势 需要用户有较强的技术背景,且对云计算的使用需要有熟悉和了解的过程。
剑曼红尘 2020-03-18 20:45:28 0 浏览量 回答数 0

问题

用户指南-数据迁移- SQL Server备份数据上云-增量备份 数据上云SQL Server 2012

适用场景 RDS for SQL Server 2012/2016版提供了增量上云功能,将上云期间的业务中断时间控制在分钟级别,大大缩短了业务中断时间。RDS for SQL Server增量数据上云适用于以...
李沃晟 2019-12-01 21:39:45 720 浏览量 回答数 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

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

演讲人:章文嵩博士,阿里集团的高级研究员与副总裁,主要负责基础核心软件研发和云计算产品研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本电子商务基础设施。他也是开放源码及 Linux内...
云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。
景凌凯 2019-12-02 02:05:12 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 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

问题

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

【编者按】时下,传统安全策略显然已无法支撑 DevOps 环境的敏捷需求。那么,对于一个决策者来说,你又该如何实现 DevOps 速度与安全的兼得?本篇译自 Dzone 的一篇运维文章...
忆远0711 2019-12-01 21:56:45 8122 浏览量 回答数 1

回答

虽然跨平台的移动APP开发有利有弊。但从业务初创的角度来看,优点应该是大于缺点的。而且,随着对跨平台移动应用需求的不断增长,现在可用的工具和框架数量也已经很可观了。 但选择过多会令人头疼,这就是为什么我们只关注最突出的跨平台移动开发框架的原因:React Native, Flutter, NativeScript, 和Xamarin。 为了让你更深入地了解是什么使这些工具成为2020年软件开发的可选选项,我们将根据以下标准对它们进行打分:社区支持、基于的编程语言、代码可重用性、性能、界面以及使用它们构建的重要应用程序。 React Native Reaction Native是Facebook于2015年发布的开源、跨平台的应用开发框架。作为2013年举办的一场内部黑客马拉松的产物,它已经成为最受欢迎的原生App开发替代方案之一,拥有2043名GitHub贡献者,获得了超过82900 GitHub标星。不断增长的社区认知度使得找到一支可靠且经验丰富的开发团队来承接你的项目变得相对容易。 Learn Once and Write Anywhere 基于React.JS,React Native利用JavaScript(根据2019年Stack Overflow的调查,JavaScript成为了最受欢迎的编程语言),为Android和iOS用户提供真正原生的应用外观和体验。另外,使该框架脱颖而出的是,如果你需要,React Native允许你使用Java、Objective-C或SWIFT编写部分原生模块来顺利处理复杂的操作,如视频播放或图像编辑。 虽然这些组件不能在不同的平台之间共享,并且需要开发人员做更多的工作,但多达90%的React Native代码是可以重用的。很好地表明该框架的座右铭不是“Write Once, Use Anywhere”,而是“learn once, write anywhere”。 就GUI而言,React Native可以提供接近原生的用户体验,这要归功于它使用了Android和iOS的本地控制器。它还使用带有UI元素的ReactJS库,这有助于加快UI设计过程。在开发移动应用程序时,使此框架值得考虑的另一个原因是,它可用在不丢失应用程序状态的情况下对UI进行更改。 另一个使React Native成为2020年跨平台移动开发框架的首选之一,是因为持续的更新,例如近期的版本 0.60 和 0.61 : 多项辅助功能改进。 更清晰、更人性化的开始屏幕。 快速刷新,融合了实时和热重新加载,从而显著加快了开发进程。 如上的Release Note只是React Native适应不断变化的需求其中一个很小的样本。 2020年值得考虑的第二个框架是Flutter。它在Google I/O 2017上宣布,并于2018年发布,对于跨平台的世界来说,它现在仍然是一个“新人”。但尽管如此,它已经获得了超过80500 GitHub星标和绝大多数工程师将其称为2019年Stack Overflow调查中最受欢迎的三个框架之一,Flutter无疑是一股不可忽视的力量。 Dart是如何使Flutter变得独一无二的 Flutter 背后的编程语言是 Dart,谷歌称之为"客户端优化",适合在任何平台上"快速构建应用程序"。它于 2011 年推出,是一种响应式面向对象的语言,被开发者认为相对容易学习,其中原因有二:第一,语法上它借鉴了C/C++ 和 Java; 第二,在官方网站上,您可以找到内容广泛且相当简单的文档。值得一提的是,Dart 附带了大量Flutter 兼容软件包的软件包,允许您使应用程序更加复杂。 lutter的一个主要优势是,它的性能比本文提到的任何其他跨平台移动开发框架都要好。这归功于Dart的编译器和Flutter拥有自己的一套小部件。结果是它能更快、更直接地与平台直接通信,而不需要JavaScript桥(例如,Reaction Native就是这种情况)。说到小部件:通过Flutter的“UI-as-a-code”方法,它们只用DART编写,这就提高了代码的可重用性。 效率与用户体验和界面密不可分。如前所述,Flutter不依赖于一组原生组件,而是利用可视化、结构化、平台性和交互式小部件进行UI的设计,所有这些都由框架的图形引擎呈现。更重要的是,Flutter留下了很大的定制空间,如果你想要设计一个很完美的UI,它是个很好的选择。 说到Flutter的更新,最新的稳定版本是在12月12日发布的,根据官方发布说明,它合并了来自188个贡献者的近2000个pull。例如,版本1.12.13中包括的改进: 重大的API变动。 新功能,例如SliverOpacity小部件和SliverAnimatedList。 修复了崩溃和性能问题。 Beta版中的Web支持。 这不是一个完整的清单,因为Flutter的目标是让每年发布的四个版本中的每一个版本都能为框架的可用性提升一个台阶。 Flutter是一个年轻的跨平台移动应用程序开发框架,所以它没有像React Native受到众多的大公司青睐也是不足为奇的。然而,这并不意味着它不好,截至2019年12月,它也为阿里巴巴、谷歌广告、Groupon等众多公司和业务所采用。 NativeScript 如果你要开始开发你的产品,“React Native”和“Flutter”绝不是唯一的解决方案。在 2020 年初,适合您的企业的替代框架也可能是 NativeScript。 这个开源框架于2015年3月公开发布,并迅速成为广受欢迎的解决方案。例如,在发布后的短短两个月内,它就获得了3000颗GitHub星标,并在Twitter上吸引了1500多名粉丝的关注。到今天为止,市场上已有超过700个插件可供选择。 在使用NativeScript构建跨平台应用程序时,开发人员首先用JavaScript及其超集TypeScript编写代码。然后,将代码库编译成各自平台原生的编程语言。 另外值得一提的是,使用 NativeScript 的开发人员也可以使用第三方库(CocoaPods 和 Android SDK),而无需包装。 与React Native类似,NativeScript允许访问Android和iOS原生API,这对跨平台应用程序有明显的积极影响。然而,不同之处在于,前者需要构建桥接API,而后者(用Progress首席开发者倡导者TJ VanToll的话说是“将所有iOS和Android API注入JavaScript虚拟机”)。与Facebook框架的另一个相似之处在于代码重用,在这两种情况下都可以达到90%。 Xamarin Xamarin开源框架创建于2011年,这使它成为了这个列表中最“古老“的框架,但直到五年前它被微软收购时,它才获得了发展势头。截至今天,它号称拥有超过6万名贡献者的社区。 从技术上讲,要用Xamarin构建跨平台的移动应用,需要很好地掌握.NET和C#两种技术,前者是使用多种语言(包括C#编程语言)、编辑器和库的开发平台。Xamarin用一组工具补充了上述平台,这些工具有助于构建跨平台应用程序,例如库、编辑器扩展和XAML。第二种技术是C#,这是一种面向对象的编程语言,它被认为比JavaScript学习起来稍难。Xamarin利用这种编程语言编写整个应用程序,从后端到原生API,再到业务逻辑。 Xamarin.Native和Xamarin.Forms Xamarin与其他框架的不同之处在于,它提供了两种编译跨平台移动应用的方式:Xamarin Native(也称为Xamarin.Android/iOS)和Xamarin.Forms。前一种方法优先考虑共享业务逻辑,并通过使用本机接口控件实现近乎本机的性能。 后者侧重于共享代码,而不是业务原理,这一方面会导致代码重用比例增加(使用Xamarin,开发人员可以重用高达96%的C#代码),但另一方面这样会降低代码性能。 您可能已经注意到,跨平台移动应用程序的性能和GUI密切相关,所以如果我说Xamarin构建应用程序的两种方法对界面的最终外观有很大影响,我可能不会感到惊讶。 Xamarin.Android/iOS允许开发人员使用原生控件和布局,而Xamarin.Forms基于标准UI元素,允许从单个API设计应用程序,但如果你需要更完美的原生UI,则可能还不够。 2020年跨平台应用程序开发还值得考虑吗? 不论如何,跨平台确实是一个值得考虑和极具前景的方向,特别是我们上面提到的 “React Native”和“Flutter”。 前者是一个成熟而稳定的框架,利用了最流行的编程语言之一,并拥有成熟的大型开发人员社区。后者是一个快速发展的技术,尽管它比React Native年轻的多,它也已经赢得了世界各地许多开发人员的青睐。 但无论您选择的是“React Native”、“Flutter”还是任何其他框架,跨平台方法都一定会为您节省时间和金钱,同时能为你最大限度地扩大市场覆盖范围。 最后,值不值得考虑,最终还是取决于你的业务目标、预算和时限。 来源;:葡萄城官网
问问小秘 2020-04-15 13:30:17 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。
hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

前言 随着计算机技术和 Internet 的日新月异,视频点播技术因其良好的人机交互性和流媒体传输技术倍受教育、娱乐等行业青睐,而在当前, 云计算平台厂商的产品线不断成熟完善, 如果想要搭建视频点播类应用,告别刀耕火种, 直接上云会扫清硬件采购、 技术等各种障碍,以阿里云为例: image 这是一个非常典型的解决方案, 对象存储 OSS 可以支持海量视频存储,采集上传的视频被转码以适配各种终端,CDN 加速终端设备播放视频的速度。此外还有一些内容安全审查需求, 比如鉴黄、鉴恐等。 而在视频点播解决方案中, 视频转码是最消耗计算力的一个子系统,虽然您可以使用云上专门的转码服务,但在很多情况下,您会选择自己搭建转码服务。比如: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? 您有并发处理大量视频的需求。 您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF。后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF、获取视频或者音频的时长,自己搭建成本更低。 各种格式的音频转换或者各种采样率自定义、音频降噪等功能 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将它们再迁移到 OSS 上。 如果您的视频处理系统有上述需求,或者您期望实现一个 弹性、高可用、低成本、免运维、灵活支持任意处理逻辑 的视频处理系统,那么本文则是您期待的最佳实践方案。 Serverless 自定义音视频处理 在介绍具体方案之前, 先介绍两款产品: 函数计算 :阿里云函数计算是事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码,并提供日志查询、性能监控、报警等功能。 函数工作流:函数工作流(Function Flow,以下简称 FnF)是一个用来协调多个分布式任务执行的全托管云服务。您可以用顺序,分支,并行等方式来编排分布式任务,FnF 会按照设定好的步骤可靠地协调任务执行,跟踪每个任务的状态转换,并在必要时执行用户定义的重试逻辑,以确保工作流顺利完成。 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 函数计算可靠的执行任意逻辑, 逻辑可以是利用 FFmpeg 对视频任何处理操作, 也可以更新视频 meta 数据到数据库等。函数工作流对相应的函数进行编排, 比如第一步的函数是转码, 第二步的函数是转码成功后,将相应 meta 数据库写入数据库等。 至此,您应该初步理解了函数计算的自定义处理能力 + 函数工作流编排能力几乎满足您任何自定义处理的需求,接下来,本文以一个具体的示例展示基于函数计算和函数工作流打造的一个弹性高可用的 Serverless 视频处理系统,并与传统方案进行性能、成本和工程效率的对比。 Simple 视频处理系统 假设您是对视频进行单纯的处理, 架构方案图如下: image 如上图所示, 用户上传一个视频到 OSS, OSS 触发器自动触发函数执行, 函数调用 FFmpeg 进行视频转码, 并且将转码后的视频保存回 OSS。 OSS 事件触发器, 阿里云对象存储和函数计算无缝集成。您可以为各种类型的事件设置处理函数,当 OSS 系统捕获到指定类型的事件后,会自动调用函数处理。例如,您可以设置函数来处理 PutObject 事件,当您调用 OSS PutObject API 上传视频到 OSS 后,相关联的函数会自动触发来处理该视频。 Simple 视频处理系统示例工程地址 强大的监控系统: 您可以直接基于示例工程部署您的 Simple 音视频处理系统服务, 但是当您想要处理超大视频(比如 test_huge.mov ) 或者对小视频进行多种组合操作的时候, 您会发现函数会执行失败,原因是函数计算的执行环境有最大执行时间为 10 分钟的限制,如果最大的 10 分钟不能满足您的需求, 您可以选择: 对视频进行分片 -> 转码 -> 合成处理, 详情参考:fc-fnf-video-processing, 下文会详细介绍; 联系函数计算团队(钉钉群号: 11721331) 或者提工单: 适当放宽执行时长限制; 申请使用更高的函数内存 12G(8vCPU) 为了突破函数计算执行环境的限制(或者说加快大视频的转码速度), 进行各种复杂的组合操作, 此时引入函数工作流 FnF 去编排函数实现一个功能强大的视频处理工作流系统是一个很好的方案。 视频处理工作流系统 image 如上图所示, 假设用户上传一个 mov 格式的视频到 OSS,OSS 触发器自动触发函数执行, 函数调用 FnF,会同时进行 1 种或者多种格式的转码(由您触发的函数环境变量DST_FORMATS 参数控制)。 所以您可以实现如下需求: 一个视频文件可以同时被转码成各种格式以及其他各种自定义处理,比如增加水印处理或者在 after-process 更新信息到数据库等。 当有多个文件同时上传到 OSS,函数计算会自动伸缩, 并行处理多个文件, 同时每次文件转码成多种格式也是并行。 结合 NAS + 视频切片, 可以解决超大视频(大于 3G )的转码, 对于每一个视频,先进行切片处理,然后并行转码切片,最后合成,通过设置合理的切片时间,可以大大加速较大视频的转码速度。 所谓的视频切片,是将视频流按指定的时间间隔,切分成一系列分片文件,并生成一个索引文件记录分片文件的信息 视频处理工作流系统示例工程地址 示例效果: gif 函数计算 + 函数工作流 Serverless 方案 VS 传统方案 卓越的工程效率 自建服务 函数计算 + 函数工作流 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 并行&分布式视频处理 需要很强的开发能力和完善的监控系统来保证稳定性 通过 FnF 资源编排即可实现多个视频的并行处理以及单个大视频的分布式处理,稳定性和监控交由云平台 学习上手成本 除了编程语言开发能力和熟悉 FFmpeg 以外,可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码和熟悉 FFmpeg 使用即可 项目上线周期 在具体业务逻辑外耗费大量的时间和人力成本,保守估计大约 30 人天,包括硬件采购、软件和环境配置、系统开发、测试、监控报警、灰度发布系统等 预计 3 人天, 开发调试(2人天)+ 压测观察(1 人天) 弹性伸缩免运维,性能优异 自建服务 函数计算 + 函数工作流 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维,视频处理工作流系统 (FnF + FC) 压测;性能优异, 详情见下面的转码性能表 监控报警查询 ECS 或者容器级别的 metrics 提供更细粒度的 FnF 流程执行以及函数执行情况, 同时可以查询每次函数执行的 latency 和日志等, 更加完善的报警监控机制 函数计算 + 函数工作流 Serverless 方案转码性能表 实验视频为是 89s 的 mov 文件 4K 视频: 4K.mov,云服务进行 mov -> mp4 普通转码需要消耗的时间为 188s, 将这个参考时间记为 T 视频切片时间 FC转码耗时 性能加速百分比 45s 160s 117.5% 25s 100s 188% 15s 70s 268.6% 10s 45s 417.8% 5s 35s 537.1% 性能加速百分比 = T / FC转码耗时 从上表可以看出,设置的视频切片时间越短, 视频转码时间越短, 函数计算可以自动瞬时调度出更多的计算资源来一起完成这个视频的转码, 转码性能优异。 更低的成本 具有明显波峰波谷的视频处理场景(比如只有部分时间段有视频处理请求,其他时间很少甚至没有视频处理请求),选择按需付费,只需为实际使用的计算资源付费。 没有明显波峰波谷的视频处理场景,可以使用预付费(包年包月),成本仍然具有竞争力。 函数计算成本优化最佳实践文档。 假设有一个基于 ECS 搭建的视频转码服务,由于是 CPU 密集型计算, 因此在这里将平均 CPU 利用率作为核心参考指标对评估成本,以一个月为周期,10 台 C5 ECS 的总计算力为例, 总的计算量约为 30% 场景下, 两个解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元 函数计算按量付费占整个计算量的占比 <= 10%,费用约为 3×864×10% = 259.2 元,(3G 规格的函数满负载跑满一个月费用为:0.00011108×3×30×24×3600 = 863.8,详情查看计费) ITEM 平均CPU利用率 计算费用 总计 函数计算组合付费 >=80% 998(246.27×3+259.2) <= 998 按峰值预留ECS <=30% 2190(10*219) >=2190 在这个模型预估里面,可以看出 FC 方案具有很强的成本竞争力,在实际场景中, 基于 ECS 自建的视频转码服务 CPU 利用甚至很难达到 20%, 理由如下: 可能只有部分时间段有视频转码请求 为了用户体验,视频转码速度有一定的要求,可能一个视频转码就需要 10 台 ECS 并行处理来转码, 因此只能预备很多 ECS 因此,在实际场景中, FC 在视频处理上的成本竞争力远强于上述模型。 即使和云厂商视频转码服务单价 PK, 该方案仍有很强的成本竞争力 我们这边选用点播视频中最常用的两个格式(mp4、flv)之间进行相互转换,经实验验证, 函数内存设置为3G,基于该方案从 mp4 转码为 flv 的费用概览表: 实验视频为是 89s 的 mp4 和 flv 格式的文件视频, 测试视频地址: 480P.mp4 720P.mp4 1080P.mp4 4K.mp4 480P.flv 720P.flv 1080P.flv 4K.flv 测试命令: ffmpeg -i test.flv test.mp4 和 ffmpeg -i test.flv test.mp4 mp4 转 flv: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 889 kb/s 24 11.2s 0.003732288 0.032 88.3% 高清 1280720 1963 kb/s 24 20.5s 0.00683142 0.065 89.5% 超清 19201080 3689 kb/s 24 40s 0.0133296 0.126 89.4% 4K 38402160 11185 kb/s 24 142s 0.04732008 0.556 91.5% flv 转 mp4: 分辨率 bitrate 帧率 FC 转码耗费时间 FC 转码费用 某云视频处理费用 成本下降百分比 标清 640480 712 kb/s 24 34.5s 0.01149678 0.032 64.1% 高清 1280720 1806 kb/s 24 100.3s 0.033424 0.065 48.6% 超清 19201080 3911 kb/s 24 226.4s 0.0754455 0.126 40.1% 4K 38402160 15109 kb/s 24 912s 0.30391488 0.556 45.3% 成本下降百分比 = (某云视频处理费用 - FC 转码费用)/ 云视频处理费用 某云视频处理,计费使用普通转码,转码时长不足一分钟,按照一分钟计算,这里计费采用的是 2 min,即使采用 1.5 min 计算, 成本下降百分比基本在10%以内浮动 从上表可以看出, 基于函数计算 + 函数工作流的方案在计算资源成本上对于计算复杂度较高的 flv 转 mp4 还是计算复杂度较低的 mp4 转 flv, 都具有很强的成本竞争力。 根据实际经验, 往往成本下降比上表列出来的更加明显, 理由如下: 测试视频的码率较高, 实际上很多场景绝大部分都是标清或者流畅视频的转码场景, 码率也比测试视频低,这个时候计算量变小, FC 执行时间短, 费用会降低, 但是通用的云转码服务计费是不变的. 很多视频分辨率在通用的云转码服务是计费是有很大损失的, 比如转码的视频是 856480 或者 1368768, 都会进入云转码服务的下一档计费单价, 比如856480 进入 1280720 高清转码计费档,1368768 进入 19201080 超清转码计费档, 单价基本是跨越式上升, 但是实际真正的计算量增加可能还不到30%, 而函数计算则是真正能做到按计算量付费. 操作部署 免费开通函数计算,按量付费,函数计算有很大的免费额度。 免费开通函数工作流,按量付费,函数工作流有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 详情见各自示例工程的 README Simple 视频处理系统示例工程地址 视频处理工作流系统示例工程地址 总结 基于函数计算 FC 和函数工作流 FnF 的弹性高可用视频处理系统天然继承了这两个产品的优点: 无需采购和管理服务器等基础设施,只需专注视频处理业务逻辑的开发,大幅缩短项目交付时间和人力成本 提供日志查询、性能监控、报警等功能快速排查故障 以事件驱动的方式触发响应用户请求 免运维,毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,性能优异 成本极具竞争力 相比于通用的转码处理服务: 超强自定义,对用户透明, 基于 FFmpeg 或者其他音视频处理工具命令快速开发相应的音视频处理逻辑 原有基于 FFmpeg 自建的音视频处理服务可以一键迁移 弹性更强, 可以保证有充足的计算资源为转码服务,比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完 各种格式的音频转换或者各种采样率自定义、音频降噪等功能, 比如专业音频处理工具 aacgain 和 mp3gain 可以和 serverless 工作流完成更加复杂、自定义的任务编排,比如视频转码完成后,记录转码详情到数据库,同时自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力 更多的方式的事件驱动, 比如可以选择 OSS 自动触发(丰富的触发规则), 也可以根据业务选择 MNS 消息(支持 tag 过滤)触发 在大部分场景下具有很强的成本竞争力相比于其他自建服务: 毫秒级弹性伸缩,弹性能力超强,支持大规模资源调用,可弹性支持几万核.小时的计算力,比如 1 万节课半个小时完成转码 只需要专注业务逻辑代码即可,原生自带事件驱动模式,简化开发编程模型,同时可以达到消息(即音视频任务)处理的优先级,可大大提高开发运维效率 函数计算采用 3AZ 部署, 安全性高,计算资源也是多 AZ 获取, 能保证每个用户需要的算力峰值 开箱即用的监控系统, 如上面 gif 动图所示,可以多维度监控函数的执行情况,根据监控快速定位问题,同时给用户提供分析能力, 比如视频的格式分布, size 分布等 在大部分场景下具有很强的成本竞争力, 因为在函数计算是真正的按量付费(计费粒度在百毫秒), 可以理解为 CPU 的利用率为 100% 最后一一回答一下之前列出的问题: Q1: 您已经在虚拟机/容器平台上基于 FFmpeg 部署了一套视频处理服务,能否在此基础上让它更弹性,更高的可用性? A: 如工程示例所示,在虚拟机/容器平台上基于 FFmpeg 的服务可以轻松切换到函数计算, FFmpeg 相关命令可以直接移值到函数计算,改造成本较低, 同时天然继承了函数计算弹性高可用性特性。 Q2:您的需求只是简单的转码需求,或是一些极其轻量的需求,比如获取 OSS 上视频前几帧的 GIF 等。 自己搭建成本更低。 A: 函数计算天生就是解决这些自定义问题, 你的代码你做主, 代码中快速执行几个 FFmpeg 的命令即可完成需求。典型示例: fc-oss-ffmpeg Q3: 您有更高级的自定义处理需求,比如视频转码完成后, 需要记录转码详情到数据库, 或者在转码完成后, 自动将热度很高的视频预热到 CDN 上, 从而缓解源站压力。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案),after-process 中可以做一些自定义的操作, 您还可以基于此流程再做一些额外处理等, 比如: 再增加后续流程 最开始增加 pre-process Q4: 您有并发同时处理大量视频的需求。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), 当有多个文件同时上传到 OSS, 函数计算会自动伸缩, 并行处理多个文件。详情可以参考 视频处理工作流系统 (FnF + FC) 压测 Q5:您有很多超大的视频需要批量快速处理完, 比如每周五定期产生几百个 4G 以上的 1080P 大视频, 但是希望当天几个小时后全部处理完。A: 详情可以参考视频处理工作流系统 (FnF + FC) 压测, 可以通过控制分片的大小, 可以使得每个大视频都有足够多的计算资源参与转码计算, 大大提高转码速度。 Q6: 自定义视频处理流程中可能会有多种操作组合, 比如转码、加水印和生成视频首页 GIF,后续为视频处理系统增加新需求,比如调整转码参数,希望新功能发布上线对在线服务无影响。 A: 详情见视频处理工作流系统(函数计算 + 函数工作流方案), FnF 只负责编排调用函数, 因此只需要更新相应的处理函数即可,同时函数有 version 和 alias 功能, 更好地控制灰度上线, 函数计算版本管理 Q7: 您的视频源文件存放在 NAS 或者 ECS 云盘上,自建服务可以直接读取源文件处理,而不需要将他们再迁移到 OSS 上。 A: 函数计算可以挂载 NAS, 直接对 NAS 中的文件进行处理
1934890530796658 2020-03-27 18:21:36 0 浏览量 回答数 0

回答

关于域的重命名也是很多网络管理人员近几年遇到的比较多的一个现象,往往是由于公司内部或外部的一些原因而导致公司的名称发生变化,那么公司的域名也要发生相应的变化,但是由于域构架的特殊性,所以对域进行重命名可不像对修改计算机的主机名这么简单,那么接下来我将为大家详细说一下域的重命名的操作流程。 * Z; B! p1 U. l2 q   先给大家罗列一下实验环境: 1 E9 E* o3 b& ]' e9 x, n+ S2 Q  原域域名:demo.com 6 u+ b0 S9 X, Q8 r3 k9 n  域控制器:server.demo.com# \8 e- O- Z. S$ F( j$ j) ~) H   IP:192.168.5.1 # U: N( d" [% A5 N0 F2 A0 }- e" x  子网掩码:255.255.255.0 $ E' k7 ?3 A* l; r" o. q3 _  DNS:192.168.5.17 w- e$ c1 Z9 x+ X2 Q) E% P1 X   其中还有一台域外额控制器,名为:test20031.demo.com,一个子域:test.demo.com * a8 M$ }/ ~! , L  实验目的:把demo.com重命名为try.com 9 J4 n0 } ?8 4 W* B  一、前提条件:& d2 C- e3 |, M   1、 所有的域控制器必须全部是Windows Server 2003,这是一个必备条件,因为Windows 2000域并不支持域重命名。如果你是Windows 2000域的话,那么你只能用ADMT进行活动目录迁移,具体操作请参见我的上一篇文章。 ! u) p, W6 {7 D% ?  2、 由于域的重命名操作并不是在域控制器上完成的,(这一点出乎很多人的意料之外吧),所以除了域控制器外,还要有一台装着Windows Server 2003的成员服务器,而且必须已经加入到该域。本实验环境中这台计算机的配置如下:) }; c. n8 d$ n& Z' Z( ]) S* E7 K   计算机名:ren2003.demo.com 2 K$ G+ E9 O- E! @4 c6 _. |3 W1 O  IP:192.168.5.6, V/ r, G$ ^7 v' s: I   子网掩码:255.255.255.0 - K' O7 O% T' l2 R- n4 Q  DNS:192.168.5.13 z V7 f: p5 t! o0 k   二、准备工作:, N5 t$ K. K: W   1、 在进行域的重命名操作以前,请一定要用Ntbackup工具备份现在所有域控制器的系统状态数据数据,以防万一。我在前面的文章——“活动目录之备份与恢复”上已经详细讲过了,这里就不重复了。 : C K, c+ L7 U0 B3 W; P0 S6 s& c) C- A 7 u; a) @0 x. z0 y, V   2、 要进行域的重命名操作,所有的域控制器一定要是Windows Server 2003,并且提升域和森林的功能级别到Windows 2003纯模式,因为默认是Windows 2000混合模式;关于提升域功能级别我已要在“活动目录之迁移”是提到了,这里我只是提一下提升森林的功能级别:, ^+ q5 F- C- _2 Y: A* Z   点击“开始-设置-控制面板-管理工具-Active Directory域和信任关系”: $ C$ k g/ m$ o; {& M 3 z% [5 L" d4 G1 u) _+ j   在“Active Directory域和信任关系”上击右键:8 J% U& \+ N r+ I7 l, H$ L 8 l" K) t2 @+ n& G Q$ ~  选择“提升林功能级别”:$ H; F- }$ }2 T7 a# P % C! W! n8 U6 u s   点击“提升”就可以了,只是这个操作也是不可逆的。之前一定要保证域级别在Windows Server 2003,包括子域的域级别哟!) E$ ?8 g6 ]: Q) d% d$ E+ F   提升完成后,大家要注意复制的时间,最好等一会,至于具体要等多久就要取决于你的网络规模大小了。: R8 V: ?7 T9 j3 M0 N3 L   3、新建一个新的DNS区域,域名要和新建域的域名一致;( ?9 y. E5 g/ @2 ?   点击“开始-设置-控制面板-管理工具-DNS”:" m3 d; x% _3 F7 _" \7 e+ ~1 I * o: a: R2 ]8 U7 G$ i% m  在“正向查找区域”上击右键: ' |/ E5 Q+0 }* c) E2 q) H) X% X & V* V6 d6 a: O$ c! [  选择“新建区域”: - ~7 M: a% v6 O# R9 T4 M* } * g+ R5 s4 v* U( s  点“下一步”: 8 Z& m8 k3 L u/ Y: B  选“主要区域”,其它保持默认,点“下一步”: ( P, K4 z' c8 Z* o8 g* r 6 m! b# k/ x: i7 t, t. x8 h   选“至Active Directory林demo.com中的所有域控制器”,然后点“下一步”:3 y" O, Y" [; [2 i, {2 u p; P/ P$ u<br>& p& F; w1 U8 Y( j( M2 T9 ]4 g0 j<br>  这里要输入新域的域名,实验中是“try.com”,继续“下一步”:6 ]& ?# v- Z% F: T) S9 |. @# m<br><br>$ R2 j4 y4 3 d0 i* H# ]  点“下一步”:7 d% G6 i6 ]0 C5 f<br><br>' S/ T: J9 t* G H* \  确认没有问题后点“完成”:<br>) f& |' w" \: j7 ~$ q# F0 T <br>' O v4 d/ B& K' u& \  建立完成。<br>, z5 X8 S# U( S- ?6 x<br>0 Q& I+ r,' a0 b+ ! s 三、重命名操作; <br>9 }' p; }+ X; Z/ ?4 Q  1、在成员服务器上获得重命名工具。4 Q4 F" g3 w" j   在默认情况下,重命名工具并不会被安装,所以我们要到安装光盘中去获得这个工具,在x:\valueadd\msft\mgmt\domren,(X表示安装盘所在的光驱盘符): ) c$ f( F4 K& I' T/ _ $ G. n; X. b6 B1 Y2 h& |, _   两个工具的名称分别是rendom.exe和gpfixup.exe,其中rendom是我们用以的主要工具,gpfixup是用来修复组策略的。还有一篇readme文档,英文不错的朋友可以看一下。把这两个工具拷到硬盘上,实验中,我拷到了C盘。 . j; _$ e: ~4 v8 O4 z  2、点击“开始-运行”,输入:cmd,回车,在出来的命令提示符下把当前目录切换到C盘根目录下:/ J2 n/ u; u6 C/ ? ( f8 T. w# T4 H+ A8 ^: s8 ^   输入:rendom /list,回车: * t7 B" p' T9 z% V; L/ | 3 k8 q7 p4 y. R) k   运行成功后在该工具的文件夹下会产生一个名为domainlist.xml文件,实验中就是C盘根目录下;5 t5 H, S; l% t) w5 t2 J$ y7 L, ^1 w 6 A) f0 c. [8 r/ t) G# h   我们打开一下这个文件看一下,里面是些什么内容: 2 h# \: V9 ~0 \5 A) n. K8 X8 U/ t; \ 8 {1 @& U( C) x6 f$ Y  3、 用记事本修改domainlist.xml文件,把里面的demo.com,全部换成try.com<br>" _9 M4 G K4 Y$ M2 R. _ }- F: ~# E! W- l5   修改完成后保存退出:0 {/ [' Q- y/ b ; K6 A( A$ ?/ {4 w  4、 再点击“开始-运行”,输入“cmd”回车,并切换到C盘根目录下,然后再输入:rendom /upload,然后回车:; k7 c) t) e8 N3 y<br>- _/ l, t0 p& E% R. o. @8 V/ l Q<br>  执行成功后,会产生一个dclist.xml文件,该文件相当于一个日志文件,会纪录重命名过程中的状态,这是这个文件的内容:<br>! p1 C+ v$ A; {/ X) ~. y 4 }4 k& E$ @# Q3 f   并且此时森林被冻结,也就是说这个时候,域已经不可用了;7 P- _* I; G+ K6 P& v2 a   5、继续在命名提示符下运行rendom /prepare,此步骤主要是校验DC是否全部准备完成;: I7 G, f4 W9 ~8 _ & ( p: D( S9 A% ]4 k3 L  以上图表示准备完成。 - e# b( e- d5 b$ Z5 r- ' |  6、如果上述步骤中出现失误,比如发现新域名书写错误等,可以运行rendom /end,可以取消前面第2步开始的操作,并同时解除森林的冻结状态;) h& L& v& N( m7 V8 i   7、如果没有问题的话,那么此时在命令提示符下执行:rendom /execute。+ [7 F; ]) Q7 A/ V, H- z9 } - _1 a8 X* P9 g+ G  执行成功后,会发现所有的域控制器全部自动重启。重启后,登陆界面会发生变化:3 [" S- o( v0 D( @5 t4 w; V& x. N ; e4 }8 u* g/ G; B, B   看到了吧?原来的“demo”不见了,换成了“try”。 * o9 K9 I3 r6 A& h6 b ~  8、重新命名域控制器的DNS后缀。 / s' W3 N% s! @,! a, q# Y1 Q  进入系统后,你会发现,虽然域名已经换了,但域控制器的DNS名却并没有发生改变,如下图: ' x* G& X( @6 g2 W / c" e4 _% A6 a0 {/ V4 M8 R; @  所以我们要点击上面的“更改”按钮:8 j3 {& u* q8 R0 D! P! N* d* S. y & e3 P4 d6 l r5 c: M1 f; K   点“确定”: 2 L! g; [0 b( b. U6 m / s) S* l+ {5 Y  点“其它”:<br>) ]( p$ S {& O4 O { <br>0 b7 ?) t2 P$ b/ F  把上面的“demo.com”换成“try.com”,然后再点“确定”,系统会要求重启,重启后的域控制器的DNS名字就会换掉了:<br>$ {$ s0 a, Z% d$ C: r7 y5 t e; L <br>- Q& i9 D0 }0 $ J  相同的操作在所有的域控制器上做一次,包括子域上的域控制器。7 l' B& {: S- U* R$ d& ~* A' b- |4 ]   9、客户端的操作。 , l' t5 K& R2 V) Z- u( i2 K  客户端上不用做其它的额外操作,只要把客户端重启。重启会可以看到如下界面: * |- L( 3 n$ |, R 0 S6 [! V/ l& O8 C!8 ]/ s  奇怪,怎么还是“demo”?为什么不是“try”?别急,再重启一下:5 l$ u/ y1 e" P) V0 r0 d4 e : D' j , q a+ W. m& X  “try”出来了吧? : T* P4 ?& A2 j9 I  10、清除AD中的老域名。 $ z7 n( X3 l$ h* J  转到成员服务器,点击“开始-运行”,输入cmd,回车,并切换到C盘根目录下,然后再输入:rendom /clean,回车: ! ?" r" {' c* b- }3 I $ K4 t! a9 o6 b/ L3 B8 a/ E/ [0 [' t  出现上图表示清除成功! + M" C/ M2 E# L o4 {2 v  11、组策略的修复。<br>( r/ b+ ~/ e! t% c  截止到第10步,其实整个域的重命名操作算是完成了,但是我们还有一个后续工作要做,就是修复组策略,大家可以此时去运行一下组策略,我想大部份的网络管理员都会得到如下画面:<br>! ?8 g1 z4 k; x8 <br>$ T' |- " U- d7 u4 S; ~  发现组策略根本不可用,OK,那我们来修复它,还记得文章刚刚开始的时候,我提到的两个工具吗?其中一个是用到现在的rendom,另一个就是用来修复组策略的gpfixup。现在转到成员服务器上,点击“开始-运行”,输入cmd,回车,并切换到C盘根目录下,然后再输入:gpfixup /olddns:demo.com /newdns:try.com /oldnb:demo /newnb:try /dc:try.com,回车:9 L1 D, x: m/ i; q$ X<br># u+ }7 Z7 K. H5 t   运行成功后,再到域控上去执行一下组策略:2 e* M% h4 b. P4 ? & : Q3 J5 s" j. o2 v* o$ P  看到了吧,组策略已经可以成功执行了。 $ Z, M% o" ?; q4 ^& u ' H* K# j. w* ^, v+ Z" h   到此为止,整个操作全部完成了。 2 - v' i7 }# C% H1 H  四、注意事项。3 I2 W8 G$ n/ {   1、如果森林中有Exchange 2000或2003请不要进行域的重命名,因为一旦进行重命名操作,Exchang将会停止工作。这一点请大家一定要注意!0 z3 $ S ^, @* f9 P( l4 L% |   2、森林在短时间内停止工作,具体时间取决于域控制器的多少和你的网络规模。 0 {6 \7 c7 U# U8 T  3、域的重命名操作要么所有的域控制器完成重命名,要么就从森林里彻底的消失。. {! d6 l d) j   4、在域的重命名操作中,不能添加或删除域控制器,也不能进行新的域信任关系的建立。. R) Z O; _; D 答案来源于网络
养狐狸的猫 2019-12-02 02:17:47 0 浏览量 回答数 0

回答

Re:Re【第二期】10月9日周四ECS产品经理ECS网络与运维技术分享答疑 引用第14楼hongxing于2014-10-06 17:01发表的 Re【第二期】10月9日周四ECS产品经理ECS网络与运维技术分享答疑 : 香港ECS何时有镜像,香港ECS何时不再绕道小日本,而是直连 感谢您的问题! 香港的镜像市场计划在12月份推出。 香港地域,主要是面向东南亚等海外客户,到国内的链路,主要依赖国际运营商的路由调度。短时间内,还没有太好的优化方案 ------------------------- Re:Re【第二期】10月9日周四ECS产品经理ECS网络与运维技术分享答疑 引用第16楼at6569s2r于2014-10-09 09:38发表的 Re【第二期】10月9日周四ECS产品经理ECS网络与运维技术分享答疑 : 目前对于ecs云服务器宕机,阿里云目前优化措施和未来的优化措施是什么? 非常感谢您的问题,给了我这个机会和大家说说这个热点话题。 ECS云服务器宕机,从原因上可以分为硬件原因引起的宕机和Guest操作系统原因引起的宕机。 我理解您关心的主要是硬件原因引起的宕机。这部分,作为一个公有云平台是无法回避的,同时也一直是用户关心的热点,借这个机会和大家交流下。 针对硬件故障引起的宕机,我们通过如下几个手段来控制和减少: 1,收集所有硬件宕机的数据,通过数据挖掘的手段进行分析,重点改进和优化驱动/硬件Bug等引起的宕机。减少可避免的宕机。 2,制定一振出局的策略。对于发生过宕机的服务器,自动从集群中摘除,进入buffer区。进行维修和排查。避免单台物理机多次故障而重复伤害客户。 3,阿里云是一个已经运营超过3年的云平台,硬件设备寿命增大而带来的不稳定,是我们无法回避的问题。针对这部分设备,我们正在考虑提供硬件替换功能,为用户更换更好更稳定的硬件设备。 4,加强硬件监控,对有隐患的硬件,通知用户进行迁移。将意外不可控的宕机转化为主动可控的迁移维护。 长期看,我们希望继续探索对硬件故障进行分析挖掘,尝试进行故障预测,并结合热迁移计划,进一步减少硬件故障对用户服务连续性的影响。 最后,从一个技术人员的角度,想对大家说,硬件故障,是一个无法回避的问题。我们能做的,更多是降低概率,但100%消灭,是不可能的。对服务连续性比较在意的用户,建议结合应用架构的高可用,这样才能够最大限度的保证您服务的可靠。 ------------------------- Re:Re【第二期】10月9日周四ECS产品经理ECS网络 引用第9楼老大的老大于2014-09-29 16:40发表的 Re【第二期】10月9日周四ECS产品经理ECS网络 : 磁盘原地扩容和支持卸载到底什么时候才能实现,这个功能非常重要。 这两个功能,确实呼声非常高,计划在12月份支持。
ECS-产品PD 2019-12-02 00:33:18 0 浏览量 回答数 0

问题

【教程免费下载】Redis开发与运维

前  言 Redis作为基于键值对的NoSQL数据库,具有高性能、丰富的数据结构、持久化、高可用、分布式等特性,同时Redis本身非常稳定,已经得到业界的广泛认可和使用。掌握Redis已经逐步成为...
知与谁同 2019-12-01 22:07:46 2741 浏览量 回答数 2

问题

该来的终于来了:“第一起”基于 IPv6 的 DDoS 攻击

作者介绍 杨彪,蚂蚁金服技术专家,《分布式服务架构:原理、设计与实战》和《可伸缩服务架构:框架与中间件》作者。近10年互联网和游戏行业工作经验,曾在酷我音乐盒、人人游戏...
驻云科技 2019-12-01 21:44:35 4186 浏览量 回答数 1

问题

【阿里云产品公测】以开发者角度看ACE服务『ACE应用构建指南』

评测介绍 评测产品: 云引擎ACE服务开发语言: PHP评测人: mr_wid评测时间: 2014年10月13日-19日 评测概要 非常有幸能够申请到ACE的公测资格, 在本篇评测中, 笔者将以一个开发者的角度来对云引擎...
mr_wid 2019-12-01 21:10:06 20092 浏览量 回答数 6

回答

92题 一般来说,建立INDEX有以下益处:提高查询效率;建立唯一索引以保证数据的唯一性;设计INDEX避免排序。 缺点,INDEX的维护有以下开销:叶节点的‘分裂’消耗;INSERT、DELETE和UPDATE操作在INDEX上的维护开销;有存储要求;其他日常维护的消耗:对恢复的影响,重组的影响。 需要建立索引的情况:为了建立分区数据库的PATITION INDEX必须建立; 为了保证数据约束性需要而建立的INDEX必须建立; 为了提高查询效率,则考虑建立(是否建立要考虑相关性能及维护开销); 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用:加快查询速度。原则:(1) 如果某属性或属性组经常出现在查询条件中,考虑为该属性或属性组建立索引;(2) 如果某个属性常作为最大值和最小值等聚集函数的参数,考虑为该属性建立索引;(3) 如果某属性经常出现在连接操作的连接条件中,考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像,对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言,快照能保证系统的完整性。 89题 游标用于定位结果集的行,通过判断全局变量@@FETCH_STATUS可以判断是否到了最后,通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前,而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行,而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引,叫做联合索引。在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引。具体原因为:MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句,在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句,所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程,不由用户直接调用。创建触发器时会对其进行定义,以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合,涉及特定表或其它对象的任务,用户可以调用存储过程,而函数通常是数据库已定义的方法,它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接,减少复杂 SQL,拆分成简单SQL。减少排序:非必要不排序,利用索引排序,减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or,使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤:选择更优的索引,先分页再Join…。避免类型转换:索引失效。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL。从全局出发优化,而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or,即使其中有条件带索引也不会使用(要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引)。对于多列索引,不是使用的第一部分,则不会使用索引。like查询是以%开头。如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引。如果mysql估计使用全表扫描要比使用索引快,则不使用索引。例如,使用<>、not in 、not exist,对于这三种情况大多数情况下认为结果集很大,MySQL就有可能不使用索引。 81题 主键不能重复,不能为空,唯一键不能重复,可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键,但可以有很多唯一键。 80题 空值('')是不占用空间的,判断空字符用=''或者<>''来进行处理。NULL值是未知的,且占用空间,不走索引;判断 NULL 用 IS NULL 或者 is not null ,SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0;它们是不等价的。无法使用比较运算符来测试 NULL 值,比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较,该符号与等号作用相似,但对NULL有意义。进行 count ()统计某列的记录数的时候,如果采用的 NULL 值,会被系统自动忽略掉,但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表,他使用保存在内存中的散列索引。一旦服务器重启,所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=,<,>,=>,= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字,可以输入带有单引号的十六进制数字和前缀(X),或者只用(Ox)前缀输入十六进制数字。如果表达式上下文是字符串,则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问,权限表存放在mysql数据库里,由mysql_install_db脚本初始化。这些权限表分别user,db,table_priv,columns_priv和host。 76题 在缺省模式下,MYSQL是autocommit模式的,所有的数据库更新操作都会即时提交,所以在缺省情况下,mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话,你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式,在非autocommit模式下,你必须使用COMMIT来提交你的更改,或者用ROLLBACK来回滚你的更改。 75题 它会停止递增,任何进一步的插入都将产生错误,因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引,由于使用b+tree做为索引,以innodb为例,一个树节点的大小由“innodb_page_size”,为了减少树的高度,同时让一个节点能存放更多的值,索引列尽量在整数类型上创建,如果必须使用字符类型,也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读。垂直分区: 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,自定义一个注解,用于做切面。针对注解进行切面,设置最大重试次数n,然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞,是通过innodb的行多版本实现的,行多版本并不是实际存储多个版本记录而是通过undo实现(undo日志用来记录数据修改前的版本,回滚时会用到,用来保证事务的原子性)。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎:尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);哈希索引也不支持多列联合索引的最左匹配规则;B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单,一般优先考虑,但float存储的数据范围大,所以范围大的数据就只能用它了,但要注意一些处理细节,因为不精确可能会与自己想的不一致,也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒,datetime与时区无关,存储的范围广(1001-9999),timestamp与时区有关,存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储,char(4)存储4个字符,根据编码方式的不同占用不同的字节,gbk编码方式,不论是中文还是英文,每个字符占用2个字节的空间,utf8编码方式,每个字符占用3个字节的空间。Varchar保存可变长度的字符串,使用额外的一个或两个字节存储字符串长度,varchar(10),除了需要存储10个字符,还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格,char会自动去掉空格后存储,varchar虽然不会去掉空格,但在进行字符串比较时,会去掉空格进行比较。Varbinary保存变长的字符串,后面不会补\0。 65题 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。分析语句的执行计划,然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解:存储过程可以说是一个记录集,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码块取一个名字,在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块,执行效率比较高,一个存储过程替代大量T_SQL语句 ,可以降低网络通信量,提高通信速率,可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID,不要使用UUID。因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容。该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted(读取未提交数据) 即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据,未提交的数据读不到。 三. repeatable read(可重读)---MySQL默认的隔离级别 当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。 四. serializable(串行化) 其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层,所以查找记录时最多只需要2-4次IO,相对二叉平衡树已经大大降低了。范围查找时,能通过叶子节点的指针获取数据。例如查找大于等于3的数据,当在叶子节点中查到3时,通过3的尾指针便能获取所有数据,而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎,MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统,也就是 redo log 来实现 crash-safe 能力。 55题 重做日志(redo log)      作用:确保事务的持久性,防止在发生故障,脏页未写入磁盘。重启数据库会进行redo log执行重做,达到事务一致性。 回滚日志(undo log)  作用:保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 二进 制日志(binlog)    作用:用于主从复制,实现主从同步;用于数据库的基于时间点的还原。 错误日志(errorlog) 作用:Mysql本身启动,停止,运行期间发生的错误信息。 慢查询日志(slow query log)  作用:记录执行时间过长的sql,时间阈值可以配置,只记录执行成功。 一般查询日志(general log)    作用:记录数据库的操作明细,默认关闭,开启后会降低数据库性能 。 中继日志(relay log) 作用:用于数据库主从同步,将主库发来的bin log保存在本地,然后从库进行回放。 54题 MySQL有三种锁的级别:页级、表级、行级。 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。死锁的解决办法:1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性(脏读,不可重复读,幻读等),可能产生死锁。 乐观锁:乐观锁不是数据库自带的,需要我们自己去实现。 悲观锁:在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁:加了共享锁的数据对象可以被其他事务读取,但不能修改。 排他锁:当数据对象被加上排它锁时,一个事务必须得到锁才能对该数据对象进行访问,一直到事务结束锁才被释放。 行锁:就是给某一条记录加上锁。 52题 Mysql是关系型数据库,MongoDB是非关系型数据库,数据存储结构的不同。 51题 关系型数据库优点:1.保持数据的一致性(事务处理)。 2.由于以标准化为前提,数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点:1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点:1、无需经过sql层的解析,读写性能很高。 2、基于键值对,数据没有耦合性,容易扩展。 3、存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,文档形式、图片形式等等,而关系型数据库则只支持基础类型。 缺点:1、不提供sql支持,学习和使用成本较高。 2、无事务处理,附加功能bi和报表等支持也不好。 redis与mongoDB的区别: 性能:TPS方面redis要大于mongodb。 可操作性:mongodb支持丰富的数据表达,索引,redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用,使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况),必须使用可以在运行时进行数据再平衡的一套系统,而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外(Redis默认的有6种策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种: 1.定时去清理过期的缓存; 2.当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方案,可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列,一旦消息到达,消费者马上消费,谁先抢到算谁的,如果队列里没有消息,则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道,只要发布者发布消息,所有订阅者都能收到消息,订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列,可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop,blpop/brpop阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列,消息作为value,时间作为score。Zrem 命令用于移除有序集中的一个或多个成员,不存在的成员将被忽略。当 key 存在但不是有序集类型时,返回一个错误。 45题 1.热点数据缓存:因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务:expire 命令设置 key 的生存时间,到时间后自动删除 key。 3.计数器:incrby 命令可以实现原子性的递增。 4.排行榜:借助 SortedSet 进行热点数据的排序。 5.分布式锁:利用 Redis 的 setnx 命令进行。 6.队列机制:有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n 个关键字重新映射,其中K是关键字的数量, n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点:适合做冷备份;读写服务影响小,reids可以保持高性能;重启和恢复redis进程,更加快速。RDB的缺点:宕机会丢失最近5分钟的数据;文件特别大时可能会暂停数毫秒,或者甚至数秒。 AOF的优点:每个一秒执行fsync操作,最多丢失1秒钟的数据;以append-only模式写入,没有任何磁盘寻址的开销;文件过大时,不会影响客户端读写;适合做灾难性的误删除的紧急恢复。AOF的缺点:AOF日志文件比RDB数据快照文件更大,支持写QPS比RDB支持的写QPS低;比RDB脆弱,容易有bug。 42题 对于Redis而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,要么不执行。Redis的操作之所以是原子性的,是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的,这也和普通数据库的表现是一样的,可以用incr或者使用Redis的事务,或者使用Redis+Lua的方式实现。对Redis来说,执行get、set以及eval等API,都是一个一个的任务,这些任务都会由Redis的线程去负责执行,任务要么执行成功,要么执行失败,这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单(相对redis只需修改连接端口),对旧项目扩展的首选。(2)codis,目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数改变情况下,旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。(4)在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的代替算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 40题 (1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 (2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 39题 比如订单管理,热数据:3个月内的订单数据,查询实时性较高;温数据:3个月 ~ 12个月前的订单数据,查询频率不高;冷数据:1年前的订单数据,几乎不会查询,只有偶尔的查询需求。热数据使用mysql进行存储,需要分库分表;温数据可以存储在ES中,利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说,一般情况冷数据存储在磁带、光盘,热数据一般存放在SSD中,存取速度快,而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。 37题 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。 35题 redis分布式锁加锁过程:通过setnx向特定的key写入一个随机值,并同时设置失效时间,写值成功既加锁成功;redis分布式锁解锁过程:匹配随机值,删除redis上的特点key数据,要保证获取数据、判断一致以及删除数据三个操作是原子的,为保证原子性一般使用lua脚本实现;在此基础上进一步优化的话,考虑使用心跳检测对锁的有效期进行续期,同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random:当内存不足以容纳写入数据时,从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru:当内存不足以容纳写入数据时,从数据集中挑选最近最少使用的数据淘汰。 allkeys-random:当内存不足以容纳写入数据时,从数据集中任意选择数据淘汰。 noeviction:禁止驱逐数据,当内存使用达到阈值的时候,所有引起申请内存的命令会报错。 33题 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿,一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。如何避免:在访问key之前,采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key。 31题 缓存雪崩,是指在某一个时间段,缓存集中过期失效。大量的key设置了相同的过期时间,导致在缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。而缓存服务器某个节点宕机或断网,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。如何避免:1.redis高可用,搭建redis集群。2.限流降级,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热,在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间。 30题 缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。一些恶意的请求会故意查询不存在的 key,请求量很大,对数据库造成压力,甚至压垮数据库。 如何避免:1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。2:对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份,即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小:redis最大可以达到1GB,而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置,但是 Spring Boot 中也可以使用 XML 配置,通过spring提供的@ImportResource来加载xml配置。例如:@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族,有众多衍生产品例如Spring Boot,Spring Security等等,但他们的基础都是Spring的IOC和AOP,IOC提供了依赖注入的容器,而AOP解决了面向切面的编程,然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架,主要解决WEB开发的问题,因为 Spring的配置非常复杂,各种xml,properties处理起来比较繁琐。Spring Boot遵循约定优于配置,极大降低了Spring使用门槛,又有着Spring原本灵活强大的功能。总结:Spring MVC和Spring Boot都属于Spring,Spring MVC是基于Spring的一个MVC框架,而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"(YAML 不是一种标记语言)的递归缩写。YAML 的配置文件后缀为 .yml,是一种人类可读的数据序列化语言,可以简单表达清单、散列表,标量等数据形态。它通常用于配置文件,与属性文件相比,YAML文件就更加结构化,而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式: 1.使用springloaded配置pom.xml文件,使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动,配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包,操作简单,但是每次需要重新部署。 用
游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0

回答

一、建表高级属性 下面几个 shell 命令在 hbase 操作中可以起到很到的作用,且主要体现在建表的过程中,看 下面几个 create 属性 1、bloomfilter 布隆过滤器 默认是 NONE 是否使用布隆过虑及使用何种方式, 布隆过滤可以每列族单独启用 使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 对列族单独启用布隆 Default = ROW 对行进行布隆过滤(默认是ROW过滤) 对 ROW,行键的哈希在每次插入行时将被添加到布隆 对 ROWCOL,行键 + 列族 + 列族修饰的哈希将在每次插入行时添加到布隆 使用方法: create 'table',{BLOOMFILTER =>'ROW'} 作用: 用布隆过滤可以节省读磁盘过程,可以有助于降低读取延迟 2、versions 默认是 1 这个参数的意思是数据保留 1 个 版本,如果我们认为我们的数据没有这么大 的必要保留这么多,随时都在更新,而老版本的数据对我们毫无价值,那将此参数设为 1 能 节约 2/3 的空间 使用方法: create 'table',{VERSIONS=>'2'} 附: MIN_VERSIONS => '0'是说在 compact 操作执行之后,至少要保留的版本 3、compression 默认值是 NONE 即不使用压缩, 这个参数意思是该列族是否采用压缩,采用什么压缩算 法, 方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'} , 建议采用 SNAPPY 压缩算法 , HBase 中,在 Snappy 发布之前( Google 2011 年对外发布 Snappy),采用的 LZO 算法, 目标是达到尽可能快的压缩和解压速度,同时减少对 CPU 的消耗; 在 Snappy 发布之后,建议采用 Snappy 算法(参考《 HBase: The Definitive Guide》),具体 可以根据实际情况对 LZO 和 Snappy 做过更详细的对比测试后再做选择。 4、TTL 默认是 2147483647 即:Integer.MAX_VALUE 值大概是 68 年 , 这个参数是说明该列族数据的存活时间,单位是 毫秒 这个参数可以根据具体的需求对数据设定存活时间,超过存过时间的数据将在表中不在 显示,待下次 major compact 的时候再彻底删除数据 注意的是 TTL 设定之后 MIN_VERSIONS=>'0' 这样设置之后, TTL 时间戳过期后,将全部 彻底删除该 family 下所有的数据,如果 MIN_VERSIONS 不等于 0 那将保留最新的 MIN_VERSIONS 个版本的数据,其它的全部删除,比如 MIN_VERSIONS=>'1' 届时将保留一个 最新版本的数据,其它版本的数据将不再保存。 5、alter 使用方法: 如 修改压缩算法 disable 'table' alter 'table',{NAME=>'info',COMPRESSION=>'snappy'} enable 'table' 但是需要执行 major_compact 'table' 命令之后 才会做实际的操作。 6、describe/desc 这个命令查看了 create table 的各项参数或者是默认值。 使用方式: describe 'user_info' 7、disable_all/enable_all disable_all 'toplist.*' disable_all 支持正则表达式,并列出当前匹配的表的如下: toplist_a_total_1001 toplist_a_total_1002 toplist_a_total_1008 toplist_a_total_1009 toplist_a_total_1019 toplist_a_total_1035 ... Disable the above 25 tables (y/n)? 并给出确认提示 8、 drop_all 这个命令和 disable_all 的使用方式是一样的 9、 hbase 预分区 默认情况下,在创建 HBase 表的时候会自动创建一个 region 分区,当导入数据的时候, 所有的 HBase 客户端都向这一个 region 写数据,直到这个 region 足够大了才进行切分。一 种可以加快批量写入速度的方法是通过预先创建一些空的 regions,这样当数据写入 HBase 时,会按照 region 分区情况,在集群内做数据的负载均衡。 命令方式: create table with specific split points hbase>create 'table1','f1',SPLITS => ['\x10\x00', '\x20\x00', '\x30\x00', '\x40\x00'] create table with four regions based on random bytes keys hbase>create 'table2','f1', { NUMREGIONS => 8 , SPLITALGO => 'UniformSplit' } create table with five regions based on hex keys create 'table3','f1', { NUMREGIONS => 10, SPLITALGO => 'HexStringSplit' } 也可以使用 api 的方式: bin/hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info 参数: test_table 是表名 HexStringSplit 是 split 方式 -c 是分 10 个 region -f 是 family 这样就可以将表预先分为 15 个区,减少数据达到 storefile 大小的时候自动分区的时间 消耗,并且还有以一个优势,就是合理设计 rowkey 能让各个 region 的并发请求平均分配(趋 于均匀) 使 IO 效率达到最高,但是预分区需要将 filesize 设置一个较大的值,设置哪个参数 呢 hbase.hregion.max.filesize 这个值默认是 10G 也就是说单个 region 默认大小是 10G 这个参数的默认值在 0.90 到 0.92 到 0.94.3 各版本的变化: 256M--1G--10G 但是如果 MapReduce Input 类型为 TableInputFormat 使用 hbase 作为输入的时候,就要注意 了,每个 region 一个 map,如果数据小于 10G 那只会启用一个 map 造成很大的资源浪费, 这时候可以考虑适当调小该参数的值,或者采用预分配 region 的方式,并将检测如果达到 这个值,再手动分配 region。 二、表的设计 1、列簇设计 追求的原则是:在合理范围内能尽量少的减少列簇就尽量减少列簇。 最优设计是: 将所有相关性很强的 key-value 都放在同一个列簇下,这样既能做到查询效率 最高,也能保持尽可能少的访问不同的磁盘文件 以用户信息为例,可以将必须的基本信息存放在一个列族,而一些附加的额外信息可以放在 另一列族 2、rowkey设计 (100字节以内,合理的取8的倍数,一般是8或者16) HBase 中,表会被划分为 1...n 个 Region,被托管在 RegionServer 中。 Region 二个重要的 属性: StartKey 与 EndKey 表示这个 Region 维护的 rowKey 范围,当我们要读/写数据时,如果 rowKey 落在某个 start-end key 范围内,那么就会定位到目标 region 并且读/写到相关的数 据 那怎么快速精准的定位到我们想要操作的数据,就在于我们的 rowkey 的设计了 rowkey设计 三原则: (1)rowkey长度原则 Rowkey 是一个二进制码流, Rowkey 的长度被很多开发者建议说设计在 10~100 个字节,不 过建议是越短越好,不要超过 16 个字节。 原因如下: 1、 数据的持久化文件 HFile 中是按照 KeyValue 存储的,如果 Rowkey 过长比如 100 个字 节, 1000 万列数据光 Rowkey 就要占用 100*1000 万=10 亿个字节,将近 1G 数据,这会极大 影响 HFile 的存储效率; 2、 MemStore 将缓存部分数据到内存,如果 Rowkey 字段过长内存的有效利用率会降低, 系统将无法缓存更多的数据,这会降低检索效率。因此 Rowkey 的字节长度越短越好。 3、 目前操作系统是都是 64 位系统,内存 8 字节对齐。控制在 16 个字节, 8 字节的整数 倍利用操作系统的最佳特性。 (2)rowkey散列原则 如果 Rowkey 是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将 Rowkey 的高位作为散列字段,由程序循环生成,低位放时间字段,这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象,这样在做数据检索的时候负载将会集中 在个别 RegionServer,降低查询效率。 (3)rowkey唯一原则 必须在设计上保证其唯一性。 rowkey 是按照字典顺序排序存储的,因此,设计 rowkey 的时候,要充分利用这个排序的特点,将经常读取的数据存储到一块,将最近可能会被访问 的数据放到一块。 三、数据热点 1、数据热点 HBase 中的行是按照 rowkey 的字典顺序排序的,这种设计优化了 scan 操作,可以将相 关的行以及会被一起读取的行存取在临近位置,便于 scan。然而糟糕的 rowkey 设计是热点 的源头。 热点发生在大量的 client 直接访问集群的一个或极少数个节点(访问可能是读, 写或者其他操作)。大量访问会使热点 region 所在的单个机器超出自身承受能力,引起性能 下降甚至 region 不可用,这也会影响同一个 RegionServer 上的其他 region,由于主机无法服 务其他 region 的请求。 设计良好的数据访问模式以使集群被充分,均衡的利用。 为了避免写热点,设计 rowkey 使得不同行在同一个 region,但是在更多数据情况下,数据 应该被写入集群的多个 region,而不是一个。 2、防止数据热点的措施 (1)加盐 这里所说的加盐不是密码学中的加盐,而是在 rowkey 的前面增加随机数,具体就是给 rowkey 分配一个随机前缀以使得它和之前的 rowkey 的开头不同。分配的前缀种类数量应该 和你想使用数据分散到不同的 region 的数量一致。加盐之后的 rowkey 就会根据随机生成的 前缀分散到各个 region 上,以避免热点。 (2)哈希 哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群,但是读却是 可以预测的。使用确定的哈希可以让客户端重构完整的 rowkey,可以使用 get 操作准确获取 某一个行数据 (3)反转 第三种防止热点的方法时反转固定长度或者数字格式的 rowkey。这样可以使得 rowkey 中经常改变的部分(最没有意义的部分)放在前面。这样可以有效的随机 rowkey,但是牺 牲了 rowkey 的有序性。 反转 rowkey 的例子以手机号为 rowkey,可以将手机号反转后的字符串作为 rowkey,这 样的就避免了以手机号那样比较固定开头导致热点问题 (4)时间戳反转 一个常见的数据处理问题是快速获取数据的最近版本,使用反转的时间戳作为 rowkey 的一部分对这个问题十分有用,可以用 Long.Max_Value - timestamp 追加到 key 的末尾,例 如 [key][reverse_timestamp] , [key] 的最新值可以通过 scan [key]获得[key]的第一条记录,因 为 HBase 中 rowkey 是有序的,第一条记录是最后录入的数据。比如需要保存一个用户的操 作记录,按照操作时间倒序排序,在设计 rowkey 的时候,可以这样设计 [userId 反转][Long.Max_Value - timestamp],在查询用户的所有操作记录数据的时候,直接指 定 反 转 后 的 userId , startRow 是 [userId 反 转 ][000000000000],stopRow 是 [userId 反 转][Long.Max_Value - timestamp] 如果需要查询某段时间的操作记录, startRow 是[user 反转][Long.Max_Value - 起始时间], stopRow 是[userId 反转][Long.Max_Value - 结束时间
游客2q7uranxketok 2021-02-22 13:25:43 0 浏览量 回答数 0

问题

MathML 介绍:报错

MathML 是一个 W3C 推荐标准,旨在为标记数学表达式定义一个 XML 词汇表。版本 1 作为一个 W3C 推荐标准发布于 1998 年,就在 XML 规范发布后不久。MathML 已作为推荐标准发布的另外...
kun坤 2020-06-08 11:09:17 2 浏览量 回答数 1

问题

阿里云归档存储简介

欢迎使用阿里云归档存储。归档存储作为阿里云数据存储服务体系的一部分,提供了极低成本的数据存储服务。适合各种离线数据,包括但不局限于数字媒体、企业归档资料、科学实验数据、个人备份等。用户可以将数据进行几个月、几年甚...
云栖大讲堂 2019-12-01 21:07:35 1328 浏览量 回答数 0

回答

Go 的优势在于能够将简单的和经过验证的想法结合起来,同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧,作者认为,Go 语言具备的所有这些优点,将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大,如果将所有因素都纳入考虑,没有其他语言能够像 Go 语言一样“全面开花”,在大型软件工程方面,尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的,长期以来,他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前,Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后,在编译器和垃圾收集方面拥有数十年的经验。有太多次,他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是,他们开始着手创建新的编程语言,将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下,在包含数千万行代码的大型代码库上进行协作时,就会发生真正令人痛苦的问题。这样会导致一些问题,如下: 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有,混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等,他们需要了解代码库,但也具备广泛的编码经验。依赖于许多外部库或运行时,其中一些不再以原始形式存在。在代码库的生命周期中,每行代码平均被重写 10 次,被弄得千疮百痍,而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题,有时会以使小型工程变得更麻烦为代价,例如,代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能,如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式,机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式,从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是,Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言,只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码,以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的,避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而,在其生命周期中,人们阅读代码的时间却远远超过最初编写代码所需的时间(100 倍)。例如,审查、理解、调试、更改、重构或重用代码。在查看代码时,往往只能看到并理解其中的一小部分,通常不会有完整的代码库概述。为了解释这一点,Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说,这使得错误处理编写起来更加繁琐,但是也更容易理解。 简单易学 Go 是如此的小巧而简单,以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验,培训用不了一个星期(相比于掌握其他语言需要几个月),初学者就能够理解 Go 专家编写的代码,并为之做出贡献。为了方便吸引更多的用户,Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行,允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作,而不是个人的自我表达。 在 Go(和 Python)中,所有的语言特性都是相互正交和互补的,通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题,你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时,国骂会更少,而且人们的工作可以更好地融合在一起,从而形成了一致的整体,人人都为之感到自豪,并乐于工作。这还避免了大型工程的问题,如: 开发人员认为良好的工作代码很“混乱”,并要求在开始工作之前进行重写,因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/e64418f1455d46aaacfdd03fa949f16d.png) 简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言(Java、JavaScript、Python、Ruby、C、C++)都是 20 世纪 80 年代到 21 世纪初设计的,当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的,并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现,而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式,如 Actor 模型,但是总有多个可用选项,结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核,软件必须并行化才能高效运行。Go 是在多核处理器时代编写的,并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言,计算机系统接收数据,对其进行处理(通常要经过几个步骤),然后输出结果数据。例如,Web 服务器从客户端接收 HTTP 请求,并将其转换为一系列数据库或后端调用。一旦这些调用返回,它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例: 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供(几乎无限的)并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的,因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来,面向对象的使用富有成效,并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法,并记住了这些知识。它保留了好的部分,如封装、消息传递等。Go 还避免了继承,因为它现在被认为是有害的,并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言(Java、JavaScript、Python、Ruby)都是在互联网成为当今无处不在的计算平台之前设计的。因此,这些语言的标准库只提供了相对通用的网络支持,而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的,当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题: 碎片化:总是有多个选项实现相同的功能。 膨胀:库常常实现的不仅仅是它们的用途。 依赖地狱:库通常依赖于特定版本的其他库。 未知质量:第三方代码的质量和安全性可能存在问题。 未知支持:第三方库的开发可能随时停止支持。 意外更改:第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢,但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式,但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响: 集中讨论重要主题: 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在, 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码,但如果其他人按照自己喜欢的方式格式化了代码,这么做很招人烦。 自动代码更改并不会打乱手写代码的格式,例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时,通常会有几个相互竞争的格式标准。例如,JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用,也可以只使用其中的一个。但许多 JS 项目并没有采用它们,因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中,因此只有一个标准,每个人都在使用它。 快速编译 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/8a76f3f07f484266af42781d9e7b8692.png) 对于大型代码库来说,它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java,与 Haskell、Scala 或 Rust 等更复杂的语言相比,它们的编译速度相对较快。尽管如此,当编译大型代码库时,即使是少量的缓慢也会加剧编译的延迟,从而激怒开发人员,并干扰流程。Go 的设计初衷是为了提高编译效率,因此它的编译器速度非常快,几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈,还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单,因此它被移植到许多平台,如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言(Java、JavaScript、Python 等)不同,Go 二进制文件不需要启动或预热的时间,因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外,Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码,每次运行程序时,它们还会加载大型且高度复杂的基础架构,以进行编译和优化程序。如此一来,它们的启动时间就变慢了,并且还占用了大量内存(数百兆字节)。而 Go 进程的开销更小,因为它们已经完全编译和优化,只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中,以及在开发过程中,这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈,同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍,这是因为它无需包含编译器、JIT,以及更少的运行时基础架构的原因。这些特点,在部署大型应用程序时很重要。想象一下,如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样?如果使用 Node/JVM 时,我们的 Docker 注册表就必须提供 100 个 docker 镜像,每个镜像 200MB,那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下,如果我们想每天部署 100 次的话,如果使用 Go 服务,那么 Docker 注册表只需提供 10 个 docker 镜像,每个镜像只有 20MB,共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署,从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件,并无需安装特定版本的 JVM、Node 或 Python 运行时;也不必将库下载到生产服务器上,更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是,只是将 Go 二进制文件放到服务器上,它就会在那里运行,而不用关心服务器运行的是什么。前面所提到的那些,唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库,并将所有相关代码下载(供应)到自己的代码库中。这样做有很多好处: 在使用第三方代码之前,我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样,是我们应用程序的一部分,应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方(包括私有 Git repos)获取第三方库,你就能永久拥有它们。 经过验收后,编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码,这也并不足为奇。 即使软件包存储库速度变慢,或托管包不复存在,部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易,并且可从它们带来的许多性能和安全性改进中获益。同时,由于 Go 二进制文件包含了它们需要的所有依赖项,因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件,而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中,文档对于使软件可访问性和可维护性非常重要。与其他特性类似,Go 中的文档简单实用: 由于它是嵌入到源代码中的,因此两者可以同时维护。 它不需要特殊的语法,文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中,因此每个人都使用它们。 Go linter 需要导出元素的文档,以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时,那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化,使系统更为健壮、可靠、高效,并具有开放式开发的优势,如来自许多行业的广泛支持,多个大型实体和许多用户的支持,以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然,Go 也并非完美无缺,每种技术选择都是有利有弊。在决定选择 Go 之前,有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念(如 HTTP 2 Server push 等)方面处于行业领先地位,但与 JVM 生态系统中的第三方库相比,用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素,Go 团队非常谨慎,只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后,Go 团队正在谋划对语言进行一系列更大的改进,作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿,但支持硬实时需要没有垃圾收集的技术,例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则,虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时,这些准则可能会使大型工程项目免于许多痛苦。总的来说,正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里,用于大型软件开发项目的绝佳选择。
有只黑白猫 2020-01-07 14:11:38 0 浏览量 回答数 0

回答

线网络优化是通过对现已运行的网络进行话务数据分析、现场测试数据采集、参数分析、硬件检查等手段,找出影响网络质量的原因,并且通过参数的修改、网络结构的调整、设备配置的调整和采取某些技术手段(采用MRP的规划办法等),确保系统高质量的运行,使现有网络资源获得最佳效益,以最经济的投入获得最大的收益。 二 GSM无线网络优化的常规方法 网络优化的方法很多,在网络优化的初期,常通过对OMC-R数据的分析和路测的结果,制定网络调整的方案。在采用图1的流程经过几个循环后,网络质量有了大幅度的提高。但仅采用上述方法较难发现和解决问题,这时通常会结合用户投诉和CQT测试办法来发现问题,结合信令跟踪分析法、话务统计分析法及路测分析法,分析查找问题的根源。在实际优化中,尤其以分析OMC-R话务统计报告,并辅以七号信令仪表进行A接口或Abis接口跟踪分析,作为网络优化最常用的手段。网络优化最重要的一步是如何发现问题,下面就是几种常用的方法: 1.话务统计分析法:OMC话务统计是了解网络性能指标的一个重要途径,它反映了无线网络的实际运行状态。它是我们大多数网络优化基础数据的主要根据。通过对采集到的参数分类处理,形成便于分析网络质量的报告。通过话务统计报告中的各项指标(呼叫成功率、掉话率、切换成功率、每时隙话务量、无线信道可用率、话音信道阻塞率和信令信道的可用率、掉话率及阻塞率等),可以了解到无线基站的话务分布及变化情况,从而发现异常,并结合其它手段,可分析出网络逻辑或物理参数设置的不合理、网络结构的不合理、话务量不均、频率干扰及硬件故障等问题。同时还可以针对不同地区,制定统一的参数模板,以便更快地发现问题,并且通过调整特定小区或整个网络的参数等措施,使系统各小区的各项指标得到提高,从而提高全网的系统指标。 2.DT (驱车测试):在汽车以一定速度行驶的过程中,借助测试仪表、测试手机,对车内信号强度是否满足正常通话要求,是否存在拥塞、干扰、掉话等现象进行测试。通常在DT中根据需要设定每次呼叫的时长,分为长呼(时长不限,直到掉话为止)和短呼(一般取60秒左右,根据平均用户呼叫时长定)两种(可视情况调节时长),为保证测试的真实性,一般车速不应超过40公里/小时。路测分析法主要是分析空中接口的数据及测量覆盖,通过DT测试,可以了解:基站分布、覆盖情况,是否存在盲区;切换关系、切换次数、切换电平是否正常;下行链路是否有同频、邻频干扰;是否有小岛效应;扇区是否错位;天线下倾角、方位角及天线高度是否合理;分析呼叫接通情况,找出呼叫不通及掉话的原因,为制定网络优化方案和实施网络优化提供依据。 3.CQT (呼叫质量测试或定点网络质量测试):在服务区中选取多个测试点,进行一定数量的拨打呼叫,以用户的角度反映网络质量。测试点一般选择在通信比较集中的场合,如酒店、机场、车站、重要部门、写字楼、集会场所等。它是DT测试的重要补充手段。通常还可完成DT所无法测试的深度室内覆盖及高楼等无线信号较复杂地区的测试,是场强测试方法的一种简单形式。 4.用户投诉:通过用户投诉了解网络质量。尤其在网络优化进行到一定阶段时,通过路测或数据分析已较难发现网络中的个别问题,此时通过可能无处不在的用户通话所发现的问题,使我们进一步了解网络服务状况。结合场强测试或简单的CQT测试,我们就可以发现问题的根源。该方法具有发现问题及时,针对性强等特点。 5.信令分析法:信令分析主要是对有疑问的站点的A接口、Abis接口的数据进行跟踪分析。通过对A接口采集数据分析,可以发现切换局数据不全(遗漏切换关系)、信令负荷、硬件故障(找出有问题的中继或时隙)及话务量不均(部分数据定义错误、链路不畅等原因)等问题。通过对Abis接口数据进行收集分析,主要是对测量仪表记录的LAY3信令进行分析,同时根据信号质量分布图、频率干扰检测图、接收电平分布图,结合对信令信道或话音信道占用时长等的分析,可以找出上、下行链路路径损耗过大的问题,还可以发现小区覆盖情况、一些无线干扰及隐性硬件故障等问题。 6.自动路测系统分析:采用安装于移动车辆上的自动路测终端,可以全程监测道路覆盖及通信质量。由于该终端能够将大量的信令消息和测量报告自动传回监控中心,可以及时发现问题,并对出现问题的地点进行分析,具有很强的时效性。所采用的方法同5。 在实际工作中,这几种方法都是相辅相成、互为印证的关系。GSM无线网络优化就是利用上述几种方法,围绕接通率、掉话率、拥塞率、话音质量和切换成功率及超闲小区、最坏小区等指标,通过性能统计测试→数据分析→制定实施优化方案→系统调整→重新制定优化目标→性能统计测试的螺旋式循环上升,达到网络质量明显改善的目的。 三 现阶段GSM无线网络优化方法 随着网络优化的深入进行,现阶段GSM无线网络优化的目标已越来越关注于用户对网络的满意程度,力争使网络更加稳定和通畅,使网络的系统指标进一步提高,网络质量进一步完善。 网络优化的工作流程具体包括五个方面:系统性能收集、数据分析及处理、制定网络优化方案、系统调整、重新制定网络优化目标。在网络优化时首先要通过OMC-R采集系统信息,还可通过用户申告、日常CQT测试和DT测试等信息完善问题的采集,了解用户对网络的意见及当前网络存在的缺陷,并对网络进行测试,收集网络运行的数据;然后对收集的数据进行分析及处理,找出问题发生的根源;根据数据分析处理的结果制定网络优化方案,并对网络进行系统调整。调整后再对系统进行信息收集,确定新的优化目标,周而复始直到问题解决,使网络进一步完善。 通过前述的几种系统性收集的方法,一般均能发现问题的表象及大部分问题产生的原因。 数据分析与处理是指对系统收集的信息进行全面的分析与处理,主要对电测结果结合小区设计数据库资料,包括基站设计资料、天线资料、频率规划表等。通过对数据的分析,可以发现网络中存在的影响运行质量的问题。如频率干扰、软硬件故障、天线方向角和俯仰角存在问题、小区参数设置不合理、无线覆盖不好、环境干扰、系统忙等。数据分析与处理的结果直接影响到网络运行的质量和下一步将采取的措施,因此是非常重要的一步。当然可以看出,它与第一步相辅相成,难以严格区分界限。 制定网络优化方案是根据分析结果提出改善网络运行质量的具体实施方案。 系统调整即实施网络优化,其基本内容包括设备的硬件调整(如天线的方位、俯仰调整,旁路合路器等)、小区参数调整、相邻小区切换参数调整、频率规划调整、话务量调整、天馈线参数调整、覆盖调整等或采用某些技术手段(更先进的功率控制算法、跳频技术、天线分集、更换电调或特型天线、新增微蜂窝、采用双层网结构、增加塔放等)。 测试网络调整后的结果。主要包括场强覆盖测试、干扰测试、呼叫测试和话务统计。 根据测试结果,重新制定网络优化目标。在网络运行质量已处于稳定、良好的阶段,需进一步提高指标,改善网络质量的深层次优化中出现的问题(用户投诉的处理,解决局部地区话音质量差的问题,具体事件的优化等等)或因新一轮建设所引发的问题。 四 网络优化常见问题及优化方案 建立在用户感知度上的网络优化面对的必然是对用户投诉问题的处理,一般有如下几种情况: 1.电话不通的现象 信令建立过程 在手机收到经PCH(寻呼信道)发出的pagingrequest(寻呼请求)消息后,因SDCCH拥塞无法将pagingresponse(寻呼响应)消息发回而导致的呼损。 对策:可通过调整SDCCH与TCH的比例,增加载频,调整BCC(基站色码)等措施减少SDCCH的拥塞。 因手机退出服务造成不能分配占用SDCCH而导致的呼损。 对策:对于盲区造成的脱网现象,可通过增加基站功率,增加天线高度来增加基站覆盖;对于BCCH频点受干扰造成的脱网现象,可通过改频、调整网络参数、天线下倾角等参数来排除干扰。 鉴权过程 因MSC与HLR、BSC间的信令问题,或MSC、HLR、BSC、手机在处理时失败等原因造成鉴权失败而导致的呼损。 对策:由于在呼叫过程中鉴权并非必须的环节,且从安全角度考虑也不需要每次呼叫都鉴权,因此可以将经过多少次呼叫后鉴权一次的参数调大。 加密过程 因MSC、BSC或手机在加密处理时失败导致呼损。 对策:目前对呼叫一般不做加密处理。 从手机占上SDCCH后进而分配TCH前 因无线原因(如RadioLinkFailure、硬件故障)使SDCCH掉话而导致的呼损。 对策:通过路测场强分析和实际拨打分析,对于无线原因造成的如信号差、存在干扰等问题,采取相应的措施解决;对于硬件故障,采用更换相应的单元模块来解决。 话音信道分配过程 因无线分配TCH失败(如TCH拥塞,或手机已被MSC分配至某一TCH上,因某种原因占不上TCH而导致链路中断等原因)而导致的呼损。 对策:对于TCH拥塞问题,可采用均衡话务量,调整相关小区服务范围的参数,启用定向重试功能等措施减少TCH的拥塞;对于占不上TCH的情况,一般是硬件故障,可通过拨打测试或分析话务统计中的CALLHOLDINGTIME参数进行故障定位,如某载频CALLHOLDINGTIME值小于10秒,则可断定此载频有故障。另外严重的同频干扰(如其它基站的BCCH与TCH同频)也会造成占不上TCH信道,可通过改频等措施解决。 2.电话难打现象 一般现象是较难占线、占线后很容易掉线等。这种情况首先应排除是否是TCH溢出的原因,如果TCH信道不足,则应增加信道板或通过增加微蜂窝或小区裂变的形式来解决。 排除以上原因后,一般可以考虑是否是有较强的干扰存在。可以是相邻小区的同邻频干扰或其它无线信号干扰源,或是基站本身的时钟同步不稳。这种问题较为隐蔽,需通过仔细分析层三信令和周围基站信息才能得出结论。 3. 掉话现象 掉话的原因几乎涉及网络优化的所有方面内容,尤其是在路测时发生的掉话,需要仔细分析。在路测时,需要对发生掉话的地段做电平和切换参数等诸多方面的分析。如果电平足够,多半是因为切换参数有问题或切入的小区无空闲信道。对话务较忙小区,可以让周围小区分担部分话务量。采用在保证不存在盲区的情况下,调整相关小区服务范围的参数,包括基站发射功率、天线参数(天线高度、方位角、俯仰角)、小区重选参数、切换参数及小区优先级设置的调整,以达到缩小拥塞小区的范围,并扩大周围一些相对较为空闲小区的服务范围。通过启用DirectedRetry(定向重试)功能,缓解小区的拥塞状况。上述措施仍不能满足要求的话,可通过实施紧急扩容载频的方法来解决。 对大多采用空分天线远郊或近郊的基站,如果主、分集天线俯仰角不一致,也极易造成掉话。如果参数设置无误,则可能是有些点信号质量较差。对这些信号质量较差而引起的掉话,应通过硬件调整的方式增加主用频点来解决。 4. 局部区域话音质量较差 在日常DT测试中,经常发现有很多微小的区域内,话音质量相当差、干扰大,信号弱或不稳定以及频繁切换和不断接入。这些地方往往是很多小区的交叠区、高山或湖面附近、许多高楼之间等。同样这种情况对全网的指标影响不明显,小区的话务统计报告也反映不出。这种现象一方面是由于频带资源有限,基站分布相对集中,频点复用度高,覆盖要求严格,必然不可避免的会产生局部的频率干扰。另一方面是由于在高层建筑林立的市区,手机接收的信号往往是基站发射信号经由不同的反射路径、散射路径、绕射路径的叠加,叠加的结果必然造成无线信号传播中的各种衰落及阴影效应,称之为多径干扰。此外,无线网络参数设置不合理也会造成上述现象。 在测试中RXQUAL的值反映了话音质量的好坏,信号质量实际是指信号误码率, RXQUAL=3(误码率:0.8%至1.6%),RXQUAL=4(误码率:1.6%至3.2%),当网络采用跳频技术时,由于跳频增益的原因,RXQUAL=3时,通话质量尚可,当RXQUAL≥6时,基本无法通话。 根据上述情况,通过对这些小区进行细致的场强覆盖测试和干扰测试,对场强覆盖测试数据进行分析,统计出RXLEV/RXQUAL之间对照表,如果某个小区域RXQUAL为6和7的采样统计数高而RXLEV大于-85dBm的采样数较高,一般可以认为该区域存在干扰。并在Neighbor-List中可分析出同频、邻频干扰频点。 5.多径干扰 如果直达路径信号(主信号)的接收电平与反射、散射等信号的接收电平差小于15dB,而且反射、散射等信号比主信号的时延超过4~5个GSM比特周期(1个比特周期=3.69μs),则可判断此区域存在较强的多径干扰。 多径干扰造成的衰落与频点及所在位置有关。多径衰落可通过均衡器采用的纠错算法得以改善,但这种算法只在信号衰落时间小于纠错码字在交织中分布占用的时间时有效。 采用跳频技术可以抑制多径干扰,因为跳频技术具有频率分集和干扰分集的特性。频率分集可以避免慢速移动的接收设备长时间处于阴影效应区,改善接收质量;而且可以充分利用均衡器的优点。干扰分集使所有的移动及基站接收设备所受干扰等级平均化。使产生干扰的几率大为减小,从而降低干扰程度。 采用天线分集和智能天线阵,对信号的选择性增强,也能降低多径干扰。 适当调整天线方位角,也可减小多径干扰。 若无线网络参数设置不合理,也会影响通话质量。如在DT测试中常常发现切换前话音质量较差,即RXQUAL较大(如5、6、7),而切换后,话音质量变得很好,RXQUAL很小(如0、1),而反方向行驶通过此区域时话音质量可能很好(RXQUAL为0、1),因为占用的服务小区不同。对于这种情况,是由于基于话音质量切换的门限值设置不合理。减小RXQUAL的切换门限值,如原先从RXQUAL≥4时才切换,改为RXQUAL≥3时就切换,可以提高许多区域的通话质量。因此,根据测试情况,找出最佳的切换地点,设置最佳切换参数,通过调整切换门限参数控制切换次数,通过修改相邻小区的切换关系提高通话质量。总之,根据场强测试可以优化系统参数。 值得一提的是,由于竞争的激烈及各运营商的越来越深化的要求,某些地方的运营商为完成任务,达到所谓的优化指标,随意调整放大一些对网络统计指标有贡献的参数,使网络看起来“质量很高”。然而,用户感觉到的仍是网络质量不好,从而招致更多用户的不满,这是不符合网络优化的宗旨的。 总之,网络优化是一项长期、艰巨的任务,进行网络优化的方法很多,有待于进一步探讨和完善。好在现在国内两大运营商都已充分认识到了这一点,网络质量也得到了迅速的提高,同时网络的经济效益也得到了充分发挥,既符合用户的利益又满足了运营商的要求,毫无疑问将是持续的双赢局面。 答案来源于网络
养狐狸的猫 2019-12-02 02:18:17 0 浏览量 回答数 0

问题

DRDS 错误代码如何解决?

本文档列出了 DRDS 返回的常见错误码及解决方法。 TDDL-4006 ERR_TABLE_NOT_EXIST TDDL-4007 ERR_CANNOT_FETCH_TABLE_META TDDL-4100 ERR_ATOM_NOT...
猫饭先生 2019-12-01 21:21:21 7993 浏览量 回答数 0

回答

配置你的 csh/tcsh 选择 csh/tcsh 和许多刚从 Linux 转到 BSD 的人不同,我并没有装完 BSD 就顺手安装 bash,因为之前除了打命令,我没有用到额外的功能,bash 也好,csh 也罢,在我眼里都是当做 shell 来用。但是渐渐地,我发现 csh 真的挺好用,它小巧、简单、开放,不需要额外依赖。可能有人要拿脚本能力来作对比,比如bash脚本支持函数,csh不支持等。对我来说,其实我从未像模像样地写过一个脚本,我的工作是 C++ 程序员。从我的角度来看,论脚本能力,其实bash、csh、zsh都比不上Python,论兼容性,bash、csh、zsh都比不上sh,论强大,bash、csh、zsh都比不上C/C++,甚至asm。再看易学程度,bash、csh、zsh可能还是要输给Python。综上,脚本能力忽略不计。:-x好了,说了这么多大不敬的话,我们开始切入正题。8-) 配置文件 全局配置文件 /etc/csh.cshrc个人配置文件 ~/.cshrc或~/.tcshrc为了方便,建议修改全局性的配置文件,这样每个账号都可以享受便利。按键绑定 通常,我们不设置按键绑定也能很好地工作,但是对于远程登录,可能需要一些额外的配置。比如,为了避免putty登录后,Home、End、Delete等变成~,你需要如下配置: bindkey '\e[1~' beginning-of-line # Home bindkey '\e[3~' delete-char # Delete bindkey '\e[4~' end-of-line # End bindkey "^W" backward-delete-word # Delete bindkey -k up history-search-backward # PageUp bindkey -k down history-search-forward # PageDown 提示符 设置一个漂亮使用的的提示符可以让工作变得更愉快高效。 以下是一个合理的配置方案: if ( $?prompt ) then #如果$prompt变量尚未设置,则做如下设置 if ( "$uid" == "0" ) then #判断用户的uid set prompt = "%U%n%u@%m [%l] %B%~%b # " #对于root,我们显示“#”号 else set prompt = "%U%n%u@%m [%l] %B%~%b % " #对于普通用户,显示“%”号。 endif endif Konsole中的效果如下: prompt2_img 一种彩色的配置方案如下: set cr = "%{\e[31m%}" #开始红色 set cg = "%{\e[32m%}" #开始绿色 set c0 = "%{\e[0m%}" #恢复为默认色彩 # Set some variables for interactive shells if ( $?prompt ) then if ( "$uid" == "0" ) then set prompt = "%B%U%n%u@%m.$cr%l$c0%b %c2 %B%#%b " else set prompt = "%B%U%n%u@%m.$cg%l$c0%b %c2 %B%%%b " endif endif Konsole中的效果如下: prompt3.png 颜色代码: 1 for brighter colors 4 for underlined text 5 for flashing text 30 for black foreground 31 for red foreground 32 for green foreground 33 for yellow (or brown) foreground 34 for blue foreground 35 for purple foreground 36 for cyan foreground 37 for white (or gray) foreground 40 for black background 41 for red background 42 for green background 43 for yellow (or brown) background 44 for blue background 45 for purple background 46 for cyan background 47 for white (or gray) background 查看更多参数,及其作用: man tcsh #查看man手册 /%/ #搜索到“%/”开始的地方 环境变量等 你在抱怨 FreeBSD下的 ls 没有显示颜色, grep 出来的东西没有高亮吗? 那么你需要如下的配置: 让 ls 鲜艳些 setenv LSCOLORS ExGxFxdxCxegedabagExExsetenv CLICOLOR yes 让 grep 匹配到的字符高亮 setenv GREP_OPTIONS --color=auto对于在KDE下使用fcitx的人,需要如下三行设置,其实就是fcitx安装完后所提示的内容,如果你够细心的话。setenv XMODIFIERS @im=fcitxsetenv QT_IM_MODULE ximsetenv GTK_IM_MODULE xim嗯, ls 有颜色了,但是等等,为何 tab 不能补全?你需要如下配置:set autolist若要在补全时也将历史记录(即命令history的输出)纳入参考范围,可以添加如下配置:set autoexpand而对与命令history本身,则提供了以下两项配置:set history = 100set savehist = 10第一项设置了历史记录暂存条数,默认为100;第二项设置了退出当前Shell时会将多少条最新的暂存条数写入~/.history,其取值显然不能大于set history。需要说明的是,在savehist的设置中,还可以使用类似set savehist = (10 merge)的写法;这里merge表示保存时合并历史记录中的相同命令,合并后的序列号、时间则与其中最新者相同。如果命令输错了,让csh/tcsh 为你纠正:set correct = cmd为了在命令行启动某个游戏,或者kde程序,例如dolphin、kcalc,你需要加两个路径到$path中去:/usr/games /usr/local/kde4/bin/ set path = (/sbin /bin /usr/sbin /usr/local/bin /usr/games /usr/local/sbin /usr/bin $HOME/bin /usr/local/kde4/bin/) 黑魔法防御术 重定向防御 重定向很强大,我们有时候会运行诸如“date » b.txt”,“ls -l > files.txt”等命令。然而如果一不小心,把“»”输成“>”会造成什么后果呢?为此,tcsh提供了noclobber这个选项:set noclobber有了它,悲剧就不会发生。如果“>”的目标文件已存在,tcsh会拒绝重定向。覆盖防御 是否遇到过“mv a b”,从而把有用的b文件覆盖掉了?为此,我们要让mv和cp的行为更谨慎:alias mv 'mv -i'alias cp 'cp -i'如果目标文件已存在,mv和cp会拒绝操作,除非使用参数“-f”。误删防御 rm这个命令自从诞生起,就一直是个危险的操作。我们可以让rm更温和:alias rm 'rm -i'这样rm之前,会要求再次确认。一切皆alias 前面,我们在黑魔法防御术中已经初步见识了alias。alias不仅可以避免危险操作,还可以简化命令,自创命令。除非极短,否则良好的alias命名,应当以某个统一的单词或字母开头,例如下面即将展示的reload/edit系列、update系列、show系列等。先展示最基本的alias,并逐条解释。alias .. 'cd ..' #两点即可回到上级目录alias - 'cd -' #一杠返回上次的目录alias q 'exit' #退出登录alias rm 'rm -i' #误删防御alias del 'rm -r' #删除整个目录alias mv 'mv -i' #覆盖防御alias cp 'cp -i' #覆盖防御alias ls 'ls -I' #root状态下,默认不显示隐藏文件(.*)。BSD的ls很特殊,root默认显示所有文件。alias la 'ls -a' #显示所有文件alias ll 'ls -h -l' #显示文件权限和大小(以合理的单位)alias lr 'ls -R' #递归显示目录alias dh 'df -h -a -T' #以合适的单位显示所有磁盘的剩余空间,以及文件系统类型(如ufs、devfs、procfs)。alias ds 'du -sh' #以合适的单位显示查看每个文件/文件夹的大小find/wc系列。快速查找当前目录下的所有c/cxx/python源码文件。结合wc可以统计行数。alias find-c 'find . -name ".h" -o -name ".c"'alias find-x 'find . -name ".h" -o -name ".hpp" -o -name ".cpp" -o -name ".cxx"'alias find-py 'find . -name ".py"'alias wc-c 'find . -name ".h" -o -name ".c" | xargs wc | sort -k 4'alias wc-x 'find . -name ".h" -o -name ".hpp" -o -name ".cpp" -o -name ".cxx" | xargs wc | sort -k 4'alias wc-py 'find . -name ".py" | xargs wc | sort -k 4'reload/edit系列。实现快速修改,载入配置文件。alias reload-rc.conf 'sh /etc/rc'alias reload-cshrc 'unalias * && source /etc/csh.cshrc'alias edit-xorg.conf 'vim /etc/xorg.conf'alias edit-csh.cshrc 'vim /etc/csh.cshrc'alias edit-make.conf 'vim /etc/make.conf'alias edit-kern.conf 'vim /etc/kernconf/thinkpad'alias edit-rc.conf 'vim /etc/rc.conf'alias edit-vimrc 'vim /usr/local/share/vim/vimrc'set系列。快速设置locale。 alias setlocale-zhcn 'setenv LC_ALL zh_CN.UTF-8 && setenv LANG zh_CN.UTF-8'alias setlocale-c 'setenv LC_ALL C'startx专用。保持命令行下为英文locale(避免date等命令出现乱码),而让x环境为中文,适合手动startx而不是kdm的人。 alias sx 'setenv LC_ALL zh_CN.UTF-8 && setenv LANG zh_CN.UTF-8 && startx && setenv LC_ALL C'make系列。快速编译kernel/world。 alias make-world 'cd /usr/src && make buildworld && cd -'alias make-kernel 'cd /usr/src && make kernel KERNCONF=thinkpad && cd -'alias make-installworld 'cd /usr/src && make installworld && make delete-old && cd -'show系列。查看状态或某些信息。 alias show-ifstat 'systat -ifstat' #查看网络接口的数据流量alias show-geom 'gstat' #查看I/O状态alias show-thermal 'sysctl dev.acpi_ibm.0.thermal' #查看ThinkPad笔记本的各部分温度alias show-cpufreq 'sysctl dev.cpu.0.freq' #查看当前cpu频率alias show-cpulevels 'sysctl dev.cpu.0.freq_levels' #查看可用的cpu频率alias show-battery 'sysctl hw.acpi.battery.life && sysctl hw.acpi.battery.time' #查看电力alias show-smartctl 'smartctl -a /dev/ad4' #需要安装smartmontools,查看磁盘smart参数alias show-alldep 'make all-depends-list' #需要在ports的安装目录下执行,显示所有依赖alias show-dep 'portmaster --show-work ./ | sort' #同上,且需要安装portmaster,只显示尚未安装的依赖alias show-ver 'pkg_version -v' #查看是否有软件可更新update系列。顾名思义,更新嘛。alias update-locatedb '/usr/libexec/locate.updatedb' #更新locate数据库alias update-kernsrc 'csup -L 2 /etc/supfiles/stable-supfile' #同步kernel treealias update-ports 'portsnap fetch update' #同步ports treealias update-apps 'portmaster -a --force-config' #需要安装portmaster,更新所有软件,提示配置选项杂项,均需要安装第三方软件才能用。 alias lt 'tree -N -C' #需要安装tree。树状显示目录,-N可以保证中文显示,-C使用彩色alias l3 'tree -N -C -L 3' #目录最多递归三级alias l4 'tree -N -C -L 4' #四级alias l5 'tree -N -C -L 5' #五级alias l6 'tree -N -C -L 6' #六级alias v 'vim' #不用说,我懒alias m 'mocp' #控制台下的cs架构播放器alias getdir 'wget -c -r -np -k' #递归下载目录alias ssh-home 'ssh raphael.vicp.cc -l root' #用root账号登录,结合key可以免输密码alias ftp-home 'ftp ftp://syh:syh@raphael.vicp.cc' #BSD自带的ftp,免输账号密码。主机已被电信和工信部和谐,勿再试alias lft-phome 'lftp raphael.vicp.cc -u syh,syh' #lftp的免输账号密码。alias scons 'scons -Q -j 4' #构建工具,默认4个线程进行alias valgrind-checkmem 'valgrind --tool=memcheck --leak-check=full' #检查内存泄漏
小旋风柴进 2019-12-02 02:35:10 0 浏览量 回答数 0

回答

iperf,具体要纤细直接去看文档, 简单给你列条测试:(TCP和UDP知只是两种传输数据的协议) 1)TCP测试    服务器执行:./iperf -s -i 1 -w 1M '这裏是指定windows如果是 iperf -s则windwos默认大小为8kbyte/s    客户端执行:./iperf -c host -i 1 -w 1M   其中-w表示TCP window size,host需替换成服务器地址。    2)UDP测试    服务器执行:./iperf -u -s    客户端执行:./iperf -u -c 10.255.255.251 -b 900M -i 1 -w 1M -t 60   其中-b表示使用多少带宽,1G的线路你可以使用900M进行测试。 不给分不给力 连接速度是个很怪的概念。我们通常用连接带宽和网络延迟来表达网络连接的状态。 带宽可以用一端建立FTP服务器,另一端下载来测试。网络延时可以用PING命令来测试。 希望能帮到你。 行的。 家庭或小型办公室,如果有两台或更多的计算机,很自然地希望将他们组成一个网络。为方便叙述,以下约定将其称为局域网。在家庭环境下,可用这个网络来共享资源、玩那些需要多人参与的游戏、共用一个调制解调器享用Internet连接等等。办公室中,利用这样的网络,主要解决共享外设如打印机等,此外,办公室局域网也是多人协作工作的基础设施。 别看这样小的网络工程,在过去也是需要专业人员来进行组网配置的。那时,大部分操作的都是手工的,一般的用户都不具备相应的知识和经验。正好属于"高不成低不就"的情况,自然限制了它的发展。Windows XP的出现,打破了这种局面,这依赖它内建有强大的网络支持功能和方便的向导。用户完成物理连接后,运行连接向导,可以自己探测出网络硬件、安装相应的驱动程序或协议,并指导用户,完成所有的配置步骤。 本文介绍两种在Windows XP操作系统下的组网方案,并介绍Windows XP用于局域网中的各种很有特色的功能。 一. 目标: 组成家庭局域网:对外,可以连接Internet,允许局域网内的各个计算机共享连接。对内,可以共享网络资源和设备。 二. 采用什么网络形式? 家庭网中的计算机可能有桌面机或便携机,例如掌上电脑或笔记本机等,也可能出现各种传输介质的接口,所以网络形式上,不宜都采用有线网络,无线接口是必须考虑的。但如果可以明确定位在纯粹的有线网上,也可不设无线接口。所以,这里提供两种方案: 1. 有线与无线混合。 2. 有线。 三. 网络硬件选择 网络适配器(网卡)可采用PCI、PC或PCMCIA接口的卡(后两者多用在便携式机或笔记本机上),Windows XP也支持用USB接口的网络适配器。究竟采用那种适配器,取决于接入网络中的计算机。无论那种适配器,都需要注意与现有计算机的接口以及HUB的协调一致,USB接口的适配器可能适应性更强一些,但对于较旧的计算机,又需要注意它是否支持USB接口。 网络连接线,常用的有同轴电缆和双绞线,这都是大家熟悉的东西,不多解释。究竟采用哪一种,就看你怎么想了。 四. 可采用的网络结构和介质 以太结构:这种结构在办公室或商业用户中最为流行,熟悉的人也很多,技术资料和维护人员也容易找到,所以不多赘述。 电话线连接:这种形式主要的特色是成本很低,物理连接也很简单,适用于大部分的家庭用户。 无线电波:利用电磁波信号来传输信号,可以不用任何连线来进行通讯,并可以在移动中使用。但需要在每台计算机上加装无线适配器,成本高是肯定了。在我国,无线形式用在计算机网络通讯的还较少。在美国,用于无线网络的是一个称为IEEE 802.11b的标准协议,用于计算机近距离网络通讯。在该协议支持下,可达到的网速是11 Mbps。 五. 方案之一 这是一个有线、无线混合方案,具体结构可以参看图1。这个例子中,用4台计算机组成了一个混合网络,PC1是主机,它与外部连接有3个通路: 1. 与Internet接连的调制解调器:用于整个网络的各个计算机共享上网之用。 2. 无线适配器:用于和本网络内的无线设备之间的通讯。 3. HUB:用于"带动"本网络内的下游计算机。 该方案中的PC1、PC2机,必须用Windows XP操作系统,有线部分采用的是以太网结构连接。图中的HPNA是home phoneline network adaptor的缩写,表示家庭电话线网络适配器。图中的PC3和移动计算机,并不要求非使用Windows XP操作系统不可,别的windows版本也行。移动计算机和主机之间的网络连接利用的是无线形式。 如果希望建立混合网络,这种方案已经具备典型的功能,并且不需要花费很大就可以扩充网络规模。 关于连通操作: 图1显示的结构只能表示物理连接关系,物理连接完成后,还需要进行连通操作,网络才可真正投入使用。连通操作包括局域网内部各个计算机之间的连通,和局域网与Internet之间的连通。前者连通建立的步骤如下: 1. 鼠标点击 开始,进入控制面板,点击"Network and Internet Connections网络和Internet连接",选择网络连接( Network Connections),进行下一步。 2. 选择进行"两个或多个LAN的连接" 3. 右键点击一个连接. 4. 确定完成连接任务. 局域网之内的连通操作就完成了。 再说局域网与Internet之间的连通,这种情况主要考虑速度与成本两方面的兼顾。多机上网,最省事的办法是每个机器占据一条独立的电话线,但这不是一般用户能承受起的,资源的浪费也太大。另一个办法,可以使用住宅网关,但这样成本需要增加,不是最佳途径。比较好的方法是使用一个计算机作为主机服务器。这不仅技术上可行,还有很多别的优点,如: ①:由于Windows XP有内建的防火墙,主机介于Internet和终端机之间,可以利用主机的防火墙保护局域网中的分机免受来自Internet的攻击。 ②:主机是"隐匿在" Internet和局域网之间的,充当了网关的脚色,在分机上,用户感觉好像自己是直接连在Interne上一样,察觉不到中间还有主机存在。特别是可以使局域网中的每台计算机同时上网。大大减少了设备投资。 ③:除主机必须使用Windows XP操作系统之外,局域网内的计算机可使用早期的windows版本。 ④:如果局域网中需要使用不同的媒体(例如有线和无线混合),可以利用Windows XP作为过渡的网桥。 ⑤:虽然有网络资源和设备的共享功能,但也可以限制别人对私有文件和数据的访问,特别是将文件存放在主机上的时候,更具有这种优势可用。 ⑥:利用"万能即插即用"功能,可以随时扩充局域网的规模。 六. 方案之二 下面是这种方案的结构示意图。该方案适用于小型办公室。与上一个方案比较,主要是去掉了无线部分,主机与分机之间不采用电话线连接,而是采用了电缆或双绞线连接。所有分机都通过一个HUB与主机连接到Internet上,并可以支持打印机共享。这其实就是最常见的那种局域网的结构。 该方案完成物理连接之后,还需要进行下列操作: 1. 打开网络连接文件夹或找到网络连接的图标. 2. 右键点击"connection to the Internet you want to share(共享Internet连接)"然后再右键点击"Properties(属性)" 3. 选择"Advanced(高级)"任务条。 4. 选择"Allow other networkusers to connect through this computer′s Internet connection(允许另外用户通过这个计算机连接到Internet)"检查框,并选定。 5. 点击 OK.结束操作。 启用Windows XP的防火墙,必须进行设置,不设置是不起作用的。设置过程: 1.打开网络连接文件夹或找到网络连接的图标. 2.右键点击"connection to the Internet you want to share(共享Internet连接)"然后再右键点击"Properties(属性)" 3.选择"Advanced(高级)"任务条。 4. 选择"Protect my computer and network by limitingor preventing access to this computer from the Internet(利用这个计算机限制从Internet进入的访问并保护我的计算机和网络" ,在其下面有一个Internet连接防火墙的检查框,鼠标点击选定。 5. 点击 OK.结束操作。 七. 几点说明 A.主机必须采用Windows XP操作系统,局域网内的计算机可以使用早一些的windows版本,如:windows98、windows ME、windows2000等等。 B.这里提供的是典型的情况,想扩充网络规模基本上可以照此叠加。 C.本文是依据英文测试版本进行的试验,不能保证将来的正式版本。特别是中文正式版本的性能与此完全一致。 参考资料: 创建局域网及配置管理 一.概念: (一).局域网的概念: 局域网做为网络的组成部分,发挥了不可忽视的作用。我们可以用Windows 9X把众多的计算机联系在一起,组成一个局域网,在这个局域网中,我们可以在它们之间共享程序、文档等各种资源,而不必再来回传递软盘;还可以通过网络使多台计算机共享同一硬件,如打印机、调制解调器等;同时我们也可以通过网络使用计算机发送和接收传真,方便快捷而且经济。 局域网是一个范围可大可小、简单的只有2台运行着Windows95的计算机连网(以工作组方式工作),也可以是幅员辽阔的高速ATM网和以太网混合使用、运行多种平台的大型企业。 (二).网络的类型: 1、按网络的地理位置分类 a.局域网(LAN):一般限定在较小的区域内,小于10km的范围,通常采用有线的方式连接起来 b.城域网(MAN):规模局限在一座城市的范围内,10~100km的区域。 c.广域网(WAN):网络跨越国界、洲界,甚至全球范围。 目前局域网和广域网是网络的热点。局域网是组成其他两种类型网络的基础,城域网一般都加入了广域网。广域网的典型代表是Internet网。 (二).硬件指南:网络硬件设备 组成小型局域网的主要硬件设备有网卡、集线器等网络传输介质和中继器、网桥、路由器、网关等网络互连设备。以下主要介绍网卡、集线器等网络传输介质和中继器、网桥、路由器、网关等局域网互连设备。 1.网卡 网卡(Network Interface Card,NIC)也叫网络适配器,是连接计算机与网络的硬件设备。网卡插在计算机或服务器扩展槽中,通过网络线(如双绞线、同轴电缆或光纤)与网络交换数据、共享资源。 Realtek 10/100M,这是我们实例中所使用的网卡 二.组网: 返回顶部 (一).硬件配置:服务器:普通PC机,主板:intel 815,硬盘:迈拓40G,CPU:PIII933,内存:512M ,显示器:ACER。 其他:双绞线一箱(300m),16口HUB一个,RJ45头32个,网卡:Realtek 10/100M 16块。。 由于服务器需要安装两块网卡来用SyGate维护管理,两个网卡的设置请参阅如下的动画。 三.网络维护: 返回顶部 SyGate 4.0是一种支持多用户访问因特网的软件,并且是只通过一台计算机,共享因特网帐号,达到上网的目的。使用SyGate 4.0,若干个用户能同时通过一个小型网络(包括您的笔记本电脑),迅速、快捷、经济地访问因特网。SyGate 4.0能在目前诸多流行的操作系统上运行,譬如:Windows95、Windows98、Windows NT, Windows2000等操作系统;同时,SyGate 4.0还支持多数的因特网连接方式,这包括:调制解调器(模拟线路)拨入、ISDN(综合业务数字网)、线缆调制解调器(Cable Modem)、ADSL以及DirectPC等方式。 SyGate 4.0具有以下优势: 易于安装 SyGate在数分钟之内便可以安装完成,并且通常不需要其他外加的设置。和其他代理服务器软件(proxy server)不同的是,SyGate仅安装Server便可以了。 易于使用 SyGate拥有直观的图形化界面,懂得操作Windows的人员均会操作。SyGate启动后便在后台运行,不需要人工的干预。当SyGate检测到局域网内有上网 要求时,它能自动地连接到因特网上,免去了每次需要手工拨号的烦恼。用户可以不间断地、透明地浏览因特网、收发电子邮件、聊天、使用FTP以及操作其他的小程序等等。局域网内非Windows用户,如Macintosh、Solaris和Linux,均能通过TCP/IP协议上网。 四.Windows 对等网创建与维护 返回顶部 (一).建网软件要求 在一个局域网中,Windows 95、98、NT和2000等操作系统可以并存。当然,即使你的电脑是在DOS下面跑的,也可以实现联网。由于Windows操作系统才是广泛应用的系统,本文不准备讨论DOS联网。 建网硬件要求 要组建电脑网络,无疑需要能将电脑连在一起的硬件设备。最简单的办法是,使用特制的电缆,将两台电脑的并口或者串口联接起来,通过Windows的“直接电缆连接”实现联网。这种联接电缆可以自制,也可以到电脑城购买。其缺点是,只能联接两台电脑,联网距离较短、方式古板,实际应用很不方便,通常要求将一台电脑用作服务器,另外一台用作客户端来实现联网。 但更为普遍采用的是网卡加网线的联网方式。从插槽上分,网卡有ISA和PCI两种;从速度上分,网卡又有10MB和100MB甚至传输速度更高的网卡。要求不高的话,一块PCI 10MB网卡就够用了。 五.疑难解答 返回顶部 (一).网卡安装故障检查方法 如果无法安装网卡驱动程序或安装网卡后无法登录网络,请按下述步骤检查处理: 1.选择“控制面板”/“系统”图标,打开“系统属性”窗口; 2.在“系统属性”窗口的“设备管理”标签的“按类型查看设备列表”中,双击“网络适配器”条目前的“ ”号将其展开,其下应当列出当前网卡; 3.如果“设备管理”标签中没有“网络适配器”条目或当前网卡前有一“X”号,说明系统没能识别网卡,可能产生的原因有网卡驱动程序安装不当、网卡硬件安装不当、网卡硬件故障等等; 参考 LAN(局域网)一词指位于同一区域甚至同一建筑物内的中小型计算机网络,字典上的解释是:将计算机和字处理机等电子办公设备连接在一起构成的办公室或建筑物内的网络系统。相信大多数人都在学校里、当地图书馆或朋友家里。接触过局域网。 随着宽带互联网日益流行,许多人家里都有几台计算机,家庭局域网正在形成规范。通过局域网共享宽带互联网访问可降低成本,不需要每台计算机都连接调制解调器和单独的IP地址。但如何构建一个家庭局域网共享宽带互联网访问呢? 网络带宽表示 网络带宽以兆位秒Mbps测量,通常不用兆字节秒MBps表示。一个字节有八个二进制位组成,多数人都熟悉MBps。当前局域网多为10base-T(10Mbps或1.25MBps)和100base-TX(100Mbps或12.5MBps)的以太网,使用类似标准电话线的RJ-45接口,通过网络电缆把集线器(或路由器、交换器)和计算机连接起来就构成了以太网。 网络布线 开始组建家庭局域网之前,应多少了解一些可用网络电缆的区别。这取决你家中PC机需要安排的位置,因为可能需要在墙上打眼,以穿过五类网络电缆。对家里地方不宽敞的人,这可能是令人畏缩的任务,甚至不太可能。如果你想避免穿墙打眼的麻烦,无线局域网也很方便,但应注意,无线局域网通常速度不够快,花费也高的多。另一种选择可考虑10Mbps电话线套件,利用你现成的电话线在计算机之间传送数据,可购买D-Link,Linksys,3Com和Netgear等公司的产品。不想采用无线局域网的人,可选择五类双绞线网络电缆。如果对电缆不熟悉,下面列出了电子工业协会EIA关于电缆分类的解释。根据电缆的速度和质量,可将电缆分为六类: 一、二类电缆:数据传输速度低于10Mbps(普通电话线) 三类电缆:数据传输速度达16 Mbps 四类电缆:数据传输速度达20 Mbps 五类电缆:数据传输速度达100 Mbps 五类电缆增强:数据传输速度达200 Mbps 六类电缆:数据传输速度达600 Mbps 五类电缆十分普通,连接以太网费用也较低。如果你计划穿墙打眼或使用超过50英尺五类电缆,应购买细电缆,自己动手将RJ-45插头接在电缆两端。注意,别忘了电缆穿过墙之后再接RI-45插头。 连接RJ-45插头 五类电缆连接RJ-45插头并不困难,但需要专用连接工具,可从当地五金商店买一把或从朋友处借用。操作时小心剪掉约1/4英寸电缆外塑料皮,露出电缆里面8根彩色线,注意放入RJ-45连接器里面电缆线的次序: 1、白绿 2、绿 3、白橙 4、兰 5、白兰 6、橙 7、白橙 8、棕 应仔细展开8条彩色编码线,放入RJ-45插孔中,用专用工具压紧。有条件时可用RJ-45测试器验证一下是否连接可靠,以免将来麻烦。 需要的硬件 首先确保每台计算机里都安装了网卡,100base-TX或10base-T网卡,型号、尺寸任意。注意,一般选PCI网卡,各网卡速率应一致。100base-TX网卡数据传输率较高,适合于大量数据传输,如数字电影或其它大的多媒体文件。 组建局域网需要使用集线器,交换器或内置集线器的路由器,集线器只不过用于将你所有的计算机连到局域网上。如果你只有2台计算机并且不打算增加数量,可以用一段电缆直接将2台计算机连起来,缺点是你试图共享宽带互联网访问仍然有麻烦。如果你想多台计算机访问宽带互联网,使用路由器是个好主意,可以选购Netgaer,D-Link和Linksys等著名网络公司的产品。 典型的以太网使用集线器或交换器,两种设备都有单独的连接器,用于将每台计算机连接到局域网上。集线器与交换器的主要差别在于吞吐量,集线器在所有在用的端口间分配吞吐量,因此4端口100base-TX集线器每个在用的端口只有25Mbps吞吐量。交换器更贵些,但允许每个端口全速运行。 假如你准备设置一个只有单个宽带互联网连接的局域网,应确保你的DSL或有线电缆供应商给你提供的是外置调制解调器。多数外置调制解调器通过网卡连接到你的计算机,你可把具有调制解调器的那台计算机设置为路由器,虽然这并不推荐。作为一个例子,你将电话插头接入宽带调制解调器,然后经RJ-45(双绞线)电缆连至集线器/交换器/路由器,从此,你的任一台计算机都可连接到互联网上。 设置Windows网络 确保你准备在局域网上使用的每台计算机,都有足够的五类电缆已连到了集线器或路由器。现在你可能已安装了适当的网卡以及相应的驱动程序,右击“网络邻居”,选择“属性”,可以看到当前已经安装的协议和网卡。要设置网络,应确保所用的网卡已安装了TCP/IP协议。如果你使用的微软操作系统是Windows98或更高版本,网络设置相当简单,Windows网络作为操作系统的基本选项之一应该已经安装了。如果你至少在一台计算机上使用的是Windows Me,你可运行家庭网络向导,将一步步引导你完成设置。记住,你需要使用相同的组名设置你网络中的每台计算机。在Windows95/98中,需要进入网络属性,并确保所有设置为缺省。你的互联网服务供应商ISP可能已经告诉你,如何设置TCP/IP,怎样连接到互联网。你可能是静态IP地址,或是动态IP地址,取决于你的ISP。静态IP地址设置需要的时间稍长一点,如果你想给互联网用户提供服务,如FTP,Web服务器或任何其它服务,静态IP地址是不错的。如果你分配的是IP地址,你的TCP/IP协议属性获得的应是自动选择的IP地址。要检查你的计算机是否已被集线器/路由器分配了一个IP地址,可使用Windows TP配置(进入开始 传输大点的东西,用iostat 1 查看io 来源于网络,供您参考
保持可爱mmm 2019-12-02 02:20:25 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT