「全棧之路」Web前端開發的後端指南

  • 用戶通過表單上傳的各類文件。
  • 雲服務供應商不是將這些存儲在數據庫中,而是提供專用服務來存儲這些服務,例如 AWSSimpleStorageService(S3), Azure, GoogleCloudStorage和阿里雲 OSS等。

    這樣做的好處是雲供應商可以安全地存儲文件,並可以為其製作冗餘副本,以最大限度地降低數據丟失的風險。

    6.1 關於 Blob 存儲:

    Blob 存儲用於:

    • 直接向瀏覽器提供圖像或文檔。
    • 存儲文件以供分佈式訪問。
    • 對視頻和音頻進行流式處理。
    • 向日志文件進行寫入。
    • 存儲用於備份和還原、災難恢復及存檔的數據。
    • 存儲數據以供本地或 Azure 託管服務執行分析

    7、內容分發網絡(CDN)

    Blob /文件存儲服務允許客戶端通過 HTTP端點訪問文件。例如,您的Web應用程序的HTML標記可以簡單地鏈接到AWS S3中存儲的圖像和CSS文件的URL。

    傳統網絡訪問

    「全棧之路」Web前端開發的後端指南

    但是,假設我的用戶位於中國,我的S3存儲位於美國西部 - 數據傳輸距離數千英里,因此我的用戶會看到延遲。

    CDN是什麼?使用CDN有什麼優勢?

    • CDN是雲供應商提供的服務,它們在全球範圍內分佈有“邊緣服務器”。
    • 這些邊緣服務器從“原點”(例如,blob /文件存儲位置)獲取文件的副本。你的前端Web應用程序將指向 其CDN URL,而不是指向靜態資產的Blob存儲URL。
    • 現在,客戶端和“邊緣”之間的距離遠不是幾千英里的往返,而是更少,因此文件的獲取速度更快。

    使用了CDN的網站訪問:

    「全棧之路」Web前端開發的後端指南

    7.1 CDN工作流

    「全棧之路」Web前端開發的後端指南

    通過權威DNS服務器來實現最優節點的選擇,通過緩存來減少源站的壓力。

    8、緩存服務:CachingService

    雖然 CDN是靜態文件的一種緩存形式,但 Web應用程序可能需要臨時緩存動態數據。

    例如,假設存在一個數據庫查詢,該查詢對昨天的數據執行計算,其結果每天經常被成千上萬的用戶訪問。每次用戶請求此數據時聯繫數據庫就沒有任何意義。

    對此的解決方案是使用高速緩存服務在第一個用戶請求之後將結果存儲一段時間。通過緩存將更快地提供對該數據的後續請求。

    緩存服務本質上是一種特殊類型的數據庫。 緩存採用鍵值存儲的形式,其中鍵是應用程序代碼用於查詢數據的字符串(例如DailySiteStats_2018-10-17),值是緩存的實際數據。緩存的數據通常完全保存在內存中,這使得從緩存中檢索數據的速度非常快。

    常見的緩存服務是 Redis和 Memcached。AWS通過其 Elasticache服務提供這兩者的託管版本。

    8.1 Redis和 Memcached對比

    Redis和 Memcached是都是主流的開源內存數據存儲。雖然它們既易於使用又提供高性能,但在選擇引擎時需要考慮重要的差異。Memcached是為簡單而設計的,而 Redis提供了豐富的功能,使其能夠廣泛用於各種用例。


    MemcachedRedis亞毫秒級延遲是是開發人員易用性是是數據分區是是多語言支持是是高級數據結構-是多線程架構是-快照-是複製-是發佈/訂閱-是Lua腳本-是地理空間支持-是

    亞毫秒級延遲:

    Redis和 Memcached都支持亞毫秒的響應時間。通過將數據存儲在內存中,它們可以比基於磁盤的數據庫更快地讀取數據。

    開發人員易用性:

    Redis和 Memcached在語法上都很容易使用,並且需要最少量的代碼才能集成到您的應用程序中。

    數據分區:

    Redis和Memcached`都允許您在多個節點之間分發數據。這允許您在需求增長時向外擴展以更好地處理更多數據。

    支持廣泛的編程語言:

    Redis和 Memcached都有許多面向開發人員的開源客戶端。支持的語言包括 Java,Python,PHP,C,C++,C#,JavaScript,Node.js,Ruby,Go等等。

    高級數據結構:

    除了字符串, Redis還支持列表,集合,有序集,哈希,位數組等。應用程序可以使用這些更高級的數據結構來支持各種用例。例如,你可以使用Redis排序集輕鬆實現遊戲排行榜,該排行榜保持按其排名排序的玩家列表。

    多線程架構

    由於 Memcached是多線程的,因此它可以使用多個處理核心。這意味著您可以通過擴展計算容量來處理更多操作。

    快照:

    使用 Redis,您可以使用即時快照將數據保存在磁盤上,該快照可用於存檔或恢復。

    複製:

    Redis允許您創建 Redis主數據庫的多個副本。這允許您擴展數據庫讀取並具有高可用性集群。

    發佈/訂閱:

    Redis支持使用模式匹配的 Pub/Sub消息傳遞,您可以將其用於高性能聊天室,實時評論流,社交媒體源和服務器互通。

    Lua腳本:

    Redis允許您執行事務性 Lua腳本。腳本可以幫助您提高性能並簡化應用程序。

    地理空間支持:

    Redis具有專門用於大規模處理實時地理空間數據的命令。您可以執行諸如查找兩個元素(例如人或地點)之間的距離以及查找點的給定距離內的所有元素之類的操作。

    9、消息隊列:Message queue

    「全棧之路」Web前端開發的後端指南

    適用於批處理任務和分離應用程序的異步消息收發

    有時,你程序需要執行的任務與響應用戶請求沒有直接關係。

    例如,假設用戶上傳了需要編碼和水印的視頻。但這是一項長期運行的任務,因此讓用戶在完成時等待是沒有意義的。更好的方法是異步執行此操作。您的網絡應用程序代碼會在隊列中創建一條作業消息,並通知您的用戶,當水印視頻準備就緒時,他們將收到一封電子郵件(消息)。

    然後,你將擁有一個可以執行以下操作的工作任務流:

    1. 從隊列中讀取消息。
    2. 開始處理視頻。
    3. 完成後,保存視頻的編碼副本。
    4. 向用戶發送通知電子郵件(消息)。
    5. 從隊列中刪除消息。

    這裡有2個架構組件:

    您可以通過以下幾種方式實現 worker任務:

    • 調度 CRON作業以觸發應用程序服務器上安裝的指定代碼,以便按特定計劃從隊列中讀取。
    • 將消息添加到隊列時,使用 FaaS平臺調用工作器代碼。

    9.1 Message queue 簡介

    消息隊列是一種異步的服務間通信方式,適用於無服務器和微服務架構。消息在被處理和刪除之前一直存儲在隊列上。每條消息僅可被一位用戶處理一次。消息隊列可被用於分離重量級處理、緩衝或批處理工作以及緩解高峰期工作負載。

    現在常用的MQ組件有 activeMQ、 rabbitMQ、 rocketMQ、 zeroMQ 還有近年來火熱的 kafka,從某些場景來說也是MQ,當然kafka的功能更加強大,雖然不同的MQ都有自己的特點和優勢,但是,不管是哪種MQ,都有MQ本身自帶的一些特點。

    9.2 MQ主要特性

    特性說明推送或拉取傳送拉取是指不斷查詢隊列以獲取新消息。推送是指系統在有可用消息時通知用戶 (也稱為發佈/訂閱消息收發)。您還可以使用長輪詢讓拉取等待指定的時間,以便新消息在完成之前到達。定時或延遲傳送支持為消息設置特定的傳送時間。如果需要為所有消息設置相同延遲,可以設置一個延遲隊列。至少一次傳送消息隊列可以存儲多個消息副本以實現冗餘和高可用性,並在發生通信故障或錯誤的情況下重新發送消息,以確保它們至少經過一次傳送。確切一次傳送在不容許重複的情況下,FIFO (先進先出) 消息隊列會通過自動篩選重複來確保每個消息均精確地傳輸了一次 (且只有一次)。FIFO (先進先出) 隊列在這些隊列中,首先接受處理的是最早的 (或第一個) 條目,有時稱為“隊首”。消息優先級通常情況下,您可以為消息分配優先級,以確定要在隊列中添加該消息的位置,從而確保優先級較高的消息位於隊列前端並得到優先處理。

    9.3 MQ應用示例

    來源:MQ(消息隊列)常見的應用場景解析

    我們的實際場景大概是一個基於微服務架構的電商系統,分為用戶微服務、商品微服務、訂單微服務、促銷微服務等。

    基於微服務模式開發的系統,MQ的使用場景更多。這裡我們就列舉一下常見的應用示例。

    1、註冊後的初始化

    註冊後我們可能需要做很多初始化的操作,如:

    • 調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關係系統等。
    • 那麼這時候我們將這些操作去監聽MQ,當用戶註冊成功過後,通過MQ通知其他業務進行操作。確保註冊用戶的性能。

    2、後臺發佈商品

    後臺發佈商品的時候:

    • 商品數據需要從數據庫中轉換成搜索引擎數據(基於 elasticsearch)
    • 那麼我們應該將商品寫入數據庫後,再寫入到 MQ,然後通過監聽 MQ來生成 elasticsearch對應的數據。

    3、支付超時取消

    用戶下單後,24小時未支付,需要取消訂單。

    • 以前我們可能是定時任務循環查詢,然後取消訂單。
    • 實際上,我更推薦類似延遲MQ的方式,避免了很多無效的數據庫查詢,將一個MQ設置為24小時後才讓消費者消費掉,這樣很大程度上能減輕服務器壓力。

    4、支付完成後通知

    • 支付完成後,需要及時的通知子系統(進銷存系統發貨,用戶服務積分,發送短信)進行下一步操作。
    • 但是,支付回調我們都是需要保證高性能的,所以,應該直接修改數據庫狀態,存入MQ,讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。


    分享到:


    相關文章: