Mobabel

Just One Pure ITer

Category: Distributed Message Queue

[转]消息中间件–5 消息处理失败&死信队列 0

MQ in distributed Architecture

[转]消息中间件–5 消息处理失败&死信队列

消息中间件消费到的消息处理失败怎么办？ 一般生产环境中，如果你有丰富的架构设计经验，都会在使用MQ的时候设计两个队列：一个是核心业务队列，一个是死信队列。 核心业务队列，就是比如专门用来让订单系统发送订单消息的，然后另外一个死信队列就是用来处理异常情况的。比如说要是第三方物流系统故障了，此时无法请求，那么仓储系统每次消费到一条订单消息，尝试通知发货和配送，都会遇到对方的接口报错。 此时仓储系统就可以把这条消息拒绝访问，或者标志位处理失败！注意，这个步骤很重要。

[转]MQ中间件各种疑难杂症 0

MQ in distributed Architecture

[转]MQ中间件各种疑难杂症

1. 消息队列有什么优点和缺点? 为什么使用消息队列？假设你的业务场景遇到个技术挑战，如果不用 MQ 可能会很麻烦，但是你用了 MQ 之后会带给你很多好处。 消息队列 MQ 的常见使用场景其实有很多，但是比较核心的有如下三个： 解耦 异步 削峰 1-1-1. 解耦：A 系统发送个数据到 BCD 三个系统，接口调用发送，那如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？

0

Kafka Practice

[总结]Kafka性能调优和参数调优

Kafka的配置详尽、复杂，想要进行全面的性能调优需要掌握大量信息，这里只记录一下我在日常工作使用中走过的坑和经验来对kafka集群进行优化常用的几点。

[转]同程RocketMQ如何应对每天1500亿条的数据处理？ 0

RocketMQ

[转]同程RocketMQ如何应对每天1500亿条的数据处理？

同程艺龙的机票、火车票、汽车票、酒店相关业务已经接入了 RocketMQ，用于流量高峰时候的削峰，以减少后端的压力。 同时，对常规的系统进行解耦，将一些同步处理改成异步处理，每天处理的数据达 1500 亿条。 在近期的 Apache RocketMQ Meetup 上，同程艺龙机票事业部架构师查江，分享了同程艺龙的消息系统如何应对每天 1500 亿条的数据处理。 通过此文，您将了解到： 同程艺龙消息系统的使用情况 同程艺龙消息系统的应用场景 技术上踩过的坑 基于 RocketMQ 的改进

[转]Kafka 2.0升级实战！携程的经验有何可借鉴之处 0

Kafka Practice

[转]Kafka 2.0升级实战！携程的经验有何可借鉴之处

早在 2014 年，携程的一些业务部门开始引入 Kafka 作为业务日志的收集处理系统。2015 年，基于 Kafka 的高并发、大数据的特点，携程框架研发部在 Kafka 之上设计了 Hermes Kafka 消息系统，作为大规模的消息场景的统一的中间件。随着业务量的迅速增加，以及具体业务、系统运维上的一些误用，Kafka 现有系统变得不稳定，经历了多次 down 机，故障期间完全不可用，持续时间长达 5 小时以上，恢复缓慢。Kafka 还能用多久？成为一个迫切棘手的问题。问题严重又难以解决，必须做出改变。 本文主要分享携程将 Kafka 从 0.9 升级到 2.0 的实战经验以及基于 Kafka 2.0 的应用实践。这是 InfoQ 特别策划《Kafka 的七年之痒》专题系列文章的第三篇，前两篇文章回顾见 《Kafka 从 0.7...

[转]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？ 0

RabbitMQ

[转]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？

“上一篇讲消息中间件的文章《扎心！线上服务宕机时，如何保证数据100%不丢失？》，初步给大家介绍了一个在生产环境中可能遇到的问题，就是你的消费者服务可能会宕机，一旦宕机，你就需要考虑是否会导致没处理完的消息丢失。 这篇文章，再给不太熟悉MQ技术的同学，介绍另外一个生产环境中可能会遇到的问题。