一、前言
当初大多都应用 MQ 来做零碎的异构，来做零碎的解耦，零碎的的模块相当于寄信者与收信者，MQ 则扮演者邮局的角色。作为一个直达的角色，就须要确保音讯的 100% 投递。
明天咱们就来钻研一下如何确保音讯的 100% 的投递。
二、先谈谈 RabbitMQ 的个性
RabbitMQ 所做的确保是：只有你把音讯投递到 Broker 中，那么我就确保这个音讯会送达到消费者的手中。
当然这是有前提条件的，比方：
- 你须要进行手动应答，
- 最起码 Broker 不挂，且音讯进行了长久化等。
联合 RabbitMQ 的个性来做剖析，针对于投递端，咱们只须要确保把音讯发送到 Broker 中即可，那么如何保障可靠性呢，分下列步骤：
- 音讯胜利的发送了进来
- 保障 Broker 胜利的收到了音讯
- 生产者收到了 Broker 的确认应答
- 音讯弥补机制，以后三步都跪了，做一个弥补重发机制
- 最初一道屏障，如果第四步重试次数过多，那么阐明零碎呈现问题，咱们就须要人工干预了
只有做到下面五步，基本上咱们就能够保障，音讯投递 100% 的投递进来。
三、生产者的投递的可靠性保障
3.1 先上一个示意图
3.2 就上述的图示，咱们逐渐解析
- step1：数据落库，这一步是必须的
- step2：把音讯落库，且初始化其状态为 0（发送中）
- step3：把音讯投递到 Broker 中
- step4：Broker 发送胜利应答
- step5：生产者拿到胜利应答，批改音讯状态为 1:（发送胜利）
下面讲述的都是失常的流程，上面讲讲如果呈现不失常的解决机制： - step6：定时查看音讯的状态是否为 1
- step7：如果 step6 的音讯的状态依然为 0，则进入重发，反复上述 step1 – step5
- step8：如果音讯重发达到肯定的的次数，则人工接入解决，因为此时阐明可能是音讯
上述的计划看似白璧无瑕，然而细想，如果在 step4 中 Broker 发送应答的过程中，网络呈现问题这个音讯没有达到生产者会导致整个流程进入弥补的流程当中，此时 Broker 中就有两条音讯，也就是发成了反复的投递的问题，所以接下来咱们要在生产端来解决这个问题。
四、生产端的幂等：
4.1 导致须要解决幂等的起因
- Broker 发送应答音讯的时候，音讯未达到生产者
- 消费者在发送应答的时候，消费者挂掉了
4.2 就上述咱们的机制的解决
因为上述我的音讯都有惟一的标识，所以咱们只须要查找对应的音讯对应的标识来判断其状态即可
4.3 构建惟一标识的计划
首先阐明不同的计划应用不同的利用场景，不要一上来你就说十几万的并发怎么样的，这个慢慢来，一步步往这里走
4.3.1 利用数据库自增 id
长处：
1)：不能再简略了，在并发不大的状况能够承受
2)：对分页和排序是有帮忙的
毛病：
1)：分库分表和读写拆散多住从的状况下不实用
2)：性能达不到要求时，不利于扩大
3)：不同数据库的语法实现不一样
4.3.2 利用 redis 来生成 id
长处：
1)：redis 单线程能够生成全局惟一 ID
2)：能够应用 redis 集群获取更高的吞吐量
毛病：
1)：引入新的组件，减少零碎复杂度
2)：须要留神解决并发问题
4.3.3 利用 twitter 开源的 snowflake
snowflake 是 twitter 开源的一个分布式的 ID 的生成算法，后果是一个 long 的 ID，应用 41bit 作为毫秒数，10bit 作为机器 ID（5 个 bit 是数据中心，5 个 bit 是机器 ID）12 bit 作为毫秒内的流水号（每个节点每毫秒能够产生 2^12 = 4096 个 ID）最初是一个符号位，
长处：
1)：不依赖数据库和其余的中间件，且性能尚可
毛病：
1)：是有依赖工夫的，如果各个机器的失重不同步就会呈现不适全局递增的状况
最初，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 RabbitMQ 系列面试题和答案，十分齐全。
作者：热心市民小陈
链接：blog.csdn.net/weixin_42849915/article/details/87828163
版权申明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接和本申明。
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！