Moonxiyue的博客

分布式事务，咱们前边也聊过很多次了，网上其实也有不少文章在介绍分布式事务，不过里边都会涉及到不少专业名词，看的大家云里雾里，所以还是有一些小伙伴在微信上问我。那么今天，我就再来一篇文章，和大家捋一捋这个话题。以下的内容主要围绕阿里的 seata 来和大家解释。首先，来和大家解释一个名词，大家在看分布式事务相关资料的时候，经常会看到一个名词：反向补偿。啥是反向补偿呢？我举一个例子：假设我们现在有三个微服务分别是 A、B、C，现在在 A 服务中分别调用 B 和 C 服务，为了确保 B 和 C 同时成功或者同时失

其实我觉得 seata 中的四种不同的分布式事务模式，学完 AT、TCC 以及 XA 就够了，Saga 不好玩，而且长事务本身就有很多问题，也不推荐使用。Seata 中的 XA 模式实际上是基于 MySQL 的 XA 两阶段提交发展出来的，所以学习 XA 模式，需要小伙伴们先理解 MySQL 中的 XA 是怎么一回事，把 MySQL 中的 XA 搞清楚了，再来学习 Seata 中的 XA 模式就容易的多了。我们先来稍微回顾一下两阶段提交。先来看下面一张图：这张图里涉及到三个概念：那么什么是两阶段(Two-P

Kafka 是由 公司开发的，它是一个分布式的，支持多分区、多副本，基于 Zookeeper 的分布式消息流平台，它同时也是一款开源的基于发布订阅模式的消息引擎系统。消息：Kafka 中的数据单元被称为，也被称为记录，可以把它看作数据库表中某一行的记录。批次：为了提高效率， 消息会写入 Kafka，批次就代指的是一组消息。主题：消息的种类称为 （Topic）,可以说一个主题代表了一类消息。相当于是对消息进行分类。主题就像是数据库中的表。分区：主题可以被分为若干个分区（partition），同一个主题中的分

我们先来稍微回顾一下两阶段提交。先来看下面一张图：这张图里涉及到三个概念：那么什么是两阶段(Two-Phase Commit, 简称 2PC)提交？两阶段提交说白了道理很简单，松哥举个简单例子来和大家说明两阶段提交：比如下面一张图：我们在 Business 中分别调用 Storage 与 Order、Account，这三个中的操作要同时成功或者同时失败，但是由于这三个分处于不同服务，因此我们只能先让这三个服务中的操作各自执行，三个服务中的事务各自执行就是两阶段中的第一阶段。第一阶段执行完毕后，先不要急着提交

——陈默（墨城）阿里云数据库技术专家了解更多PolarDB-X 内容：developer.aliyun.com/topic/polar…在刚刚发布的PolarDB-X 2.1.0版本中，开源了透明分布式能力，能带给用户完全不同的透明分布式数据库使用体验。其中，一个最明显的不同，就是用户不再需要关注分区健这个概念，这也是副标题《再见，分区健》的来由。1970 年代末，分区的概念首先在并行数据库系统中出现，用来代表一组记录的集合。在并行数据库中，表首先按照某种规则被切分为若干分区，每个分区存入数据库节点，每个数

Kafka是一种分布式、高吞吐量的分布式分布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据，主要应用于大数据实时处理领域。类比来说，kafka是一个邮箱，生产者是发送邮件的人，消费者是接收邮件的人，Kafka是用来存东西的，只不过它提供了一些处理邮件的机制。特点优点：缺点Kafka的使用场景1、消息队列功能：在系统或应用程序之间构建可靠的用于传输实时数据的管道2、数据处理功能：在系统或应用程序之间构建可靠的用于传输实时数据的管道，Kafka架构Kafka的生

一个RabbitMQ实例就是一个Broker 虚拟主机。相当于Mysql的DataBase, 一个Broker上可以存在多个vhost，vhost之间相互隔离。每个vhost都拥有自己的队列、交换机、绑定和权限机制。vhost必须在连接时指定，默认的vhost是 /。 交换机，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 消息队列，用来保存消息直到发送给消费者。它是消息的容器。一个消息可投入一个或多个队列。 绑定关系，用于消息队列和交换机之间的关联。通过路由键(Routing Key)将交换机

大家都知道，系统架构有三高：「高性能、高并发和高可用」，三者的重要性不言而喻。对于任意系统，想要同时满足三高都是一件非常困难的事情，大型业务系统或者传统中间件都会搭建复杂的架构来保证。除以上三种模式之外，还有一个指标方向也很重要，那就是高可靠，甚至你可能会将它和「高可用」混淆起来。事实上两者并不一样，高可用会更偏向于整体服务的可用性，防止系统宕机等等。而高可靠是指数据的可靠性保证嘛，你可以理解”高可靠“相比于系统三高会是一个更细一点的概念。那么什么是数据的高可靠呢，总结一下就是系统要提供可靠的数据支撑，不能

我们先思考下面几个业务场景的解决方案:很多业务场景需要我们某一特定的时刻去做某件任务，定时任务解决的就是这种业务场景。一般来说，系统可以使用消息传递代替部分定时任务，两者有很多相似之处，可以相互替换场景。如，上面发货成功发短信通知客户的业务场景，我们可以在发货成功后发送MQ消息到队列，然后去消费mq消息，发送短信。但在某些场景下不能互换：单机分布项目背景及社区力量X-Job　：　大众点评公司下员工许雪里、贡献者 3人;　github有2470star、1015fork　|　QQ讨论群6个　|　有登记在使用的