消息队列的使用场景.
- 校验用户名等信息，如果没问题会在数据库中添加一个用户记录
- 如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
- 分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
- 发送给用户一个包含操作指南的系统通知
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 非鱼小站！
微信- 支付宝
相关推荐
2022-07-27
消息的堆积解决思路
如果还没开始投入使用 Kafka，那应该在设计分区数的时候，尽量设置的多点（当然也不要太大，太大影响延迟，具体可以参考我前面提到的文章），从而提升生产和消费的并行度，避免消费太慢导致消费堆积。 增大批次瓶颈在消费吞吐量的时候，增加批次也可以改善性能 增加线程数如果一些消费者组中的消费者线程还是有 1 个消费者线程消费多个分区的情况，建议增加消费者线程。尽量 1 个消费者线程对应 1 个分区，从而发挥现有分区数下的最大并行度。
2022-07-13
死信、延迟、重试队列
死信队列DLQ(Deal Letter Queue)，死信队列。当一个消息在队列中变成死信之后，他能被重新发送到 DLQ 中，与 DLQ 绑定到队列就是死信队列。 什么情况下需要死信队列 消息被拒绝 消息过期 队列达到最大长度 生产者生产一条消息，存储到普通队列中；设置队列的过期时间为 10 秒，在 10 秒内没有消费者消费消息，那么判定消息过期；此时如果设置了死信队列，过期消息被丢给死信队列交换机，然后被存储在死信队列中。 延迟队列顾名思义就是延迟执行消息，比如我们可以增加一个队列并设置其超时时间为 10 秒并且不设置任何消费者，等到消息超时，我们可以将消息放入死信队列，让消费者监听这个死信队列就达到了延迟队列的效果。 重试队列重试的消息在延迟的某个时间点（业务可设置）后，再次投递给消费者。而如果一直这样重复消费都持续失败到一定次数，就会投递到死信队列，最后需要进行人工干预。
2022-07-25
消息的重发补偿解决思路
可靠消息服务定时查询状态为已发送并超时的消息 可靠消息将消息重新投递到 MQ 组件中 下游应用监听消息，在满足幂等性的条件下，重新执行业务。 下游应用通知可靠消息服务该消息已经成功消费。 通过消息状态确认和消息重发两个功能，可以确保上游应用、可靠消息服务和下游应用数据的最终一致性。
2022-07-26
消息的幂等性解决思路
查询操作查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select 是天然的幂等操作 删除操作删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个) 唯一索引，防止新增脏数据比如：支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录 Token 机制防止页面重复提交 悲观锁获取数据的时候加锁获取 select * from table_xxx where id='xxx' for update; 注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的 悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用 乐观锁乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。 分布式锁还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的...
2022-07-29
如何保证消息的有序性
通过轮询所有队列的方式来确定消息被发送到哪一个队列（负载均衡策略）。订单号相同的消息会被先后发送到同一个队列中， 在获取到路由信息以后，会根据算法来选择一个队列，同一个 OrderId 获取到的肯定是同一个队列。
评论
WalineDisqus
