我也要談談大型網站架構之系列（4）——分佈式中的異步通訊

我也要談談大型網站架構之系列（4）——分佈式中的異步通訊

 

　　咱們知道在面向對象編程中，總會想着各類辦法來實現代碼的解耦，從而讓項目中的各類人員面對本身熟悉的業務進行開發，

作到術業有專攻，好比你們很是熟悉的三層架構，MVC，MVP以及MVVM模式，讓前端設計專一於html的製做，讓後端開發人員

更加專一於業務邏輯的編寫，能夠看到，咱們這麼作的目的就是想最大程度的作到系統的可擴展和可維護性，那麼咱們的大型網站

是否是也要遵照這種模式呢？

 

一：分層和分割

1：分層

    對於分層，咱們可能很是熟知了，數據訪問層，業務邏輯層，緩存層，應用層，層層專一於本身的業務，而後根據須要創建起

 各自的集羣，各自分離部署，而從達到系統的擴展性和維護性。

 

2：分割

    若是說前面是橫向切割，那分割就是縱向切割，咱們能夠把網站的總體業務切分紅不少的小業務，好比博客園的導航欄，咱們都

能夠認爲是一個獨立的網站，配上各自的二級域名，創建各自的集羣來實現系統的擴展性，固然這個粒度可大可小。

若是說這些子網站不存在相互調用，那麼咱們新增模塊或者修改模塊基本上都不會對其餘模塊形成影響，這也是咱們作擴展性的終極

目標，如今既然都作到解耦了，下面的目標就是作如何通訊了，通訊能夠分爲「同步」和「異步」，這篇主要是討論下異步操做，在分佈式

系統中作到"異步操做「，固然少不了強大的消息隊列。

 

二：消息隊列

    在分佈式的系統中使用消息隊列後，咱們的生產者只管向消息隊列中甩完數據後當即返回，而不論是哪一個消費者來消費，能夠看到

其實消息隊列有以下三個優勢。

 

1.  加快網站的相應速度

　   這個剛纔也說了，應用層直接把消息給消息隊列而後直接返回調用端，這樣就避免了處理複雜的業務邏輯而後同步的插入到數據

  庫後再返回形成的響應延遲，在不少網站上用戶提交訂單就是這麼處理的，應用層生成一個訂單號以後，將訂單丟給消息隊列，而後

  直接到訂單成功頁面，此時後端消費者對訂單尚未處理完畢，由於後面會有比較多的數據操做，好比減庫存，數據庫同步等等，而

  用戶若是想要看到訂單詳情，須要點擊「訂單號」才能進入到訂單詳情頁，這種處理也是由於消息隊列的非及時性，因此須要獲得網站

  設計方改進和支持。

 

2. 提供系統的可用性

    既然是異步操做，就形成了生產者不知道消費者的存在，而反過來消費者不知道生產者的存在，若是消費者掛了就不會影響到生產者，

  生產者還會照常無誤的向消息隊列甩消息，當消費者恢復正常後就會繼續消費消息隊列，系統的表現可能就是email或者短信延遲收到，

  不會對系統形成太大的影響。

 

3. 併發削峯

   既然是大型網站就免不了高併發的讀寫操做，很典型的一個例子就是電商中的秒殺，這種高併發的寫操做，若是一會兒都涌入到數據庫

裏面去了，會致使數據庫的壓力很是大，從而致使客戶端的訪問延遲，就是不掛也容易形成數據庫的死鎖從而形成不少靈異事件，遇到這

種一擁而入的狀況，咱們就必須進行線性化操做，在代碼層面上咱們能夠用lock機制來串行化，在分佈式中咱們用「消息隊列」來串行化，

並且還能夠經過邏輯操做來對消息隊列進行動態的防洪，控洪。

 

 在消息隊列的選擇上，微軟有本身的MSMQ，可是在大型網站中，咱們的消息隊列一樣須要集羣，而且但願能跑在內存中，而且支持序列

化硬盤，同時在「伸縮性」和「可靠性」上要有好的做爲，因此推薦你們用用開源的RabbitMQ，網址：http://www.rabbitmq.com/  不過很

多公司都有本身開發的消息隊列，好比攜程的CMessage，淘寶的MetaQ。