电商网站处理大数据和并发架构网站

电商网站是怎么处理大数据和并发架构网站

第一点服务器负责均衡:

web 负载均衡的作用就是把请求均匀的分配给各个节点，它是一种动态均衡，通过一些工具实时地分析数据包，掌握网络中的数据流量状况，把请求理分配出去。对于不同的应用环境(如电子商务网站，它的计 算负荷大;再如网络数据库应用，读写频繁，服务器的存储子系统系统面临很大压力;再如视频服务应用，数据传输量大，网络接口负担重压。)，使用的均衡策略 (算法)是不同的。 所以均衡策略(算法)也就有了多种多样的形式，广义上的负载均衡既可以设置专门的网关、负载均衡器，也可以通过一些专用软件与协议来实现。在OSI七层协议模型中的第二(数据链路层)、第三(网络层)、第四(传输层)、第七层(应用层)都有相应的负载均衡策略(算法)，在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径;在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点;而传输层和应用层的交换(Switch)，本身便是一种基于访问流量的控制方式，能够实现负载均衡。

目前，基于负载均衡的算法主要有三种：轮循(Round-Robin)、最小连接数(Least Connections First)，和快速响应优先(Faster Response Precedence)。

①轮循算法，就是将来自网络的请求依次分配给集群中的节点进行处理。

②最小连接数算法，就是为集群中的每台服务器设置一个记数器，记录每个服务器当前的连接数，负载均衡系统总是选择当前连接数最少的服务器分配任务。 这要比"轮循算法"好很多，因为在有些场合中，简单的轮循不能判断哪个节点的负载更低，也许新的工作又被分配给了一个已经很忙的服务器了。

③快速响应优先算法，是根据群集中的节点的状态(CPU、内存等主要处理部分)来分配任务。 这一点很难做到，事实上到目前为止，采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说，只能在TCP/IP协议方面做工作，几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。

上面是负载均衡常用的算法，基于以上负载均衡算法的使用方式上，又分为如下几种：

1、DNS轮询

最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。

DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候，必须尽量保证不同的 客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志，一旦超过这个时间限制，其他DNS服务器就需要和这个服务器交互，以重新获得地址数 据，就有可能获得不同IP地址。因此为了使地址能随机分配，就应使刷新时间尽量短，不同地方的DNS服务器能更新对应的地址，达到随机获得地址，然而将过 期时间设置得过短，将使DNS流量大增，而造成额外的网络问题。DNS负载均衡的另一个问题是，一旦某个服务器出现故障，即使及时修改了DNS设置，还是
要等待足够的时间(刷新时间)才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器

2、反向代理服务器

使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。

这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部服务器，而这种代理方式是代理多个客户访问内部服务器，因此也被称为反向代理模式。虽然实现这个任务并不算是特别复杂，然而由于要求特别高的效率，实现起来并不简单。

使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能。然而它本身也存在一些问题，首先就是必须为每一种服务都专门开发一个反向代理服务器，这就不是一个轻松的任务。

代理服务器本身虽然可以达到很高效率，但是针对每一次代理，代理服务器就必须维护两个连接，一个对外的连接，一个对内的连接，因此对于特别高的连接请求， 代理服务器的负载也就非常之大。反向代理方式下能应用优化的负载均衡策略，每次访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加，代理服务 器本身的负载也变得非常大，最后反向代理服务器本身会成为服务的瓶颈。

3、地址转换网关

支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。很多 硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡 策略来分配负载。由于地址转换相对来讲比较接近网络的低层，因此就有可能将它集成在硬件设备中，通常这样的硬件设备是局域网交换机。

第二：数据库主从关系的映射：

很重要一个信息就是数据库的分离，电商的数据库业务是这样做的，业务数据的增删改进行的是在主数据库的操作，全部的查询都是在从数据库操作，大家可能就会有疑问了，那么怎么保证数据的一致性呢，是因为数据库服务进行映射和配置，当主数据库发生了数据变化会立刻同步到所有的从数据库。这样的做法的好处就是减少数据库服务器的压力。从而大大的提升查询和性能。真是一种聪明的做法。

采用的架构是：Springmvc+Mybatis+Freemarker+Nginx+Tomcat6.x+Mysql数据库。

过去当运行一个大的web应用时候意味着需要运行一个大型的web服务器。因为你的应用吸引了大量的用户，你将不得不在你的服务器里增加更多的内存和处理器。今天，“大型服务器”模式已经过去，取而代之的是大量的小服务器，使用各种各样的负载均衡技术。
　　“更多小服务器”的优势超过过去的“大型服务器”模式体现在两个方面：
　　1. 如果服务器宕机，那么负载均衡系统将停止请求到宕机的服务器，转而分发负载到其他正常运行的服务器上。
　　2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。
　　所以，把握住这个机会。当然，代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。
　　这时你可能对自己说:“但是我怎么知道我正在使用负载均衡呢?”。最诚实的回答是，如果你正在问这个问题，那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况，当应用成长足够大的规模时，负载均衡就需要明确提出和设置了。然而，我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡，或者像下面描述的那样要自己来做。
　　注意，我一直提“web应用”而不是website,这是想区分“web应用”是那些复杂的站点往往涉及服务器端编程和数据库，而不是website那样只显示简单的静态内容。
　　1. PHP文件
　　第一个问题是，如果你有大量的小型服务器，你怎么把你的php文件上传到所有的服务器上?有如下的方法供你参考：
　　◆分别上传所有的文件到每一个服务器 , 这种方法带来的问题是：想像一下你有20个服务器，那么上传过程中这将很容易导致错误，并且更新时极有可能导致不同服务器上有不同版本的文件。
　　◆使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。
　　◆使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码，当发布我的应用时，可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。
　　◆使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然，如果你的文件服务器宕机，那么多所有你的站点将不能使用。这时，你就需要花费更多的开支来恢复它。
　　选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统，那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而，如果使用文件服务器，你就要实现一些失败恢复机制，防止万一服务器宕机导致请求失败。
　　2. 文件上传
　　当只有一台服务器时，文件上传不是一个问题。但是当我们有多台服务器时，那么上传的文件应该怎么存放呢?上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:
　　◆把文件存储到数据库中。大多数数据允许存储二进制数据。当你请求文件下载时，访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。
　　◆在一个文件服务器上存储上传的文件 . 与前面的介绍一样，你要安装一个文件服务器让所有web服务器共享，把所有上传的文件上传到这里，上传后所有的web服务器就都可以使用它。但是，如果文件服务器宕机，那么可能发生图像文件下载中断。
　　◆设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷，但是将增加你代码的复杂度。例如，如果上传到多个服务器过程中，服务器宕机，你要怎么处理?
　　用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时，首先检查缓存系统中是否有该文件，如果发现那么从缓存系统下载，否则从数据库读取并把它缓存到文件系统中。
　　3. 会话(Sessions)
　　如果你熟悉php的session 处理，你将可能知道默认情况下，它存储session数据在服务器的临时文件里。而且，这个文件仅仅在你请求处理的那个服务器上，但是接下来的请求可能被另外一个服务器处理，这将在另一个服务器上生成新的session。这导致session频繁地不被识别，如登录用户总是要求重新登录。
　　我推荐的方案是，要么重新php内建的session处理机制存储session数据到数据库，或者实现你自己的机制保证发送一个用户的请求到同一台服务器。
　　4. 配置(Configuration)
　　尽管这个话题不是和php特别相关，我感觉还是有必要提及。当运行集群服务器时，用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致，可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。
　　我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件，也可以保持所有服务器配置文件同步。
　　5. 日志(Logging)
　　像配置问题一样，logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统，你怎么知道如果PHP代码开始产生错误(在系统正式运行时，你总是关闭display_errors 设置，不是吗?)
　　有几种方法你可以实现logging：
　　1. 在每一个服务器上记录日志。 这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单，可能只要很少的配置。但是，随着服务器数量的增多，监控每台服务器上的日志文件将变得非常困难。

2. 记录日志到一个共享 这种方法每一个服务器仍然有这个日志文件，但是他们通过共享机制被存储在一个中央文件服务器上，这将使监控日志变得更简单。该方案的问题在于，如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。
　　3. 记录日志到logging服务器 你可以使用一个logging软件，如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置，但是他也提供了最健壮的方案。