A request to resize an image should not keep a user waiting while the server does heavy work. Instead, the application can add a task to a queue and respond promptly. Worker Pods take pending tasks from the queue and process them in the background. The application can show progress, notify the user when the result is ready, or have the client retry. section 10.1 section 6.4.3
A queue holds tasks until workers are ready for them. In a Redis-backed queue, the application uses RPUSH to add a task at the back, and a worker uses BLPOP to remove one from the front. This gives first-in, first-out ordering. BLPOP waits when the queue is empty, avoiding a resource-consuming retry loop. section 10.1.1
Workers calculating pi
A producer adds iteration counts to the Redis queue and checks its length. Two worker Pods repeatedly take a count, calculate pi, and log the result. The queue separates adding work from doing it; a Kubernetes Deployment keeps the workers running to handle new tasks. section 10.1.1 section 10.5
Listing 10.2 Chapter10/pi_worker/pi_worker.py
import os
import redis
from pi import *
redis_host = os.environ.get('REDIS_HOST') #1
assert redis_host != None
r = redis.Redis(host=redis_host, #2
port='6379', #2
decode_responses=True) #2
print("starting")
while True:
task = r.blpop('queue:task') #3
iterations = int(task[1])
print("got task: " + str(iterations))
pi = leibniz_pi(iterations) #4
print (pi)
The worker loop calls Redis BLPOP for the next task, then performs the calculation. section 10.1.1
Use a Deployment with a shared queue when tasks arrive continuously; its worker capacity can be adjusted against queue length. For a known, finite set of tasks, a Kubernetes Job can instead create Pods for a static queue. An Indexed Job, for example, can assign each Pod a frame number to render without requiring workers to pull from Redis. section 6.4.3 section 10.3.2
