互聯網架構的演變：
1 最初是前端一個web 加一個DB的結構
這種結構，web容易掛掉，業務就會終止，由於高可用的需求，出現了下面這樣的架構
2 加了一個web，兩個web之間是主備的關系，一個掛了，另一個來代替，用來解決高可用問題
3 之后發現這樣的架構支持的訪問量不夠了，前端撐不住那么大的訪問量，因為前端的訪問量和DB的落庫有大概是10比1的比例，前端訪問10個，會有1個能夠落庫，所以隨着訪問量的增加，前端先扛不住了，這個時候主、備結構已經不能解決高可用的問題，所以在web前面加了一個ngx，作為負載均衡進行訪問的轉發，這個時候，web和web之間的主備關系就不存在了，在ngx進行轉發的時候會有一個session保持的操作，再后來就出現無狀態的概念，在兩個web之間進行輪詢，給誰都行
4當無狀態的概念出來以后，web這一層就可以進行多次的橫向擴展，這是第一次質的飛越
后來人們覺得一個ngx也會出問題，就設計了主、備結構的ngx
5 后來主、備ngx結構也不滿足需求了，就在ngx前面加了一個lvs，lvs負責把請求轉發給nginx
這時nginx就解放出來了，不是主、備結構了，而是作為一個層級的結構，可以進行無限橫向擴展；
lvs這里是一個單點，它可以被設計成主、備的結構，一台掛了，另一台接管，但是不能橫向擴展。
注意：lvs不能直接做負載集群，不能說一台不夠了，再來一台，做不了負載集群，但是如果負載不夠怎么辦，它只能抗10到20萬的訪問量，怎么擴呢？可以一個ip放在一台lvs上，再來一個ip時放到另外一個lvs上邊，用這種方式把它進行擴展；
然后lvs本身的高可用怎么做呢，它做不了高負載，沒法擴展它的吞吐量，但是高可用是可以做的，有主、備的結構，一個掛了，另一個接管，就可以了，實際上公司里邊的做法，可以做兩台lvs互為主、備，4個ip在一邊，4個ip在另一邊，兩台共同提供業務，就做到了高負載，當一台出故障的時候，這個8個ip就可以集中到另外一台lvs上。
在高可用的集群里邊，所有的東西都是負載均衡的，但是如果這不是一個分布式架構，那么在最上層那一點一定會存在一個單點的，就是入口永遠會存在一個單點，這個單點一定不能影響它的性能，比如lvs；
lvs分三種轉發模式：net模式，路由模式和隧道模式：
net模式是所有的流量都過它自己，它來做轉發，就是你后端ngx所有接來的請求都是從lvs轉過來的，這種模式，lvs的壓力是最大的，它要承載所有的流量，如果lvs這台機器流量不夠的話，它是會被打垮的，所以說一般互聯網公司都會用第二種模式：路由模式；
路由模式就涉及到回環ip（127.0.0.1），路由模式的時候，它的回環地址里會配后端ngx的地址，然后lvs和ngx就會有回環地址的通訊，干啥用呢？就是網絡上的包從哪兒來的，還從哪兒回，遠程的ie瀏覽器在訪問這個網站的時候，這個包會發給lvs（總入口），lvs通過路由模式把這個包扔給ngx，ngx再找后端服務器，后端服務器響應以后把這個包回給ngx，這個時候ngx和客戶的瀏覽器直接發生通選，不再進過lvs，為什么說路由模式lvs的壓力小呢？因為它接收請求包以后，直接分發給后端的ngx，由ngx和客戶產生直接的數據關系，只有在頭一個包（首包），是過lvs的，其他包都 不過lvs，這時候lvs的壓力和負載會特別小，然后這個這時候會用到回環地址，因為網絡的包從哪兒來就要從哪兒回，但是ngx回出去的包不再是lvs的ip了，這個時候瀏覽器會把它的包給扔掉的，因為ip已經不是lvs的ip了，怎么辦？這個時候就用到回環地址，ngx回環地址里邊配lvs的地址（lvs在回環地址里邊也配了ngx的地址），ngx在把這個包發出去的時候，做一次偽裝，把自己偽裝成lvs的地址，這樣客戶端就會接受它的包，就會和它通訊，這個時候，lvs只在首包的時候做了一下轉發，指定了ngx，所以這個架構里邊的核心，就在於lvs用了路由模式，這一套架構中lvs是由中國的一位博士寫的，他寫這套lvs在全球都在有，可以代替F5（負載均衡的硬件設備）和array，造價方面，單台機器，轉發能力在5萬的，最少要20萬元，是四層轉發，現在應該可以7層轉發；
lvs的隧道模式：隧道模式和路由模式類似，區別在於路由模式要求lvs、ngx內網地址要在同一層上，同一個子網里邊，但是隧道模式不需要，隧道模式可以跨網，甚至跨廣域網去轉發，但是垮了3層就不是很穩定，所以在公司里邊一般都是用路由模式，跨機房的時候才用到隧道模式，隧道模式和路由模式的工作方式基本是類似的，比較接近，但是更復雜一點，因為要跨廣域網，它的ip配置更負載一點。
至此，lvs作為第一層就不再變化了，第一層始終是主、備的結構，lvs的負載特別小，所有的負載到lvs直接就傳給ngx，ngx再往下分發
這個時候，轉發層活了，web層活了，壓力就全到DB了，DB就開始演變
6 最初DB演變出來master和slave這樣的架構
所有的web既連master也連slave，連slave只進行讀操作，連master只進行寫操作，這樣把讀和寫進行分離，這時速度就有一個質的提升
然后如果一個slave不夠的時候，再加一個slave，就解決了這個架構對數據庫讀的壓力，這個時候的網站的並發訪問量，理論上可以到萬級了
但是有一個問題，master是一個單點，如果它掛了，整個系統就都掛了，
這個時候要考慮的不只是吞吐量，也要看性能、可靠性，前端已經沒有問題了，但是數據庫這里有一個單點的問題，后來人們就開始想辦法，怎么能保證DB不會出問題呢，后來人們就把DB這塊給重構了
7 在web下面加了一層proxy結構，可以說是轉發，也可以說是中間件，這一層結構可以做成集群，這個集群是給數據庫做切片的，做成類似於分布式的功能，這一層下來給DB做切片轉發，這樣DB這一層的庫之間就不再有主、從的關系了，都認為是主，掛掉一個，其他的還能正常工作，既做高可用，又做高性能，保證某一台掛掉的時候，另外兩台可以做到高可用，如果負載不夠的時候，還可以添加
這個4層結構，可以在很高的性能下，很高的可靠性下做到萬級甚至十萬級的並發
這是5年前開始流行的架構，現在的使用率也很高，在對可靠性和性能方面要求不是很高的系統中可以很穩定的應用，但它存在一個問題，就是訪問量再大的時候，落庫的時候會有一個瓶頸，因為DB不只是做插入和查詢，還要做分析和關聯，速度會很慢，那怎么辦呢？
8 人們開始在DB層的上邊加兩個緩存層（讀和寫），讀緩存層是用redis，它也是集群，在業務層下邊，DB層的上邊，redis從數據庫里抽數據，到自己的緩存中，然后提供給業務，只要被緩存命中的數據，讀的是特別快的，redis把DB中的熱數據提取到緩存層，直接給業務層來用。
寫的話用的是MQ，來實現寫的業務，一讀一寫合起來就大大的提升了並發的處理。
這個架構中的lvs負責四層轉發，nginx做7層轉發，4層和7層對應的是osi模型的第四層和第七層，4層轉發或7層轉發就是對后台服務器進行負載均衡時，依據四層的信息或七層的信息來決定怎么轉發流量；
四層就是通過三層的IP地址（虛擬IP），加上四層的端口號，來決定怎樣轉發流量，七層轉發是在四層的基礎上，再考慮應用層的特征，比如七層的url、瀏覽器類別、語言來決定是否要進行負載均衡；
轉發下來后，web做接收，讀的時候，熱數據從DB里抽到redis里讀，就不會因為DB的計算卡着web了，在像雙十一這種秒殺的業務，可以把數據提前放到redis里，供web來讀，寫數據時可以快速的寫給mq，之后web就不用管了，用戶就可以接着做下一步了，然后mq往DB里一點一點的落庫，就是說通過緩存層把高速的web和低速的DB給隔離開，這樣給前邊的用戶體驗就會特別好，
比如雙十一之前加購物車，都是提前被寫好了放到redis里邊，然后下訂單都是通過mq來落庫，你這邊一點刷一下就過去了，你覺得過去了，實際上都在mq里往DB里處理，不可能一下子就落到DB里，目前還沒有一家公司能夠做到，就算是分布式數據庫也不行，分布式數據庫只能解決中型的業務場景，解決不了巨型的業務場景，這是這兩年很典型的比較火的架構，但是它比不上分布式數據庫，這種結構即使很快，如果技術實力不夠也只能達到十萬級，如果要擴的話，只能是橫向的擴，一套一套的往上累加
9 出現了新型分布式數據庫以后，這個架構變得很簡單，很明晰，速度也很快
lvs，nginx，web這三層不變，下邊的緩存層，代理層都沒有了，只剩數據庫本身了，
這個DB目前可以撐住10萬甚至20萬（瞬間的並發寫），沒有理論上限，各種的復雜的計算在一秒內都可以完成，這就是分布式架構的架構之美，越來越簡潔
這個DB實際上是很復雜的
它的底層有自己的分布式存儲dfs結構，另外有控制節點，還有提供實際計算，運行sql的計算節點，這三部分是沒有中心（去中心），可擴展，對稱的（壞掉一台、加一台都沒問題），可以做到平行的擴展，做到無限制的可行性，也是分布式的目的所在。
他是怎么做到高速的呢？實際上就是分布式存儲和計算的理念，如果有中心的話，需求下來一定是發給一個中心節點上，這個中心就會成為瓶頸，無中心的話，需求下來拋給控制節點，控制節點也沒有中心，控制節點接到請求以后告訴它你去哪個計算節點上去，然后計算節點去計算的時候，如果這時所有的數據放到一個dfs上邊（存儲DB），讀寫勢必會很慢，但是分布式存儲它是完全散開的（多個dfs），一個請求過來后是放到所有的計算節點上去算的，然后拿的時候是到所有的dfs上去拿的，這個速度會特別快，這個過程完全都是分布的，所以，這種新型的數據庫架構，就可以做到每秒10萬個查詢、寫入、update，也可以做分析，最快可以到每秒10萬
目前能做到千萬級別的並發的，有BAT，12360，其他就沒有了，這種架構覆蓋了當前互聯網基本上%95 甚至是99%的需求
數據在下發的時候，是多副本，掛掉一個機器數據是不會丟失的，它的數據是打散的，這樣讀的才會快，這個結構出來之后直接干掉緩存層，而且可以支持列式數據庫，目前的數據庫基本是行式的，列式數據庫對那種特別大的數據量支持的特別好