我想使用 data.table::fwrite 以文本日志的形式快速存储和检索状态。这些是通过移动应用程序更新的，该应用程序使用管道工 API 调用 R 端点。移动应用程序每秒可能会触发许多 API，并且同一行有可能在大约 0.5 秒的间隙内被两个 API 修改。由于每次 API 调用延迟 1~2 秒，我正在避免 DB 读写（R 的 fwrite 第一次可以在 0.5 秒内完成相同的工作，然后在随后的调用中在不到 20 毫秒的时间内完成 API）
我的问题是：
fwrite/fread 组合是否适用于更高的流量场景，还是我必须寻找锁定文件的方法以避免损坏？是否有任何方法可以锁定文件以进行读取或写入？
fwrite/fread 组合是否适用于更高的流量场景，还是我必须寻找锁定文件的方法以避免损坏？
答案是“视情况而定”。
如果您使用简单的托管模型托管应用程序，其中所有流量都命中相同的单例 R 进程，那么即使在高流量情况下您也可能会没事。这里需要注意的是，如果您在 API 中进行任何类型的内部进程分叉（或者如果 data.table 这样做；我不确定，我从未使用过），这将不会成立。
但是，如果您使用多个 R 进程和在它们前面的负载均衡器来托管应用程序，那么您将遇到多个进程尝试写入同一个文件的问题。
扩展 Plumber API 的典型建议是通过添加更多 R 进程来水平扩展。因此，我鼓励您尝试找到一个能够在您最终希望多个 Plumber 进程并行运行时继续工作的设计。您可以查看在远程数据库中进行集中处理，甚至使用 SQLite 在本地进行集中处理，只需确保将其配置为支持多个并发编写器（我不能 100% 确定 SQLite 是否支持这一点）。
我当然不会期望 1-2 秒的延迟来击中数据库。可能值得调查您的数据库硬件/软件或检查网络中是否存在任何延迟。您还可以将pool 包视为保持数据库连接打开并可用于您的 API 的一种方式。我猜想这会大大减少您的数据库写入所需的时间。