add .

文亮 · 文亮 · commit 13d5e3cb9fc9 · 2019-08-12T19:32:43.000+08:00
diff --git 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
@@ -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
diff --git a/docs/distributed-system/rocketmq-eventual-consistency.md 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
@@ -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
@@ -0,0 +1,2 @@
+
+思路全给到位了，想想自己系统里哪个业务场景可以用这个分布式事务，基于RocketMQ自己实现一遍，自己写可靠消息服务实现一遍

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,2 @@`
	`1`	`+`
	`2`	`+思路全给到位了，想想自己系统里哪个业务场景可以用这个分布式事务，基于RocketMQ自己实现一遍，自己写可靠消息服务实现一遍`