規劃可伸縮Web應用程序的開發

Question

我們已經創建了一個產品，可能會爲駐留在我們的服務器上的數據文件生成大量的請求。目前我們有一個共享託管服務器，它運行一個PHP腳本來查詢數據庫併爲每個用戶請求生成數據文件。這個效率並不高，迄今爲止還沒有成爲問題，但我們希望轉向更加可擴展的系統，以便我們能夠尋找EC2。我們主要關注的是能夠在發生數據流量時處理大量流量，併爲下載數據文件的用戶提供低延遲。

我在這是怎麼去工作還沒有不知道100％，但這樣的想法：

我們使用的EC2實例來承載我們的管理面板，並生成被服務的文件應用用戶。當任何管理員進行影響這些數據文件（由用戶下載）的更改時，我們會使用CloudFront複製到S3。這裏的想法是獲取數據緩存並在S3上等待，這樣我們就可以保持較低的計算時間，並且可以使用CloudFront爲所有請求文件的用戶獲得低延遲。

我仍然在學習這個系統，並想知道是否有人對這個想法有什麼反饋或對這一切如何工作有所瞭解。我也很好奇Cassandra這樣的項目的目的。我的理解是，簡單地將我們的應用程序放在EC2服務器上，可以根據服務器的性質進行擴展。 Cassandra是否只是在保持低資源使用率，還是有理由使用這樣的系統，即使在EC2上？

CloudFront的：http://aws.amazon.com/cloudfront/ EC2：http://aws.amazon.com/cloudfront/ 卡桑德拉：http://cassandra.apache.org/

Answer 1

Cassandra是一個非關係型數據庫引擎，如果這是你需要什麼，你應該先評估亞馬遜的SimpleDB：非關係數據庫引擎建立在S3的頂部。

如果文件只需要根據時間（每天，每小時......）更新，那麼這似乎是一個合理的解決方案。但是您可以考慮在2個EC2映像前面放置一個負載均衡器，每個映像都運行一份應用程序副本。如果一個實例失敗，這將使後面的擴展更容易，更安全。

你應該閱讀一些其他服務：

http://aws.amazon.com/elasticloadbalancing/ - 亞馬遜負載均衡解決方案。

http://aws.amazon.com/sqs/ - 用於在DA（分佈式體系結構）中的系統之間傳遞消息。例如，如果您希望創建數據文件的系統與承載該網站的系統不同。

http://aws.amazon.com/autoscaling/ - 允許您根據流量調整在線實例的數量

確保與EC2良好的備份過程中，快照您的操作系統驅動往往並放置任何揮發性數據（如數據庫文件）在EBS塊。 EC2不會經常失敗，但是當它不能訪問硬件時，如果你有最新的快照，你可以在線啓動一個新的實例。

Answer 2

取決於數據集，Cassandra還可以顯着提高查詢的響應時間。

有一個在NoSQL的解決方案中使用的數據結構的一個很好的說明，可以幫助你瞭解是否是一個合適的解決方案，以幫助：

WTF is a Super Column