Add Message queues section
This commit is contained in:
parent
87c4fafccb
commit
c931a8544c
15
README.md
15
README.md
@ -1407,3 +1407,18 @@ Refresh-ahead can result in reduced latency vs read-through if the cache can acc
|
||||
</p>
|
||||
|
||||
Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data.
|
||||
|
||||
### Message queues
|
||||
|
||||
Message queues receive, hold, and deliver messages. If an operation is too slow to perform inline, you can use a message queue with the following workflow:
|
||||
|
||||
* An application publishes a job to the queue, then notifies the user of job status
|
||||
* A worker picks up the job from the queue, processes it, then signals the job is complete
|
||||
|
||||
The user is not blocked and the job is processed in the background. During this time, the client might optionally do a small amount of processing to make it seem like the task has completed. For example, if posting a tweet, the tweet could be instantly posted to your timeline, but it could take some time before your tweet is actually delivered to all of your followers.
|
||||
|
||||
**Redis** is useful as a simple message broker but messages can be lost.
|
||||
|
||||
**RabbitMQ** is popular but requires you to adapt to the 'AMQP' protocol and manage your own nodes.
|
||||
|
||||
**Amazon SQS**, is hosted but can have high latency and has the possibility of messages being delivered twice.
|
||||
|
Loading…
Reference in New Issue
Block a user