系统可靠性表示系统在规定的条件下和规定的时间内完成规定功能的能力。从整体上看系统能否完成预期的功能,有多个衡量指标。一般对于可修系统、机器设备常用可靠度、平均故障间隔时间(MTBF)、平均修复时间(MTTR)、可用度、有效寿命、和经济性等指标表示。对于不可修系统或产品常用可靠度、可靠寿命、故障率、平均寿命(MTTF)等指标表示。
系统的可靠性比性能、高并发更重要。没人希望整天分析错误数据、修复错误数据。任何一个错误都可能导致客户的损失。
成熟可靠的系统和不可靠系统之间的差别很大程度取决于:异常的正确处理。经验丰富的程序员和经验不丰富的程序员之间的差别是是否考虑到并正确处理可能发生的各种异常。这和处理用户输入数据的验证非常相似。
可以发现即使是运行多年,知名的互联网公司的大型系统都或多或少存在异常处理的问题。
1、系统可靠性概述
常见的评价系统可靠性的指标为:
(1)平均无故障时间(MTTF)
MTTF = 失效率的倒数,串联系统的失效率等于各部件的失效率之和
(2)平均故障修复时间(MTTR)
(3)平均故障间隔时间(MTBF)
(4)系统可用性
2、系统可靠性分析
3、冗余技术
分为结构冗余(静态冗余(屏蔽冗余),动态冗余,混合冗余),信息冗余和时间冗余
其中静态冗余是指模块的互相验证,使错误模块的输出被屏蔽,动态冗余是指有后备模块存在
提高系统可靠性的技术可以分为避错技术和容错技术
4、软件容错技术
N版本程序设计,不同版本的程序并行执行,需要解决同步问题,通信问题,表决算法等,也包括不同计算机环境等。属于后向恢复,不适合实时系统,是一种静态的故障屏蔽技术
恢复块方法,主块先进行运行,如果没有通过验证,则转入后备块运行。依赖于验证测试。
防卫式程序设计,就是在程序中插入断言等检查错误的代码,提前发现错误,进行估计和恢复。
也可以采用一致性检查,提前预测运行结果然后和预测值进行比较
能力检查是诊断程序检查程序中各个系统,如一次检查每个内存单元的读写能力
Try catch 的内部实现
异常必然发生
原因很多种:比如,网络不稳定、硬件故障、软件 BUG 等等。很多程序员如果不接触系统运维的话,很难考虑到并处理这些异常。这是问题原因的一部分。从这个角度看全栈工程师还是非常有用的。
异常处理的性能考虑
Donald Knuth: “premature optimization is the root of all evil”.
考虑到这个问题其实就已经进入的误区。该交给编译器的事情还是不要过多考虑了。
应该使用 try catch 的情况
说道 try catch 的性能,可能很多人会想到这会让程序变慢。其实不然,虽然它对应用性能的影响取决于编译器的实现,但是大部分情况下不会影响不抛异常情况下的执行速度,但是会有稍微内存占用的提升。并且,假如异常很少触发,使用 try catch 取代错误码然后 if 判断的方式可以提升速度,因为你不需要没次都判断这个错误码。使用异常代替判断还可以让程序更可读。
不应该使用 try catch 的情况
异常处理不应该取代 if else 用来做流程控制。
几个理念:Fail fast vs Retry vs Let it crash
Let it crash & Fail Fast
可以让错误停止扩散,保证整个系统的健康。可以重置系统状态、清理变量和内存占用等等。让系统恢复到原始状态。这对于恢复系统异常非常有用。
重试 Retry
在操作幂等的情况下,假如第一次操作失败,重试是处理异常的很好的方式。但是注意自动重试在处理不当的情况下会引起操作数量持续增长导致系统雪崩。
异常和错误的类型
第一种划分:
1. 编译错误:很明显,易处理。
2. 应用逻辑错误:最难发现问题;(类型系统有助于避免逻辑错误。Let it crash 主要针对逻辑错误和 BUG。)
3. 运行时错误:终止进程。
4. 生成的异常:throw 异常,尽早发现问题。
第二种划分:
1. 内部异常:可以内部恢复的异常;一般记录日志或打印相关信息告知用户错误。
2. 外部异常:Error,只能从外部恢复;一般打印堆栈信息并退出。还包括 RuntimeException, 软件 BUG,逻辑错误,错误使用 API。比如 NullPointerException。Let it crash 就是主要针对逻辑错误。这需要人工介入及时修复 BUG 。
异常区分的简单原则:
如果应用可以从异常中自动恢复,则为内部异常。如果不能,则为外部异常。
相信最后大家阅读完毕本篇文章后,学到了不少知识吧?大家私下还得多自学才能了解到更多的知识,当然如果大家还想要了解更多相关方面的详细内容的话呢,请登录课课家教育平台咨询哟~
¥1888.00
¥49.00
¥499.00
¥5999.00
¥10500.00