通常而言,技術随着業務的需要而産生,随着業務的擴充而不斷改進。
一、Web的過去
在老古董般的計算機誕生之後,人們迫切的希望使用它來進行消息的傳遞,資源的共享。
在早期的Web階段,為了滿足資源共享的需求,靜态的Web産生了,但是它隻能提供資源擁有者想與别人分享的内容。
随着靜态Web的使用,人們對它感覺還是有點兒差強人意,畢竟它是服務于資源擁有者,而不是使用者,是以不能滿足使用者的需求。
為了滿足使用者的需求,動态的Web便産生了,它可以辨識使用者,也就是使用者需要使用者名和密碼、手機号等資訊來辨別自己。
由于早期的Web完全是按照資源擁有者的意願來顯示,而突然轉變成要按照使用者的意願來顯示,這個問題該怎麼解決呢?
早期的界面顯示仍然是用到現在的HTML、CSS、JS三劍客,而服務端的語言有Java、PHP、ASP等。
這個時期的沒有前後端之分,用于顯示的代碼和業務邏輯的代碼幾乎是緊密的糅合在一起,很明顯,這是一個很大的問題。
随着業務不斷擴充,開發人員将會越來越痛苦,幾乎是牽一發而動全身,為了解決該痛點,就有了我們如今的前後端分離的概念。
二、Web的現在
随着網際網路商業的發展,不少優秀的企業随着客戶的激增,系統變的越來越卡,這是什麼原因導緻的呢?
第一點:資料量的激增,一些對資料的操作的時間複雜度和資料量相關,是以越來越遲鈍。
第二點:大量使用者同一時間通路Web,伺服器不堪重負,響應速度越來越慢。
第一個問題:比如我們目前常用的關系型資料庫MySql(能白嫖為啥要付錢),以及Oracle(有錢就是任性)。
MySql面對查詢優化有如下解決方案,分庫、分表、分區和索引,對于索引不作過多解釋。
首先問題是:分庫,分表,分區根據什麼來分,真的能解決實際問題嗎?
現在讓我們仔細想想,我們以查詢操作為例,畢竟其他操作是在查詢操作的基礎之上的,如果查詢操作慢的話,實際是慢在哪裡?
我們都知道Mysql索引是B+樹的結構,預設每頁16Kb,假設内部節點大小為16Byte,葉子節點大小為1Kb。
那麼每層内部節點可以有1000個,葉子節點能存儲16個資料行,這樣三層大概能存1.6千萬條資料,而僅僅隻需要進行三次磁盤IO。
假如四層的話,将能存儲160億條資料,這也僅僅隻需要進行四次磁盤IO(不知道能否存的下哈哈)。
當然這是單表的情況下,那麼如果是建立了索引的連表查詢呢?業務不可能隻是單表增删查改吧哈哈!
同樣我們假設B+樹是三層的,現在僅連接配接一次,假設第一次通過索引(假設不用回表)篩選出100條資料,這裡僅用了三次磁盤IO。
接下來進行第二次索引篩選,也就是需要走100*3次IO,假設A,B兩表是一對一的關系(最簡單的情況,也可能沒對上)。
如果再連接配接一張表的話,并且第二次恰好能查詢出100條,那麼第三次也需要走100*3次磁盤IO。總共就是300多次磁盤IO。
當然這僅僅是最簡單的情況下,才走300多次IO,複雜的話有可能走成千上萬次IO,這樣就會特别慢了,有可能查不出來。
首先我們以最小的解決方案出發,根據業務來将資料分成10個區段,最好的情況,每個區都是總資料的十分之一。
我們以1000為log的底,真數為1000萬,将真數除10變成100萬,B+數的樹高仍然沒有變化,也就是并沒有降低IO次數。
那麼分庫和分表呢?他們分為兩種,垂直拆分和水準拆分,垂直和水準也能很形象的描述出來怎麼拆分的,這裡不做過多介紹。
首先分庫肯定是可以減輕資料庫的壓力的,因為連接配接數過多的話資料庫是肯定扛不住的。
但是分表就不好解釋了,為什麼呢,因為分的表始終都在一個資料庫中,另外他的水準拆分和分區有點兒類似。
至于提升性能方面可能是對資料進行操作時可能會對表進行加鎖?(個人了解)
第二個問題:為了解決同一時刻伺服器通路量過多,我們可以再加一些該服務來使用,然後把請求負載均衡到每個伺服器。
這時候通過增加伺服器的方式,伺服器是能夠抗住了,但是Mysql扛不住呀。那該怎麼解決呢?
為了讓Mysql也能抗住,可以考慮使用緩存來儲存熱點資料,但是這個解決不了根本問題,隻能當作是一種優化。
但是這樣會帶來另外一個問題,那就是資料一緻性的問題以及分布式事物的問題。
為了解決如上的問題,引入了如下專業名字負載均衡、緩存、微服務、分布式鎖、XA或TCC...等等。
消息隊列在性能控制方面也是一種緩存的思想,把請求緩存起來,稍後有時間再給你處理,告訴你等着結果。
三、Web的将來
很明顯上面的問題産生的根本原因是性能和穩定性方面。
為了應對穩定性,多搞幾個伺服器或資料庫,然後帶來了資料一緻性方面的問題。
另外由于多搞幾個伺服器,也能提升并發量,但是性能方面還是需要自己進行一些優化。
或許不久後,會有一個高性能資料庫,分庫、分表,分區這種方案不需要我們去考慮。
也可能是底層硬體方面發生改變,磁盤存儲的方式會以另外一種方式進行替代,大幅提高讀寫效率。