前端工程師-構建大型網(wǎng)站架構案例(編輯修改稿)
2025-05-13 23:51 本頁面
【文章內(nèi)容簡介】 體系：負載均衡技術(包括但不限于硬件負載均衡、軟件負載均衡、負載算法、linux轉發(fā)協(xié)議、所選用的技術的實現(xiàn)細節(jié)等)、主備技術(包括但不限于ARP欺騙、linuxheartbeat等)、狀態(tài)信息或緩存同步技術(包括但不限于Cookie技術、UDP協(xié)議、狀態(tài)信息廣播、所選用的緩存同步技術的實現(xiàn)細節(jié)等)、共享文件技術(包括但不限于NFS等)、存儲技術(包括但不限于存儲設備等)。架構演變第六步：分庫享受了一段時間的系統(tǒng)訪問量高速增長的幸福后，發(fā)現(xiàn)系統(tǒng)又開始變慢了，這次又是什么狀況呢，經(jīng)過查找，發(fā)現(xiàn)數(shù)據(jù)庫寫入、更新的這些操作的部分數(shù)據(jù)庫連接的資源競爭非常激烈，導致了系統(tǒng)變慢，這下怎么辦呢?此時可選的方案有數(shù)據(jù)庫集群和分庫策略，集群方面像有些數(shù)據(jù)庫支持的并不是很好，因此分庫會成為比較普遍的策略，分庫也就意味著要對原有程序進行修改，一通修改實現(xiàn)分庫后，不錯，目標達到了，系統(tǒng)恢復甚至速度比以前還快了?？纯催@一步完成后系統(tǒng)的圖示：這一步涉及到了這些知識體系：這一步更多的是需要從業(yè)務上做合理的劃分，以實現(xiàn)分庫，具體技術細節(jié)上沒有其他的要求。但同時隨著數(shù)據(jù)量的增大和分庫的進行，在數(shù)據(jù)庫的設計、調(diào)優(yōu)以及維護上需要做的更好，因此對這些方面的技術還是提出了很高的要求的。架構演變第七步：分表、DAL和分布式緩存隨著系統(tǒng)的不斷運行，數(shù)據(jù)量開始大幅度增長，這個時候發(fā)現(xiàn)分庫后查詢?nèi)匀粫行┞谑前凑辗謳斓乃枷腴_始做分表的工作。當然，這不可避免的會需要對程序進行一些修改，也許在這個時候就會發(fā)現(xiàn)應用自己要關心分庫分表的規(guī)則等，還是有些復雜的。于是萌生能否增加一個通用的框架來實現(xiàn)分庫分表的數(shù)據(jù)訪問，這個在ebay的架構中對應的就是DAL，這個演變的過程相對而言需要花費較長的時間。當然，也有可能這個通用的框架會等到分表做完后才開始做。同時，在這個階段可能會發(fā)現(xiàn)之前的緩存同步方案出現(xiàn)問題，因為數(shù)據(jù)量太大，導致現(xiàn)在不太可能將緩存存在本地，然后同步的方式，需要采用分布式緩存方案了。于是，又是一通考察和折磨，終于是將大量的數(shù)據(jù)緩存轉移到分布式緩存上了。看看這一步完成后系統(tǒng)的圖示：這一步涉及到了這些知識體系：分表更多的同樣是業(yè)務上的劃分，技術上涉及到的會有動態(tài)hash算法、consistenthash算法等。DAL涉及到比較多
教學教案相關推薦
鄂ICP備17016276號-1