問題：周一出現(xiàn)生產(chǎn)問題，服務(wù)cps-service報死鎖，adm-service報線程池耗盡。adm宕掉之后，2個小時無法做交易。

分析：初步分析，DBA并沒有發(fā)現(xiàn)表鎖，可能是adm-service超時超過50s之后，cps-service有提交事務(wù)，超過mysql配置的最大50s的時間，所以拋出死鎖，但是唯一的困惑是，Dubbo服務(wù)默認時間為1s，cps不可能等待adm50s

操作：之后在壓測環(huán)境進行測試，adm設(shè)置線程池數(shù)為2，目的讓adm的線程池耗盡，之后10個線程發(fā)請求，adm報線程池耗盡錯誤，cps未報出死鎖；之后將adm服務(wù)sleep50s，之后發(fā)送請求，發(fā)現(xiàn)，cps調(diào)用adm會一直等待50s后，也就是說dubbo的默認超時時間沒有生效，之后需要排查為什么Dubbo設(shè)置超時時間失效。

查看源碼發(fā)現(xiàn)，DubboInvoker類中，如果沒有設(shè)置，默認時間是1秒。

簡單的排查沒有發(fā)現(xiàn)問題，之后想到，dubbo注冊再zk上的url連接中，有timeout的設(shè)置時間，打開zk，拿到該服務(wù)，consumer和provider的注冊url，timeout為180秒，之后在項目中搜索180秒，找到錯誤原因，CPS引用了bmp的xml，該xml配置了consumer的超時時間為180秒