2

我想保留一些應用程序配置條目作爲數據存儲區中的實體。現在,當我從數據存儲查看器(開發環境)或Google Cloud Platform數據存儲用戶界面(生產環境)更新這些條目時,應用程序不會看到新值。這是因爲ndb緩存實體。如何刷新Google App Engine數據存儲區中保存的配置條目?

我的(相當開放的)問題是:在數據存儲中保存配置條目,從Google的用戶界面更新配置條目以及爲應用程序提供新值的技術是什麼?

我已經想到以下的:

  1. ndb.Model子類定義了配置條目設置一個合理_memcache_timeout - 但內存緩存的用法是在這種情況下,次優的(執行不必要的數據存儲區中讀取)。

  2. 將緩存設置保持爲最大值,但在應用程序的管理區域中執行flush操作以單獨刷新實體。這很棘手,因爲您無法確定實體的實際緩存鍵。但通常應該是_memcache_prefix + key.urlsafe(),其中_memcache_prefixndb.context module中定義。

  3. 更新應用程序管理區域中的所有配置條目,但不使用Google的數據存儲用戶界面 - 這需要額外的努力。

+1

在生產環境和開發環境控制檯上,您都可以進入memcache查看器並在更新值後手動刷新緩存。您的應用不應再看到較舊的值。這會刷新所有條目,但影響應該很小 - 無論如何,您的應用程序應該準備好處理消失的memcache值。 –

+1

根據您的應用程序使用這些配置的方式,您可能還需要重新啓動已在運行的應用程序實例。 –

+0

@DanCornilescu我也將緩存用於其他目的(不僅用於存儲配置條目)。在我的情況下,刷新整個緩存對性能的影響是不可忽視的。但是在其他情況下你的想法聽起來很棒。 –

回答

2

選項1 - 大多數工作

實現在App Engine中使用NDB客戶端庫自己的管理模塊。如果您通過自己的應用對實體進行更改,那麼它自然會爲您編寫正確的內存緩存密鑰。

選項2 - 用於更新交易成本延遲

正如你已經暗示,減少最大緩存年齡模型。例如,在大多數情況下,在變更生效之前允許1小時的時間並不是不合理的。

選擇3 - 最不工作,而是通過雲端控制檯大規模

刷新整個緩存一個壞主意的內存緩存。

警告:如果你在大規模運行,這是一個壞主意,因爲它可能會導致請求的巨大高峯。例如,如果您在90%的緩存命中率之後以100萬次讀取/秒的速度運行數據存儲,則可以在刷新後立即達到1000萬次讀取/秒。

+2

選項1不必很複雜 - 你需要的只是一個簡單的(受保護的)處理程序,它觸發清理必要的Memcache條目(例如「/ admin/update_config」) –

+1

@AndreiVolgin - 事實上它並沒有,但它仍在設置增加更多的代碼/服務。最終,它可以作爲爲應用程序構建更多功能管理體驗的跳板點,例如定時更新,回滾,日誌記錄,更改驗證等。 –

相關問題