高并发大流量网站架构简单思路
2023-09-11 14:19:23 时间
*******************************
前端
*******************************
1.增加必要的硬件和带宽,同时额外储备一部分,以备不时之需
2.特别监控网络数据流量是否正常,如是否有大规模的爬虫、DDOS等浑水摸鱼,可以针对iP和Cookie的限流
3.使用CDN同时做一些必要的算法改造,动静分离
*******************************
代码端
*******************************
1.必要的代码优化改造如软件升级、慢查询、客户端缓存、多线程之类
2.设计高峰期时的降级使用:关掉或暂停非核心的页面功能、后端统计功能
3.SOA做好横向扩展,最好是自动化扩展
4.负载选择七层还是四层,负载会不是瓶颈
5.各种高大上的缓存:reids、mongdb、memcache等
6.web到数据库端需要一个“隔离区”,让数据平稳、源源不断的进入数据库
7.尽量不要使用带复杂业务逻辑处理的存储过程(犹其是在N大数据结果集中做业务逻辑处理),减少数据库CPU和内存压力
8.功能模块间,做好隔离,不能因为一个功能加载不出数据,而影响其它非相互依赖功能。
9.合理的连接池设计
*******************************
后端
*******************************
1.主从复制:
情况1:很难做到实时,但是切换时,可能有部分数据没有同步过来,带来了数据的一致性问题。
可以在操作主数据库的同时,记录操作日志,切换到备时,会和操作日志做个check,补齐未同步过来的数据;
情况2:dbrd+master-slave模式或share eveything架构
2.PXC或MGC群集的share nothing架构
3.按照页面不同需求拆分数据库:如用户登录、购物车、下单、支付等分布在不同数据库
4.按区域划分DB:如华东、华北、华中、华南、华西不同区域用户到不同IDC的DB,最后数据汇总到总部IDC即可;当问题爆发时不会影响全局;单机房DB压力会降低.
5.数据库硬件:如使用SSD、闪存存储等.
6.纯内存数据库:如timesten、HANA或自己定制开发
7.杀手锏:
1)强行设置交易完成如起飞时间也过也不可能退款的数据归档,归档数据只供查询 .
2)如果第一种强行归档数据量依然巨大,可以按照天如10天之前的归档,毕竟
80以上的交易都会完成,在不大量修改代码的情况,如前端需要退款、改签处理,
将数据直接insert导入主库即可,毕竟数据库insert不是最大的瓶颈.
3)按照订单状态拆分:下单未支付、支付完成、处理中、支付完成,分别架构到不同的表.
---------多机房容灾探讨
1.异地机房容灾
A->P还是A->A
2.单机房可以考虑多路光纤
3.底层复制:硬件、软件(RSYNC、DBRD、OGG)
前端
*******************************
1.增加必要的硬件和带宽,同时额外储备一部分,以备不时之需
2.特别监控网络数据流量是否正常,如是否有大规模的爬虫、DDOS等浑水摸鱼,可以针对iP和Cookie的限流
3.使用CDN同时做一些必要的算法改造,动静分离
*******************************
代码端
*******************************
1.必要的代码优化改造如软件升级、慢查询、客户端缓存、多线程之类
2.设计高峰期时的降级使用:关掉或暂停非核心的页面功能、后端统计功能
3.SOA做好横向扩展,最好是自动化扩展
4.负载选择七层还是四层,负载会不是瓶颈
5.各种高大上的缓存:reids、mongdb、memcache等
6.web到数据库端需要一个“隔离区”,让数据平稳、源源不断的进入数据库
7.尽量不要使用带复杂业务逻辑处理的存储过程(犹其是在N大数据结果集中做业务逻辑处理),减少数据库CPU和内存压力
8.功能模块间,做好隔离,不能因为一个功能加载不出数据,而影响其它非相互依赖功能。
9.合理的连接池设计
*******************************
后端
*******************************
1.主从复制:
情况1:很难做到实时,但是切换时,可能有部分数据没有同步过来,带来了数据的一致性问题。
可以在操作主数据库的同时,记录操作日志,切换到备时,会和操作日志做个check,补齐未同步过来的数据;
情况2:dbrd+master-slave模式或share eveything架构
2.PXC或MGC群集的share nothing架构
3.按照页面不同需求拆分数据库:如用户登录、购物车、下单、支付等分布在不同数据库
4.按区域划分DB:如华东、华北、华中、华南、华西不同区域用户到不同IDC的DB,最后数据汇总到总部IDC即可;当问题爆发时不会影响全局;单机房DB压力会降低.
5.数据库硬件:如使用SSD、闪存存储等.
6.纯内存数据库:如timesten、HANA或自己定制开发
7.杀手锏:
1)强行设置交易完成如起飞时间也过也不可能退款的数据归档,归档数据只供查询 .
2)如果第一种强行归档数据量依然巨大,可以按照天如10天之前的归档,毕竟
80以上的交易都会完成,在不大量修改代码的情况,如前端需要退款、改签处理,
将数据直接insert导入主库即可,毕竟数据库insert不是最大的瓶颈.
3)按照订单状态拆分:下单未支付、支付完成、处理中、支付完成,分别架构到不同的表.
---------多机房容灾探讨
1.异地机房容灾
A->P还是A->A
2.单机房可以考虑多路光纤
3.底层复制:硬件、软件(RSYNC、DBRD、OGG)
相关文章
- 一个不错的过TP思路,转载CSDN
- Java 学习思路
- 要理清思路在做事
- 【转】锁表原因及解决思路
- 接口测试方案(接口测试思路)
- 高性能服务器架构思路
- vue后台管理权限正确思路
- IP花式玩法背后,海澜之家营销思路出现哪些变化?
- 数据驱动企业的架构思路探讨
- 华为OD机试 - 数列还原(JavaScript) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 - 投篮大赛(JavaScript) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 - 环中最长子串(JavaScript) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 -Excel 单元格数值统计(Python) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 - 寻找路径(Python) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 - 数字的排列(Python) | 机试题+算法思路+考点+代码解析 【2023】
- 华为OD机试 - 新工号系统(Python)| 真题+思路+考点+代码+岗位
- 华为OD机试 - 火星文计算 2(Python)| 真题+思路+代码
- 华为OD机试 -去除多余空格(Java) | 机试题+算法思路+考点+代码解析 【2023】
- Unity 工具类 之 简单的UI管理框架/仅通过UIWidget(UI元素组件)名即可添加UI对应事件(简单的MVC思路管理UI与逻辑)
- 云成为安全策略中的一大盲点 需要转变传统安全思路
- OpenWRT - WEB界面开发思路和基本方法