Web负载均衡,LoadBalancing,,简单地说就是给我们的服务器集群分配“工作任务”,而采用恰当的分配方式,对于保护处于后端的Web服务器来说,非常重要。

　　反向代理服务的核心工作主要是转发HTTP请求,扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层,应用层,,也就是网络七层结构中的第七层,因此也被称为“七层负载均衡”。可以做反向代理的软件很多,比较常见的一种是Nginx。

　　Nginx是一种非常灵活的反向代理软件,可以自由定制化转发策略,分配服务器流量的权重等。反向代理中,常见的一个问题,就是Web服务器存储的session数据,因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求,无法保证一定分配到相同的Web机器上,会导致无法找到session的问题。

　　配置反向代理的转发规则,让同一个用户的请求一定落到同一台机器上,通过分析cookie,,复杂的转发规则将会消耗更多的CPU,也增加了代理服务器的负担。

　　将session这类的信息,专门用某个独立服务来存储,例如redis/memchache,这个方案是比较推荐的。

　　反向代理服务,也是可以开启缓存的,如果开启了,会增加反向代理的负担,需要谨慎使用。这种负载均衡策略实现和部署非常简单,而且性能表现也比较好。但是,它有“单点故障”的问题,如果挂了,会带来很多的麻烦手机clash绕过大陆。而且,到了后期Web服务器继续增加,它本身可能成为系统的瓶颈。

　　一旦使用了负载均衡,session就会存在同步问题,使用memcache同步session是个不错的解决方案。

　　需要准备一个相对强大的memcache服务器,安装memcache服务。代码层将其他几个主机的seesion都指定到这台memcache服务器。

　　应用扩展性的重要因素。许多Web应用都将数据保存到RDBMS中,应用服务器从中读取数据并在浏览器中显示。但随着数据量的增大、访问的集中,就会出现RDBMS的负担加重、数据库响应恶化、网站显示延迟等重大影响。这时就该memcached大显身手了。memcached是高性能的分布式内存缓存服务器。一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、提高可扩展性。

　　memcache以键值对形式进行数据的保存,通过与php的结合memcahe可以将变量、数组、对象等数据保存到内存中。极大的提升了服务器缓存的效率。

　　为了提高性能,memcached中保存的数据都存储在memcached内置的内存存储空间中。由于数据仅存在于内存中,因此重启memcached、重启操作系统会导致全部数据消失。另外,内容容量达到指定值之后,就基于LRU(LeastRecentlyUsed)算法自动删除不使用的缓存。memcached本身是为缓存而设计的服务器,因此并没有过多考虑数据的永久性问题。

　　php默认情况下并没有开启的memcache扩展,下面将详细讲解memcache扩展的安装。

　　安装好了memcache服务和php的扩展,我们就可以使用php去操作memcache来实现缓存啦,

　　默认情况下session以文件形式保存在服务器端, 当我们遇到大访问量、高并发时我们会对web服务器进行集群化处理。那么不同服务器之间的 session共享会成为一个问题。

　　保存好了变量, 我们经常想看看他们的值或者检测他们的状态。 通过命令行我们可以完成这样的操作。但是命令行比较难懂。

　　MemAdmin是一款可视化的Memcached管理与监控工具,使用 PHP开发,体积小,操作简单。

　　将压缩文件解压后获得 memadmin文件夹,将memadmin文件复制到项目目录下,通过网址直接访问运行即可。

　　我们的We b站点随着访问量的上升,会遇到很多的挑战,解决这些问题不仅仅是扩容机器这么简单,建立和使用合适的缓存机制才是根本。

　　MySQL的缓存机制,就从先从MySQL内部开始,下面的内容将以最常见的 InnoDB 存储引擎为主。

　　最简单的是建立索引, 索引在表数据比较大的时候, 起到快速检索数据的作用,但是成本也是有的。首先, 占用了一定的磁盘空间,其中组合索引最突出,使用需要谨慎,它产生的索引甚至会比源数据更大。其次,建立索引之后的数据insert/update/delete等操作, 因为需要更新原来的索引,耗时会增加。 当然,实际上我们的系统从总体来说,是以 select查询操作居多, 因此,索引的使用仍然对系统性能有大幅提升的作用。

　　如果,每一个数据库操作请求都需要创建和销毁连接的话, 对数据库来说, 无疑也是一种巨大的开销。为了减少这类型的开销,可以在 MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候,再创建,空闲过多的时候,则销毁。

　　其实,还有更为激进一点的做法,使用 pconnect ,数据库长连接, ,线程一旦创建在很长时间内都保持着。但是,在访问量比较大,机器比较多的情况下,这种用法很可能会导致 “数据库连接数耗尽”, 因为建立连接并不回收,最终达到数据库的max_connections ,最大连接数, 。因此,长连接的用法通 常需要在CGI 和MySQL之间实现一个 “连接池”服务,控制CGI机器“盲目”创建连接数。

　　innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区,如果机器是MySQL独占的机器, 一般推荐为机器物理内存的 80%。在取表数据的场景中, 它可以减少磁盘IO。一般来说,这个值设置越大, cache命中率会越高。

　　MySQL数据库表一般承受数据量在百万级别,再往上增长,各项性能将会出现大幅度下降, 因此, 当我们预见数据量会超过这个量级的时候,建议进行分库 /分表/分区等操作。最好的做法, 是服务在搭建之初就设计为分库分表的存储模式,从根本上杜绝中后期的风险。 不过,会牺牲一些便利性, 例如列表式的查询,同时,也增加了 维护的复杂度。不过,到了数据量千万级别或者以上的时候,我们会发现,它们都是值得的。

　　二、 MySQL数据库多台服务搭建1 台MySQL机器,实际上是高风险的单点, 因为如果它挂了,我们 Web服务就不可用了。而且,随着 We b系统访问量继续增加,终于有一天,我们发现 1台MySQL服务器无法支撑下去,我们开始需要使用更多的 MySQL机器。当引入多台MySQL机器的时候,很多新的问题又将产生。

　　这种做法纯粹为了解决 “单点故障”的问题,在主库出故障的时候,切换到从库。不过,这种做法实际上有点浪费资源, 因为从库实际上被闲着了。

　　两台数据库做读写分离,主库负责写入类的操作,从库负责读的操作。并且,如果主库发生故障, 仍然不影响读的操作, 同时也可以将全部读写都临时切换到从库中,需要注意流量,可能会因为流量过大,把从库也拖垮, 。

　　两台MySQL之间互为彼此的从库, 同时又是主库。这种方案,既做到了访问量的压力分流, 同时也解决了 “单点故障”问题。任何一台故障,都还有另外一套可供使用的服务。

　　不过,这种方案,只能用在两台机器的场景。如果业务拓展还是很快的话,可以选择将业务分离,建立多个主主互备。

　　实际上,解决大访问量的问题,不能仅仅着眼于数据库层面。根据 “二八定律”,80%的请求只关注在20%的热点数据上。因此,我们应该建立We b服务器和数 据库之间的缓存机制。 这种机制,可以用磁盘作为缓存, 也可以用内存缓存的方式。通过它们,将大部分的热点数据查询,阻挡在数据库之前。

　　用户访问网站的某个页面,页面上的大部分内容在很长一段时间内,可能都是没有变化的。例如一篇新闻报道,一旦发布几乎是不会修改内容的。这样的话,通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。 除了第一次, 是通过动态CGI查询数据库获取之外,之后都直接将本地磁盘文件返回给用户。

　　在We b系统规模比较小的时候, 这种做法看似完美。 但是,一旦We b系统规模变大,例如当我有100台的We b服务器的时候。 那样这些磁盘文件, 将会有 100份,这个是资源浪费,也不好维护。这个时候有人会想,可以集中一台服务器存起来,呵呵,不如看看下面一种缓存方式吧,它就是这样做的。

　　通过页面静态化的例子中,我们可以知道将 “缓存”搭建在We b机器本机是不好维护的,会带来更多问题,实际上,通过 PHP的apc拓展,可通过Key/value操作We b服务器的本机内存, 。因此,我们选择搭建的内存缓存服务,也必须是一个独立的服务。

　　内存缓存的选择, 主要有redis/memcache。从性能上说,两者差别不大,从功能丰富程度上说, Redis更胜一筹。

　　当我们搭建单台内存缓存完毕,我们又会面临单点故障的问题, 因此,我们必须将它变成一个集群。 简单的做法, 是给他增加一个s lave作为备份机器。 但是,如果请求量真的很多,我们发现 cache命中率不高,需要更多的机器内存呢,因此,我们更建议将它配置成一个集群。例如,类似 redis cluster。

　　Redis cluster集群内的Redis互为多组主从, 同时每个节点都可以接受请求, 在拓展集群的时候比较方便。 客户端可以向任意一个节点发送请求, 如果是它的 “负责”的内容,则直接返回内容。 否则,查找实际负责Redis节点,然后将地址告知客户端,客户端重新请求。

　　内存缓存服务在切换的时候,是有一定风险的。从 A集群切换到B集群的过程中,必须保证B集群提前做好“预热” ,B集群的内存中的热点数据,应该尽量与A集群相同,否则,切换的一瞬间大量请求内容,在 B集群的内存缓存中查找不到,流量直接冲击后端的数据库服务,很可能导致数据库宕机, 。

　　上面的机制,都实现减少数据库的 “读”的操作,但是,写的操作也是一个大的压力。写的操作, 虽然无法减少, 但是可以通过合并请求, 来起到减轻压力的效果。这个时候, 我们就需要在内存缓存集群和数据库集群之间, 建立一个修改同步机制。

　　先将修改请求生效在 cache中,让外界查询显示正常,然后将这些 sql修改放入到一个队列中存储起来, 队列满或者每隔一段时间, 合并为一个请求到数据库中更新数据库。

　　不管数据库的读还是写, 当流量再进一步上涨,终会达到 “人力有穷时”的场景。继续加机器的成本比较高, 并且不一定可以真正解决问题的时候。 这个时候, 部分核心数据,就可以考虑使用 NoSQL的数据库。 NoSQL存储,大部分都是采用key-value的方式,这里比较推荐使用上面介绍过 Redis, Redis本身是一个内存cache, 同时也可以当做一个存储来使用,让它直接将数据落地到磁盘。

　　这样的话, 我们就将数据库中某些被频繁读写的数据, 分离出来, 放在我们新搭建的Redis存储集群中,又进一步减轻原来 MySQL数据库的压力, 同时因为Redis 本身是个内存级别的 Cache,读写的性能都会大幅度提升。

　　国内一线互联网公司, 架构上采用的解决方案很多是类似于上述方案, 不过,使用的cache服务却不一定是Redis,他们会有更丰富的其他选择,甚至根据自身业务特点开发出自己的 NoSQL服务。

　　当我们搭建完前面所说的全部服务, 认为We b系统已经很强的时候。 我们还是那句话,新的问题还是会来的。 空节点查询, 是指那些数据库中根本不存在的数据请求。例如,我请求查询一个不存在人员信息, 系统会从各级缓存逐级查找,最后查到到数据库本身,然后才得出查找不到的结论,返回给前端。因为各级cache对它无效,这个请求是非常消耗系统资源的,而如果大量的空节点查询,是可以冲击到系统服务的。