最近很好奇,在分布式事务的情况下,如何解决高并发的问题?
今天面试,一个人问我,如何解决高并发的分布式事务处理,我按照我之前干活的经验,认为用消息队列做写入缓冲,用二端提交和串联的transaction做事务处理,在出现commit异常的情况下,采用事务补偿,也就是说,先假设事务成功的概率是99%以上,然后检查最终一致性,最后针对出错的不到1%做事务补偿。
但是被骂了。。说现有互联网场景下,消息队列最多承受20W/s的并发,而且消息队列会有很长的延时。
但是我就很好奇,究竟还有什么大法可以搞定这种每秒超过100W以上的并发分布式事务写入操作呢?
或者说难道不能用局部性原则来从设计上解决这个问题吗?
大家有什么好的思路?
"
用了两年的时间,终于把这个问题解决了。。
######能分享下如何解决的吗######分布式事务的基本理论,2PC, QUORUM, PAXOS,系统要达到100w/s的水准靠水平分割
######好问题,。。。######mark######你的解法是正确可行的,不知道面试官是怎么想的,估计面试官自己都没有答案。消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。
如果单库多master还无法解决的话,那就要进行数据库分割。
如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。
灵活运用吧。
######两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。
所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。
其实海量分布式事务的解决方案就是最终一致性模型。
######因为他的说法中有错别字,我没有看到2pc,这一点他的强一致模型确实和最终一致模型概念不清。楼主本身估计不是做架构的,是根据自己公司原来的架构体系自己总结的一些东西。不过楼主的解决方案的大体方向是可行的。######消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。
如果单库多master还无法解决的话,那就要进行数据库分割。
如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。
灵活运用吧。
两阶段提交本身属于强一致性模型,你又说做最终一致检查,有点概念不清的嫌疑。
所以面试官在听到你说2PC的时候,估计已经不想跟你扯了, 猜测~~。
其实海量分布式事务的解决方案就是最终一致性模型。
消息队列是可以集群的,最终的瓶颈只是在数据库上面,所以要做多master应该就可以解决了。
如果单库多master还无法解决的话,那就要进行数据库分割。
如果分割了还无法解决的话,那就要采用内存数据库,然后在持久化到磁盘。
灵活运用吧。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。