→ pttuser:唉…寫得讓人看得懂很難嗎？ 02/20 17:03
推 YahooTaiwan:我始終覺得連code都沒看過就在分析系統優劣是一件很奇 02/20 19:57
→ YahooTaiwan:怪的事情 02/20 19:57
推 leafy:這篇好難懂啊，能說得更清楚一點嗎 02/21 00:59
就是這幾位大大說的這件事.
mow811236:所以有人有看到IISI發新聞稿推卸責任？ 02/12 17:48
mow811236:是誰把有問題的平台驗收過的？ 02/12 17:50
mow811236:說有問題也不大對，因為那BUG台灣沒能力處理 02/12 17:55
有一說是這樣的:
也就是新版AIX 與新版 Middleware weblogic 對不起來, 懷疑有些
功能沒動作或不對.
mow811236:我看最大的錯誤就是沒拿真實的上線環境去做壓測 02/12 17:56
mow811236:不過這次的事件給台灣各大SI廠商一個警惕 02/12 18:02
mow811236:原廠發出的補丁該上還是要上，沒有天天過年的 02/12 18:05
就扯到團隊有的有patch,有的沒有, 所以對不攏. 也就是sub version不對.
ppttpptt:噗，真的是雖小還是有人指事要換成i公司的solution? 02/12 23:30
yesonline:原廠發的補丁有更新喔, 結果還是當掉了... 02/14 18:36
用tuxedo 還是 queue, 基本上核心也是 queue, 這是distributed transaction
常用的老方法, 使concurrent 變按序排隊, 但如果拆或併了一些queue, 某些地
方沒分析寫好, 因共用資源鎖定, 相互碰上了就會造成死鎖.
若只是version問題, 暫時不patch/update 用舊的就能先過關. 就能先清狀況.
推 luciferii:g老師明明就狀況外，不知為何硬要回這幾篇? 02/21 01:36
→ Lordaeron:又來吐一下,明明都是QUEUE,何苦買MQ? 02/21 18:36
→ Lordaeron:自已寫一個會不會比較QUEUE? 02/21 18:36
這個戶役政在1986-1993完成時,就是由中央大學資工所的黃教授在III開頭
做的. 後來的連線,通報也是在此基礎下完成, 這系統出了狀況, 怎麼不會
讓人好奇? 以往, 這系統都不支援跨區領取戶口謄本, 也很令人納悶, 還
以為是繳費拆帳問題阻擋了這事.
這次的結婚登記, 就出狀況的報導言, 是有跨區查閱及跨區更新身份證. 顯
然是勇敢的跨出去了!
這樣的bug, 是一題能上教科書的好問題!
→ Lordaeron:跨區更新新分證,舊系統就可以做了, 請問跨出什麼? 02/23 01:47
→ Lordaeron:講到教科書, 台灣的好像沒在教這種"常用的老方法". 02/23 02:29
→ Lordaeron:要不要上一下教科書呢? 02/23 02:30
去年9月去遷戶口, 只好跟著換身份證, 同區更動可能還是得上報內政部,雖慢得
很難想像但還是可以忍受.
新舊差異不大, 但可能更強調及時通報更新, 才是新系統的特點.
戶政從日據以來, 警察就是假借查戶口年節到訪, 抓通緝犯.
幾個金融犯都是從法院通報到戶政到海關太慢, 有時差得以潛逃. 如今資安/國安
無限上綱, 即時相互通報似乎是新戶政系統的想法, etag 可讓警政即時查詢, 繳
費計扣帳反而是一天後才知, 就可知"即時通報"目的何在?
即時通報要即時反應, 就會即時更新並再通報其他相關單位更新再回報.
這些連鎖的即時異動, 因跨網路而延遲, 若都要連鎖互動, 鎖定時間太長, 就會企
圖分段鎖, 雖有queue 的串列化排隊, 仍然解不了相互不同queue內的程序搶奪相
關資源的鎖定, 若沒有仔細分析就會造成死鎖.
這種 distributed transaction/concurrent transaction 原理現象都會教, III
的老手怎會犯這種錯? 可以平行的不平行就會排隊等候慢得很, 不該平行的沒管
制同步做好亂平行, 那就是造成錯誤甚至相互死鎖. 這種time dependent error
因狀況有隨機性, 要重覆展示不易, 是很難靠一般測試得知的.
→ Lordaeron:III的老手? III推出的Big5還重覆字呢,還不只一個呢. 02/23 10:51
→ Lordaeron:另外,III幹出的鳥系統可多到你怕呢,你要不要去了解一下 02/23 10:52
→ Lordaeron:你口中的老鳥們的偉業才出來講呢. 02/23 10:53
→ Lordaeron:再來,queue的產品,我是沒見過resource lock的. 還想請 02/23 10:53
→ Lordaeron:教你一下你用的是哪一套. 02/23 10:54
event queue 或 message queue 就是 request 送進 queue 排隊, 再由queue送給
對應的 object process 處理 request. 處理的時候可能因被其他 queue service
object/process 鎖定資源, 而得不到 resources 就只有等候. 互等就有可能互鎖.
queue 化並行多進的輸入成串列排隊, 就queue操作言, 空位位置這項資源的更新就
用到 lock 以維持正確同步與更新, 只是這是系統幫應用者寫好.
→ alan3100:有卦就報別一直打迷糊仗,講的東西課本裡都有的話沒人想看 02/23 13:03
→ Lordaeron:問題: 請教你一下你用的是哪一套(哪麼公司的產品)會 02/23 15:41
→ Lordaeron:lock? 給你選,IBM, ORACLE, MS, TIBCO, ActiveMQ, 02/23 15:42
→ Lordaeron:ZeroMQ, RabbitMQ. 其它(請填寫)______? 02/23 15:43
producer/consumer 對一個有限長度的 queue 做塞進,取出 東東的動作, 如果只限
只有這兩者使用, 對進出位置更新不用到共用變數可不動用到 lock. 但通用的queue
其producer或consumer都非只有一個, 兩個以上的producer使用同一個queue, 對同
一個位置變數更新, 以便存東東的位置值就必須動用到 lock. 只是這是底層系統幫
忙做, 所以看不見. 各別只有一個producer/consumer使用同一個 cycle queue, 若
用共用的queuelength 決定queue empty/full 狀況就會用到 lock 機制.
使用現成的queue感覺不到queue如何有lock operation, 但會用到queue, 就是有調
整處理動作(如producer/consumer)前後次序必要才會擺個queue維持某個次序. 訊息
驅動的異動(Transaction)對更新的對象是否需要考慮同步鎖定, 就在於這些對象是
否皆必經過等效串列化的唯一queue才能取得. 若不是透過這個機制的共用資源就有
自備鎖定的額外必要. 這是如何正確使用串列化等效的問題, 不是使用了queue就都
沒有同步鎖定.
這題是課本都有, 範例一般也都會. 但實況都不是可無限擴張的理想狀況, "有限制"
是經常被忽略的.
→ Lordaeron:還在答非所問. 等你答為所問囉. 02/23 19:01
→ alan3100:...你到底打給誰看啦 鬼打牆喔 02/23 19:07
那種 multiple input queue 可以不用到 lock 機制 可以實現的? 這是回答.
→ Lordaeron:有LOCK也不用AP 去管啊,你用過嗎? 02/23 19:28
LOCK 都是 system call 靠 system support 來使用. 該用的地方還是得用.
message queue 只是 確保process間訊息傳遞正常. concurrent acccess 的效率化
還要再依靠等效串列化才有交錯平行處理的效率, 只有排隊執行無法得到交錯平行.
→ Lordaeron:請問你用的哪一個產品會需要到你去管LOCK的? 02/23 22:14
→ Lordaeron:選項已經給出, 請回答即可, 別扯了. 02/23 22:14
如果queueA送出訊息啟動一個processA去update某個共用變數x及另一個某條件下
才更新的y. a,b,c process都透過 queueA來啟動 processA 更新x但都不更新y,
另一個 p process 則是透過queueA更新x及y, q process 則是為了速度及優先可
直接更新y. a,b,c,p,q 都是進行中的process. 此時, 這個高優先的process q 及
一般的processA要不要對共用的y透過系統支援做 LOCK 以確保正確有效?
→ Lordaeron:請問你用的哪一個產品會需要到你去管LOCK的? 02/24 10:25
這個問法是沒有意義的. 只要產品的功能不能符合需求, 就必須利用底層的系統
支援來自備所要的功能. LOCK 通常是作業系統會提供的支援, AP只要會叫用也是
可以 by-pass middleware 進行自己所要的特異功能.
所以是產品沒提供的功能, 就有可能要自備管理的機制. 內政部擁有警政的軍力,
只要掛起國安的需要, 很多實時監控與通報的"高優先"需求就會介入, 而且還會
要求夾在公開系統中做隱密式的處理. 這種需求是存在的也不用置疑.
→ Lordaeron:哪不然怎麼問? 什麼是產品, 當然得為使用者處理這些 02/24 17:18
→ Lordaeron:事, 而且要處理好, 你以為產品這麼好做? 02/24 17:19
這個戶政案的需求, 顯然並沒有完全公開. 承包這個案的是否能全然了解並熟練應
用選定的middleware去完成需求是很難說的, 如果承包者認為需要自備某些道具才
能達成需求, 那就會去自己搭建"自認為"middleware做不到的部份. 只是出了狀況
只能說不夠戒慎恐懼, 太过掉以輕心, 而且還幾乎退不回去原有的水準, 是有夠糟.
這個案應該成為學習檢討的例子, 應該好好深入公開檢討, 軟體業才能有前途.
→ Lordaeron:就JMS, 但又沒你講的LOCK的問題, 也沒有你搞不清的 02/25 00:13
→ Lordaeron:queue 和tuxedo的應用. 02/25 00:14
→ Lordaeron:你有本事就去開一門tuxedo, queue等middleware的課吧. 02/25 00:14
→ Lordaeron:好過在這發表這些你搞不清楚的東西. 02/25 00:14
Java Message System 可以介接到 MQ 使用. 本質上同producer/consumer queue
是一樣的. 任何Transaction update都是read-modify-write, 強制一個個的R-M-W
都排隊一個一個來, 在網路傳送速度的限制下, 每筆異動就變得耗時太長, 太多人
同時要更新異動就很可怕的等候. 串列化等效的平行處理就必須提供, 如果加上分
散式多server複製型備援, 這事就升級到 distributed transaction, 串列化等效
的平行處理及復原是少不了的. 多servers複製型備援可以用data center 及高速
連網組成雲端縮短傳送的準備與處理時間, 但單一資料庫還是變成分散式資料庫,
distributed transaction 還是難以避免. 後者的 read/write delay & commit
這些同步問題還是得自行設計處理. 單靠MQ是解不了這種平行效率的問題.
賣車票的最壞是開車前明明是有空位卻讓想坐車的買不到票, 但賣些自由座站票靠
車上服務人員調整也能緩解問題. 但戶政則是 "老是要人到,驗明正身, 若非在限
時內服務完, 那絕對是怨聲載道, 人人痛恨. 先進與落後就在這些點顯現.
→ Lordaeron:就跟你說了,你沒用過這些東西,有空去用一用,不要在這扯 02/25 10:26
→ Lordaeron:這些理論. 02/25 10:27
戶政的資料本來只存放在各區公所, 組織精改向上集中, 有些資料因區合併, 集中
在新改的大區, 這很正常. 但內政部在此新系統的角色是甚麼? 各縣市區公所需要
把最新資料備一份到內政部嗎? 有備援顯然是需要的, 但都備援集中到一處嗎? 還
是分更大區相互同步複製備份? 這個架構弄不好就搞死自己了. 現在國際化的網路
教學互動平台, 就已是這樣的系統. 現在不只是用,還要增添新工具新課程, 已有
的要相容, 新的服務要自動銜接上去. 除了及時優先更新這種特異要求外, 可說具
體都有, 這些才不會是用扯的.
※ 編輯: ggg12345 來自: 140.115.50.240 (02/25 15:38)