快递系统高并发优化设计.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
快递系统高并发优化设计

快递系统高并发优化设计   摘 要:随着电子商务市场的蓬勃发展带动了传统快递业务量的急速上涨,由此剧增的业务数据传输、处理、查询成为了快递业提升服务品质的新瓶颈。本文为解决大型信息处理系统中高性能、大吞吐量和高并发?稻莸挠呕?问题,从软件架构、数据架构、高可用三个方面阐述如何提高系统的整体性能,以保证大用户量高并发访问系统时仍然具有良好的用户体验,以及高可用和高可靠性。   关键词:高并发;优化设计;大用户量   引言   我国于2006发布的《物流术语》中给快递定义是:承运人将文件或货物从发件人所在地通过承运人自身或代理的网络送达收件人手中的一种快速的运输服务方式[1]。快递是突出物流服务中运输功能的一个特别版本,是针对物流中零散、快速、精确派送部分的一个具体体现。   快递行业是一个既传统又新兴的行业,说起传统其是典型的劳动密集型行业,跟大型工厂仓库有不少类似,说起新兴是因其随着互联网购物等新兴需求使得市场不断扩大而蓬勃上升。其市场规模2008年仅0.13万亿,据国家邮政局6月24日发布的《2016年度快递市场监管报告》显示,2016年中国快递业务量达到了312.8亿,同比增长51.4%[2]。电子商务市场的高速增长产生了大量的快递需求,尤其是C2C电商,对第三方快递的依赖几乎是 100%。快递业务量的急剧增长使得业务员要计划和管理越来越多的数据[3-4]。业务快速增长,如果无法在短时间内处理完成必然引起公司的运营效率降低,导致无法及时完成快递业务,又必然引起客户的不满,继而影响自身信誉及后续业务[5]。   1业务场景分析   与电商围绕用户行为和商户或商品维护不同,物流快递系统里围绕的基本就只有运单。但是物流快递有其特殊性,以及传统行业难以避免的历史遗留问题,所以在一个运单的生命周期内有好几个变体,简单说来业务上是1收件(包括电商来的订单可以看作是预备的运单)、2发件(门店主要靠定期来回于门店与转运中心之间的班车来将收件以后的快递件传递给上级门店、本区域的中心门店或最终达到本区域转运中心)、3到件(发件方区域转运中心发往收件人一方所在区域的转运中心乃至具体门店)、4派件(具体门店分配具体人员进行快递件的最终派送)、签收(收件人签收快递件,最终完成整个生命周期)。其中每一处人员接手都有相关操作记录,每一次涉及车辆的运输操作都会有每件快递件的扫描记录操作乃至将多个小件打包后的包裹记录的扫描记录操作。车辆相关操作可能大都集中在前后半夜的几个小时内,而且是一边一些地方有发车装货扫描、一边一些地方有到车卸货扫描,而人员操作主要集中在每天早上上班的1、2小时内的早高峰阶段、以及晚上下班发件方门店收到件以后,集中进行快递件收件确认的操作,这几个时间点,在数千家网店的物流快递公司内,都会短时间产生大量的并发压力,这就是本文所要分析并优化的问题。   2高并发设计   当前大多数业务系统都基于B/S架构或者基于前端APP或本地gui+后端接口的架构,其本质都是以HTTP通信协议为基础,可以将架构简化为前端+http接口+后端业务逻辑+后端其它组件。   2.1前端架构   前端的关键是清晰的功能和贴心的用户体验,其次才是绚丽的界面。业务逻辑设计上前端主要处理view层从后端接口下载的数据,然后承载、小部分情况下缓存在本地,最终显示。在需要的时候编辑相关数据,然后作为接口参数回发给后端接口以便后端处理复杂的业务逻辑,而前端在这个过程中主要是初期验证回传数据(确保调用后端接口前数据尽量是有效的,以免太多无意义的后端处理)和在大并发业务场景下某些场景的操作频率限制,比如运单录入时候(收件),调用后端报价与折扣接口,按照某物流公司门店4千左右,单门店同时调取报价接口的设备以5个计算,设极端情况下50%客户端同时访问后端为例,该场景点的性能极端情况瞬间就达:4000*5*0.5=1w的访问次数,假设后端的处理能力是1k每秒,这样集中的请求需要10秒以上的时间来处理,那么可选的限制操作首先就是不允许重复使用这个功能,每5-10秒才允许使用一次,这样确保尽量在短时间内不会对后端产生太大的压力,其次可以在请求后端接口前随机增加若干秒的延迟,这样也能大大降低极端情况下的压力。   2.2后端架构   后端的软件架构其设计上要遵循的原则颇多。   (1)容器无状态:最基础的业务容器的无状态,常见的实际场景就是作为后端入口的http接口,这里所说的业务容器主要是指的iis这类,当然能够独立不需要外部webserver就能直接提供http服务的比如.net的owin规范的hostself的独立exe方案来处理高并发短连接的http请求。之所以要保证无状态是为了业务容器这一层可以配合负载均衡手段达到理论上无限扩展实例,以期横向扩展性

文档评论(0)

189****7685 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档