新工作第九周

今天是12月份的第一天,天气很不错,是一个好的开始。 第一个事情 是周一发现有些后台任务没有运行,突然意识到后台那么多任务,如果没有运行成功,会有什么后果?

所以再一次强调下后台任务(cron定时任务和队列任务,队列任务是处理队列数据的,和队列存储引擎不是一回事,当然队列引擎也会提供一些队列任务的功能,比如延时处理;队列任务用于消费存储引擎数据,需要有一个队列任务框架)的重要性,它们没有前台任务那么耀眼,但实际上非常关键,想寻找一个好的后台任务框架(队列任务框架)。

队列任务框架包含的功能?并发运行机制(根据队列容量自动启动多个任务,且任务之间不会处理同一个数据),单例运行机制(某个时间只能运行一个任务),运行结果跟踪,任务日志报表,纠错机制(比如强行杀死任务不会丢失数据),事务性(一个任务包含很多子任务,要么全部成功,要么全部失败),当然还有很多其它功能。在开发消息未读数功能的时候,简单写过一个,但还是希望找到一个开源的解决方案。

第二个事情还是和后台任务有关,管理后台和后台任务很多功能之间有共同性,我们业务是一个重运营的产品,很多功能可能都要发Push,每个Push还会有不同的路由功能。由于缺乏 框架规则 ,来了一个新需求,就会拷贝一大段代码去执行相同的任务(比如发送Push),从而导致越来越不可控,这涉及到几点。

首先基础代码库很重要,比如Push发送和Push路由应该封装好,方便调用,能做到这个,基本上就解决了大部分问题;其次就是技术理念的问题,尤其要大量使用队列机制,比如很多功能要发送Push,它就丢给Push队列处理,有专门的队列处理Push发送,类似于管道,连横合纵;然后就是规则,后台任务的业务模型是什么?要梳理出来,形成层级关系,简单来说就是知道有那些后台任务,并文档化,编写方式也要遵守一定的规则。

第三个事情还是和前面两个事情有些关系,是关于队列的,本周有个要做个活动,活动的完成条件就是发文、发评论、加关注,这些条件如果由前台API去完成,影响性能不说,还要修改很多API,那么应该怎么做呢?

以前要开发一个功能,比如和发文有关,就在API上丢个队列出来,这样累计下来发文API可能有m个队列,这里面就一个全局性的问题,因为大家时间有限,不愿意自己开发的代码影响其他代码,所以就又投递出个队列。

为了解决这个问题,和大家简单讨论了下,应该有个队列控制器的概念,就是所有的入队/出队应该统一封装下,有专门的管道处理。未来发文只会投递一个队列,然后由这个中心发文队列再投递出m个子队列(毕竟如果所有的子业务全部由中心队列处理,耦合度就太高了)。本次活动我们就采用了这种机制,先有个模型,然后再慢慢迁移。

说到活动开发,包括后台任务开发,大家可能觉得没有技术含量,其实想开发好也并不容易,另外我周记说的很多东西其实和“高深技术”无关,只是想着尽力去做好它,带来的可能是经验,而不是技能,这些东西在面试的时候好像也说不出来,那怎么办呢?做每件事情的态度决定了个人的工作方式,当然更重要的是要有自己的技术学习方法,在接触一门新技术的时候,有自己专门的一套方法。

第四个事情还是和开发理念有关,很多东西并不完全要由代码实现,比如为了实现热门话题、热门文章等等,完全可以由后台任务将需要的数据通过算法生成,不仅快还更容易调整。如果由前台实现,则要使用大量的数组函数,比如排重、排序、算分,数据量少发现不了问题,数据量大了呢?后台任务生成数据可能只要100行代码,而前台实现也许就要1000行,本次开发热门街区文章就采用了这种方式,甚至热门话题文章同样可以这样实现。

第五个事情,上几周说了mongodb的问题,本周也梳理了下,首先明确mongodb存储什么数据,那些地方在更新和查询。我们的Feed流就是基于mongodb运算的,这是我在以前公司没有用过的,真的不能太依赖Mysql,眼界应该更广阔点,等我将Mongodb运维搞得再明白一点,将来可以大量使用,在NoSql中,Reids和Mongodb好像是混的最好的。

第六个事情,我们一直说要改造和优化,应该怎么做?先做些调研,将每天所有表的新增记录条数统计了下,增长量太大的表就是优化的重点, 容量 决定了风险和性能;将每天mysql表的CURD数量统计了下,查询量最多的表就是优化的重点,并发性是决定性能很重要的条件;统计每天redis的操作数量(现在还无法根据key和指令进行细颗粒的统计);统计mysql和redis的响应时间,如果出现慢就要分析原因(索引?),很惊讶的是redis的操作时间居然比mysql select操作的时间要慢;统计所有API接口的响应时间,查询慢的接口和访问量大的接口是要优先处理的(很多人说花20%的时间解决80%的问题,其实某种意义上我更希望整体去解决,如果只是针对某个问题解决,只是表面好看而已);安装了xhprof(php7环境安装要注意,后面会专门写一篇)用于分析PHP性能,其实最主要的是了解一个接口或代码到底做了些什么。

有了这些数据,再细颗粒去分析,就可能会发现一些问题,比如说一个接口要查询20次redis,难道不是设计上有问题吗?一个接口客户端调用了无数次,但这个接口设计之初是要缓存的,是不是有问题?一个mysql查询次数太多了,是不是可以缓存?redis用于存储、队列、缓存,队列已经有了统一的管理器(只是雏形),接下去是攻坚哪一个?

我媳妇说发这些会不会不合适?我四年前就决定写一些总结,而总结如果写给自己看,就会很敷衍,写给其他人看会思考的更多;而且就算丢人的事情我也会写,其实并没有什么;如果没有这样的周记,过几年我就全忘记了,多年以后再看看这些记录,我会想起很多事情;写作是一门软技能,技术学习有三个阶段,阅读、构建、写下来,写下来才算是真正理解,否则只会自己觉得是理解的;很多人可能觉得我写的啥啊,其实如果每篇都看,我想会有一些收获的。

关于工作心得的问题,今天太匆忙了,我再整理下思路,下周再分享,唯一要提醒的就是淡定和微笑,最后说下我闺女,很喜欢画画和剪纸,表达能力也强了很多,每天早上能送她上幼儿园,每天回家看看她的大脸和小眼睛。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章