下载文档原格式
云南化工Yunnan Chemical TechnologyMar.2018 Vol.45，No.32018年3月第45卷第3期Experion PKS系统广泛应用于工业控制领域，由于受到技术发展的限制和实际应用水平的限制，其服务器在使用过程中经常出现一些故障，轻则造成工业控制无法顺畅进行，重则造成整个系统的死机，导致无法对各种仪表数据进行及时的监控和接收。
因此，有必要对这些常见问题进行研究，并对处理方法进行深刻的探讨。
1 系统的简要介绍Experion PKS系统是一个将整个工厂的商业信息系统与生产过程控制系统统一在一个平台上的自动化系统，它高度融合了各种新的技术，采用了标准化的工业以太网信息网络，是工业自动化领域中应用最多的网络，它提供标准的以太网接口，非常容易实现对网络的扩展，可以实现各种工作站和服务器的双向通信模式，其服务器采用先进的Windows视窗管理系统，非常便于操作，且该系统软件支持升级功能，能够不断提高整个系统的性能。
该系统包含有BB控制器、C200控制器或C300控制器，每套控制器支持8个I/O机架，多达64个的IO单元，可以完成点对点的通讯功能，用来实现与服务器之间的点对点通信。
SERVER服务器主要负责将工业现场采集到的数据发送给操作站。
其还负责网络环境的搭建，对整个系统进行组态，控制整个系统的有效运行，并对其它节点的工作状态进行监督。
2 系统的各种故障及其处理1）服务器内存增长过快。
在服务器使用过一段时间后，发现内存使用在某一时间段内过快增长，造成这种现象的主要原因是服务器硬件处理器处理速度过慢、服务系统软件需要升级、操作系统需要清理。
服务器的应用软件也是出于不断更新换代的阶段，其在使用过程中，各种问题会不断的爆发，时间一长就会造成软件的执行效率低下，并最终导致内存增长过快，这需要工作人员及时对软件进行升级。
服务器采用的是windows视窗管理系统，该系统在长时间的运行后，其系统垃圾和冗余会越来越多，磁盘的系统碎片也会不断增多，这导致系统在运行中需要消耗的内存也越来越大，这需要我们定期对系统进行垃圾清理并对磁盘碎片进行整理，从而有效提高系统运行的流畅度，避免其在运行过程中消耗大量的内存。
IIS-Serveristoobusy_解决⽅法httpRuntime Server Too Busy修改⽅法：修改服务器.net配置“machine.config＂⽂件，该⽂件位于Windows系统⽬录下，如“C:\WINDOWS\\Framework\v1.1.4322\CONFIG ”，视你的⽹盘程序版本，修改对应⽬录下的 machine.config⽂件，如2.0版本⽤户就修改“C:\WINDOWS\\Framework \v2.0.50727\CONFIG”下的machine.config⽂件，查找该⽂件中的“processModel”配置段落，修改其中的字段 maxWorkerThreads="200" maxIoThreads="200"，1.1和2.0的默认段落不太⼀样，修改后的配置如下：1.1版本：<processModelenable="true"timeout="Infinite"idleTimeout="Infinite"shutdownTimeout="0:00:05"requestLimit="Infinite"requestQueueLimit="5000"restartQueueLimit="10"memoryLimit="60"webGarden="false"cpuMask="0xffffffff"userName="machine"password="AutoGenerate"logLevel="Errors"clientConnectedCheck="0:00:05"comAuthenticationLevel="Connect"comImpersonationLevel="Impersonate"responseDeadlockInterval="00:03:00"maxWorkerThreads="200"maxIoThreads="200"/>2.0版本：原来默认的是<processModel autoConfig="true"/>改为<processModel maxWorkerThreads="200" maxIoThreads="200"/>不⽤重新启动服务器就可以看到效果。
运维故障处理实例在日常的运维工作中，故障处理是必不可少的环节。
下面是一个典型的运维故障处理实例，旨在帮助读者了解故障处理的基本流程和技巧。
1. 故障现象某天早晨，公司内部系统出现大面积故障，导致员工无法正常工作。
系统页面显示“服务器繁忙，请稍后再试”的提示信息。
2. 故障分析首先，需要对故障现象进行初步分析。
根据系统页面的提示信息，可以判断是服务器繁忙导致的故障。
因此，需要进一步检查服务器是否正常运行。
其次，可以通过检查服务器的日志文件，来确定故障的具体原因。
例如，可以检查服务器的系统日志、应用程序日志等，查看是否有异常错误信息。
最后，需要对服务器进行全面的检查，包括硬件检查和软件检查。
例如，可以检查服务器的CPU、内存、磁盘等硬件是否正常，检查服务器的操作系统、应用程序等软件是否正常运行。
3. 故障处理经过检查发现，服务器的CPU使用率过高，导致系统运行缓慢。
进一步检查发现，是由于某个应用程序的运行导致的。
于是，可以采取以下措施来处理故障：首先，可以通过调整应用程序的配置参数，来降低CPU使用率。
例如，可以减少应用程序的并发连接数、缓存大小等参数，来降低CPU使用率。
其次，可以考虑对应用程序进行优化，来提高系统的运行效率。
例如，可以对应用程序进行代码优化、数据库优化等，来提高系统的运行效率。
最后，可以考虑对服务器进行升级，来提高服务器的性能和容量。
例如，可以考虑增加服务器的CPU、内存等硬件，来提高服务器的性能和容量。
4. 故障总结通过以上措施，成功解决了服务器的CPU使用率过高的问题，系统恢复正常运行。
在这次故障处理过程中，需要对故障现象进行初步分析，检查服务器的日志文件，对服务器进行全面的检查，确定故障的具体原因。
然后，采取相应的措施来处理故障，例如调整应用程序的配置参数、对应用程序进行优化、对服务器进行升级等。
总之，运维故障处理需要综合运用各种技能和工具，对故障进行快速定位和处理，以保障系统的正常运行。
TermServDevices报错导致服务器死机（远程服务使用者必读）事件类型: 错误事件来源: TermServDevices事件 ID: 1111描述：打印机 !!192.168.99.6!HP LaserJet 3050 Series PCL 5e 所需的驱动程序 HP LaserJet 3050 Series PCL 5e 未知。
登录之前，请与管理员联系，安装驱动程序。
这是第二次服务器死机，因为问题机器是一台提供数据服务的机器，没当这个时候，该机器运行相当缓慢，其它服务器不能从得到请求的数据，造成一连串的服务down掉，之前也出现了一次这样的情况，以后是系统增加的服务将系统拖死了，最后关掉之前的数据服务，机器确实快了一点，但其它的服务器依然得不到数据。
实在没办法，只有重启该机器。
但是，重启过程费了好长时间，但是最终各种服务恢复正常。
追究了一些的日志文件，未果，最终那个新增的数据同步服务成了替罪羊。
这次又出现了这个问题，这下的情形和上次类似。
看来真得彻底清查一番了。
我调出所有的系统系统日志，进行分析，结果发现：每当机器死掉之前总是出现类似的错误报告。
具体的日志信息如下：-------------------------------------------------------------------------------------------------事件类型: 错误事件来源: TermServDevices事件种类: 无事件 ID: 1111日期: 2009-3-3事件: 12:47:03用户: N/A计算机: BMC222描述:打印机 !!192.168.99.6!HP LaserJet 3050 Series PCL 5e 所需的驱动程序 HP LaserJet 3050 Series PCL 5e 未知。
登录之前，请与管理员联系，安装驱动程序。
有关更多信息，请参阅在/fwlink/events.asp 的帮助和支持中心。
电子商务平台技术使用中常见问题随着电子商务的迅速发展，越来越多的企业和个人开始利用电子商务平台进行销售和购物。
然而，随着使用电子商务平台的人数增加，用户在使用过程中也会遇到一些常见的问题。
本文将介绍一些电子商务平台技术使用中常见的问题，并提供解决方案。
1. 无法登录账户当用户尝试登录到电子商务平台时，有时会遇到无法登录的问题。
可能的原因包括忘记密码、账户被冻结、网络连接问题等。
解决此问题的方法包括重置密码、联系平台客服解决账户冻结问题、检查网络连接设置等。
2. 商品页面加载缓慢在浏览商品页面时，有时会出现加载缓慢的情况。
这可能是由于平台服务器负载过大、网络连接不稳定等原因导致的。
用户可以尝试刷新页面、换用其他浏览器、检查网络连接等方法来解决此问题。
如果问题仍然存在，建议联系平台客服进行咨询。
3. 付款遇到问题在进行在线购物时，付款环节可能会遇到一些问题。
例如，银行卡被拒绝、支付密码错误等。
解决此问题的方法包括确认输入的信息是否准确、联系银行核实付款问题等。
如果问题依然存在，建议联系电子商务平台的客服或者支付机构的客服寻求帮助。
4. 物流信息不准确在购买商品后，用户可以通过电子商务平台查询物流信息。
然而，有时物流信息可能不准确或者更新较慢。
这可能是由于物流公司更新系统不及时、运输过程中出现问题等原因导致的。
用户可以等待一段时间再次查询，或者联系电子商务平台客服进行帮助。
5. 商品与描述不符有时用户收到的商品与描述不符。
对于这个问题，用户首先应该核实自己购买的商品是否与订单一致。
如果是的话，用户可以联系电子商务平台客服解决售后问题，要求退款或者更换商品。
如果用户购物时没有仔细检查商品信息，可能需要自行承担责任。
6. 账户安全问题随着电子商务的普及，账户安全问题也变得越来越重要。
例如，账户被黑客入侵、密码泄漏等。
为确保账户安全，用户应选择强密码，定期更改密码，并注意不要共享或泄露密码信息。
如果怀疑账户被盗用，用户应尽快联系电子商务平台客服。
运维遇到的故障案例
1.硬盘故障：在一个大型的金融机构中，运维团队发现了一台服务器的硬盘故障。
该服务器包含了重要的交易数据和客户信息，并且需要24小时不间断运行。
在快速备份数据后，团队决定更换硬盘并进行数据恢复。
但是，由于硬盘故障导致的数据损坏问题，数据恢复花费了数天的时间。
2. 网络故障：在一家游戏公司中，用户反映无法登录游戏或游戏延迟严重。
运维团队调查发现，游戏服务器与数据库服务器之间的网络连接出现了故障。
团队立即采取措施修复网络连接，但在此期间，用户的游戏体验受到了很大影响。
3. 程序故障：在一家电商公司中，用户反馈支付页面无法正常显示，导致无法完成订单支付。
运维团队检查发现，服务器上的一个程序出现了故障，导致支付页面无法正常显示。
团队通过修复程序代码解决了该问题，但由于故障的出现，客户订单量减少。
4. 安全故障：在一家科技公司中，运维团队发现了一台服务器被黑客攻击，黑客成功入侵并盗窃了公司的数据。
团队立即采取措施追踪攻击来源，加强服务器安全性，并恢复数据备份。
但由于黑客入侵，公司在竞争中处于明显的劣势。
5. 负载故障：在一家在线教育公司中，用户反映视频播放卡顿、无法正常观看。
运维团队调查后发现，该视频服务器负载过高，无法承载当前的用户流量。
团队通过增加服务器数量和优化视频压缩算法等措施缓解了负载问题，但在此期间，用户体验受到了一定影响。
WAS宕机问题总结起来有以下几类：一、线程挂起导致线程池满（Thread Hang）:Hangs refer to the JVM locking up or refusing to respond.A hang can occur when:1）Your application entered an wait leak2）Excessive Synchronization cause performance problems3）A deadlock has occurred收集日志：生成JAVA CORE分析工具：IBM Thread and Monitor Dump Analyzer1、线程等待泄漏(Wait Leaks)常见的情况就是，有很多线程使用wait()方法，等待被唤醒notify（）。
但是，存在某一个线程获取到锁并且进行业务处理完成后，忘记去唤醒等待执行的进程。
这样导致的等待泄漏，从而线程挂起。
When you use the wait/notify mechanism, you typically have one or more threads blocked in the wait() call, waiting to be notified. The notifying thread is supposed to call notify() or notifyAll() to signal that waiting threads can wake up and carry on processing.A problmatic situation could occur that the notify() call is invoked before the threads go into the wait() method. In this case, the waiting threads would not be notified anymore and become stuck.So, do not forget to notify the waiting theads in you application and maks sure that the Notify action is performed after all the waiting threads are started.应对策略：notify必须发生在所有wait之前。
电商平台客服系统崩溃应急预案随着电子商务的迅速发展，电商平台客服系统成为了保证客户满意度和提升品牌形象的关键工具。
然而，由于技术原因或突发事件，客服系统可能会崩溃，给平台运营和用户体验带来严重影响。
为了应对这种突发情况，电商平台需要制定应急预案，确保能够快速有效地恢复客服系统的正常运行。
本文将就电商平台客服系统崩溃应急预案进行探讨。
一、背景概述电商平台客服系统是用户与平台进行交互、解决问题和获得服务的重要途径。
一旦系统崩溃，将导致用户无法及时获得帮助，影响用户体验及平台声誉。
同时，崩溃带来的大量问题需手工处理，极大增加人力成本和运营压力。
因此，制定应急预案成为电商平台运营的重要任务。
二、应急预案的重要性客服系统崩溃可能是由于意外故障、网络攻击、服务器故障等原因所致。
无论原因如何，制定应急预案是电商平台应对突发事件的必要措施，具有以下重要性：1. 快速恢复系统运行：应急预案将确保平台有紧急措施和备用方案来尽量减少系统崩溃对平台运营的影响，保证客服系统迅速恢复正常运行；2. 提升用户满意度：通过建立应急预案，平台可以在系统崩溃时快速通知用户，并提供替代解决方案，减少用户的困扰和失望，提升用户满意度；3. 增强品牌信誉：电商平台客服系统的稳定性直接关系到品牌形象和用户信任度。
应急预案的制定和执行将展示平台对问题的敏感程度和专业应对能力，增强品牌信誉；4. 降低经济损失：客服系统崩溃会导致用户无法及时获得帮助，从而造成用户流失和销售额下降。
制定应急预案可以最大限度地减少经济损失。
三、应急预案的制定和执行为了有效应对电商平台客服系统的崩溃，以下几个方面需要在制定和执行应急预案时予以关注：1. 预案制定团队：组建由技术、客服和管理层人员组成的团队负责预案的制定和执行。
团队成员应具备技术娴熟、应变能力强和沟通协调能力的特点；2. 崩溃报警机制：建立监测系统，监控客服系统的稳定性，一旦发现异常情况，立即触发报警机制，通知相关人员进行处理；3. 快速响应和通知：即时通知相关人员，并启动预案。
/doc/104990/1.html当你访问博客园，出现“Server Error in '/' Application.Runtime Error.”的错误时，你知道这个错误的背后是什么吗? 你也许会想，博客园怎么不设计个定制错误页面？这样的错误页面让访问者不知所措，只能抱怨“服务器出问题了”。
当出现这个问题时，我急啊!真想站到互联网上，拿着大喇叭对大家喊，我刚更新了程序或者修改了web.config的设置，在进行首次编译，在编译的同时还要处理大量的请求，忙不过来，只能拒绝请求，实际的错误信息是"Server Too Busy"，错误来自HttRuntime的RejectRequestInternal方法。
你也许会说用customErrors页面处理一下啊！可是HttRuntime已经拒绝了这个请求，重定向到defaultRedirect定制错误页面，还是被拒绝，结果就出现“Server Error in '/' Application.Runtime Error.”错误。
这个问题困扰我很长时间，当更新程序(或者修改web.config的设置、应用程序池回收、IIS重启)时，就会出现这个问题，尤其是访问高峰期，要几分种才能恢复正常，郁闷!要是在这时显示一个友好的错误显示页面，那该多好啊!今天晚上更新程序时，又遇到这个问题。
我再次下决心要解决这个问题。
要解决问题，首先要分析出为什么会出现问题。
既然是HttRuntime抛出的异常，那就从HttRuntime下手。
怎么下手呢？用强大的Reflector工具，微软这点做的不错，很多.NET类库都可以通过Reflector工具查看源代码。
通过分析HttRuntime的源代码，我找到了问题的原因，这里我简单地描述了一下：Re:定制“Server Too Busy”错误信息当请求被发送到 Worker Process时，先是由HttpRuntime的ProcessRequest方法处理，在ProcessRequest方法中，先从请求队列(RequestQueue)中获取有效的请求（GetReq uestToExecute），如果有有效的请求，就调用HttpRuntime.ProcessRequestNow进行进一步的处理。
Weblogic宕机事件定位分析段常飞Weblogic宕机,是很多运维人员的噩梦，时不时的系统挂了，而且总是找不到源头，开发说程序没有大的变动，一直很平稳呀，客户反馈，系统硬件配置已经相当高了，足以支持系统运行呀。
又把问题抛给了运维人员，必须得找出原因了。
可是怎么下手呢下面我以郑州为例来演示如何定位程序问题。
郑州市、宕机事件日志错误类型：<2016-5-9 上午11时22分13秒CST> <Error> <WebLogicServer> <BEA-000337><[STUCK] ExecuteThread: '1' for queue: ' (self-tuning)' has been busy for "3,708" seconds working on the request "Workmanager: default, Version: 0, Scheduled=true, Started=true, Started time: 3708125 ms[Cookie:JSESSIONID=yGn2XvYC6yV3nDLJHCQFyxVQLSBcpL1WmRxkhQl78nyZTpq13J8v!-8; BIGipServerPool-zhongxinduan=", which is more than the configured time (StuckThreadMaxTime) of "3,600" seconds. Stack trace:>> INFO >> Timer-3 >> >> 检查内存更新...<2016-5-9 上午11时24分21秒CST> <Warning> <Socket> <BEA-000449> <Closing socket as no data read from it on during the configured idle timeout of 5 secs><2016-5-9 上午11时26分28秒CST> <Warning> <Socket> <BEA-000449> <Closing socket as no data read from it on during the configured idle timeout of 5 secs><2016-5-9 上午11时26分28秒CST> <Warning> <Socket> <BEA-000449> <Closing socket as nodata read from it on during the configured idle timeout of 5 secs>分析原因：weblogic的线程阻塞，进而导致批量等待阻塞，最纵引起weblogic挂起现象Weblogic 线程处理的默认时间为3600s，StuckThreadMaxTime:3600。
IT人角度分析京东商城Server is too busy事件(转) 浏览: 677 评论: 3发表评论作者: 聖騎天下京东商城策划的正常折扣之后，只要满200元就五折购书活动，营销活动策划的非常成功，但是第一次活动出现无法下单或无法付款等一些问题，提示网购者错误信息为Server is too busy，然后京东商城创始人刘强东先生站在用户角度表达不满意，并且要求加三倍机器也要第二天重新开启购书促销活动，但是第二次活动继续出现Server is too busy。
纵观整个事件，不管是活动策划效果，还是京东商城或创始人刘强东先生的危机公关，以及主动透露对待信息部门的态度，都非常成功，唯一失败的是出现戏剧性的Server is too busy，也许没有这个事件京东商城的促销活动并不会引起这么大的影响，个人相信这不是事先策划过的事情，但是此事件暴露京东商城技术实力的薄弱和管理者的落伍，甚至京东商城号称要招5000名工程师等，根据这一系列的信息，我们分别从IT技术从业者和技术管理者的角度阐述一些个人的观点，希望对网络世界的我们有所启发或帮助。
(一)营销活动的前期准备及部门协同我们先围绕2011年11月1号京东商城促销购书营销活动事件展开，超低价促销的营销活动，那么有一些信息就需要运营部门和技术部门合作一起梳理：(1) 参加促销活动的商品种类、商品名称和数量等信息；(2) 促销活动的力度，持续的时间；(3) 促销活动可能会吸引多少网购者参与，并发访问量能够达到什么规模，这些要通过事先收集本站及其它竞争对手的过往数据及经验进行综合分析；(4) 网站不进行特殊的技术处理情况下，能承受多少用户并发购物，并且对不同环节进行预估，尤其京东商城的购物车应用；(5) 网站提供服务的负载均衡设备、Web应用服务器、后端应用服务器、MemCached等可正常扩容情况下，可以支撑多少购物者同时在线完成购物流程：挑选物品、添加到购物车、填写邮寄地址等信息、付款等；(6) 把第4，5步骤得出的系统能力，与营销策划活动的部门提供的可能购物者有多少进行最大值和最小值比较，计算出差值并且做好最坏打算，如何保证一定数额的购物者能正常完成购物流程，以及与运营部门商议是否可放宽促销活动的时间宽度，减少并发购物人数的概率性；(7) 评估是否有条件，以及有合理的时间和资源对策划的运营活动开发一套新的系统，以支撑运营活动的开展；(8) 对参与促销活动的物品信息及相关物品信息（比如促销为书籍，可能非促销的书籍也会购买，尤其热门书籍），优先生成静态页面储存到专门开辟的MemCached服务器中，提高对用户的响应速度和减少现有系统的负载；(9) 大型营销活动，还可能涉及CRM部门、财务部门、物流等相关部门，尤其物流涉及的仓储和配送预计能承担的负荷能力，事先告知而避免购物者下单之后抱怨物流太慢或货物质量等问题；(10) 限时大规模的促销活动，也必定会带来带宽和安全方面的问题，必须做好监测和防备DDOS攻击的能力，避免导致营销活动泡汤；(11) 运营活动结束之后，需要得到什么样的数据分析报告等，都要事先规划好，甚至预演过；相信京东商城能成为B2C领域独领风骚的公司，内部专业人士可以列出更多更详细的信息，就不继续往下，把上述可能需要大家一起梳理的信息罗列出来一部分，就是告诉大家：我们是一个整体，任何一个环节的疏忽都可能成为瓶颈而导致出问题，要把部门与部门之间配合详细描述清楚，且使营销活动参与支撑的每一个人都清楚自己要做什么，要给别人什么支持或信息，甚至通过梳理信息和商议一些做法，可以达到承载更多的购物者参与促销运营活动，并且为公司节省成本。
(二)营销活动期间出现的故障及关联信息京东商城网站大量用户出现报错信息(注：笔者也是参与购书活动的用户之一)：IT人角度分析京东商城Server is too busy事件这样大规模营销活动时，其他企业也出现类似的故障花絮，淘宝策划的双十一促销活动也一样出现过故障，而且淘宝开展促销运营活动，是整个阿里的资源都调动起来：支付宝、阿里巴巴（内称B2B）、阿里云、淘宝等子公司都有专门的技术团队参与支持，活动开始之前就早早安排好值班的人员。
而京东商城属于B2C 型电子商务，无论物品种类、数量等，还是在线购物者都是无法比拟，而且内部还称信息部，这更加证明京东商城，还是类似传统型企业，技术的积累和接受过的挑战并没那么多，为此造成营销活动出现宕机的故障也在所难免，若是说找一个人承担责任的话，那么只能套用一句俗话：一切问题的发生都是管理不当造成的，那么这个责任应该是京东商城的信息部经理承担（注：互联网行业公司一般称技术总监或CTO，像阿里巴巴是副总裁），他应该要有能力或意识提前预测可能发生的问题，以及组织架构师、开发人员、DBA、系统工程师等人员寻找应对或解决的办法。
我们继续围绕这一事件及京东商城刘强东先生微博透露的信息，先梳理知道或可猜测的信息：(1). 单一品种：图书音像类，促销方式为折扣+满200元再打五折；点评：折扣是其他图书类网站都有，且并不占优势，但是满200元再打五折非常诱人；(2). 第一次营销活动就出现Server is toow busy的问题且超严重；点评：技术人难得的挑战机会，结果是京东商城技术人的耻辱。
(3). 第一次营销活动搞砸之后，京东商城创始人刘强东要求增加三倍服务器，坚持促销的3个小时，且确保大家的订单能提交；猜测：未必真添加3倍的服务器，若真增加了，说明之前使用的服务器数量太少，没重视此事情。
(4). 第二次营销活动依然出现Server is too busy，但是相比较稍好；分析：部分网购者已经购买成功；系统有改进或优化；服务器也有增加；不少人放弃参加第二次的促销活动。
(5). 三小时促销活动订单为：数十万（注：具体数字不详），超过300W本书籍出售；推测：订单数30W-50W之间，估计是40W订单出头。
(6). 事后补偿机制：20日内我们会给所有没抢到的老用户发放高额优惠券；点评：不靠谱的做法，即使发放也不需要等待那么长时间，这也更加间接说明技术实力的薄弱。
(三) 围绕技术方面如何应对高并发根据官方微博透露出售的书籍信息，及订单数量级，我们可以再大胆猜测大概有30W-50W的网络用户在三个小时促销期内参与购买，而且是分二天完成的，相信一天的促销时间段参与购买者的数字会更低一些，不过这对于一个B2C网站而言确实并发压力不小，假设一台Web服务器能支撑5000个并发，所有用户同时间点添加书籍到购物车中，那么需要600-1000台Web服务器。
不过这只是个极端假设，真实的情况肯定不是这样。
有几个点肯定容易成为瓶颈：购物车服务、MemCached服务、订单管理服务、支付服务、数据库服务，不清楚内部具体情况，所以只能进行猜测性分析：(1). 京东商城采用购物车系统，方便网购客进行物品挑选，然后集中完成订单的模式，有区别于淘宝网的模式，为此购物车系统的压力将会非常大。
购物车系统服务涉及大量的数据添加和显示操作，甚至修改和删除，数据必须考虑先要你用内存（例如：MemCached、Redis等）方式支持物品数据的增加、修改、删除，并异步更新到数据库中，因此购物车系统需要操作的内存缓存区最好能支持分布式部署和提供数据服务的模式，否则容易成为瓶颈，若是无法水平分布式的方式扩容，那必须进行垂直扩容，不得不考虑更换内存更大及性能更优秀的服务器支持；(2).MemCached提供读服务是必须的且压力也会不小，但还必须考虑提供写操作，即数据先写入MemCached再队列方式同步到数据库；(3).队列服务，涉及到一些数据的异步执行和排队等待等事件，在电子商务领域一样非常流行和成熟的技术，鄙人曾参与一个分布式队列项目的研发，达到可以在线部署、停止、调度、监控等功能，尤其是这种网购促销活动队列尤其重要，若是能有此类技术服务，会对整个系统的有序控制非常有帮助；(4). 提供数据服务的数据库产品为SQL Server，这并不是意味着性能就差，关键是要做到：操作系统不需要的服务必须关闭，磁盘RAID要合理，数据库的设计要合理，索引组织结构要优化好，SQL Server 服务器端参数要配置和优化，重点借助Windows自带的工具就足够监控和分析数据库服务器的性能和瓶颈。
主要是数据库服务器往往不容易进行拆分，而实现水平方向的分布式部署（注释：SQL Server有一个分布式分区视图功能，可以轻易实现数据的拆分，且不需要应用做任何修改，只是性能相对而言会降低一点）。
故可对于一些静态的数据提前预存到后端的缓存系统中，减少数据库服务器的压力，提高对网购者物品信息查询的响应速度；(5). 提供Web服务的程序为.net编写的，一般做到水平扩展，然后再搭配LVS 或F5（注释：听说京东商城使用F5）实现负载均衡设备即可，Web服务层面不会成为瓶颈。
若是.net程序代码质量不高，则可能成为瓶颈，就需要更多的机器支持；实际上，.net和Java都是这样的，对程序员的编码水平相对要求较高，不是会写就行，代码质量必须保证很高系统效率才会高，否则写出来的代码会成为网站的瓶颈。
(6). 订单管理系统将会成为压力非常大的服务，需要合并订单和检查库存，分配订单到不同的仓库所在地等，建议只做订单常规的检查，至于订单分配到不同地方仓库处理等事情可以等活动结束之后的1-2个小时内再后台集中处理的模式；(7).支付服务方面，京东商场有自己的物流配送服务，且提供在线支付和货到付款的模式，具体数字不详，网络上获得的京东商城货到付款比率高达90%；小结：曾经微博mysqlops上发过一段话形容“产品、运营、技术”的三角恋关系：成功的产品需要优秀的运营团队；好的运营团队也需要优秀的产品；再好的产品和运营，也要坚如磐石的技术作支撑，否则最多是一座小洋楼；再牛的技术人要是不能服务于产品和运营，就像深锁闺房的黄花大闺女。
正确看待三者的关系，就是肯定我们大家的工作，公司或团队才可能取得巨大的成功！这次大规模的促销毕竟是京东商城的第一次真正体验互联网网购压力，多少会存在预备不足的情况，以及运营部门和技术部门衔接的信息不畅或不到位的情况，关键是出现这些问题之后，是否能借助这些经验教训，进行深刻的对内性反思且发现存在的问题，是否在高位的管理者意识到技术将成为业务发展的瓶颈，毕竟京东商城的运营团队和产品团队已经做得非常棒了，而且B2C领域的市场占有率也非常高，接下来就是如何把这些优势如何发挥得更加明显，那么就需要技术支撑了，相信京东商城2010年至今从阿里系挖了不少技术人员，以及从其他公司搜刮了不少非常优秀的技术人，不至于愿意把他们束之高阁。
