必须严谨,慢一点,细心一点,淡定一点
  5HAFzPFxGStu 2023年11月02日 75 0


>>>>>>>>>>>>>>>>>>>>>>>>

1,jquery datatable  数据不是json是值得数组

2,jmx的ip配置问题

3,java-api-5与jms.jar冲突问题

4,配置文件加载问题

>>>>>>>>>>>>>>>>>>>>>>>>>>

1,工程依赖,但是取一直报错引用不到相关的类,刷新,重启Eclipse,clean还是不行,无意发现,没有编译的class。。 哎。第一眼要看见

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

update 的set语句字符串前带空格 ' aaaa' 导致无法查出


>>>>>>>>>>>>>>>>>>>>>>>>

getMap('pst')

close('rp')


获取的数据源与关闭的数据源不一致,而两库的内容相近

>>>>>>>>>>>>>>>>>>>>>>>>>>>

jdbc的url的key值写错,结果启动后一之报错连接不上和拒绝连接一只找数据库是否开启网络服务,以及jar的驱动是否正常,连接的url对不对,就是没检查key,哎,其实仔细点 对比下配置文件的key和连接的key就知道了。或者跟下源码也可以的

>>>>>>>>>>>>>>>

现象:api接口调用耗时突增,分析业务日志,发现访问量陡增,怀疑被攻击。于是开始分析服务器网络情况,以及系统之间调用情况,发现一台服务器网络阻塞很高,开始分析访问源ip,还是没有结果。无意中通过ip+端口访问 服务器宕机。分析日志内存溢出加大日志,调用时长没有变化。实在无奈,就登陆下中间件,发现无法访问,于是乎,猛然,顿悟。中间件挂了,导致新的消息到来后,每次都要连接中间件,知道timeout,所以耗时较多,因为api 捕获了所以异常,而且没有调用者响应,导致调用看到返回值200,以为正常。现在看来问题其实很明显,访问时间过长,响应200,没数据入库,肯定api服务有问题,服务器网络阻塞很大,说明消息处理慢,慢的原因可以看看为什么。。。 谨慎谨慎

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

现象:队列积压越来越多,不堪重负,一直盯着宕机,接着不知所措,乱看日志。其实要静下心来,先重启,重启不行,新建队列,使线上服务可以用。等线上没问题了 再想怎么恢复数据。遇事沉着冷静。。。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>

从数据库查出的记录没问题,当时从应用查数据库就有问题,查询sql一样。通过对比发现。应用查出来多一条记录。这个时候要想为什么应用多呢。sql都一样。肯定是数据出问题了,那数据怎么出问题了。格式不对,库不对。通过排查是库不对。自己一直在主库上查,而应用在从库上查,主从不一直。通过发现从库有脏数据。。 淡定啊

>>>>>>>>>>>>>>>>>>>>>>>>>>>

这个地方减库存,为什么其它地方不减呢,为什么补想想呢

>>>>>>>>>>>>>>>>>>>>>>>>>>>

通过现象要抓住事物的本质。不能瞎猜 想当然

>>>>>>>>>>>>>>>>>>>>>>>>>>>

select 的where条件2014写错成2013导致查不数据。。。 无语ing

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

where 条件少个表遗漏 业务不清看来,至少也要质疑结果和实际相差蛮大。。。 细心。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

同样的表,同样的库,别人可以查到数据,自己却不能,改怀疑是否连错了库 亲

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1,mybatis配置文件不熟悉的情况下就开始修改别人的配置,导致配置好后,一致运行不起来,没办法只能还原。其实 首先要了解别人的配置,才能做修改。


自动生成的配置文件,随意的改 字段都不理解,导致一致不错,莫名其妙,就瞎改一桶,网上乱搜。求助别人还是没解决,最后发现,自己的配置类也对不上,配置的属性字段也是错的 细心细心

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


(baidu za )两个系统不一致,都没有分析,就立马本地起应用,跟代码重新汇总数据,结果数据还是老样子。立马傻眼了。接着怀疑对方系统统计有问题。有开始看对方系统怎么统计。又浪费了时间。无意中找到业务系统的调用代码type有问题。突然顿悟。。。
哎,其实一开就应该排查调用方。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

一听说单点,立马想到通过反向代理来做负载均衡消除单点,接着就部署应用实例,配置反向代理。ok,完成后以为万事大吉,查看队列后发现,两个队列通过反向代理集群后,总会有一个有消息未被消费。百思不得其解。偶然想到,取队列的数据要通过两次访问,第一次查看队列是否有数据,第二次则去数据。问题就出在这。nginx默认是轮询下发请求。查询的请求和获取数据的请求不再一个队列导致查A队列有数据,取B队列无数据。想到此,甚是高兴,立马把nginx轮询配置成ip_hash,这样就不存在查A队列,取B队列。以为万事大吉,有一顿忙活。部署后,观察队列,一个队列有数据进入和消费,另一个队列始终没有消息。又郁闷了。仔细想了想。发现。两台机器通过nginx代理访问。通过ip_hash后,都落到了同一台机器,顿时傻眼了。只能退而求其次。消费者个连一个实际的应用。哎,多思考,多思考

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

队列消费只进不出,应该是消费者出问题了,日志也木看,直接重启,结果没用。随想队列有问题,有不确定,随便看了下消费者日志,发现空指针,也没留意。只是搜了下,发现有重置命令,就把队列重置,结果就ok了。其是一开始就该看日志,看为什么空指针。后续看知道,是获取队列状态失败报错,导致不从队列取数据。。思路错了 ,什么都白费

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

plsql修改数据,当你同时连多个库的时候,一定要看下方的连接,到底连的那个库。。。。 mysql也要看看上面的表头到底连的是主是从。
测试数据都改了,为什么没数据,库错了 亲

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

怎么木打印日志呢,莫非木启动成功嘛,看下info木有输出,果断重启。接着看catalina.out有,info还是木有,接着怀疑检查log4j日志配置是否有问题,结果检查了下,没问题。郁闷了。。。。。 算了,再检查下tomcat的配置,心想tomcat应该木错了。抱着无意的心情看了下。突然发现tomcat的指向应用的路径错了是app1,不是app2.。。。。 其实一开始就应该看log4j对不对,然后看tomcat配置就可以了。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

配置了反向代理以为ok了就没做检查,下午看的时候发现一个队列1w多条记录,另一个个位数,于是怀疑nginx负载均衡配错了,检查没错,重启还是木错,接着检查消费者日志,确实打印队列为空。为啥没数据,不应该啊。查看队列状态正常。get也正常。很是郁闷。把队列重启,问题依然存在。莫非非要删除,重置吗。。。。偶然间发现一开始重启生产者生产者放数据报错。。拒绝链接后。下次链接就正常了。于是检查nginx日志,请求确实都到另一台机器上了无奈。。。。  想看队列日志,搜了半天也没找到。突然想起来,是不是那个队列有问题,生产者不能放呢。于是,自己试着put一个数据果然不行。看来队列有问题。重启 重置 都没效果
、当ps的时候,突然发现给队列的数据文件被另个队列使用。啊,怎么这样。一个数据文件只能一个队列使用。果断关了另一个。把当前的重启。ok好了。。 其实一开始就要检查 是否可以put。如果不能,重启队列,因为应用一样另个没问题。所以应用没事。重启队列发现队列文件被占用,问题及解决了。。 可惜啊  不细心。。。
 >>>>>>>>>>>>>>>>>>>>>>>>>>>

接口时好时坏,一开始怀疑队列出了问题,就查看队列,木有问题。取消了重启队列的想法。接着看日志,总共部署四个实例,两个有请求响应,有一个只有请求没有响应,怀疑这个有问题。于是就重启,问题还是存在,接着查看调用者发过来的错误日志。。。 没办法,自己这边日志没有错误。分析得知初始化jms出差。。。 这个时候想到是不是上次修改配置导致的问题。自己检查配置,果真有问题。。。 细心检查。。啊

>>>>>>>>>>>>>>>>>>>>>>>>>>>

1,怎么设置都没有便宜,于是怀疑jdk配置,结果正常,接着怀疑依赖,也正常。重启无效,对比source一样。无奈之下,去source在加ok。哎郁闷
>>>>>>>>>>>>>>>>>>>>
js 在js文件中想定义个全局变量 var a = 0 ,函数私活读不到,查查资料 a=0即可。哎 好好打好基础
>>>>>>>>>>>>>>>>>>>>
js中获取当前时间,只能在action放入吗。
>>>>>>>>>>>>>>>>>>>>
alert("ok",b) b变量始终输出为null,郁闷之下语法错了 ,熟悉语法吧 不要逗号。找了半天函数定义 传值 就是没找对方向。
>>>>>>>>>>>>>>>>>>>>
'ok'++'ok' 输出 'okNanok' 找了半天找不到问题,最后发现语法错了 肿么不报错。检查后台数据 ,数据库数据 就是没找准方向,方向不对,努力白费。 其实,该好好检查 不能瞎找  浪费时间。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

服务不稳定,时好时坏。一看日志没有输出,于是想当然认为系统宕机了,立马重启。以为ok了。但是还是没日志。于是乎ip:port没问题。nginx也没有前端来的请求。于是怀疑前端出问题了。但是运维的不再木办法。哎。。 上班后,找运维定位。网络正常但是有向nginx发包。于是乎就纳闷了。此时运维的突然问这个test.jsp肿么没有输出。而其他的有呢。于是乎把test.jsp备份。直接输出200 ok。恍然发现,前端根据test页面来判断服务是否正常。但是test却不知道咋出问题了。可以访问木有输出哎。还是要对部署熟悉啊。其实一开始就ip:port木问题。nginx没日志。就可以定位到前端。即热nginx没请求说明前端认为服务已经挂了,这个时候要深入确认 前端通过什么机制判断后端挂呢 这样不就ok了么

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

新增功能后,替换class和xml文件,启动报错端口占用,于是乎查看端口确实占用,停止还是占用。于是怀疑端口和之前某些应用冲突,于是就改端口,端口没被占用了,报错Error listenerStart。实在没办法了。将本地class完全替换线上,问题依旧,替换lib后。ok。原来,之前添加某个功能后代码提交,但没有部署。这次替换class只是替换这次修改的而已。以后还是改了提交后就部署了。。不能这样了。另外替换的是把配置文件替换到备份的文件里面导致数据库没有对应的字段入库,, 哎 细心吧。几分钟的事搞了一上午。。。浪费时间。。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

登陆后提示“木有激活”,于是乎就开始要url,本地起来debug,结果一直提示500内部错误。就开始纠结业务代码有问题,就开始跟,跟的过程发现是调其它系统接口返回403,业务判断返回304不处理 直接返回500.。。。 接着开始单独把第三方url拿来执行,显示404,就想当然找错误码,一看是ip受限,于是纳闷了。。 搞了半天不知道神马情况。拿着接口名一找,看系统的错错误码了。接着又看其他系统的错误码吗,是超时。于是让业务重新给连接,结果还是超时。纳闷,突然发现原来是自己本地时间有问题。于是改时间。请求正常,跟第三方响应200.于是跟第三方代码,sql。这时有人提醒是不是没有激活所以才报错。于是一看是这样。就问别人流程。哦,原来要激活。于是找激活接口,跟代码最终解决。 哎,其实第一步了解流程,第二部检查有没激活,第三部看激活的逻辑就ok了浪费时间。。。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

线上应用跑的好好的,今天突然报错,cx_Oracle.DatabaseError: ORA-01002: fetch out of sequence。于是乎怀疑网络有问题,于是找db和运维的同事帮忙看下,折腾了半天,结果一切正常,傻眼了。。。 最后问发现问题的同事,他做了什么操作,结果说增加一条记录,于是乎,让他先删了,然后重启ok,于是乎怀疑这条数据有问题,可是通过查询发现没啥问题,单独sql拿出来也没问题,莫非python的oralce组件有数量限制,于是通过找文档发现,默认游标是50,超过50游标的arraysize字段还是50,于是乎把arraysize改成和记录数相同就ok。哎,分析问题还是淡定点,一开始就问做了什么操作导致的问题就不会这么折腾了

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

业务系统,域名经常无法访问,而我自己本地通过域名却可以正常访问。于是乎,怀疑域名解析出问题了,因为我是内网。可是通过查看dns和lvs没发现异常信息。运维同事偶然发现业务系统有其系统自带的防火墙,于是就想当然是这个问题,把8081端口和 80端口,添加到防火墙外,以为万事大吉,结果一个小时后问题继续出现,自己就把防火墙禁用,结果问题依旧,唉,找运维同事帮忙看下,运维同事直接把防火墙卸载。ok了,然后半个小时后,再次出现。于是再次找到运维,运维同事通过,观看lvs对后端的分流,发现其中有一台机器分流成功却响应失败,发现业务机入口没问题,出口却不能正常响应,于是想起,系统的重启脚本里面有设置出口ip,路由的, 因为是用的是lvs的nat所以要设置出口路由,重启后脚本正常。哎,网络拓扑不清楚导致,网络偶滴硬伤

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

由于机器迁移,要把一个节点停机,于是kill完所有java进程,就让运维关闭系统,在另外一台机子有启动了几个备用节点,把核心统计节点的备用开启了,于是以为万事大吉,下午突然有统计充值的同事问,怎么掉了那么多单,于是赶紧去系统查看,自从钱以后一直没统计数据,于是去备份统计查看,啊,内存溢出,于是关闭了几个备份节点,同时把相关节点mem统一调小,并查看统计报表正常后,开始搞起它了,三个小时后,机器迁移完毕,开启关闭节点的应用,关闭备份节点,就急匆匆的下班了,结果晚上到家一看还是没统计数据,于是查看,启动挂了,于是关闭重启,没有查看就sleep,第二天早上一看还是没有数据,查看缺少mysql和spring的jar,纳闷明明有,,,, 于是忽重启结果问题依旧,于是 替换不存在文件居然ok了,接着核实另外几个也同样存在问题,于是lib全部替换ok。这样本来正常的代码,重启后缺少包可以看报错信息invalid LOC header (bad signature)错误与 java.lang.ClassFormatError: com/mysql/jdbc错误,即可知道包有问题了,浪费时间。注意报错信息。以后还是别kill了,哎

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

1,运行demo或者test

2,看官网文档

2,本地调试

4,代码调试

5,一步到位

6,零调试与零bug第一,时间第二

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 2023年11月08日 0

暂无评论

推荐阅读
5HAFzPFxGStu
最新推荐 更多