笔者redis学习相关笔记如下: 欢迎阅读
| 内容 | 连接 |
|---|---|
| Redis高性能 | https://blog.csdn.net/ylx1066863710/article/details/111468140 |
| Redis持久化 | https://blog.csdn.net/ylx1066863710/article/details/111475668 |
| redis高可靠之redis主从模式 | https://blog.csdn.net/ylx1066863710/article/details/111768608 |
| Redis高可靠之哨兵集群 | https://blog.csdn.net/ylx1066863710/article/details/111814997 |
| redis缓存雪崩、击穿、穿透 | https://blog.csdn.net/ylx1066863710/article/details/111826713 |
下面主要介绍RocketMQ的作用与场景
RocketMQ的作用与场景
异步
异步这个名次不多做解释, 如果不清楚可以google一下哈. 下面列一个笔者实际使用过程中的例子:
曾经在做某个签约项目中除了正常提交签约资料外, 还需要设置费率, 此时可用同步或者异步两种方式实现微信费率的设置, 最终笔者选择使用异步费率设置, 原因是同步设置费率会阻塞主签约流程, 可能因为费率设置不成功而导致签约失败. 异步设置费率会有一个问题, 使用MQ异步设置费率失败将会导致用户资损. 为了解决这个问题, 笔者采用MQ消息重试机制,如果失败会重试16次. 重试16次依然没有设置成功则通过监控报警人工介入.
解耦
- 目前规模大一点公司都是采用微服务部署, 将上下游链路解耦.例如: 在交易域中, 会依赖商品、营销(预占和核销)、库存、会员、支付、履约、结算等域, 为了解决域之间的强耦合, 可以采用MQ消息将上下游链路进行解耦. 例如, 支付成功后, 可以采用两种发送通知下游链路: 同步和异步;
同步
优点
可以保证上下游单据状态的一致性.
缺点
2. rt升高, 系统的吞吐量降低;
3. 主流程依赖下游链路, 一旦某一个链路出问题, 将导致主流程异常. 如, 下游部分域之间本不相互依赖, 如果采用同步操作则每个域都需要增加回滚接口, 如营销核销成功、下游的库存扣减失败, 此时后续履约、结算将被中断, 另外需要新增营销核销回滚接口. 这样做代价太大, 一旦影响某个域异常都将影响主流程.
异步
优点
- 上下游之间解耦, 交易域只需要关心本域主流程, 下游业务感知;
- 系统rt不会受下游链路的影响, 系统吞吐量较高;
缺点
- 上下游单据无法保证强一致性, 只能保证最终一致性.保证最终一致性的方法很多, 例如
- rocketMQ自身支持分布式事务消息: 下文将会具体描述;
- 通过异步对账来校验域之间上下游一致性: 如营销域, 营销域通过上游的业务单据核销营销相关的优惠券等, 可以采用定时任务每天定时拉取核销失败营销单据与上游业务单据比较, 如果异常报警, 然后人工介入.
- 增加系统复杂性;
- 系统响应时长将变长;
限流
- 主要是避免海量数据同时打到下游, 导致下游负载过高.
设计思路是，使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。
例如秒杀系统:
- 网关在收到请求后，将请求放入请求消息队列；
- 后端服务从请求消息队列中获取 APP 请求，完成后续秒杀处理过程，然后返回结果。
秒杀开始后，当短时间内大量的秒杀请求到达网关时，不会直接冲击到后端的秒杀服务，而是先堆积在消息队列中，后端服务按照自己的最大处理能力，从消息队列中消费请求进行处理。
对于超时的请求可以直接丢弃，APP 将超时无响应的请求处理为秒杀失败即可。 运维人员还可以随时增加秒杀服务的实例数量进行水平扩容，而不用对系统的其他部分做任何更改。
这种设计的优点是：能根据下游的处理能力自动调节流量，达到“削峰填谷”的作用。但这样做同样是有代价的：
- 增加了系统调用链环节，导致总体的响应时延变长。
- 上下游系统都要将同步调用改为异步消息，增加了系统的复杂度。
那还有没有更简单一点儿的流量控制方法呢？如果我们能预估出秒杀服务的处理能力，就可以用消息队列实现一个令牌桶，更简单地进行流量控制。令牌桶控制流量的原理是：单位时间内只发放固定数量的令牌到令牌桶中，规定服务在处理请求之前必须先从令牌桶中拿出一个令牌，如果令牌桶中没有令牌，则拒绝请求。这样就保证单位时间内，能处理的请求不超过发放令牌的数量，起到了流量控制的作用。
实现的方式也很简单，不需要破坏原有的调用链，只要网关在处理 APP 请求时增加一个获取令牌的逻辑。
令牌桶可以简单地用一个有固定容量的消息队列加一个“令牌发生器”来实现：令牌发生器按照预估的处理能力，匀速生产令牌并放入令牌队列（如果队列满了则丢弃令牌），网关在收到请求时去令牌队列消费一个令牌，获取到令牌则继续调用后端秒杀服务，如果获取不到令牌则直接返回秒杀失败。
延迟消息
延迟消息使用场景很多, 例如在交易域中的超时关单消息即是通过延迟消息实现, 延迟消息的原理见下一章.