Google云永久磁碟上的 SQLite
Google 的永久磁碟是否具有 SQLite 所需的並發訪問（許多虛擬機從單個永久磁碟訪問數據）的適當讀/寫鎖？
SQLite 使用讀/寫鎖來控制對數據庫的訪問。
$$ … $$但請注意：如果數據庫文件保存在 NFS 文件系統上，此鎖定機制可能無法正常工作。這是因為
fcntl()在許多 NFS 實現中文件鎖定被破壞。如果多個程序可能嘗試同時訪問該文件，則應避免將 SQLite 數據庫文件放在 NFS 上。我真的很想知道Google的持久性磁碟是否正確鎖定寫入。我研究了 AWS 的 EFS，它沒有適當的鎖定係統來支持 SQLite。
更新（2019 年 8 月 30 日）
Canonical 的 Dqlite提供了一個分佈式的、高可用性的 SQLite，它可能適合這個案例。它在 Apache 2.0 下是開源的，用 C 語言編寫，因此它可以作為 SQLite 的替代品。另請參閱有關 HN 的討論以獲取更多上下文。
較早的答案
從您的評論看來，MySQL 和 Google Cloud SQL 不是一個選項，因為您的架構需要使用單個 SQLite 文件。
此外，根據 SQLite 文件，由於鎖定問題，NFS 不是一個選項。
這裡有一些其他選項需要考慮。
替代分佈式文件系統
除了 NFS 之外，您可能還需要評估許多其他分佈式文件系統，例如Ceph、GlusterFS、OrangeFS、ZFS等。除了您自己的研究之外，請考慮聯繫 SQLite 使用者或開發人員以獲得指導和過去經驗。
使用 NFS，但每次執行單個寫入器
NFS 問題似乎與鎖定有關，僅在寫入時才需要：只要您可以保證一次只有一個程序鎖定數據庫以進行寫入，其他幾個程序可以打開它進行讀取，所以這應該是好的（請確認/確認是這種情況）。
因此，只要有一種外部方法來確保單個寫入器，您就可以使用 NFS。考慮使用分佈式鎖服務，例如Apache ZooKeeper、HashiCorp Consul或CoreOS etcd來提供鎖服務，您可以將 SQLite 儲存在 NFS 上。
當然，這依賴於每個直接訪問 SQLite 數據庫的程序在不再需要寫入時正確關閉它，因此很難強制執行正確性，因為它依賴於所有軟體的正確性和協作性。
輕量級 RPC 伺服器
您提到您的架構（目前無法更改）依賴於 SQLite，但如果可以讓他們呼叫 RPC 服務而不是直接打開文件，則可以讓該伺服器成為打開 SQLite 數據庫的唯一點並避免多個並髮使用者的鎖定問題。但是，這意味著您將不得不更改所有客戶端程式碼以呼叫 RPC 服務，而不是直接打開 SQLite 數據庫，這是一項非常重要的工作。
結論
這些選項都不是微不足道的，需要工作。原因是：
與許多其他數據庫管理系統相比，SQLite 不是客戶端-伺服器數據庫引擎。相反，它嵌入到最終程序中。
因此，它不是多個訪問器的正確解決方案，因此需要大量變通方法。
從長遠來看，如果您必須進行重大更改才能繼續維護此系統，您可能需要考慮遷移到 MySQL 或 Google Cloud SQL，而不是投資於變通方法以繼續使用SQLite。