Sending webhook of message queue to realize cross application asynchronous callback

send out Webhook

Besides mail sending and scheduled task scheduling , We can also asynchronously initiate network requests to third-party services through message queues , It's like JavaScript Medium Ajax like that , Push messages across applications . A typical scenario is sending Webhook Implement asynchronous callback notification .

We create a queue task class  SendWebhook  Used to perform Webhook Sending work of , stay  handle  In the method , adopt Laravel Self contained  HTTP client Send... Containing event data POST Request to given URL As Webhook,URL After the corresponding application receives the request , And then carry out follow-up treatment ：

here , We also set the requested supermarket time to be 5s, No response from the other party's application is received after this time , The request is considered to have timed out .

Next , In the controller method  SendWebhook  The task is pushed to the message queue for asynchronous processing , Third party services and event instances are passed in as parameters during push , In order to use... When processing tasks ：

Try again after the request fails

Since it is HTTP Network request , Then the request may fail for various reasons , For example, the network is disconnected 、 The other server goes down 、 Appoint URL non-existent 、 Or the other party's service is not available . Embodied in  $response  As a result, a timeout exception is thrown 、 obtain 404 perhaps 500 Respond to , We can retry after determining that the response has failed ：

Of course , If we  SendWebhook  The maximum number of attempts is set  tries, In the event of a request failure ,Laravel Message queuing will automatically retry this task , However, through this manual retry method, the underlying logic of retry can be more finely controlled , For example, how long to delay the next retry after each failure , The configuration here is actually a skip retry , Because each retry will  attempts  Add the values of a ：

The reason why the delay time is set so long , because HTTP The response time of the request is uncontrollable , And if oneortwo requests fail, it may be network jitter , However, if the request fails many times, it is likely that the service is no longer available （ The network is disconnected 、 Server down 、 Service crash, etc ）, This is the time , Frequent retries will waste system resources , Increase system load .

Configure task expiration

Push the above tasks 、 Both asynchronous processing and failure retry are automatic , As we said above , If the third-party service is really unavailable , It is futile to try again and again , It will only increase the empty consumption of system resources in a meaningless way （ Each time a task is executed, the current machine's CPU And memory resources ）.

This is the time , We can set the maximum number of task retries , Or set a termination condition for failed retries , For example, don't try again after a day , This can be done by defining  retryUtil  Method to implement ：

In this case , It is usually necessary to set the maximum number of attempts to infinite retry ：

Otherwise, it may not trigger  retryUtil  The conditions are , In fact, one of these two can be set arbitrarily , The purpose is to set termination conditions for failed retries , Avoid infinite retries .

Failed to process task

Last , If the queue task triggers the maximum number of attempts , Or it has not been successfully executed before the expiration date , Will be marked as execution failure , You can define for the task class  failed  Method , In order to send email to developers or operators after it fails to execute / SMS notification , Human intervention , Push for problem solving , Such as solving program problems , Or feed back to the third-party service provider to solve the problem ：