海量分布式事务的处理策略? 400 请求出错  -问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

海量分布式事务的处理策略? 400 请求出错 

kun坤 2020-05-25 20:36:08 81

最近很好奇,在分布式事务的情况下,如何解决高并发的问题?

今天面试,一个人问我,如何解决高并发的分布式事务处理,我按照我之前干活的经验,认为用消息队列做写入缓冲,用二端提交和串联的transaction做事务处理,在出现commit异常的情况下,采用事务补偿,也就是说,先假设事务成功的概率是99%以上,然后检查最终一致性,最后针对出错的不到1%做事务补偿。

但是被骂了。。说现有互联网场景下,消息队列最多承受20W/s的并发,而且消息队列会有很长的延时。

但是我就很好奇,究竟还有什么大法可以搞定这种每秒超过100W以上的并发分布式事务写入操作呢?

或者说难道不能用局部性原则来从设计上解决这个问题吗?

大家有什么好的思路?

分享到
取消 提交回答
全部回答(1)
  • kun坤
    2020-05-26 13:15:05

    "

    用了两年的时间,终于把这个问题解决了。。

    ######能分享下如何解决的吗######

    分布式事务的基本理论,2PC, QUORUM, PAXOS,系统要达到100w/s的水准靠水平分割

    ######好问题,。。。######mark######你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。

    消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。

    如果单库多master还无法解决的话,那就要进行数据库分割。
    如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。

    灵活运用吧。

    ######

    两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。

    所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。   

    其实海量分布式事务的解决方案就是最终一致性模型。

    ######因为他的说法中有错别字,我没有看到2pc,这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的,是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。######

    引用来自“jobet”的评论

    你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。

    消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。

    如果单库多master还无法解决的话,那就要进行数据库分割。
    如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。

    灵活运用吧。

    什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈######其实这个问题基本上没有正确的方案,每一个平台根据业务性质都会不同,唯一能够提供的就是一个大体的思虑,其他的根据自己的业务性质自行提炼和优化。######

    引用来自“兮风古道”的评论

    两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。

    所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。   

    其实海量分布式事务的解决方案就是最终一致性模型。

    二段提交的时候,最后一次commit还是会出错的。。######回复 @jobet : 收到。。我搞错了。。######回复 @Brin想写程序 : 2pc是针对于多数据源的事务处理,也就是分布式事务。你说的这个不是。######回复 @jobet : 问一下mysql的autocommit=false后的,commit和rollback难道不是二段提交的吗?这个应该就是数据库的二段提交吧?######2pc的话,对性能的消耗是很大的。估计面试官是因为听到他说2pc就直接否决了,后续的已经没有兴趣了。###### Brin有什么好办法了,记得 博客里补上######我的解决方案是根据用户顺序处理,也就是用顺序一致性替代绝对一致性,然后用分布式消息队列,用一致性哈希算法,只将一个用户的数据发送给同一个处理者,然后按顺序执行这一个人的操作。所以这个是无锁的,可并行的。######

    引用来自“jobet”的评论

    你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。

    消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。

    如果单库多master还无法解决的话,那就要进行数据库分割。
    如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。

    灵活运用吧。

    引用来自“中山野鬼”的评论

    什么东西一大了,单纯靠数据库,分布式平台等数据工具是解决不了的。一定要结合具体业务特性,大概率下数据分布特征来做模型的重新设计和优化。这就是我说的,大数据的工作,hadoop之类的工具,并不能帮你做什么。还是自身业务模型设计的问题。哈
    我也觉得是具体业务具体分析,比如在电商平台里面,在怎么分布式,买东西这个过程是一个用户触发的。 所以按照用户对纬度,对资源进行水平分割,应该可以解决大部分问题。 但是但是,最麻烦的是先有很多电商平台非常庞大,而且一开始就没有做这种分割,业务是一团乱麻,没人清楚这个用户的购买行为会影响多少台服务器里面的数据,所以只能寻找比较通用的解决方案。 也就是在某个层面上能彻底解决,现在好像思路还是从rpc层面去解决这个问题。找到统一的一劳永逸的中间价或者说体系结构。。 所以我也很难想明白。。######马克,学习了"
    0 0
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

推荐文章