High priority items should be executed if they’re available. Let’s say that we want to have three priority levels: high, medium, and low. Remember the BLPOP/ BRPOP commands-we can provide multiple LISTs in which to pop an item from the first LIST to have any items in it will have its first item popped (or last if we’re using BRPOP).
QUEUE FIFO PASSWORD
Or maybe we want to send password reset emails before we send out emails for an upcoming special event. In our case, maybe we want to send emails about sales that completed before we send emails about sales that expired. Sometimes when working with queues, it’s necessary to prioritize certain operations before others. With this generic worker process, our email sender could be written as a callback and passed with other callbacks. Listing 6.18 The send_sold_email_via_queue() function The function that pushes an email onto the item-sold email task queue appears in the next listing. As in previous chapters, we use JSON because it’s human readable and because there are fast libraries for translation to/from JSON in most languages.
To add an item to the queue, we’ll get all of the necessary information together, serialize it with JSON, and RPUSH the result onto our email queue. Our queue will simply be a list of JSON-encoded blobs of data, which will look like figure 6.9. Figure 6.9 A first-in, first-out queue using a LIST We’ll only handle item-sold messages in this version for the sake of simplicity, but adding support for sending timeout emails is also easy. (We do this because it makes sense visually for readers of left-to-right languages.) Because our worker processes are only going to be performing this emailing operation, we’ll use the blocking version of our list pop, BLPOP, with a timeout of 30 seconds. For our email queue, we’ll push emails to send onto the right end of the queue with RPUSH, and pop them off the left end of the queue with LPOP. As we talked about in chapters 3 and 5, Redis LISTs let us push and pop items from both ends with RPUSH/ LPUSH and RPOP/ LPOP. The queue that we’ll write only needs to send emails out in a first-come, first served manner, and will log both successes and failures. To do this, we’ll use a task queue to keep a record of people who need to be emailed and why, and will implement a worker process that can be run in parallel to send multiple emails at a time if outgoing mail servers become slow.
QUEUE FIFO CODE
Because outgoing email is one of those internet services that can have very high latencies and can fail, we need to keep the act of sending emails for completed or timed-out sales out of the typical code flow for those operations. To encourage users to play the game when they don’t normally do so, Fake Game Company has decided to add the option for users to opt-in to emails about marketplace sales that have completed or that have timed out. Let’s again look back to an example from Fake Game Company. Later, we’ll talk about adding a method for coarse-grained priorities, and even later, timebased queues. We’ll look first at a first-in, first-out queue, because it offers the most reasonable semantics for our first pass at a queue, can be implemented easily, and is fast.
In the world of queues beyond task queues, normally a few different kinds of queues are discussed-first-in, first-out (FIFO), last-in first-out (LIFO), and priority queues.
0 kommentar(er)
