光缆故障测试

错误处理是软件开发中最困难且被忽略的部分之一，而且如果系统是分布式的，那么这将变得更加困难。

不错的论文写在“ 简单测试可以预防最关键的故障” 主题上。

每个开发人员都应该阅读本文。 我将尝试总结本文的主要内容，但建议阅读该文章以获取有关它的更多详细信息。

分布式系统中断很常见，最近的一些例子是

Youtube于2018年10月关闭约1小时以上

亚马逊在2018年7月的黄金交易日下跌

Google服务（如Map，Gmail，Youtube）在2018年停运了无数次

Facebook还面临着许多数据泄漏问题。

本文讨论了在分布式系统（如Cassandra，Hbase，HDFS，Redis，Map Reduce）中发生的灾难性故障。

根据纸张，大多数错误是由于2原因引起的

–由于复杂的事件顺序而发生故障

–灾难性错误是由于处理不当造成的

–我将在我在“ 设计压力对工程团队”的帖子中写到关于“忽略设计压力”的第三篇

HBase中断的示例

1 –负载平衡器从从站A到从站的传输区域R

2 –从站B的开放区域R

3 –主从属B拥有后，删除当前的Zookeeper区域R

4 –从属B模具

5 –将区域R分配给从属C和从属C打开区域

6 – Master尝试删除Zookeeper上的Slave B znode，并且因为错误的错误处理代码，slave b关闭并且整个集群关闭。

在上面的示例中，事件序列对于重现问题很重要。

当不复制块时，HDFS失败。

在此示例中，事件序列也是如此，当新数据节点启动时，它将暴露系统错误。

本文还有更多示例。

错误的根本原因

92％的灾难性错误是由于错误处理而发生的。

这意味着扣除了错误，但错误处理代码却不好，这听起来像您正在从事的许多项目！

1 –错误被忽略
这是25％失败的原因，我认为在许多实时系统中，这个数字会很高。

eg of such error
catch(RebootException e) {
log.info("Reboot occurred....")
}

是的，这种无害的日志语句忽略了异常，并且是错误处理的非常常见的反模式。

2 –追赶异常
这也很常见，例如具有通用的catch块并导致整个系统崩溃

catch(Throwable e) {
cluster.abort()
}

3 –评论中的TODO / FIXME
是的，真正的分布式生产系统在代码的关键部分也有很多TODO / FIXME。

错误处理的其他示例

} catch (IOException e) { // will never happen  }} catch (NoTransitionException e) { /* Why this can happen? Ask God not me. */  }try { tableLock.release(); } catch (IOException e) {  LOG("Can't release lock”, e); }  

4 –优先开发功能
我认为所有软件工程师都会同意。 这也称为技术债务，我想不出比Knight Capital破产更好的例子了，这是由于配置和实验代码所致。

结论

所有的错误都是很复杂的，但是重现更好的单元测试肯定会抓住这些错误，这也表明，在许多系统中进行的单元/集成测试不是在测试诸如服务中断并再次返回以及如何影响系统的场景。

根据上面的示例，看起来所有错误都是由于Java检查异常引起的，但是在其他系统（如C / C ++）中没有检查但未检查所有内容的情况也没有什么不同，开发人员有责任在各个地方进行检查。

附带说明一下，没有像Python这样的类型系统的语言使编写在运行时中断的代码变得非常容易，如果您真倒霉，那么错误处理代码将出现类型错误，并且将在生产中进行测试。

同样，几乎所有产品都将具有一些静态代码工具（findbugs）集成，但是这些工具并没有更加重视这种错误处理反模式。

链接到论文中提到的问题

HDFS

MapReduce

HBase的

雷迪斯

卡桑德拉

请分享您在生产系统中看到的更多反模式。

直到快乐的单元测试。

翻译自: https://www.javacodegeeks.com/2018/10/simple-testing-prevent-critical-failures.html

光缆故障测试