上一篇《??美团二面：如果每天有百亿流量，你如何保证数据一致性？??》给大家初步分析了复杂分布式系统中数据不一致的问题是如何产生的。简单来说，分布式系统中的多个子系统（或服务）协同处理一个数据，但是这个数据的最终结果并不符合预期。这是一个非常典型的数据不一致问题。当然，在分布式系统中，还有其他数据不一致的情况。例如，多个系统必须维护一条数据的多个副本。导致一个系统中的数据副本与其他副本不一致，这也是数据不一致。但是这些文章主要讲的是如何解决我们上一篇分析的数据不一致的问题。一、多系统订阅数据回顾先来看一张图，是讲系统架构解耦时用到的一张图。好的！通过上图，我们来回顾一个系统解耦后的架构图。实际上，实时计算平台会将数据计算的结果传递给一个消息中间件。那么需要数据计算结果的数据查询平台、数据质量监控系统、数据链路跟踪系统都会订阅其中的数据。这就是现在的架构，所以本系列文章就分析到这里，也能理解为什么之前要做系统架构的解耦。因为一个核心数据可能被很多系统需要。通过引入MQ实现架构解耦后，各个系统都可以按需订阅数据。2、核心数据监控系统要想解决核心数据不一致的问题，首先要对核心数据进行监控。有同学会认为这个监控是用falcon之类的系统来监控业务指标，其实不是这样的。这种核心数据监控，做一个指标监控是远远解决不了的。在我们的实践中，我们必须自己开发一个核心的数据监控系统，根据自己的需要，针对复杂的数据校验逻辑开发大量的监控代码。我们以数据平台项目为例。自己写的数据质量监控系统需要从MQ消费一些核心数据指标。这些数据指标由实时计算平台计算得出。那么这个时候就需要自定义一套监控逻辑，不同的系统是完全不同的。比如在这类数据系统中，数据指标A的监控逻辑很可能是这样的：数据指标A=数据指标B+数据指标C-数据指标D*24。每个核心指标都有自己的监测公式。这个监控公式是负责开发实时计算平台的同学。他们写的数据计算逻辑，知道数据指标之间的逻辑关系。所以这个时候，有一个很简单的想法：首先，数据监控系统从MQ中消费每一个新计算的核心数据指标。然后，根据预先定义的监控公式，从数据查询平台调用接口，获取公式需要的其他数据指标。然后，根据公式进行监测和计算。如果经过监控和计算，发现几个数据指标之间的关系不符合预先定义的规则，那么此时可以立即发出告警（短信、邮件、IM通知）。工程师收到警报后，可以立即开始调查数据不符合一组预定义业务规则的原因。这样就可以解决数据问题的第一个痛点：无需等待用户发现并反馈给客服，自己的系统会第一时间发现数据的异常时间。同样，这里放一张图给大家直观感受一下。3、如何监控电商库存数据如果以电商中的库存数据为例，也是一样的。假设你要监控电商系统中的核心数据：库存数据。首先，第一步，在微服务架构中，一定要闭嘴。也就是说，在彻底的服务化中，需要保证所有的子系统/服务如果有任何库存更新操作，都是通过接口调用来请求库存服务。只有库存服务负责在数据库层面对库存数据进行更新操作，从而完成关闭。闭口后便于监控库存数据。可以使用MySQL的binlog采集技术，直接使用Mysql的binlog同步中间件来监控数据库中存量数据涉及的表和字段。InventoryService对应的数据库中的表只要涉及到增删改查操作，都会被Mysqlbinlog同步中间件采集并发送给数据监控系统。此时，数据监控系统可以使用预定义的库存数据监控逻辑来检查库存数据是否准确。这种监控逻辑可以有很多种。例如，异步线程请求可以在后台发送到实际的C/S存储系统，查询实际库存数量。或者按照一定的库存逻辑来查，比如：虚拟库存+预售库存+冻结库存+可售库存=总可用库存。当然这只是一个例子，具体怎么监控，大家根据自己的业务来做。4、数据计算链路跟踪至此，我们已经解决了第一个问题，主动监控系统中的少量核心数据，可以在第一时间收到报警，发现核心异常。但是这时候我们还需要解决第二个问题，就是当你发现核心数据有问题的时候，如何快速排查问题出在哪里？比如你发现数据平台的某个核心指标有错误，或者电商系统某个商品的库存数据有错误，你需要排查数据为什么不对，你应该怎么办？做？很简单，此时我们就要跟踪数据计算环节了。也就是说，你必须从一开始就知道数据经过了哪些环节和步骤，每个环节是如何更新数据的，更新的数据是什么，记录每次数据变化后的变化。监控检查点。例如：步骤A->步骤B->步骤C->2018-01-0110:00:00。第一次数据更新后，数据监控检查点，数据校验无误，盘点数据值为1365。步骤A->步骤B->步骤D->步骤C->2018-01-0111:05：00。第二次数据更新后，数据监控checkpoint，数据校验错误，库存数据值为1214。像上面这样的数据计算环节的跟踪是必须的。因为你必须知道一个核心数据，它每一次更新一个值都经过了哪些中间步骤，有哪些服务更新过它，那个数据变化对应的数据监控结果是什么。这时候，如果你发现某个库存数据有误，可以马上通过人肉搜索找出这个数据的历史计算链接。可以看到这个数据是从最开始出现的，然后是每次变化的计算环节和监控结果。比如上面的例子，你可能会发现第二次更新库存数据的结果是1214，这是错误的。然后你看一下，发现第一次更新的结果其实是正确的，但是第二次更新的计算环节多了一个步骤D，那么这个步骤D可能就是服务D做的更新。这个时候，可以询问服务D的服务人员，可能会发现服务D没有按照约定的规则更新库存，导致库存数据错误。这是解决核心数据问题的一般思路。5.百亿流量下的数据链路追踪如果要做数据计算链路，其实只有一个技术问题需要解决，就是在百亿流量的高并发下，每天的计算链路任何一个核心数据都可能是上亿，这个时候应该怎么存储呢？其实我给大家推荐的是使用elasticsearch技术来存储这种数据链接。因为es一方面是分布式的，支持海量数据的存储。而且，它可以做高性能的分布式检索。在排查数据问题时，需要对海量数据进行高性能的多条件检索。因此，我们可以独立创建一个数据链路跟踪系统，设置如下操作：数据计算过程中涉及的每个服务都需要对核心数据进行处理，并向数据链路跟踪系统发送计算链路日志。然后，数据链路跟踪系统可以将计算链路日志存入存储器，并按照一定的规则建立相应的索引字段。例如索引字段：核心数据名称、核心数据id、当前请求id、计算节点序号、当前监控结果、子系统名称、服务名称、计算数据内容等。此时，一旦发现一个错误某条数据，根据这条数据的id，可以立即从es中提取出历史上所有的计算环节。此外，还可以为数据链跟踪系统开发一个用户友好的前端界面。例如，可以根据请求id在界面上显示一个由每个请求对应的一系列技术步骤组成的链接。此时你会有怎样的体验？我们可以立即清楚地看到是哪个计算环节导致了数据错误，以及每个子系统/服务在这个过程中对数据做了哪些修改。那么，我们就可以追本溯源，直接定位错误逻辑，分析修改。说了这么多，还是想给大家一张图，大家一起感受一下过程。6.自动化数据链路分析至此，如果能在贵公司的大型分布式系统中实现上述数据监控+链路跟踪机制，就已经可以很好的保证核心数据的准确性了。通过这种机制，当核心数据出错时，可以第一时间收到告警，第一时间拉出数据计算链路，快速分析数据出错的原因。但是，如果想进一步节省排查数据错误的人力，可以在数据链跟踪系统中加入一套自动化的数据链分析机制。你可以反过来想。如果你现在发现数据不对，手边有数据计算环节，你会怎么查？当然不用说了，大家坐在一起分析，人脑分析。比如步骤A执行后数据应该是X，步骤B执行后数据应该是Y，步骤C执行后数据应该是Z。结果，哎！C步执行后，为什么数据是ZZZ？？看来问题出在步骤C！然后进入步骤C，发现是服务C更新的，这时候服务C的负责人开始查看自己的代码，看看为什么收到一个数据Y后，他的代码会被处理成数据ZZZ，而不是数据Z？终于找到代码问题了，这时候就ok了。本地复现了数据错误，后来修了bug再上线。因此，这个过程的前半部分可以完全自动化。也就是你写一套自动分析数据链接的代码，只是模拟你人脑分析链接的逻辑，一步步自动分析每一步的计算结果。这样就可以实现数据监控系统和链路跟踪系统的连接。数据监控系统一旦发现数据错误，可以立即调用链路跟踪系统的接口进行自动链路分析，判断数据错误是否由链路中的服务bug引起。然后，收集所有信息并向相关人员发送警报通知等。相关人员看到报警后，一目了然，大家立刻就知道是哪个环节、哪个服务导致了数据错误。最后，该服务的负责人可以根据报警信息立即在自己的系统中查询代码。7.小结到此为止，我们已经基本梳理了在大型责任分布式系统中如何保证核心数据的一致性。
