小结：
1、
/1/退订请求入库--->消息队列异步--->调用供应商对接系统
调用
成功--->标识数据库
失败--->补偿脚本--->重新调用
我们引入RocketMQ将同步改为异步，当前端用户发出退订需求，退订系统接收到请求后就会记录到退订系统的数据库里面，表示这个用户正在退订，同时通过消息引擎把这条退订消息发送到和供应商对接的系统，去调用供应商的接口。
如果调用成功，就会把数据库进行标识，表示已经退订成功。同时，加了一个补偿的脚本，去数据库捞那些未退订成功的消息，重新退订，避免消息丢失引起的退订失败的情况。
2、
同一Group和同一Topic下，一个是消费Tag1的数据，另一个是消费Tag2的数据。
正常情况下，启动应该是没问题的，但是有一天我们发现一个应用起不来了，另外一个应用，因为他只消费Tag2的数据，但是因为RocketMQ的机制会把Tag1的数据拿过来，拿过来过后会把Tag1的数据丢弃。
3、
对于大量老数据读取的改进方式是
- > 对于新消费组，默认从LAST_OFFSET消费而不是初始默认的0；
- > Broker中单Topic堆积超过1000万时，禁止消费，需联系管理员开启消费；
https://mp.weixin.qq.com/s/Uj0lirsq0zyCIb8AlEoNBg
消息规模超千亿，同程艺龙的消息系统建设实践
导读：
同程艺龙的机票、火车票、汽车票、酒店相关业务已经接入了RocketMQ，用于流量高峰时候的削峰，以减少后端的压力。同时，对常规的系统进行解耦，将一些同步处理改成异步处理，每天处理的数据达1500亿条。
在近期的Apache RockeMQ Meetup上，同程艺龙机票事业部架构师查江，分享了同程艺龙的消息系统如何应对每天1500亿条的数据处理，通过此文，您将了解到：
-
同程艺龙在消息方面的使用情况；
-
消息在同程艺龙的应用场景；
-
技术上踩过哪些坑；
-
基于RocketMQ，做了哪些改进；
同程艺龙在消息方面的使用情况
虑性能，另一个考虑安全性。 在纯数据的Broker分成很多组，每个组里面分为Master和Slave。目前，我们的机票、火车票、汽车票、酒店相关业务已经接入了RocketMQ，用于流量高峰时候的削峰，以减少后端的压力。同时，对常规的系统进行解耦，将一些同步处理改成异步处理，每天处理的数据达1500亿条。
选择RocketMQ的原因是：
-
接入简单，引入的Java包比较少；
-
纯Java开发，设计逻辑比较清晰；
-
整体性能比较稳定的，Topic数量大的情况下，可以保持性能；
消息在同程艺龙的应用场景
退订系统
这个是我们退订系统中的一个应用场景。用户点击前端的退订按钮，系统调用退订接口，再去调用供应商的退订接口，从而完成一个退订功能。
如果供应商的系统接口不可靠，就会导致用户退订失败，如果系统设置为同步操作，会导致用户需要再去点一次。所以，我们引入RocketMQ将同步改为异步，当前端用户发出退订需求，退订系统接收到请求后就会记录到退订系统的数据库里面，表示这个用户正在退订，同时通过消息引擎把这条退订消息发送到和供应商对接的系统，去调用供应商的接口。
如果调用成功，就会把数据库进行标识，表示已经退订成功。同时，加了一个补偿的脚本，去数据库捞那些未退订成功的消息，重新退订，避免消息丢失引起的退订失败的情况。
房仓系统
第二个应用场景是我们的房仓系统。这是一个比较常规的消息使用场景，我们从供应商处采集一些酒店的基本信息数据和详情数据，然后接入到消息系统，由后端的分销系统、最小价系统和库存系统来进行计算。同时当供应商有变价的时候,变价事件也会通过消息系统传递给我们的后端业务系统，来保证数据的实时性和准确性。
供应库的订阅系统
数据库的订阅系统也用到了消息的应用。一般情况下做数据库同步，都是通过binlog去读里面的数据，然后搬运到数据库。搬运过程中我们最关注的是数据的顺序性，因此在数据库row模式的基础上，新增了一个功能，以确保每一个Queue里面的顺序是唯一的。
我们踩过哪些坑
供应商系统的场景
上图中，一个MQ对应有两个消费者，他们是在同一个Group1中，起初大家都只有Topic1，这时候是正常消费的。但如果在第一个消费者里面加入一个Topic2，这时候是无法消费或消费不正常了。这是RocketMQ本身的机制引起的问题，需要在第二个消费者里面加入Topic2才能正常消费。
支付交易系统的场景
另外一个是支付交易系统，这个场景下也是有两个应用，他们都是在同一Group和同一Topic下，一个是消费Tag1的数据，另一个是消费Tag2的数据。正常情况下，启动应该是没问题的，但是有一天我们发现一个应用起不来了，另外一个应用，因为他只消费Tag2的数据，但是因为RocketMQ的机制会把Tag1的数据拿过来，拿过来过后会把Tag1的数据丢弃。这会导致用户在支付过程中出现支付失败的情况。
对此，我们把Tag2放到Group2里面，两个Group就不会消费相同的消息了。个人建议RocketMQ能够实现一个机制，即只接受自己的Tag消息，非相关的Tag不去接收。
大量老数据读取的场景
在火车票消费的场景中，我们发现有200亿条老数据没有被消费。当我们消费启动的时候，RocketMQ会默认从第0个数据开始读，这时候磁盘IO飙升到100%，从而影响到其他消费端数据的读取，但这些老数据被加载后后，并没有实际作用。因此，对于大量老数据读取的改进方式是：
- > 对于新消费组，默认从LAST_OFFSET消费；
- > Broker中单Topic堆积超过1000万时，禁止消费，需联系管理员开启消费；
- > 监控要到位，磁盘IO飙升时，能立刻联系到消费方处理。
服务端的场景
CentOS 6.6中 Futex Kernel bug, 导致Name Server, Broker进程经常挂起，无法正常工作；
- > 升级到6.7
服务端2个线程会创建相同CommitLog放入List，导致计算消息offset错误，解析消息失败，无法消费，重启没法解决问题。
- > 线程安全问题，改为单线程
Pull模式下重置消费进度，导致服务端填充大量数据到Map中，broker cpu使用率飙升100%。
- > Map局部变量场景用不到，删除
Master建议客户端到Slave消费时，若数据还没同步到Slave, 会重置pullOffset, 导致大量重复消费。
- > 不重置offset
同步没有MagicCode，安全组扫描同步端口时，Master解析错误，导致一些问题。
- > 同步时添加magicCode校验
基于RocketMQ，我们做了哪些改进
新增客户端
新增.net客户端，基于Java源代码原生开发；
新增HTTP客户端，实现部分功能，并通过Netty Server连接RocketMQ；
新增消息限流功能
如果客户端代码写错产生死循环，就会产生大量的重复数据，这时候会把生产线程打满，导致队列溢出，严重影响我们MQ集群的稳定性，从而影响其他业务。
上图是限流的模型图，我们把限流功能加在Topic之前。通过限流功能可以设置rate limit和size limit等。其中rate limit是通过令牌桶算法来实现的，即每秒往桶里放多少个令牌，每秒就消费多少速度，或者是往Topic里写多少数据。以上的两个配置是支持动态修改的。
后台监控
我们还做了一个监控后台，用于监控消息的全链路过程，包括：
-
消息全链路追踪，覆盖消息产生、消费、过期整个生命周期；
-
消息生产、消费曲线；
-
消息生产异常报警；
-
消息堆积报警，通知哪个IP消费过慢。
其他功能
-
HTTP方式生产，消费消息；
-
Topic消费权限设置，Topic只能被指定Group消费，防止线上错乱订阅；
-
支持新消费组从最新位置消费 (默认是从第一条开始消费)；
-
广播模式消费进度同步 (服务端显示进度)。
以上便是同程艺龙在消息系统建设方面的实践。