高并发大流量网站架构简单思路

时间：2015-07-24 14:16:55 阅读：108 评论：0 收藏：0 [点我收藏+]

*******************************
前端
*******************************
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)

高并发大流量网站架构简单思路

标签：数据库架构高并发架构

原文地址：http://blog.csdn.net/yangzhawen/article/details/47040357

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行