工作中的任务高并发问题

在开始文章之前，我先把我今天一天做的工作大概罗列一下，看看这一天的时间都怎么被这些任务瓜分了:

1、协助业务方分析MySQL实例无法访问的问题；（20分钟）

2、协助业务方找回误操作数据；（20分钟）

3、协助直播业务方启动一个MySQL实例，拉取部分数据做相关分析，然后再停服；（5分钟）

4、协助数据统计业务方备份一个数据库的部分数据，并在另外一个实例上进行恢复，表大概有30张，数据大概100万；（30分钟）

5、协助业务方修改线上数据库的存储过程；（5分钟）

6、协助SQL Server方向同事访问某MySQL实例；（5分钟）

7、协助业务方添加4月份的相关日表；（15分钟）

8、协助业务方清理过期表数据；（10分钟）

9、慢日志转储通用性脚本逻辑开发及测试；（3小时）

10、修复自动化运维平台主从关系表；（5分钟）

11、阿里云工作室的游戏日志数据离线访问方法沟通；（5分钟，delay）

12、阿里云线上rds合服前准备；（1小时）

13、新实例NFS远程备份机目录挂载。（30分钟）

目前能想到的事情就这么多，可能还有一些琐碎的事情没有整理，就上面的整理来讲，总共的时间累加是6小时30分钟（我只算了一遍，如果算错了还请见谅），按照每天9:30上班，6:30下班这个时间算，可能也就占用了大半天时间，剩余的那一两个小时，吃饭、午休、倒水、上厕所，差不多也就够数了。

理想很丰满，但是现实很骨感，实际上我是在晚上九点半才把这些事情搞定的，可见重点还有很多时间是花在了一些算不上事情的事情上面，比如说跟别人沟通一件事情、聊聊某个功能的迭代方案等等。

不知道别人家的DBA一天的工作是怎样的，就我而言，业务方这些琐碎的事情占用的时间太多了，而且并发度比较高，导致自己的时间被分割的有些明显，这样很难集中精力去搞定某一件事情。

但是，在上面罗列的那些任务中，不难发现，这个满日志转储的脚本开发和测试占用了大量的时间，也就是3个小时，实际上脚本的逻辑很简单，是把一个MySQL实例生成的满日志通过scp的方式拷贝到另外一台备份服务器上面，然后在备份服务器上面利用percona-tool，也就是pt工具中的pt-query-digest进行解析就可以，但是问题就在这里：现有的几百台MySQL实例环境不一致，突出表现在一些data目录和slowquery.log的目录上，大部分的环境部署都是一致的，看了一眼，大概四五十个不一样的吧，这就牵扯出来一个问题，在满日志文件转储之前，需要对这些mysql实例的目录进行分类分析。

我的整体思路是这样：

1、先写一个通用脚本，假设每个实例上的目录都是一致的，然后把那些不能跑成功的Mysql实例进行标注；

2、针对这些跑不成功的实例，大体分为几种情况：slowquery.log文件名不规范、slowquery.log文件目录不规范、slowquery.log不存在、mysql实例临时下线

3、开始修复，以不停数据库为首要原则，把一些简单的slowquery.log名称不规范的实例进行修复，通过slow_query_log参数的启停来生成一个新的规范的慢查询日志

4、针对下线实例，在慢日志配置表中进行删除

5、其他的特殊实例，例如data目录不规范等，直接新建一张数据表，把这些实例的信息单独存储在不规范实例的统计表里，当脚本便利到这个IP的时候，直接从这张不规范的实例统计表里面去取

6、针对上述逻辑进行脚本测试。

不难看出，之所以浪费时间比较多，是以为在写通用脚本的时候，为了匹配当前的线上环境，所以就会产生很多条件判断语句，脚本的逻辑也会变得复杂。如果我们的线上环境都是一致的，那么上述操作将会简化为步骤1+步骤6，相对而言，会省去一大部分时间。

在前文中，我之所以说每天都在努力换之前欠下的债，其实就是在说我们在部署线上环境的时候，一定要按照一定的规则去部署，不能图一时之快。前人们在做这些事情的时候可能没有完整的规则去约束，所以导致每个人处理问题的方法不一样，这样可能当时看着比较方便，但是，当你想做自动化运维这种高效率运维方法的时候，很多时候不是技术限制，而知历史遗留问题会让你被动的接受任务的delay，这是我们不愿意看到的。

有些偏离主题了，我想说的是，在工作中我们经常会遇到类似这种高并发的任务处理问题，其实之所以问题会高并发，我的一种观点是我们本身提供的服务就有问题，所以会导致问题源源不断的回溯到我们自身，然后自己承担自己种的恶果，或者让后人来替你背锅，想起了一句话“自己亲手写的bug，跪着也要给修掉”。在后续的工作中，就我个人而言，需要将很多简单的工作都流程化、规范化、能用运维平台操作的，尽量不要用手工操作，因为平台能够保证环境的一致性，而手工操作就不能保证一致性，举个简单例子，在平台上设置访问密码，得要保证16位，而且是大小写字母加符号混合的，而手动指定密码，可能就随意的写个‘Iamastudent’这种的，这种密码显然是不规范的，如果某一天我们需要对密码长度进行统一化管理，这些密码将又会成为不合格密码，就会导致不必要的返工。再说一个例子，今儿的创建日表的业务（任务7），这个任务其实可以通过平台进行管理的，但是我们之前没有这么做，有一些是通过脚本执行的，有一些是通过手工添加的，还有的是crontab直接设置成定时任务的，所以经常会收到一些业务方的反馈，“今儿都4月2号了，怎么4月11号的日表还没有创建成功？”，这种当然是DBA不想看到的。这种问题其实都可以通过平台化的管理来规避掉。

总结一下：工作中的任务高并发，分为两种，一种是不可避免的，我们今儿不做讨论，另外一种是我们可以从规则上、标准上杜绝的，这类问题，如果我们从一开始就卡的比较严，那么我相信，这种高并发问题将会减少。