《大型网站技术架构：核心原理与案例分析》读书笔记-案例分析

网购秒杀系统架构设计案例分析

 

秒杀是电子商务网站常见的一种营销手段：将少量商品（通常只有一件）以极低的价格，在特定的时间点开始出售。比如一元钱的手机，五元钱的电脑，十元钱的汽车等。 因为商品价格诱人，而且数量有限，所以很多人趋之若鹜，在秒杀活动开始前涌入网站， 等到秒杀活动开始的一瞬间，点下购买按钮（在此之前购买按钮为灰色，不可以点击），抢购商品。这些商品因为在活动开始的一秒内就被卖光了，所以被称作秒杀。

1.秒杀活动的技术挑战

1.1假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就是说最大并发请求数是10,000，秒杀系统需要面对的技术挑战有如下几点。

a.对现有网站业务造成冲击:秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。

b.高并发下的应用、数据库负载:用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成极大的负载压力。

c.突然增加的网络及服务器带宽:假设商品页面大小200K (主要是商品图片大小），那么需要的网络和服务器带宽是2G ( 200KX 10,000 )，这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。

d.直接下单:秒杀的游戏规则是到了秒杀时间才能开始对商品下单购买，在此时间点之前，只能浏览商品信息，不能下单。而下单页面也是一个普通的URL,如果得到这个URL，不用等到秒杀开始就可以下单了。

1.2秒杀系统的应对策略

为了应对上述挑战，秒杀系统的应对策略有如下几点。

a.秒杀系统独立部署

为了避免因为秒杀活动的高并发访问而拖垮整个网站，使整个网站不必面对蜂拥而来的用户访问，可将秒杀系统独立部署；如果需要，还可以使用独立的域名，使其与网站完全隔离，即使秒杀系统崩溃了，也不会对网站造成任何影响。

b.秒杀商品页面静态化

重新设计秒杀商品页面，不使用网站原来的商品详情页面，页面内容静态化：将商品描述、商品参数、成交记录和用户评价全部写入一个静态页面，用户请求不需要经过应用服务器的业务逻辑处理，也不需要访问数据库。所以秒杀商品服务不需要部署动态的Web服务器和数据库服务器。

c.租借秒杀活动网络带宽

因为秒杀新增的网络带宽，必须和运营商重新购买或者租借。为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽。                                                         .

d.动态生成随机下单页面URL

为了避免用户直接访问下单页面URL,需要将该URL动态化，即使秒杀系统的开发者也无法在秒杀开始前访问下单页面的URL。办法是在下单页面URL加入由服务器端生成的随机数作为参数，在秒杀开始的时候才能得到。

2.秒杀系统架构设计

商品页面中的购买按钮只有在秒杀活动开始的时候才变亮，在此之前及秒杀商品卖出后，该按钮都是灰色的，不可以点击。

下单表单也尽可能简单，购买数量只能是一个且不可以修改，送货地址和付款方式 都使用用户默认设置，没有默认也可以不填，允许等订单提交后修改；只有第一个提交 的订单发送给网站的订单子系统，其余用户提交订单后只能看到秒杀结束页面.

除了上面提到的秒杀系统的技术挑战及应对策略，还有一些其他问题需要处理。

2.1如何控制秒杀商品页面购买按钮的点亮

购买按钮只有在秒杀活动开始的时候才能点亮，在此之前是灰色的。如果该页面是动态生成的，当然可以在服务器端构造响应页面输出，控制该按钮是灰色还是点亮，但是为了减轻服务器端负载压力，更好地利用CDN、反向代理等性能优化手段，该页面被设计为静态页面，缓存在CDN、反向代理服务器上，甚至用户浏览器上。秒杀开始时，用户刷新页面，请求根本不会到达应用服务器。

解决办法是使用JavaScript脚本控制，在秒杀商品静态页面中加入一个javaScript文件引用，该JavaScript文件中加入秒杀是否开始的标志和下单页面URL的随机数参数， 当秒杀开始的时候生成一个新的JavaScript文件并被用户浏览器加载，控制秒杀商品页面的展示。这个javaScript文件使用随机版本号，并且不被浏览器、CDN和反向代理服务器缓存。如图12.3所示。

这个JavaScript文件非常小，即使每次浏览器刷新都访问JavaScript文件服务器也不会对服务器集群和网络带宽造成太大压力。

2.2如何只允许第一个提交的订单被发送到订单子系统

由于最终能够成功秒杀到商品的用户只有一个，因此需要在用户提交订单时，检査是否已经有订单提交。事实上，由于最终能够成功提交订单的用户只有一个，为了减轻下单页面服务器的负载压力，可以控制进入下单页面的入口，只有少数用户能进入下单页面，其他用户直接进入秒杀结束页面。假设下单服务器集群有10台服务器，每台服务器只接受最多10个下单请求，如图12.4所示。

秒杀系统的整体架构如图12.5所示。

小结

秒杀是对网站架构的极大考验，在难以预计和控制的高并发访问的冲击下，稍有不慎，系统就会被用户秒杀，导致整个系统宕机，活动失败，构成重大事故。因此在遵循秒杀活动游戏规则的基础上，为了保证系统的安全，保持适度的公平公正即可。即使系统出了故障，也不应该给用户显示出错页面，而是显示秒杀活动结束页面，避免不必要的困扰。

 

 

大型网站典型故障案例分析

1.写曰志也会引发故障

故障现象：某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用空间低于警戒值，并且很快有服务器宕机。登录到线上服务器，发现log文件夹里的文件迅速增加，不断消耗磁盘空间。

原因分析：这是一个普通的应用服务器集群，不需要存储数据，因此服务器里配置的是一块100GB的小硬盘，安装完操作系统、Web服务器、Java虚拟机、应用程序后， 空闲空间只有几十GB 了，正常情况下这些磁盘空间足够了，但是该应用的开发人员将log 输出的level全局配置为Debug。这样一次简单的Web请求就会产生大量的log文件输出， 在高并发的用户请求下，很快就消耗完不多的磁盘空间。

经验教训：

•应用程序自己的日志输出配置和第三方组件日志输出要分别配置。

•检査log配置文件，日志输出级别至少为Warn，并且检査log输出代码调用，调用级别要符合其真实日志级别。

•有些开源的第三方组件也会不恰当地输出太多的Error日志，需要关闭这些第三方库的日志输出，至于哪些第三方库有问题，只有在遇到问题时才知道。

2.高并发访问数据库引发的故障

故障现象：某应用发布后，数据库Load居高不下，远超过正常水平，持续报警。

原因分析：检査数据库，发现报警是因为某条SQL引起的，这条SQL是一条简单的有索引的数据査询，不应该引发报警。继续检査，发现这条SQL执行频率非常高，远远超过正常水平。追査这条SQL,发现被网站首页应用调用，首页是被访问最频繁的网页， 这条SQL被首页调用，也就被频繁执行了。

经验教训：

•首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。

•首页最好是静态的。

3.高并发情况下锁引发的故障

故障现象：某应用服务器不定时地因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。

原因分析：程序中某个单例对象（singleton object)中多处使用了 synchronized (this )，

由于this对象只有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都 是一些简单操作，获得锁，迅速完成操作，释放锁，不会引起线程排队。但是某个需要远程调用的操作也被加了 synchronized (this )，这个操作只是偶尔会被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完后释放锁，其他线程迅速执行，超时解除。

经验教训：

•使用锁操作要谨慎。

4.缓存引发的故障

故障现象：没有新应用发布，但是数据库服务器突然Load飙升，并很快失去响应。 DBA将数据库访问切换到备机，Load也很快飙升，并失去响应。最终引发网站全部瘫痪。

原因分析：缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段，丢失一些缓存也没什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。结果这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的十几台Memcached服务器，导致网站全部瘫痪的重大事故。

经验教训：

•当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

5.应用启动不同步引发的故障

故障现象：某应用发布后，服务器立即崩溃。

原因分析：应用程序Web环境使用Apache+JBoss的模式，用户请求通过Apache转发JBoss。在发布时，Apache和JBoss同时启动，由于JBoss启动时需要加载很多应用并初始化，花费时间较长，结果JBoss还没有完全启动，Apache就已经启动完毕开始接收用户请求，大量请求阻塞在JBoss进程中，最终导致JBoss崩溃。除了这种Apache和JBoss启动不同步的情况，网站还有很多类似的场景，都需要后台服务准备好，前台应用才能启动，否则就会导致故障。这种情况被内部人戏称作“姑娘们还没穿好衣服，老鸨就幵门迎客了”。

经验教训：

•老鸨开门前要检査下姑娘们是否穿好了衣服。就本例来说，在应用程序中加入一个特定的动态页面（比如只返回0K两个字母），启动脚本先启动JBoss，然后在脚本中不断用curl命令访问这个特定页面，直到收到0K，才启动Apache。

6.大文件读写独占磁盘引发的故障

故障现象：某应用主要功能是管理用户图片，接到部分用户投诉，表示上传图片非常慢，原来只需要一两秒，现在需要几十秒，有时等半天结果浏览器显示服务器超时。

原因分析：图片需要使用存储，最有可能出错的地方是存储服务器。检査存储服务器，发现大部分文件只有几百ICB，而有几个文件非常大，有数百兆，读写这些大文件一次需要几十秒，这段时间，磁盘基本被这个文件操作独占，导致其他用户的文件操作缓慢

经验教训：

•存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。

7.滥用生产环境引发的故障

故障现象：监控发现某个时段内，某些应用突然变慢，内部网络访问延迟非常厉害。

原因分析：检査发现，该时段内网卡流量也下降，但是没有找到原因。过了一阵子才知道，原来有工程师在线上生产环境进行性能压力测试，占用了大部分交换机带宽。

经验教训：

•访问线上生产环境要规范，不小心就会导致大事故。

网站数据库有专门的DBA维护，如果发现数据库存在错误记录，需要进行数据订正， 必须走数据订正流程，申请DBA协助。于是就有工程师为避免麻烦，直接写一段数据库更新操作的代码，悄悄放到生产环境应用服务器上执行，神不知鬼不觉地订正了数据。 但是如果不小心写错了SQL,后果可想而知。

8.不规范的流程引发的故障

故障现象：某应用发布后，数据库Load迅速飙升，超过报警值，回滚发布后报警消失

原因分析：发现该应用发布后出现大量数据库读操作，而这些数据本来应该从分布式缓存读取。检査缓存，发现数据已经被缓存了。检査代码，发现访问缓存的那行代码 被注释掉了。原来工程师在开发的时候，为了测试方便，特意注释掉读取缓存的代码， 结果开发完成后忘记把注释去掉，直接提交到代码库被发布到线上环境。

经验教训：

•代码提交前使用diff命令进行代码比较，确认没有提交不该提交的代码。

•加强code review,代码在正式提交前必须被至少一个其他工程师做过code review, 并且共同承担因代码引起的故障责任。

9.不好的编程习惯引发的故障

故障现象：某应用更新某功能后，有少量用户投诉无法正常访问该功能，一点击就显示出错信息。

原因分析：分析这些用户，都是第一次使用该功能，检査代码，发现程序根据历史使用记录构造一个对象，如果该对象为null，就会导致NullPointException。

经验教训：

•程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判 断。

•程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象（使用空对象模式)。