一个订单系统
架构和业务
怎么计算？
注册用户
千万
活跃用户
百万
访问频率
用户习惯
机不离手 （抖音）
购物 垂直（京东） 逛 （淘宝）
频率 时间段 时长
日新增订单
几十万
根据线上统计数据推算系统负载
晚上下班后 8点左右 到凌晨 11点左右 大概 6个小时
用户100万
大部分动作是 浏览商品，搜索商品。主要和商品系统和评论系统交互。读 高读
对订单系统而言 主要访问量是下单，订单查询，订单详情，偶尔退款 。
每天 50万订单 大概百万次下单操作和订单查询等操作
一共百万操作分摊到4个小时，每秒钟大概几十个请求。
能不能这么算？不能。
晚上六点开始慢慢增加，到9点到10点是个高峰，访问量最大，然后慢慢回落。
每天限时限量购的特价商品，会在晚上某个是时间点售卖。
怎么算？
要按照晚上购物最活跃的时候 高峰来算。
根据线上接口统计 最活跃的时候 最高峰每秒会有超过2000的请求，最高负载。
Tomcat mysql 容量规划
术语
一、QPS/TPS
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特点的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用时间和完成的事务个数。
Tps即每秒处理事务数，包括了
a、用户请求服务器
b、服务器自己的内部处理
c、服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是N；
Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成的Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，可计入到Qps之中
例如：访问一个页面会请求三次，一次放，产生一个T，产生3个Q
二、系统吞吐量
一个系统的吞吐量（承载能力）与request对CPU的消耗，对外部接口、IO等等紧密关联。单个request对CPU消耗越高，外部系统接口、IO影响数度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数：系统同时处理的request/事务数
响应时间：一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系
QPS（TPS）= 并发数/平均反应时间或者并发数=QPS*平均响应时间
例；一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登陆签到系统进行签到。公司员工为1000人，平均每个员工登陆签到系统的时间为5分钟。可以用下面的方法计算。
QPS = 1000/（30*60）事务/秒
平均响应时间为 = 5*60秒
并发数 = QPS*平均响应时间 = 1000/（30*60）*（5*60）=166.7
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都要一个相对极限值，在应用场景访问压下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其他消耗导致性能下降。
三、吞吐量的计算公式
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
https://cloud.tencent.com/developer/article/1579814
总结
系统面临的问题
系统压力
2000每秒TPS怎么抗？
服务器有几台？
6台
每台抗200-300请求
服务器tomcat配置是什么？
4核8G
每秒抗几百问题不大。
数据库有几台？什么配置
16核32G
每秒抗3-4千问题不大。
什么是系统压力？系统线上部署的机器情况和数据库的机器情况
然后对各种机器配置大概能抗多少并发有个基本了解。
用户越来越多，访问量越来越多，订单越来越多，系统怎么办？ 业务问题和技术挑战
技术方案
加订单服务节点? 学了微服务了 扩展服务节点 单点故障
加缓存? Redis
加消息队列?
分库分表? 分布式存储
...
核心流程问题
下单流程
下单，支付，支付完成。
支付完成要干很多事情 更新订单状态，更新积分，发优惠券，发红包，发短信通知给用户，通知配送系统。
全部执行 需要多长时间？可能需要1-2秒，高峰的时候可能时间更长。
问题？1到2秒怎么来的？在公司开发项目的时候，对接口的响应时间是有要求的。20ms-40ms
带来什么影响？
性能不好，界面上整个小圈圈转啊转，用户烦躁，用户体验不好。
取消订单流程
把库存还回去，把积分还回去，把优惠券还回去，把红包还回去，给用户发短信，通知配送系统
带来什么影响？
性能不好，界面上整个小圈圈转啊转，用户烦躁，用户体验不好。
退款问题
别的都成功了，第三方支付系统退款失败。可能三方系统出问题了，也可能网络出现故障调用失败。
带来什么影响？
不止性能不好，货不要了，钱没了，用户不止烦躁。投诉，下次再也不来。网上曝光。比体验不好要更加严重。
用户下单后一直不付款
已经跳到支付了，我们系统的库存锁定了，然后突然来个电话，一直没支付。我们订单系统会有一条
待支付的订单记录。
怎么办？
搞个后台线程，扫待付款的订单，超过1个小时没支付，把订单状态改为已关闭，释放库存。中间状态 补偿
问题？
订单量太大，数据库有几十万待支付的订单，我们的线程扫啊扫，效率太低。
延迟队列怎么用?
系统耦合
什么叫耦合？
配送系统定义了一个接口 刚开始 定义3个参数，后来改为需要传递5个参数，他的新接口上线，你不改就报错，必须改，你需要配合新接口进行测试上线。要动一起动，要静一起静 这就是系统间的耦合。
订单系统有没有和三方物流系统，短信平台耦合？
订单是和配送系统耦合，和消息系统耦合，配送系统和三方物流系统耦合，消息系统和三方短信平台耦合，订单系统也间接耦合了三方物流系统和三方短信平台。
和三方系统耦合有什么问题？
我们的系统可控，自己内部人写的，可优化，知道如何运行，知道问题在哪，可优化，可解决。
三方系统不可控，完全黑盒。 黑盒测试 白盒测试
有时候20ms 有时候200ms，有时候正常，有时候失败。他慢我们也跟着慢，他失败我们也跟着失败。
他不稳定不可控，导致你的系统不稳定不可控。
用户不关心你用没用三方系统，三方的不可控有可能会伤害用户。
大数据要来查你的订单数据
每天大量用户访问你的app ，积累下来的浏览行为，访问行为，交易行为，这个数据有点大，这就可以称为大数据。 BI
大数据团队要数据干什么？
用户行为报表
订单分析报表
商品推荐
数据怎么给？
直接从订单数据库查？复杂查询 搞个几百行的大sql。 复杂查询和简单查询的区别?
咔，把表锁死了。甚至搞挂了。
查询慢 把数据库性能给降低。cpu累，io累。
导致订单系统的操作性能下降。甚至失败。
大促
双11 618
系统访问量增加10倍 每秒2W
思考
技术学习要放到真实的环境中，去解决相应的问题，按照一个一个知识点去学容易忘
自己系统的架构设计业务流程和负载情况？
自己负责的系统不太行，没什么用户量，业务简单，没有什么技术难点？体现不出自己高超的技术？
把你的系统用户量扩大100倍 1000倍
你负责的系统核心流程性能如何？每个步骤要耗费多长时间？
哪个关键步骤会失败？如果失败了，系统会怎么样？如何补偿？
有没有和别的系统耦合，有没有和三方系统交互？
跨系统的数据访问是否存在？
系统会不会有流量洪峰？
对用户的影响是什么？
有多大的访问量？
有多大的数据量？
如何抗住这么大的压力？
有哪些技术难题？
怎么解决？
去做，去思考，去总结。
总结
消息中间件
前置知识
同步
用户发起一个请求 A收到请求，接着A调用B，直到B返回了，A才能返回结果给用户。
异步
用户发起一个请求 A收到请求，接着A给B 发个消息，B什么时候获取消息，有没有获取消息，什么时候执行，A不管 ，A直接返回结果给用户。
消息中间件
前置知识
同步
用户发起一个请求 A收到请求，接着A调用B，直到B返回了，A才能返回结果给用户。
异步
用户发起一个请求 A收到请求，接着A给B 发个消息，B什么时候获取消息，有没有获取消息，什么时候执行，A不管 ，A直接返回结果给用户。
消息中间件是什么？
一个系统，独立部署，可以帮助我们系统之间通过发消息和收消息来进行异步调用。
异步化提升性能
同步调用 A系统和B系统都干完活，50+300 350ms 用户要等待 350ms。
加入消息中间件后异步调用 50+10 60ms 350-50 用户等待 60ms 快了 290ms 这么多。厉不厉害。 RT
插播小知识
人生匆匆，孤独却不漫长 我们要好好学习 天天向上。
降低系统耦合
耦合在一起，B出了故障，可能会影响A。
加入MQ 解耦 B出了故障 对A 没有影响。A也感觉不到。
流量削峰
A能扛住，B扛不住，B奔溃。夯住
加入MQ ，流量洪峰被MQ 抗下来，存储到MQ 的磁盘，系统B慢慢消费消息，慢慢处理
思考
MQ 出了故障怎么办？
MQ 怎么能抗住高并发？
MQ 怎么存储数据？
MQ 会不会丢数据？
你自己负责的系统如果引入MQ，能不能提升性能?，能不能降低耦合度?，能不能应对流量洪峰?
技术选型
常用MQ的优缺点 找合适的。
怎么定义合适呢？
性能能不能满足要求，功能能不能满足要求？
总结
架构原理
特性
高并发
集群化部署 多个broker 分摊并发压力
海量消息
分布式存储 把数据分散到多台机器来存储
可伸缩
可以在集群中加入或者减少broker 线性扩缩容
高可用
NameServer
集群化部署 每台机器都有完整的路由信息
Broker
集群化部署 主从架构和多副本机制
挂了slave 对集群没太大影响
挂了master 基于Dledger 实现自动slave切换为master 选举机制
生产者
集群化部署
消费者
集群化部署
核心组件
NameServer
高可用方案
集群部署 Peer-to-Peer 点对点 节点之间相互独立相互平等 互不通信
注册
broker如何注册？ 全部注册 注册到所有的NameServer，每个NameServer 都会有一份集群中所有Broker信息
获取
生产者和消费者如何获取broker信息？ 主动从NamerServer拉取 推和拉? 实现方式和实时性
故障感知
Broker挂了，NameServer如何感知？心跳
存储信息
Broker Topic Queue 信息和关系
思考
没有这个NameServer行不行？
不同注册中心的实现 Zookeeper，Nacos zk kafka 注册中心是zk , rocket-mq 注册中心是 name-server
Broker
高可用方案
两种角色
Master Slave （Leader Follower）
如果slave挂了有什么影响 ？ 有一点影响 影响不大
如果master挂了有什么影响 ？ 消息写入和拉取都有影响 读写分离 mysql
slave会切换为master么？4.5 之前 不能 4.5 之后 Dledger 自动故障切换 选举机制
Dledger技术
Raft协议
至少一个Master两个Slave，作为一个分组来运行。一旦Master宕机，从剩余的两个Slave中选举出来一个新的作为Master
选举机制
第一轮
三台Broker机器启动的时候，他们都会投票自己作为Leader，然后把这个投票发送给其他Broker。
B1是投票给自己，B2是投票给自己，B3是投票给自己，他们都把自己的投票信息发送给了别人。
都在投票给自己，第一轮选举失败。
第二轮
接着每个Broker随机时间睡一会，B1睡 2秒，B2休眠5秒，B3睡3秒。
过了一会
B1先醒，直接会继续投票给自己，并且发送自己的选票给别人。
B3休眠3秒后醒了，发现B1已经发送来了一个选票是投给B1自己的，此时他自己没投票，尊重别人的选择，把票投给B1了，同时把自己的投票发送给别人。
B2醒了，收到B1投票给B1自己，收到B3也投票给了B1，此时自己是没投票，尊重别人的选择，直接就投票给B1，并且把自己的投票发送给别人。
此时所有人都会收到三张投票，都是投给B1的，那么B1就会当选为 Master
第二轮选举成功
Raft协议中选举leader算法的简单描述 核心是 随机睡会 睡觉耽误事
大多数同意大伙就同意（机器数量 / 2） + 1就是大多数。
消息同步
Master和Slave如何同步？
1 Master-Slave 模式 Slave从Master拉取 pull模式 不用了
2 Dledger模式 Dledger管理CommitLog 两阶段提交2PC raft
一个是uncommitted阶段，一个是commited阶段
Leader 收到一条消息之后，会标记为uncommitted状态，把这个uncommitted数据发送给Follower。
Follower 收到uncommitted消息后，必须返回ack给Leader，Leader 收到超过半数的Follower ack之后，消息更新为committed状态。
Leader发送commited消息给Follower，Follower把消息更新为comitted状态。
消息同步
Master和Slave如何同步？
1 Master-Slave 模式 Slave从Master拉取 pull模式 不用了
2 Dledger模式 Dledger管理CommitLog 两阶段提交2PC raft
一个是uncommitted阶段，一个是commited阶段
Leader 收到一条消息之后，会标记为uncommitted状态，把这个uncommitted数据发送给Follower。
Follower 收到uncommitted消息后，必须返回ack给Leader，Leader 收到超过半数的Follower ack之后，消息更新为committed状态。
Leader发送commited消息给Follower，Follower把消息更新为comitted状态。
异步发送
不会等待MQ返回结果代码继续执行
当MQ返回结果会调用你的回调函数 成功 onSuccess 失败 onException
单向消息发送
不关心返回结果
Topic
Topic 是什么 mq的核心数据模型 一个数据集合，不同类型的数据放到不同的topic，
如订单的topic，支付的topic
topic数据集合怎么在broker集群里存储 分布式存储
流程
和nameserver建立tcp长链接
定时拉取最新路由信息
集群有哪些broker
集群里有哪些topic
每个topic存储在哪些broker
根据负载均衡算法选取一个台broker
轮询
hash
...
建立长连接 发送消息
生产者一定是投递消息到Master broker
高可用
broker 挂了 容错机制
重试与Broker规避
sendLatencyFaultEnable 开启规避
自动容错机制 比如某次访问一个broker超时，暂时跳过这个broker，过一段时间再访问。
消费者
消费模式
push
broker主动推送给消费者
pull
消费者主动拉
本质是一样的，都是消费者主动拉，消费者去broker拉消息，拉一批处理一批。处理完继续拉，实效很高。
请求挂起和长轮询机制 ，消费者请求broker ，broker 发现没有新消息，就会让请求线程挂起，歇一会，然后有个后台线程去扫描 看有没有新消息 如果有新消息了，把线程唤醒，然后把消息给你。
线程在中间件中的使用。
流程
消息拉取
和nameserver建立tcp长连接
找到自己要获取消息的topic在哪几台broker上
建立长连接
拉取消息
扩展
消费者到一个broker拉取MessageQueue3 上的消息，之前没有拉过，所以从第一条信息开始拉
broker 找到MessageQueue3 对应的 consumeQueue3 从里面找到第一条信息的偏移量 offsite ，根据offsite 去commitlog 读取这条消息返回给消费者。
Ack
消费者处理完消息以后 返回 CONSUME_SUCCESS 这个常量 ，提交当前的消费进度，broker存储起来。下次消费者再拉取，就会从这个位置往后拉。
消费者扩缩容 Rebalance 负载重平衡机制
订单的topic 4 Q 两个消费者 A B
A MessageQueue0 MessageQueue1
B MessageQueue2 MessageQueue3 m2 m1 B 处理 m1 更新数据库, ack 给mq 准备给mq ack的时候 突然宕机了
B宕机 缩
A MessageQueue0 MessageQueue1 MessageQueue2 MessageQueue3 m2 m1
扩充C 扩
A MessageQueue0
B MessageQueue2 MessageQueue0
C MessageQueue3
D MessageQueue1
E 没活可干
F 没活可干
闭环 全链路的解决方案
1 加messageQueue方案合不合理,
2 加Topic 方案(方案问题) ? 怎么加 (落地问题)?
3 加消费者 加对列 ?
consumeQueue3 文件几MB?
面试题 消息重复消费？消息为什么会重复？B处理消息处理完业务逻辑，突然宕机 还没上报给broker 自己的消费进度，然后被A平衡过去了，A 会重复消费。
重复消息怎么处理？幂等。如何处理幂等？
不丢失 p(生产者) -> q(broker) -> c (消费者)
高可用
broker挂了重试与Broker规避
消费者组
配送 a_group 2台机器 营销 b_group 3台机器
订单发送消息 两个组都能消费到这条消息
集群模式
a_group 2台机器谁获取到？只有一台能获取到。
广播模式
b_group 3台机器谁获取到？每台能获取到。
总结
Topic 的多个messgeQueue 分散到多个broker上，每个broker 上，一个MessageQueue 对应一个ComsumeQueue，磁盘上多个，先理解为 一对一。
一个broker 上 所有的topic 和 message 消息都写入到一个 CommitLog 。1G 满了换下一个 顺序写
小扩展 kafka 是 一个topic 一个 文件 （顺序写） 考虑个问题 topic 多了以后 会退化成 随机写。
ConsumeQueue 存储属于MessageQueue 文件中的物理地址 ，一个偏移量。
一个topic对应多个MessageQueue 消费者组的多台机器如何消费？均匀分配。
一个messageQueue 只能被一个消费机器处理，消费机器可以处理多个messgaeQueue的消费。
核心底层原理
高性能网络模型
基于netty 构建
短连接
建立连接 发送请求 接收响应 断开连接
长连接
建立连接 发送请求 接收响应 发送请求 接收响应 发送请求 接收相应
建立好连接后 ，不停的发送请求和接收相应，连接不会断开。存在时间长 长连接。
TCP长连接
按照TCP协议建立的长连接。 什么是协议？对暗号。天王盖地虎 宝塔镇河妖 网络粘包和黏包
Reactor主线程 负责和生产者，消费者等建立长连接 SocketChannel
Reactor线程池并发监听连接是否有请求到达
Worker线程池 并发对多个请求进行预处理
业务线程池 并发对具体的业务比如磁盘的读写操作
多路复用
各干各的，互不影响
思考
这是什么设计模式？ 观察者模式 责任链模式
自己去了解下 NIO BIO AIO TCP Channel SocketChannel Selector Poll Epoll 多路复用等网络的相关基础知识。
上下文切换
高性能文件读写
传统文件IO操作
Mmap + page cache
解决多次拷贝问题。
CommitLog顺序写 + OS cache + 异步刷盘
内存映射 刚开始创建的时候，没有拷贝任何数据，数据还在磁盘，映射的是地址
Mmap 文件映射对文件大小有限制 1.5-2 G 所有commitlog 搞个1G
写数据 先写到pagecache，然后由os线程异步刷盘到磁盘，一次拷贝
读数据 pagecache 有么，有直接从pagecache 读 。没有从磁盘读 一次拷贝
零拷贝
https://zhuanlan.zhihu.com/p/447890038
pagecache 在加载数据的时候会把数据临近的其他的数据块也加载到pagecache。
使用一个数据，下次大概率会使用它附近的数据
6 5 4 3 2 1
扩展
数据预读 局部性原理
时间 如果一个数据正在被访问，那么在近期它很可能还会被再次访问。
空间 如果一个数据的位置被访问，那么将来他附近的位置的数据也会被访问。
madvise https://www.cnblogs.com/wlzy/p/10665472.html
局部性原理和磁盘预读
https://www.jianshu.com/p/d689f806c745
https://blog.csdn.net/caohao0591/article/details/104746150
思考
对高可用的理解？NameServer， peer-to-peer Broker 选举机制 raft 睡觉
分布式的理解？ 分布式存储 分片机制 Topic 和 MessageQueue 的关系 kafka是怎么实现的?
数据一致性的理解？ 和分布式事务的关系 raft 2PC 3PC TCC
Broker写入磁盘的怎么保障高性能？ Mmap 刷盘机制 顺序写
主动思考 举一反三
扩展知识
事务处理
http://icyfenix.cn/architect-perspective/general-architecture/transaction/
RocketMQ 的存储模型
https://cloud.tencent.com/developer/article/2229035
https://blog.csdn.net/beiduofen2011/article/details/121309530
分布式共识算法
http://icyfenix.cn/distribution/consensus/
https://www.tpvlog.com/article/66
http://thesecretlivesofdata.com/raft/
时间轮算法
https://zhuanlan.zhihu.com/p/478935723
面试题
如何进行消息队列的选型？技术选型
引入消息队列后如何保证可用性，高可用原理
重复消息怎么处理？重复的原理，重复的处理
如何保证消息不丢失？消息零丢失方案 Ack 刷盘机制 os-cache 同步刷盘，异步刷盘
如何保证消息的顺序性？topic 和 messgequeue 机制
系统突然积压了好多消息，如何处理？ 扩容
如果你来设计一个消息中间件，如何设计？ 架构原理
通用解决方案
消息积压
10000W 堵死在mq 里 了怎么处理? 事前 事中 事后 复盘 (分锅) 方法论 赋能
消费者的 存储 挂掉 es 一直没有ack.
1 多启动broker 错误的
2 增加消费者 扩容 topic 和 messageQueue (consumeQueue)的关系 默认4个 两台消费者 一人两个 , 5台消费者?有用 没用 ,
1 扩大消费者 原来是一个消费者消费两个Q ,增加两个消费者 消费速度增加了一倍 小红花一枚
2 增加 MessageQueue 扩容 ,怎么重平衡, Topic 4 Q, 4-->16 支持? 支持 怎么实现,不支持 怎么办?
3 转移,新的消息发送到新的topic ,然后原来积压的慢慢, 先让他不堵 小红花一枚
新上一批 过去包含业务的消费者停掉, 先搞一批消费者 转发
1 新申请机器 topic 40 messageQueue , 消息转发到 新的这个40个Q
1 申请新的消费者,40个消费者 40个Q , 考虑新起来的es 能否扛着这么大的并发量 es的扩缩容 .
后续动作 ,对MQ 进行了监控 如果消息积压到一定程度 就系统报警 打电话发短信相关负责人
转移消息
消息迁移
老系统 用的rabbit-mq, 技术升级 换rocket-mq, 保证系统不长时间停机(不影响现有的业务)情况下,如何平滑迁移
rabbit-mq --> rocket-mq
现在线上跑着一套正常的业务 rabbit-mq ,我们部署了一套rocket-mq
1 本地测,测试环境,灰度(灰度方案 ) ,逐步的替换topic ,打日志,看监控, 逐步迁移.
2 读写分离 优点 快,分摊压力,rocket-MQ slave 不能写消息 缺点 一致性问题
3 双写 VS 单写 双写优点 对比 方便观察 测试. AB-test 留存率或者转化率
rabbit-mq 一条消息
rocket-mq 一条消息
生产者修改代码 两个都发,写日志,方便观察,
观察 rocket-mq 表现 tps等一些指标
消费者不能同时消费, 原来的rabbit 继续跑真实的业务,rocket-mq 消费完后 业务逻辑是一样的,存储 临时数据库 数据对比 打日志. 搞了一段时间 , 消息数据 过期时间 默认7天 7天观察 存正式库 把rabbit 下掉, 生产者也改掉
延迟队列
延迟消费 延迟 反义 正常 rabbit-mq TTL-死信队列
生产者-Q-消费者
长时间30分钟 未支付 时间限制 库存锁定 30分钟 1个小时 订单数据未支付, 更新订单的状态, 超过了30分钟,未支付的订单 中间状态 待支付 完成状态 订单完成 订单取消
定时任务 分布式job job的状态. xx-job ,扫表 (定位数据) 业务补偿 方案可以用 缺点? 数据量大 怎么扫 ? 分时间段 取余
支付超时
支付失败
顺序消息
有顺序的消息
解决方案
局部有序
消息不丢失
局部不丢
事务消息
幂等
消息丢失的问题?
师傅抢单成功,服务完成, 我们系统要师傅发一个红包? 红包没收到
订单服务 生产者 消息丢了 ?
Mq 消息丢了?
营销服务 消费者 消息丢了?
事务消息底层原理
RMQ_SYS_TRANS_HALF_TOPIC 自己去了解
https://blog.csdn.net/usagoole/article/details/126504592
幂等
为什么会有重复消息?
Rebalance 重平衡
重试 实际发送成功了,mq 收到消息,响应的时候 生产者没有收到,失败 又发了一遍.
重复消费
rocket-mq 为什么不解决这个问题 ? 太难解决 架构设计的妥协 tradoff ,交给业务来解决.
场景
一个订单 发红包 别发多 公司损失
https://baijiahao.baidu.com/s?id=1696481470162670700&wfr=spider&for=pc
怎么解决?
两种场景 创建 更新(删除) CRUD
1 给数据库搞个唯一的标识,处理过就不处理了. 根据唯一主键更新 ,插入 主键冲突
2 本地搞个静态变量 ? 根据变量去判断 不行 分布式场景
3 redis记一下 ? 需要处理结果和redis 保持一致, 缓存一致性 (复杂了) redis 数据丢失问题 .
4 MQ API 你可以去查, 消息id 会不会唯一 , 怎么保证唯一 (分布式id生成器？ 雪花算法？）
https://blog.csdn.net/zhuqiuhui/article/details/103003733
https://blog.csdn.net/weixin_38277138/article/details/130099097
奥卡姆剃刀原理 如无必要,勿增实体
