当你处理了几千万数据之后...

数据出问题了!

一次偶发的端上问题。

排查日志、监控、数据、代码逻辑。

服务没有添加事务性保障,不可避免的数据不一致:缓存有数据,数据库没数据或者相反;有A阶段数据,没有B阶段数据;该有的数据没有,不该有的数据却存在。

主从机制遇到了强一致性需求,偶发的缓存不一致。

服务被埋下了错误的逻辑,日积月累全量的错误数据。

... ...

不管是哪种情景,总之是数据变脏了。

怎么办?

一、处理当前问题的数据

对的,不是所有问题数据,是当前问题的数据,我们通常称这种为紧急问题,重不重要分情景另说。

用户的问题诉求,总是需要第一时间响应的,这个关系大公司产品的使用体验及公司形象,不容推延。

当然,在此之前,还是需要保留现场的,这些现场就是你排查的经过,每一步印证问题所提取的信息。

经验需要积累,教训也要留存。

二、修复引发问题的诱因

已经排查了问题的所在,也已经处理了个例的问题。那么接下来需要做的就是去修正服务的问题。

1、事务性保障问题

首先确定问题点是不是关键核心模块,是不是可以容忍

类如,交易系统,订单、库存、账户余额等关联,是一点错乱都无法忍受的,这就要从全方位进行数据一致性、正确性的保障。

服务逻辑层面的接口幂等性,业务操作的事务性,补偿、重试保障可靠性;消息中间件层面的或涉及消息的持久化、镜像容错等;数据存储层面的分布式缓存、数据库主从等,不一例举。

类如,阅读数,点赞数此等,很少人会去关注具体的多一个或者少一个(较真儿的除外),某大V写了篇文章,瞬间阅读数就查过了几万,转发上千,大V不会去关心本该有30001的阅读数只有30000。

此类数据,或者求个最终一致性,或者偶尔的遗失数据也可以忽略。也就不必要去添加额外的耗损性能的事务性保障。

2、主从与强一致性

主从与强一致性就像两个同极的磁铁,通常都是无法共存的。

以前遇到过有同事在提到“刚写进去又查出来”总会发笑,那种认为可笑的发笑。

而往往此时,我没有笑,只有疑惑和思考。疑惑是笑的同事,为什么会笑;思考是,是不是只有这样才能达到目的,有没有更好的替代方式。

通常现实中的业务都是大业务套着小业务,小业务套着更小的业务,环环相扣,一环连着一环。也如,一个人背着一打木板过河,放下一个踩上去,然后再放下下一个,有二必先有一。

所以,固化前一个变更,然后进行下一个变更,这,很正常。

然而,随着信息时代的爆炸式发展,信息服务的载重和载压一年便是一个量级,这就不断演化了现如今的许多多般复杂信息服务。而在这其中,便是这“主从”应运而生,横亘至今。

主从是一种分治的思想,读场景和写场景,量级不同,处理逻辑不同,保障性不同,所以涉及数据层面,就可以采用不同的提供方式。

缓存或者数据库,从主节点分离出一个或多个从节点专门用于数据的查询,从节点实时同步主节点的数据变更,数据会有一定的延迟,但是基本符合现实的应用场景,我们追求的是不那么强的最终一致性。

主节点则主要负责对数据变更的处理,以及,必要的数据查询,对于需要强一致性的场景

在实际的应用开发中,要特别注意筛选出对数据延迟零容忍的的业务逻辑,结合实际,应用主节点进行数据查询或者其它手段来保障数据的强一致性需求。

3.避免不必要的低级逻辑错误

这里,我们强调的是因为疏忽,非因个人能力而导致逻辑错误。

以前读过卡耐基的人性的弱点,人是情感的生物,一生都在与自己的弱点作斗争。人类自大,容易烦躁,又缺乏耐心。而这,往往会导致一些不必要的的失误。

属性赋值错了,未赋值;空值未判断; 特殊状态值未过滤等等,细枝末节往往影响深远

人不可能不犯错误,我们需要做的是怎么去避免不必要的错误

这里需要提一下就是 Code Review 的重要性。一个人很难发现自己错误,这其中有主观情感因素及客观认知问题。旁观者清,Code Review 的过程就是一个发现,纠正,优化改进的过程,每个人的关注点不同,或全局的架构设计,或细节的变量命名,层层滤网过滤之后,将极大的减少出错的可能。有一点需要指出的是,很多初次接触 Code Review 的开发人员,往往会有抵触情绪,或认为不必要,后羞于漏洞与众人,团队间在此方面需要建设共同的认知,意识,规约是非常有必要的。

三、处理脏数据

数据脏了怎么办?洗洗就好了!

脏数据好处理吗?好处理。问题是脏数据在哪里

单个用户问题的数据可以针对性的去处理。而那些隐藏的脏数据则需要去定位清洗。

1、限定影响范围

哪些数据受影响了?从什么时候开始?影响是什么

限定业务逻辑范围,影响的数据面,比如,粉丝+好友+群组关联的数据群,A关注了B,A多了一个好友,B多了一个粉丝,A把B放在了特定的群组里。

限定时间范围:从什么时候开始上线了或者从什么时候触发了有问题的业务逻辑,比如,对 X 对象的变更修改调整起始于 1 号,那么就需要查找所有 1 号至今的所有与 X 对象修改相关的活动数据。

限定影响:确定对数据的影响是什么,才能进一步决定下一步怎么处理,比如漏掉了一个属性赋值,那么是否可以根据其它状态属性进行修正?改删除的数据没有删除,是否直接删除就能解决问题?

2、筛查数据

有了第一步的基础,这一步需要做的就是找出问题数据。one by one,一个一个与校准值进行对比过滤。通常,我们会添加一个临时的处理接口进行实时的校验。

这里,需要指出的是,不同量级的数据的处理筛查方式上会有所区别。

如果,你的数据量是万级别的,那么单个顺序过滤就行了,不需要做什么额外的处理;

如果,你的数据量是十万级别的,那么你可能需要在处理接口上添加批处理

如果,你的数据量是百万级别的,那么除了接口批处理外,脚本的多线程处理也会需要。

如果,你的数据量是千万级别的,临时扩展一些数据处理节点也会大大提高处理效率。

3、处理脏数据

脏数据总归不是大量级的,处理之前,必要的校验,验证不可或缺。

选取测试数据或者从脏数据中选择少许进行处理结果验证。充分认证后,再进行全量处理。

四、附加订阅

posted @ 2020-09-23 11:40  WindWant  阅读(1071)  评论(1编辑  收藏  举报
文章精选列表