Re: [請益]高流量網站和資料結構
高流量應用 你沒定義好需求根本無法討論怎麼設計
1. 資料一致性要求? 持久性要求?
如果一定要用到交易,基本上一致性和持久性就一定要,
就直接用掉 CAP 定理的 Consistency,算是最常見的瓶頸
2. 如果是寫 log 系統,這種 QPS 要破萬比網站容易多了,也很常見
在台灣,檯面下 QPS 破萬的 log 系統應該比檯面上的"網站"多
但這種系統通常送出 request 就不理他了,
因此後端可以用 kafka 之類的大量接收 至於要怎麼寫 log 與寫到哪 (通常是 HDFS)
是另一段需求
3. 如果一致性不重要,基本上就盡量設計成可以無腦 Scale out
但如果系統有做 sharding,那 Scale out 的數量非常驚人,
因此如何撐爆單台的資源就變得重要
4. 根據情境,還需要判斷 bare metal server 的重要性。
例如你程式用到 file system cache 等
5. 事情沒這麼單純,還有 latency/SLA 要求,如 95% percentile < 100ms 等
6. 外加 request payload 大小多大
7. 其實這些系統會再劃分好幾個子團隊,例如搞 storages、搞整合(dependencies)測試
真正搞大流量設計的是核心中的核心
其中因為系統通常包含非常多 components,整合測試規模可能會很複雜
我覺得還有很多我沒列到的 畢竟大流量系統的情境多元,
即使同樣的需求,不同團隊討論出的設計也不盡相同
因此在討論"大流量"沒先說好需求,那討論基本上會過於發散
如果你是靜態網站 那就 CDN 設好就能撐 QPS 一萬惹
要進大流量系統的團隊 不一定要需要先做過
即使考系統設計 也只是想知道你對於每個 Componennt 抉擇的邏輯合理性
實務上設計因為需求會更 tricky
因此建議:
a. 基本知識弄好: OS 演算法 資料結構 multithreads 寫程式基本功
語言也要夠深,知道怎麼做 Memory/CPU profiling
如果有用到如 JVM 的技術,也要知道 GC 演算法與怎麼分析與調整參數
b. 找出大流量團隊在哪,不是你進 google 就能搞這個
--
※ 編輯: alihue (106.73.26.66 日本), 08/22/2021 15:56:03
補充,以購物網站就有不同的流量主題:搜尋 訂單成交 商
品庫存 推薦系統 使用者前端log
有沒有經驗啊 靜態網站QPS才1萬
隨便挑臺大學維護的系網站壓一下
這樣都能發文哦
真的完全在打臉自己基本功的部份
系網站不是商用機器 一般pchome買的到的commodity
https://i.imgur.com/lw1Ig63.jpg
Lushen人格跑出來了
請問jason大大的系網站每個request是多少流量?
推 一致性的問題真的是高併發的難題
HDFS? 直接放到S3不是更簡單?
update. 查了一下同樣用途 s3 也做得到,選擇細節就看各 team 不過大公司還是會想要弄自己私有雲
QPS 還要看同時連線數量吧?你單機可以模擬十萬個 tcp
connection?
Lushen 是誰
你捅過的鄉民,只是 ip 剛好跟 jason 一樣
你認錯人了我不是版主
抱歉 認錯人
對了 我好奇 jason 是測試哪個網站 我可以用 wrk -t1
-c10000 -d180 跑跑看
但後續資料整合就知道了。目前就在收s3的鍋
※ 編輯: alihue (106.73.26.66 日本), 08/23/2021 06:23:26
.............
6
講購票系統,台灣的講法永遠只有一個,就是AWS 可以動態增加,沒了。 劃位如何LOCK? 要先扣再劃,還是先劃再扣? 還有劃位方式? USER 自己挑? 都電腦挑? --9
「沒有學會走,先學跑,從來不是問題,但先問一問自己是不是天才。 如果不是,就要一步步來。」 (寒戰2 梁家輝) 我假設你是三年以內的工程獅,那有這個問題合理 那如果你是三年以上的工程獅,Umm... 這麼說好了,高併發跟海量請求其實是集合性的名詞、概念跟技術64
首先很高興看到原PO發問 能夠這樣追逐更深入的技術,先恭喜你,離高手又更近一步了 我寫程式要飯也好一陣子了,分享一下我從聽說大流量很屌,想玩大流量, 到現在可以真正碰觸到大流量一路的心得 在開始之前,先回應原PO的 搶票網站 例子9
首Po先自承是非本科的新人 最近看了版上的討論串,覺得自己的確實是 沒有CS基礎的API工程師,以前在學校修過資料結構 但是只有一些很粗糙的觀念 像是hash function因為返回的是index,所以在查找資料上非常快16
這是常用場景,已知問題,所以有很多解決方案。 其中一種就是類似Twtiiter的Push架構,每次新增一個員工就把資料寫進cache&DB 然後API打進來先去問cache要資料,然後cache多設幾個組成一個cluster, 避免單點失效...這些知識都可以從下面推薦的網站中學到,不用做過也略知一二 : 還是說這可能跟資料結構比較無關,我要去補充其他知識才會知道
17
Re: [心得] 如果可以, 真的建議不要再去創業公司了我只是來推薦一本書的 叫作學徒模式 裡面寫到在各種人生遇到瓶頸時該怎麼解 書中滿多建議都很實用 在去年找工作時 投了履歷給TonyQ大14
Re: [請益] 後端精進的方向?如果為了薪水導向,那跟開發語言無關,跟產業有關 每個語言都很好,但根據它的長短處,實務應用的場景各有不同 如果你求的是全端快速開發網站,那 PHP、ROR 等等的成績有目共睹 如果你求的是商業生態系完整,那 .NET、Java 歷史悠久 如果你求的是運行的極速,這幾年 Go、Rust 能見度上升有其道理3
Re: [心得] 如果可以, 真的建議不要再去創業公司了結論:人的問題、際遇的問題 大公司的架構你沒權限摸不到 大公司的設計你沒經過一連串的開發過程 不懂為何這樣設計 多數的情形是2
Re: [請益] 當主管要求資深RD撰寫自己經驗的文件額 這種要求還是第一次聽到 如果是畫畫UML圖 講一下各系統的關聯 讓新接手的同事能快速上手 這個是滿正常的 有底子的人看圖再自己追code就夠了- 作者: bookbook (bookbook) 看板: job 標題: [台北] 資深SA系統分析師-善導寺附近 時間: Tue May 31 15:20:29 2022 job版禁止張貼違反「就業服務法」、「性別平等工作法」、「勞基法」與其他法律之文章 發文者已同意一切遵循現行法律,並確知文責自負。本工作確實勞健保!