本文为学习 基于云原生的秒杀系统设计思路后的读书笔记。

关于秒杀服务

  1. 秒杀活动本身是很多业务推广的重要方式之一,多数的电商类业务都会涉及这一促销方式。其活动时间短、瞬时并发十分的高,易对现有网站业务造成冲击。
  2. 秒杀最能考验系统的负载能力,瞬间涌入平时数十倍甚至更多的压力,对开发和运维都是噩梦。

秒杀服务的指导思路

秒杀的核心问题就是极高并发处理。由于系统要在瞬时承受平时数十倍甚至上百倍的流量,这往往超出系统的上限,因此处理秒杀的核心思路就是流控和性能优化。

流控

  1. 请求流控:尽可能在上游拦截和限制请求,限制流入后端的量,保证后端系统正常。因为无论多少人参与秒杀,实际的成交往往是有限的,而且远小于参与秒杀的人数,因此可以通过系统进行拦截,限制最终流入系统的请求数量,来保证系统正常进行。
  2. 客户端流控:在客户端进行访问限制,较为合适的做法是屏蔽用户高频请求,比如在网页设置5S一次访问限制,可以防止用户过度刷接口。
  3. Web端流控:针对客户端流控,稍有编程知识或者网络基础的用户而言没有作用,因此服务端流控是必要的。服务端流控的方式又很多种。现在主流的Web服务器都支持配置访问限制,可以通过配置实现简单的流控。比如:在内存或者缓存服务中加入请求访问信息,来实现访问量限制。
  4. 后端系统流控:上述做法只能限制用户的异常访问,如果正常访问的用户依然数量很大,后端系统压力依然很大甚至宕机的可能。 对于后端系统的限制,可以通过异步处理、消息队列、并发限制等方式实现。 核心思路是保证后端系统的压力在可以正常处理的水平。

系统架构优化

  1. 读取加速:秒杀活动中,数据需求一般都是读多写少。因此可以使用缓存服务对用户请求进行缓存优化,将高频的访问内容放到缓存中。对于更大规模的系统,可以通过静态文件分离、CDN服务等把用户请求分散到外围设施中,以此分担系统压力。
  2. 异步处理和排队:通过消息队列和异步调用的方式可以实现接口异步处理,快速响应用户请求,在后端有较为充足时间来处理用户操作,提高对用户的响应速度,从而提升用户体验。通过消息队列还可以隔离前端的压力,实现排队系统,在涌入大量压力的情况下保证系统可以按照正常速率来处理请求。
  3. 无状态服务设计:针对有状态服务,无状态服务更容易进行扩展,实现无状态化的服务可以在秒杀活动前进行快速扩容。

一些总结

  1. 基于服务单一职责原则,将秒杀服务同其他的服务分离出来,同时可以将秒杀服务对应的库分离。这样的好处是在秒杀服务挂掉或者卡住的时候,不会影响到其他的服务。
  2. 页面静态化,将相关资源可以提前放到CDN中
  3. 使用Nginx,放在Tomcat前面,进行负载均衡。
  4. 针对秒杀链接实现URL动态化,同时通过MD5之类的加密算法加密随机的字符串去做URL,在后台校验才能通过。
  5. 针对读多写少的情况,将相关数据放到Redis中。比如,在秒杀开始前将商品的库存加载到Redis中,让整个流程都在Redis中做,等到秒杀结束,再去异步的修改库存就可以。但是当使用Redis集群的时候,高并发的去修改Redis中的库存,就会出现问题。需要保证Redis的事务性操作。 针对Redis集群,同时可以进行主从同步、读写分离、开启持久化,保证数据不丢失。

图-抄的呢