<strike id="g1ugu"></strike>
    <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

  1. <font id="g1ugu"></font>
    <b id="g1ugu"></b>

  2. 
    

      <tt id="g1ugu"></tt>

        <rp id="g1ugu"></rp>
        首頁 - 網站建設 - 常見的網站服務器架構

        常見的網站服務器架構 返回列表

        瑞瑞2018-09-19編輯發布,已經有1710個小可愛看過這篇文章啦

        初級篇:(單機模式)

        假設配置:(Dual core 2.0GHz,4GB ram,SSD)基礎框架:apache(PHP) + Mysql / IIS + MSSQL(最基礎框架,處理一般訪問請求)

        進階1 : 替換Apache為Nginx,并在數據庫前加上cache層 【數據庫的速度是最大的瓶頸】

        Nginx(PHP) + Memcache + Mysql (此時已經具備處理小型訪問量的能力)

        進階2:隨著訪問量的上漲,最先面臨的問題就來了:CGI無法匹配上Nginx的高IO性能,這時候可以通過寫擴展來替代腳本程序來提升性能,C擴展是個好辦法,但是大家更喜歡用簡單的腳本語言完成任務,Taobao團隊開源了一個Nginx_lua模塊,可以用lua寫Nginx擴展,這時候可處理的并發已經超越進階1 一個檔次了。
        Nginx(nginx_lua or C) + Memcache + Mysql (此時處理個同時在線三四千人沒有問題了)

        進階3:隨著用戶的增多,Mysql的寫入速度成了又一大瓶頸,讀取有memcache做緩存,但寫入是直接面對Mysql,性能受到了很大阻礙,這時候,要在Nginx和Mysql中間加入一層寫緩存,隊列系統就出場了,就以RabbitMQ為例,所有寫入操作全部丟到這只兔子的胃里面,然后屁股后面寫個接應程序,一條條的拉出來再寫入mysql。而RabbitMQ的寫入效率是Mysql的N倍,此時架構的處理能力又上一階層。

        |----write------>RabbitMQ--------
        Nginxlua or c----- |--------->Mysql
        |----read------>Memcache--------

        (此時的并發吞吐能力已經可以處理萬人左右在線)


        中級篇:(分而治之)

        此時我們在單機優化上已經算是達到極限,接下來就要集群來顯示作用了。

        數據庫: 數據庫總是在整個環節中是吞吐能力最弱的,最常見的方法就是sharding。
        sharding可以按多種方法來分,沒有定式,看情況。可以按用戶ID區段分,按讀寫分等等,可用參考軟件:mysql proxy(工作原理類似lvs)

        緩存:memcache一般采用的是構建memcache pool,將緩存分散到多臺memcache節點上,如何將緩存數據均勻分散在各節點,一般采用將各節點順序編號,然后hash取余對應到各個節點上去。這樣可以做到比較均勻的分散,但是有一個致命點就是,如果節點數增加或減少,將會帶來幾乎80%的數據遷移,解決方案我們在高級篇再提。

        WEB服務器篇: web服務器集群的建設,最常見的就是lvs方式(memcache pool同樣可以如此組建),lvs的核心就是調度節點,調度節點負責將流量通過算法分散到各個節點上,因調度所耗資源很少,所以可以產生很高的吞吐率,后臺節點數量可以任意增刪,但此法弊病就是如果調度節點掛了,則整個集群都掛了,解決方案我們在高級篇提。

        方法2:參見 HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer


        高級篇:(高可用性+高可擴展性的集群)

        單點調度故障解決:
        集群的好處顯而易見,但是有一個弊端就是單節點進行調度,如果節點出現故障,則整個集群全部都無法服務,對此的解決方案,我們使用keepalived來解決。Keepalived for Linux
        keepalived是基于VRRP協議(VRRP協議介紹)的,請一定先了解VRRP協議后再進行配置。
        keepalived可以把多臺設備虛擬出一個IP,并自動在故障節點與備用節點之間實現failover切換。這樣我們配置兩臺貨多臺lvs調度節點,然后配置好keepalived就可以做到lvs調度節點出現故障后,自動切換到備用調度節點。(同樣適用于mysql)

        memcache集群擴展解決:

        memcache因為我們一般采用的都是hash后除以節點數取余,然后分配到對應節點上,如果節點數出現變化,以前的緩存數據將基本都不能命中。
        解決方法:consistent hashing 簡介:一致性哈希

        consistent hashing大概的思路就是,把hash后的值保證在 0 ~ (2^32)-1 的數值上,然后把這一連串數字對應映射到一個想象的圓上。

        把要存儲的各個值hash后,放到圓上

        然后把cache節點也用同樣的hash方法,映射到圓上,然后每個剛才hash過的value順時針尋找離自己最近的節點,這個節點就是存儲它的節點。

        為了提高存儲的平衡性,算法還可以加入虛擬節點的概念,即每個實際cache節點,會在圓上對應N個虛擬的節點,這樣可以提高算法的命中率,更加平衡。consistent hashing原理:Consistent hashing and random trees完結。


        針對不同的項目情況,輸煤這邊會根據實際情況進行針對性的采用不同的服務器架構,以確保網站上線后的穩定運行。


        相關新聞

        來電咨詢 4146.com牛彩彩票
        <strike id="g1ugu"></strike>
          <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

        1. <font id="g1ugu"></font>
          <b id="g1ugu"></b>

        2. 
          

            <tt id="g1ugu"></tt>

              <rp id="g1ugu"></rp>
              <strike id="g1ugu"></strike>
                <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

              1. <font id="g1ugu"></font>
                <b id="g1ugu"></b>

              2. 
                

                  <tt id="g1ugu"></tt>

                    <rp id="g1ugu"></rp>