• 【后端】设计高并发场景下的高可用后端系统


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

    转载地址:http://blog.daijiale.cn/2016/12/07/%E3%80%90%E5%90%8E%E7%AB%AF%E3%80%91%E8%AE%BE%E8%AE%A1%E9%AB%98%E5%B9%B6%E5%8F%91%E5%9C%BA%E6%99%AF%E4%B8%8B%E7%9A%84%E5%90%8E%E7%AB%AF%E7%B3%BB%E7%BB%9F/?utm_source=tuicool&utm_medium=referral

    背景

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

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

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

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

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

    设计思路

    设计层面需要考虑的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 压力测试工具

    参考文档

  • 相关阅读:
    codeforces round#600
    第三章:数据操作
    1143 Lowest Common Ancestor (30 分)
    游标
    1151 LCA in a Binary Tree (30 分)
    jQuery之setInterval()定时器
    C程序第四次作业
    C程序第三次作业
    C程序第二次作业
    C程序第一次作业
  • 原文地址:https://www.cnblogs.com/lupeng2010/p/6519466.html
Copyright © 2020-2023  润新知