一种缓解服务端数据库访问压力的方法和装置制造方法
【专利摘要】本发明公开了一种缓解服务端数据库访问压力的方法和装置。该方法包括：查询服务端数据库中的应用的版本信息并复制到共享内存中；接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求；查询共享内存，判断共享内存中是否有对应的应用的记录，有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用；向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。本发明的技术方案，由于在服务端数据库的前端设置了共享内存，利用共享内存的作用过滤掉其实不需要更新的应用的查询请求，从而实际查询服务端数据库的请求数量都是有效的请求，这大大减小了服务端数据库的访问压力。
【专利说明】一种缓解服务端数据库访问压力的方法和装置
【技术领域】
[0001]本发明属于网络通信【技术领域】，具体涉及一种缓解服务端数据库访问压力的方法和装置。
【背景技术】
[0002]当前，可以在智能终端(如手机、PC、PAD等)上安装各种功能的应用软件(在本申请中也简称为应用)。且各种应用也在不断推出功能更完善更强大的新版本，需要在智能终端上进行升级。
[0003]以手机上安装的手机助手客户端为例，请求量最大的功能是查询升级接口，具体而言:客户端会不定期的把手机中应用名称及其应用版本信息发送到服务器，服务器通过比较版本信息来判断客户端的应用是否需要升级，如果需要就返回若干项相关信息。通常，一台手机中会装几十个到上百个应用不等，对于服务端来说其处理的请求是来自很多部手机上客户端的，当海量客户端一起请求时，服务端需要处理的访问量巨大，其压力可想而知。
[0004]目前，服务端一般使用Redis，它是目前最流行的NoSQL软件，为了简化架构，它使用了单线程的模式，由于一个线程只能使用一个CPU，因此，致使在海量查询请求发送至服务端时，服务端的处理查询请求的压力过大。
[0005]而服务端其实是有多个CPU的，现有技术中，为了提高多CPU服务端的CPU利用率以缓解服务端的压力，增加了多个Redis，每个Redis分别对应一个CPU。但是启动多个Redis实例，无疑增加了系统的复杂性，同时也增加了维护的成本。我们不得不关心多实例之间的数据内容是否一致，同时，多实例方案在解决高效利用CPU的问题时，却极大的浪费了系统的内存资源。
【发明内容】
[0006]鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种缓解服务端数据库访问压力的方法和装置。
[0007]依据本发明的一个方面，提供了一种缓解服务端数据库访问压力的方法，其中，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该方法包括:
[0008]查询服务端数据库中的应用的版本信息并复制到共享内存中；
[0009]接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求；
[0010]查询共享内存，判断共享内存中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用；
[0011]向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
[0012]可选地，该方法进一步包括:
[0013]为复制到共享内存中的每个应用的版本信息设置一个过期时间；[0014]当共享内存中的一个应用的版本信息的过期时间到达时，从共享内存中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存中。
[0015]可选地，
[0016]所述共享内存为Nginx的共享内存；
[0017]所述接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，以及所述查询共享内存包括:启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及查询Nginx的共享内存。
[0018]可选地，该方法还包括:
[0019]利用服务端的多个CPU来操作所述共享内存。
[0020]可选地，所述服务端数据库为单线程Redis。
[0021]根据本发明的另一方面，提供了一种缓解服务端数据库访问压力的装置，其中，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该装置包括:复制单元，共享内存单元、应用更新请求处理单元；
[0022]复制单元，适于查询所述服务端数据库中的应用的版本信息并复制到共享内存单元中；
[0023]共享内存单元，适于保存复制单元查询的应用的版本信息；
[0024]应用更新请求处理单元，适于接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，查询共享内存单元，判断共享内存单元中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用，以及向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
[0025]可选地，所述复制单元，进一步适于为复制到共享内存单元中的每个应用的版本信息设置一个过期时间，当共享内存单元中的一个应用的版本信息的过期时间到达时，从共享内存单元中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存单元中。
[0026]可选地，所述共享内存单元为Nginx的共享内存单元；
[0027]应用更新请求处理单元，适于启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及查询Nginx的共享内存单元。
[0028]可选地，所述共享内存单元为Nginx的共享内存单元；
[0029]应用更新请求处理单元，适于利用服务端的多个CPU来操作所述共享内存单元。
[0030]可选地，所述服务端数据库为单线程Redis。
[0031]根据本发明的这种服务端数据库中保存有应用的版本信息以及应用的更新相关信息，查询服务端数据库中的应用的版本信息并复制到共享内存中，接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，查询共享内存，判断共享内存中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用，向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端的技术方案，由于在服务端数据库的前端设置了共享内存，利用共享内存的作用过滤掉其实不需要更新的应用的查询请求，从而实际查询服务端数据库的请求数量都是有效的请求，这大大减小了服务端数据库的访问压力。
[0032]上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的【具体实施方式】。
【专利附图】
【附图说明】
[0033]通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中:
[0034]图1示出了根据本发明一个实施例的一种缓解服务端数据库访问压力的方法的实施例一的流程图。
[0035]图2示出了根据本发明一个实施例的一种缓解服务端数据库访问压力的装置的结构示意图。
【具体实施方式】
[0036]下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0037]图1示出了根据本发明一个实施例的一种缓解服务端数据库访问压力的方法的实施例一的流程图。参见图1，该实施例提供了一种缓解服务端数据库访问压力的方法，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该方法包括:
[0038]步骤S110、查询服务端数据库中的应用的版本信息并复制到共享内存中。
[0039]步骤S120、接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求。
[0040]步骤S130、查询共享内存，判断共享内存中是否有所述应用更新查询请求所对应的应用的记录，如果有，则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用。
[0041]在该步骤中，如果共享内存中没有上述的应用的记录，则直接跳至步骤S140。在本发明的一个实施例中，还将上述应用的版本信息复制到共享内存中，以方便下一次的查询。
[0042]步骤S140、向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
[0043]图1所述的方法，由于在服务端数据库的前端设置了共享内存，利用共享内存的作用过滤掉其实不需要更新的应用的查询请求，从而实际查询服务端数据库的请求数量都是有效的请求，这大大减小了服务端数据库的访问压力。
[0044]以手机应用更新为例，此时客户端即为手机上的手机助手，接收到海量的客户端的应用更新查询请求之后，先查询共享内存，与共享内存中的应用信息进行比对:如果一个应用的应用版本信息高于或者同于共享内存中的应用信息，则不需要更新，相对应的该应用的更新查询请求被过滤掉；如果一个应用的应用版本信息低于共享内存中的应用信息，则需要更新，相对应的该应用的更新请求被发送至服务端。在实际作业中，实际上需要更新的应用所占比例极小，据此，大部分的应用更新查询请求被共享内存过滤掉，只发送实际需要更新的应用的应用更新请求至服务端。因此，大幅减少了服务端的请求处理量，进而缓解了服务端数据处理的压力。尤其对于单Redis服务端而言，本发明的方法大大缓解了单Redis的访问压力。
[0045]在本发明的一个实施例中，图1所述的方法还包括:为复制到共享内存中的每个应用的版本信息设置一个过期时间；当共享内存中的一个应用的版本信息的过期时间到达时，从共享内存中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存中。
[0046]例如，为一个应用的版本信息设置的过期时间为5分钟，不同应用的版本信息可设置不同的过期时间，也可以所有的应用的版本信息设置相同的过期时间。以此确保，共享内存中各应用的版本信息即时与服务端数据库保持一致更新至最新状态，进一步确保客户端应用更新查询的准确性。
[0047]在本发明的一个实施例中，所述共享内存优选为Nginx的共享内存，Nginx具有占用内存少和并发能力强的特点，可采用多个Nginx进程分别利用多个CPU参与运算，提高步骤S120和步骤S130的运行效率。也即，所述接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，以及所述查询共享内存具体可以为:启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及查询Nginx的共享内存。同时，多个Nginx进程可利用服务端的多个CPU来操作所述共享内存。据此，在本发明的一个实施例中，可以继续沿用单Redis服务端，但是可以利用多个CPU参与运算，打破了现有的服务端数据库访问方法中，单Redis服务端的单进程浪费CPU资源的局限性。
[0048]图2示出了根据本发明一个实施例的一种缓解服务端数据库访问压力的装置的结构示意图。参见图2，该实施例提供了一种缓解服务端数据库访问压力的装置200，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该缓解服务端数据库访问压力的装置200包括:复制单元210，共享内存单元220、应用更新请求处理单元230。
[0049]复制单元210，适于查询所述服务端数据库中的应用的版本信息并复制到共享内存单元220中；
[0050]共享内存单元220，适于保存复制单元210查询的应用的版本信息；
[0051]应用更新请求处理单元230，适于接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，查询共享内存单元220，判断共享内存单元220中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用，以及向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
[0052]在本发明的一个实施例中，复制单元210，进一步适于为复制到共享内存单元中的每个应用的版本信息设置一个过期时间，当共享内存单元220中的一个应用的版本信息的过期时间到达时，从共享内存单元220中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存单元220中。以此确保，共享内存单元220中各应用的版本信息即时与服务端数据库保持一致更新至最新状态，进一步确保客户端应用更新查询的准确性。[0053]在本发明的一个实施例中，所述共享内存单元220可以为Nginx的共享内存单元。此时，应用更新请求处理单元230,适于启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及适于利用服务端的多个CPU来查询Nginx的共享内存单元220。据此，在仍然沿用单Redis服务端时，仍可以利用多个CPU参与运算，打破了现有的服务端数据库访问方法中，单Redis服务端的单进程浪费CPU资源的局限性。
[0054]综上所述，本发明的这种服务端数据库中保存有应用的版本信息以及应用的更新相关信息，查询服务端数据库中的应用的版本信息并复制到共享内存中，接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，查询共享内存，判断共享内存中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用，向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端的技术方案，由于在服务端数据库的前端设置了共享内存，利用共享内存的作用过滤掉其实不需要更新的应用的查询请求，从而实际查询服务端数据库的请求数量都是有效的请求，这大大减小了服务端数据库的访问压力。
[0055]需要说明的是:
[0056]在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
[0057]在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0058]类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循【具体实施方式】的权利要求书由此明确地并入该【具体实施方式】，其中每个权利要求本身都作为本发明的单独实施例。
[0059]本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0060]此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0061 ] 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP )来实现根据本发明实施例的缓解服务端数据库访问压力的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0062] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
【权利要求】
1.一种缓解服务端数据库访问压力的方法，其中，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该方法包括: 查询服务端数据库中的应用的版本信息并复制到共享内存中； 接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求； 查询共享内存，判断共享内存中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用； 向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
2.如权利要求1所述的方法，其中，该方法进一步包括: 为复制到共享内存中的每个应用的版本信息设置一个过期时间； 当共享内存中的一个应用的版本信息的过期时间到达时，从共享内存中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存中。
3.如权利要求1或2所述的方法，其中， 所述共享内存为Nginx的共享内存； 所述接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，以及所述查询共享内存包括:启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及查询Nginx的共享内存。
4.如权利要求1或2所述的 方法，其中，该方法还包括: 利用服务端的多个CPU来操作所述共享内存。
5.如权利要求1或2所述的方法，其中， 所述服务端数据库为单线程Redis。
6.一种缓解服务端数据库访问压力的装置，其中，所述服务端数据库中保存有应用的版本信息以及应用的更新相关信息，该装置包括:复制单元，共享内存单元、应用更新请求处理单元； 复制单元，适于查询所述服务端数据库中的应用的版本信息并复制到共享内存单元中； 共享内存单元，适于保存复制单元查询的应用的版本信息； 应用更新请求处理单元，适于接收来自客户端的包含应用名称和应用的版本信息的应用更新查询请求，查询共享内存单元，判断共享内存单元中是否有所述应用更新查询请求所对应的应用的记录，如果有则通过对比应用的版本信息确定应用更新查询请求所对应的应用是否需要更新，过滤掉不需要更新的应用，以及向服务端数据库查询需要更新的应用的更新相关信息，并返回给客户端。
7.如权利要求6所述的装置，其中， 所述复制单元，进一步适于为复制到共享内存单元中的每个应用的版本信息设置一个过期时间，当共享内存单元中的一个应用的版本信息的过期时间到达时，从共享内存单元中删除该应用的版本信息，并从所述服务端数据库重新查询该应用的版本信息并复制到共享内存单元中。
8.如权利要求6或7所述的装置，其中， 所述共享内存单元为Nginx的共享内存单元；应用更新请求处理单元，适于启动多个Nginx进程来接收来自客户端的应用更新查询请求，以及查询Nginx的共享内存单元。
9.如权利要求6或7所述的装置，其中， 所述共享内存单元为Nginx的共享内存单元； 应用更新请求处理单元，适于利用服务端的多个CPU来操作所述共享内存单元。
10.如权利要求6或7所述的装置，其中， 所述服务端数据库为单线程Redis。
【文档编号】G06F17/30GK103631869SQ201310541236
【公开日】2014年3月12日 申请日期:2013年11月5日 优先权日:2013年11月5日
【发明者】王博, 叶剑峰, 吴凯 申请人:北京奇虎科技有限公司, 奇智软件（北京）有限公司