关于最近项目中优化的一些思考
前言
最近有一天领导突然跟对我说:让我负责一个项目优化,而我当时心里一万个xxx在飞,当时瞬间心里一激动,我平时吹牛逼划划水配合别人打打小手还可以,让我主动去负责一个项目优化,这不是要我的老命吗?
表面的我我曹?????我曹????我只想摸鱼啊。
内心的我我曹?不就是个优化吗?没啥问题,这次轮到我大显身手了,瑟瑟发抖吧 我的同事们!
背景
首先在之前我们的系统中出现过几次比较大的事故,当时临时的解决办法是:
- 1 Job 跑数据+缓存,目前这么处理,这个实时性是存在问题的,有好几家供应商反馈新增的一些班次,站点不能查到数据,解决办法是我们手动去job刷新了一下,但也不能总这样去处理!
- 2 其他的一些查询(包含不同渠道)数据存在很多join 关键,有用的没用的,都挤在哪一个sql里,导致现在的sql维护成本很大,一些非必要的join查询
- 3 基于第2点,在并发较大或者说查询较大的情况下,这些 sql 很容易拖垮db,以至于打满db连接
- 4 一些缓存数据基于业务,一些实时性,一致性与当前业务不匹配
- 5 代码混乱,数据和逻辑严重耦合
- 6 其他的一些问题比如线程使用等
优化什么?
在当时的背景条件下,我们做了大量的分析和调研,目前基于几个模块点,首页的一些城市站点,依赖于这些城市站点去查询相关的车次,然后展示等后续逻辑。
1 在创单前,大量的前置操作都是基于这些步骤
2 还有一些前置步骤,如一些热门城市站点,公告等其他业务
分析思考
通过对业务的分析,我们发现:
- 缓存
一些业务可以将其缓存起来:如城市,站点,热门线路,公告等! - 数据组合
一些业务可以将数据在创建的时候就生成好,这部分数据变动不是很大,改动的时候再将其更新即可,这里为什么不去选择缓存呢?是因为这些数据都是基于车次去组合的,其中里面包含了站点,城市,以及上下车点等信息!
在首页根据站点城市查询的时候:
1 之前是根据db去查,部分缓存,需要先去a表查前置依赖数据,再去b表查其他数据,最后再基于结果去查车次。
- 优缺点:
join存在很多好处,简单方便,但是随着数据量大以及其他业务,后期难以维护
单表:需要组合数据,该动起来较为麻烦
2 基于分析后我们发现这里的业务数据变动几乎不变,可以生成好,基于易于维护以及方便查询,维护,能不能将数据组装好在文档数据库里,更新时实时更新?
3 当然做这一切都是为了减少db访问压力
还需要考虑数据一致性问题
落地过程
这里落地过程是怎么样的?
- 1 首先通过监控工具发现接口的调用次数,响应时间等确定接口
- 2 其次去找响应的模块页面,分析接口数据以及不同供应商的配置差异
- 3 接口分析这里需要考虑几个点:
- 3.1 数据是否可以缓存
- 3.2 数据缓存一致性问题,业务对一致性要求高不高,这里的业务重要吗?,弱一致性还是强一致性,还是直接set get 对数据缓存,需不要需要防止大流量构建缓存(缓存击穿),恶意请求以及不存在的数据(缓存穿透)
- 3.3 易于上面3.1,3.2缓存如何更新?
- 4 数据是否是可变动的?用缓存还是文档db?
- 5 是否需要异步执行?(多线程还是mq?)
- 6 数据如何同步&预热?
- 7 全量还是增量?
- 8 就接口和新接口优化数据如何比对?
- 9 出问题线上如何及时回滚?
- 10 线上如何安全平稳的过度?
- 11 数据结构变化了如何同步,写数据和读数据是否分离?
- 12 开发过程中如何测试?
- 13 开发过程中任务的分配?
- 14 开发过程中如何主动推动
- 15 开发过程中如何和同事沟通?
- 16 开发过程中理想和现实差别很大如何避免?
- 17 同事不配合怎么办?
- 18 上线后与预期不相符怎么办?监控多久呢?
- 19 项目搭建流程,一些公司流程,权限申请?
- 20 项目搭建:基于原项目还是抽离呢?
- 21 组织会议,万事开头难,中间浪,收尾更难?
- 22 开发周期,任务分配,延期怎么办?
- 23 review 代码,查漏补缺?
- 24 上线步骤以及流程安排?
- 25 心里压力,是否可以负起责任,抗事?
- 26 需求文档,讲解,评估
- 27 模块流程图等等
- 28 等等…
以上步骤以及内容都是在项目进展中实际的一些思考,初始时由于角色改变,不是很适应这种角色,以前是写代码,现在是主动推动,负责(当然承担的事情也很多,这是不可避免的),从写代码到负责推动一系列到方案决策,中间很姐姐也很迷茫,同时也很快乐,以前觉得程序员死写代码,现在觉得推动事情+发现问题+决策+落地+后续,整个过程是很快乐的,程序员不仅仅是写代码!
后续问题处理
在我们上线完后:发现一些问题:
- 一些mq数据积压问题
- 部分业务&接口的遗漏,这是不可避免的
- 数据同步问题,影响主流程db
- 缓存不一致问题
- 代码和实际想过不一致
基于以上问题,没有什么好的办法,及时切换,首先避免线上问题时间过长,立马回滚,或者流量控制,不要影响大部分用户。
其次是查询,以及修改代码,在预发环境观测,等修复,再切换反复修复到稳定阶段(这个阶段也是不可避免的,任何软件功能上线后都需要一个稳定期)
最后就是总结一些流程及时复盘输出文档(技术&流程)