大数据和高并发的解决方案汇总

    大数据和高并发的解决方案汇总

1.3海量数据解决方案

1.使用缓存:

  使用方式:1,使用程序直接保存到内存中。主要使用Map,尤其ConcurrentHashMap。

2,使用缓存框架。常用的框架:Ehcache,Memcache,Redis等。

  最关键的问题是:什么时候创建缓存,以及其失效机制。

对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态。

2.数据库优化:

  1,表结构优化。

  2,SQL语句优化,语法优化和处理逻辑优化。可记录各语句执行时间,有针对性的分析。

  3,分区

  4,分表

  5,索引优化

  6,使用存储过程代替直接操作

3.分离活跃数据

  例如用户,可以分为活跃用户和不活跃用户。

4.批量读取和延迟修改

  高并发情况可以将多个查询请求合并到一个。

  高并发且频繁修改的可以暂存缓存中。

5.读写分离

  上图,数据库服务器配置多个,配置主从数据库。写用主数据库,读用从数据库。

6.分布式数据库

  将不同的表存放到不同的数据库中,然后再放到不同的服务器中。有些复杂问题,如:事务处理,多表查询。

7.NoSql和Hadoop

  NoSql,not only SQL。没有关系型数据库那么多限制,比较灵活高效。

  Hadoop,将一个表中的数据分层多块,保存到多个节点(分布式)。每一块数据都有多个节点保存(集群)。集群可以并行处理相同的数据,还可以保证数据的完整性。

1.4高并发的解决方案。

  1.应用和静态资源分离。

    将静态资源(js,css,图片等)放到专门的服务器中。

  2.页面缓存

    将应用生成的页面缓存起来可以节省大量cpu资源。

  对于部分页面经常变换数据的,可以使用ajax来处理。

3.集群和分布式

  集群,多台服务器具有相同的功能,主要起分流的作用。

  分布式,将不同的业务放到不同的服务器中,处理一个请求可能需要多台服务器,进而提高一个请求的处理速度。

  又分为静态资源集群和应用程序集群。后者较复杂,经常要考虑session同步等问题。

4.反向代理

  客户端直接访问的服务器并不是直接提供服务的服务器,它从别的服务器获取资源,然后将结果返回给用户。

  代理服务器和反向代理服务器:

  代理服务器是代我们访获取资源,然后将结果返回。例如,访问外网的代理服务器。反向代理服务器是我们正常访问一台服务器的时候,服务器自己调用了别的服务器。

  代理服务器我们主动使用,是为我们服务的,不需要有自己的域名;反向代理是服务器自己使用的,我们并不知道,有自己的域名。

5,CDN

  CDN是一种特殊的集群页面缓冲服务器,和普通的集群的多台页面缓冲服务器相比主要区别是:其存放位置和分配请求方式不同。

  CDN的服务器分布在全国各地,接收到请求后会将请求分配到最合适的CDN服务器节点来获取数据。其每一个CDN节点就是一个页面缓存服务器。

  分配方式:并不是普通的负载均衡,而是专门的CDN域名解析服务器在解析域名的时候就分配好的,一般的做饭是:ISP那里使用CNAME将域名解析到一个特定的域名,然后再将解析到的那个域名用专门的CDN服务器解析(返回给浏览器,再访问)到相应的CDN节点。每个节点可能也集群了多台服务器。

小结:

  网站架构的整个演变主要围绕大数据和高并发而展开。解决的方案主要是使用缓存和多资源两种类型。多资源:多存储,多CPU,多网络。可以单个资源处理一个请求,也可以多个。

  使用复杂框架之前一定要将项目的业务优化好,基础中的基础,重中之重!

  架构和协议并不是神圣不可侵犯的东西。

------名白

http://www.cnblogs.com/mingbai/p/7049458.html

时间: 2024-09-30 06:54:42

大数据和高并发的解决方案汇总的相关文章

PHP中大数据和高并发的解决方案汇总

大数据和高并发的解决方案汇总 1.3海量数据解决方案 1.使用缓存: 使用方式:1,使用程序直接保存到内存中.主要使用Map,尤其ConcurrentHashMap. 2,使用缓存框架.常用的框架:Ehcache,Memcache,Redis等. 最关键的问题是:什么时候创建缓存,以及其失效机制. 对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态. 2.数据库优化: 1,表结构优化. 2,SQL语句优化,语法优化和处理逻辑优化.可记录各语句执行时间,有针对性的分析.

大数据和高并发的解决方案总结

现在,软件架构变得越来越复杂了,好多技术层出不穷,令人眼花缭乱,解决这个问题呢,就是要把复杂问题简单化,核心就是要把握本质. 软件刚开始的时候是为了实现功能,随着信息量和用户的增多,大数据和高并发成了软件设计必须考虑的问题,那么大数据和高并发本质是什么呢? 本质很简单,一个是慢,一个是等.两者是相互关联的,因为慢,所以要等,因为等,所以慢,解决了慢,也就解决了等,解决了等,也就解决了慢. 关键是如何解决慢和等,核心一个是短,一个是少,一个是分流. 短是指路径要短.典型的mvc结构是请求->con

(转)大数据量高并发的数据库优化与sql优化

大数据量高并发的数据库优化 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整

大数据量高并发的数据库优化详解(MSSQL)

转载自:http://www.jb51.net/article/71041.htm 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而

[转]浅析大数据量高并发的数据库优化

链接:http://www.uml.org.cn/sjjm/201308264.asp 高并发数据库可以同时处理海量信息,应用范围很广.今天我们将讨论的是大数据量高并发的数据库优化,希望对大家有所帮助. 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性

大数据量高并发的数据库优化

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

大数据量高并发访问的数据库优化方法

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须

大数据量高并发的数据库优化(转)

参考:http://www.cnblogs.com/chuncn/archive/2009/04/21/1440233.html 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时

大数据量高并发的数据库优化,sql查询优化

一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整个系统的流程的时候,我们必须