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

*******************************

前端

*******************************

1.添加必要的硬件和带宽,同一时候额外储备一部分,以备不时之需

2.特别监控网络数据流量是否正常。如是否有大规模的爬虫、DDOS等浑水摸鱼,能够针对iP和Cookie的限流

3.使用CDN同一时候做一些必要的算法改造,动静分离

*******************************

代码端

*******************************

1.必要的代码优化改造如软件升级、慢查询、client缓存、多线程之类

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)

时间: 2024-10-12 17:36:40

高并发大流量站点架构简单思路的相关文章

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

******************************* 前端 ******************************* 1.增加必要的硬件和带宽,同时额外储备一部分,以备不时之需 2.特别监控网络数据流量是否正常,如是否有大规模的爬虫.DDOS等浑水摸鱼,可以针对iP和Cookie的限流 3.使用CDN同时做一些必要的算法改造,动静分离 ******************************* 代码端 ******************************* 1.必要的

php高并发大流量站点nginx优化

我们的站点目前能应对千万级PV以及百万级的并发,对php+nginx的优化有一点点心得,写下来做一些记录. 1.TCP sockets 与Unix sockets Unix sockets比TCP sockets提供更好一些的性能(因为I/O数据读写少,上下文切换少). upstream backend { server unix:/var/run/fastcgi.sock; # server 127.0.0.1:8080; } 2.禁用或者优化access_log 大流量访问时,较大的访问会导

高并发大流量网站 10 个解决方法

高并发大流量网站 10 个解决方法1.硬件升级 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 2.负载均衡 它是根据某种负载策略把请求分发到集群中的每一台服务器上,让整个服务器群来处理网站的请求.公司比较有钱的,可以购买专门负责负载均衡的硬件(如:F5),效果肯定会很好.对于大部分公司,会选择廉价有效的方法扩展整个系统的架构,来增加服务器的吞吐量和处理能力,以及承载能力.

网站高并发大流量访问的处理及解决方案

1.硬件升级 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 2.负载均衡 它是根据某种负载策略把请求分发到集群中的每一台服务器上,让整个服务器群来处理网站的请求. 公司比较有钱的,可以购买专门负责负载均衡的硬件(如:F5),效果肯定会很好.对于大部分公司,会选择廉价有效的方法扩展整个系统的架构,来增加服务器的吞吐量和处理能力,以及承载能力. 3.服务器集群 服务器集群就是

【java高并发 大数据企业架构框架整合】Springmvc+mybatis+shiro+lucene+rest+webservice+maven

1. 使用阿里巴巴Druid连接池(高效.功能强大.可扩展性好的数据库连接池.监控数据库访问性能.支持Common-Logging.Log4j和JdkLog,监控数据库访问) 2. 提供高并发JMS消息处理机制 3. 所有功能模块化.所有模块服务化.所有服务原子化的方式,提供可拓展的服务模型,使程序稳定运行,永不宕机 4. 提供Wink Rest.Webservice服务,故可作为独立服务平台部署 框架整合: Springmvc + Mybatis + Shiro(权限) + REST(服务)

php解决与处理网站高并发 大流量访问的方法

方法/步骤 首先,确认服务器硬件是否足够支持当前的流量 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 其次,优化数据库访问前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站, 静态化往往不能满足某些功能. 缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用 这些文件,而不必再访问数据库,WordPress和Z-Blog都

高并发大流量

1.首先关注参数 首先关注我们的请求量是多少,单台服务器并发量是多少 请求数 响应时间 并发连接数是指系统同时处理的请求数量. 2.然后根据我们需要达到多少并发数,采取相应的方案 数据库缓存.负载均衡.读写服务器.CDN加速. 静态HTML缓存 业务分离.分布式存储 3.流量优化 防盗链处理 前端优化:减少http请求,图片合并, 添加异步请求 启用浏览器缓存和文件压缩 原文地址:https://www.cnblogs.com/juanzhi/p/12562768.html

高负载、高并发网站架构知识汇总-大流量网站架构的几点认识

:硬架构 1:机房的选择: 在 选择机房的时候,根据网站用户的地域分布,可以选择网通或电信机房,但更多时候,可能双线机房才是合适的.越大的城市,机房价格越贵,从成本的角度看可以 在一些中小城市托管服务器,比如说广州的公司可以考虑把服务器托管在东莞,佛山等地,不是特别远,但是价格会便宜很多. 2:带宽的大小: 通常老板花钱请我们架构网站的时候,会给我们提出一些目标,诸如网站每天要能承受100万PV的访问量等等.这时我们要预算一下大概需要多大的带宽,计算带宽大小主要涉及两个指标(峰值流量和页面大小)

高性能、高并发网络通信系统的架构设计

1 引言 随着互联网和物联网的高速发展,使用网络的人数和电子设备的数量急剧增长,其也对互联网后台服务程序提出了更高的性能和并发要求.本文的主要目的是阐述如何进行高并发.高性能网络通信系统的架构设计,以及这样的系统的常用技术,但不对其技术细节进行讨论.本篇只起抛砖引玉的之效,如有更好的设计方案和思路,望您共分享之![注:此篇用select来讲解,如想用epoll,设计思路是一致的] 我们首先来看看课本或学习资料上关于处理并发网络编程的三种常用方案,以及对应的大体思路和优缺点,其描述如下所示: