[鸿篇巨制]蚂蚁金融级分布式架构SOFAStack编年史

本文涉及的产品
mPaaS订阅基础套餐,标准版 3个月
简介: 十几年前,一群支付宝“懒汉”程序员一起开发了一套.......

有人说,历史是由懒汉推动的。

科技的演进史,其实就是人类不断偷懒的过程。我们懒得浪费体力,于是有了蒸汽机;我们懒得动笔演算,于是有了电子计算机;我们懒得随身携带现钞,于是有了线上交易和无接触支付……程序和信息成为这个时代的基底,服务和应用围绕着我们的指尖打转。

我们从网络上索取一切,海量的数据和代码在赛博空间里奔流不息。

突然有一天,构筑代码世界的工人们也犯懒了。为首的“懒汉”开始思考,能不能把一些通用的代码模块打包起来,供给上层随时取用,这样就省下了重复“造轮子”的力气,让敲代码也成为一种模块化的工作?

这一“偷懒”,就偷出了一个新概念:中间件。

无人探索的道路

对普通人来说,“中间件”是一个很遥远的词汇。

从技术层面来讲,中间件是介于基础设施和业务系统之间的特殊软件。程序员们别出心裁地构思了各种比喻:有人说它是建筑工地上的“预制件”,让工人不必从头开始搅拌水泥;有人说它是整合货源的“中间商”,让商家免于一次次询价比价的操劳……

“基础设施和业务系统之间,有很多通信和集成方面的要求,让每个业务系统都去做一遍是很浪费人力的。”蚂蚁集团高级产品专家马振雄这么说,“大家都有这样的诉求。”

时势造英雄,SOFAStack在蚂蚁集团应运而生。

它诞生得悄无声息,初衷只是为了“解救”支付宝。那还是青涩年代的支付宝,没有琳琅满目的蚂蚁森林、花呗和健康码,用4个“一”就能概括它的全部:一个简单的应用,装在一台应用服务器上,使用一个数据库,服务一个大客户——淘宝。

简单、轻快、便捷,这个系统支撑了支付宝从2004年到2006年早期的发展。但是随着交易量的攀升、业务的复杂化,支付宝很快遭遇了成长中的阵痛。

“从刚开始几十个人,后来几百人,到现在几千人的技术团队,在不同规模下的研发方式和组织方式都是不一样的。”蚂蚁集团高级技术专家黄挺说,“人一多,你发现不同的人写的代码会不一样,冲突也越来越多。”

概而言之,研发效率出现了问题。

如果说从前的支付宝是一间平房,如今则要发展成一座城市。而每搭建一座建筑,工人都必须从头开始烧制砖块、搅拌水泥——没有挖掘机,没有液压锤,一切从手无寸铁开始,对以“建设城市”为己任的团队来说,这是完全不可接受的。

举个例子,当时支付宝的一个电子钱包系统iWallet,每次启动需要五六分钟,足够开发人员下楼抽一支烟。如果发现错误,就得修改后重新启动,开发人员每天深陷在代码编译和重启的“死循环”之中。

究其原因,就是因为iWallet系统包含了几十个工程,有十多个团队并行开发。支付宝原本的系统无法支撑这么复杂的业务逻辑,也难以让那么多工程师在一起并行工作,大家把它称为monolithic——庞大的单体系统。

支付宝的诉求显而易见:第一,希望成百上千个项目并行进行,每个工程师可以不受干扰地工作;第二,当业务逻辑增加的时候,系统的复杂度不要成指数级上升。

它需要一套能够力挽狂澜的“中间件”。
image.png

2006年,契机来临。技术团队在这一年开了一连串的会,会议的核心议题只有一个:决定支付宝未来的技术架构。团队内部分成两派:第一派提议向银行老大哥学习,走集中式架构的老路;第二派则认为分布式架构才能支撑未来的交易支付系统,而且不是客户端/服务器时代那种小规模架构,是互联网时代的超大规模分布式架构。

毫无疑问,这是一条无人探索过的道路。

当然,你知道阿里人的秉性,退缩和守成从来不是他们的标签。经过长达一年左右的思考和论证,技术团队果断驶入第二条赛道。2007年起,支付宝率先启动了对交易系统、商户系统、会员系统、支付清算系统的改造,一个全新的架构正在孕育之中。

这套分布式架构就叫“SOFA”。

为什么叫这个名字?其一是源于当时正火的“SOA”概念,即Service-Oriented Architecture,“面向服务的架构”,在此基础上加入金融业务,就构成了SOFA的全称:Service-Oriented Fabric Architecture。

其二则是开发者的私心,“希望能够像沙发(Sofa)一样,让工程师可以非常爽地工作。”

从“连接器”到“工具库”

什么是SOA?用偏技术的语言表述,就是把企业的IT系统以“服务”的方式重新组织,再通过“服务总线”连接起来,形成可插拔式的企业IT架构,这个架构就是SOA。

你或许觉得这个释义很难懂,没关系,因为在那个年代,SOA纯粹只是一套面向传统企业IT架构的思想,换句话说,一套理论框架罢了。

你问业界具体的成功实践?抱歉,没有。

初次试水,蚂蚁的“探路者”们走得非常谨慎:第一代SOFA只解决两个问题,一是充当一个类似于“胶水”、“连接器”的机制,把分布式系统连接成整体;二是做到每一个服务组件化,让每个工程师专注做好各自的组件,最后把组件拼装在一起成为“服务”,再把“服务”拼装在一起组成整个系统。

用黄挺的话来说,“SOFA能够隔离出一些不同的模块,由不同的人去做开发,每个人有了更加细致的分工,不会跟别人出现太多的交叉。”

第一代SOFA清晰地定义了团队之间的边界,何时分工协作,何时紧密联合,安排得明明白白。黄挺举了个例子:简单的一次转账业务,系统需要调用用户的通讯录,调用账务相关的子系统——可能还得去问银行,账户余额到底够不够?整个流程涉及到非常复杂的系统交互,这些由不同团队开发和运维的系统,怎样才能高效交互、稳定完成每一笔业务呢?这就仰赖SOFA从中协调和沟通了。

燃眉之急解决了,但初生的分布式中间件SOFA并不能处理所有问题。它还需要打怪升级,积累经验,向下一代、再下一代演化。
image.png

无人探索的道路上没有先驱者,只有野蛮生长的技术难题在横冲直撞。

在SOFA的加持下,支付宝一边拆分金融业务系统(后来的业务中台)一边拆分底层IT系统(后来的数据中台和计算中台),在拆分过程中还要应对历年双十一的海量数据冲刷,以及不断涌现、千奇百怪的技术问题。甚至在解决分布式服务一致性问题时,由于业界提出的两个SOA事务标准都无法支撑支付宝核心系统的交易量,团队干脆一狠心一咬牙:现有的标准都不可行,要不我们自己提一个吧!

逢山开路,遇水搭桥。很难说清SOFA这些年来的演进中,他们遭遇过多少类似的阻碍,又有多少奇思妙想和技术实践沉淀下来,最后凝练成SOFA内部的几行代码。

他们在无人区设下哨塔,漫漫长夜被灯火点亮。

第一代SOFA,做到了模块化。

第二代SOFA,完成了服务化。

第三代SOFA的亮点,则是被誉为“蚂蚁黑科技”的单元化,“异地多活”架构让服务器资源水平扩容的难度大大下降,保障了用户的每一笔订单平稳顺滑。团队坦陈,面向超大规模互联网金融交易的分布化改造,单元化这一技术构想完全是被业务倒逼的,业界没有先例可循。

“我们找到过一些论文、一些概念,但以支付宝这么大的体量,没有人确定这事儿真的能做成。”团队成员感慨。

就这样,随着支付宝架构的逐次优化,SOFA也在不断迭代和成长。从最初仅是一个简单的框架,到后来强化通讯性能、提升容灾效率、建设异地容灾架构、单元化改造、添加LDC逻辑数据中心项目……SOFA羽翼渐丰,安插在它身上的技术工具越来越多元,它也逐渐超出了“中间件”的范畴,成为一座事实上的“工具库”。

到这里为止,SOFA走完了自己的第一段浴火重生之路。它的全名也被改成了Scalable Open Financial Architecture,致力于解决金融级系统构建的基础架构问题。开发者还在SOFA后面加上了Stack,这个单词的意思是“栈”,可以简单地理解为“套组/组合”。

仔细品味,不难从命名中读出开发者的愿景和苦心:

  • Scalable,可扩展能力,处理更多的交易,容纳更多的业务,能够让几千甚至上万个工程师一起协同工作的可扩展架构。

Open,开放,既让业务应用容易上手,又能和经典架构有机融合。

Financial,意味着SOFAStack必须具备金融级属性,真正实现金融级的一致性、可用性和稳定性。

在2020年发布的《SOFAStack金融分布式架构白皮书》中,蚂蚁集团对SOFAStack的严格定义是:一套用于构建金融级云原生分布式应用的技术栈。

经受了多年来大促活动的考验,支撑了蚂蚁集团全域业务的发展,SOFAStack已成为蚂蚁内部的明星产品。这时,有人望向山门之外的世界:分布式架构开始走入大众视野,中间件市场山雨欲来。

团队终于有人按捺不住,提议:要不,我们出去看看?

一呼百应。山门大开,SOFAStack闯入江湖。

出山

江湖险恶,暗流汹涌。

SOFAStack出山之前,传统企业核心系统仍然是集中式架构的天下,尤其是大名鼎鼎的IOE架构:IBM提供计算能力强大的小型机,EMC配套昂贵的高端存储,结合Oracle的数据库,形成集中式架构“三驾马车”。而大量业务逻辑的执行,则要依赖重量级的J2EE容器或交易中间件CISC等。

但在繁荣之下,基石已经不稳。IBM主机的单机性能固然强大,可随着大量金融机构走向数字化转型、积极开展线上业务,基于主机系统构建的单体式核心应用已经无法再支撑这么庞大的并发量。

怎么解决?只能水平扩容。

但一扩容就扩出了问题:在IOE架构下,升级主机配置的价格非常昂贵,远远不是所有企业都能承担的。早在2013年双十一,Oracle就从美国把天价账单甩到阿里巴巴面前:你们双十一的流量全跑在我们数据库上,加钱!

幸好阿里留了后手:没想到吧,我们用的是自研数据库OceanBase!

“国产”、“自研”,这当然是成本角度之外的另一个重要考量。蚂蚁集团敏锐地察觉到了市场上“去IOE化”的呼声,SOFAStack适时入局。
image.png

谁来当第一个吃螃蟹的人呢?南京银行挺身而出。

“蚂蚁之前的成就,在金融方面的创新,其实很多银行都看在眼里。”作为SOFAStack商业化团队负责人,马振雄表示前景乐观,“共识已经凝聚了,方向大家也都认可。他们也想去走这条路。”

2017年初,南京银行确立了“双模运行”的选型方向:在保留传统的“稳态”核心之余,搭建一个开放灵活的“敏态”核心。同年4月,蚂蚁平台架构部、金融核心平台部、技术风险部、微贷事业部等多个团队精锐尽出,对南京银行进行全面问诊。

毕竟是第一个客户,做不好就是自砸招牌,谁也不敢轻忽大意。SOFAStack亮出自己的全副武装,这将是它的生涯首秀。

7月,蚂蚁集团派驻技术团队现场入驻南京银行,包揽了分布式架构转型的路线图和顶层架构设计,要让客户“在设计之初就避免走弯路”。10月,南京银行在云栖大会现场发布了自己的互联网金融开放平台,取名“鑫云+”。

11月18日,“鑫云+”正式落地。

第一枪成功打响,SOFAStack在商业化过程中吸收经验、快速调整,以更敏捷的步态应对客户的反馈和需求——按照常规流程,“响应”意味着一条非常漫长的链路:客户的需求先反馈给交付部门和售后运维部门,运维部门提炼需求后提交到产品团队,产品团队给出排期,再让技术团队去落实,最后再发一个新版本由售后团队去运维。

但在南京银行,有蚂蚁派出的“联合阵型”镇场:产品、技术、业务、售后、交付、运维,一应俱全。有任何bug或产品需求,项目组就地消化,高速解决。甚至在1天之内,一个产品连续发了6个版本,这种互联网式的“闪电迭代”让传统金融行业眼界大开。

在商业化、产品化的道路上打磨历练,第四代SOFAStack破茧。

南京银行之后,SOFAStack和蚂蚁提供的整套金融级云原生架构解决方案得到了业界认可,越来越多急于摆脱IOE掣肘的金融机构登门拜访,向蚂蚁抛出了橄榄枝。

水域被凶猛搅动,“新物种”正在蜕变中。

此时有声胜无声

如今再看SOFAStack的客户名单,可以列出长长的一串。

有声名显赫的大型机构,也有眼光独到的小企业,有平顺的过渡期,也有困难重重的功能适配问题。马振雄回忆说,有时候团队刚部署完平台,进入到开发测试环节,客户就会在一天之内就一款产品就提出几十个问题。

我问他,气馁吗?

马振雄笑说,团队更多是“痛并快乐着”。

痛,可以理解,蚂蚁多年培养的明星产品,一下子被迎面而来的问题打懵了。快乐,则是从客户的态度中看到对自身的期望,如果对产品一点信心都没有,团队迎来的只会是难堪的沉默。马振雄说,这样的客户非常难能可贵,“我们不怕声音,我们最怕的是没有声音。”
image.png

在众声喧哗的客户名单里,华瑞银行是不可忽视的一员。

和动辄千亿的股份行、城商行,乃至资产过万亿的南京银行相比,资产规模300多亿的上海华瑞银行,或许只是一个“小客户”。

但也正因其小而能成其大,SOFAStack与华瑞银行合作的案例,被马振雄评价为“做民营银行业务的标杆”。在与阿里和蚂蚁集团合作之前,华瑞银行就花了将近1年时间研究云平台建设,它没有线下网点和柜面,所有的获客、开户、存贷业务都在线上完成。

这是一家天然偏向互联网化的银行,和骨子里烙印着互联网基因的蚂蚁集团一拍即合。2019年底,华瑞银行搭载了金融级分布式架构SOFAStack、mPaaS移动开发平台、阿里云“飞天”云计算操作系统,构建起自己的“祥云”专属金融云平台,支撑手机银行、营销、反欺诈、贷款核算等业务系统。

十八般兵器开箱即用,创新之路,踏雪无痕。

华瑞银行科技部总经理叶宁在一次专访中提到,中小银行要学会“有所为,有所不为”,既然不具备国有大行和股份行的技术实力,就需要找到互补的金融科技公司提供助力。

“通过和阿里云、蚂蚁集团的合作,我们可以从低效的工作中解放出来,不用把精力花在标准化的软硬件技术重复建设上。”叶宁将这个过程比喻成“做菜”,有人喜欢从零开始种菜、养猪、榨油,这当然符合绿色健康理念,但并不是每个家庭主妇都有余力承担这些工作。

“华瑞银行不想做农民,也不想做养殖户。我们就想把超市里加工好的半成品拿过来,做出符合自己口味的菜。”叶宁说。

——等等,这个设定是不是很耳熟?

这个奇妙的比喻,恰好和一开始“中间件”诞生的意义不谋而合。建筑工地上有了搅拌器,家用冰箱里有了半成品,模块化的组件伸手即得,所有人都不必在重复低效的劳动上耗费精力。

2020年一季度,华瑞银行手机端获客增长468%,系统开发速度提升30%以上,系统环境准备和资源扩容周期大幅度缩短。疫情来临之际,经过更新换代的金融级分布式核心完美支撑住了线上业务量的爆发。
image.png

入局银行业之外,SOFAStack更在保险业界展露身手。

2018年,蚂蚁集团对接中国人保健康,以一整套包含mPaaS和SOFAStack等技术产品在内的解决方案,帮助这家老牌保险公司成功突破技术瓶颈,构建起对标行业顶尖水平的新一代核心业务系统。

短短数月,中国人保健康的保单处理能力提升数千倍,出单时间达到每秒1000单,外部渠道产品接入效率提升6倍,新产品上线时间缩短80%,平台服务可用性达到99.99%。从前需要4小时才能处理完的上万单日结文件,现在只需要6分钟。

切入保险领域,SOFAStack轻车熟路,毫无水土不服。

马振雄说,SOFAStack之前的使命是支撑蚂蚁集团全域业务,“全域”这两个字可不是说说而已——SOFAStack服务的对象涵盖了余额宝、蚂蚁保险、芝麻信用等一系列我们耳熟能详的产品,整个金融行业的业务需求几乎都被包融在内。

“这方面没有困扰,我们天然原生就可以支撑金融行业的所有细分行业。”马振雄轻描淡写,背后的技术沉淀重达千钧。

从初试锋芒到大展拳脚,从无人区的前哨到数字化转型的领航员,SOFAStack从蚂蚁集团扬帆出海,联同mPaaS移动开发平台、OceanBase分布式数据库,舰队并列向前,征途上只留下航行的尾迹。

顺德农商行、深圳农商行、国泰产险、信美相互……与SOFAStack合作的客户名单还在不断加长。正像2020年那句豪情万丈的口号“分布式才是未来”那样,越来越多旅客站上月台,看分布式架构的列车跨越山海,要为这时代带来全新的变革。

汽笛声震颤破晓,人们涌入车厢,驶向未来。

未来已来

如今,SOFAStack已经演进到了第五代。当初那个简单的中间件框架,如今已是一个变化百出的魔盒。SOFABoot、SOFARegistry、MOSN、SOFARPC……在开源社区里,数万人为这些项目和组件添砖加瓦,SOFAStack得以在更多应用场景中经受锻炼。

我问黄挺,第五代SOFAStack有什么求新求变的地方?

黄挺说,最大的改变是“可信原生”,当SOFAStack为一个国民级应用提供服务,用户对数据隐私、安全、可靠性的要求也会相应提高。SOFAStack团队在打破技术边界、构建稳定框架的路上穷尽探索,向着更加安全可信的目标进发。

要提“可信原生”,就不得不介绍“云原生”的概念。

正如这个轻灵飘逸的名字那样,云原生是一种专门针对“云上应用”而设计的方法,云上应用能够实现快速和频繁的构建、发布、部署,在可扩展性、可用性、可移植性方面均有优秀表现。此时此地,云原生技术已成为现代云计算技术的发展潮流,越来越多企业接受和采用了这一技术选型。

从2018年起,蚂蚁集团全面转向云原生技术,SOFAStack作为其中核心技术的载体,也悄然发生着天翻地覆的变化。

在部分技术领域,SOFAStack已经走在了业界的最前沿。其中最知名的就是服务网格(Service Mesh),SOFAStack在开源社区项目的基础上,发展了自己的组件SOFAMosn(后独立运作,并升级品牌为MOSN),并在2019年的双十一大促中承担了支付宝核心链路的流量检验,是世界上最大的Service Mesh集群之一。
image.png

创新的热潮开始翻涌。观潮者云集,“弄潮儿”却不肯露面。

云原生技术对旧有的技术架构带来了巨大的冲击,出于对新兴技术的不信任,业务人员和客户大多抱以观望态度。近年来,金融行业只肯把云原生技术试用于新业务,却几乎没有在核心交易系统中应用的先例。

隐忧不除,难以为继。经过长时间的思考和实践,蚂蚁提出了“可信原生”的理念,它的本质非常简单:让云原生变得可信赖。

短短的“可信”两字,却涉及到庞大的技术链路:无论业务方还是用户,都有对安全、稳定和可信的追求,但这不是加强某些技术点就可以做到的,而是需要让整个系统从硬件到应用,让所有应用从开发、部署、升级到下线的完整生命周期,让每个用户访问从移动端到核心数据库的全链路——都是可信的。

作为可信原生理念的践行者,SOFAStack正在谋求更华丽的转变。

在可靠性方面,SOFAStack承载了历年双十一大促,三地五中心异地多活经受了实践检验;在安全生产和数据保护等方面,可信原生中的关键技术“安全容器”和“机密计算”,已经加入到SOFAStack技术栈中。未来,SOFAStack将通过与国内外学术机构和行业客户的研究合作,继续加强可信原生方面的建设。

新技术带来的既是风险,也是机遇。

“我们可以利用新技术打造比以前更安全可靠的系统,”蚂蚁集团资深技术专家王旭说,“更重要的是,我们是否能够将‘信任’这一无形的产品,通过我们的技术交付给用户。”
image.png

历史真是由懒汉推动的吗?未必尽然。

但是我相信,那些依靠发明新技术来“偷懒”的人,既是这个世界上最懒惰的人,也是最聪明、最勤奋的人。

制造“中间件”的人也一样。他们把代码世界中繁重的部分做成模块,解放了广大程序员的双手,让编译程序成为一件更加流畅、优雅、得心应手的工作。他们懒惰,因为他们不愿接受枯燥和低效的工作;他们勤劳,因为他们付出的心血并不比别人更少,而且用自己所造的工具惠及到行业内外。

跌跌撞撞一路演化至今,分布式架构的江湖群雄林立,厮杀正酣。SOFAStack回望山头,只看见雾霭弥漫。

时代风声如潮涌,下一班列车又将到站。

目录
相关文章
|
3月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
3月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
3月前
|
存储 JSON 数据库
Elasticsearch 分布式架构解析
【9月更文第2天】Elasticsearch 是一个分布式的搜索和分析引擎,以其高可扩展性和实时性著称。它基于 Lucene 开发,但提供了更高级别的抽象,使得开发者能够轻松地构建复杂的搜索应用。本文将深入探讨 Elasticsearch 的分布式存储和检索机制,解释其背后的原理及其优势。
273 5
|
4天前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
38 11
|
6天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
29 11
|
7天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
42 11
|
9天前
|
自然语言处理 负载均衡 Kubernetes
分布式系统架构2:服务发现
服务发现是分布式系统中服务实例动态注册和发现机制,确保服务间通信。主要由注册中心和服务消费者组成,支持客户端和服务端两种发现模式。注册中心需具备高可用性,常用框架有Eureka、Zookeeper、Consul等。服务注册方式包括主动注册和被动注册,核心流程涵盖服务注册、心跳检测、服务发现、服务调用和注销。
45 12
|
21天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
17天前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
33 1
|
25天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
55 8

热门文章

最新文章