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、這種數據注入問題，通常是由多個相同配置文件造成的，其實只需要搜索搜索就可以看出來。