I have a web service that runs multiple DB queries and takes roughly ~500ms-1,000ms (depending on how much I/O EC2 decides to give me at the given junction if invocation). Users want stuff faster than 1,000ms, and understandably so. What I'm thinking of doing is taking the request parameters, stuffing them into a redis queue without writing to disk, and then running a job in an asynchronous queue which does the disk writes. Does something like this happen normally in practice? am I insane for suggesting it?
我有一个运行多个DB查询的web服务，大约需要500ms- 1000ms(取决于如果调用的话，在给定的连接上I/O EC2决定给我多少)。用户想要的东西超过1000毫秒，这是可以理解的。我想做的是获取请求参数，在不写入磁盘的情况下将它们填充到redis队列中，然后在执行磁盘写入的异步队列中运行一个作业。这样的事情在实践中经常发生吗?我这么说是疯了吗?
1 个解决方案
#1
3
So long as your Redis is persisting to disk on regular intervals, this should work. You want to limit the number of scenarios where you might lose data. A sufficiently aggressive persistence schedule for Redis should work for most cases.
只要您的Redis持续定期地对磁盘进行持久化，这应该会起作用。您希望限制可能丢失数据的场景的数量。对于Redis，一个足够积极的持久性计划应该适用于大多数情况。
Try to give feedback to the user immediately that their action has been received and is being processed. Nothing is more confusing than a slight delay before it appears that might prompt people to attempt the upload again.
试着立即反馈给用户他们的行为已经收到并且正在被处理。没有什么比在提示人们再次尝试上传之前稍微延迟更让人困惑的了。
#1
3
So long as your Redis is persisting to disk on regular intervals, this should work. You want to limit the number of scenarios where you might lose data. A sufficiently aggressive persistence schedule for Redis should work for most cases.
只要您的Redis持续定期地对磁盘进行持久化，这应该会起作用。您希望限制可能丢失数据的场景的数量。对于Redis，一个足够积极的持久性计划应该适用于大多数情况。
Try to give feedback to the user immediately that their action has been received and is being processed. Nothing is more confusing than a slight delay before it appears that might prompt people to attempt the upload again.
试着立即反馈给用户他们的行为已经收到并且正在被处理。没有什么比在提示人们再次尝试上传之前稍微延迟更让人困惑的了。