文章目录
  1. 1. 背景
    1. 1.1. 为什么要构建一个高并发场景下的后端系统?
  2. 2. 设计思路
    1. 2.1. 设计层面需要考虑的Points
      1. 2.1.1. Point1:静态页面设计
      2. 2.1.2. Point2:动态页面设计
      3. 2.1.3. Point3:高可用(双活)
      4. 2.1.4. Point4:高并发(负载均衡,安全过滤)
      5. 2.1.5. Point5: 数据库设计注意静态配置和动态数据分离
      6. 2.1.6. Point6:缓存雪崩
      7. 2.1.7. Point7:缓存击穿
      8. 2.1.8. Point8:脱离原站点部署
        1. 2.1.8.1. 分业务分布式部署
        2. 2.1.8.2. 分容器分布式部署
      9. 2.1.9. Point9:监控+监控+监控(总要事情说三遍!)
    2. 2.2. 大厂的成熟解决方案
    3. 2.3. 个人开发者/创业公司的解决方案
  3. 3. 研发策略
    1. 3.1. 一、认清业务的环境、形式
    2. 3.2. 二、分析业务的状态
      1. 3.2.1. 商品/奖品展示层
        1. 3.2.1.1. 技术细节
      2. 3.2.2. 用户登记层
        1. 3.2.2.1. 技术细节
          1. 3.2.2.1.1. token加/解密(加密协议自己拟订)
          2. 3.2.2.1.2. ajax跨域(常用jsonp)
      3. 3.2.3. 数据接入层
        1. 3.2.3.1. 技术细节
          1. 3.2.3.1.1. 数据校验
          2. 3.2.3.1.2. 存入nosql消息队列
      4. 3.2.4. 数据处理层
        1. 3.2.4.1. 技术细节
    3. 3.3. 三、根据状态进行代码模块层面的设计
    4. 3.4. 四、全量的压力测试
  4. 4. 参考文档

PS:前段时间和Mentor们一起参与研发”百度地图百城千店感恩节AR游戏送大礼”的后端项目,积累了一些高并发情景下的系统设计经验,这里统一抽象成【秒杀情景下的后端系统】,归纳总结一下学习到的知识点。

背景

为什么要构建一个高并发场景下的后端系统?

  • 技术角度:业务规模覆盖用户群大,数据联通实时性强,响应时间要求极短,需要高可用,高并发。

  • 市场角度:用户体验、曝光度、促销(秒杀)等。

简而言之,就是让自己编写的系统应用做到如何更优雅的”接客”。

好,现在我们来看看,如何用正确的”姿势”来”接客”?

设计思路

设计层面需要考虑的Points

Point1:静态页面设计

  • cdn托管
  • 网址隐藏
  • 页面压缩
  • 缓存机制

Point2:动态页面设计

  • 队列设置
  • 乐观锁(利用redis原子操作实现)
  • 异步调用
  • 资质抢购

Point3:高可用(双活)

双活:让主备两个数据中心都同时承担用户的业务,此时,主备两个数据中心互为备份,并且进行实时备份,尤其是在缓存层和DB层。

Point4:高并发(负载均衡,安全过滤)

负载均衡:分软件层、硬件层、链路层,但不管哪一层,主要有两种通用常用技术思路:第一种是将大量的同时发送的数据流在多个节点上进行处理。第二种是将单一负载的大量分担在多个节点上进行并行处理,并且在所有节点都完成处理后将结果合并起来输出给用户。而现在,负载均衡技术已经不是什么新鲜技术,一般维护过服务器,或有两台以上的服务器都可以使用负载均衡技术。

安全过滤:设置比较完备的rules过滤器。

Point5: 数据库设计注意静态配置和动态数据分离

静态配置:在前端页面主要呈现内容为主,在接口层主要只读的数据字段。

动态数据:频繁更新,频繁检索的数据字段。

Point6:缓存雪崩

注意设置缓存失效时间,不然超出redis缓存最大内存,溢出讲导致雪崩。

Point7:缓存击穿

注意设置缓存失效时间的随机性,别同一时间同时失效,瞬间同时失效将导致密集的IO读写操作,容易导致缓存击穿。

Point8:脱离原站点部署

简而言之就是:千万不要把鸡蛋放在一个篮子里!!!

分业务分布式部署

  • 定义:一个业务分拆成多个子业务,部署在不同的服务器上。
  • 好处:强调机器间的协作,其重点是任务可拆分,如:某个任务需要一个机器运行10个小时, 将该该任务用10台机器的分布式跑,可能2个小时就跑完了。(子任务之间有依赖关系)。
  • 坏处:中心化带来的主要问题是可靠性,若中心节点宕机则整个系统不可用,分布式除了解决部分中心化问题,也倾向于分散负载,但分布式会带来很多的其他问题,最主要的就是一致性。

分容器分布式部署

  • 定义:俗称”集群”,同一个业务,部署在多个服务器容器上。为的
  • 好处:同一个业务部署在多台机器上,提高系统可用性。如:某个任务需要一个机器运行10个小时,那任务放到 处理该任务的集群上 还是需要10个小时。 假如有10个这样的任务, 放到同一个集群上, 仍然需要10个小时,但是由于挂载的机器来自不同地域节点,可以提升带宽上的物理传输速度,一台服务器垮了,其它的服务器可以顶上来。
  • 坏处:整体性能难得到显著得提升,受业务内极端需求峰值限制。

PS: “没有最好的方式,只有最适合的方式”,不同的业务场景需求,不同的模块:数据库、缓存、消息中间件、媒体资源、系统应用等,需要选用不同的部署方案才能达到高可用,当然,一般更建议两种方式组合部署。

Point9:监控+监控+监控(总要事情说三遍!)

系统研发完成,测试通过并不代表就结束了,一个高并发系统最关键的时期往往是在活动的峰值期间,为了不让RD们24小时目不转睛地盯着所有可能出现问题的地方,最好在关键处加上异常监控信息,以便及时对异常事件做出响应。

这里介绍两个开源监控项目:

大厂的成熟解决方案

  • 在百度的解决方案:百度云opcode缓存BigPipeBDRP(RedisV3)集群ORP集群CDN分流,hiphoto等更大的云实例。
  • 从阿里同学那得知的一些那边的解决方案:活用阿里云服务,譬如云监控云盾ECSOSSRDSCDN分流,这些大都已经是面向大众的商业产品。

个人开发者/创业公司的解决方案

回头单开一篇文章介绍,留个传送门

研发策略

一、认清业务的环境、形式

  • 用户纬度:超大量,正常用户/恶意用户。
  • 地域:全国各地。
  • 业务流程:
    • 【前台】卡券、奖品展示,领用登记等。
      • 【后台】数据接入、数据处理、数据同步、数据录入、库存管理。

通用的业务场景如下:

二、分析业务的状态

商品/奖品展示层

  • 商品/奖品展示:秒杀倒计时页面。
  • 秒杀进行中:点击进入秒杀页面。
  • 秒杀活动结束:提示活动已结束。

技术细节

页面/服务器优化,依赖包cdn网络加速部署,隐藏跳转页面,状态切换(sh脚本设置定时任务实现),这里就不扩展了,现在应对大型Web系统的成熟前端页面技术栈特别多。

用户登记层

  • 秒杀进行中:秒杀登记页面。
  • 秒杀结束了:秒杀结束页面。

技术细节

token加/解密(加密协议自己拟订)

比较常见的token加/解密算法和协议

ajax跨域(常用jsonp)

比较常见的ajax跨域处理方式

数据接入层

  • 数据校验:完成对数据、用户验证(安全和速度均要考虑)。
  • 存入nosql消息队列:去重/排序/缓存/检索数据。
  • 检测商品最大数量:提示活动已结束。


简而言之:就是”一言不合就反馈,功成名就须尽人皆知”。

技术细节

数据校验

数据校验器示例写法

存入nosql消息队列

比较常见的nosql消息中间件

数据处理层

  • 数据持久化:转存nosql数据到mysql数据库,主要为dao层DB操作。
  • DB优化:DB分表,DB表扩展,DB迁移。
  • 转存:sql转存,导出excel打印审核。

技术细节

三、根据状态进行代码模块层面的设计

四、全量的压力测试

简而言之:正式表演前,请务必带装彩排一轮

十个免费的 Web 压力测试工具

参考文档

文章目录
  1. 1. 背景
    1. 1.1. 为什么要构建一个高并发场景下的后端系统?
  2. 2. 设计思路
    1. 2.1. 设计层面需要考虑的Points
      1. 2.1.1. Point1:静态页面设计
      2. 2.1.2. Point2:动态页面设计
      3. 2.1.3. Point3:高可用(双活)
      4. 2.1.4. Point4:高并发(负载均衡,安全过滤)
      5. 2.1.5. Point5: 数据库设计注意静态配置和动态数据分离
      6. 2.1.6. Point6:缓存雪崩
      7. 2.1.7. Point7:缓存击穿
      8. 2.1.8. Point8:脱离原站点部署
        1. 2.1.8.1. 分业务分布式部署
        2. 2.1.8.2. 分容器分布式部署
      9. 2.1.9. Point9:监控+监控+监控(总要事情说三遍!)
    2. 2.2. 大厂的成熟解决方案
    3. 2.3. 个人开发者/创业公司的解决方案
  3. 3. 研发策略
    1. 3.1. 一、认清业务的环境、形式
    2. 3.2. 二、分析业务的状态
      1. 3.2.1. 商品/奖品展示层
        1. 3.2.1.1. 技术细节
      2. 3.2.2. 用户登记层
        1. 3.2.2.1. 技术细节
          1. 3.2.2.1.1. token加/解密(加密协议自己拟订)
          2. 3.2.2.1.2. ajax跨域(常用jsonp)
      3. 3.2.3. 数据接入层
        1. 3.2.3.1. 技术细节
          1. 3.2.3.1.1. 数据校验
          2. 3.2.3.1.2. 存入nosql消息队列
      4. 3.2.4. 数据处理层
        1. 3.2.4.1. 技术细节
    3. 3.3. 三、根据状态进行代码模块层面的设计
    4. 3.4. 四、全量的压力测试
  4. 4. 参考文档