(传统企业电商峰值系统应对实践.docVIP

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

摘要:双11这样的场景要求电商对系统进行合理的峰值架构设计,以保证业务的顺利开展。那么一个能够应对短时间流量暴涨的电商系统,在同时考虑成本因素的情况下,具体会遇到哪些瓶颈,主要需要解决哪些层面的技术障碍呢? 近年来,随着电子商务交易额在社会消费品零售总额中占比的不断提升,电子商务越来越成为传统企业不可忽视的销售渠道之一,甚至很多具备前瞻性眼光的传统企业,已开始了利用电子商务手段改造其线下业务的探索。 但是,传统企业在执行电子商务项目的过程中,特别是在应对峰值方面,由于对互联网峰值架构的不熟悉,经常出现一些认识上的误区,造成系统上线后出现不稳定甚至连续宕机的情况,不但在经济上造成损失,而且对企业的品牌也造成了伤害。 作为电子商务技术与服务提供商,商派已执行了近千个传统企业的电商项目,收获了很多的经验与教训。下面我们就传统企业电商峰值系统的设计与维护过程中常见的问题进行探讨。 在一个典型的电商系统中,核心对象主要有三个:会员、商品和订单。整个系统主要是为消费者服务,运营模型以流量与用户量为核心,流量以导入新客户为主,用户量代表着老客户的贡献。无论是大规模进行新客户获取还是老客户营销,都会给系统带来极大的压力,其中特别是限时抢购、秒杀等营销方式尤为明显,这就要求我们对系统进行合理的峰值架构设计,以保证业务的顺利开展。那么一个能够应对业务峰值的电商系统,在同时考虑成本因素的情况下,具体会遇到哪些瓶颈,主要需要解决哪些层面的技术障碍呢? 大规模查询优化 对会员与商品的大规模查询是一个常见的场景。例如,在一个秒杀系统中,在开放购买的时间点附近,会产生大量的基于会员和商品的查询请求,通常情况下,比平时的请求量会多数十倍甚至百倍,同时访问带宽也会相应大幅增加。在我们以往的运维实践中,曾经出现过由于带宽预估不足造成无法访问的情况。 应对类似的大规模查询业务,只依靠数据库的能力是远远不足的,因此,我们需要用到大量的缓存架构,将峰值的访问压力由磁盘转向内存。一般来说,商品的主数据、会员的登录,系统的Session、页面都可以采用Memcache、Redis、Varnish等KV架构进行缓存。另外,某些动态数据在特定业务场景下也可以进行缓存。例如,由于库存量在下单前只用于控制前台是否可售展示,对一致性要求不高,只要求保证最终一致性,因此也可以在此场景下使用内存进行缓存。 商品有哪些信誉好的足球投注网站和基于属性的面包屑导航等场景,在峰值下对数据库的压力也非常明显。由于该业务不具备高命中率的特征,所以缓存解决方案不适用。我们通常需要使用有哪些信誉好的足球投注网站引擎去解决,一般常见的有哪些信誉好的足球投注网站引擎解决方案有Sphinx、Lucene等。前台的应用服务器需要设计成无状态的可水平扩展架构,这样在高负载下只要通过简单地增加应用服务器即可通过负载均衡设备线性扩展前端的负载能力。 分布式架构设计 一个完整的电商系统,分为前台交易系统与后台作业系统,前后台共库是传统企业在设计电商项目时的一个常见做法。但这个做法引发了上线后的诸多麻烦。在前台交易系统处于峰值情况下,数据库本身已存在很大的压力,此时如果后台作业系统产生大规模的查询或写入请求,则很容易造成数据库无法响应。我们在很多客户案例中发现,如果前后台共库,正常非峰值情况下,每日订单数只要超过2000单,就会不同程度地出现前后台互相干扰,数据库成为主要瓶颈。此时,客户不得不在系统高峰时停止在后台作业系统上的操作,这给业务造成了很大伤害,发货延时、客服水平下降、统计不准确等情况成了家常便饭。实际上,从架构上来说,前台交易系统与后台作业系统服务的用户对象不同,前者是消费者,后者是企业内部员工,完全可以进行系统分离,两者之间采用消息队列进行异步订单传输,以隔离互相之间的影响。 当然,对于交易系统,我们也要根据业务特征进行分布式设计,提升业务扩展性、应对高负载。例如对商品货架系统、会员系统、核心交易系统、资金系统、日志系统等以高内聚、低耦合的原则进行分离,以分别根据不同的访问特征进行优化。 根据分布式架构的CAP理论,Consistency(一致性)、 Availability(可用性)和Partition tolerance(分区容忍性)最多只能同时满足两点。对于一个峰值系统而言,分布式(分区)设计是必然的,可用性也是基础要求,因此,我们只能放弃一致性要求,只达到最终一致性。不过,在一个电商系统的架构设计中,最容易出现的问题是滥用CAP原则。例如在交易过程中,后台的供应能力(库存)是至关重要的,在交易生成过程必须要保证严格一致性,而不是最终一致性,这就要求我们以事务的方式来解决。否则,虽然在架构实践中很容易达到从容应对峰值访问的目的,但超卖等伤害业务的现象必然会出现。 在分布式系统设计中,必然要求我们采用面向服务的体系结构(SOA)。但需要在设计中注意几点。第一,在峰值

文档评论(0)

34shart09 + 关注
实名认证
文档贡献者

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

1亿VIP精品文档

相关文档