最近在研究异步批量操作的时候发现，这个操作很像快递行业中的定时收件：
经常网购的朋友或许也知道，当你下单后问店家什么时候发货，通常店家都回答“当日下午四点（五点）前付款的订单当天发走”，这是源于快递行业收单的业务规划决定的。
定时收单，它的好处是一次能获取一个较大批量的运单，对快递员来说，只需要在到点的时候跑一次就能把之前累积的所有运单一次收回来。
如果来一单就跑一趟，假设一个上午有10单，快递员就要往返跑10次，这往返10次的时间成本是很重的，更何况一个快递员不可能只管一个收件点，每个收件点都这样跑，在运单稍微多一点的时候跑断腿都不一定收得过来。
类似的操作，kafka应该是最早开始使用微批量思想的MQ中间件：
传统消息中间件的消息发送和消费整体上是针对单条的。对于生产者而言，它先发一条消息，然后broker返回ACK表示已接收，这里产生2次rpc；对于消费者而言，它先请求接受消息，然后broker返回消息，最后发送ACK表示已消费，这里产生了3次rpc（有些消息中间件会优化一下，broker返回的时候返回多条消息）。而Kafka采用了批量处理：生产者聚合了一批消息，然后再做2次rpc将消息存入broker，这原本是需要很多次的rpc才能完成的操作。假设需要发送1000条消息，每条消息大小1KB，那么传统的消息中间件需要2000次rpc，而Kafka可能会把这1000条消息包装成1个1MB的消息，采用2次rpc就完成了任务。这一改进举措一度被认为是一种“作弊”的行为，然而在微批次理念盛行的今日，其它消息中间件也开始纷纷效仿。
————————————————
版权声明：本文为CSDN博主「朱小厮」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://hiddenpps.blog.csdn.net/article/details/93772377
利用快递行业的业务知识，理解什么是异步操作：
在当今快递行业中，哪一个步骤最能体现“异步操作”的精髓呢？
是快件签收。考虑以下场景：
在寄存服务盛行的当下，当你网购付款后，快递在途中运转几天，派送的那一天快递员甚至都不需要给你打点话，而是直接将快件投递到“寄存点”（X巢，速X易，天X驿站），然后以短信的形式通知你快件已经被“代收”了。整个快件签收过程，用户全程不需要参与，假如说网购付款的那一刻是快件投递的请求发起，那么签收这一刻就是投递请求完成了，这整个快件转运和投递过程就是一个活生生的“异步操作”的真实案例。
类比过程：用户付款（异步请求发起），快递员将快件投递到离用户最近的寄存点签收后用户收到签收短信通知（异步消息通知），这个过程中快递在其中担起了“异步操作”的责任，负责将这个操作完成并通知用户。
PS：通常寄存点离用户付款时填的地址不会太远。这样就比较符合“异步操作”后数据会搬运到用户指定的地点了。