- 综合排序
- 最热优先
- 最新优先
- 来自专栏Lcry个人博客
运维常说的 5个9、4个9、3个9 的可靠性，到底是什么鬼？
在系统的高可靠性（也称为可用性，英文描述为HA，High Available）里有个衡量其可靠性的标准——X个9，这个X是代表数字3~5。 X个9表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，我们通过下面的计算来感受下X个9在不同级别的可靠性差异。 下面就展示了这几个9的允许中断的时间表： 3个9：(1-99.9%)*365*24=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。 扩展一下： 1个9：(1-90%)*365=36.5天 ，表示该系统在连续运行1年时间里最多可能的业务中断时间是36.5天。 2个9：(1-99%)*365=3.65天，表示该系统在连续运行1年时间里最多可能的业务中断时间是3.65天。
7.4K30编辑于 2022-11-29 - 来自专栏运维开发王义杰
系统可靠性的量化：理解“多少个9”的含义
在谈论系统架构设计时，我们经常会提到系统的可靠性，并用“多少个9”来量化这一概念。对于很多人来说，这个表述可能显得抽象和难以理解。 在这篇文章中，我们将深入探讨系统可靠性的量化概念，特别是如何将“多少个9”转换为系统每年的理论故障时间，从而更直观地理解这一指标。 一、什么是系统可靠性？ 系统可靠性是指系统在规定条件下和规定时间内能够正常运行而不发生故障的能力。在软件架构和系统架构的领域中，这通常意味着系统能持续提供服务，不受中断或故障的影响。 二、“多少个9”是什么意思？ “多少个9”实际上是一种衡量系统可靠性的方式。它代表的是系统正常运行的时间占总时间的比例。例如，“三个9”即99.9%，表示系统在99.9%的时间里是正常运行的，而0.1%的时间可能出现故障。 六、结论 理解和量化系统的可靠性是系统架构设计中的关键部分。通过将“多少个9”转换为具体的年故障时间，我们可以更直观地理解和比较不同系统的可靠性水平。
2.3K10编辑于 2024-01-27 - 来自专栏用户7261497的专栏
服务器可靠性:一个9的差距究竟有多大?
服务器可靠性:一个9的差距究竟有多大? 说到关键业务系统的可靠性，经常用到所谓4个9或者5个9，也就是99.99%与99.999%。 那么，4个9或者5个9的差距有多大，差距是0.009%，还不到0.01%。但对于系统而言，恰恰是这不到0.01%的差距，决定了系统完全不在一个档次上。 下面小编赵一八笔记给大家说说服务器一个9的差距究竟有多大? 所谓5个9的系统，一年内不能正常工作的时间少于5分15秒。对应4个9的系统是不超过52分36秒。 与小型机、大型机等具有高可靠性的产品相比，采用容错方案构建的系统，其高可靠性不是来自容错服务器产品，不是来自产品不出错，而是通过特殊的体系架构应对故障的发生。 对于小型机、大型机而言，如果也采用容错结构，那么系统的可靠性要跨上一个新的台阶，但成本代价不是一般用户可以承受的。
2.1K20发布于 2020-11-10 - 来自专栏超级架构师
【可靠性工程】Microsoft 可靠性模式
可用性以正常运行时间的百分比来衡量，并定义了系统正常运行和工作的时间比例。可用性受系统错误、基础设施问题、恶意攻击和系统负载的影响。云应用程序通常为用户提供服务水平协议 (SLA)，这意味着必须设计和实施应用程序以最大限度地提高可用性。
56220编辑于 2022-09-26 - 来自专栏超级架构师
【可靠性工程】GCP 可靠性核心原则
由于 SLO 是制定有关可靠性的数据驱动决策的关键，因此它们是站点可靠性工程 (SRE) 实践的焦点。 错误预算 错误预算计算为 100% – SLO 在一段时间内。 核心原则 Google 的可靠性方法基于以下核心原则。 可靠性是您的首要功能 新产品功能有时是您短期内的首要任务。 但是，从长远来看，可靠性是您的首要产品功能，因为如果产品速度太慢或长时间不可用，您的用户可能会离开，从而使其他产品功能变得无关紧要。 可靠性由用户定义 对于面向用户的工作负载，衡量用户体验。 100% 的可靠性是错误的目标 你的系统应该足够可靠，让用户满意，但又不能过于可靠，以至于投资不合理。定义设置所需可靠性阈值的 SLO，然后使用错误预算来管理适当的变化率。 当错误预算减少时，放慢速度并专注于可靠性功能。 设计和操作原则 为了最大限度地提高系统可靠性，以下设计和操作原则适用。在架构框架可靠性类别的其余部分中详细讨论了这些原则中的每一个。
1.1K10编辑于 2022-09-26 - 来自专栏技术从心
kafka可靠性？
kafka最初是被LinkedIn设计用来处理log的分布式消息系统，因此它的着眼点不在数据的安全性（log偶尔丢几条无所谓），换句话说kafka并不能完全保证数据不丢失。
56320发布于 2019-08-06 - 来自专栏centosDai
可靠性规则
支持库和应用程序可靠性（例如正确使用内存和线程）的可靠性规则。 可靠性规则包括： 规则 描述 CA2000:丢失范围之前释放对象 由于可能发生异常事件，导致对象的终结器无法运行，因此，应显式释放对象，以避免对该对象的所有引用超出范围。
77930编辑于 2022-02-26 - 来自专栏超级架构师
【架构质量】可靠性系列#1：可靠性与韧性
可靠性与弹性——可靠性和弹性之间有什么区别，为什么重要？ 2. 可靠性增强技术——以 DIAL 中的“D”和“A”为例，我们将研究一些可以纳入与发现和身份验证相关的设计中的可靠性增强技术。 4. 可靠性增强技术——以 DIAL 中的“I”和“L”为例，我们将研究一些可用于与错误和限制相关的设计中的可靠性增强技术。 我的目的是深入了解 Microsoft 如何看待可靠性以及我们为提高客户服务可靠性而采用的流程和技术。 那么什么是可靠性？ 最后一点让我们明白了我认为可靠性和弹性之间的区别。 可靠性是云服务提供商追求的结果——它就是结果。弹性是基于云的服务能够承受某些类型的故障，但从客户的角度来看仍保持正常运行的能力。
59010编辑于 2022-07-29 - 来自专栏让技术和时代并行
可靠性基础-冗余
它是指对组件或系统进行复制，以提高整个系统的可靠性和可用性。分布式系统由多个组件组成，如果其中一个组件发生故障，整个系统都会受到影响。 它涉及拥有关键硬件组件的多个副本，例如： 电源 网卡 RAID存储 散热风扇 认识到系统可靠性和可用性的重要性，硬件制造商整合了冗余组件和功能，以最大限度地降低硬件故障影响整个系统的风险。 它提高了系统的可靠性、可用性和性能。虽然冗余有其好处，但它也带来了一些挑战，例如成本和复杂性。因此，在实施冗余时，必须权衡收益与成本，并确保冗余组件得到良好配置和维护。
1K10编辑于 2023-10-09 - 来自专栏超级架构师
【可靠性工程】GCP 定义您的可靠性目标
您将了解如何迭代您定义的服务级别目标 (SLO)，并使用错误预算来了解如果发布其他更新，可靠性可能会受到影响。 根据用户体验选择 SLI 并设置 SLO 本架构框架部分的核心原则之一是可靠性由用户定义。尽可能靠近用户测量可靠性指标，例如以下选项： 如果可能，请检测移动或 Web 客户端。 衡量服务器的可靠性应该是最后的选择。 例如，使用 Stackdriver Monitoring 监控 Compute Engine 实例。 您更改的速率会影响系统的可靠性。但是，频繁进行小幅更改的能力可以帮助您更快、更优质地交付功能。根据客户体验调整的可实现的可靠性目标有助于定义客户可以容忍的最大变化速度和范围（功能速度）。 有关更多信息，请参阅架构中心可靠性类别中的构建协作事件管理流程。 使用错误预算来管理开发速度 错误预算会告诉您您的系统在某个时间窗口内是否比所需的可靠性更高或更低。
92520编辑于 2022-08-26 - 来自专栏码上修行
Kafka 消息可靠性
在 Kafka 工作机制 一文提及了 Kafka 消息的不可靠性。本文就 Kafka 消息的三种不可靠性（重复、丢失、乱序），分析它们出现的内部原因和解决办法。
1.1K40发布于 2019-06-26 - 来自专栏超级架构师
【可靠性测试】什么是可靠性测试：定义、方法和工具
什么是可靠性测试？ 可靠性定义为在特定环境中指定时间段内无故障软件运行的概率。 执行可靠性测试是为了确保软件是可靠的，它满足其目的，在给定的环境中指定的时间量，并能够呈现无故障运行。 1) 重测信度 考虑以下我们正在测试功能的情况，比如说在上午 9:30 并在下午 1 点再次测试相同的功能。稍后，我们比较两个结果。我们在结果中得到了高度的相关性。然后我们可以说测试是“可靠的”。 它是一种特殊类型的可靠性，由多个评估者或法官组成。它处理不同评级者/观察者提出的评级的一致性。 例如，考虑参加歌唱比赛并从多个评委那里获得 9、8、9（满分 10）分的参赛者。 但是，如果他的得分是 9、3、7（满分 10），那么它就不能被认为是“可靠的”。 注意：这些评分将在很大程度上取决于不同评委/评分者之间的普遍共识。 CASRE 可靠性测量工具基于现有的可靠性模型构建，有助于更好地估计软件产品的可靠性。该工具的 GUI 提供了对软件可靠性的更好理解，并且非常易于使用。
5K20编辑于 2022-09-28 - 来自专栏企业平台构建
RabbitMq可靠性分析
当然我们所谓的可靠性主要指的以下几方面（个人认为）： 生产消息时，如果broker处理成功/失败，是否一定会告知生产者 消息生产者告知消息发送成功/失败，是否broker也是一致 消息被消费，broker
51920发布于 2019-08-07 - 来自专栏后台技术底层理解
消息队列的可靠性
但是rabbitMQ事务操作太耗费性能，因为为了保证可靠性，需要同步等待机制，等待你成功。 confirm机制，先设置 channel 为confirm,如果接受到消息，回调这个接口，接受成功。
95510发布于 2020-08-04 - 来自专栏code-x
RabbitMQRocketMQ消息可靠性保证
发布者确认需要手动开启，默认是没有开启的，也就是说默认情况下我们消息发出去就完事儿了，但是服务端有没有成功处理并不一定，此时虽然消息发布成功但是broker可能并没有正确处理该消息导致消息丢失，所以为了消息的可靠性 broker的磁盘损坏仍然会导致数据丢失，而如果broker是集群部署的，如果集群中所有broker的磁盘都损坏，此时消息也会丢失，由于硬件故障是无法避免的，只能根据消息的重要性做集群，集群规模越大、磁盘可靠性越高
72510编辑于 2022-11-17 - 来自专栏蓝天
测试 Linux 的可靠性
LTC 尤其感兴趣的领域是 Linux 可扩展性、适用性、可靠性和系统管理 —— 所有的目的都是为了使 Linux 更适用于企业。 Linux 可靠性度量 目标 对 IBM Linux Technology Center 来说，Linux 可靠性工作的目标是，使用 LTP 测试套件对 Linux 操作系统进行超长时间的测试，重点在于 测试环境概述 本文描述的是使用 LTP 测试套件进行的 30 天与 60 天的 Linux 可靠性度量测试的测试结果和分析。 我们的可靠性测试中使用的 LTP 版本是 20030524，这是当时可以获得的最新版本。 她有三年的 Linux 工作经验，当前的工作是 Linux 内核验证与 Linux 可靠性度量。可以通过 lge@us.ibm.com 与她联系。
2K30发布于 2018-08-07 - 来自专栏全栈程序员必看
可靠性测试的基础知识——可靠性的计算方法
n个子系统组成，当且仅当所有的子系统都有能正常工作时，系统才能正常工作，这种系统称为串联系统 设系统各个子系统的可靠性分别用R1, R2, R3……, Rn表示，则系统的可靠性 R=R1×R2×R3×… X个9 X个9表示在软件系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，一般都是3~5。 我们接着往下计算： 1个9：(1-90%)*365=36.5天 2个9：(1-99%)*365=3.65天 6个9：(1-99.9999%)*365*24*60*60=31秒 可以看到1个9和、2个9分别表示一年时间内业务可能中断的时间是 36.5天、3.65天，这种级别的可靠性或许还不配使用“可靠性”这个词；而6个9则表示一年内业务中断时间最多是31秒，那么这个级别的可靠性并非实现不了，而是要做到从5个9》6个9的可靠性提升的话，后者需要付出比前者几倍的成本 ，所以在企业里大家都只谈（3~5）个9。
8K10编辑于 2022-09-06 - 来自专栏后端码匠
【RabbitMQ】消息可靠性投递
RabbitMQ消息可靠性投递 什么是消息的可靠性投递？即保证消息百分百发送到消息队列中去，消息发送端需要接受到mq服务端接受到消息的确认应答。 是默认值，CORRELATED值是发布消息成功到交换器后会触发回调方法 publisher-confirm-type: correlated thymeleaf.cache: false 可靠性投递 return */ @GetMapping("/confirmCallback") public R confirmCallback() { log.info("可靠性投递 2023-11-12 15:48:42.146 INFO 6840 --- [nio-9090-exec-5] c.c.codingce.controller.SendController : 可靠性投递 INFO 4848 --- [nio-9090-exec-1] c.c.codingce.controller.SendController : 交换机到队列通过returnCallback 可靠性投递
53550编辑于 2023-11-12 - 来自专栏后端/图像融合/机器学习/爬虫
RabbitMQ怎么保证可靠性
前言 RabbitMQ相信大家都非常熟悉了，今天咱们来聊聊怎么保证RabbitMQ的可靠性。 那什么时候会出现问题呢？ 第一种是生产端出现的问题。 总结 从生产端、RabbitMQ以及消费端三方面介绍了一下怎么保证RabbitMQ的可靠性，另外还有关于死信队列和延迟队列的内容在这篇博客中，大家有兴趣可以看一下。
44510编辑于 2024-06-19 - 来自专栏sql与spec性能
pgsql的数据可靠性
如何保证数据的可靠性pgsql的数据页大小是8K，linux文件系统页大小是4K或8K（getconf PAGE_SIZE查询），数据页大小是8K，磁盘扇区是512B，因此在数据页并发写入磁盘时每个io 由于写入扇区不同，可能因为传输或硬件故障等原因导致写入失败，一部分写入，一部分未写入；针对对数据可靠性要求较高的环境，可以通过full_page_writes和check_sum配置来保证数据的可靠性full_page_writes
48920编辑于 2023-09-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号