聊聊最近的一个项目/你做了什么/你印象最深的功能点

视频社交平台 背景简述

那么我来说一下最近深度参与过的一个项目,就是视频社交平台,这个平台内容包括(医疗、金融、编程等等)垂直内容,您可以理解为一个垂直领域的头条(抖音),这个平台是一个ugc平台,不同于国外的类似Youtube这种平台,它可以专注于技术,它可以做到先播后审,即有人举报,才会有真人来看视频是否合规,毫无疑问,这是最高效的审核方式,国内的视频平台,绝对不可能做到这一点,国内的ugc内容平台,人力成本的很大比例就是审核,事实上,国内的所有平台都属于信息孤岛类型的互联网环境,所以必须是强人工环境,所以审核系统(视频运营)非常重要。

组织架构

5人研发团队,3个RD(一个前端),一个QA(测试),一个PM(产品经理),半个月更新一版(上线),Leader(部门经理)负责分配任务

产品研发流程

需求分析 -》需求评审(QA做用例评审) -》分配任务(leader) -》 填写工时 =》项目研发 =》code review =》 合并测试分支 =》 测试提测 =》bug fix(bug 修复) =》合并主分支 =》 项目上线

相关数据

50w用户数(uv),日活10w左右,单日有效审批增量2w左右审批任务,因为只做大陆广告主业务,所以白天上午10-12点,峰值qps在400-500左右,最高记录达到过600,因为有渠道商做引流操作。有少量的海外用户,谷值不到20的qps

主要负责模块

我个人主要负责的就是视频审核系统,我刚接手的时候实际上这套系统的审核效率非常低,您也知道,传统的审核逻辑是通过用户状态来进行审批动作,比如0代表待审,1代表审核中,2代表通过等等,这种审批逻辑在待审任务和审核员量级小的情况没有问题,但是如果审批量大或者审批员较多就会出现资源分配不一致的问题,也就是生产者-消费者问题。

设计思路

为了解决生产者和消费者过度耦合的效率低下问题,我设计了一个缓冲区,生产者不会直接和消费者产生关系,而是通过缓冲区解耦,这个缓冲区就是异步任务队列,队列容器我采用redis数据库,因为redis性能优势比较明显,同时内置的list数据类型比较契合队列这种数据结构,工具类内置了,初始化方法,入队方法,出队方法,队列长度,以及查重唯一方法。每当商户提交表单,此时并不会修改状态,而是将表单数据入库,同时将商户uid进行入队操作,遵循fifo原则,在消费者端使用多线程的方式进行消费,也就是出队操作,每一个线程对应一个审核员,通过消费方法进行传参,每次将出队的商户uid和线程传入的审核员id进行组合分配,然后在mysql端进行update操作,达到异步分配审核的目的。

加权队列

在此基础上,我还开发了基于异步任务队列的加权队列,用来对审核任务进行优先级分类和管理,将渠道方用户的审核顺序进行加权操作,主要设计了两套方案,一套是基于排序字段的逻辑,即队列中嵌套一个tuple,tuple中除了商户uid以外,加入一个倒序的等级字段,入队后通过等级字段进行倒序排序,从而达到加权的目的,第二套方案就是维护一个多队列的结构,优先级队列和普通用户队列进行顺序合并,达到加权的目的,celery也是采用这种多队列的方式进行加权,这两套方案各有优劣吧,第一套虽然可以将指定的商户进行加权,但是性能上要损耗一些,成本比较高,第二套方案不需要进行排序操作,但是原子性的细化操作不好处理。

消费模式

第一版采用多线程的消费方式其实是有一些问题的,那就是怎样保证缓冲容器中数据状态的一致性,多线程消费方式是并发的,也就是出队之后如果没有来得及更改队列长度,其他线程就会发生争抢问题,导致审核状态的不一致,比如重申问题,所以在执行消费方法的时候,需要先获取线程锁,再做出队和数据库更新操作,操作结束之后再释放锁,这个过程中,如果redis或者mysql宕机的话,还可能出现死锁问题,所以需要异常捕获机制的参与。

协程消费

项目后期,我改变了多线程异步消费的思路,采用协程的方式,主要考虑到协程虽然是单线程的,但是它是用户态调度,可以通过调度器自由的分配审核员的优先级,同时协程性能要比线程优秀,不会触发python的gil全局解释器锁,优化了出队的步骤,所以协程消费可以有效的提高审核效率。

协程是一种用户态的轻量级线程,协程的调度完全由用户控制,不像进程和线程是系统态,同时协程是单线程的,即可以共享内存,又不需要系统态的线程切换,同时也不会触发gil全局解释器锁,所以它性能比线程要高。具体使用场景和线程一样,适合io密集型任务,所谓io密集型任务就是大量的硬盘读写操作或者网络tcp通信的任务,一般就是爬虫和数据库操作,文件操作非常频繁的任务,比如我负责开发的审核系统,需要同时对mysql和redis有大量的读写操作,所以我后期将多线程改造成协程进行消费。协程我使用的python原生协程库asyncio库,首先通过asyncio.ensure_future(doout(4))方法建立协程对象也就是事件循环体系,然后根据当天审核员数量指定开启协程数,和多线程以及多进程的区别是,协程既可以直接传实参,也可以传不定长参数,很方便,然后通过await asyncio.gather(*tasks)方法启动协程,需要注意的是,如果是脱离tornado事件循环的单独协程任务,主方法需要声明成async方法,并且通过asyncio.run(main())来启动。协程虽然是python异步编程的最佳方式,但是我认为它也有缺点,那就是异步写法导致代码可读性下降,同时对编程人员的综合素质要求高,并不是所有人都能理解协程的工作方式,以及python原生协程的异步写法。

幂等性操作ack确认机制

事实上,当审核任务出队之后,如果在消费端出现意外,这个意外包含但不限于出对后tornado宕机、mysql宕机等等,导致出队任务没有进行流程化处理,所以我采用了ack验证机制,也就是缓冲区队列从单队列升级为双队列,把rpop出队改成redis内置的rpoplpush的原子性操作,出队后立即进入确认队列,在消费端完成审核任务后,对ack队列进行确认移除操作,如此,一次审批任务才算完结,如果任务生命周期内,任务一直存在于确认队列没有出队,那么轮询任务会将任务id移出确认队列,重新在缓冲区队列进行入队操作,这样就避免了,僵审任务的问题。

遇到的问题

在开发过程中,主要有几个问题,具有代表性:

重复消费

任务重复消费问题,也就是任务的全局唯一性问题, 两个人同时审批一个,一个人同时有两个审批任务重复提交,这里我入队之前会设置一个拦截器,这个拦截器基于redis中的set数据类型,在审批动作流转过程中,被审批人uid在集合中存储,审批结束后释放,如果审批中再次入队会被拦截器拦截下来。

任务丢失

这是QA曾经给我提的bug,任务丢失问题主要有三种可能性,第一种就是商户提交资料后,后台服务接收到了用户提交的资料,并且在mysql中写入了,但是入队的时候,redis服务挂了,导致入队失败,这种情况导致任务丢失,商户提交材料,但是永远没机会被审核,这个问题我采用一种轮询的方式进行检测,只检测用户状态为待审的用户,如果用户状态为待审并且没有出现在拦截器集合中,那么我们认为该任务异常,启动重新入队的操作

第二种就是队列中丢失,比如redis宕机,导致队列中数据丢失,这块主要是redis的数据持久化问题导致的,默认的rdb全量延迟持久化方式改成aof的增量实时持久化方式,防止重启或者宕机导致的数据丢失

第三种就是出队后没有及时进行审批操作导致的丢失,这里也可以通过轮询拦截器进行一致性比对来解决

内存溢出

当峰值审核量非常大的时候,单台redis可能承受不住压力,导致审核队列崩溃的问题,此时的解决方案主要通过搭建redis集群的方式解决负载均衡问题,我是通过docker搭建了三台redis服务,一主两从,三哨兵实力,集群结构是sential,也就是哨兵的监控模式,当某一台服务宕机后,哨兵会选举一台丛机升级成主机,以达到高可用的服务架构,

哨兵选举机制:

slave 优先级,通过 slave-priority 配置项,给不同的从库设置不同优先级(后台有人没办法),优先级高的直接晋级为新 master 掌门。 slave_repl_offset与 master_repl_offset进度差距(谁的武功与之前掌门的功夫越接近谁就更牛逼),如果都一样,那就继续下一个规则。其实就是比较 slave 与旧 master 复制进度的差距; slave runID,在优先级和复制进度都相同的情况下,ID 号最小的从库得分最高,会被选为新主库。(论资排辈,根据 runID 的创建时间来判断,时间早的上位);

这就是审核系统的介绍。

为什么不直接用开源的celery、KafKa、RabbitMq?

事实上,开源软件确实可以帮我们节省开发时间,但开源自身的发展方向一定有取舍,只会关注全球最通用的客户需求,新功能优先级的设定就不一定满足当下客户需求,这时自研就有它很香的地方,越来越多的客户也在享受自研的红利,自研比开源更快的适配客户需求并实际落地。

另外,由于出队业务我们采用了原生协程的方式,它可以直接集成到tornado的ioloop事件循环中作为回调方法运行,这样,我们只需要维护一个服务即可,降低了维护和监控成本,而如果采用celery,我们需要多维护两套服务,一套异步任务服务,一套定时任务服务。

以现实中的事情为例子,像华为、小米为什么要自研芯片?一直用美国的高通芯片不就行了吗?事实也一再教育了华为,美国一旦对其芯片技术进行制裁和断供,华为连5g芯片手机都上不了市,所以自研技术体现在核心竞争力,而不是躺平,等着别人施舍。

最后,您肯定也带过团队,一个团队需要成长,如果只局限于调用三方开源库,团队内部根本接触不到底层核心技术,久而久之,这个团队就失去了核心竞争力,成为了“调包侠”,所以,一个技术团队能否在业务上攻克技术难题,就看它的自研能力是否过硬,可以不重复造轮子,但是不能没有造轮子的能力,就像核武器一样,你可以不用,但是你不能没有。

results matching ""

    No results matching ""