本周值得注意的事项就是，测试人员那边反馈在测试环境下，某些账号突然无法正常使用的 问题。目前整个账号的体系还是在沿用老的系统。而在当前老系统中，账号信息使用某种特 殊的数据存储分成多个模块存储，每个模块相当于一张表。每张表都各有侧重，有些侧重于 与其他账号之间的关联关系，有些侧重于查询等等。这些账号无法使用的问题在于，其中最 重要的一张表也就是主表，这个用户的记录消失了。在其他表中该用户的相关记录还是存在 的。
这就引发了我的各种猜想，是否是测试人员测试的过程中的环境弄混了？或者是某个服务的 配置有问题导致了部分应该写在测试环境的数据写到了生产环境去了？说代码写得有问题导 致了某些极端情况下，用户的主表信息写入失败？通过调查发现，最终要的查询表中，数据 结构还是完整的，而且能够反推出用户注册时候的微信账号。查询表只有在账号创建的时候 才会去写，后续基本不会再修改了。而主表中的数据应该是和查询表在用户注册的时候一块 写入。
对于这个问题，后续推断应该是数据模块发生了某种问题导致数据丢失。而在我咨询数据模 块相关维护人员的时候，我还没说清楚问题，他们就说是测试环境并不保证服务的可用性， 可能发生任何问题。那么这个问题可能就无解了，因为如果是数据模块这层问题，我作为使 用方基本没有任何能力来自己解决。除非我能替换掉这个数据模块，使用更加稳定可靠的解 决方案。那对于这个问题，我只能够然同事手动清理查询表中的索引关系，然后在让用户重 新进入应用。当用户重新进入应用的时候，由于没有索引就相当于没有这个用户，此时就会 重新创建用户。后续几个月遇到了十几例相同的问题，没有办法，让同事添加了一段自动处 理这个问题的业务代码，以免去每次手动处理的麻烦。
这个问题第一次出现将近一年后，由于某个重要客户反馈了这个问题。而又正好这个重要客 户当时半个月之内反馈的我们的各种问题有点多，领导对此十分困扰，所以对于我这个问题 他特别重视。领导后续找到我让我推动解决这件事，我同意执行，因为我也想知道问题具体 是什么。现在能够确定的是，问题出现在数据存储层，而这一层又不是我们直接控制，我们 只是使用这样一个产品。这个产品已经很老了，维护人员很少了，而且还有其他事情。他们 不愿意来主动寻找问题，也是情有可原的。所以想要推动他们的维护人员来解决，就只能抓 住具体且直接的证据来证明他们的问题在哪里。
我以当时的了解，知道数据层分为缓存和落盘数据库，而且经过一年在各种问题的解决过程 中学习，我也能很熟练调取分析落盘数据库里的数据了。我调取了落盘数据库中的用户 ID 的倒序情况，发现从某个用户 ID 开始，后面就没有了。最近一年，用户报问题的用户 ID 以及新注册的用户 ID 是远远大于这个 ID 的。我又去日志中获取了一个最新注册的用户 ID，查询数据层，发现是有的。说明缓存中是有正常数据的，但是由于某种原因数据并没有 落到数据库中，而是在缓存满后直接消失了。
这已经能够说明问题了。于是我将这些调查记录截图发给数据层产品的维护人员，并提了一 个工单，推动他们来解决这个问题。该问题的脉络我已经提前分析地很清楚明了了，而且又 有直接的证据，他们也开始认真对待这个问题。后面确实，他们重启某个模块后，这个问题 就好了。而且最终他们承认问题与缓存层落库的机制有关系。