分布式 web 集群的搭建 -- 存储篇

2015-03-25 22:12:14   最后更新: 2015-03-25 22:12:49   访问数量:2117




在网络层的背后,每一个业务都需要数据的支撑,数据库的优化在整个系统中就显得至关重要了

虽然 NoSQL 在并发性能上要优于传统的 DBA,但由于 MySQL 在扩展性等方面的优势,MySQL 依然作为企业级数据存储的首选

 

 

建立适当索引

对于 MySQL 优化,最简单的做法就是建立索引,在表数据量较大时可以起到快速检索数据的作用

主要的成本在于其磁盘开销比较大,占用空间甚至可能比源数据更大,同时,由于需要维护和更新索引,所以 insert、update、delete 操作耗时会随之增加

对于主要以 select 操作为主的字段,合理建立索引对系统性能的提升是有明显作用的

 

数据库连接线程池缓存

MySQL 是一个多线程并发模型数据库,因此数据库的访问常常伴随着线程的创建和销毁,这个工作是非常耗时的

可以通过配置 thread_cache_size 选项来改变线程池的大小,减少线程的创建和销毁

 

 

还有另一种办法,那就是使用 pconnect(数据库长连接),线程一旦创建在很长时间内都保持着

但是,这样在数据库连接访问量大的时候会出现数据连接数耗尽的情况,因此,长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务,控制CGI机器“盲目”创建连接数

 

建立数据库连接池服务,有很多实现的方式,PHP的话,可以使用swoole(PHP的一个网络通讯拓展)来实现

 

 

Innodb缓存设置(innodb_buffer_pool_size)

innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区,如果机器是MySQL独占的机器,一般推荐为机器物理内存的 80%

在取表数据的场景中,它可以减少磁盘IO

一般来说,这个值设置越大,cache命中率会越高

 

分库/分表/分区

MySQL 数据库表一般承受数据量在百万级别,再往上增长,各项性能将会出现大幅度下降

因此,当我们预见数据量会超过这个量级的时候,建议进行分库、分表、分区等操作

最好的做法,是服务在搭建之初就设计为分库分表的存储模式,从根本上杜绝中后期的风险

不过,会牺牲一些便利性,例如列表式的查询,同时,也增加了维护的复杂度,不过,到了数据量千万级别或者以上的时候,它们都是值得的

 

单点部署 MySQL 数据库具有很多风险,如数据的持久化、服务的持续性,如果一旦数据库服务挂掉,整个系统都将无法继续工作

有以下几种分布式部署方案可以选择:

 

建立MySQL主从,从库作为备份

这样的部署方式是纯粹为了解决单点故障的问题的,在主库故障时切换从库继续提供服务

日常工作中,从库仅通过 binlog 从主库备份数据,作为数据备份使用,这样的策略造成资源很大程度上的浪费

 

 

MySQL 读写分离

两台数据库做读写分离,主库负责写入类的操作,从库负责读的操作。并且,如果主库发生故障,仍然不影响读的操作,同时也可以将全部读写都临时切换到从库中

但这个策略需要注意流量,可能会因为流量过大,把从库也拖垮

 

 

主主互备

两台MySQL之间互为彼此的从库,同时又是主库

这种方案,既做到了访问量的压力分流,同时也解决了“单点故障”问题

任何一台故障,都还有另外一套可供使用的服务

 

 

这种方案的缺陷在于,只能使用两台服务器搭建集群,如果业务拓展很快,应该选择将业务分离,建立多个主主互备集群

 

当我们有多台 MySQL,在业务高峰期,很可能出现两个库之间的数据有延迟的场景。并且,网络和机器负载等,也会影响数据同步的延迟

如果从服务器的数据严重慢于主服务器的数据,则从服务器已经失去其备份的效用了

 

有以下方案解决数据同步问题:

 

MySQL自带多线程同步

MySQL5.6 开始支持主从数据库通过多线程同步

但是,这个方式只支持以库为单位的备份

同时,这一过程是通过主数据库的 binlog 进行的,由于 binlog 有严格的操作顺序,所以备份过程只能单进程进行,所以效率也较低

 

自己解析 binlog 实现以表为单位的多线程备份

以数据库的表为单位,解析binlog多张表同时做数据同步,这样能够加快数据同步的效率

但是,如果表和表之间存在结构关系或者数据依赖的话,则同样存在写入顺序的问题

 

 

这种方式,可用于一些比较稳定并且相对独立的数据表

国内一线互联网公司,大部分都是通过这种方式,来加快数据同步效率

 

二八定律出现在生活的方方面面,在 web 系统搭建的时候也符合这一原理,80% 的请求只关注在 20% 的热点数据上

因此,将这 20% 的数据放在高速缓存中,既可以缓解后端数据库的访问压力,也可以提高 web 服务的性能,即便是用磁盘作为缓存,也可以很大程度的缓解后端数据库的压力

 

 

页面静态化

对于大多数用户访问的页面,很长的时间内是不会发生变化的

而重复的向服务器请求不仅降低访问效率占用带宽,还会增加网站展现延时

这样的话,通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次,是通过动态CGI查询数据库获取之外,之后都直接将本地磁盘文件返回给用户是一个不错的解决方案

 

 

但是,一旦Web系统规模变大,例如当我有100台的Web服务器的时候。那样这些磁盘文件,将会有100份,这个是资源浪费

 

单台内存缓存

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

 

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

 

 

内存缓存集群

当我们搭建单台内存缓存完毕,我们又会面临单点故障的问题,因此,我们必须将它变成一个集群

简单的做法,是给他增加一个slave作为备份机器

但是,如果请求量真的很多,我们发现cache命中率不高,需要更多的机器内存

因此,我们更建议将它配置成一个集群。例如,类似redis cluster

 

Redis cluster集群内的Redis互为多组主从,同时每个节点都可以接受请求,在拓展集群的时候比较方便

客户端可以向任意一个节点发送请求,如果是它的“负责”的内容,则直接返回内容。否则,查找实际负责Redis节点,然后将地址告知客户端,客户端重新请求

 

 

对于使用缓存服务的客户端来说,这一切是透明的

 

 

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

 

减少数据库“写”

上面的机制,都实现减少数据库的“读”的操作,

是,写的操作也是一个大的压力

写的操作,虽然无法减少,但是可以通过合并请求,来起到减轻压力的效果

这个时候,我们就需要在内存缓存集群和数据库集群之间,建立一个修改同步机制

 

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

 

 

除了上述通过改变系统架构的方式提升写的性能外,MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许,从硬件层面解决问题,可以选择老一点的RAID(Redundant Arrays of independent Disks,磁盘列阵)或者比较新的SSD(Solid State Drives,固态硬盘)

 

NoSQL存储

不管数据库的读还是写,当流量再进一步上涨,终会达到“人力有穷时”的场景。

续加机器的成本比较高,并且不一定可以真正解决问题的时候

这个时候,部分核心数据,就可以考虑使用NoSQL的数据库

NoSQL存储,大部分都是采用key-value的方式,这里比较推荐使用上面介绍过Redis,Redis本身是一个内存cache,同时也可以当做一个存储来使用,让它直接将数据落地到磁盘

 

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

 

 

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

 

空节点查询问题

当我们搭建完前面所说的全部服务,认为Web系统已经很强的时候

我们还是那句话,新的问题还是会来的

空节点查询,是指那些数据库中根本不存在的数据请求

例如,我请求查询一个不存在人员信息,系统会从各级缓存逐级查找,最后查到到数据库本身,然后才得出查找不到的结论,返回给前端。因为各级cache对它无效,这个请求是非常消耗系统资源的,而如果大量的空节点查询,是可以冲击到系统服务的

 

 

因此,为了维护Web系统的稳定性,设计适当的空节点过滤机制,非常有必要

我们当时采用的方式,就是设计一张简单的记录映射表。将存在的记录存储起来,放入到一台内存cache中,这样的话,如果还有空节点查询,则在缓存这一层就被阻挡了

 

 

文章来源于 http://www.csdn.net/article/2014-11-06/2822529,本博主对文章内容进行了重新排版与部分修改和内容添加

 

欢迎关注微信公众号,以技术为主,涉及历史、人文等多领域的学习与感悟,每周三到七篇推文,只有全部原创,只有干货没有鸡汤

 






技术帖      web      mysql      sql      技术分享      存储      cgi      集群      server      redis      webserver      分布式      nosql      cluster      innodb      dataserver     


1#蓝星星: (回复)2018-06-22 14:57:47

对于最后一段设计的记录映射表,有几个问题想了解下。1. 这张表是存储在本机的还是存储在分布式存储系统中的?2. 并且其更新策略是什么?删除记录时删除新增记录时增加?3. 新增这一张表是不是成本有点高?当数据量很大时需要占用很大内存。

2#博主: (回复)2018-07-25 11:06:10

回复:1#1. 表是存储在分布式缓存中的;2. 由于只缓存查询必要参数的 key,如用户 id,记录不会很多,我们的业务中,线上数据不会物理删除;3. 是有可能占用很大内存的,但是只存储必要字段,仍然是可以接受的

京ICP备15018585号