秒杀or红包

应对--短时峰值流量

超卖问题 100w人抢3件 结果有三百人抢成功了

秒杀

• 10W人在12：00：00时间抢购3件商品
• B/S架构--浏览器 /服务器架构 --大部分的逻辑会压在后端
• 前端展示的东西都要从后端获取

问题

• 浏览器加载问题--网路带宽（尤其是服务器的网络带宽）

  • 1Mbps 网络带宽 1000Mbps的 125MBps
  • 商品有图片 10张 共1MB大小 同时有100人访问这个页面-》 带宽就跑满了
  • 资源静态化-》cdn 内容分发网络 图片 css js 等存入到cdn oss

• 保证准时秒杀

  • 修改自己的本地时间-》很有用-》获得服务器时间
  • 篡改网络时间-》改包-》http的前提下还是存在的-》https来避免
  • 提前拿到了你的秒杀连接-》后端做时间验证 连接的动态化

• 用机器抢的

  • 验证码-》必然降低用户体验
  • 加一些验证信息--token

• 处理请求

  • 3W同时进来了
    • 2核4g的tomcat -》500-600请求/s
  • 配置 50-60节点 前面挂上nginx集群
    • 贵
    • 不好管理的呀
    • 很难确定到底谁先到谁后到
  • mq->10
  • redis

• 秒杀模块和其他模块分开部署

红包

点对点红包

• 和转账一样 保证事务即可

群红包

• 和秒杀就很类似
  • mq
  • redis
• 假如 同一时刻 有三个请求进入 -就剩最后一个了怎么办
• 防止抢到最后没有钱了 手气红包
  • 先给一分
• 让先抢和后抢 概率上钱差不多
  • 给一个正态分布曲线公式

摇一摇红包-春晚红包

• 流量很大
• 奖品种类丰富