对浏览器崩溃数据进行处理的方法与系统

暂无

对浏览器崩溃数据进行处理的方法与系统\n技术领域\n[0001] 本发明涉及网络技术领域，特别是涉及一种对浏览器崩溃数据进行处理的方法与系统。\n背景技术\n[0002] 随着互联网技术应用的越来越广泛，人们很多的日常工作和娱乐都在网络上进行，网页浏览器为人们的这种工作和娱乐提供了便捷途径。网页浏览器是显示网页服务器或档案系统内的文件，并让用户与这些文件互动的一种软件。它用来显示在万维网或局部局域网络等内的文字、影像及其他资讯，通过网页浏览器用户可迅速及轻易地浏览各种资讯。\n[0003] 但是，在使用网页浏览器浏览网页，进行网页加载的过程中，常常由于种种原因，例如内存泄露、网页代码复杂、浏览器的Bug、网页数据过多、ajax的web服务漏洞等等，使得网页浏览器反应变得很慢，或者造成网页浏览器失去响应，最终导致浏览器崩溃，进而可能连带整个系统都无法进行其他的操作。\n[0004] 因此，需要有效地对大量的浏览器崩溃数据进行收集存储，以便进行后续的浏览器崩溃分析和处理成为亟待解决的问题。\n发明内容\n[0005] 鉴于上述现有技术无法有效地对大量的浏览器崩溃数据进行收集存储的问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的对浏览器崩溃数据进行处理的方法与系统。\n[0006] 依据本发明的一个方面，提供了一种对浏览器崩溃数据进行处理的方法，包括：浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃基本信息；依据所述上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知所述浏览器侧进行崩溃数据包的上传，并通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中；接收所述浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应所述浏览器崩溃数据保存在所述数据服务器中；对所述崩溃数据包进行分析，并将分析结果对应所述浏览器崩溃数据保存在所述数据服务器中。\n[0007] 根据本发明的另一方面，提供了一种对浏览器崩溃数据进行处理的系统，包括：浏览器崩溃接口服务器和数据服务器；其中，所述浏览器崩溃接口服务器包括：接收模块，用于接收浏览器侧上传的浏览器崩溃基本信息；处理模块，用于依据所述上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知所述浏览器侧进行崩溃数据包的上传，并通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在所述数据服务器中；第一保存模块，用于接收所述浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应所述浏览器崩溃数据保存在所述数据服务器中；第二保存模块，用于对所述崩溃数据包进行分析，并将分析结果对应所述浏览器崩溃数据保存在所述数据服务器中。\n[0008] 根据本发明的对浏览器崩溃数据进行处理的方案，使用云存储技术存储浏览器的崩溃信息，若浏览器发生了崩溃，则浏览器崩溃接口服务器获取浏览器上传的浏览器崩溃基本信息，确定可上传的浏览器崩溃数据，通知浏览器上传崩溃数据包，通过浏览器崩溃缓存服务器保存可上传的浏览器崩溃数据的崩溃基本信息，保存崩溃数据包及对该崩溃数据包进行分析后的分析结果。一方面，云存储可以存储海量数据；另一方面，依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，可以进一步精减上传的崩溃数据量；再一方面，保存对该崩溃数据包进行分析后的分析结果，为后续的浏览器崩溃分析和处理提供了方便。可见，通过本发明，解决了相关技术无法有效地对大量的浏览器崩溃数据进行收集存储的问题，实现了海量浏览器崩溃数据的有效存储。\n[0009] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。\n附图说明\n[0010] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：\n[0011] 图1是根据本发明实施例一的一种对浏览器崩溃数据进行处理的方法的步骤流程图；\n[0012] 图2是根据本发明实施例二的一种对浏览器崩溃数据进行处理的方法的步骤流程图；\n[0013] 图3是根据本发明实施例三的一种对浏览器崩溃数据进行处理的方法的流程示意图；\n[0014] 图4是根据本发明实施例四的一种对浏览器崩溃数据进行处理的系统的结构框图；\n[0015] 图5是根据本发明实施例五的一种对浏览器崩溃数据进行处理的系统的示意图。\n具体实施方式\n[0016] 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。\n[0017] 实施例一\n[0018] 参照图1，示出了根据本发明实施例一的一种对浏览器崩溃数据进行处理的方法的步骤流程图。\n[0019] 本实施例的对浏览器崩溃数据进行处理的方法包括以下步骤：\n[0020] 步骤S102：浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃基本信息。\n[0021] 其中，浏览器崩溃接口服务器可以包括一台或多台服务器。\n[0022] 步骤S104：浏览器崩溃接口服务器依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传，并通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中。\n[0023] 步骤S106：浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据保存在数据服务器中。\n[0024] 步骤S108：浏览器崩溃接口服务器对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据保存在数据服务器中。\n[0025] 通过本实施例，使用云存储技术存储浏览器的崩溃信息，若浏览器发生了崩溃，则浏览器崩溃接口服务器获取浏览器上传的浏览器崩溃基本信息，确定可上传的浏览器崩溃数据，通知浏览器上传崩溃数据包，通过浏览器崩溃缓存服务器保存可上传的浏览器崩溃数据的崩溃基本信息，保存崩溃数据包及对该崩溃数据包进行分析后的分析结果。一方面，云存储可以存储海量数据；另一方面，依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，可以进一步精减上传的崩溃数据量；再一方面，保存对该崩溃数据包进行分析后的分析结果，为后续的浏览器崩溃分析和处理提供了方便。可见，通过本实施例，解决了相关技术无法有效地对大量的浏览器崩溃数据进行收集存储的问题，实现了海量浏览器崩溃数据的有效存储。\n[0026] 实施例二\n[0027] 参照图2，示出了根据本发明实施例二的一种对浏览器崩溃数据进行处理的方法的步骤流程图。\n[0028] 本实施例的对浏览器崩溃数据进行处理的方法包括以下步骤：\n[0029] 步骤S202：浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃基本信息。\n[0030] 本实施例中，浏览器崩溃基本信息包括：根据浏览器崩溃基本信息生成的崩溃标识、崩溃模块信息、崩溃偏移信息、崩溃堆栈信息、浏览器版本号信息、浏览器所在设备的唯一标识号（mid）和操作系统版本号信息。其中，通过在崩溃基本信息中包括mid，后续就可以将发生浏览器崩溃的设备和所上传的浏览器崩溃数据绑定起来，并且在进行浏览器崩溃分析后将分析的结果或者崩溃的相关的预警信息直接发送到与mid相对应的浏览器客户端所在的设备上，从而可以实现对于浏览器崩溃分析信息的定点反馈。\n[0031] 但不限于此，在实际使用中，崩溃信息可以只包括上述信息中的一部分，也可以使用其它与崩溃有关的信息替换上述信息中的部分信息，或者根据实际情况选择其它崩溃信息等。\n[0032] 步骤S204：浏览器崩溃接口服务器依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传。\n[0033] 其中，设定规则可以由本领域技术人员根据实际情况适当设定，优选地，本实施例中，浏览器崩溃接口服务器根据崩溃模块信息、崩溃偏移信息、崩溃堆栈信息、浏览器版本号信息、浏览器所在设备的唯一标识号和操作系统版本号信息，按照MD5算法生成崩溃标识。MD5（Message DigestAlgorithm5，消息摘要算法第五版）为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护，使用MD5算法能够较好地避免生成的崩溃标识的冲突。“崩溃标识的数量”可以由各本领域技术人员根据实际情况适当设置，如，目前SE浏览器的5.0和6.0版本设置为3，Chrome浏览器设置为5万，SE6浏览器设置为5万。\n[0034] 优选地，浏览器崩溃接口服务器根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，并根据崩溃标识的数量和/或浏览器的主程序版本是否在预先定义的版本范围内的判断，确定可上传的浏览器崩溃数据。例如，假设崩溃标识的数量设置为3，即要求对于相同的崩溃数据的接收次数不超过3次。如果dumpkey（崩溃标识）指示已经接收到3个与崩溃基本信息相对应的崩溃数据，则生成指示不允许上传崩溃数据的崩溃序号信息（例如，dumpid=0）并将其返回给浏览器；而如果dumpkey指示已经接收到少于3个与崩溃基本信息相对应的崩溃数据，则生成指示允许上传崩溃数据的崩溃序号信息（例如，dumpid=dump_id）并将其返回给浏览器。另外，可以规定预先定义的浏览器主程序版本范围，例如，对于安全浏览器，可以将版本范围规定为5.0至6.0版本，对于低于5.0版本的安全浏览器，可以生成指示不允许上传崩溃数据的崩溃序号信息并将其返回给浏览器。需要说明的是，上述\n3这个数目仅为所述预先定义的数目的示例，5.0至6.0版本的范围也仅为示例，本发明的范围并不局限于此，本领域技术人员可以根据实际需要选择其它数目和版本范围。\n[0035] 优选地，浏览器崩溃接口服务器通过携带有校验信息的指令通知浏览器侧进行崩溃数据包的上传，其中，检验信息用于指示指令是否来自合法的浏览器崩溃接口服务器。\n[0036] 优选地，本实施例中还设置有第一缓存服务器和第二缓存服务器，当第一缓存服务器根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，确定崩溃标识的数量满足设定数量，并且，当第二缓存服务器确定浏览器崩溃基本信息在设定时间内未重复提交时，则浏览器崩溃接口服务器确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传。使用第二缓存服务器为崩溃信息是否重复提交进行确认，不但保证了提交和交互数据量，也避免了系统因重复提交造成的处理负担，提高了系统处理速度和效率。\n[0037] 优选地，浏览器侧上传的崩溃数据包具有唯一的数据包标识；浏览器崩溃接口服务器在接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据保存在数据服务器中时，接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，根据崩溃数据包的数据包标识，对应浏览器崩溃数据保存在数据服务器中；浏览器崩溃接口服务器在对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据保存在数据服务器中时，对崩溃数据包进行分析，并将分析结果按照崩溃数据包的数据包标识，对应浏览器崩溃数据保存在数据服务器中。\n[0038] 步骤S206：浏览器崩溃接口服务器通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中。\n[0039] 包括：浏览器崩溃接口服务器通过浏览器崩溃缓存服务器接收可上传的浏览器崩溃数据；按照浏览器崩溃数据对应的浏览器所使用的浏览器内核类型，将浏览器崩溃数据分别保存到数据服务器的不同目录下，或者保存到不同的数据服务器中。\n[0040] 优选地，本实施例中，使用数据队列服务器从浏览器崩溃缓存服务器获取崩溃基本信息，进而使用队列将崩溃基本信息存储至数据服务器的数据库中。\n[0041] 步骤S208：浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据保存在数据服务器中。\n[0042] 其中，数据服务器使用与浏览器所在的操作系统相同的操作系统，也即，浏览器崩溃接口服务器接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据同步保存到使用与浏览器所在的操作系统相同的操作系统的数据服务器中。如，浏览器所在的操作系统使用Windows系统，则同步到的操作系统机器也使用Windows系统。\n[0043] 优选地，在具体实现时，浏览器崩溃接口服务器可以接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，将崩溃数据包保存为临时文件；将崩溃数据包持久化存储到数据库中；将存储到数据库的崩溃数据包同步到数据服务器中，并删除临时文件。\n[0044] 优选地，浏览器崩溃接口服务器使用镜像命令，将存储到数据库的崩溃数据包同步到虚拟的操作系统机器中，其中，虚拟的操作系统机器设置于数据服务器中。\n[0045] 步骤S210：浏览器崩溃接口服务器对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据保存在数据服务器中。\n[0046] 本实施例中，设置数据服务器包括主数据服务器和从数据服务器；则，浏览器崩溃接口服务器对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据存储到主数据服务器中，并进行主数据服务器和从数据服务器的同步。\n[0047] 步骤S212：浏览器崩溃接口服务器使用索引服务器对更新到数据服务器中的数据进行增量索引。\n[0048] 步骤S214：当接受到针对更新到数据服务器中的数据的数据检索命令时，浏览器崩溃接口服务器根据增量索引的结果对数据服务器中的数据进行检索。\n[0049] 通过本实施例，实现了海量浏览器崩溃数据的存储的处理分析，进而后续可以根据这些数据和处理分析结果对浏览器进行修正，以避免或尽量减少浏览器崩溃现象的发生。\n[0050] 实施例三\n[0051] 参照图3，示出了根据本发明实施例三的一种对浏览器崩溃数据进行处理的方法的流程示意图。\n[0052] 本实施例中，使用多个服务器实现浏览器崩溃接口服务器的功能，以避免浏览器崩溃接口服务器负荷过重，且使功能划分更为清晰，但本领域技术人员应当明了，当服务器具备较高性能时，浏览器崩溃接口服务器可以仅使用一台服务器实现。本实施例中，实现浏览器崩溃接口服务器功能的多个服务器包括云崩溃服务端1、云崩溃服务端2、云崩溃服务端3，以及操作系统机器等。\n[0053] 本实施例的对浏览器崩溃数据进行处理的方法包括以下步骤：\n[0054] 步骤S302：浏览器发生崩溃，浏览器客户端调用GET接口向云崩溃服务端1发送浏览器崩溃基本信息。\n[0055] 其中，浏览器崩溃基本信息的信息内容可参照下述步骤S310中的表1中的内容。\n[0056] 其中，GET接口用于接收浏览器发送来的get请求，在get请求中携带有上传的浏览器崩溃的基本信息。本实施例中，由云崩溃服务端1来处理浏览器终端上报的Get请求。\n步骤S304：云崩溃服务端1接收并验证浏览器发送的浏览器崩溃基本信息。\n[0057] 浏览器上传数据时，云崩溃服务端1验证数据交互密钥（如cverify效验），以保证数据来源合法及完整性。\n[0058] 步骤S306：云崩溃服务端1向缓存服务器发送浏览器崩溃基本信息。\n[0059] 步骤S308：缓存服务器根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，并根据崩溃标识的数量确定上传浏览器崩溃基本信息对应的崩溃数据，向云崩溃服务端1返回确定上传信息。\n[0060] 本实施例中，缓存服务器包括缓存服务器1和缓存服务器2。\n[0061] 其中，缓存服务器2进行2秒数据提交限制，防止浏览器在2秒钟之内连续提交两次相同数据。其判断规则基于cverify，如果在浏览器在2秒钟之内连续提交两次相同数据，则视为一次提交。2秒数据提交限制仅为示例性说明，该时间可由本领域技术人员根据实际情况适当设置，不限于2秒。\n[0062] 缓存服务器1根据一定规则生成dumpkey（即崩溃标识）,根据dumpkey的存在数量，判断是否可以上传崩溃信息对应的dump（即崩溃数据）。\n[0063] 步骤S310：数据队列服务器从缓存服务器获取浏览器崩溃基本信息，使用队列将浏览器崩溃基本信息存储至MYSQL数据库的主数据库中。\n[0064] 数据队列服务器把浏览器崩溃基本信息放入队列，服务器后端启动进程把队列中的数据存入到MYSQL。\n[0065] 一种MYSQL存储崩溃信息的格式如下表1所示：\n[0066] 表1浏览器崩溃基本信息存储格式\n[0067] \n[0068] \n[0069] \n[0070] 通过上表，可以对浏览器崩溃基本信息进行有效存储和处理。\n[0071] 步骤S312：MYSQL主数据库将存储的浏览器崩溃基本信息的数据同步到MYSQL从数据库中。\n[0072] 步骤S314：云崩溃服务端1根据确定上传信息，向浏览器发送崩溃数据上传信息，指示浏览器上传崩溃数据。\n[0073] 崩溃数据是不同于崩溃信息的数据，可以包括部分内存和崩溃的线程，以及线程调用栈等相关信息，其内容是系统抓的崩溃快照，包括系统当前的寄存器，崩溃数据可以采用二进制文件的形式。例如，云崩溃服务端1可以把json格式的确定上传信息返回给浏览器。如果可以上传dump（即崩溃数据），浏览器继续进行dump上传操作，否则此次交手结束。浏览器可以根据服务器返回标识判断是否可以上传dump包，如dumpid=0代表不允许上传dump包，大于0允许上传dump包。此外，云崩溃服务端1返回的数据中携带sverify信息，以保证返回数据确实来自合法的服务器。\n[0074] 需要说明的是，本步骤不限于本实施例中的执行顺序，在步骤S308后执行即可。\n[0075] 步骤S316：浏览器根据云崩溃服务端1返回的信息，调用POST接口将崩溃数据上传到云崩溃服务端2。\n[0076] 其中，POST接口是浏览器向服务器侧进行Dump数据包（崩溃数据包）发送的接口，通过POST接口将崩溃数据包进行上传。\n[0077] 浏览器将崩溃数据上传到云崩溃服务端2时，云崩溃服务端2进行数据效验，判断崩溃数据来源是否合法；验证数据交互密钥（如cverify校验），以保证数据来源合法及完整性；以及，POST数据的其它一些安全校验，如内容是否为空、ID是否正确等。\n[0078] 步骤S318：云崩溃服务端2接收浏览器上传的崩溃数据，将崩溃数据保存为临时文件。\n[0079] 云崩溃服务端2一方面把上传的dump文件保存为临时文件，移动到临时目录；另一方面，把通过POST接口上传的dump存入到队列中（每一台服务器都可以有一个队列），然后，给浏览器返回信息，告知浏览器是否此次交手完毕。\n[0080] 如，设定云崩溃服务端2具有四台临时文件服务器，上传的dump中可以携带相应的临时文件服务器的路径信息，则根据这些路径信息可以将dump上传到对应的临时文件服务器中保存为临时文件。\n[0081] 步骤S320：云崩溃服务端2将崩溃数据持久化存储到Cassandra数据库中。\n[0082] 步骤S322：云崩溃服务端2将存储到Cassandra数据库中的崩溃数据同步到操作系统机器中，并删除临时文件。\n[0083] 优选地，云崩溃服务端2使用镜像命令，将存储到Cassandra数据库中的dump同步到虚拟的操作系统机器中。\n[0084] 以云崩溃服务端2使用Linux操作系统，操作系统机器也使用Linux操作系统，但为dump建立虚拟的Windows环境为例，云崩溃服务端2读取dump队列，把se、chrome各自的dump传送到相应的两台虚拟的Windows环境下的Windows机器目录下。其中，Linux系统向Windows同步文件可以采用基于C/S模式软件的rsync实现。rsync是数据镜像备份工具，可以镜像保存整个目录树和文件系统。\n[0085] 如：cwRsync，则Rsync LINUX把dump文件同步到Windows命令示例如下：\n[0086] Rsync-topg本地 路径rsync:://windows机 器IP/目录 地址，一 个实 例如:rsync-topg/data/tmp/xxxx.dmp rsync:://192.168.100.29/dump。\n[0087] 同步到Windows后，被同步的dump文件，即在云崩溃服务器的临时文件夹中的dump文件被删除。\n[0088] 步骤S324：操作系统机器对崩溃数据进行分析，获取分析结果并存储到MYSQL数据库中。\n[0089] 一种方式是：Windows机器上步署了自动dump包分析程序，随时监控当前目录下文件。一旦发现有新的dump文件，立马分析，然后向云崩溃服务端3回传数据，以达到实时分析回传。另一种方式是：Windows机器调用云崩溃服务端3的自动化分析接口，依据上述的同步到Windows中的dump文件，调用自动化分析接口对于dump文件进行分析，并由云崩溃服务端3将分析结果插入到主数据库MYSQL中。\n[0090] 本实施例中，分析结果存储采用MYSQL+SPHINX的架构，云崩溃服务端3采用MYSQL作为永久存储引擎，当前系统采用主从数据库分离、按月分表技术。其中，主从数据库之间的数据自动同步，主数据库可以专门用于客户端数据插入，即浏览器崩溃数据的插入，从数据库可以用于后台管理员管理，及SPHINX服务器索引源头。使用SPHINX索引服务器可以对于不断更新的崩溃数据进行增量索引，实现管理员的实时崩溃数据的检索。\n[0091] 通过本实施例，实现了海量浏览器崩溃数据的存储的处理分析，进而后续可以根据这些数据和处理分析结果对浏览器进行修正，以避免或尽量减少浏览器崩溃现象的发生。\n[0092] 实施例四\n[0093] 参照图4，示出了根据本发明实施例四的一种对浏览器崩溃数据进行处理的系统的结构框图。\n[0094] 本实施例的对浏览器崩溃数据进行处理的系统包括浏览器崩溃接口服务器40和数据服务器42。\n[0095] 其中，浏览器崩溃接口服务器40包括：接收模块402，用于接收浏览器侧上传的浏览器崩溃基本信息；处理模块404，用于依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传，并通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中；第一保存模块406，用于接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据保存在数据服务器中；第二保存模块408，用于对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据保存在数据服务器中。\n[0096] 优选地，浏览器崩溃基本信息包括：根据浏览器崩溃基本信息生成的崩溃标识、崩溃模块信息、崩溃偏移信息、崩溃堆栈信息、浏览器版本号信息、浏览器所在设备的唯一标识号和操作系统版本号信息。\n[0097] 优选地，处理模块404在依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据时，根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，并根据崩溃标识的数量和/或浏览器的主程序版本是否在预先定义的版本范围内的判断，确定可上传的浏览器崩溃数据。\n[0098] 优选地，处理模块404在根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，并根据崩溃标识的数量确定可上传的浏览器崩溃数据时，根据崩溃模块信息、崩溃偏移信息、崩溃堆栈信息、浏览器版本号信息和操作系统版本号信息，按照MD5算法生成崩溃标识。\n[0099] 优选地，处理模块404在通知浏览器侧进行崩溃数据包的上传时，通过携带有校验信息的指令通知浏览器侧进行崩溃数据包的上传，其中，检验信息用于指示指令是否来自合法的浏览器崩溃接口服务器。\n[0100] 优选地，第一保存模块406，用于接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，并对应浏览器崩溃数据同步保存到数据服务器中，其中，数据服务器使用与浏览器所在的操作系统相同的操作系统。\n[0101] 优选地，第一保存模块406，用于接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，将崩溃数据包保存为临时文件；将崩溃数据包持久化存储到数据库中；将存储到数据库的崩溃数据包同步到数据服务器中，并删除临时文件。\n[0102] 优选地，第一保存模块406在将存储到数据库的崩溃数据包同步到数据服务器时，使用镜像命令，将存储到数据库的崩溃数据包同步到虚拟的操作系统机器中，其中，虚拟的操作系统机器设置于数据服务器中。\n[0103] 优选地，数据服务器包括主数据服务器和从数据服务器；第二保存模块408，用于对崩溃数据包进行分析，并将分析结果对应浏览器崩溃数据存储到主数据服务器中，并进行主数据服务器和从数据服务器的同步。\n[0104] 优选地，处理模块404在依据上传的浏览器崩溃基本信息确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传时，当第一缓存服务器根据浏览器崩溃基本信息，按照设定规则生成崩溃标识，确定崩溃标识的数量满足设定数量，并且，当第二缓存服务器确定浏览器崩溃基本信息在设定时间内未重复提交时，则确定可上传的浏览器崩溃数据，通知浏览器侧进行崩溃数据包的上传。\n[0105] 优选地，浏览器侧上传的崩溃数据包具有唯一的数据包标识；第一保存模块406，用于接收浏览器侧上传的浏览器崩溃数据对应的崩溃数据包，根据崩溃数据包的数据包标识，对应浏览器崩溃数据保存在数据服务器中；第二保存模块408，用于对崩溃数据包进行分析，并将分析结果按照崩溃数据包的数据包标识，对应浏览器崩溃数据保存在数据服务器中。\n[0106] 优选地，处理模块404在通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中时，通过浏览器崩溃缓存服务器接收可上传的浏览器崩溃数据；按照浏览器崩溃数据对应的浏览器所使用的浏览器内核类型，将浏览器崩溃数据分别保存到数据服务器的不同目录下，或者保存到不同的数据服务器中。\n[0107] 优选地，处理模块404在通过浏览器崩溃缓存服务器将可上传的浏览器崩溃数据的崩溃基本信息保存在数据服务器中时，数据队列服务器从浏览器崩溃缓存服务器获取崩溃基本信息，使用队列将崩溃基本信息存储至数据服务器的数据库中。\n[0108] 优选地，浏览器崩溃接口服务器还包括：索引模块410，用于使用索引服务器对更新到数据服务器中的数据进行增量索引；当接受到针对更新到数据服务器中的数据的数据检索命令时，根据增量索引的结果对数据服务器中的数据进行检索。\n[0109] 本实施例的对浏览器崩溃数据进行处理的系统用于实现前述多个方法实施例中相应的对浏览器崩溃数据进行处理的方法，并具有相应的方法实施例的有益效果，在此不再赘述。\n[0110] 实施例五\n[0111] 参照图5，示出了根据本发明实施例五的一种对浏览器崩溃数据进行处理的系统的示意图。\n[0112] 本实施例是对实施例四的实例说明，本实施例的对浏览器崩溃数据进行处理的系统主要包括浏览器端100和云端200这两大部分。浏览器端100可以包括一个或者多个浏览器客户端1、浏览器客户端2、……浏览器客户端n，它们通过GET接口14和POST接口\n15与云端200通信。\n[0113] 在云端200，可以包括三个云崩溃服务器—云崩溃服务器4、云崩溃服务器5、云崩溃服务器6。这三个云崩溃服务器联合实现实施例四中的浏览器崩溃接口服务器40的功能。但不限于此，其它数量的云崩溃服务器也同样适用。\n[0114] 在浏览器端100通过POST接口15将浏览器崩溃数据发送到云端200之后，可以根据与云端200的一个或者多个云崩溃服务器的唯一标识相对应的保存目录，来保存浏览器崩溃数据。例如，假设key1、key2、key3分别代表上述三个云崩溃服务器的诸如IP地址之类的唯一标识，而与这些key相对应的值即为崩溃数据的存放目录。而在此之前，可以在云崩溃服务器中先建立临时目录，将崩溃数据暂存在此临时目录中。\n[0115] 对于云崩溃服务器4（相当于实施例四中的接收模块402和处理模块404），其可以用于处理上述各实施例所述的崩溃基本信息，在云端200接收到从浏览器通过GET接口\n14上传的浏览器崩溃基本信息之后，通过缓存服务器7将浏览器崩溃基本信息保存到云端\n200的数据队列服务器8中，然后从数据队列服务器8中读取浏览器崩溃基本信息并且保存到云端200的数据库，例如MySQL数据库9中。MySQL数据库9可以包括主库91和从库\n92。\n[0116] 对于云崩溃服务器5（相当于实施例四中的第一保存模块406），其可以用于将浏览器崩溃数据通过同步的方式传送到基于与云崩溃服务器的操作系统不同的操作系统的计算机中。例如，假设云崩溃服务器所采用的操作系统为Linux，如果希望将浏览器崩溃数据传送到操作系统为Windows的计算机中，就可以通过同步的方式（例如采用用于从Linux向Windows同步文件的自动化分析接口13）将崩溃数据从基于Linux操作系统的崩溃服务器传送到基于Windows操作系统的计算机中。如图5所示，例如可以布置两台Windows计算机，即，Windows机器11和Windows机器12，其中一台可以用于处理来自例如基于IE内核的安全浏览器的崩溃数据，另一台可以用于处理来自基于Webkit内核的Chrome浏览器的崩溃数据。\n[0117] 在将崩溃数据传送到基于Windows操作系统的计算机之后，可以读取崩溃数据队列，将属于不同浏览器的崩溃数据传送到相应的Windows计算机目录下。上述目录可以按照年/月/日来进行划分。可以采用C语言来开发用于Windows年/月/日自动目录生成的脚本。还可以在Windows计算机上布置自动崩溃数据分析程序，以随时监控当天目录下的崩溃数据。一发现有新的崩溃数据，就立刻执行分析，然后向云端200回传数据，从而实现了实时分析回传。\n[0118] 对于云崩溃服务器6（相当于实施例四中的第二保存模块408），其可以对浏览器崩溃数据进行分析，进而通过Sphinx索引服务器10将分析结果保存到MySQL数据库9中。\n[0119] 另外，Sphinx索引服务器10（相当于实施例四中的索引模块410），用于对更新到MySQL数据库9中的数据进行增量索引，在接受到针对更新到MySQL数据库9中的数据的数据检索命令时，根据增量索引的结果对MySQL数据库9中的数据进行检索。\n[0120] 本实施例的对浏览器崩溃数据进行处理的系统用于实现前述多个方法实施例中相应的对浏览器崩溃数据进行处理的方法，并具有相应的方法实施例的有益效果，在此不再赘述。\n[0121] 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。\n各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造具有本发明方案的系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。\n[0122] 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。\n[0123] 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。\n[0124] 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。\n[0125] 此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。\n[0126] 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的对浏览器崩溃数据进行处理的方案中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。\n[0127] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。