持久化消息就意味着消息的可靠性吗？如何实现可靠性投递？
消息可靠性需要考虑生产端投递消息的可靠性以及保证消费端最终成功地消费消息。
虽然通过生产端的ACK机制，可以确保消息成功的投递到了RabbitMQ中，保证投递的消息不丢失。但是如果生产端不知道消费者究竟有没有成功的消费了消息，那也就无法实现可靠性投递了。
而生产端投递消息的过程中，通常会涉及到生产端的事务提交，要保证消息跟随事务提交而发送，也是需要考虑的问题。
如何实现可靠投递呢？这里留给大家思考，关键设计要点：
- 是否要发消息跟随生产端
事务一起保存到发送日志表，提交事务之后立刻向消息队列投递一次消息；- 生产端发送日志表
消息状态：1 发送中，2 Broker签收成功，3 Broker签收失败，4 消费端签收成功，5 消费端签收失败
- 生产端发送日志表
- 使用消息队列模拟
RPC调用，在消费者成功处理消息之后，向生产者投递成功消费的消息，以便让生产端知道消息已经处理成功了； 定时任务定时扫描生产端发送日志表，对于超过固定时间之内，还未处理成功的消息，进行重试投递，重试可以使用指数退避策略，并设置投递上限次数。如果达到上限次数还未成功，则预警人工介入排查；- 消费端一定要做好
幂等处理，避免重复消费导致业务异常。
提示的还不够具体？我再上一张图：
有更好的方案的朋友，欢迎在评论区留言交流，也许你就是评论区最靓的仔。