Re: [心得] 技能升級假說

作者: soraka (索拉卡)   2013-09-08 00:15:36
針對回應一下
※ 引述《hectorhsu (The Hector)》之銘言:
: 再辯就難看了喔~
: → yols:重點是滿技後系統是否還會累計他的回合數.畢竟這對SERVER很傷 09/07 23:05
: → yols:除非那工程師很懶..不然一般不會開無限上限的記錄(暫記憶空間 09/07 23:06
: → yols:會這麼說是因為假若每個人都有一張黑狗,所以主機得儲存每個 09/07 23:07
: → yols:人每隻黑狗的回合場數,重點無上限。等同要無限空間,這是很 09/07 23:08
: → yols:腦X的程式設計寫法就是... 09/07 23:08
: 1. 一般不會開無限上限的紀錄 => 不太懂您的意思
: int a = 5 和 a = 100000000 儲存空間一樣
: 2. 神魔歡慶600萬下載,假設每個人有1張那就記錄600萬個整數
: 需要 4 Bytes * 6000000 = 24000000 bytes = 24000 KB = 24MB
: 還真大,害我都擔心SERVER會傷爆了 /Q__Q\
: 2. 說MH的程式設計寫法腦殘,這邊一定有MH的工程師會看,他們應該很不爽吧
: 4. "等同要無限空間" 這邊你說空間 空間 空間 那大家應該沒有曲解你的初衷吧?
: → yols:不是資料問題..單純就程式語言概念來講就不可能= =" 09/07 23:09
: 1. 剛剛說空間,現在又不是資料問題了,難道是程式碼太多行?機器太多台?
: → yols:所以才說這是一個很腦X的寫法..因為遲早會爆阿.若是這樣有天 09/07 23:10
: 2. 全球60億人次下載好了,每個人有1隻滿技黑狗
: 需要 24MB * 1000 = 24000MB = 24GB
: 好像我家的硬碟勉強還夠
幫你算仔細一點
60億人次
一個玩家最多有400張卡片
一張卡片要有卡片經驗還有技能經驗(也就是我們在討論的回合數) 也就是2個變數
假設用了理論上絕對用不完的4byte來記錄(2147483647)
6,000,000,000 * 400 * 2 * 4 byte = 19,200,000,000,000 byte = 19TB
你說這個容量是不是有點可觀呢
所以變數大小的取捨還是很重要的喔 揪咪
: → yols:要改就會可能變成大工程..INT 要轉其他型別..ORZ一想到就可怕 09/07 23:11
: (unsigned long long) a = ..
: 我想到也覺得好可怕 > <
對阿 每個變數一次 複製上面的算式一下
6,000,000,000 * 400 * 2 = ...
懶得算了 反正還是很多次
: 推 yols:re..我是覺得不可能..但不是把人當白癡..因為這代表程式有可 09/07 23:14
: 不,你就是把人當白痴
: → yols:能出現的BUG 而已..你要試就試..打我臉我就認了而已 09/07 23:14
: 啪。
: → yols:我只是覺得不可能無上限..而這極限又在哪你又說不準.. 09/07 23:16
: → yols:重點不在65535好嗎...你用DOUBLE也依樣= ="... 09/07 23:20
: 講到這好像你的意思不是指數字很大,我們繼續看下去
: → yols:所以LUKE 若是這樣就跟我說的一樣這篇猜測是錯的 09/07 23:21
: → yols:我只是要說一般程式到達這東西當前上限後基本不會再記錄了 09/07 23:22
: 又是"一般程式",請問閣下是哪一間公司的工程師..
: 推 yols:超過那極限值皆以那數值記,而這極限值可能會以兩種方式記錄 09/07 23:26
: 有人回了,if(N<25000) N++;
: 這樣子的東西比起那些動畫和背後一堆工作...
: 每一場戰鬥有多少邏輯判斷在執行..
: → yols:一種是每個不同SLV最大值最極限,或者以一個不可能人達到數 09/07 23:27
: → yols:來記,但後者所耗費資源基本會比前者多..(光是每人50張卡算 09/07 23:27
: → yols:一百萬玩家*50張卡*後者那極大數,外加同時上線SERVER負擔很 09/07 23:28
: → yols:大... 09/07 23:29
: 剛算過了
: → yols:講真的我不太相信一家手機公司會花到多少錢擴充SERVER 就是= 09/07 23:29
: → yols:讀取卡片資料 搜索卡片資料 搜索卡片個別技能經驗資料.. 09/07 23:30
: 方法問題而已,看到這裡就知道你不懂了,麻煩請留給玩家一個正常討論練法的空間。
好啦 我只能說打臉文真的不要發太快 想法也不要太單純
程式設計要考慮的事情其實還蠻多的... 0.0|||
作者: nightjustin (洛神天來)   2013-09-08 00:16:00
113推一下~補XD
作者: hectorhsu (The Hector)   2013-09-08 00:16:00
我剛有筆誤,回去看一下真實大小再說
作者: hectorhsu (The Hector)   2013-09-08 00:17:00
第一個請 /1000存卡片只要這點空間~夠划算了~
作者: hectorhsu (The Hector)   2013-09-08 00:19:00
照您說的已經是超級高估,也只要19GB
作者: hectorhsu (The Hector)   2013-09-08 00:20:00
是不是有點不可觀呢?啾咪 ^_<
作者: qiaffvvf (鸑鷟)   2013-09-08 00:20:00
所以快把上限改五百張吧 不夠用啦 ><
作者: lin89710 (谷)   2013-09-08 00:21:00
真有60億人數我相信MH會笑著買伺服器的.......才19T
作者: hectorhsu (The Hector)   2013-09-08 00:22:00
是19G,我剛剛發文一開始漏掉K..
作者: yols (yols)   2013-09-08 00:22:00
HEC ..你去看一下我為啥說不可能吧...
作者: yols (yols)   2013-09-08 00:23:00
還有19T 是指記憶體不過真那樣我相信MH 會用GOOGLE那種電腦玩
作者: yols (yols)   2013-09-08 00:24:00
硬碟儲存空間一直不是要點,要點是要順間處理19T資料量阿還有不能讓使用者感覺到你沒服務到我這樣
作者: lin89710 (谷)   2013-09-08 00:25:00
一台SERVER包含他的網路設備 還有他單筆資料的記法
作者: lin89710 (谷)   2013-09-08 00:26:00
一定會算出同時可服務的人數上限 MH也會知道有多少"活"
作者: lin89710 (谷)   2013-09-08 00:27:00
帳號 適時的評估何時需要多租用或是購入新主機維持營運吧.... 當哪天他需要同時瞬間處理19T的資料的時候
作者: lin89710 (谷)   2013-09-08 00:28:00
他應該發到不知到哪裡去了......
作者: soraka (索拉卡)   2013-09-08 00:31:00
重點還是19T的變數空間十分驚人...
作者: yols (yols)   2013-09-08 00:33:00
不過那是指瞬間..只要CPU 有辦法處理的話...
作者: yols (yols)   2013-09-08 00:34:00
但光那CPU 我這邊8核*4處理字串比對有時都快炸了...
作者: rigmarole (Brad Pin~)   2013-09-08 00:43:00
如果他有60億個玩家包包空間有400格...19T硬碟會是什麼問題嗎? 買下google都沒問題了
作者: whatai (多多)   2013-09-08 00:44:00
19T隊伺服器來說根本不算什麼好嗎.. 又再以家用電腦計算
作者: rigmarole (Brad Pin~)   2013-09-08 00:45:00
更不用說一般線上遊戲的資料量跟本遠大於這個數字
作者: yols (yols)   2013-09-08 00:45:00
我是不知這邊文是指硬碟還是記憶體..但我指的是記憶體
作者: whatai (多多)   2013-09-08 00:45:00
且真有60億人次 早就是世界級的超大型網路公司了 好嗎
作者: darkster (草民)   2013-09-08 00:45:00
用不到瞬間吧…遊戲也只有進出場有傳送封包而已
作者: whatai (多多)   2013-09-08 00:46:00
為什魔同時load到記憶體呢? 呵呵 讀完資料庫再來吧
作者: rigmarole (Brad Pin~)   2013-09-08 00:46:00
你真的寫過線上遊戲的server端程式, 就會知道這根本一點都不是問題...
作者: yols (yols)   2013-09-08 00:46:00
任何程式跟資料在運算前是都先弄到記憶體內喔~~
作者: yols (yols)   2013-09-08 00:47:00
所以才會有用快取記憶體存在的必要性
作者: whatai (多多)   2013-09-08 00:47:00
真要19T記憶體只有一個情形 60億人"同時"上線 恩..
作者: rigmarole (Brad Pin~)   2013-09-08 00:48:00
同時上線還不夠哩... 所有卡片資料還要全部用到
作者: Nuaaukw (晨曦之憶、)   2013-09-08 00:48:00
什麼情況才會有六十億人次同時存取啦...你要先擔心網路吧
作者: yols (yols)   2013-09-08 00:48:00
商比較可能做法是累積到一定的量一次做,這就考驗記憶體的大小了..
作者: rigmarole (Brad Pin~)   2013-09-08 00:49:00
你要不要先看一下別人伺服器端的程式怎麼寫的^^""你很明顯都是用想像的,而且還跟現實差很遠...
作者: Nuaaukw (晨曦之憶、)   2013-09-08 00:49:00
你該不會認為這遊戲的資料庫,所有玩家用一個吧?
作者: yols (yols)   2013-09-08 00:49:00
先不管幾人上線啦= ="我這邊SERVER不是一般使用者在用光單台
作者: whatai (多多)   2013-09-08 00:50:00
等你們真的寫過socket SQL相關程式再說吧 根本出師表全文
作者: yols (yols)   2013-09-08 00:50:00
傳送10G封包量就很緊了..現在大概最多1G..那個運算量更不用說
作者: yols (yols)   2013-09-08 00:51:00
應該不可能在同一台就是~只是分批後還要搜尋搜尋後還要運算
作者: yols (yols)   2013-09-08 00:52:00
所以依此推斷下來我才說不太可能是MAX LV 後繼續計數畢竟只搜索運算可能還好 再加上寫入我是覺得壓力有點太大了
作者: darkster (草民)   2013-09-08 00:53:00
總感覺你的邏輯不是用在伺服器型主機上的,硬體層面的存取不需要使用資料庫的人去擔心吧,資料庫伺服器會處理好,除非邏輯錯的太誇張嚴重佔用的伺服器資源
作者: rigmarole (Brad Pin~)   2013-09-08 00:53:00
你知道神魔一場戰鬥只有開始跟結束各會傳一次封包嗎
作者: lin89710 (谷)   2013-09-08 00:54:00
伺服器資源一定是必要的浪費阿 有良心的公司至少會租到
作者: yols (yols)   2013-09-08 00:54:00
YES DARK 因為我本就不是對資料庫那邊很熟,所以我重點在於
作者: Nuaaukw (晨曦之憶、)   2013-09-08 00:54:00
...只有進出戰鬥才有傳送封包為什麼會一直在想壓力的事
作者: yols (yols)   2013-09-08 00:55:00
硬體寫入上,但硬體讀寫絕對會影響服務速度總不會要硬體怪罪
作者: lin89710 (谷)   2013-09-08 00:55:00
夠用的SERVER數吧.... 60億人的遊戲只需要19T的資料空間
作者: whatai (多多)   2013-09-08 00:55:00
真的有60億人"同時"上線再說吧 根本脫離現實 沒有討論必要
作者: lin89710 (谷)   2013-09-08 00:56:00
12點應該不只六萬....
作者: yols (yols)   2013-09-08 00:56:00
那應該得列資料庫才可能了解了..那我們猜再多也沒用
作者: whatai (多多)   2013-09-08 00:56:00
但是同時傳輸封包的機率又是多少? 看清楚現實面吧
作者: darkster (草民)   2013-09-08 00:57:00
真的不熟的話,建議先別爭了,你可以想看看魔獸世界的使用者比神魔多多少,資料量又大多少,為什麼就沒問題魔獸還是即時遊戲喔
作者: yols (yols)   2013-09-08 00:57:00
你沒聽過程式開發者解決不了問題時就是脫一段時間嗎..然後就
作者: Xinlong (Ashyjet)   2013-09-08 00:57:00
dark大.. 你這讓我想到D3一開始...(泣
作者: yols (yols)   2013-09-08 00:58:00
硬體升級價格降低問題解決(啾咪
作者: lin89710 (谷)   2013-09-08 00:58:00
D3那跟工程師沒關係 是韓國買的伺服器不夠 又被中國硬上
作者: darkster (草民)   2013-09-08 00:58:00
啃,死暴風雪分明是拿玩家當測試員
作者: Nuaaukw (晨曦之憶、)   2013-09-08 00:59:00
我只想跟你說,sLv數值有上限是可能的,但是你想法是錯的
作者: Xinlong (Ashyjet)   2013-09-08 00:59:00
我沒有說工程師怎麼樣 我只是在說D3很有問題..沒其他..
作者: lin89710 (谷)   2013-09-08 00:59:00
壓力測試本來就是靠玩家阿XDD 只是這壓力..... 有點大
作者: Nuaaukw (晨曦之憶、)   2013-09-08 01:00:00
有上限的原因絕對不會是因為硬體考量
作者: lin89710 (谷)   2013-09-08 01:00:00
這遊戲的資料 手機就能處理了 伺服器還要考慮硬體
作者: yols (yols)   2013-09-08 01:00:00
WOW機制我沒鑽研過就是總不會一台負責某幾塊地圖運算這樣吧..
作者: yols (yols)   2013-09-08 01:02:00
要看它們怎玩的...或許只記錄地圖上怪物數量跟哪幾個玩家及
作者: Nuaaukw (晨曦之憶、)   2013-09-08 01:02:00
WOW的伺服器單位請用「組」而不是「台」....XD
作者: yols (yols)   2013-09-08 01:03:00
目前動作這些病不會讀寫到硬體,真正要讀寫進去應該是離開遊戲升級..某些情況這樣
作者: yols (yols)   2013-09-08 01:04:00
所以多數資料都是在記憶體跟暫存記憶體間來回的話這樣還好真正寫入跟讀取才會慢(所以登入登出時間都很久阿...
作者: lin89710 (谷)   2013-09-08 01:06:00
你怎麼知道打完之後的溝通多久 到你下次跟他溝通之前
作者: ChiKK   2013-09-08 01:07:00
我是MH有60億玩家伺服器要我架在月球也沒問題…
作者: lin89710 (谷)   2013-09-08 01:07:00
她可能都在寫入 你唯一知道的只有 登入 好像有點久
作者: whatai (多多)   2013-09-08 01:08:00
請做好socket TCP/IP DB distributed DB 的功課再來
作者: yols (yols)   2013-09-08 01:08:00
那我小看硬碟的耐久度了...
作者: lin89710 (谷)   2013-09-08 01:09:00
那東西本來就是耗材 租伺服器的時候都算在價錢裡了
作者: whatai (多多)   2013-09-08 01:10:00
如果真有60億人同時對一"台"伺服器連線 這不叫連線是DDos
作者: yols (yols)   2013-09-08 01:10:00
WHAT大...別這樣要是我兩邊都很熟我還在這做啥!!!!
作者: lin89710 (谷)   2013-09-08 01:10:00
樓上XDDDDDDD
作者: darkster (草民)   2013-09-08 01:11:00
這功課有點多XD,之前都是有點興趣大略看看而已
作者: Domobear (CAT)   2013-09-08 01:12:00
wow都沒問題了,神魔怎麼會有問題
作者: Xinlong (Ashyjet)   2013-09-08 01:13:00
提到WOW 我又只好再次望向D3.. 單純抱怨..
作者: darkster (草民)   2013-09-08 01:13:00
之前晚上12點整,玩家就是在對神魔伺服器DDOS啊XD
作者: yols (yols)   2013-09-08 01:13:00
那是用行為跟程式設計概念做推斷而已跟這邊一樣
作者: KeyFSN ( ~☼☽✩☁~ )   2013-09-08 01:15:00
19T真的沒有很多...
作者: whatai (多多)   2013-09-08 01:21:00
其實有興趣可以先研究封包是怎麼傳輸的 Wireshark很好用
作者: whatai (多多)   2013-09-08 01:22:00
一切的魔法都是從這裡開始
作者: yols (yols)   2013-09-08 01:23:00
封包傳輸我大概了解但我只了解到封包在UNIX 的結構但我不確定
作者: yols (yols)   2013-09-08 01:24:00
跟你說的DB有啥關係就是。所以我著重點都盡量在主機運算負擔而不是網路傳輸負擔
作者: whatai (多多)   2013-09-08 01:24:00
那麼之後可以了解到怎麼發送封包與接收
作者: yols (yols)   2013-09-08 01:25:00
麻自己做包我倒還沒試過大概知道原理,解包基本都OK但這跟DB??????Y
作者: whatai (多多)   2013-09-08 01:25:00
之後就是處理收到的資料 以及如何儲存 要傳怎麼跟DB溝通
作者: yols (yols)   2013-09-08 01:26:00
DB 負擔不是重點在資料庫設計與相關搜索演算法上嗎?
作者: whatai (多多)   2013-09-08 01:26:00
例如你收到一個LOGIN的封包 在伺服器驗證之後 可能會把
作者: yols (yols)   2013-09-08 01:27:00
那邊我感覺玩下去很深阿...深到我會溺死這樣...
作者: whatai (多多)   2013-09-08 01:27:00
登入時間寫入資料庫 伺服器的程式本身沒有這數值也不會儲存
作者: whatai (多多)   2013-09-08 01:28:00
有需要直接從DB撈 如此程式不用開很大的記憶體至於DB資料量超過100萬筆時 就完全是另一個故事了
作者: whatai (多多)   2013-09-08 01:29:00
資料庫優化 效率要深入其實東西也很多
作者: yols (yols)   2013-09-08 01:30:00
姆..這樣寫法我就不清楚了..我一直把DB 跟處理在邏輯上放再一起,而WHAT大則是把它徹底分開這樣比較有效率就是~~
作者: maple205 (艾瑞克)   2013-09-08 02:58:00
有人要喝飲料嗎
作者: ffaatt (不由分說)   2013-09-08 09:24:00
一次不是才處理五張

Links booklink

Contact Us: admin [ a t ] ucptt.com