《阿里巴巴Java开发手册》条例解读(一)

  • 时间:
  • 浏览:0

在IOT场景下,不同的终端设备需用分配不同的物联网卡进行数据通信,最基本的限制随后一张卡都并能并能 分给一个多 设备。机会,一张卡分给多个设备机会导致 着卡被交替使用,不同的终端使用同一张卡交替上线下线,进一步导致 着运营商停卡和客户投诉。即便是一定量的一卡多分在业务上也是没能接受的。而分卡服务必定需用部署多个服务节点,单个节点肯定无法满足大业务量需用,并发/并行地选中并占用同一张卡是必然会出现的(并发/并行补救的概念请自修)。机会一定量终端请求到达服务端后,会被后端无状态服务的多个节点补救,不同的终端分卡请求会落在不同的节点上,这时不同的终端机会会被不同的服务节点分配同一张卡。比如节点A的终端TA请求占卡1,表示为1-TA,和节点B的终端请求TB占卡1,表示为1-TB。机会这名个多 不同节点上的请求请求原来后相差1毫秒的时间更新了数据库,导致 着的结果是TA分到了卡1,并返回给终端,紧接着TB也被认为分到了卡1并返回给终端,一卡多分。但系统中的最终记录是1-TB,终端TB占有卡1。可一毫秒前从业务的厚度看是终端TA占的卡1。于是在接下的一段时间,终端TA和终端TB轮流使用用卡1,卡1会被不断地上线又踢下线又上线,循环反复。如下图

很多很多“更新丢失”更准确的描述是“更新覆盖”,当一个多 程序修改某条业务数据都会被原来删改不知情的程序覆盖数据,导致 着在整个业务层面数据状态的不一致,随后“需用加锁”。随后规范中并都并能并能 明确应该为啥选泽在哪此样的场景下使用哪此样的锁。

为了应用服务并能平滑横向扩容,都并能并能 对业务状态有特定要求的场景,大伙儿儿通常会把应用设计成无状态应用,当业务压力增大只需用通过增加应用服务节点就能满足提升补救能力的要求。对于上述占卡的应用场景,系统选泽多应用节点并行补救分卡请求,来提升系统吞吐量。机会仅仅选泽在单应用节点加进锁,都并能 补救多节点多程序并行补救导致 着的数据冲突。但机会选泽缓存(Redis)锁,把卡资源作为锁对象,则需用将数据库中的记录和缓存做同步,一种就涉及数据同步和数据一致性难题。在需用对一定量数据加锁或长时间加锁时,不建议优先考虑使用悲观锁,机会一次分卡请求机会需用读取一定量的卡资源做排序、过滤,锁住一定量的卡会极大降低并发吞吐量。更好的妙招是使用乐观锁,随后是直接在数据库层使用乐观锁,用version(UUID)作为更新妙招。更新SQL ,UPDATE table XXX where version = UUID。(数据库乐观锁的原理请自修)。随后在选卡和占卡时,需用做这名功课来降低冲突的机会性,但能保证在任何原来卡数据不被过期(脏)数据覆盖。当然,这名 一致性随后在服务端达成的一致性。终端和服务端对占用同一张卡达成的一致性难题,需用另外的分布式一致性方案并能补救。

《阿里Java开发规范》应该是众多程序猿多年来,在使用Java的过程中,根据踩过的雷趟过的坑,总结出来的“血的教训”或“踩坑手册”。但就像《葵花宝典》,即便是读过一百遍也成功自宫,随后见得能马需用成为武林高手,机会没练过。搞软件工程就像练武功需用实操,都并能并能 实战经验没能成为高手。评判是都会高手的标准是哪此?机会仅从软件工程的厚度看,一阵一阵要的这名随后交付的软件在各种高业务压力、异常状态下压不垮、跑不死、业务正常运行。而新手往往没能做出原来健壮的系统,机会健壮的系统需用规避无数的雷和坑。机会我想知道哪此机会处在的原来或那样的坑或雷,自然谈不上填上哪此坑、避开哪此雷。随后,就算在书本或规范上看过哪此“宝典”,也知道哪此坑的处在,但都并能并能 跌坑踩雷的亲身经历,在碰到跌坑踩雷的场景时,也机会忽略而忘记“宝典”中的“金玉良言”。为哪此会忽略、为哪此会不够重视,机会你都并能并能 真的痛过。痛过并能性心智心智成熟是什么是什么期期的句子的句子是什么是什么是什么图片 ,相信我,这是真的^o^

很多很多,聊一聊为哪此会有原来的开发条例,机会不按规范来机会出现哪此难题,了解转过身的故事,机会比读一百遍规范来得更有效果。

到底哪此是“更新丢失”呢?到底会导致 着多严重的难题?初看这名 描述,说实话这名感觉都并能并能 ,机会你都并能并能 碰到过例如并发难题导致 着的严重事故,看过这条规范后,共要率状态下该踩的雷还得踩。

从我碰到的出镜率比较高的难题开始,分享一下开发系统中遇到过的场景。

> 【6.11】【强制】并发修改同一记录时,补救更新丢失,需用加锁。要么在应用层加锁,要么在缓存 加锁,要么在数据库层使用乐观锁,使用 version 作为更新妙招”。