【文章摘要】
对于使用数据库来存放大量用户的软件来说，过期数据的清理机制需要慎重设计。如果设计不当，则会导致数据的误删除或清理不完全。
本文对某数据清理模块因参数配置不当而导致的过期用户数据堆积问题进行了详细的分析，为相关软件问题的分析及解决提供了有益的参考。
一、问题描述
在某软件系统中，为了让不同种类的用户享受对应的服务，引入了一个信箱服务等级的概念，即不同服务等级的用户具有不同的权限。“一分钱，一分货”，对于运营商来说，高服务等级的用户收取高的资费，提供高质量的服务。
为了维护不同用户的信息，在数据库中建立了用户数据表，表中包含了用户号码(如手机号)、状态(如正常使用、停用、欠费等)、服务等级(称作cos值)、用户属性(A或B类用户)等字段。
近期，该软件系统的某商用局点的支持人员反馈回一个问题：数据库中过期用户数据堆积，很多本该被删除掉的数据依然存在。
二、问题原因初步分析
在该软件系统中，有一个过期数据清理模块专门用于清理过期用户数据。既然数据库中出现了大量未被删除的过期用户数据，那么一定是这个模块出了问题。
我们让现场的支持人员将使用的数据库打包返回，并在开发小组的自测数据库中将数据恢复了。我们查看了用户数据表，发现的确有大量过期用户数据还保存在数据库中的。那么，这些本该删除的数据有什么特点呢？
我们对部分过期用户数据进行了观察，发现它们具有以下两个方面的特点：
第一，某个cos值对应的过期用户数据特别多，占到了未被清理的数据量的80%以上。
第二，未被删除的过期用户数据的用户属性大多为B类。
三、问题定位
基于以上分析，我们参照代码和数据库脚本来查找问题原因。
首先，为什么某个cos值对应的过期用户数据特别多呢？难道是这类数据很特别，程序不会对其执行删除操作吗？
我们详细追踪了程序执行流程，发现在数据库脚本中，有一个参数值用于控制是否将过期用户数据删除以及过期多少天的数据要删除。而这个参数的值是在一个cos参数表中定义的。cos参数表的定义如下：
create table tb_cosparamter ( cosname varchar(100) not null, cosid int not null, cosvalue int not null )
控制过期用户数据删除的cos参数的名字“cosname”为“DelOverdueData”，“cosid”对应的是用户数据表中的服务等级，“cosvalue”表示删除数据的时间阈值。
我们在数据库中执行SQL语句“select cosid, cosvalue from tb_cosparamterwhere cosname = ‘DelOverdueData’”，结果如下：
cosid cosvalue
1 0
2 30
3 30
4 40
5 50
可以看到，服务等级为1的用户数据对应的时间阈值为0，表示不删除。而我们之前查看数据库，确实是cos值1对应的过期用户数据特别多。看来，就是因为这个cos值配得不对，导致了该服务等级对应的过期用户数据无法删除掉。
我们执行SQL语句“update tb_cosparamter set cosvalue= 30 where cosname = ‘DelOverdueData’ and cosid = 1”将cosid为1时对应的cosvalue值修改为30，重新启动清理模块之后，发现确有大量过期数据被删除掉了，但仍有少量用户属性为B的过期数据还存在，什么原因呢？
我们继续追踪数据库脚本，发现有一个参数值用于控制要删除哪类用户数据，这个参数也是在cos参数表tb_cosparamter中定义的。cos参数的名字“cosname”为“DelUserType”，“cosid”对应的是用户数据表中的服务等级，“cosvalue”为1表示只删除A类用户，为0表示A或B类用户都要删除。
我们在数据库中执行SQL语句“select cosid, cosvalue from tb_cosparamterwhere cosname = ‘DelUserType’”，结果如下：
cosid cosvalue
1 1
2 1
3 1
4 1
5 1
可以看到，各个服务等级对应的cos值均为1，表示只删除A类用户。这与我们观察到的情况是一致的。看来，就是因为这个cos值配得不对，导致了用户属性为B的过期数据无法删除掉。
我们执行SQL语句“update tb_cosparamter set cosvalue= 0 where cosname = ‘DelUserType’”将cosname为“DelUserType”对应的cosvalue值修改为0，重新启动清理模块之后，发现用户属性为B的过期数据被删除掉了，数据库中再也没有多余的过期数据了。
四、总结
在过期用户数据堆积问题的排查过程中，我们首先通过对问题数据进行分析来初步查找问题原因，之后通过追踪程序流程来定位问题。
通过本次问题排查，我们总结出的经验有以下几个：
第一，遇到程序问题，我们不要惊慌，可以先从表面上观察问题的现象并推测问题原因，然后再根据之前的分析深入研究程序流程，找到问题关键所在。
第二，对于数据库中的重要数据，要有人员定期进行维护，并作相应的记录。这样才能够避免出现某些参数值不一致的情况。
第三，修改数据库中的相关字段值时，一定要谨慎。在修改之前，尽量将重要表中的数据备份，避免对数据库造成破坏而无法恢复。
不管是程序bug也好，数据库问题也罢，我们的目标都是要尽力将它们解决掉。在解决问题的过程中，我们要采用灵活的处理方法，并沿着发现的蛛丝马迹追查下去。如此这般，不管是什么样的bug都是可以被消灭的。
--------------------------
本人微信公众号：zhouzxi，请扫描以下二维码：
