审核回调原子化方案

最新推荐文章于 2024-08-15 15:53:19 发布
最新推荐文章于 2024-08-15 15:53:19 发布
阅读量359 收藏
点赞数
分类专栏： JAVA
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/foreverwingsfly/article/details/76187948
版权

要解决的问题：

目前审核分为三种，一种是审核评价文字，会变更评价的整体状态；一种是审核评价带图，会变更评价图片的状态；还有一种是审核回应，会变更回应的状态。现在存在一种情况，当审核方同时或者在很短的时间间隔内提交一个评价的多张图片状态更新请求，会出现某张图片的更新操作没有生效。

出现此问题的根本原因是因为，每次更新图片状态时，都会先读整个ReviewData，更新该图片在ReviewData中的状态，然后再根据ReviewData更新Tair & 索引表 & Base表。下面是一次出现错误更新的示例：

解决方案：

NOTE: 由于此方案以前未经线上验证，所以目前只实现图片审核原子化，但是为评价审核原子化预留了处理字段，图片审核原子化验证没问题后，年后会上线评价审核原子化。

分布式锁+延时队列+时间戳：

分布式锁：

什么是分布式锁：如果不同系统或者同一系统中的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，这时便需要使用分布式锁。

本方案的实现：使用Tair实现了简单的分布式锁，使用了SetNx接口，如果Tair中不存在当前key，则setNx成功，如果Tair中存在，则setNx失败。设置超时时间为1分钟。

延时队列：

本方案的实现：使用了Mafka的消息粒度延时的功能，可以为每个消息设置不同的延时时间。

实现思路：
基础版

以Review为维度在Tair中建锁，当审核回调更新图片状态时，执行以下步骤：

  1. 先获取picId对应的reviewId, 构建该reviewId对应的Key；
  2. 获取该图片所在Review的锁(setNx)，如果获取到(setNx成功)，则执行更新操作；
  3. 如果获取不到，则按照图片在评价带图中的位置确定不同的延时时间，发送到mafka延时队列，以消费消息的方式来执行更新操作。为了防止读写Tair失败，将锁的失效时间置为1分钟。

下面为执行流程图：

改进版

如果按上述思路来实现，会引入另外一种更新出错，例如对一张原始状态是1的图片进行2次审核回调更新操作，第一次图片新状态是2，第二次图片新状态是1，即整个更新是（1→ 2 → 1）。第一次更新操作未获取到锁，扔到延时队列，第二次获取到锁后执行了更新操作（图片状态 1 → 1），待第一次更新操作被消费时，图片状态更新操作（图片状态 1→ 2)。

为了解决此问题，需要增加时间戳判断，每次审核回调请求来的时候，都记录下当前系统时间(auditTime)，存在ReveiwAuditMsg中。并且在执行一次更新操作后，以当前图片ID为key，将当前操作的auditTime记录在Tair中，表示上次更新时间LastTime（失效时间1分钟）。在执行更新操作之前，比较当前ReviewAuditMsg的auditTime和LastTime，如果当前auditTime < LastTime， 则说明此次更新为无效更新，只记log。

下面是审核回调更新操作的完整流程图：

excute: 执行了更新操作， send_mafka和send_mafka_success: 加锁失败，存入mafka， consume_mafka： 消费mafka消息， expire_msg: 当前消息无效

NOTE ： 我们使用的Mafka机器的系统时间比ugc-review-service所在机器的系统时间快了3秒，所以会有计数和Mafka队列消息记录对不上的情况。

前后数据对比：

更新效果对比

以2016年1月21日为例，当天共有16,293次图片审核回调更新请求；有3280次请求获取锁失败，会存入队列后被消费；有918次请求存入队列后变为过期更新。

下面为方案上线前出现的错误更新：

ID 变更类型 变前 变后 时间 解释

213391736 信审     2016-12-15 17:32:41  
213391748 信审

picId: 2391693565 status: 1

picId: 2391969716 status: 1

picId: 2391113970 status: 1

picId: 2391693565 status: 5

picId: 2391969716 status: 1

picId: 2391113970 status: 1

 2016-12-15 17:32:42

将照片2391693565置为审核删除状态

213391749 信审

picId: 2391693565 status: 1

picId: 2391969716 status: 1

picId: 2391113970 status: 1

picId: 2391693565 status: 1

picId: 2391969716 status: 5

picId: 2391113970 status: 1

 2016-12-15 17:32:42

将照片2391969716置为审核删除状态，

但覆盖了picId: 2391693565的状态


此例中，几乎同时更新了picId=2391693565 和picId=2391969716的状态，造成了picId=2391693565的审核操作失效（状态是1→ 5 → 1)。

下面为方案上线后的更新记录示例：


247191427 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:52:17 加锁成功，直接更新
247191428 信审 1 2 2017-01-22 07:52:17  
247191429 信审 2 1 2017-01-22 07:52:18  
247191462 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:52:22 加锁失败，消费消息更新
247191473 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 2

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:52:23 加锁失败，消费消息更新
247191476 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 2

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 2

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:52:23 加锁成功，直接更新
247191479 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 2

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 2

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:52:24 加锁成功，直接更新
247191484 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 2

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:52:24 加锁成功，直接更新
247191487 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:52:24

加锁成功，直接更新

更新picId=2396237778 状态 1→ 2 → 1，

ID=247191505的操作失效

247191505 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 2

2017-01-22 07:52:26

过期审核信息

 加锁失败，过期审核信息
247193207 信审 1 2 2017-01-22 07:56:42  
247193209 信审 2 1 2017-01-22 07:56:42  
  用户编辑        
247193206 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:56:42 加锁成功，直接更新
247193240 信审

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

2017-01-22 07:56:46

 

 加锁失败，消费消息更新
247193261 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

 2017-01-22 07:56:48

加锁成功，直接更新

更新picId=2396846539的状态 1→ 2 → 1，

操作247193271失效

247193263 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 2

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:56:49 加锁成功，直接更新
247193268 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:56:49

加锁成功，直接更新

更新picId=2396237778的状态1→ 2 → 1，

操作247193274失效

247193271 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 2

picId: 2396443150 status: 1

picId: 2396237778 status: 1

2017-01-22 07:56:49

过期审核信息

 加锁失败，过期审核信息
247193274 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 2

2017-01-22 07:56:49

过期审核信息

 加锁失败，过期审核信息
247193299 信审

picId: 2396861271 status: 2

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

picId: 2396861271 status: 1

picId: 2396846539 status: 1

picId: 2396443150 status: 1

picId: 2396237778 status: 1

 2017-01-22 07:56:53 加锁失败，消费消息更新

可以看到， 日志中有很多加锁失败，消费消息更新的记录，使用延时队列岔开了图片更新时间，使得每次只有一个操作在更新ReviewData，例如ID=247191462，ID=247191473，ID=247191427表示在很短的时间内更新了picId=2396861271, 2396846539, 2396443150的状态，其中ID=247191427加锁成功，直接在2017-01-22 07:52:17完成了更新操作，而ID=2396846539和ID=2396443150加锁失败，放入延时队列后，分别在2017-01-22 07:52:22 和2017-01-22 07:52:23完成更新操作。

性能对比

使用本方案前，ReviewPicService:updateReviewPicStatusByAdmin接口99线约16ms， 使用本方案后99线约为25ms，由于处理逻辑变复杂，增加了与tair的交互操作，99线上升10ms是在预期之内。


foreverwingsfly
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
钉钉接口开发——审批注册及回调接口编写
qq_38585508的博客
01-06 1万+
记：钉钉开发大坑之审批模块开发 审批接口开发——审批注册 虽然钉钉API提供了demo但是很多地方真的是一言难尽… 第一步：建立一个审批模板以及建立审批模板并且获得审批core，在你的应用开放审批权限。 接入必读 第二步：建议下载官方的demo，配置一些必要的参数 官方demo的后台 如果开发过程中对参数出处有疑问，可以参考下面这个官方解读的链接 官方对demo的详解 第三步：如果上述这些你都准备...
回调原子化方案调研
zxahu的博客
07-27 275
目前审核分为三种，一种是审核评价文字，会变更评价的整体状态；一种是审核评价带图，会变更评价图片的状态；还有一种是审核回应，会变更回应的状态。现在存在一种情况，当审核方同时或者在很短的时间间隔内提交一个评价的多张图片状态更新请求，会有某张图片的更新操作没有生效。 出现此问题的主要原因是因为，每次更新图片状态时，都会先读整个ReviewData，更新该图片在ReviewData中的状态，然后再根
java中审核订单流程图_Java必备主流技术流程图
weixin_35901475的博客
12-23 730
https://juejin.im/post/5d214639e51d4550bf1ae8df1、Spring的生命周期Spring作为当前java最流行性、最强大的轻量级容器框架，了解熟悉Spring的生命周期非常有必要容器启动后，对bean进行初始化按照bean的定义，注入属性检测该对象是否实现xxxAware接口，并将相关的xxxAware实例注入给bean，如BeanNameAware等以...
提升服务性能的 9 大优化方案！
最新发布
m0_58026506的博客
08-15 837
本文主要总结进行服务性能优化的几种方式，每一种方式在我们常用的中间件中都有所体现，我想这也是我们常说多学习这些中间件的意义，学习它们不仅仅是学会如何去使用它们，也是学习它们底层优秀的设计思想，理解为什么要这样设计，这种设计有什么好处，后续我们在架构选型或者做服务性能优化时都会有一定的帮助。此外性能优化方式也给出了具体的落地实践。希望通过实际的应用例子加强对这种优化方式的理解。此外要做服务性能优化，还是要从自身服务架构出发，分析服务调用链耗时分布跟 CPU 消耗，优化有问题的 RPC 调用和函数。
离线包方案
qq_34084869的博客
08-25 1775
网易(资源离线/JsBridge通信/接口预请求) 网易新闻客户端H5秒开优化 H5优势: 跨平台, 实时更新, 便于传播等 劣势: 功能(硬件访问能力, 离线功能), 性能, 体验等 一. 资源离线 静态资源加载耗时, 资源离线到本地, 能很好解决. web页面把静态资源生成zip包, 客户端在合适的时机拉去zip包并解压到本地, 持久化存储. 用户访问的时候拦截WebView发出去的页面请求, 直接返回对应的本地文件. 前端: 生成zip包 -> 更新
高频面试题基本总结回顾（含笔试高频算法整理）
热门推荐
张彦峰的博客
04-03 172万+
1.自我介绍+项目介绍+项目细节/难点提问-------这个主要看个人的经历了，每个人都不一样 2.基础知识点考核---------还是可以去增强自己的，也是这次的主要的一些总结思路 3.算法题-----------一般都是LeetCode高频题，这个得在找工作之前的好好的练习(d对常见的高频题进行总结分析，见对应的链接提示)
电商项目实战之分布式事务解决方案
CharlesYan的博客
08-12 1678
以电商下订单为例介绍分布式事务解决方案，主要包括：异步锁库存、异步解锁库存等
数据库MySQL详解
卓越无关环境，保持空杯心态——靡不有初，鲜克有终
07-24 18万+
全网最详细MySQL教程，2023持续更新中
QEMU深入浅出: 整体架构及线程模型
bemind1的专栏
08-16 2288
本文转自https://www.ibm.com/developerworks/community/blogs/5144904d-5d75-45ed-9d2b-cf1754ee936a/entry/20161222?lang=en 本文面向开发者，尝试在QEMU的工作机制方面做知识的分享，以期对新人贡献者们于学习QEMU代码方面有所裨益。 运行一个客户机时需要处理很多工作，包括执行客户机指令、处...
华为架构师8年经验谈：从单体架构到微服务的服务化演进之路
科技D人生
07-03 1万+
传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向 一 、传统应用开发面临的挑战 挑战1-- 研发成本高 主要体现在如下几个方面： 代码重复率高 在实际项目分工时，开发都是各自负责几个功能，即便开发之间存在功能重叠，往往也会选择自己实现，而不是类库共享，主要原因如下： 从技术架构角度看，
Writing an ALSA Driver(二)
Android系统攻城狮
12-19 943
后者alsa-driver包含许多精巧的文件，用于在Linux内核树之外编译ALSA驱动程序，较旧的2.2和2.4内核的包装函数，以适应最新的内核API，以及仍在开发或测试中的其他驱动程序。除SND_PCM以外，选择命令还支持以下组件：SND_RAWMIDI，SND_TIMER，SND_HWDEP，SND_MPU401_UART，SND_OPL3_LIB，SND_OPL4_LIB，SND_VX_LIB，SND_AC97_CODEC。也就是说，在打开的回调中，您可以根据需要修改复制的描述符（）。
鸿蒙开发者高级能力认证考试题目（96分）
喜欢猪猪
12-04 3567
[判断题] 2/2 云函数打包完成后，需要到AppGallery Connect创建对应函数的触发器才可以在端侧中调用 错误(False) [判断题] 2/2 每一个自定义组件都有自己的生命周期 正确(True) [判断题] 2/2 基于端云一体化开发，开发者需要精通前端、后端不同的开发语言 错误(False) [判断题] 2/2 首选项preferences是以Key-Value形式存储数据，其中Key是可以重复。 错误(False) [判断题] 2/2 Ha
支付域——路由系统
庄小焱
02-14 855
老王有家杂货店，承蒙街坊照顾，生意一直非常红火，慢慢地店面从一家，到两家，到三家，到最后基本上哪里有商业中心，哪里就有老王的店。店面也从当初只有几十平方米的杂货店变成几千平方米的老王连锁超巿。店面大了，大家都喜欢来老王的店里买东西，老王要管理的事情越来越多，要打交道的人越来越多，遇到的问题也越来越多。还有很多诸如此类的问题。“顾客就是上帝。”对于这些问题，老王有着朴素的想法，就是希望服务好顾客，让顾客再满意一点，自己赚得再多一点。发现问题，就要解决问题，我们看看老王是怎么解决这些问题的。老王定了3条策略，要
华为架构师经验：从单体架构到微服务的服务化演进之路
芒果不是程序猿v：lemon-hanwa 的博客
12-27 341
本次分享的技术大纲如下： 传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向 一 、传统应用开发面临的挑战 挑战1-- 研发成本高 主要体现在如下几个方面： 代码重复率高 在实际项目分工时，开发都是各自负责几个功能，即便开发之间存在功能重叠，往往也会选择自己实现，而不是类库共享，主要原因如下： 从技术架构角度看，传统垂直架构的特点是本地API接口调用，不...
服务运行原理
zxahu的博客
07-28 624
当我们写完代码，发布之后，服务器上到底发生了什么。目前我们的代码都是部署在tomcat上，tomcat运行在虚拟机上，虚拟机运行在物理服务器上。下面是服务运行的整体结构，分析每层都发生了什么，有助于我们了解服务是怎么运行的。 tomcat tomcat是一个开源的应用服务器，它可以运行Java web应用。先看下tomcat的结构： server: 表示这个tomcat
maven 学习笔记
zxahu的博客
10-02 614
MAVEN的核心是pom.xml，pom定义了项目的基本信息。 maven的坐标：maven世界中拥有大量的构件，为每一个构件都定义了唯一的坐标标识。 定义一个项目的基本坐标，需要： groupId（定义了项目隶属的实际项目）， artifactId（定义了当前maven在组中的唯一id）， version（定义了当前项目的版本），（以上为必写） package（定义了打包方式）默认为
java面试
zxahu的博客
04-12 562
快一年没看过java，面试的时候被虐成狗，还是复习一下吧 内容有些是从书上看到，有些是百度到的。JVMJava运行时的数据区域： 1. 程序计数器 a. 当前线程所执行的字节码的行号指示器，通过改变本区域的值来选取下一条要执行的指令 b. 如果线程正在执行的是java方法，那么计数器记录的是正在执行的虚拟机字节码指令地址 c. 如果正
HarmonyOS原子化服务：免安装，跨设备的便捷应用
"HarmonyOS原子化服务 - 武汉大学计算学院赵小刚" 在当前的万物互联时代，人们手中的智能设备数量日益增多，应用场景变得多元化，这使得应用开发面临更多挑战，用户对便捷获取和使用服务的需求也更加迫切。Harmony...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值