关闭

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

标签: redis系统
260人阅读 评论(0) 收藏 举报
分类:

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的时候流程就是这样的:
![这里写图片描述](http://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、这种数据注入问题,通常是由多个相同配置文件造成的,其实只需要搜索搜索就可以看出来。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:6869次
    • 积分:196
    • 等级:
    • 排名:千里之外
    • 原创:13篇
    • 转载:1篇
    • 译文:0篇
    • 评论:1条
    文章分类
    最新评论