diff --git a/README.md b/README.md index 03dcd9e..4eaa27d 100644 --- a/README.md +++ b/README.md @@ -218,6 +218,11 @@ - [42、你能说说一个TCC分布式事务框架的核心架构原理吗?](/docs/distributed-system/tcc-framework-principle.md) - [43、现有的TCC事务方案的性能瓶颈在哪里?能支撑高并发交易场景吗?如何优化?](/docs/distributed-system/tcc-high-concurrence.md) - [44、作业:如果对自己的系统核心链路落地TCC事务,应该如何落地实现?](/docs/distributed-system/work-tcc-landing-scheme.md) +- [45、你了解RocketMQ对分布式事务支持的底层实现原理吗?](/docs/distributed-system/rocketmq-transaction.md) +- [46、在搭建好的电商系统里,如何基于RocketMQ最终一致性事务进行落地开发?](/docs/distributed-system/rocketmq-eventual-consistency.md) +- [47、如果公司没有RocketMQ中间件,那你们如何实现最终一致性事务?](/docs/distributed-system/eventual-consistency.md) +- [48、作业:如果对自己的系统落地最终一致性事务,如何落地实现?](/docs/distributed-system/work-eventual-consistency.md) + ### 第二季-高并发 diff --git a/docs/distributed-system/eventual-consistency.md b/docs/distributed-system/eventual-consistency.md new file mode 100644 index 0000000..3507f35 --- /dev/null +++ b/docs/distributed-system/eventual-consistency.md @@ -0,0 +1,8 @@ + +其实也很简单,自己写一个可靠消息服务即可,接收人家发送的half message,然后返回响应给人家,如果Producer没收到响应,则重发。然后Producer执行本地事务,接着发送commit/rollback给可靠消息服务。 + +可靠消息服务启动一个后台线程定时扫描本地数据库表中所有half message,超过一定时间没commit/rollback就回调Producer接口,确认本地事务是否成功,获取commit/rollback + +如果消息被rollback就废弃掉,如果消息被commit就发送这个消息给下游服务,或者是发送给RabbitMQ/Kafka/ActiveMQ,都可以,然后下游服务消费了,必须回调可靠消息服务接口进行ack + +如果一段时间都没收到ack,则重发消息给下游服务 diff --git a/docs/distributed-system/images/rocketmq-transaction.png b/docs/distributed-system/images/rocketmq-transaction.png new file mode 100755 index 0000000..f282c64 Binary files /dev/null and b/docs/distributed-system/images/rocketmq-transaction.png differ diff --git a/docs/distributed-system/rocketmq-eventual-consistency.md b/docs/distributed-system/rocketmq-eventual-consistency.md new file mode 100644 index 0000000..2987963 --- /dev/null +++ b/docs/distributed-system/rocketmq-eventual-consistency.md @@ -0,0 +1,6 @@ + +seata,作业,参考官网示例,自己玩儿,在自己本地部署一个单机版的RocketMQ,做实验,参考示例代码,实现一下发送消息,回调接口,一个是事务消息,一个是消费者ack + +面试训练营,讲究必须留作业给你自己动手 + +如果要看详细的项目实战类课程,参考训练营的课程目录中有一个文档,里面有我之前的课程,《亿级流量电商详情页系统实战》,一步一步带着手敲代码,可以去看看 diff --git a/docs/distributed-system/rocketmq-transaction.md b/docs/distributed-system/rocketmq-transaction.md new file mode 100644 index 0000000..156fd6d --- /dev/null +++ b/docs/distributed-system/rocketmq-transaction.md @@ -0,0 +1,40 @@ + +类似TCC事务的落地的一些东西,技术选型,业务场景需要分布式事务,结合我个人亲身经历的一个创业公司APP的一个事故,给大家介绍了一下,对于系统核心链路,为什么必须要上分布式事务 + +seata,github上,都会提供sample,跟dubbo,官方的同学是定义为double,spring cloud,seata都提供了sample,知道如何把分布式事务框架整合到框架里去了 + + +![核心交易链路](/docs/distributed-system/images/rocketmq-transaction.png) +核心交易链路,分布式事务框架 + + + +有些服务之间的调用是走异步的,下成功了订单之后,你会通知一个wms服务去发货,这个过程可以是异步的,可以是走一个MQ的,发送一个消息到MQ里去,由wms服务去从MQ里消费消息 + + +MQ,消息中间件,面试突击第一季,刚开头我就讲过消息中间件的面试连环炮 + + + +可靠消息最终一致性方案,参考面试突击第一季 + + + +落地,RocketMQ来实现可靠消息最终一致性事务方案 + + +Producer向RocketMQ发送一个half message + +RocketMQ返回一个half message success的响应给Producer,这个时候就形成了一个half message了,此时这个message是不能被消费的 + +注意,这个步骤可能会因为网络等原因失败,可能你没收到RocketMQ返回的响应,那么就需要重试发送half message,直到一个half message成功建立为止 + +接着Producer本地执行数据库操作 + +Producer根据本地数据库操作的结果发送commit/rollback给RocketMQ,如果本地数据库执行成功,那么就发送一个commit给RocketMQ,让他把消息变为可以被消费的;如果本地数据库执行失败,那么就发送一个rollback给RocketMQ,废弃之前的message + +注意,这个步骤可能失败,就是Producer可能因为网络原因没成功发送commit/rollback给RocketMQ,此时RocketMQ自己过一段时间发现一直没收到message的commit/rollback,就回调你服务提供的一个接口 + +此时在这个接口里,你需要自己去检查之前执行的本地数据库操作是否成功了,然后返回commit/rollback给RocketMQ + +只要message被commit了,此时下游的服务就可以消费到这个消息,此时还需要结合ack机制,下游消费必须是消费成功了返回ack给RocketMQ,才可以认为是成功了,否则一旦失败没有ack,则必须让RocketMQ重新投递message给其他consumer diff --git a/docs/distributed-system/work-eventual-consistency.md b/docs/distributed-system/work-eventual-consistency.md new file mode 100644 index 0000000..3fb821b --- /dev/null +++ b/docs/distributed-system/work-eventual-consistency.md @@ -0,0 +1,2 @@ + +思路全给到位了,想想自己系统里哪个业务场景可以用这个分布式事务,基于RocketMQ自己实现一遍,自己写可靠消息服务实现一遍