看板
[ Soft_Job ]
討論串[請益]高流量網站和資料結構
共 7 篇文章
內容預覽:
先自承是非本科的新人. 最近看了版上的討論串，覺得自己的確實是. 沒有CS基礎的API工程師，以前在學校修過資料結構. 但是只有一些很粗糙的觀念. 像是hash function因為返回的是index，所以在查找資料上非常快. 目前還在惡補基礎的DS，至於OS和計算機組織就真的完全沒概念了. 每次看
(還有622個字)
內容預覽:
這是常用場景，已知問題，所以有很多解決方案。. 其中一種就是類似Twtiiter的Push架構，每次新增一個員工就把資料寫進cache&DB. 然後API打進來先去問cache要資料，然後cache多設幾個組成一個cluster，. 避免單點失效...這些知識都可以從下面推薦的網站中學到，不用做過也
(還有681個字)
內容預覽:
「沒有學會走，先學跑，從來不是問題，但先問一問自己是不是天才。. 如果不是，就要一步步來。」 (寒戰2 梁家輝). 我假設你是三年以內的工程獅，那有這個問題合理. 那如果你是三年以上的工程獅，Umm.... 這麼說好了，高併發跟海量請求其實是集合性的名詞、概念跟技術. 後面的先不要想，你至少要知道怎
(還有608個字)
內容預覽:
高流量應用 你沒定義好需求根本無法討論怎麼設計. 1. 資料一致性要求? 持久性要求?. 如果一定要用到交易，基本上一致性和持久性就一定要，. 就直接用掉 CAP 定理的 Consistency，算是最常見的瓶頸. 2. 如果是寫 log 系統，這種 QPS 要破萬比網站容易多了，也很常見. 在台灣
(還有1208個字)
內容預覽:
首先很高興看到原PO發問. 能夠這樣追逐更深入的技術，先恭喜你，離高手又更近一步了. 我寫程式要飯也好一陣子了，分享一下我從聽說大流量很屌，想玩大流量，. 到現在可以真正碰觸到大流量一路的心得. 在開始之前，先回應原PO的 搶票網站 例子. https://imgur.com/TON1Nid. 以這
(還有4693個字)