xiaozm1223的博客

单一的垂直型架构已经无法很好的满足大流量的系统需求，继而产生了分布式的架构。分布式架构中会将各个服务独立部署为进程，并采用各种技术手段保障HA，但在分布式系统中，经常遇到单一架构中没有的事务问题。也就是分布式事务问题，为了解决这个问题，各大厂商都提出了自己的中间件。eg：蚂蚁金服的分布式事务产品：https://tech.antfin.com/products/DTX阿里云的全局事务服务：...

TCC（Try-Confirm-Cancel）：Try 阶段：尝试执行，完成所有业务检查（一致性），预留必需业务资源（准隔离性）。Confirm 阶段：确认真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作满足幂等性。要求具备幂等设计，Confirm 失败后需要进行重试。Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源，Cancel ...

最初是由ebay提出的。核心是把大事务转变为小事务，逻辑如下：举例说明：我拿100元去买一瓶水1.当你扣钱的时候，你需要在你扣钱的服务器上新增加一个本地消息表，你需要把你扣钱和减去水的库存写入到本地消息表，放入同一个事务(依靠数据库本地事务保证一致性）。2.这个时候有个定时任务去轮询这个本地事务表，把没有发送的消息，扔给商品库存服务器，叫它减去水的库存，到达商品服务器之后，...

通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。先从消息生产者这端来分析，请看伪代码：根据上述代码及注释，我们来分析下可能的情况：操作数据库成功，向MQ中投递消息也成功，皆大欢喜操作数据库失败，不会向...

举个例子，Bob向Smith转账，那我们到底是先发送消息，还是先执行扣款操作？好像都可能会出问题。如果先发消息，扣款操作失败，那么Smith的账户里面会多出一笔钱。反过来，如果先执行扣款操作，后发送消息，那有可能扣款成功了但是消息没发出去，Smith收不到钱。除了上面介绍的通过异常捕获和回滚的方式外，还有没有其他的思路呢？下面以阿里巴巴的RocketMQ中间件为例，分析下其设计和实现思路。...

理论说明：1 数据库的2阶段提交协议（2PC或者称为XA Transactions）：第一阶段：事务协调器要求涉及事务的数据库都预提交，并反馈是否可以提交第二阶段：事务协调器要求每个数据库提交/回滚数据2 BASE理论（对CAP进一步补充）：Basically Available（基本可用） Soft state（软状态） Eventually consistent（最终...

两阶段指的是准备阶段和提交阶段，基本逻辑就是协调者给参与者发送请求，各个参与者将操作的结果反馈给协调者，协调者统一安排是提交还是终止事务。准备阶段：1）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）...

由于二阶段提交存在很多的问题，我们对其做了一定的改进，也就是三阶段提交，过程图如下：主要有2个优化点：1 引入超时机制。同时在协调者和参与者中都引入超时机制。2 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。CanCommit阶段协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。PreCo...

Consul简介：2018年6月28号eureka官方正式宣布：自2.0起不再维护该项目，并在github 项目wiki上放出了一段吓唬人的话:从2.x起，官方不会继续开发了，如果需要使用2.x，风险自负。目前业内服务注册中心的替代方案是consul。Consul原理：consul借助agent来运行，类似elk的logstash agent 或 zabbix监控系统的age...