1.为什么要用mq(mq的作用)?
2.引入mq会多哪些问题?
3. 如何解决这些问题?
1.1实现异步发送
有些复杂的业务系统,一次用户请求可能会同步调用N个系统的接口,需要等待所有的接口都返回了,才能真正的获取执行结果。这种同步接口调用的方式总耗时比较长,非常影响用户的体验,特别是在网络不稳定的情况下,极容易出现接口超时问题。
同步接口调用导致响应时间长的问题,使用mq之后,将同步调用改成异步,能够显著减少系统响应时间。
1.2解耦
很多复杂的业务系统,一般都会拆分成多个子系统。系统之间耦合性太高,如果调用的任何一个子系统出现异常,整个请求都会异常,对系统的稳定性非常不利。
子系统间耦合性太大的问题,使用mq之后,只需要依赖于mq,避免了各个子系统间的强依赖问题。订单系统作为消息生产者,保证它自己没有异常即可,不会受到支付系统等业务子系统的异常影响,并且各个消费者业务子系统之间,也互不影响。这样就把之前复杂的业务子系统的依赖关系,转换为只依赖于mq的简单依赖,从而显著的降低了系统间的耦合度。
1.3 削峰
某一时间请求量特别大时,消费方消费能力不足,可能会导致系统响应变慢或者直接挂掉。
订单系统接收到用户请求之后,将请求直接发送到mq,然后订单消费者从mq中消费消息,做写库操作。如果出现请求峰值的情况,由于消费者的消费能力有限,会按照自己的节奏来消费消息,多的请求不处理,保留在mq的队列中,不会对系统的稳定性造成影响。
2.引入mq会多哪些问题?
引入mq后子系统间耦合性降低了,异步处理机制减少了系统的响应时间,同时能够有效的应对请求峰值问题,提升系统的稳定性。
但是,引入mq同时也会带来一些问题。
2.1 重复消息问题
重复消费问题可以说是mq中普遍存在的问题,不管你用哪种mq都无法避免。
有哪些场景会出现重复的消息呢?
- 消息生产者产生了重复的消息
- kafka和rocketmq的offset被回调了
- 消息消费者确认失败
- 消息消费者确认时超时了
- 业务系统主动发起重试
如果重复消息不做正确的处理,会对业务造成很大的影响,产生重复的数据,或者导致数据异常,比如会员系统多开通了一个月的会员。
2.2 数据一致性问题
很多时候,如果mq的消费者业务处理异常的话,就会出现数据一致性问题。比如:一个完整的业务流程是,下单成功之后,送100个积分。下单写库了,但是消息消费者在送积分的时候失败了,就会造成数据不一致的情况,即该业务流程的部分数据写库了,另外一部分没有写库。
如果下单和送积分在同一个事务中,要么同时成功,要么同时失败,是不会出现数据一致性问题的。
但由于跨系统调用,为了性能考虑,一般不会使用强一致性的方案,而改成达成最终一致性即可。
2.3 消息丢失问题
同样消息丢失问题,也是mq中普遍存在的问题,不管你用哪种mq都无法避免。
有哪些场景会出现消息丢失问题呢?
消息生产者发生消息时,由于网络原因,发生到mq失败了。
mq服务器持久化时,磁盘出现异常
kafka和rocketmq的offset被回调时,略过了很多消息。
消息消费者刚读取消息,已经ack确认了,但业务还没处理完,服务就被重启了。
导致消息丢失问题的原因挺多的,生产者、mq服务器、消费者 都有可能产生问题,我在这里就不一一列举了。最终的结果会导致消费者无法正确的处理消息,而导致数据不一致的情况。
2.4 消息顺序问题
有些业务数据是有状态的,比如订单有:下单、支付、完成、退货等状态,如果订单数据作为消息体,就会涉及顺序问题了。如果消费者收到同一个订单的两条消息,第一条消息的状态是下单,第二条消息的状态是支付,这是没问题的。但如果第一条消息的状态是支付,第二条消息的状态是下单就会有问题了,没有下单就先支付了?消息顺序问题是一个非常棘手的问题,比如:
kafka同一个partition中能保证顺序,但是不同的partition无法保证顺序。
rabbitmq的同一个queue能够保证顺序,但是如果多个消费者同一个queue也会有顺序问题。
如果消费者使用多线程消费消息,也无法保证顺序。
如果消费消息时同一个订单的多条消息中,中间的一条消息出现异常情况,顺序将会被打乱。
还有如果生产者发送到mq中的路由规则,跟消费者不一样,也无法保证顺序。
2.5 消息堆积
如果消息消费者读取消息的速度,能够跟上消息生产者的节奏,那么整套mq机制就能发挥最大作用。但是很多时候,由于某些批处理,或者其他原因,导致消息消费的速度小于生产的速度。这样会直接导致消息堆积问题,从而影响业务功能。
这里以下单开通会员为例,如果消息出现堆积,会导致用户下单之后,很久之后才能变成会员,这种情况肯定会引起大量用户投诉。
2.6 系统复杂度提升
这里说的系统复杂度和系统耦合性是不一样的,比如以前只有:系统A、系统B和系统C 这三个系统,现在引入mq之后,你除了需要关注前面三个系统之外,还需要关注mq服务,需要关注的点越多,系统的复杂度越高。mq的机制需要:生产者、mq服务器、消费者。
有一定的学习成本,需要额外部署mq服务器,而且有些mq比如:rocketmq,功能非常强大,用法有点复杂,如果使用不好,会出现很多问题。有些问题,不像接口调用那么容易排查,从而导致系统的复杂度提升了。
3 如何解决这些问题?
mq是一种趋势,总体来说对我们的系统是利大于弊的,难道因为它会出现一些问题,我们就不用它了?
那么我们要如何解决这些问题呢?
3.1 重复消息问题
不管是由于生产者产生的重复消息,还是由于消费者导致的重复消息,我们都可以在消费者中通过做幂等设计来解决。
一种解决方法是增加一张消费消息表,来解决mq的这类问题。消费消息表中,使用messageId做唯一索引,在处理业务逻辑之前,先根据messageId查询一下该消息有没有处理过,如果已经处理过了则直接返回成功,如果没有处理过,则继续做业务处理。
3.2 数据一致性问题
数据一致性分为:
强一致性
弱一致性
最终一致性
而mq为了性能考虑使用的是最终一致性,那么必定会出现数据不一致的问题。这类问题大概率是因为消费者读取消息后,业务逻辑处理失败导致的,这时候可以增加重试机制。
重试分为:同步重试 和 异步重试。
有些消息量比较小的业务场景,可以采用同步重试,在消费消息时如果处理失败,立刻重试3-5次,如何还是失败,则写入到记录表中。但如果消息量比较大,则不建议使用这种方式,因为如果出现网络异常,可能会导致大量的消息不断重试,影响消息读取速度,造成消息堆积。
而消息量比较大的业务场景,建议采用异步重试,在消费者处理失败之后,立刻写入重试表,有个job专门定时重试。
还有一种做法是,如果消费失败,自己给同一个topic发一条消息,在后面的某个时间点,自己又会消费到那条消息,起到了重试的效果。如果对消息顺序要求不高的场景,可以使用这种方式。
3.3 消息丢失问题
不管你是否承认有时候消息真的会丢,即使这种概率非常小,也会对业务有影响。生产者、mq服务器、消费者都有可能会导致消息丢失的问题。
为了解决这个问题,我们可以增加一张消息发送表,当生产者发完消息之后,会往该表中写入一条数据,状态status标记为待确认。如果消费者读取消息之后,调用生产者的api更新该消息的status为已确认。有个job,每隔一段时间检查一次消息发送表,如果5分钟(这个时间可以根据实际情况来定)后还有状态是待确认的消息,则认为该消息已经丢失了,重新发条消息。
这样不管是由于生产者、mq服务器、还是消费者导致的消息丢失问题,job都会重新发消息。
消息多次丢失处理方式:
1. 重试几次仍然失败,则关闭消费者
2. 将失败记录发送到死信队列,然后处理下一条记录
3.4 消息顺序问题
消息顺序问题是我们非常常见的问题,我们以kafka消费订单消息为例。订单有:下单、支付、完成、退货等状态,这些状态是有先后顺序的,如果顺序错了会导致业务异常。
解决这类问题之前,我们先确认一下,消费者是否真的需要知道中间状态,只知道最终状态行不行?
其实很多时候,我真的需要知道的是最终状态,这时可以把流程优化一下:
这种方式可以解决大部分的消息顺序问题。
但如果真的有需要保证消息顺序的需求。订单号路由到不同的partition,同一个订单号的消息,每次到发到同一个partition。
生产者保证顺序:根据订单key,将同一订单的消息放入同一partition
消费者保证顺序:对顺序要求高的情况下单线程消费;
多线程下,由于消费数据线程不安全,所以一个线程负责拉去数据,其余线程负责消费,为保障全局顺序,应该为消息创建一个全局id属性,可以存到redis里,线程按照id顺序执行,同时为了避免数据丢失,offset不应自动提交,由一个服务定时去拉取多线程offset消费情况,取最大的连续offset提交,这样可能会有重复消息,因此要保证操作幂等性;
三种多线程并行消费方式
1. 一个partition由一个线程去消费,消费并发度由partition数量决定,消息顺序消费
2. 根据消息的key消费,一种key的消息由一个消费者去消费(一个partition可能包含多种key),消息顺序消费
3.无需关心顺序问题,最大程度并行消费
3.5 消息堆积
如果消费者消费消息的速度小于生产者生产消息的速度,将会出现消息堆积问题。
那么消息堆积问题该如何解决呢?
这个要看消息是否需要保证顺序。
如果不需要保证顺序,可以读取消息之后用多线程处理业务逻辑。
这样就能增加业务逻辑处理速度,解决消息堆积问题。但是线程池的核心线程数和最大线程数需要合理配置,不然可能会浪费系统资源。
如果需要保证顺序,可以读取消息之后,将消息按照一定的规则分发到多个队列中,然后在队列中用单线程处理。