Google的永久磁盘是否具有SQLite所需的并发访问（许多虚拟机访问单个永久磁盘中的数据）的读写器锁？
根据SQLite FAQ ：
SQLite使用读写器锁来控制对数据库的访问。 […]但请小心：如果数据库文件保存在NFS文件系统上，则此locking机制可能无法正常工作。 这是因为在许多NFS实现上
fcntl()文件locking被破坏。 如果多个进程可能试图同时访问文件，则应避免将SQLite数据库文件放在NFS上。
我真的很想知道Google的持久性磁盘是否可以正确locking写入。 我研究AWS的EFS，并没有适当的locking系统来支持SQLite。
这听起来像您的意见，由于您的架构要求使用单个SQLite文件，MySQL和Google云SQL不是一个选项。
另外，根据SQLite文档，由于locking问题，NFS不是一个选项。
这里有一些其他的select要考虑。
除NFS以外，还有许多其他分布式文件系统可能需要评估，例如Ceph ， GlusterFS ， OrangeFS ， ZFS等。除了您自己的研究，还可以考虑向SQLite用户或开发人员寻求指导和过去经验。
NFS问题似乎是关于locking的，只有在写入时才需要locking：只要您能保证只有一个进程locking数据库以便一次写入，其他几个进程可以打开它进行读取，所以这应该是好（请确认/确认是这种情况）。
因此，只要有一个确保单写者的外部方法，你可以使用NFS。 考虑使用分布式locking服务，例如Apache ZooKeeper ， HashiCorp Consul或CoreOS etcd作为locking服务，并且可以将您的SQLite存储在NFS上。
这当然依赖于每个进程直接访问SQLite数据库，以便在不再需要写入时正确closures它，所以正确性很难执行，因为它依赖于所有的软件是正确的和合作的。
你提到你的体系结构（目前不能改变）依赖于SQLite，但是如果可以让它们调用一个RPC服务而不是直接打开这个文件，那么你可以让这个服务器成为打开SQLite数据库避免了多个并发用户的locking问题。 但是，这意味着您将不得不更改所有的客户端代码来调用RPC服务，而不是直接打开SQLite数据库，这不是一件容易的事情。
这些选项都不是微不足道的，需要工作。 原因是 ：
与许多其他数据库pipe理系统不同，SQLite不是客户端 – 服务器数据库引擎。 而是embedded到最终的程序中。
因此，这不是多个访问器的正确解决scheme，因此需要一堆解决方法。
从长远来看，如果您需要进行重大更改才能继续维护此系统，则可能需要考虑迁移到MySQL或Google Cloud SQL，而不是投入到变通方法中以继续使用SQLite的。
Re：使用SQLite进行多重访问： 你链接到的FAQ说：
（5）同一应用程序的多个应用程序或多个实例可以同时访问单个数据库文件吗？
多个进程可以同时打开同一个数据库。 多个进程可以同时做一个SELECT。 但是，只有一个进程可以随时对数据库进行更改。
这意味着您不应该使用SQLite作为通用数据库，它可以用作单个作者的embedded式数据库，尽pipe它也可以支持多个读者。
回复：永久磁盘：看到我的答案堆栈溢出相关的问题; 简言之，Google计算引擎上的永久性磁盘可以被挂载：
因此，您不能像build议的那样以读写模式将永久磁盘共享给多个虚拟机。 如果你想要一个共享的数据库，就像在注释中指出的yagmoth555一样 ，你应该使用一个SQL数据库，比如MySQL。
方便的是， Google Cloud SQL提供了一个托pipeMySQL实例，您可以从多个虚拟机中使用它，因为它提供了正确的locking以及备份，故障转移等function。