对比分析法

    花时间处理重要的事，而不是紧急的事。。。

    紧急的事处理了就过去了，然而并不一定有什么长远的价值，或许在一瞬间体验了各种不同的感觉；而重要的事则不一样，事处于长远的考虑。。。

    本篇文章主要提供一种解决问题的思路：也就是对比分析法，熟悉测试的人都知道，在测试中经常会有基线，也就是对比的标准。。。基准测试，maybe。。。

    1、 离线任务无法完成

    在进行离线任务的时候，发现任务一直不能结束。

    查看相关的监控，发现业务没有流量洪峰，数据量根据相关人员的反馈也是正常的数据量，查看计算存储资源，发现还剩余很多。

    在正常情况下，一般运行的时间也就几个小时，今天这次任务居然跑了N个小时还未结束。

    离线任务是从数据库中拉取数据，然后进行统计分析，打开出问题的任务，发现数据量在几亿条，查看相关的日志，也是正常的，未发现明显的问题，主要耗费时间的地方在join的操作。

    查看以前的历史任务，发现数据量的条数只有千万级别，数据量增长了十倍之多，再次询问业务方，上层调用出现问题，从而导致数据重复，最后就是任务无法继续。

    总结：对比成功的案例和失败的案例，找出不一样的地方，从而能更快的排查问题，当然，业务监控还是需要进行改进，能明显的看到历史的相关曲线图，从而能大大减少排查的时间。。。。说的都是不可靠的，查出来的日志等相关信息才是可靠的。

    2、 同城异地业务延迟

    在进行同城异地搭建服务集群的时候，业务方总是要求进行双活，使用分布式存储的时候，不可避免的会造成相关的延迟，但是。。。正常的延迟时间应该不过是几毫秒而已，毕竟相互之间是高速互联的网络。。。

    业务是否能接受这种延迟？这种延迟带来的后果是不是会影响业务的正常运转，都是需要进行测试的。

    跨机房访问，会跨几次，如何来避免跨机房的操作，这个时候就需要进行相关的测试了，将不跨机房的操作，做为基准，统计相关的业务耗时情况；然后可以进行测试，跨机房一次需要的时间；跨机房两次需要的时间。。。

    同城异地，如果不是关键的核心业务，那就应该接受这种延迟，如果不能满足，就只能进行业务改造了。。。

    总结：将就近访问的时间作为基准，从而可以统计出最大的延时情况，最后结合业务的情况，从而进行相关的优化操作。

    3、 谨慎使用对比

    在使用对比分析的时候，不是所有的情况都满足这种条件，在进行对比分析的时候，因为是基于测试来做，从而在测试的时候，尽量保证只有一个变量在变化，从而才能得出尽可能正确的结果。

    在一般的测试的时候，可能分为平台的不同导致测试的结果不一致，使用的linux操作系统，或者windows操作系统；也可能因为数据量的不同而造成结果不一致，例如有的数据量很大，有的数据量很小。。。在不同的时候，选择不同的方法，要结合相关的实际业务情况来进行思考。

    拿着弱点和强点进行比较，可能会有促进的作用。。。但是你也需要考虑的是，这种对比对你来说，你一种拉伸的动力还是一种摧毁的动力。。。如果是拉伸的动力，那么你可能进步很快，但是如果是摧毁的东西，可能就是从入门到放弃。。。

    人嘛，总是喜欢对比。。。。然而，又有什么意思。。。

    有的时候，觉得思考过程更加重要，而所谓的一些操作步骤，随地一找，遍地都是。。。弄懂为什么更加重要

    例如在python之中，list和tuple有什么区别？都是线性存储，但是区别在于一个是可变的，一个不可变的，而这种区别体现在哪儿？为什么要选择tuple而不选择list。。。

    区别体现在操作上，list有各种增删改查的方法，而tuple则没有，对于使用方来说，区别又在哪儿。。。当你不希望别人修改你的数据的时候，可以使用tuple，当需要经常变化内容的时候，你可以选择list。。。两者之间的转化也很简单

    弄懂为什么？到底是要靠自己思考，还是别人的指引。。。靠别人的指引，那肯定是飞速的进步，不过也可能让自己的思维无法转动。。。靠自己思考，过程也是很艰难，但是却能训练你的逻辑思维。。。没有绝对的对，也没有绝对的错。。。

    瞎说什么大实话。。。心好慌。。。所有文章只是带动你的思考，打开你的思维。。。想象的空间是无限的。。。