總摘要: spring
2018-01-03
- 摘要: spring注入對(duì)象
1. 在springmvc獲取request的方式中丈挟，RequestContextListener诽俯、.@Autowired诽嘉，這兩種會(huì)不會(huì)有并發(fā)時(shí)的線程安全問(wèn)題悄谐？[河北-波濤]
廣州-小護(hù)士<-> 17:27:29
controller注入request對(duì)象不會(huì)有并發(fā)問(wèn)題
河北-波濤(-) 17:34:27
我也是在網(wǎng)上學(xué)習(xí)井联，想到這種問(wèn)題缠导，這兩種方式的代碼也沒(méi)啥特殊的吧削罩，如果我理解無(wú)誤應(yīng)該是：
RequestContextListener：在web.xml配置lisener沦泌，在代碼通過(guò)全局類獲群肌（HttpServletRequest req = ((ServletRequestAttributes)RequestContextHolder.getRequestAttributes()).getRequest();
@Autowired：
就是什么request屬性，實(shí)現(xiàn)spring自動(dòng)注入吧
@廣州-小護(hù)士 注入式有啥特殊實(shí)現(xiàn)嗎谢谦？不同方法對(duì)應(yīng)不同request溅蛉，而注入的是方法公用的類屬性，這樣不會(huì)并發(fā)時(shí)不會(huì)有問(wèn)題他宛，還是我對(duì)這兩種方式的理解有誤
成都-梅小西(-) 17:42:17
controller里注入的對(duì)象只是線程安全
成都-勇<-> 17:46:12
利用threadlocal 和 ObjectFactory來(lái)實(shí)現(xiàn)的線程安全船侧，每次在processRequest設(shè)置的reqeust對(duì)象, 你看FrameworkServlet這個(gè)類里面的service()方法嘛
廣州-小護(hù)士<-> 17:51:22
先看看 DispatchServlet源碼~
河北-波濤(-) 17:51:58
a請(qǐng)求映射到controller的方法1，b請(qǐng)求映射到方法2厅各，a镜撩、b都會(huì)對(duì)controller的request做注入，如果a队塘、b請(qǐng)求同時(shí)發(fā)起袁梗，方法1和方法2中的去使用這個(gè)被注入的request，那這個(gè)被注入的request到底是對(duì)應(yīng)哪個(gè)請(qǐng)求憔古？這不會(huì)用線程安全問(wèn)題遮怜？
成都-勇<-> 17:54:05
你可以簡(jiǎn)單的認(rèn)為每個(gè)請(qǐng)求都會(huì)啟一個(gè)線程來(lái)處理，所以threadlocal獲取的對(duì)象也不一樣的
廣州-小護(hù)士<-> 17:54:45
如果說(shuō)用到的request不是真實(shí)的request鸿市，是代理類. 從頭到尾都在代理锯梁。注入request對(duì)象有兩種方式嘛即碗，一個(gè)是方法上傳參，一個(gè)是字段注入. 方法傳參很好理解陌凳，就是反射調(diào)用的時(shí)候傳參進(jìn)去, 字段注入就比較難理解了. 單例模式下也是安全的. Inject HttpServletRequest into Controller
2018-01-08
- 摘要: 線程阻塞
1. 請(qǐng)教大家一個(gè)問(wèn)題剥懒，我想限制一個(gè)線程池的最大隊(duì)列不超過(guò)200，如果線程里已經(jīng)有 core+隊(duì)列200 個(gè)線程了合敦，就阻塞初橘，直到有線程空出來(lái)，才能放入新的線程請(qǐng)求, 有現(xiàn)成的線程池可以實(shí)現(xiàn)這樣的功能嗎充岛？[杭州-Freedom]
深圳-rubin(-) 13:59:44
Jdk就可以滿足呀
杭州-Freedom(-) 14:00:30
怎么做保檐？
廣州-揚(yáng)帆(-) 14:00:44
線程池有四種方式來(lái)處理滿了后的線程, 你如果滿了后直接丟棄的話，本身就有的
廣州-小護(hù)士<-> 14:00:46
@杭州-Freedom 你到底要隊(duì)列還是線程池崔梗？
北京-w(-) 14:01:25
newFixedThreadPool
杭州-Freedom(-) 14:02:18
有點(diǎn)像隊(duì)列+線程池展东，因?yàn)橥獠空?qǐng)求會(huì)一直不斷的放入，但我想限制線程池最多只能有200個(gè)線程
廣州-小護(hù)士<-> 14:04:37
我感覺(jué)你要的是生產(chǎn)者消費(fèi)者模式炒俱，固定隊(duì)列長(zhǎng)度
成都-孤狼(-) 14:04:40
線程池不是有一個(gè)最大線程數(shù)目的參數(shù)么
廣州-小護(hù)士<-> 14:05:02
PriorityBlockingQueue, DelayQueue, LinkedBlockingQueue, 我推薦的設(shè)計(jì)是用LinkedBlockingQueue + threadpool
成都-梅小西(-) 14:30:54
直接core=200然后用無(wú)限隊(duì)列不就行了
杭州-Freedom(-) 18:23:02
最終解決方案: 支持生產(chǎn)阻塞的線程池
2018-01-09
- 摘要: 線程阻塞
1. 下單支付遇到個(gè)問(wèn)題盐肃， 下單后事務(wù)還沒(méi)提交或者提交到數(shù)據(jù)庫(kù)后還沒(méi)執(zhí)行完成，訂單這邊就收到付款成功的MQ 消息权悟，但是此時(shí)根據(jù)結(jié)算號(hào)去查找訂單的信息 有幾率出現(xiàn)查詢不到的場(chǎng)景砸王，不知道有啥好辦法規(guī)避掉呢？ [杭州-水表哥]
北京-喜<-> 17:26:10
這個(gè)問(wèn)題太多了啊. 都不知道該給你出什么方法了
杭州-水表哥(-) 17:26:48
我的問(wèn)題嗎峦阁？
北京-喜<-> 17:27:03
下單后事務(wù)還沒(méi)提交或者提交到數(shù)據(jù)庫(kù)后還沒(méi)執(zhí)行完成谦铃，訂單這邊就收到付款成功的MQ 消息 - 這里有2個(gè)問(wèn)題
北京-Sun(-) 17:27:07
你這個(gè)是app端支付完成，但是你訂單都沒(méi)生成榔昔。
北京-喜<-> 17:27:23
此時(shí)根據(jù)結(jié)算號(hào)去查找訂單的信息 有幾率出現(xiàn)查詢不到 - 這里是1個(gè)問(wèn)題, 2, 你訂單沒(méi)生成或者沒(méi)修改完?duì)顟B(tài)對(duì)面就能付款了驹闰？
湖南-stone(-) 17:27:29
應(yīng)該是先有訂單吧，回調(diào)的時(shí)候再改狀態(tài)啊, 怎么會(huì)查不到訂單撒会？這業(yè)務(wù)不正常吧
杭州-水表哥(-) 17:28:02
下單這邊只是把訂單號(hào)和結(jié)算信息返回給客戶端嘹朗，但是這個(gè)時(shí)候事務(wù)是已經(jīng)提交到數(shù)據(jù)庫(kù)了，但是量大的時(shí)候 其實(shí)數(shù)據(jù)庫(kù)這個(gè)事務(wù)都還沒(méi)執(zhí)行完成, 會(huì)出現(xiàn)這種場(chǎng)景的 時(shí)間 基本精確到10毫秒以內(nèi)
北京-Sun(-) 17:28:37
那就等事務(wù)完成后在返回給客戶端啊诵肛。
北京-喜<-> 17:29:10
那就是業(yè)務(wù)流上 本身是保證不了時(shí)序的
杭州-水表哥(-) 17:29:15
這個(gè)事務(wù)完成后 其實(shí)也不可控啊屹培，完全依賴數(shù)據(jù)庫(kù)了
北京-喜<-> 17:29:25
你就需要額外做個(gè) 時(shí)序派發(fā)的處理, 面向狀態(tài)機(jī)躍遷，自己做個(gè)統(tǒng)一的時(shí)序控制和排外處理
杭州-水表哥(-) 17:30:12
沒(méi)看懂
北京-喜<-> 17:30:15
簡(jiǎn)單的說(shuō)就是怔檩，支付回調(diào)回來(lái)褪秀，發(fā)現(xiàn)訂單狀態(tài)不對(duì)。先落地
成都-奮斗(-) 17:30:18
不是應(yīng)該先把訂單生成成功之后薛训，再提交支付到第三方嗎?
重慶-Rocky(-) 17:30:26
嗯 先存下來(lái), 后期定時(shí)跑, 更新
北京-喜<-> 17:30:41
等訂單下單成功之后媒吗，反向去解鎖支付回調(diào)數(shù)據(jù)
杭州-水表哥(-) 17:30:43
@ffud 明白你的意思了，也就是所謂的補(bǔ)償
北京-喜<-> 17:30:52
不是補(bǔ)償, 你這個(gè)是前半段的技術(shù)設(shè)計(jì)有問(wèn)題, 在后半段 誰(shuí)也不知道互相之間的關(guān)系, 就得互相檢測(cè), 你完成的時(shí)候看看我對(duì)不對(duì)乙埃， 我完成到時(shí)候看看你在不在
天津-Michael(-) 17:31:51
下單和支付fork/join
成都-奮斗(-) 17:32:04
喜神闸英，是不是應(yīng)該先生成了訂單锯岖，然后再提交到第三方支付，收到回調(diào)消息自阱，更新庫(kù)狀態(tài)嚎莉。這是才正常的業(yè)務(wù)流程吧, 怎么可能你自己的庫(kù)的訂單還未生成完成米酬，第三方回調(diào)都來(lái)了
北京-喜<-> 17:32:37
是的沛豌，一般是這樣, 否則有超賣、退款等風(fēng)險(xiǎn)
重慶-Rocky(-) 17:32:55
現(xiàn)在討論的就是這種特殊情況
杭州-水表哥(-) 17:33:21
奮斗赃额，我現(xiàn)在是訂單號(hào)和結(jié)算號(hào)都生成了加派，事務(wù)也提交到數(shù)據(jù)庫(kù)了，只是量大的場(chǎng)景下會(huì)出現(xiàn)事務(wù)還沒(méi)執(zhí)行完成跳芳，客戶端就可以付款芍锦，訂單這邊就收到 MQ 消息了
成都-奮斗(-) 17:33:36
恩，明白你的意思, 你們是在訂單事務(wù)里面也提交到第三方支付的吧
杭州-水表哥(-) 17:34:13
按照喜神的意思飞盆，我可以在收到 支付消息后 如果找不到訂單信息的話 先落地后續(xù)再處理這筆單子
北京-喜<-> 17:34:18
就是狀態(tài)機(jī) 躍遷不是 下單成功-> 支付成功娄琉，多了一個(gè) 支付成功->下單成功->支付成功, 應(yīng)該是在事務(wù)里RPC了
杭州-水表哥(-) 17:34:55
我沒(méi)在訂單事務(wù)里面 提交第三方支付的
北京-喜<-> 17:35:14
有異步么
杭州-水表哥(-) 17:35:19
沒(méi)異步的, 訂單這邊 只負(fù)責(zé)生產(chǎn)訂單號(hào)和結(jié)算號(hào)， 客戶端拿到這些數(shù)據(jù)后去請(qǐng)求支付
北京-喜<-> 17:35:27
沒(méi)有的話吓歇，就是前面說(shuō)的第3個(gè)問(wèn)題 主從延遲, 訂單有超時(shí)不支付孽水，關(guān)閉的動(dòng)作么？
杭州-水表哥(-) 17:36:16
有的, 我自己判斷應(yīng)該就是 事務(wù)提交到數(shù)據(jù)庫(kù)里面 在排隊(duì)等待處理城看，但是這邊有結(jié)算號(hào)就可以去支付
北京-喜<-> 17:36:39
有好多方案可以處理女气，前面提到的可以, 還有一種是解決主從延遲的問(wèn)題, 加熱點(diǎn)，讀主庫(kù)也可以
杭州-水表哥(-) 17:37:23
目前訂單和支付 我這邊都是 讀主庫(kù)
北京-Jerry(-) 17:36:38
按照你說(shuō)的應(yīng)該會(huì)造成長(zhǎng)款問(wèn)題吧
北京-喜<-> 17:37:37
如果一直在讀主庫(kù) 出現(xiàn)這個(gè)問(wèn)題
杭州-水表哥(-) 17:37:39
因?yàn)橹鞍l(fā)生過(guò)主從延時(shí) 就沒(méi)再讀從庫(kù)
北京-喜<-> 17:37:42
就是前面的設(shè)計(jì)的時(shí)序不對(duì), 如果不改時(shí)序测柠，就用先存儲(chǔ)炼鞠，后處理的方案
杭州-水表哥(-) 17:38:07
能詳細(xì)的說(shuō)下 哪里的時(shí)序不對(duì)嗎？
北京-Jerry(-) 17:38:08
你的業(yè)務(wù)每秒多少筆交易轰胁？
杭州-水表哥(-) 17:38:28
每秒有100單的并發(fā)量
北京-喜<-> 17:38:25
你提交給三方支付之前, 你對(duì)外承諾的業(yè)務(wù)語(yǔ)義谒主，是你的事情做成功了, 結(jié)果支付回調(diào)回來(lái)之后，發(fā)現(xiàn)你沒(méi)做成
北京-Jerry(-) 17:38:36
你這個(gè)是不是有專門(mén)的一個(gè)訂單服務(wù)的赃阀，和交易系統(tǒng)是拆分出來(lái)的
杭州-水表哥(-) 17:38:47
這個(gè)問(wèn)題 搞活動(dòng)的時(shí)候會(huì)比較明顯
成都-奮斗(-) 17:39:07
強(qiáng)制服主庫(kù)
北京-喜<-> 17:39:39
事務(wù)沒(méi)做完瘩将，就把訂單號(hào)+訂單狀態(tài)返回出去了？
杭州-水表哥(-) 17:39:54
事務(wù)只是提交到數(shù)據(jù)庫(kù), 關(guān)鍵我這邊也這邊也不知道數(shù)據(jù)庫(kù)這邊把事務(wù)執(zhí)行完了啊
北京-喜<-> 17:40:40
這個(gè)事務(wù)不是你們自己的代碼編寫(xiě)的么凹耙？
杭州-水表哥(-) 17:41:00
是的
北京-喜<-> 17:41:06
那怎么會(huì)不知道呢, JDBC處理完 你知道的啊
杭州-水表哥(-) 17:42:37
網(wǎng)上我是查了下 有 事務(wù)處理成功以后的回調(diào)姿现，我今天問(wèn)下 dba ，他的意思是說(shuō) 事務(wù)只是提交到數(shù)據(jù)庫(kù)了肖抱，但是不是提交到數(shù)據(jù)庫(kù)就意味著執(zhí)行完成了
北京-喜<-> 17:43:17
什么數(shù)據(jù)庫(kù)
杭州-水表哥(-) 17:43:24
mysql
北京-liunx(-) 17:44:07
commit之后成功或者失敗都應(yīng)該會(huì)有一個(gè)結(jié)果吧备典？
杭州－東子(-) 17:44:28
@杭州-水表哥 這查錯(cuò)了吧
杭州-水表哥(-) 17:46:05
怎么說(shuō)
上海-給你們(-) 17:46:45
從庫(kù)策略本來(lái)就是做報(bào)表之類的查詢用的, 如果實(shí)時(shí)性要求高就別才用主從這種策略
杭州-水表哥(-) 17:47:03
網(wǎng)上我是看到有 spring 事務(wù)提交后的回調(diào)處理，也就是說(shuō) 事務(wù)真正提交后再處理后續(xù)的意述。 喜神提佣，求解惑 我也不太想通過(guò) 數(shù)據(jù)線落地再去處理吮蛹。
北京-喜<-> 17:47:15
不是一件事, 你們DBA說(shuō)的是 begin 和 commit , begin不等于一定能夠commit, 你的問(wèn)題是commit后，沒(méi)拿到 提交的信息, spring 那個(gè)是java的callback拌屏，更不是一件事, commit成功或失敗都是可以知道的啊潮针。commit如果返回的是成功，是一定會(huì)包成持久化的. 這個(gè)是ACID的語(yǔ)義倚喂，mysql不能master擴(kuò)展 也是因?yàn)檫@個(gè)原因每篷。本地強(qiáng)一致性，CAP里 不做P端圈。 先落地焦读。后續(xù)互相檢查在處理，是可以解決的舱权， 但還是沒(méi)找到根本原因矗晃。
杭州-水表哥(-) 17:51:05
嗯，這個(gè)是第二種方案宴倍，還是沒(méi)找到根本原因
北京-鵝鵝鵝(-) 17:51:06
mysql就是不做p吧
北京-喜<-> 17:51:15
是啊张症， 你可以在講講處理流程 , 1 2 3 4這樣列下
上海-給你們(-) 17:52:17
異步支付回調(diào)比訂單生成早 在支付回調(diào)后沒(méi)找到訂單放到隊(duì)列里，設(shè)置一個(gè)重試次數(shù)就行了鸵贬， 從用戶付款到支付回調(diào)俗他，我覺(jué)得正常情況下不會(huì)比生成訂單早，你們訂單生成的真復(fù)雜恭理。
北京-alex(-) 17:54:43
一般都是生成訂單在支付的吧
上海-給你們(-) 17:54:52
不一定
北京-alex(-) 17:54:55
也見(jiàn)過(guò)不支付不生成訂單的app拯辙， 京東淘寶等都是先有訂單在支付的
杭州-水表哥(-) 17:55:39
下單大致流程
1.生成結(jié)算號(hào)
2.預(yù)減庫(kù)存
3.執(zhí)行下單 （生成訂單號(hào)，調(diào)用支付服務(wù)增加結(jié)算付款信息）
4.返回客戶端 訂單 結(jié)算信息 （后續(xù)可以發(fā)起支付操作）
北京-喜<-> 17:57:13
全部是同步的颜价？
杭州-水表哥(-) 17:57:52
嗯涯保， 壓根沒(méi)異步的場(chǎng)景
北京-喜<-> 17:58:07
那可能是 redo log 到 fsync file system的問(wèn)題， 你問(wèn)下DBA周伦， redo log刷盤(pán)用的什么策略
杭州-水表哥(-) 17:59:45
mysql 默認(rèn)的, redo log 刷盤(pán)用的是默認(rèn)的 夕春，具體是啥我也不懂
北京-喜<-> 18:02:04
就是redo log buffer，會(huì)在事務(wù)commit的時(shí)候专挪，一定持久化到數(shù)據(jù)文件里
杭州-水表哥(-) 18:03:04
也就是說(shuō) 只要事務(wù)提交了及志，那就肯定數(shù)據(jù)都持久化到數(shù)據(jù)庫(kù)了
北京-喜<-> 18:04:02
是的
杭州-水表哥(-) 18:04:27
那我知道啥問(wèn)題了，目前截圖給群里的代碼是我改造后的寨腔，原來(lái)的代碼事務(wù)是無(wú)效的, 原來(lái)的事務(wù)代碼 只在 executeOrder 這個(gè)方法上面加了事務(wù)注解速侈，沒(méi)生效, 在addOrder 上加了注解就行了.
