在简历上写“精通秒杀系统”之后...
1、前台
静态资源
未处理的海量请求
前台是整个秒杀系统第一次直面海量请求的部位。因此,前台遇到的请求数是“原汁原味”的,是没有经过任何处理的。并且在全部的用户请求中,除了正常的请求以外,还可能存在各种无效或非法请求,举例如下:
可见在整个秒杀活动期间,实际的请求数量要远远大于潜在的用户数量。前台页面就是整个秒杀系统承受流量的第一道防线。
用户在等待秒杀开始的前几秒,可能会反复刷新页面;
抢单机器人甚至会进行毫秒级的轮询抢单。
如何在前台限流,尽力守卫后台服务器和数据库服务器?
2 、后台服务器
数据的准确性。例如超卖问题、并发一致性问题等。
超卖问题。即如何避免“用户成功下单的数量 > 秒杀商品的库存数量”?在处理超卖时,还要考虑一些不良的恶意行为。例如,如果竞争对手故意将商品抢到手但却不付款,该如何处理?
并发环境下的一致性问题。如果使用了缓存,如何保证缓存的一致性?如果使用了分布式,如何保证分布式事务的一致性?
数据的时效性
除了要在并发环境下保证数据的准确性以外,秒杀系统还要控制数据的时效性。例如,用户在下单后,系统务必要在几秒内返回结果,保证用户体验。
系统的可用性
为了防止单节点故障,保证系统的高可用性,就需要将秒杀系统部署在由多个节点组成的集群上。集群如何搭建?应该依据什么将海量请求分流到集群中的不同节点上?在机房部署集群时,应该如何具体划分?
系统的稳定性
除了高可用以外,我们也应当尽力提高集群中各个节点的性能。高并发会导致部分节点的性能下降,甚至造成某些节点的崩溃。我们如何在有限的硬件条件下,提高单节点的性能,从而提高整个集群系统的稳定性?
作为系统的设计者,我们还应当思考:即使我们尽力准备了一切,但如果秒杀服务在极端情况下仍然无法满足海量请求的冲击,是否会对电商平台中物流、客服等其它服务造成影响?即,秒杀服务只是整个电商系统中的一个子系统,我们应该在为秒杀服务做好充足准备的同时,再为整个系统留一条退路。
3 、数据库服务器
并发量
对于一般的单节点关系型数据库来说,仅仅能够稳定的支撑千位数的并发量。因此在高并发环境中,往往最先遇到并发瓶颈的就是数据库。简言之,数据库是整个系统最重要的一环,但同时又是并发能力较弱的一层。
并发数
当海量请求经过了前台和后台的重重拦截抵达数据库时,必然会产生并发问题。那么,应该如何既避免并发带来的问题,又能高效进行数据存储呢?
存储容量
一个关系型数据库的存储容量有限。对于大型电商平台而言,是无法将全部的数据保存到同一个数据库中的。那么,数据应该如何存储?存储后,如何保证数据库的高可用?