基于模式挖掘的可靠性治理探索与践行

对于那些拥有上亿用户数的在线平台而言，保持高效率与稳定度是不可或缺的条件。从字面上理解，可靠性要求故障少、可信赖。与安全性一样，它们都是信息系统的固有属性之一，也是保障产品质量的关键因素。

对照Google的可靠性模型来看，测试同学会投入很多精力在用例设计、测试执行、持续交付等环节上，研发同学则会更多关注监控、应急和故障分析等。但往往由于项目进度和人力因素，在设计和编码阶段对可靠性的投入和关注不足，导致后续需要付出更高的成本发现和解决潜在隐患。有鉴于此，我们希望能找到更低成本且以更有效的方式发现和治理这些隐患，从而提升系统整体的可靠性。

一种是过于具体，Case by Case解决问题，类似算法的过拟合，过拟合的问题在于对更广泛范围内的问题缺乏有效性。以幂等性为例，想验证一个接口是否幂等性可以很快完成并很快补充接口幂等性相关的测试用例，但是对不同的接口、服务、系统以及不同的幂等性设计，那么还有哪些其他的问题和风险，我们是不是也没有办法更加全面地关注检测到并控制这些随之而来的风险。

类似这些问题如何找到更好的解决办法？我们重点看一下模式对可靠性治理的启发。模式在维基百科的定义是：揭示了这个世界上人工设计和抽象思想中的规律。

技术场景的模式会更加丰富些，这类模式和可靠性治理想找到的模式非常接近。

举例缓存设计的两种常见模式：

第一种是Cache-Aside（ 旁路缓存），也是使用比较广泛的一种方式，它只有在缓存没有命中时，才会查询数据库并更新缓存。

另外一种是Write-throught（ 只写模式），这种模式在每次数据库变更时都会同步更新缓存。

对比第一种模式，第二种模式的优点是逻辑更清晰、操作更简单、缓存命中率更高；缺点是不常请求的数据会被写到缓存中，导致缓存更大。这种模式的优点是可以实现多线程同时执行，并且不需要额外的cpu资源，对于一些特殊场景的应用非常适合。

（编辑：银川站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!