PHP实现秒杀设计

工具

压测工具

yum -y install httpd-tools
ab -V
# 检测接口最大qps
# -c 并发请求数, -n 总共访问次数
ab -n 100 -c 10 http://xxx
Requests per seconds: 101.15[#/sec](mean)

1. 查看接口是否仍有优化空间, 确保接口性能达到单机最佳
2. 若已达到最佳状态, 还需要对接口进行限流, 确保服务不会因为流量暴增而雪崩

特点

抢购人数远多于库存, 读写并发巨大

库存少, 有效写少 ( 抢购虽多, 但是形成有效订单少 )

写需强一致性, 商品不能卖超 ( 确保库存和订单数一致 )

读强一致性要求不高

难点

稳定性难

1. 高并发下, 某个小依赖可能直接造成雪崩
2. 流量预期难精准, 过高也造成雪崩
3. 分布式集群, 机器多, 出故障概率高
   减少第三方依赖, 同时自身服务部署也需做到隔离
   压测, 降级, 限流方案, 确保核心服务可用
   需健康度的检查机制, 整个链路避免单点

准确性难

库存, 抢购成功数, 创建订单数之间的一致性

高性能难

有限成本下需要做到极致的性能
缩短单请求访问路径, 减少IO
减少接口数, 降低吞吐数据量, 请求次数减少

需求

扣库存

预扣库存实现方案:

1. 先扣库存, 然后创建订单, 支付
2. 10分钟内不支付则取消订单, 避免不支付库存卖不出问题

无IO:

1. 拆解, 扣库存与写订单分开
2. 用内存
3. 用本地内存
   

读商品信息

排队进度查看

读库存

原理

减而治之

CDN原理

CDN, 内容分发网络 ( Content Delivery Network)

1. 缩短访问路径, 减少源站压力, 提高内容响应速度
2. 为源站提高安全保护
   减少读的压力( 把订单详情页内容通过CDN下发到不同的节点 )
   
   
   
   

Nginx限流

1. 按连接数限速, 即并发数 ( ngx_http_limit_conn_module )
2. 按请求速率限速, 根据IP限制单位时间内的请求数 ( ngx_http_limit_req_module )

# 配置
vim /etc/nginx/nginx.conf
# 在http模块里
http {
	...
	# 创建规则, 名称mylimit, 以用户的IP地址为key来限制请求速率1r/s, 申请空间为10m
	limit_req_zone $binary_remote_addr_zone=mylimit:10m rate=1r/s;
	...
	server {
		...
		# 应用规则, 在location里
		location ~\.php$ {
			# burst缓存空间, 若没有该参数, 则会严格按照上面限制来执行, 超过其限制速率就会拒绝访问, 返回503错误, 若有该参数, 即设置了缓存空间, 超过其限制速率不会直接拒绝而是排队等待, 若缓存空间设置的比较大, 后边的请求会一直排队, nodelay参数就是应对突发流量时, 减少后边等待时间, 即1s允许2个请求
			limit_req_zone=mylimit burst=1 nodelay;
		}
	}
}
# 重启 nginx
/usr/sbin/nginx -s reload
# 查看进程
ps aux | grep nginx
# 错误日志
tail -f /var/log/nginx/error.log

限流算法

1. 令牌桶算法
   

2. 漏桶算法
   

3. 计数器
   单位时间计数器计数即可, 一般在应用程序中写的较多

异步队列

消息队列实际为链表, 头插尾出, 先进先出, 高并发下容易发生堵塞, 为避免消息丢失, 可通过写入实时消息队列进行延时处理
实时队列: 根据数据插入的前后顺序, 依次取出

延时队列: 不根据数据插入的前后顺序来依次取出, 而是根据指定某事件在某时间触发的权重机制来取出, 根据触发时间排序

1. 提高请求响应速度, 如: 创建订单后的流程, 发push, 短信提醒等
2. 瞬间高并发下, 可起到削峰, 如: 双十一零点并发创建订单
3. 延时队列, 时间维度任务触发, 如: 发货提醒

分而治之

Nginx负载均衡

算法

1. Round-robin (轮询)
2. Weight-round-robin (带权轮询), 推荐
   
3. IP-hash (IP哈希)

链路实现漏斗型流量

读优化

1. 读商品信息页优化
   
2. 读库存优化
   

写优化

1. 扣库存优化