RocketMQ实战(三):分布式事务
推荐
推荐
现在手机银行转账已经司空见惯。但是,D瓜哥一直在思考,银卡跨行转账是如何保证事务一致性的?借机就对分布式事务,做了简单地了解。
2PC 两阶段提交(2pc, two-phase commit protocol),2pc是非常经典的强一致性、中心化的原子提交协议。中心化是指协议中有两类节点:一个中心化协调者节点(coordinator)和N个参与者节点(participant、cohort)。
本文主要介绍事务、一致性以及共识,首先会介绍它们怎么在分布式系统中起作用,然后将尝试描述它们之间的内在联系,让大家了解,在设计分布式系统时也是有一定的“套路”可寻。最后将介绍业界验证分布式算法的一些工具和框架。希望能够对大家有所帮助或者启发。
Redis 通过 MULTI、EXEC、DISCARD、WATCH 、UNWATCH 来实现事务功能,Redis 事务具备如下几个特性:
1、Redis 会将事务中的多个命令一次性、按顺序一次执行,在执行期间可以保证不会中断事务去执行其他命令;
2、Redis 的事务机制是不能保证原子性的,它只保证隔离性和一致性。
延时消息是指消息被发送以后,并不想让消费者立即拿到消息,而是等待指定时间后,消费者才拿到这个消息进行消费。
本文介绍了使用 Kotlin+RocketMQ 实现延时消息。
随着企业的发展,企业业务架构面临数据、服务的分布化,几乎无可避免地要遇到分布式架构带来的数据一致性问题。GTS 开创性地把分布式事务问题从业务中剥离出来,作为一个独立的技术切面来单独管理,以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。
本文整理自李样兵在北京站 RocketMQ meetup分享美菜网使用 RocketMQ 过程中的一些心得和经验,偏重于实践。嘉宾李样兵,现就职于美菜网基础服务平台组,负责 MQ ,配置中心和任务调度等基础组件开发工作。
微服务架构体系下,我们可以按照业务模块分层设计,单独部署,减轻了服务部署压力,也解耦了业务的耦合,避免了应用逐渐变成一个庞然怪物,从而可以轻松扩展,在某些服务出现故障时也不会影响其它服务的正常运行。总之,微服务在业务的高速发展中带给我们越来越多的优势,但是微服务并不是十全十美,因此不能盲目过度滥用,它有很多不足,而且会给系统带来一定的复杂度,其中伴随而来的分布式事务问题,是微服务架构体系下必然需要处理的一个痛点,也是业界一直关注的一个领域,因此也出现了诸如 CAP 和 BASE 等理论。
随着互联网+和平台化战略的兴起,各个行业的 IT 系统都在向互联网架构发展,涉及的主要技术包括微服务、消息和弹性计算等,采用微服务架构实现服务高内聚、低耦合,通过异步消息完成交易快速响应和高并发。由于微服务和消息是企业应用架构中用的比较多的,故希望通过本文探讨以下问题:
分布式事务是分布式数据库最难攻克的技术之一,分布式事务为分布式数据库提供一致性数据访问的支持,保证全局读写原子性和隔离性,提供一体化分布式数据库的用户体验。本文主要分享分布式数据库中的时钟解决方案及分布式事务管理技术方案。混合逻辑时钟(HLC)可以实现本地获取,避免了中心时钟的性能瓶颈和单点故障,同时维护了跨实例的事务或事件的因果(happen before)关系。
在SOA、微服务架构流行的年代,许多复杂业务上需要支持多资源占用场景,而在分布式系统中因为某个资源不足而导致其它资源占用回滚的系统设计一直是个难点。我所在的团队也遇到了这个问题,为解决这个问题上,团队采用的是阿里开源的分布式中间件Fescar的解决方案,并详细了解了Fescar内部的工作原理,解决在使用Fescar中间件过程中的一些疑虑的地方,也为后续团队在继续使用该中间件奠定理论基础。