1. All scenarios achieved using Pull can also be implemented through Push, which is also simpler.
2. Push is actually a long-polling Pull, which is also initiated by the client. You can configure parameters on the client for throttling to avoid excessive traffic on the client.
3. Push encapsulates the pull messages and distributes them to the threading model of the consuming thread. In non-throttling mode, the background thread proactively pulls the messages and caches them locally. When the consumption threading pool has free threads, messages are distributed to the consumption thread. In the case of accumulated messages, the consumer thread works all the time with higher performance. Pull only provides the function of pulling messages, while the application needs to control when to pull and other factors. The logic for message distribution to the consumption thread requires application encapsulation, which may increase workload, and lead to instability and other performance issues.
4. Push becomes more mature and stable after long-time application in large-scale projects such as Internet of Things and energy stations, and in pilot running across multiple provinces.
5. Push automatically subscribes to the retry queue and does not need to call the API of the Pull retry queue to obtain messages from the retry queue. Note: Pull calls a separate API to pull messages from the retry queue.
6. Pull is a legacy consumption mode that is compatible with earlier APIs. New applications or applications that are not online require the Push consumption mode.