CN109254880B - 一种处理数据库宕机的方法及装置 - Google Patents

Abstract

本发明实施例公开了一种处理数据库宕机的方法及装置，涉及大数据技术领域，能够降低后期进行数据修复的成本。本发明包括：对接收到的访问信息进行报文解析，并根据解析结果生成单据标识；确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中；若所述分库标识存在于宕机列表中，则重新根据所述解析结果生成单据标识，并利用重新生成的单据标识；若所述分库标识不存在于宕机列表中，则根据所述访问信息执行后续处理。本发明适用于分库访问场景。

Description

一种处理数据库宕机的方法及装置

技术领域

本发明涉及大数据技术领域，尤其涉及一种处理数据库宕机的方法及装置。

背景技术

当前，很多在线应用平台，比如电商类平台，需要实时处理海量的在线数据，并且并发量极高，为了能够在此过程快速调取前后台的数据，通常会在数据库设计层面使用分库分表和读写分离的运行方式。

但是，对于短时间内爆发式的用户访问，某个数据库分库突然出现异常并导致宕机是常有的事情，且很难避免。而宕机后若不及时处理，进一步就会造成系统瘫痪，从而中断在线应用平台的正常运营，这会造成极大的经济损失。因此，很多运营商采用主备切换重启服务器等方案来解决问题，并准备多套主备服务器，以便提高整个系统的冗余度。

但配置多套主备服务器的成本很高，而且主备切换过程中会产生大量的异常单据，需要大量维护人员耗费工时处理异常单据，从而又提高了后期进行数据修复的成本。

发明内容

本发明的实施例提供一种处理数据库宕机的方法及装置，能够降低后期进行数据修复的成本。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明的实施例提供的方法，包括：

S1、对接收到的访问信息进行报文解析，并根据解析结果生成单据标识；

S2、确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识；

S3、若所述分库标识存在于宕机列表中，则重新根据所述解析结果生成单据标识，并利用重新生成的单据标识并重新执行S2；若所述分库标识不存在于宕机列表中，则根据所述访问信息执行后续处理。

结合第一方面，在第一方面的第一种可能的实现方式中，还包括：

接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表，其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表；

将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中。

结合第一方面，在第一方面的第二种可能的实现方式中，还包括：

每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表；

当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，还包括：

接收所述配置平台发送的修复消息，其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的；

根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识。

结合第一方面，在第一方面的第四种可能的实现方式中，所述根据所述访问信息执行后续处理，包括：

当检测到所述分库标识不存在于所述宕机列表中时，将当前的单据标识和所述访问信息发送至所述分库标识对应的分库中。

结合第一方面，在第一方面的第五种可能的实现方式中，所述利用重新生成的单据标识重新执行S2，包括：

当所述分库标识存在于宕机列表中时，放弃第一单据标识，其中，所述第一单据标识为第一次执行S1时生成的单据标识；

根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；

重复执行上述过程，直至得到第N单据标识，其中，N≥2，且第N单据标识不存在于所述宕机列表中。

第二方面，本发明的实施例提供的装置，包括：

解析模块，用于对接收到的访问信息进行报文解析；

标识生成模块，用于根据解析结果生成单据标识；

检测模块，用于确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识；若所述分库标识存在于宕机列表中，触发所述标识生成模块重新根据所述解析结果生成单据标识；

业务分发模块，用于若所述分库标识不存在于宕机列表中，根据所述访问信息执行后续处理。

结合第二方面，在第二方面的第一种可能的实现方式中，还包括：

接收模块，用于接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表；并将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中。其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表。

结合第二方面，在第二方面的第二种可能的实现方式中，还包括：

更新模块，用于每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表；

和/或，当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表；

所述更新模块，还用于接收所述配置平台发送的修复消息；并根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识，其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的。

结合第二方面，在第二方面的第三种可能的实现方式中，所述检测模块，具体用于当所述分库标识存在于宕机列表中时，放弃第一单据标识；并根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；重复执行上述过程，直至得到第N单据标识；其中，所述第一单据标识为第一次生成的单据标识，N≥2，且第N单据标识不存在于所述宕机列表中。

本发明实施例提供的处理数据库宕机的方法及装置，基于接收到的访问信息生成新单号，并在写入数据库的请求时的分库判断，所依据的是新生成的请求，再将新生成的请求分发到相应的分库，且在分发请求前，会通过宕机列表检测待分发的请求是否指向了已经宕机的分库，通过宕机列表进行筛选，避免新数据保存到宕机的分库中，从而避免业务发生错误。相对于进行主备切换的处理宕机分库的方式，本发明提供了一种不必使用主备切换的处理宕机分库的方式，从而避免了主备切换后，需要大量维护人员耗费工时处理异常单据的问题，降低了后期进行数据修复的成本。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本发明实施例提供的系统架构示意图；

图2为本发明实施例提供的方法流程示意图；

图3为本发明实施例提供的具体执行流程的实例的示意图；

图4、图5为本发明实施例提供的装置结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本发明实施例所提供的方法流程，具体可以实现在一种如图1所示的系统上，该系统可以依据功能划分为网络层和存储层，其中网络层用于接收客户端设备发送的访问信息。访问信息通过ESB(Enterprise Service Bus，即企业服务总线)发送至负载均衡，再由负载均衡分配至应用服务器集群，其中，服务器集群可以划分为路由层，在路由层运行了用于执行本实施例中流程(比如S1-S3)的应用程序；服务器集群还用于访问存储层的数据库服务器和缓存服务器，以便根据访问信息从存储层查询得到相应的数据。

路由层还接收所述配置平台发送的宕机列表。所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，将宕机的分库标识记录进所述宕机列表；也可以是，由与配置平台相连的系统健康监控系统监控数据库系统中的各分库的运行状态，并通知配置平台记录宕机的分库标识。其中，路由层可以部署在应用服务器上。客户端程序加载时，会通过配置平台(用于监控宕机的分库，并写入宕机列表)自动加载配置文件并保存于客户端程序的内存中，当配置平台配置文件发生变更时，会主动通知运行时的程序重新加载。之后，可以将新生成的单据按照单据号维度保存在不同的分库中。

存储层具体可以包括：数据库服务器和缓存，其中，数据库服务器具体可以是由多个分库组成的集群，依照数据库的架构规则，分库也可分为主库和备库；在缓存中，缓存服务器可以与缓存备机连接，并建立双写随机读取机制，以便提高缓存的读写性能。

本实施例中所揭示的各类服务器，比如数据库服务器、应用服务器和缓存服务器等，具体可以是服务器设备、工作站、超级计算机等设备，或者是由多个服务器组成的一种用于数据处理的服务器集群系统。

本实施例中所揭示的客户端设备具体可以实做成单独一台装置，或整合于各种不同的媒体数据播放装置中，诸如机顶盒、移动电话、平板电脑(Tablet PersonalComputer)、膝上型电脑(Laptop Computer)、多媒体播放器、数字摄影机、个人数字助理(personal digital assistant，简称PDA)、移动上网装置(Mobile Internet Device，MID)或可穿戴式设备(Wearable Device)等。

本发明实施例提供一种处理数据库宕机的方法，如图2所示，包括：

S1、对接收到的访问信息进行报文解析，并根据解析结果生成单据标识。

其中，服务请求方(比如客户端设备)发出一种请求消息，该请求消息指向一个或者多个业务系统的服务，比如：商品查询请求、订单请求、物流查询请求等，则由服务请求方发出的该请求消息可以称为本实施例中的访问信息。通常的，访问信息以报文的形式进行传输，并在应用服务器的路由层上被解析。解析访问信息得到的结果，具体可以包括：订单号、物流编号、用户编码等标识信息，由路由层根据解析得到的这些标识信息中的一个或者多个生成单据标识。

S2、确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中。

其中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识。

在本实施例中，配置平台具体可以是由监控服务器或者监控服务器集群组成的一种监控系统，用于监控存储层中各分库的运行情况，并识别出发生了宕机的分库，且将发生了宕机分库的分库标识写入配置平台维护的宕机列表中。配置平台可以以固定的周期或者在每一次更新宕机列表后，向路由层发布当前的宕机列表。以便于路由层实时获取最新的宕机列表，使得各分库最新的宕机情况被路由层所获得。

其中，单据标识具体可以是一种通过字符串表示的编号(可以简称为单号)，例如：单号＝00+10位的数字序列；分库标识具体也可以是一种通过字符串表示的编号(可以简称为库号)，例如：库号＝10位数字序列+对分库数的取模(比如：分库数表示为n，n％8求余数作为对分库数的取模)。10位数字序列意思就是每次取到的数值＝当前值+1，其中，当前值可以利用数据库的序列自动记住。

S3、若所述分库标识存在于宕机列表中，则重新根据所述解析结果生成单据标识，并利用重新生成的单据标识并重新执行S2。

其中，若所述分库标识不存在于宕机列表中，则根据所述访问信息执行后续处理。访问信息请求业务系统的一项或者多项服务，若所述分库标识不存在于宕机列表中，则表示当前生成的单据标识已经规避了宕机的分库，应用服务器需要触发访问信息所请求的服务。

所述访问信息具体可以是客户端设备发出的业务请求报文，本实施例中根据述所述访问信息生成了分库标识后，还需执行所述访问信息所请求的业务逻辑例如：在客户端设备发出新订单申请的请求报文后，需要根据请求报文执行保存订单信息、扣减库存、处理会员的用券信息和返券信息、处理会员的积分等业务逻辑。

本发明实施例提供的处理数据库宕机的方法，基于接收到的访问信息生成新单号，并在写入数据库的请求时的分库判断，所依据的是新生成的请求，再将新生成的请求分发到相应的分库，且在分发请求前，会通过宕机列表检测待分发的请求是否指向了已经宕机的分库，通过宕机列表进行筛选，避免新数据保存到宕机的分库中，从而避免业务发生错误。相对于进行主备切换的处理宕机分库的方式，本发明提供了一种不必使用主备切换的处理宕机分库的方式，从而避免了主备切换后，需要大量维护人员耗费工时处理异常单据的问题，降低了后期进行数据修复的成本。

具体的，所述利用重新生成的单据标识重新执行S2，包括：

当所述分库标识存在于宕机列表中时，放弃第一单据标识。之后根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；重复执行上述过程，直至得到第N单据标识，其中，N≥2，且第N单据标识不存在于所述宕机列表中。

需要说明的是，单据标识的生成方式基于固定规则，且宕机的情况通常属于极端异常情况，若直接把宕机列表添加至到单号生成逻辑内，使得单据标识直接根据正常的分库生成，则改造的难度太大，且会严重拖慢单据标识的生成速度，使得整个系统的处理效率出现极大下降。而本实施例中，重复生成单据标识并再次检测是否宕机的方式，不需改变固定规则，改造成本极低，因为单号生成逻辑不用改变，因此对于系统的影响几乎可以忽略。

其中，所述第一单据标识为第一次执行S1时生成的单据标识。例如：路由层获取新数据报文请求后，生成新单号，然后由单号算出库号并与宕机库列表进行比对，如果恰巧是宕机的库则放弃此单号，重新生成下一个单号，循环此操作直至生成的单号非宕机的库。如此所有新订单数据就会保存在非宕机的分库中。

具体的，所述根据所述访问信息执行后续处理，包括：当检测到所述分库标识不存在于所述宕机列表中时，将当前的单据标识和所述访问信息发送至所述分库标识对应的分库中。

其中，应用服务器所执行的后续处理，可以理解为向访问信息所指向的业务系统发送业务触发消息，以便于触发业务系统执行访问信息所指向的服务。例如：以单据号作为单据标识为例，本实施例可以实现为如图3所示的新单据保存处理流程。当有新单据数据需要保存时，会先比较新生成的单据号是否落在宕机库上，如果是则放弃此单据号并重新生成新的单据号(即当前时刻最新生成的单据号)。

由于在实际应用中，单个数据库能提供的数据库连接是有限的，达到上限时，新的请求将无法进行数据库连接，而且单库数据量过大会严重影响查询效率，所以现在几乎所有的大型电商平台都使用多个数据库同时来支撑。但是，在分库场景下，目前的系统监控机制较弱，发现宕机故障时间较长的话，某个分库宕机极有可能会引起连锁反应导致整个业务系统瘫痪，比如：分库宕机后，大量的应用服务器会继续连接该分库进行读写操作，由于已宕机肯定会连不上，只能等待连接超时，这个过程中服务器连接数会持续增加，到达上限后新的连接请求则无法再访问服务器，进而表现为整个系统瘫痪，在客户端设备上表现出的现象就是：登录不了、查询不了，尤其是订单处理系统中，会跳出404页面以及访问操作出错的提示页面，这相当于中断了业务流程，严重损害了电商平台的销售额，经济损失巨大。

当需要采用读写分离技术对数据库中的分库进行读写操作时，现有方案经既定路由规则存储数据时，无法判断数据库分库是否已宕机，会出现数据库连接超时失败返回，导致保存失败，比如：根据既定的规则定位到应该存储的数据库时，现有方案不能判断数据库是否已宕机，会出现数据库连接超时失败返回，保存失败。本实施例中可以直接判断出单号对应的数据库已宕机，然后重新生成新的单号，然后被分配保存到其他数据库中。。。本实施例中通过应用服务器上的路由层接收请求(或称为访问信息)，并生成新单号，即每次写入数据库的请求所需要的分库判断，所依据的是新生成的请求，再将新生成的请求分发到相应的分库，从而进一步进行读写操作。且路由层在分发请求前，会通过宕机列表检测待分发的请求是否指向了已经宕机的分库，若是则重新生成请求，直至生成的请求指向的是正常的分库。

通过宕机列表进行筛选，避免新数据保存到宕机的分库中，从而避免业务发生错误，甚至可以免除发生系统瘫痪的重大事故。例如：通过配置平台监控到，指向某个分库的访问请求堆积(比如处于排队等待装态的访问请求大于门限值)，资源消耗大于预设值，处于宕机边缘，或者已经宕机，监控系统自动触发配置平台更新宕机列表。配置平台的宕机列表变化后则会通知路由层运行客户端程序修改路由层上保存的宕机列表，避免新数据保存到宕机的分库。具体的在向存在分库架构的数据库中保存相应的数据的情况下，都可以使用本实施例的方案。

在本实施例中，还包括：接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表。并将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中。

其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表。

进一步的，每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表。当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表。

在实际应用中，成熟的电商平台，高并发平台，都要求系统的高可用性，因此多是采用主备的方式从硬件层面来实现，发生宕机时进行主备切换，一般都会有一定的停机时间以及牺牲业务的情况。

在本实施例中，规避了最常见的网站瘫痪原因，从而避免了局部出问题拖死整个系统的情况发生。并且，宕机列表统一存储在配置平台的服务器上，通过服务端配置管理界面进行配置创建、修改、发布，配置文件内容存储到服务端内存以及数据库中。应用程序初始运行时，通过配置文件客户端相关接口获取配置，当配置文件发生变更后，服务端会自动推送配置变化后的配置文件给应用程序。这样，就可以通过配置文件的方式来修改运行时程序。通过监控平台监控数据库健康状况，出现不健康的情形会自动推送消息通知统一配置平台，配置平台数据变更后自动通知路由层的客户端程序运行时重新加载变量(即宕机列表的内容)，无停机时间，无业务牺牲，因此无需重启系统，从而减少了系统的维护成本，避免了系统重启造成的业务中断的问题。也避免了系统重启造成的部分业务功能不能用，部分用户无法访问的情况发生。

进一步的，还包括：接收所述配置平台发送的修复消息，并根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识。

其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的。

以高并发下保存订单的业务场景进行举例：

订单系统需要保存海量的订单数据，同时峰值并发非常高，基于以上情况，订单系统设计了10个分库来分摊数据量的压力和连接数的压力；同时设计了订单交易系统主要用于保存订单，订单查询系统用于查询订单，即所谓的读写分离。

通常的，在高并发下，会有大量订单保存的需求，前端用户点击保存订单后，会通过远程服务调用框架分发到订单交易系统应用服务器集群上，程序处理首先会生成订单号，通过订单号再获得分库号，由此得到该笔订单信息应该保存在哪台数据库分库上，再访问相应的分库执行保存操作。假设，突然分库3发生了宕机，那么所有需要保存到分库3的数据，都会发生请求超时，保存失败。一般正常保存一笔单据耗时200毫秒，而连接超时的设置一般为2秒。此时，产生的影响是，1)10分之一的订单保存失败无法下单；2)系统整体响应时间变慢，应用服务器上如果堆积太多单据请求，占满服务器的最大能力的话，后续所有单据都会保存失败，系统瘫痪。

在本实施例中，假设突然分库3发生宕机，则用于监控数据库分库运行状态的系统健康监控系统，自动将3库写入到配置平台宕机列表中，配置平台再将宕机的库号列表实时的推送给应用程序。应用程序获取到订单保存请求时，首先生成单号，然后根据单号算出应该保存在分库3上，通过比对发现分库3已宕机，则放弃刚刚生成的单号，重新生成一个单号，再算出应该保存在分库4上，执行保存操作。待分库3修复后，系统健康监控系统则会触发新的动作推送给配置平台，由配置平台再通知应用程序将分库3从宕机列表中去除。

在现有方案中，没有利用配置平台和系统健康监控系统。因此在应用服务器上的程序处理数据前，无法判断需要保存的数据库分库是否已宕机；如果出现个别数据库分库机器宕机，则会出现大量数据保存失败很容易会出现拖死整个系统的情况。

在本实施例中，可以利用健康监控系统自动发现已宕机的数据库，并将机器信息同步到配置平台。

应用服务器的程序代码在无需重启的情况下，可以读取到配置平台变化后的宕机机器信息，并程序生成单号(序列)，通过对单号取模的方式可以得到当前报文涵盖的数据应该保存在某数据库分库上。从而判断出该分库是否是宕机的数据库，如果是则重新生成单号，如果不是则继续走后续的处理逻辑。

本发明实施例还提供一种处理数据库宕机的装置，如图4所示的，包括：

解析模块，用于对接收到的访问信息进行报文解析；

标识生成模块，用于根据解析结果生成单据标识；

检测模块，用于确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识；若所述分库标识存在于宕机列表中，触发所述标识生成模块重新根据所述解析结果生成单据标识；

业务分发模块，用于若所述分库标识不存在于宕机列表中，根据所述访问信息执行后续处理。

在本实施例中，通过应用服务器上的路由层接收请求(或称为访问信息)，并生成新单号，即每次写入数据库的请求所需要的分库判断，所依据的是新生成的请求，再将新生成的请求分发到相应的分库，从而进一步进行读写操作。且路由层在分发请求前，会通过宕机列表检测待分发的请求是否指向了已经宕机的分库，若是则重新生成请求，直至生成的请求指向的是正常的分库。

通过宕机列表进行筛选，避免新数据保存到宕机的分库中，从而避免业务发生错误，甚至可以免除发生系统瘫痪的重大事故。例如：通过配置平台监控到，指向某个分库的访问请求堆积(比如处于排队等待装态的访问请求大于门限值)，资源消耗大于预设值，处于宕机边缘，或者已经宕机，监控系统自动触发配置平台更新宕机列表。配置平台的宕机列表变化后则会通知路由层运行客户端程序修改路由层上保存的宕机列表，避免新数据保存到宕机的分库。具体的在向存在分库架构的数据库中保存相应的数据的情况下，都可以使用本实施例的方案。

进一步的，如图5所示的，还包括：

接收模块，用于接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表；并将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中。其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表。

更新模块，用于每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表；

和/或，当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表；

所述更新模块，还用于接收所述配置平台发送的修复消息；并根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识，其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的。

在本实施例中，所述检测模块，具体用于当所述分库标识存在于宕机列表中时，放弃第一单据标识；并根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；重复执行上述过程，直至得到第N单据标识；

其中，所述第一单据标识为第一次生成的单据标识，N≥2，且第N单据标识不存在于所述宕机列表中。

本发明实施例提供的处理数据库宕机的装置，基于接收到的访问信息生成新单号，并在写入数据库的请求时的分库判断，所依据的是新生成的请求，再将新生成的请求分发到相应的分库，且在分发请求前，会通过宕机列表检测待分发的请求是否指向了已经宕机的分库，通过宕机列表进行筛选，避免新数据保存到宕机的分库中，从而避免业务发生错误。相对于进行主备切换的处理宕机分库的方式，本发明提供了一种不必使用主备切换的处理宕机分库的方式，从而避免了主备切换后，需要大量维护人员耗费工时处理异常单据的问题，降低了后期进行数据修复的成本。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (7)

1.一种处理数据库宕机的方法，其特征在于，包括：

S1、对接收到的访问信息进行报文解析，并根据解析结果生成单据标识；

S2、确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识；

S3、若所述分库标识存在于宕机列表中，则重新根据所述解析结果生成单据标识，并利用重新生成的单据标识并重新执行S2；若所述分库标识不存在于宕机列表中，则根据所述访问信息执行后续处理；

所述利用重新生成的单据标识重新执行S2，包括：

当所述分库标识存在于宕机列表中时，放弃第一单据标识，其中，所述第一单据标识为第一次执行S1时生成的单据标识；

根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；

重复执行上述过程，直至得到第N单据标识，其中，N≥2，且第N单据标识不存在于所述宕机列表中；

所述根据所述访问信息执行后续处理，包括：当检测到所述分库标识不存在于所述宕机列表中时，将当前的单据标识和所述访问信息发送至所述分库标识对应的分库中。

2.根据权利要求1所述的方法，其特征在于，还包括：

接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表，其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表；

将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中。

3.根据权利要求2 所述的方法，其特征在于，还包括：

每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表；

当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表。

4.根据权利要求3所述的方法，其特征在于，还包括：

接收所述配置平台发送的修复消息，其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的；

根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识。

5.一种处理数据库宕机的装置，其特征在于，包括：

解析模块，用于对接收到的访问信息进行报文解析；

标识生成模块，用于根据解析结果生成单据标识；

检测模块，用于确定对应所生成的单据标识的分库标识，并检测所述分库标识是否存在于宕机列表中，所述宕机列表由配置平台生成，所述宕机列表中记录在当前周期内已经宕机的分库标识；若所述分库标识存在于宕机列表中，触发所述标识生成模块重新根据所述解析结果生成单据标识；

业务分发模块，用于若所述分库标识不存在于宕机列表中，根据所述访问信息执行后续处理；

所述检测模块，具体用于当所述分库标识存在于宕机列表中时，放弃第一单据标识；并根据所述解析结果生成第二单据标识，并确定对应所述第二单据标识的单据标识的分库标识，检测对应所述第二单据标识的单据标识的分库标识是否存在于所述宕机列表中；重复执行上述过程，直至得到第N单据标识；

其中，所述第一单据标识为第一次生成的单据标识，N≥2，且第N单据标识不存在于所述宕机列表中；

所述根据所述访问信息执行后续处理，包括：当检测到所述分库标识不存在于所述宕机列表中时，将当前的单据标识和所述访问信息发送至所述分库标识对应的分库中。

6.根据权利要求5所述的装置，其特征在于，还包括：

接收模块，用于接收所述配置平台发送的宕机列表，通过对应所述配置平台的客户端程序加载所述配置平台发送的宕机列表；并将所述配置平台发送的宕机列表保存至所述客户端程序占用的内存中； 其中，所述配置平台用于监控数据库系统中的各分库的运行状态并记录宕机的分库标识，且根据宕机的分库标识更新所述宕机列表。

7.根据权利要求6所述的装置，其特征在于，还包括：

更新模块，用于每隔指定周期，接收所述配置平台发送的宕机列表，并根据所接受到的宕机列表更新所述内存中存储的宕机列表；

和/或，当所述内存中存储的宕机列表的内容发生变动时，触发所述客户端程序重新加载所述内存中当前存储的宕机列表；

所述更新模块，还用于接收所述配置平台发送的修复消息；并根据所述修复消息从所述宕机列表中删除所述修复消息指向的分库标识，其中，所述修复消息由所述配置平台确认至少一个分库从宕机转变为正常运行后发出的。

Images