rocketmq普通消息-消息类型
引用普通消息发送 | RocketMQ
异步调用的经典业务场景_使用异步的业务场景-CSDN博客
同步消息类型
Send消息发送方发出一条消息后，会在收到服务端同步响应之后才发下一条消息的通讯方式，可靠的同步传输被广泛应用于各种场景，如重要的通知消息、短消息通知等。
用途
1. 重要通知和报警
• 适用于需要确保消息可靠到达的场景，如系统报警、重要通知、事件提醒等。同步发送确保消息发送成功后，系统能得到立即确认，保证消息不会丢失。
2. 订单系统
• 订单系统中的订单创建、订单支付等关键操作需要确保数据一致性和可靠性。通过同步发送，系统可以在发送消息后立即确认消息已成功写入消息队列，从而保证订单数据的一致性和完整性。
3. 交易系统
• 在金融交易、证券交易等高可靠性要求的系统中，消息的可靠传输至关重要。同步发送可以确保每一笔交易的消息都成功到达服务器，避免因消息丢失导致的交易失败或数据不一致。
4. 库存管理系统
• 在库存管理系统中，库存变动消息需要可靠传输，以确保库存数据的准确性和一致性。通过同步发送，系统可以在消息发送后立即确认消息已成功写入消息队列，从而避免库存数据不一致的问题。
异步发送
SendSync消息发送方在发送了一条消息后，不需要等待服务端响应即可发送第二条消息，发送方通过回调接口接收服务端响应，并处理响应结果。异步发送一般用于链路耗时较长，对响应时间较为敏感的业务场景。例如，视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
-
不同场景（用户注册，用户购买产品等）下的短信验证码发送，可以使用异步方式发送： 一方面是因为客户这个时效性要求没有那样高，另一方面在特定时间范围内用户没有收到验证码，用户可以点击再次发送验证码。
-
购买成功或者抽奖成功后短信或者邮件通知，可以通过异步的方式进行。 因为涉及用户的利益，要谨慎对待。一方面一定要把数据先存到数据库或者日志里面（注意信息安全^-^,别存敏感明文信息或者加密存储），然后再放入到异步队列中执行。
另一个方面，要考虑到应用服务意外停止时，没有发送成功数据的补偿机制。 这种情况不常见，并且为了减少耦合和当前异步程序的复杂度。我们使用单独的服务上部署异步任务补偿程序，来扫描未完成的任务，并且进行重放（一定要注意严谨性）。
-
优惠券和卡券的发放，跟购买成功或抽奖成功的方式类似。\u000b可以在当前活动高峰后延时发放，并且使用异步的方式进行。
-
微信红包，因为需要跟微信进行交互，并且微信会通知客户红包的情况，可以使用异步的方式进行。 当涉及资金或者礼品时，一定要谨慎对待设计，并且需要有方便进行异步任务停止和启动的功能。
-
微信消息通知，因为跟微信进行交互，成功后微信进行通知，可以使用异步。 这个跟短信验证码类似。
-
订单流程处理，可以使用异步，因为涉及到后续步骤可以使用简单工作流来完成。有几个开源的框架可以参考。
-
数据同步或者异步任务补偿，因为是延时处理，可以使用异步进行处理。在使用时，可以配合定时任务，比如cron4j来周期性的进行补偿。适合后面总-分-总的任务处理模式。
单向模式发送
SendOneWay 发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答。此方式发送消息的过程耗时非常短，一般在微秒级别。
单向模式发送适用场景
1. 日志收集
• 日志收集系统需要快速、批量地发送大量日志消息到日志服务器。由于日志的发送频率高且不需要每条日志都确认接收状态，单向模式发送是非常合适的选择。
2. 监控数据
• 在监控系统中，实时采集的数据可以通过单向模式发送到监控服务器。监控数据通常是大量且频繁的，而丢失部分数据通常不会对系统产生重大影响，因此适合使用单向模式。
3. 简单通知
• 对于简单的通知消息，例如系统心跳、状态更新等，不需要确认消息是否到达，只需要发送即可。这种情况下，单向模式可以降低发送消息的开销。
4. 批量数据传输
• 批量数据传输如批量更新、同步等，不需要每一条消息都进行确认，只需要保证大部分消息成功传输即可。