2015-05-21 24 views
1

我們爲社區管理製作了一個SAAS平臺。我們被要求爲每個社區提供定製的體驗,並最終終止社區管理者想要修改視圖/元素位置/ css/js。經過大量研究,我們決定使用Shopify#liquidmarkup http://liquidmarkup.org/。什麼是存儲這些模板的理想方式?與Shopify相似的模板管理 - 建築推薦

這是我們目前的模型架構

社區的has_many用戶

,因此社區將有自己的軌道「佈局」 /「諧音」 /「liquidtemplates」。我們計劃在其佈局這種方式存儲在當前文件系統

Rails.root>模板> community_uuid> community_specific_template_files

但是作爲我們社區擴展,我們將不得不太多的「模板」文件夾越積越多。即使它們在MAINAPP git倉庫中被忽略,在具有多個獨角獸節點的應用程序服務器上,這些模板在任何給定的時間點都必須適用於任何獨角獸服務器。隨着我們的社區基礎在我們的應用服務器上的增加,這將成倍增加文件系統空間消耗。

我們有3個選項目前

  1. 存儲這些文件系統中,所有應用程序服務器上部署/更新模板 - 數據庫IO操作
  2. 存儲模板和緩存的模板查詢
  3. 存儲模板REDIS作爲HASH結構並進行相應檢索。

想知道您的想法嗎?

感謝 維韋克Sampara

回答

0
  1. 感覺很不穩定。必須處理:

    • 當同步過程開始時,節點正在離開。
    • 節點在更新過程中停止運行,它將被「半同步」,並且在備份時必須重新同步。
    • 當添加新節點時,必須有單獨的進程觸發同步過程。

你打算實現這個你自己或不麒麟/紅寶石有一些內置的功能,利用這個照顧?

  1. 感覺就像一個更明智的解決方案。但是你總是希望將數據庫查詢保持在最低限度。

  2. 這是我個人比較喜歡的解決方案。擁有專門的Redis實例,就像模板存儲庫一樣。

+0

感謝您輸入@Vic。你能解釋一下「節點離開」和「半同步」嗎? –

+0

我對第一種選擇的擔憂是籠統的。擔心在多服務器環境中使用同步文件系統。在同步過程中很難讓所有服務器/實例/節點都可用。以及在同步過程中如何處理服務器/實例/節點出現故障並重啓(針對不相關問題)的情況 – xCander