在写入数据库之前，请持续存储数据点
我有一个接收传感器数据的Django应用程序。然后，使用infuxdb-client-python库将此数据处理并写入infuxdb。我想以异步方式编写数据，从而在将数据实际写入数据库之前返回对数据生产者的响应。
但是，一旦我发送了此响应，我就再也无法承受丢失此数据了。由于我永远无法确定服务器实际上能够将数据写入InfluxDB，因此我正在考虑首先将其写入文件并在成功之后返回响应（类似于一个WAL）。这引入了新问题，例如确保WAL实际上写入文件，最重要的是，确保它是线程安全的，因为服务器可能会同时处理多个请求。
是否有更好的方法来执行此操作，也许是django内置的？
I have a Django app that receives sensor data. This data is then processed and written to influxDB using the influxdb-client-python library. I would like to write the data in an asynchronous manner and thus return a response to the producer of the data before it is actually written to the database.
However, once I send this response I can no longer afford to lose this data. Since I can never be sure that the server will in fact be able to write the data to influxDB, I was thinking about first writing it to a file and returning a response after this is successful (similar to a WAL). This introduces new problems like making sure the WAL is actually written to a file and most importantly, making sure it is thread-safe since the server may be handling multiple requests concurrently.
Is there any better way of doing this, maybe built-in in Django?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这听起来像是队列，背景任务等。您是对的，它只是置换了问题，但是队列也很可靠。
使用Django和/或Rest框架进行此操作的标准LIB是：
芹菜可能是这里正确的起点，因为它可以使用“真实”队列后端，但是如果没有大量负载，Django RQ+Redis也将工作。
在不了解您的应用或架构的情况下，很难说更多。有很多排队系统（兔子， Zeromq ，AWS SQS，Google等）。您还可以考虑使用例如AWS SQS和AWS Lambda功能（或Google版本）来构建队列+处理器。
That sounds like a queue, background tasks, etc. You are right, it just displaces the issue, but queues are highly reliable as well.
The standard libs for doing this with Django and/or Rest Framework are:
Celery is probably the right starting point here, since it lets you use a "real" queue backend, but Django RQ+redis will also work if there isn't a ton of load.
Without knowing anything more about your app or architecture, its hard to say more. There are a lot of queuing systems (Rabbit, ZeroMQ, AWS SQS, Google's, etc). You can also look into building the queue+processor using, for example, AWS SQS and AWS Lambda Functions (or google versions).