分佈式架構如何適用於動態和靜態內容

我有地圖平鋪在服務器不同的縮放級別創造了數千個映射磚。目前這在一個EC2實例上運行。我想堅持使用AWS。

當前的工作流程 - 一種用於瓷磚請求時，nginx的檢查，如果在高速緩存中存在瓷磚。如果該圖塊存在，它就會顯示出來。如果它不存在，它會將請求傳遞到一個貼圖創建腳本，該腳本既將新創建的貼圖提供給用戶，也將其緩存以供將來使用。當需要創建大量圖塊時，這開始陷入困境。

我想把它移到一個更分散的架構，其中從s3提供貼圖，如果它們不存在，它們會通過任意數量的芹菜任務呈現並創建貼圖並將其緩存到s3。

我inital的想法是建立ELB對於事物的瓷磚創建側和S3的小塊高速緩存。問題是如何檢查s3中是否存在拼貼，然後將其發送給ELB以進行渲染。我試着在ELB前面設置nginx，用try_files指令來檢查s3。儘管我可以在s3中代理磁貼，但這並不奏效。

我的問題是這樣的用例通常在AWS架構中如何管理？一個請求進入，對存儲位置進行檢查，如果它不存在，它將被創建並返回。

謝謝。

來源

2017-02-17 james

請求的圖塊已經被渲染和存儲的可能性是多少？看起來答案似乎對解決方案的可行性和效率有影響。 –

取決於縮放級別和空間位置。我們預先緩存低級別磁貼，因此z0-12被緩存並可用作靜態資產。當一個請求進入更高的縮放級別時，圖塊的創建將被啓動並存儲以供將來使用。這樣，經常訪問的區域就已經被緩存了。我現在遇到的問題是單個機器上的高速緩存會導致所有內容枯竭，並且無法提供靜態磁貼。 – james

我不是你已經配置nginx怎麼完全清楚，但它聽起來就像你需要配置它總是擊中一個動態的後端進程，可以檢查地圖瓦片還存在。如果該過程不存在，該過程將創建該塊，然後返回該塊。您可以緩存HTTP響應，以便進程不會停滯不前，檢查是否存在同一個tile一遍又一遍地存在。

如果我從頭開始一個項目，這樣我可能會創建一個數據庫來存儲每個地圖瓦片，也許DynamoDB的信息。該數據庫將包含每個創建的磁貼的記錄。當您收到請求時，您首先會執行數據庫查找以獲取磁貼的S3位置。如果您沒有獲取數據庫記錄，則創建該圖塊，將其上傳到s3，更新數據庫表格並返回圖塊。您可以在負載均衡器後面運行大量這些服務器，並隨着負載增加而增加更多。

我會使用Redis的（ElastiCache）來存放數據庫的查詢結果，以加快對同一區塊的後續請求。我還會在整個事物面前放置一個像CloudFront或CloudFlare這樣的CDN，並緩存起來，以便後續對同一個tile的請求甚至不會觸及您的服務器。

來源

2017-02-17 01:39:06

分佈式架構如何適用於動態和靜態內容

回答

相關問題