上线总是心惊胆战的,无论准备的多么充分,都无济于事,那种心惊胆战已经深入骨髓,昨天更是重新体会了一遍十八层地狱一日游。上线之前,我做了详细的准备,事先申请了数据库访问权限、建了表、加了数据、配置好配置文件,自认为能做的都做了,可是最后还是出现问题。
1. 时间:5:10 PM
事件:一切准备妥当,找运维上线,配置好配置文件,启动worker,结果:失败!!
原因: 由于之前只考虑shell脚本的权限问题,却忘记了要软连接到固定的位置。
解决方案:建立软连接。
2. 时间:5:30 PM
事件:建立软连接后兴致冲冲的重新上线,启动worker,结果:成功!!这个是很让人高兴的一件事情,但是查出来数据总量却是和我们预估的不太一样,是差太多,我们预估至少得有一千万数据,结果只有一百多万,我有点不大相信,去问dba,确认只有一百多万数据后,心中还是蛮高兴的,以后的业务处理会简单很多。
经验:在导数据之前一定要先确定数据的总数而不是自己推测、预估。
3. 时间:5:50 PM
事件: 开始导数据,启动worder,结果:失败!!这个是多么令人沮丧的事情啊。
原因:由于监控系统打出的日志有一部分是乱码,大致推断是数据中有敏感字符,想去运维要日志,结果人家不给,理由是“太忙”。这就只能是自己推测原因了,最后死马当活马医,按有敏感字符处理。
解决方案:改代码,打包,上线。
经验: 在导数据的时候要做最坏的打算,对数据进行敏感字符处理,以除后患。
4. 时间:6:30 PM
事件: 改完程序,重新启动worker,结果:失败!!我都快绝望了。
原因:数据库字段长度不够,之前我们在设计数据库的时候考虑只是类似短消息的信息,内容不会太多,500字符足够,结果导致数据库字段长度不够,上线失败。
解决方案:修改数据库字段类型,由以前的varchar(500)改为text,结果人家dba不给执行,因为没有提计划,最后求爷爷告奶奶,邮件抄送老大后,才勉强答应的(这里得感谢亲爱的dba同学了)。过一会,dba说“sql语句不行,公司现在不允许用大字段”,所以只能改varchar长度。一狠心500改成4000,dba同学给执行了。
经验:在设计数据库的时候充分的预估数据的容量,在允许的情况下设大一点比较好。
5. 时间: 7:20 PM
事件: 修改完数据库后,重新启动worker,结果成功!!我都快哭了,终于好了。
6. 时间: 7:40 PM
事件: 数据导完之后,接口平台切换到数据库,结果:成功!!我太高兴了,果然我写的代码宗师没什么问题的。
7:时间:7:50 PM
事件: 接口平台上线之后,事情并不是借此结束的,要线上验证。结果,日志系统不打日志,这个吓死我了,我还以为是程序出了问题呢。查看监控系统以后发现系统还活着,谢天谢地。过了五分钟后,日志系统重新开始打日志。好景不长,日志中出现error,好吧,最后还是出问题了。
分析原因:由于之前调用别人接口的时候消息的主键是字符串类型,而我在数据库中存的是long类型,一些用户的页面上还是之前的主键,导致出现问题,这个应该只是偶然现象,万幸的是日志在打出35条error之后终于停了下来,我的心脏也慢慢停了下来。
8:时间:8:20 PM
事件:日志系统不再打出error,但是页面打开奇慢无比,
原因:由于消息在打开页面时要将一部分的未读消息改成已读消息,但是天杀的我,竟然忘记了给主键加索引,页面打开竟然花了七秒以上,这绝对能进下周的big sql排行榜了。最后,加上索引,响应时间瞬时下来,有以前的1s表层1ms,好高兴啊!(好吧,这最后一句我骗人了,这是我今天早上来才加的,因为我这个只是消息总量访问得多,而页面访问频率太低,你们就尽情的鄙视我吧!)
经验:索引、索引、一定要加索引,主键一定要加索引啊。