2017.6.2/数据库的架构和优化

Posted 2020-10-10 呦呦鹿鸣

数据库的常见架构及性能优化

一、数据库的架构演进

数据库的架构是随着网站规模扩展而演进的，随着网站用户的访问量增加，数据库的访问压力也不断增大，因此产生了不同的数据库架构。

1、WEB应用和数据库部署在同一台服务器

起初，网站的用户量、访问量、并发量都比较小，WEB应用和数据库部署在同一台服务器上。

2、数据服务与应用服务分离

随着数据量的增加，一台服务器已经满足不了需求，将数据服务和应用服务分离，WEB应用服务器和数据库服务器各司其职，这样可以在访问量增加的时候分别升级应用服务器和数据库服务器。

3、数据库集群

当单台数据库服务器的处理能力达到上限时，很可能发生宕机事故，这时候可以采取集群方式部署数据库服务器，也就是每一个分库的节点引入多台机器，每台机器保存的数据是一样的，多台机器分摊负载，可以有效减轻数据库压力。

4、数据库读写分离——解决读压力大的问题

数据库的一部分读（未缓存、缓存过期）及所有的写操作都需要经过数据库，当用户量达到一定量，数据库的性能会达到瓶颈，由于大量的数据操作多集中在读的操作上，当读/写比例大概在 10：1左右时，可以适当增加服务器，采取数据库主从复制的方式，将读写分离。

在集群中，一个Group由1个Master和N个Slave组成。其中Master负责写操作的负载，即所有对于数据库的更新操作都是针对主数据库的，而读操作可以针对从数据库来进行，这样一来的可以大大提高读取的效率。

数据库主从复制是通过从服务器到主服务器拉取二进制日志文件，然后将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。所以主服务器必须开启二进制日志，自动记录所有对主数据库的更新操作，从服务器再定时到主服务器取得二进制日志文件进行重放，完成数据的复制。

主从复制数据是异步完成的，这就导致主从数据库中的数据有一定的延迟，在读写分离的设计中必须要考虑这一点。以博客为例，用户登录后发表了一篇文章，他需要马上看到自己的文章，但是对于其它用户来讲可以允许延迟一段时间（1分钟/5分钟/30分钟）。这时对于当前用户就需要读主数据库，对于其他访问量更大的外部用户就可以读从数据库。

5、数据库垂直分割——解决部分数据写的问题

如果数据库服务器是采取主从方式部署的，当写操作占主数据库CPU消耗的50%以上时，从服务器的写操作也将占到CPU消耗的50%以上，一台从服务器提供的查询资源就非常有限，这时应考虑采取数据库垂直分区技术，按照功能把不同的数据分别放到不同的数据库和服务器中。比如用户的个人数据和用户的博客数据，它们之间的关联性不强，可以分别部署在两个独立的数据库服务器上。

6、数据库水平分割——分片

如果数据库垂直分区后仍然无法应对大量的写操作，应采取数据库水平分区技术。把一个表的数据根据一定的规则划分到不同的数据库（两个数据库的表结构一样），进而部署在不同的数据库服务器上。以上述博客为例，数据可以根据user_id的奇偶来确定数据的划分，把id为奇数的数据放到A库，id为偶数的数据放在B库，这样就可以通过user_id知道用户的博客数据在哪个数据库。

 

二、数据库高可用架构

1、基于keepalived主从复制方案

为了达到更高的可用性，在实际的应用环境中，一般都是采用mysql replication技术配合高可用集群软件keepalived来实现自动failover，这种方式可以实现95.000%的SLA。

（注：failover：意思就是当服务器down掉，或者出现错误的时候，可以自动的切换到其他待命的服务器，不影响服务器上App的运行。）

keepalived是一个HA软件，它的作用是检测服务器(web服务器，DB服务器等)状态，检查原理是模拟网络请求检测，检测方式包括HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK等。

对于DB服务器而言，主要就是IP,端口(TCP_CHECK)，但这可能不够(比如DB服务器ReadOnly)，因此keepalived也支持自定义脚本。

keepalived通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。当Master故障时，keepalived感知，并将Slave提升主，继续提供服务对应用层透明。

2、基于MHA高可用解决方案

MHA(Master High Availability)是一套MySQL故障切换方案，保证数据库的高可用。通过从宕机的主服务器上保存二进制日志来进行回补，能在最大程度上减少数据丢失。

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

MHA可以单独部署在一台独立的机器上管理多个master-slave集群，MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。

MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

3、基于Heartbeat/SAN高可用解决方案

处理failover的方式是高可用集群软件Heartbeat，它监控管理各个节点间连接的网络，并监控集群服务。当节点出现故障或不可用时，自动在其他节点启动集群服务。

SAN(Storage Area Network)是一种LAN来处理大数据量的传输，提供了计算机和存储系统之间的数据传输，各个计算机组成的集群可以通过SAN来共享数据。

这种方案可以实现99.990%的SLA。

4、基于DRBD磁盘复制方案

DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和SAN类似的效果。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。

和SAN网络不同，它并不共享存储，而是通过服务器之间的网络复制数据。

5、基于NDB Cluster多点写方案

MySQL Cluster主要由三部分组成：SQL服务器节点、NDB数据存储节点、监控和管理节点，所有的这些节点构成一个完成的MySQL集群体系。

数据保存在“NDB存储服务器”的存储引擎中，表（结构）则保存在“MySQL服务器”中。应用程序通过“MySQL服务器”访问这些数据表，集群管理服务器通过管理工具(ndb_mgmd)来管理“NDB存储服务器”。

 

三、数据库优化

1、优化SQL语句

开启慢查询，通过慢查询日志发现有问题的SQL语句，通过explain查询分析SQL的执行计划；针对limit、group by等进行优化。

2、索引优化

选择合适的列建立索引，一般在where从句，on从句等；维护索引，去掉重复索引 ，如 primary key 不要再加上唯一索引了。

3、数据库的优化

选择合适的数据类型，范式优化和反范式优化（以空间换时间），对数据库表进行合理的垂直切分和水平切分。

4、系统配置和硬件优化

CPU、Cache、SSD硬盘等。