检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
副本选主,保障Kafka实例持续提供服务。 RabbitMQ集群提供镜像队列,通过镜像在其他节点同步数据。单节点宕机时,仍可通过唯一的访问地址对外提供服务。 RocketMQ使用一主两备架构,备节点通过数据同步的方式保持数据一致。当节点故障时,通过Raft协议自动切换主备关系,保持数据强一致性。
PERF05 性能优化 性能优化工作中,需警惕“过早优化”的问题。我们的基本指导策略还是首先让系统运行起来,再考虑怎么让它变得更快。一般只有在我们证实某部分代码的确存在一个性能瓶颈的时候,才应进行优化。除非用专门的工具分析瓶颈,否则很有可能是在浪费自己的时间。另外,性能优化的隐含
检测模块要简单:故障检测系统、模块要比被检测系统、模块简单。 在检测到问题后,需要通过监控系统及时发现,迅速处理。 故障快速恢复 故障恢复指恢复产品执行规定功能的能力,一般情况下恢复越快影响越小。 结合业务情况,综合考虑技术实现难度、技术方案复杂度、成本等设计合适的故障恢复方案: 自动恢复:对于影响业务的故障
根据错误响应码进行有针对性的重试;对于临时性故障,如错误码指示为系统繁忙时,可等待一段时间后重试,否则无需重试。 请求SDK中内置了消息重试时,客户端无需重复重试。 多层业务栈一般只在源端重试,避免逐层重试。 父主题: RES09 故障重试
提高性能和可用性:通过分区网络,可以优化网络性能和可用性,避免网络拥塞和单点故障的影响。 定义每个分区的边界,并按照方便管理和控制的原则为各网络区域分配地址。例如,对于一个Web工作负载,划分Web区、App区、Data区等。最重要的边界是公共网络(互联网)与应用程序之间的边界,这个边界是您的
将VPC和本地网络连接到一个网关中(二层互联),助力企业客户灵活构建大规模、高性能、高可靠的云上/云下网络。 NAT gateway 通过地址转换的方式,使多个云主机可以共享私网IP访问用户本地数据中心或其他VPC,并支持云主机面向私网提供服务。 应用组网 (用户<->云) ELB
中断的时间会比较少,从而需要保障故障场景下的业务快速恢复,可采用双活/多活容灾;对于重要业务,允许一定的业务中断时间,可采用主备容灾;对于一般业务,允许中断的业务时间可达到天级,则可采用远程备份;对于一些不重要的业务,其业务中断对外部客户没有影响,则不需要进行容灾。 父主题: RES04
检测到故障后需及时告警或自动恢复。 针对具体故障进行检测时,根据检测的类型通常可以分为资源检测、功能检测和业务检测。 资源检测:云环境中一般指虚拟化后的物理硬件资源及其对应的软件资源,具体包含CPU、内存、网络和磁盘资源等。 功能检测:对组成产品系统的各个内部模块对象进行检测的
选择合适的数据库资源 华为云提供了多款数据库服务,不同服务的优化方式和注意事项均有差异,可以通过以下四个不同考虑因素入手,选择合适的数据库资源: 兼容性:一般原则是平替迁移,选择云上数据库,是为了利用云上服务使得生产工作更聚焦到应用层,上云前系统中数据库的选型已经过业务实践的检验,基于对兼容性的
能下降、CPU/内存过载等,当应用系统内组件出现亚健康时,可能会导致应用系统对外业务成功率下降。 由于亚健康并非故障,因此针对亚健康的检测一般是针对业务监控指标设置阈值,当指标超过阈值时进行告警和恢复处理。 父主题: RES06 故障检测
rd则其他stream上的task已经执行完成,此时可以放心地回收这个block。 Pytorch的内存统计信息说明 pytorch的内存一般看三个峰值信息:allocated / active / reserved。allocated对应host上的tensor实际申请了但是没
动性能管理的办法来解决性能问题。除了管理上的措施外,解决性能问题需要在系统和架构设计、实现方案设计及编码实现上采取有效的技术手段来保证。 一般认为,性能问题通常由于体系架构或设计问题造成,而不是低效的编码引起的。性能问题在开发过程的早期已经引入,而大部分开发团队直到集成测试,或更
括CPU、内存、存储等,称之为纵向伸缩;另一种是单机节点处理能力不变,通过增加节点的数量来改变系统的处理能力,称之为横向伸缩。 系统设计时一般建议采用横向伸缩。采用横向伸缩时,要求业务与数据解耦,即将系统的业务处理逻辑与数据分离、数据(状态)外置,以实现业务节点(含资源)无状态,
r-num”,并在此基础上,规划需要的CPU核数和内存大小。 在规划内存时,要预留一定量的内存空间作为操作系统的buffer cache,一般预留20%。 从HDFS中读入数据时,要考虑block解压缩后的数据膨胀。 规划一定的磁盘作为缓存空间,包括缓存数据、日志、Shuffle数据。
确保重要任务的完成;如果不能在可用的时间内完成所有事情,被忽略的是最不重要的任务。主要用于处理瞬时突发负载导致超出系统处理的容量的情况,一般给重要任务赋予高优先级,最重要的行为优先得到处理。只适用于暂时超载的情况,如果超载不是暂时的,需要减少处理量,或者升级系统。如在性能过载场
COST05-02 建立可以量化的优化目标 风险等级 高 关键策略 成本优化是一项投资,而且是一个需要持续进行的流程。为了向公司或者组织的决策者、利益相关方说明投资的价值,就需要对成本优化自身,尤其是其执行的目标进行量化。从而在持续的优化活动中,都可以从决策者或者利益相关者那里得
设计原则 组织,流程和成本管理相匹配 在成本优化过程中,一个很重要的原则是需要将组织结构,流程和成本管理相匹配。需要建立“责权分明”的体系,否则即使用再好的成本优化工具,也无法将成本优化落到实处。 流程上,需要把成本管理作为各个上云流程中必备的一环; 组织上,需要投入适当的时间,资源和人力用于建立云财务管理的能力。
做出明智的决策,比之纯手工流程,最大程度避免了错误。 通过可观测性进行持续改进 可观测性是指通过观察系统的外部输出,推断其内部状态的能力。一般来说,云上应用的可观测性通常使用三种核心手段,一:指标,指标是系统状态的定量度量,例如 TPS、请求延迟、调用量等。二: 日志:日志是系统
实施威胁建模,需要有攻击者思维,像攻击者一样思考,发现潜在的暴露面/攻击目标及可用的攻击方法,从而发现系统中潜在的安全威胁、 建立相应的消减措施。 威胁建模的一般步骤如下: 确定范围:明确要进行威胁建模的云上系统范围,包括云服务、数据存储、网络架构等。 收集信息:收集关于云上系统的信息,包括系统架构图、数据流程、访问控制策略等。
灾措施,自动切换到另一个Redis使用。 建议 - 数据设计规范 分类 原则 原则说明 级别 备注 Key相关规范 使用统一的命名规范。 一般使用业务名(或数据库名)为前缀,用冒号分隔。Key的名称保证语义清晰。 建议 例如,业务名:子业务名:id 控制Key名称的长度。 在保证