本篇主要内容如下:
我们都在讨论分布式,特别是面试的时候,不管是招初级软件工程师还是高级,都会要求懂分布式,甚至要求用过。传得沸沸扬扬的分布式到底是什么东东,有什么优势?
看过火影
的同学肯定知道漩涡鸣人
的招牌忍术:多重影分身之术
。
过程和心得
:多个分身的感受和经历都是相通的。比如 A 分身去找卡卡西(鸣人的老师)请教问题,那么其他分身也会知道 A 分身问的什么问题。漩涡鸣人
有另外一个超级厉害的忍术,需要由几个影分身完成:风遁·螺旋手里剑
。这个忍术是靠三个鸣人一起协作完成的。这两个忍术和分布式有什么关系?
案例:
哨兵机制
,可以知道集群环境下哪台 Redis
节点挂了。Leader 选举机制
,如果某个节点挂了,会从 follower
中重新选举一个 leader 出来。(leader 作为写数据的入口,follower 作为读的入口)那多重影分身之术
有什么缺点?
讲到分布式
不得不知道 CAP
定理和 Base
理论,这里给不知道的同学做一个扫盲。
在理论计算机科学中,CAP 定理指出对于一个分布式计算系统来说,不可能通是满足以下三点:
BASE
是 Basically Available
(基本可用)、Soft state
(软状态)和 Eventually consistent
(最终一致性)三个短语的缩写。BASE
理论是对 CAP
中 AP
的一个扩展,通过牺牲强一致性来获得可用性,当出现故障允许部分不可用但要保证核心功能可用,允许数据在一段时间内是不一致的,但最终达到一致状态。满足 BASE
理论的事务,我们称之为柔性事务
。
将消息队列里面的消息分摊到多个节点(指某台机器或容器)上,所有节点的消息队列之和就包含了所有消息。
所谓幂等性就是无论多少次操作和第一次的操作结果一样。如果消息被多次消费,很有可能造成数据的不一致。而如果消息不可避免地被消费多次,如果我们开发人员能通过技术手段保证数据的前后一致性,那也是可以接受的,这让我想起了 Java 并发编程中的 ABA 问题,如果出现了 [ABA 问题](用积木讲解 ABA 原理 | 老婆居然又听懂了!),若能保证所有数据的前后一致性也能接受。
RabbitMQ
、RocketMQ
、Kafka
消息队列中间件都有可能出现消息重复消费问题。这种问题并不是 MQ 自己保证的,而是需要开发人员来保证。
这几款消息队列中间都是是全球最牛的分布式消息队列,那肯定考虑到了消息的幂等性。我们以 Kafka 为例,看看 Kafka 是怎么保证消息队列的幂等性。
Kafka 有一个 偏移量
的概念,代表着消息的序号,每条消息写到消息队列都会有一个偏移量,消费者消费了数据之后,每过一段固定的时间,就会把消费过的消息的偏移量提交一下,表示已经消费过了,下次消费就从偏移量后面开始消费。
坑:
当消费完消息后,还没来得及提交偏移量,系统就被关机了,那么未提交偏移量的消息则会再次被消费。
如下图所示,队列中的数据 A、B、C,对应的偏移量分别为 100、101、102,都被消费者消费了,但是只有数据 A 的偏移量 100 提交成功,另外 2 个偏移量因系统重启而导致未及时提交。
重启后,消费者又是拿偏移量 100 以后的数据,从偏移量 101 开始拿消息。所以数据 B 和数据 C 被重复消息。
如下图所示:
Set
操作天然幂等性,所以不用考虑 Redis 写数据的问题。
坑:
消息丢失会带来什么问题?如果是订单下单、支付结果通知、扣费相关的消息丢失,则可能造成财务损失,如果量很大,就会给甲方带来巨大损失。
那消息队列是否能保证消息不丢失呢?答案:否。主要有三种场景会导致消息丢失。
对于 RabbitMQ 来说,生产者发送数据之前开启 RabbitMQ 的事务机制channel.txselect
,如果消息没有进队列,则生产者受到异常报错,并进行回滚 channel.txRollback
,然后重试发送消息;如果收到了消息,则可以提交事务 channel.txCommit
。但这是一个同步的操作,会影响性能。
我们可以采用另外一种模式: confirm
模式来解决同步机制的性能问题。每次生产者发送的消息都会分配一个唯一的 id,如果写入到了 RabbitMQ 队列中,则 RabbitMQ 会回传一个 ack
消息,说明这个消息接收成功。如果 RabbitMQ 没能处理这个消息,则回调 nack
接口。说明需要重试发送消息。
也可以自定义超时时间 + 消息 id 来实现超时等待后重试机制。但可能出现的问题是调用 ack 接口时失败了,所以会出现消息被发送两次的问题,这个时候就需要保证消费者消费消息的幂等性。
事务模式
和 confirm
模式的区别:消息队列的消息可以放到内存中,或将内存中的消息转到硬盘(比如数据库)中,一般都是内存和硬盘中都存有消息。如果只是放在内存中,那么当机器重启了,消息就全部丢失了。如果是硬盘中,则可能存在一种极端情况,就是将内存中的数据转换到硬盘的期间中,消息队列出问题了,未能将消息持久化到硬盘。
解决方案
Queue
的时候将其设置为持久化。这个地方没搞懂,欢迎探讨解答。deliveryMode
设置为 2 。confirm
模式,可以重试发送消息。消费者刚拿到数据,还没开始处理消息,结果进程因为异常退出了,消费者没有机会再次拿到消息。
解决方案
ack
,每次生产者将消息写入消息队列后,就自动回传一个 ack
给生产者。ack
,告诉消息队列我处理完了。问题: 那这种主动 ack
有什么漏洞了?如果 主动 ack
的时候挂了,怎么办?
则可能会被再次消费,这个时候就需要幂等处理了。
问题: 如果这条消息一直被重复消费怎么办?
则需要有加上重试次数的监测,如果超过一定次数则将消息丢失,记录到异常表或发送异常通知给值班人员。
场景:Kafka
的某个 broker(节点)宕机了,重新选举 leader (写入的节点)。如果 leader 挂了,follower 还有些数据未同步完,则 follower 成为 leader 后,消息队列会丢失一部分数据。
解决方案
replication.factor
参数,值必须大于 1,要求每个 partition 必须有至少 2 个副本。min.insyc.replicas
必须大于 1,表示一个 leader 至少一个 follower 还跟自己保持联系。
坑:
用户先下单成功,然后取消订单,如果顺序颠倒,则最后数据库里面会有一条下单成功的订单。
RabbitMQ 场景:
RabbitMQ 解决方案:
Kafka 场景:
Kafka 解决方案:
消息积压:消息队列里面有很多消息来不及消费。
场景 1: 消费端出了问题,比如消费者都挂了,没有消费者来消费了,导致消息在队列里面不断积压。
场景 2: 消费端出了问题,比如消费者消费的速度太慢了,导致消息不断积压。
坑:比如线上正在做订单活动,下单全部走消息队列,如果消息不断积压,订单都没有下单成功,那么将会损失很多交易。
解决方案:解铃还须系铃人
坑:
RabbitMQ 可以设置过期时间,如果消息超过一定的时间还没有被消费,则会被 RabbitMQ 给清理掉。消息就丢失了。
解决方案:
坑:
当消息队列因消息积压导致的队列快写满,所以不能接收更多的消息了。生产者生产的消息将会被丢弃。
解决方案:
Purge Message
操作。在高频访问数据库的场景中,我们会在业务层和数据层之间加入一套缓存机制,来分担数据库的访问压力,毕竟访问磁盘 I/O 的速度是很慢的。比如利用缓存来查数据,可能5ms就能搞定,而去查数据库可能需要 50 ms,差了一个数量级。而在高并发的情况下,数据库还有可能对数据进行加锁,导致访问数据库的速度更慢。
分布式缓存我们用的最多的就是 Redis了,它可以提供分布式缓存服务。
Redis 可以实现利用哨兵机制
实现集群的高可用。那什么十哨兵机制呢?
sentinel
,中文名:哨兵
。
坑:
当主节点发生故障时,需要进行主备切换,可能会导致数据丢失。
主节点异步同步数据给备用节点的过程中,主节点宕机了,导致有部分数据未同步到备用节点。而这个从节点又被选举为主节点,这个时候就有部分数据丢失了。
主节点所在机器脱离了集群网络,实际上自身还是运行着的。但哨兵选举出了备用节点作为主节点,这个时候就有两个主节点都在运行,相当于两个大脑在指挥这个集群干活,但到底听谁的呢?这个就是脑裂。
那怎么脑裂怎么会导致数据丢失呢?如果发生脑裂后,客户端还没来得及切换到新的主节点,连的还是第一个主节点,那么有些数据还是写入到了第一个主节点里面,新的主节点没有这些数据。那等到第一个主节点恢复后,会被作为备用节点连到集群环境,而且自身数据会被清空,重新从新的主节点复制数据。而新的主节点因没有客户端之前写入的数据,所以导致数据丢失了一部分。
注意:缓存雪崩
、缓存穿透
、缓存击穿
并不是分布式所独有的,单机的时候也会出现。所以不在分布式的坑之列。
坑:
分库分表是一个运维层面需要做的事情,有时会采取凌晨宕机开始升级。可能熬夜到天亮,结果升级失败,则需要回滚,其实对技术团队都是一种煎熬。
坑:
分库分表看似光鲜亮丽,但分库分表会引入什么新的问题呢?
坑:
唯一 ID 的生成方式有 n 种,各有各的用途,别用错了。
UUID
唯一 ID。
B+
树节点到内存,插入记录后将整个节点写回磁盘,当记录占用空间很大的时候,性能很差。snowflake
(雪花算法):Twitter 开源的分布式 id 生成算法,64 位的 long 型的 id,分为 4 部分
UIDGenerator
算法。
Leaf-Snowflake
算法。
坑
:如何保证分布式中的事务正确执行,是个大难题。
应用场景:
缺点:
基本原理:
适用场景:
优势:
缺点:
基本原理:
RocketMQ
来实现消息事务。prepared
(预备状态,半消息),该消息无法被订阅。prepared
消息改为 commit
(提交事务消息),B 系统就可以订阅到消息了。prepared
的消息,回调 A 系统,让 A 系统告诉 MQ 本地事务处理得怎么样了,是继续等待还是回滚。Rollback
信号,丢弃消息。若执行本地事务成功,则 MQ 收到 Commit
信号。基本原理:
最大努力服务
会定时尝试重新调用系统 B,尽自己最大的努力让系统 B 重试,重试多次后,还是不行就只能放弃了。转到开发人员去排查以及后续人工补偿。分布式还有很多坑,这篇只是一个小小的总结,从这些坑中,我们也知道分布式有它的优势也有它的劣势,那到底该不该用分布式,完全取决于业务、时间、成本以及开发团队的综合实力。后续我会继续分享分布式中的一些底层原理,当然也少不了分享一些避坑指南。
参考资料: 美团的 Leaf-Snowflake 算法。 百度的 UIDGenerator 算法。 Advanced-java