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

原文：https://www.cnblogs.com/lupeng2010/p/6519466.html

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小时目不转睛地盯着所有可能出现问题的地方，最好在关键处加上异常监控信息，以便及时对异常事件做出响应。

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

• 咕咕监控
• Zabbix

大厂的成熟解决方案

• 在百度的解决方案：百度云、opcode缓存、BigPipe、BDRP（RedisV3）集群、ORP集群、CDN分流,hiphoto等更大的云实例。

• 从阿里同学那得知的一些那边的解决方案：活用阿里云服务，譬如云监控、云盾、ECS、OSS、RDS、CDN分流，这些大都已经是面向大众的商业产品。

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

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

研发策略

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

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

通用的业务场景如下：

二、分析业务的状态

商品/奖品展示层

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

技术细节

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

用户登记层

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

技术细节

token加/解密（加密协议自己拟订）

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

ajax跨域（常用jsonp）

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

数据接入层

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

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

技术细节

数据校验

数据校验器示例写法

存入nosql消息队列

比较常见的nosql消息中间件

数据处理层

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

技术细节

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

四、全量的压力测试

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