allensandy的博客

参考：TCC分布式事务案例

现今互联网界，分布式系统和微服务架构盛行。一个简单操作，在服务端非常可能是由多个服务和数据库实例协同完成的。在一致性要求较高的场景下，多个独立操作之间的一致性问题显得格外棘手。基于水平扩容能力和成本考虑，传统的强一致的解决方案（e.g.单机事务）纷纷被抛弃。其理论依据就是响当当的CAP原理。往往为了可用性和分区容错性，忍痛放弃强一致支持，转而追求最终一致性。分布式系统的特性在分布式系统中，同时满足...

参考：分布式事务处理技术之LCN

Seata目前提供AT模式（既2PC）和TCC模式。

参考：SpringCloud Alibaba Seata---处理分布式事务

不同于单一架构应用(Monolith), 分布式环境下, 进行事务操作将变得困难, 因为分布式环境通常会有多个数据源, 只用本地数据库事务难以保证多个数据源数据的一致性. 这种情况下, 可以使用两阶段或者三阶段提交协议来完成分布式事务.但是使用这种方式一般来说性能较差, 因为事务管理器需要在多个数据源之间进行多次等待. 有一种方法同样可以解决分布式事务问题, 并且性能较好, 这就是我这篇文章要介绍...

概念Rocket MQ是阿里开发的一个分布式的开源消息队列组件，目前由Apache开源组织维护，最新版本是5.3.0，已经支持事务消息。事务消息可以确保本地事务 与 发送消息 之间的原子性，相关概念:1、Half(Prepare) MessageProducer已经把消息发送给Mq服务器，但是Mq服务器尚未收到生产者的第二次Ack，这个时候消息会被标记为"temporarily undeliverable"，目前消息的状态为 HalfMessage。2、Message Status C.

对于突然到来的大量请求，您可以配置流控规则，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量突刺造成系统负载过高。1、场景请求的到来，往往是没有规律的。例如，某应用的处理能力是每秒 10 个请求。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把请求突刺均摊到一段时间内，...