个人网站 名字,做物流的网站有哪些功能,ps做网站的分辨率多少,如何寻找一批做网站的公司前言
在分布式系统中#xff0c;虽然我们会使用各种分布式事务的方案#xff0c;来保证各个系统之间的一致性。但是#xff0c;很多时候往往事与愿违。
尤其是现在很多公司都采用最终一致性的方案#xff0c;而所谓最终一致性#xff0c;无论是本地消息表、事务消息、还…前言
在分布式系统中虽然我们会使用各种分布式事务的方案来保证各个系统之间的一致性。但是很多时候往往事与愿违。
尤其是现在很多公司都采用最终一致性的方案而所谓最终一致性无论是本地消息表、事务消息、还是任务重试系统之间的调用都是有可能失败的。
而一旦发生失败就需要有一套机制来发现这些不一致的问题这时候就需要做数据对账了。
对账时机
一般来说根据对账的时机分为两种离线对账和(准)实时对账。
实时对账一般来说基本都是准实时也就是说并不能保证无延迟但是一般可以控制在秒级别的延迟上。而离线对账一般都是D1的核对。 D1:D指的是自然日包括工作日和节假日。1指的是第二天也就是说数据发生后的第二天进行核对。 T1:T指的是交易日一般来说就是工作日所以T1指的就是数据发生后的下一个工作日进行核对。 技术实现
那么对账的技术实现上一般主要就是两种要么是写代码核对要么是写SQL核对.
写代码就是查出需要比对的两条记录然后进行字段的比对不一致的就抛出来。
写SQL就是做join查询或者子查询然后通过where条件比较需要核对的字段不一致的就抛出来。
写代码这种核对方式一般来说都是通过定时任务实现的通过运行定时任务然后去扫表或者去远程拉数据然后在业务代码中进行核对这种方式的优点就是比较通用不管是数据库还是文件还是远程接口都可以做核对。缺点就是一旦数据量大了代码核对的时效性就会比较差而且代码运行存在失败的可能。万一数据量特别大就可能会出现扫表扫不动文件加载到内存导致OOM等问题。
所以写代码的核对方式不推荐
那么更好一点的方式就是写SQL了因为数据都在数据库(数仓或者大数据框架)中这些都可以通过SQL进行查询如下就是比较两个系统中金额是否一致的SQL:
SELECT OUTbiz NO,bill NO,
OWNER
FROMbill item
WHEREOUT biz NO IN (AND charge ON amount - charge off amount 0’ SELECTbiz id FROMcollectionCASEitem detail WHERECASEitem state COLLECTING AND cur ovd principal
那在哪写这些SQL进行核对就有很多种方案了一般来说有以下几个:
1、离线数仓主要用于离线数据核对。我们现在每天会把需要离线存储的数据同步到数仓中然后在数仓中写SQL进行数据的核对。
2、在线数据库离线核对的话发现问题比较慢好一点的方案是在在线库做核对可以直接在数据库中写SQL进行数据核对。为了避免数据核对影响真实业务可以考虑在备库中执行SQL。但是有的时候数据核对可能是多个系统之间的这时候就要做跨库join但是并不是所有的数据库、所有的引都文持跨库join的。
3、准实时数据库还有一种方案那就是不直接在数据库中写SQL而是把数据同步到其他的地方比如通过监听binlog的方式把MYSQL的数据同步到实时数仓比如我们公司内部用的就是AnalyticDB把需要做核对的数据同步到ADB中我们会尽量放到一个空间下面然后在这里面写SQL作核对。同步出来的这个ADB数据不仅可以做核对还可以用于查询或者做报表,
4、ETL核对还有一种比较常见的方案那就是通过ETL工具进行数据核对ETL包括了数据的提取、清洗、转化及加工所以在这个过程中也是可以做核对的。
5、flink核对flink是一个非常牛X的流处理框架可以通过fink进行数据核对。 核对与告警
有朋友提问:如果通过sql语句发现有不一致的数据,一般是怎么处理?是发告警通知开发人员还是说需要将有问题的数据标记出来过段时间重新核对?
我们一般来说告警的话人工一定要跟进
至于说过段时间重新核对这种我们一般在报警规则中把他屏蔽掉了。有需要重新核对的我们会做一些延迟核对或者二次核对。或者直接报警规则设置成多次失败后再报警或者告警值调高一点
这样就是职责单一核对就是核对报警就是报警。有报警人就要看否则都是无效报警那有效报警也没人看了.
