企业官网建设流程全解析

企业网站建设收费标准,网站开发的对联,建筑网站带图解,国外 素材 网站目录 一.京东/淘宝的并发 vs 普通管理系统的并发 二.为什么200人的管理系统也需要处理并发#xff1f; 1.典型场景举例#xff08;在一个订单审批CRM系统中#xff09; 三. 普通管理系统如何应对并发#xff1f; 四.总结一下 五.思考这两种“并发”的相同与不同…目录一.京东/淘宝的并发 vs 普通管理系统的并发二.为什么200人的管理系统也需要处理并发1.典型场景举例在一个订单审批CRM系统中三. 普通管理系统如何应对并发四.总结一下五.思考这两种“并发”的相同与不同这两种并发难道不是同一个意思吗本质就是防止数据不一致1.类比医疗领域2.结论这是一个非常好的问题它触及了“并发”概念的核心区别和普遍存在的误解。简单直接的答案是需要但此“并发”非彼“并发”。让我来详细解释一下。一.京东/淘宝的并发 vs 普通管理系统的并发特点京东/淘宝类电商618双11200人普通管理系统如OAERPCRM并发类型高并发、瞬时并发低并发、长时并发核心挑战海量用户数十万至数百万在同一秒抢购同一商品如茅台、iPhone瞬间冲击数据库和服务器。考验的是极限性能、系统架构、分布式能力、缓存策略、削峰填谷。几十到几百个用户在工作时间内同时在线但他们的操作分散在不同模块张三在填报表李四在批流程王五在查数据。考验的是数据一致性、业务逻辑正确性、资源锁的管理。技术焦点横向扩展如何通过加机器、负载均衡、微服务化来应对流量洪峰。防超卖如何保证10000件库存不被10001人买到。纵向设计如何设计合理的数据库事务、业务锁、会话管理保证业务规则不被破坏。用户体验保证用户操作不卡顿、数据不混乱。类比春运火车站几万人同时涌向几个检票口目标是瞬间疏散。公司办公楼200人同时在各办公室工作使用打印机、会议室等共享资源需要有序协调。二.为什么200人的管理系统也需要处理并发这里的并发主要指“多个用户可能同时操作同一份数据或资源”。如果不做处理会产生严重问题1.典型场景举例在一个订单审批CRM系统中“丢失更新”问题上午10:00销售A和销售B同时打开了同一个客户“XX公司”的资料页当前订单额为100万。销售A谈成了一笔10万的订单在系统里将订单额更新为100 10 110万然后保存。几乎同时销售B也谈成了一笔5万的订单在他打开的页面上看到的还是100万他更新为100 5 105万然后保存。结果销售A的更新被覆盖了数据库里最终是105万而不是正确的115万。业务逻辑冲突库存管理系统里某商品只剩最后1件。用户甲和用户乙同时点击“购买”。如果不加锁控制系统可能判断两个请求的库存都 0导致超卖卖出2件这和在京东抢茅台的本质是一样的只是规模小。数据一致性问题财务系统中会计A正在生成某部门的月度汇总报表需要读取大量数据。与此同时会计B正在修改该部门刚上报的一笔支出。如果不做隔离会计A拿到的报表可能包含部分旧数据和部分新数据导致报表不准确。三. 普通管理系统如何应对并发不需要像电商那样搭建复杂的分布式架构但需要在应用层和数据库层进行精心设计数据库事务将一组相关操作如扣库存、创建订单放在一个事务里保证其原子性。悲观锁最直接的方式。在操作数据前先锁定如SELECT ... FOR UPDATE。比如“审批流程”中一个人批的时候锁定这条申请防止多人重复审批。乐观锁更高效的方式。在数据表加一个版本号字段version。更新时检查当前版本号是否和读取时一致一致则更新并增加版本号不一致则告知用户“数据已变更请刷新重试”。这非常适合上述“丢失更新”场景。队列化处理对于某些可能冲突的核心操作如发放唯一编号采用内存队列或数据库作业队列让其顺序执行。合理的会话和状态管理确保用户操作状态清晰避免重复提交。四.总结一下并发无处不在只要有多个用户可能同时操作共享资源就需要考虑并发控制。规模决定方案京东淘宝解决的是海量、瞬时、集中的并发是“量变引起质变”的架构级挑战。普通管理系统解决的是低频、分散、业务逻辑的并发是设计严谨性的挑战。本质相同两者都要保证“数据一致性”和“业务正确性”。区别在于应对的规模和采取的技术手段不同。所以开发一个200人的管理系统绝对不能忽视并发问题。虽然不需要应对“秒杀”场景但必须处理好“多个用户同时修改一个客户信息”、“同时申请同一间会议室”、“同时审批同一张报销单”这类看似普通但隐患巨大的并发场景。否则系统上线后就会出现各种数据错乱、流程混乱的“灵异事件”。五.思考这两种“并发”的相同与不同这两种并发难道不是同一个意思吗本质就是防止数据不一致问到了本质——它们的核心目标确实是同一个防止数据不一致。但这是一个绝佳的观察正好揭示了软件工程中一个深刻的道理同一个根本问题在不同规模和场景下会演变成完全不同性质的挑战导致解决方案天差地别。1.类比医疗领域说白了就是两种并发目的一致都是为了保持数据一致角度不同一个是防止海量数据打瘫后端服务导致超卖另一个是防止脏读等情况导致数据不一致核心目标问题根源表现症状解决方案技术复杂度普通感冒恢复健康病毒感染上呼吸道打喷嚏、流鼻涕、喉咙痛休息、多喝水、吃点感冒药家庭护理级别重症肺炎恢复健康严重感染肺部导致呼吸衰竭高烧、剧烈咳嗽、呼吸困难、血氧下降ICU监护、高流量氧疗、强力抗生素、呼吸机多学科重症医疗团队电商大促并发数据一致性海量请求瞬间冲击单点资源超卖、服务崩溃、响应超时分布式架构、缓存、削峰、限流、熔断架构师、分布式专家管理系统并发数据一致性多个会话竞争同一数据行更新丢失、脏读、业务逻辑错误数据库事务、行锁、乐观锁、队列高级开发工程师2.结论所以你最初的直觉“本质就是防止数据不一致”是完全正确的。这正是计算机科学中“并发控制”理论的统一目标。但工程实践的魅力在于当冲突规模小N2时这是一个“算法正确性”问题。我们用锁、事务这些严谨的“计算机科学”工具来解决。当冲突规模巨大N100,000时它首先变成了一个“系统生存”问题其次才是正确性问题。我们不得不用“架构艺术”——拆分、缓存、异步——来改变游戏规则把一个“排队问题”转变为一个“分发和缓冲问题”。因此我们可以说普通管理系统的并发是并发问题的“经典形态”。它要求开发者深入理解数据库原理和事务隔离级别。电商大促的并发是并发问题的“极限形态”。它要求架构师具备分布式系统设计能力为了性能和可用性有时需要在“强一致性”上做出妥协转而追求“最终一致性”。作为开发者理解前者是基础是必修课了解后者是视野的拓展知道当业务规模爆炸式增长时世界会变成什么样子。两者相辅相成构成了对“并发”这一核心概念的完整理解。以上就是本篇文章的全部内容喜欢的话可以留个免费的关注呦~~~