【后端】设计高并发场景下的高可用后端系统
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缓存、BigPipe、BDRP（RedisV3）集群、ORP集群、CDN分流,hiphoto等更大的云实例。
- 从阿里同学那得知的一些那边的解决方案：活用阿里云服务，譬如
云监控、云盾、ECS、OSS、RDS、CDN分流，这些大都已经是面向大众的商业产品。
个人开发者/创业公司的解决方案
回头单开一篇文章介绍，留个传送门。
研发策略
一、认清业务的环境、形式
- 用户纬度：超大量，正常用户/恶意用户。
- 地域：全国各地。
- 业务流程：
- 【前台】卡券、奖品展示，领用登记等。
- 【后台】数据接入、数据处理、数据同步、数据录入、库存管理。
- 【前台】卡券、奖品展示，领用登记等。
通用的业务场景如下：
二、分析业务的状态
商品/奖品展示层
- 商品/奖品展示：秒杀倒计时页面。
- 秒杀进行中：点击进入秒杀页面。
- 秒杀活动结束：提示活动已结束。
技术细节
页面/服务器优化，依赖包cdn网络加速部署，隐藏跳转页面，状态切换（sh脚本设置定时任务实现）,这里就不扩展了，现在应对大型Web系统的成熟前端页面技术栈特别多。
用户登记层
- 秒杀进行中：秒杀登记页面。
- 秒杀结束了：秒杀结束页面。
技术细节
token加/解密（加密协议自己拟订）
ajax跨域（常用jsonp）
数据接入层
- 数据校验：完成对数据、用户验证（安全和速度均要考虑）。
- 存入nosql消息队列：去重/排序/缓存/检索数据。
- 检测商品最大数量：提示活动已结束。
简而言之：就是”一言不合就反馈，功成名就须尽人皆知”。
技术细节
数据校验
存入nosql消息队列
数据处理层
- 数据持久化：转存nosql数据到mysql数据库，主要为dao层DB操作。
- DB优化：DB分表，DB表扩展，DB迁移。
- 转存：sql转存，导出excel打印审核。
技术细节
三、根据状态进行代码模块层面的设计
四、全量的压力测试
简而言之：正式表演前，请务必带装彩排一轮
