消息队列–消息堆积处理方案
如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
- 关于这个事儿,我们一个一个来梳理吧,先假设一个场景,我们现在消费端出故障了,然后大量消息在mq里积压,现在事故了,慌了
如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
mq的作用很简单,削峰填谷。以电商交易下单的场景来说,正向交易的过程可能涉及到创建订单、扣减库存、扣减活动预算、扣减积分等等。每个接口的耗时如果是100ms,那么理论上整个下单的链路就需要耗费400ms,这个时间显然是太长了。
在默认情况下,用户请求数据时,会先在缓存(Redis)中查找,若没找到即缓存未命中,再在数据库中查找,数量少可能问题不大,可是一旦大量的请求数据(例如秒杀场景),缓存没有命中的话,就会将请求全部转移到数据库上,造成数据库的压力剧增,就有可能导致数据库的崩溃。
网络安全中的也有人恶意使用这种手段进行攻击称为洪水攻击。
在指定时间间隔后,将内存中的数据快照写入硬盘,在恢复的时候,直接读取快照文件,进行数据的恢复。
默认情况下,redis将数据库快照保证在名字为 dump.rdb 的二进制文件中。文件名可以在配置文件中进行自定义。
Redis 事务本质:一组命令的集合。
—————– 队列 set set set 执行 ——————-
事务中每条命令都会被序列化,执行过程中按照顺序执行,不允许其他命令进行干扰。
- 一次性
- 循序性
- 排他性
- Redis 事务没有隔离级别的概念
- Redis 单条命令是保证原子性的,但是事务不保证原子性