java问题查找------从源头查找

1、来源

前两天公司系统出现一个问题，就是咨询的问题，系统统统都回答不上；

首先介绍一下公司系统的基本流程：

公司做的一个用户咨询流程，大概流程就是在处理流程中，会把预处理的一些结果放在redis里面，然后再调用应答服务接口，应答服务接口通过redis获取对应的预处理结果。但是由于公司初始架构调整，造成了系统有两条处理线：

就是 处理流程1 与处理流程2对应相同代码但是环境是两套不同的环境，这就造成了如果应答服务2从redis1里面获取预处理结果是获取不到。（当然这个流程本身是不合理的）

2、定位问题

1、初步定位
前两天发现走处理流程2到调用应答服务2这个流程返回给用户咨询的答案不对，所以去排查。首先查看日志，发现应答服务2相同咨询条件先比应答服务1少拿到数据，然后预测是redis的原因。但是由于日志打印太少，不确定。首先需要排除掉代码原因，将处理流程1接入调用应答服务2，由于处理流程1一直正常使用，如果接入应答服务2，应答服务2应该正常工作，接入后，发现确实正常工作，且给出了正常答案；开始以为应答服务2没有问题，是处理流程2的问题。可是找了半天没有找到才发现接入应答服务2的时候 处理流程1未修改redis那么调用应答服务2的时候流程就是这样的：
![这里写图片描述](https://img-blog.csdn.net/20150706194246216)

明显是读取到两个redis但是可以正常工作，定位出来确实是应答服务2缓存链接出错额原因，链接到了redis1上面去了。
2、原因分析：
既然是redis原因就查找原因吧，直接在代码里面打开配置文件我们redis配置就是常见的spring配置的：

<bean id="redisClient" class="com.cli.ReloadableClientFactoryBean">
        <property name="configClient" ref="configClient" />
        <!-- 配置拥有集群的客户端配置ID(必选) -->
        <property name="configId" value="${db_configId}" />
        <!-- 配置拥有集群的客户端配置Token(必选) -->
        <property name="token" value="${db_token}" />
    </bean>

这个多简单，马上在代吗上面走到对应的properties配置文件：

db_configId=/redis/cluster/17
db_token=1417623612434

发现这个配置项确实是我们需要配置的redis2呀，可是现在系统表现就是连接到了redis1呀，现在就是陷入了死胡同，又重新去分析看是不是哪儿漏掉了或者查看代码片逻辑是否正确。多次重启应用还是不对。
多次修改对应properties，查找是否系统没有读取到properties文件。在这个上面耗了有大半天。心情也是各种烦躁。

**注意：查看这些数据我们都是通过代码查看，在线上也是只查看了打包后对应的properties是否正确。但是却忘了查看我redis注入时，注入的参数是否真正注入**。

最后在无意间看到注入的redis POM文件在打包以后为：

<bean id="redisClient" class="com.cli.ReloadableClientFactoryBean">
        <property name="configClient" ref="configClient" />
        <!-- 配置拥有集群的客户端配置ID(必选) -->
        <property name="configId" value="/redis/cluster/16" />
        <!-- 配置拥有集群的客户端配置Token(必选) -->
        <property name="token" value="1417623612433" />
    </bean>

这个不对呀，按理说如果从properties里面获取数据，maven打包不应该就把数据替换掉了，应该还是原来的

<bean id="redisClient" class="com.cli.ReloadableClientFactoryBean">
        <property name="configClient" ref="configClient" />
        <!-- 配置拥有集群的客户端配置ID(必选) -->
        <property name="configId" value="${db_configId}" />
        <!-- 配置拥有集群的客户端配置Token(必选) -->
        <property name="token" value="${db_token}" />
    </bean>

通过查找发现是在大系统的POM下，不知道谁将这个配置写在系统POM里面：

    <!-- db-redis test -->
                <db_configId>/redis/cluster/16</db_configId>
                <db_token>1417623612433</db_token>
                <db_used>true</db_used>

这下就真相大白了，原来是maven自己pom里面有对应参数时，打包就直接替换掉成了对应值，不再是获取配置文件的占位符，我们就算配置了对应参数properties配置文件也是没用的。
3、总结
以前有个牛人说，查找问题可以从最上游开始找，也是可以冲最下游开始找，但是切记不要从中间查找问题，不要想着这儿有问题就从这儿找。找问题是需要分析的。想想这个问题
1、我们并没有找到最下游是什么，以为properties文件就是我们系统的最下游，其实注入Bean的配置文件才是最下游，明确什么是最下游没有搞清楚。还有就是最好拿着生效的数据分析，这个问题如果我们在代码里面是查看不出来的，如果直接查看maven后上线的应用是最可靠的分析依赖。
2、分析过程中，没有逻辑，就是觉得哪儿就是哪儿。这个就是查找问题的大忌。
3、这种数据注入问题，通常是由多个相同配置文件造成的，其实只需要搜索搜索就可以看出来。