细心淡定

1.与iso对接3des签名整个过程耗时近3天，刚开始认为很简单， 半个钟就ok。把自己签名步骤发给对方，然后就等了。结果。。。签出的结果不一样。然后开始一点一点看，发现ios的byte与javabyte长度不一，接着进行处理。终于签名一样了。甚是happy，当放到真是环境一测结果发现，加密结果 明文为123456加出来一样。长的话就前面几位一样。一下子傻眼了。。。一行一行进行跟踪，突然法系是pkcs7和pkcs5不同。又开始接解决这个问题。。折腾了半天jdk1.6不支持，又开始折腾jdk eclipse。最终还是不行。。。又开始想第三方的加密算法，进行处理。找到后以为又ok了，结果还是失败。。。只能继续跟代码。无意中发现两边的分组算法不一样。。恍然大悟。。处理好分组后就ok了。其实一开始就就约定好双方的算法也没这么多事。或者细心点，前几位一样。后几位不一样，肯定是分组不对啊啊啊啊。细心心细。
2,判断问题首先从外围搞起。ios登录不上，看下安卓可以吗，已消除是终端问题。终端有问题，就省很多事。。

3，缓存查询一直有问题，其实还是细心的问题，下拉 上拉 传的时间大小是不一样啊 逻辑要缜密

4,加密算法一样。main函数跑出来的数据和工程跑出的数据不一样。并且字符串生成的byte数组也不一样。肯定是字符集不对了。。。。哎 早该想到

6,本来认为肯定没问题,明明同步了两天数据,可是日志显示也调用了一次次insert,可为什么只有一条入库呢,怎么也想不明白,烦躁的看了日志.木办法求助ing,一步一步 一行一行分析,发现原来是cache有问题.判断入不入库 要看cache有木,由于多次测试以及insert都是直接入库,而缓存中却有一条之前的记录,没删除,导致每次判断都存在,所以第二天木入库.哎 ,其实在写的过程中也想到了cache的问题,只是当时没有深入其中,不够严谨.解决了cache以为万事大吉.结果信心被打败了.... 哎,看日志是insert两条,怎么也想不明白..... 头大... 第二天看吧.第二天解决其他问题无意中发现,代码有问题当第一天入库后,接着第二条入库,第二条入库后由于逻辑判断问题把第一条状态改了.... 哎 写的时候怎么不能细心一点,这个问题折腾了两天.. 如果写的时候时间延长一倍...不出问题 顶多也就半天的工作量 现在平白无故搞出三四天,还有问题..... 细心 细心

7,不懂就问..不能一知半解... 哎本来迁移业务知道了 为啥就不考虑合并的问题呢,, 其实只要用心就会想到这个问题.

8,发布后报错 看代码没发现 只能看日志.. 一步一步看...原来copy的时候 循环依赖了

9,一看有问题,立马说接口有问题.找人问.... 结果别人说还有参数哎 羞死了 咋不好好看看呢....

10,

 一开始发送步数到微信,业务端看不到同步数据,第一就想到kafka有问题,立马看kafka情况,但是kafka正常,哎,只能查看业务日志了,一看业务日志正常,郁闷了半天,才发现看错日志了 看得是测试环境日志,与是看线上日志,一看有error,再一看参数乱码,立马看下去,找接口调用方,接口调用方所没传乱码,但又没有日志证明,于是乎 打算线上开启debug 当运维部不给加,有郁闷了,只能问调用方参数从哪来,一看从a服务来,接着从a服务查日志,没问题.陷入僵局.突然想起来b服务也调用.a服务不会调用该方法 在不同终端,哎 又搞错了,于是看b服务,b服务从c服务来,c服务数据库正常 缓存也正常,于是怀疑a服务有问题,看a服务缓存,结果a服务找不到,郁闷,正常应该有啊.纳闷了半天,,半小时后发现 看错redis,用的是默认的.打开一看 正常 于是郁闷,接着 看了一个服务器上乱码的 ,缓存一看乱码,于是确定a服务有问题,但是代码层面看又没有问题,陷入僵局,等了半天,聊天聊得序列化,开发人员突然醒悟,原来之前有序列号入缓存,后来改了,缓存没清空,立马验证果真如此,仓库,细心点,全面点,抓主不放.一开始就应该静下心来 其实很容易的.既然自己没问题,根据业务去除了b 那就看a缓存啊.....

11,

下班的时候 突然说,不能发送微信消息,立刻主观认为想到消费的慢了或者外部接口有问题,就主观的看队列消费情况,一看正常,傻眼,会不会消费线程出问题呢,想当然重启.结果问题依旧..... 毫无头绪,接着主观认为应该没生产者没发吧,接着开始开相关日志,恰好 日志有事info,看不到,找了半天,只能证明生产者发了,并且sucess,因为是异步,不知道到底成功没,于是又看相关框架源码,也没发现问题,接着找日志看到,msgid,一搜没有,眼前一亮,肯定消费者没处理了,单又不知道哪里问题,陷入混乱,静下心来,别的都可以,就这个服务收不到,那肯定是今天发的东西有问题,代码已经在测试环境验证没问题,问题会子啊那的,框架.. 配置... 于是对比框架 对比配置都没问题,这是突然想到之前有同事说修改相关代码,会不会是他改出问题了,一看聊天记录,感觉确实是这里的问题,接着又开始找相关佐证,通过框架源码找到框架相关错误日志格式,接着一搜果真如此,哎同事当时说改这个东西的时候,自己只是还说这样改会不会有问题,当没有追究下去,多个项目都依赖这个基础文件,单生产中发布后,会依赖最新的类,而消费者没更新结果.... 你懂得 序列化.... 其实一开始静下心来,分析 只有今天发的服务有问题,那肯定的发得有问题,然后自己对比问题在哪  对比测试 与 线上环境的差异     配置核对 代码核对 基础配置核对 依赖核对.... 就出来了啊