数据库高并发升级方案1讲解.docx
《数据库高并发升级方案1讲解.docx》由会员分享，可在线阅读，更多相关《数据库高并发升级方案1讲解.docx（13页珍藏版）》请在冰豆网上搜索。
数据库高并发升级方案1讲解
XXXXXXXXXXXX平台
数据库升级方案
XXXXXXXXXXXXXXX有限公司
2016年11月28日
修订记录
版本
说明
作者
批准
批准日期
V1.0
对升级方案进行编制
XX
XX
2016年12月1日1
1.
概述
1.1.背景
随着XXXXXX平台及其他子系统业务量增多，且用户已面向各地州市，用户数量增大，现有的二代办公平台及其他子系统在单一环境下的架构体系和数据库架构体系也无法高效的满足这样的场景。
当前XXXXXX平台及其子系统通过搭建多台WEB服务器和双机热备份的方式进行部署运行。
虽已提高了整体效率，但对于部分的业务处理还是未解决。
部分业务量并发处理多，业务关联多等因素，导致对数据库并发处理的业务量大，读写量大等也无法用双机热备份进行解决。
因此，在此背景下提高数据库访问效率，增大访问吞吐量等将成为二代办公平台及其子系统运行顺畅的关键因素。
1.2.目标与目的
目标：
依托现有系统服务和设备环境，建立可扩容、高并发、高吞吐量的数据库架构体系。
目的：
为缓解当前XXXXXX平台机器及其他子系统对数据库访问过大，造成的访问效率低下的问题，提升数据库访问效率和并发效率。
对部分业务繁杂的表和访问进行优化设计，缓解因此造成的使用效率低下问题。
1.3.可行性分析
数据库性能分析：
根据当前的数据库性能分析，当前硬件设备的提高也无法满足数据库性能的提升，因此应考虑数据库访问控制和数据访问方面进行优化。
现有的数据库虽也实现双机热备份，但访问的效率未较大改善，因此应考虑各健全的数据库高并发访问方案。
数据库优化分析：
当前的数据库采用的ORACLE数据库，同时，现有的均衡负载、读写分离、数据分割技术较为成熟，在对系统进行适当调整和优化的情况下，能保证系统的正常运行。
1.4.参考依据
《OracleRAC核心技术详解》
2.数据库高并发方案
2.1.数据库均衡负载（RAC）
RAC，全称realapplicationclusters，译为“实时应用集群”，是Oracle新版数据库中采用的一项新技术，是高可用性的一种，也是Oracle数据库支持网格计算环境的核心技术。
OracleRAC主要支持Oracle9i、10g、11g版本，可以支持24x7有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。
在OracleRAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。
当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。
RAC是一种并行模式，并不是传统的主备模式。
也就是说，RAC集群的所有成员都可以同时接收客户端的请求。
RAC具备以下特点：
双机并行：
RAC是一种充分利用服务器资源的高可用性实现方案，RAC的并行模式实现方式与传统的双机热备实现方式截然不同，图1-1是两者的比较。
如图1-1所示，两个节点在传统的双机热备环境中，始终有一台机器作为备用机，只有当主节点出现问题的时候才会切换到备用机上;如果主机一直没有出现问题，那么备用机始终处于空闲状态，这在资源的利用上以及成本方面都是巨大的浪费。
但RAC是一种并行模式的架构，也就是说，两个节点的集群节点间是一种并行运行的关系，当一台机器出现问题，请求会自动转发到另一台机器，没有任何一台机器作为备用机一直不被使用，这样就充分利用了服务器资源。
同时，传统的双机热备构架在出现问题时，常常需要数分钟的切换时间，而RAC在出现问题时，针对存在的会话只需要数十秒的时间就可以完成失败切换过程，对新会话的创建不会产生影响，在切换时间上也有比较大的优势。
▲图1-1双机热备与RAC并行模式对比
高可用性：
RAC是Oracle数据库高可用性解决方案。
高可用性包含两部分的内容：
首先是在这种解决方案下要确保数据不丢失，这是最基础的也是必须要保证的;其次是确保不停机，使Oracle数据库一直维持在正常的运行状态，避免停机给客户带来的损失，这是讨论最多的内容。
停机一般分为两类，计划停机和非计划停机。
所谓计划停机是有计划地安排节点或者系统的停机，一般在Oracle升级、系统维护或者硬件维护的情况下会出现。
非计划停机就是在非人为计划的情况下突然停机，这种情况一般是在Oraclebug、系统故障、硬件故障或人为操作失败的时候出现。
在没有较高花费的情况下，想实现系统100%的不停机几乎是不可能的。
表1-1列出了特定百分比高可用性比率运行停机的时间，详细记录了每种高可用性比率每年、每月、每周可以出现最大的停机时间。
通常情况下，以每月停机时间来计算对应的可用性比率。
根据系统的重要性情况，应该为系统设定合理的可用性比率。
集群最大的优势在于它的高可用性，通过使用RAC可以在一定程度上避免因为硬件或软件故障引起的数据丢失和非计划停机，并在一定程度上减少或排除计划停机时间。
这是很多客户选择RAC的最直接原因。
RAC中包含了非常多的高可用特性，主要包含如下几点：
·实现节点间的负载均衡。
·实现失败切换的功能。
·通过Service组件来控制客户端的访问路径。
·集群软件能够自动化管理各个资源，并且有定时的节点状态检测机制，能自动对一些失败的进程以及心跳检测失败的节点进行重启，使其重新恢复到正常的运行状态。
在Oracle11gR2版本中，Clusterware得到了改善，提供了更高的可用性。
例如，大量新的基于代理的监控系统用于监控所有的资源。
这些代理使用更少的资源执行更频繁的检查，即更快速的失败扫描和更短的恢复时间。
在Oracle监听的例子中，平均失败扫描时间从5分钟减少到30秒，同时，检查间隔从每10分钟减少到1分钟。
另外，Clusterware的“Out-of-PlaceUpgrade”等特性也减少了软件维护需要的停机时间。
易伸缩性：
RAC为需要重新规划的应用提供了易扩展性。
为了在系统初始阶段保持较低的成本，避免造成不必要的浪费，集群可以按照标准硬件配置，选择适当的服务器资源、存储资源来搭建数据库环境。
当系统需要更多的处理能力或者需要增加存储时，通过添加另一台服务器或存储设备到集群中，能够在不停机的情况下获得水平的扩展。
在一个集群中，Clusterware和RAC支持多达100个集群节点。
当某个集群的处理能力过剩，另一个集群的处理能力不够时，可以从处理能力过剩的集群移动一个节点到处理能力不够的集群中。
这样能够充分利用服务器资源，节约成本。
11gR2版本中推出了网格即插即用（GridPlugandPlay，GPnP），可以实现节点的快速添加。
低成本：
通过多台普通的PC服务器组成一个集群，可以提高集群的处理能力，这样要比采用一台高性能的服务器的成本低很多。
如果想提高系统的处理能力，给集群添加节点比为高性能服务器添加硬件要容易得多。
另外，使用集群还能动态地移除节点，更加充分地利用管理者掌握的所有服务器资源，从服务器整体使用上降低了服务器的采购成本。
越来越多的企业愿意将集群解决方案应用到他们的系统中，以降低成本，提高系统的可用性。
高吞吐量：
RAC是由多台服务器构成的逻辑主体，比单台数据库服务器能接收更多的客户端请求。
这在要求高吞吐量的系统中，能够得到非常明显的体现。
在RAC的架构中，多个实例分布在多个服务器上，能同时打开同一个数据库，而每个实例能够接收相等数量的客户端请求，这样，随着服务器的增加，吞吐量也在不断地增加。
2.2.数据库主从部署
主从复制：
几乎所有的主流数据库都支持复制，这是进行数据库简单扩展的基本手段。
Oracle的主从复制可采用DataGuard技术,DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。
DataGuard提供了三种日志传输（RedoTransport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。
在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（MaximumPerformanceMode）、最大保护（MaximumProtectionMode）和最大可用（MaximumAvailabilityMode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。
读写分离：
读写分离是架构分布式系统的一个重要思想。
不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。
针对业务类型特点，需要从架构模式上进行一系列的调整，比如业务模块的分割，数据库的拆分等等。
2.3.数据库垂直分割
主从部署数据库中，当写操作占了主数据库的CPU消耗的50%以上的时候，我们再增加从服务器的意义就不是很大了，因为所有的从服务器的写操作也将占到CPU消耗的50%以上，一台从服务器提供出来查询的资源非常有限。
数据库就需要重新架构了，我们需要采用数据库垂直分区技术啦。
最简单的垂直分区方式是将原来的数据库中独立的业务进行分拆（被分拆出来的部分与其它部分不需要进行Join连接查询操作），比如WEB站点的BLOG和论坛，是相对独立的，与其它的数据的关联性不是很强，这时可以将原来的数据库拆分为一个BLog库，一个论坛库，以及剩余的表所组成的库。
这三个库再各自进行主从数据库方式部署，这样整个数据库的压力就分担啦。
另外查询扩展性也是采用数据库分区最主要的原因之一。
将一个大的数据库分成多个小的数据库可以提高查询的性能，因为每个数据库分区拥有自己的一小部分数据。
假设您想扫描1亿条记录，对一个单一分区的数据库来讲，该扫描操作需要数据库管理器独立扫描一亿条记录，如果您将数据库系统做成50个分区，并将这1亿条记录平均分配到这50个分区上，那么每个数据库分区的数据库管理器将只扫描200万记录。
2.4.数据库水平分割
在数据库的垂直分区之后，假如我们的BLOG库又再次无法承担写操作的时候，我们又该怎么办呢？
数据库垂直分区这种扩展方式又无能为力了，我们需要的是水平分区。
水平分区意味着我们可以将同一个数据库表中的记录通过特定的算法进行分离，分别保存在不同的数据库表中，从而可以部署在不同的数据库服务器上。
很多的大规模的站点基本上都是主从复制+垂直分区+水平分区这样的架构。
水平分区并不依赖什么特定的技术，完全是逻辑层面的规划，需要的是经验和业务的细分。
如何分区呢？
对于大型的WEB站点来说，必须分区，并且对于分区我们没有选择的余地，对于那些频繁访问导致站点接近崩溃的热点数据，我们必须分区。
在对数据分区的时候，我们必须要存在一个分区索引字段，比如USER_ID，它必须和所有的记录都存在关系，是分区数据库中的核心表的主键，在其它表中作为外键，并且在使用主键的时候，该主键不能是自增长的，必须是业务主键才可以。
余数分区：
我们可以将User_ID%10后的值为依据存入到不同的分区数据库中，该算法简单高效，但是在分区数据库个数有变动的时候，整个系统的数据需要重新分布。
范围分区：
我们可以将User_ID的范围进行分区，比如1-100000范围为一个分区数据库，100001-200000范围为一个分区数据库，该算法在分区数据库个数有变动的时候，系统非常有利于扩展，但是容易导致不同分区之间的压力不同，比如老用户所在的分区数据库的压力很大，但是新用户的分区数据库的压力偏小。
映射关系分区：
将对分区索引字段的每个可能的结果创建一个分区映射关系，这个映射关系非常庞大，需要将它们写入数据库中。
比如当应用程序需要知道User_id为10的用户的BLOG内容在那个分区时，它必须查询数据库获取答案，当然，我们可以使用缓存来提高性能。
这种方式详细保存了每一个记录的分区对应关系，所以各个分区有非常强的可伸缩性，可以灵活的控制，并且将数据库从一个分区迁移到另一个分区也很简单，也可以使各个分区通过灵活的动态调节来保持压力的分布平衡。
3.数据库优化设计
3.1.数据库集群
数据库集群高可用的方案主要有三种：
RAC、DataGuard、MAA。
其中：
RAC在多个Oracle服务器组成一个共享的Cache，而这些Oracle服务器共享一个基于网络的存储。
这个系统可以容忍单机/或是多机失败。
不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。
DataGuard这个方案就适合多机房的。
某机房一个production的数据库，另外其他机房部署standby的数据库。
Standby数据库分物理的和逻辑的。
物理的standby数据库主要用于production失败后做切换。
而逻辑的standby数据库则在平时可以分担production数据库的读负载。
MAA（MaximumAvailabilityArchitecture）其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。
3.2.重点业务表分区
当表中的数据量不断增大，查询数据的速度就会变慢，应用程序的性能就会下降，这时就应该考虑对表进行分区。
表进行分区后，逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间（物理文件上），这样查询数据时，不至于每次都扫描整张表。
表分区的类型及操作方法主要包括范围分区、列表分区、散列分区等，其中：
范围分区将数据基于范围映射到每一个分区，这个范围是你在创建分区时指定的分区键决定的。
这种分区方式是最为常用的，并且分区键经常采用日期。
列表分区的特点是某列的值只有几个，基于这样的特点我们可以采用列表分区，比如地区。
散列分区是在列值上使用散列算法，以确定将行放入哪个分区中。
当列的值没有合适的条件时，建议使用散列分区。
散列分区为通过指定分区编号来均匀分布数据的一种分区类型，因为通过在I/O设备上进行散列分区，使得这些分区大小一致。
3.3.任务表历史数据分割
现有的任务表SA_TASK任务繁重，数据冗余，基本上的流程操作都在该表，二代办公开发平台（x5）以对此也进行了升级优化，就是将任务表已完结的历史数据单独存放，缩小任务表的数据量，提高查询的效率。
正在办理的任务数据存放与SA_TASK表中，办理办结后则清除并存放于SA_TASK_HISTORY（历史表）中。
这样SA_TASK中只有正在办理的数据，将大大降低数据冗余的情况，同时提高SA_TASK表的读写能力。
而查询经办文件时可查询SA_TASK_HISTORY（历史表），与频繁操作的SA_TASK区分开更易读取。
3.4.数据库表结构优化
随着省厅的业务量增大，最初的结构设计和调整使数据库表结构变得冗余，存在部分非表主要的属性，同时业务表结构过大，单条数据的字节数已超过1万多字节，因此在查询过程中也会占用查询效率。
优化数据库表结构，也是提升查询效率的重要手段。
对数据库非主属性的字段进行分割和处理，对结构进行优化设计；对数据库字段字节长度和类型进行设置，对于明确长度的字段进行优化（VARCHAR2也会影响查询效率），降低单表结构的复杂度。
3.5.数据访问优化
数据库相关SQL语句的查询方式也是影响数据库访问效率的原因之一，比如在数据量较大的表中进行排序、分组等操作。
因此在对特定的业务处理上，除了增大数据库的访问能力以外，同时需要提升数据库的访问效率。
对此，应建立优化数据库索引，在对写操作无影响的情况下，提升查询的效率。
同时，在查询时，因减少影响查询效率的操作，如DISTINCT、UNION等关键字。
4.实施方案
序号
任务内容
参与人
周期
备注
1
方案编制和制定
项目经理
7天
对数据库均衡负载、主从部署、分区等进行方案设计。
2
技术方案验证
软件架构师*1
15天
对数据库均衡负载、主从部署、分区等进行方案设计。
3
环境准备
实施工程师*1
3天
构建模拟环境，进行验证
4
技术实现
数据库工程师*2
20天
对系统进行升级优化和数据库访问进行并发优化
5
部署运行
实施工程师*2
5天
在正式系统上实施
6
测试
测试工程师*2
5天
编写测试报告、整理测试结果。
7
运行维护
实施工程师*1
30天
对升级后的系统运行进行维护和日常问题处理。
5.
工作量及预算评估
5.1.工作量及预算评估
序号
工作内容
工作量评估
参与人员
预算评估
备注
1
方案制定
7人/天
对数据库均衡负载、主从部署、分区等进行方案设计。
2
方案验证
15人/天
对方案进行验证分析，确定可行性。
3
技术实现
40人/天
对系统进行升级优化和数据库访问进行并发优化
4
测试运行
10人/天
编写测试报告、整理测试结果。
5
运行维护
30人/天
对升级后的系统运行进行维护和日常问题处理。
总计：
5.2.其他费用
序号
预算开支
预算金额
备注
1
交通费
总公司参与分公司项目产生的交通费
2
管理费
分公司相关的管理费用，如水、电，房租。
3
商务费
咨询、劳务费用
4
其他
利润、税费、其他费用
升级会员 