用于保持旨在与大型数据库对接的多层软件系统中的缓存内容的一致性的系统和方法

摘要

本发明涉及用于保持旨在与大型数据库对接的多层软件系统中的缓存内容的一致性的系统和方法。描述了一种用于保持服务器的多层架构中的缓存内容的一致性的方法和系统。该架构包括：卫星服务器组成的前端层，每个卫星服务器都操作一个本地缓存；和中心服务器组成的中间层，每个中心服务器都操作一个中心缓存执。中心服务器通过数据库服务器与数据库对接以检索用于构造对象的数据元素并且将其存储在中心缓存中。一旦构造了对象，对象就被赋予生存时间(TTL)并且被存储在中心缓存中，然后被转发到卫星服务器，在卫星服务器中，在被递送到请求这些对象的软件应用之前，这些对象被存储在本地缓存中。当对象过期时，使这些对象无效并从中心服务器重建这些对象，从中心服务器将这些对象转发到所有中心缓存以及需要这些对象的本地缓存。

说明书

技术领域

本发明一般涉及多层客户机/服务器软件架构，更具体地说，涉及一种保持前端层机器和中间层机器中实现的缓存内容之间的一致性以提高总体性能的方法和系统。

背景技术

20世纪80年代后期出现的客户机/服务器模型是一种通用的模块化软件架构，与作为当时标准的集中式分时计算的大型机相比，该架构想要改进可用性、灵活性、互操作性以及可扩展性。客户机是服务的请求方，而服务器则是这种服务的提供方。根据软件配置，同一台机器可以同时是客户机和服务器。

客户机/服务器架构已经逐步取代了先前的大型机软件架构，在先前的大型机软件架构中，所有智能全都位于中心主机计算机内，并且用户通过只能捕获键击和向主机发送信息的无智能终端来与主机进行交互。大型机软件架构的众所周知的限制是：它们不易于支持图形用户界面(GUI)或者从地理上分散的地点访问多个数据库。但是，在分布式客户机/服务器架构中，大型机仍被用作功能强大的服务器。

客户机/服务器架构引入了充当文件服务器的数据库服务器。在该架构中，使用关系型数据库管理系统或RDBMS来直接应答用户查询。通过提供查询响应而不是始终传送完整文件，从而减少了网络通信量。此外，该架构还改进了通过GUI前端对共享数据库进行的多用户更新。在客户机/服务器架构中，通常使用结构化查询语言(SQL)语句在客户机与服务器之间交换数据。

对于图1所示的双层客户机/服务器架构(100)来说，用户系统接口位于用户的台式机(102)环境中，而数据库管理服务则位于能为许多客户机提供服务的服务器(104)中。在用户系统接口环境与数据库管理服务器环境之间，处理管理被划分。对于往往位于局域网或LAN(108)上的包括与单个/多个服务器(未显示)对接的单个/多个客户机的拓扑结构来说，这些拓扑的所有组合都是明显可行的。

在传统的双层架构中，第一层即客户机(102)具有用户接口、主要业务以及数据处理逻辑。它接受并且检查用户输入的句法，处理应用逻辑，产生数据库请求，将这些请求发送到服务器，以及将响应传回给用户任务。第二层即数据库服务器(104)接受并处理来自客户机的数据库请求，检查授权，确保未违反完整性约束，执行查询/更新处理，以及向客户机发送响应。此外，第二层还维护系统目录，提供并发数据库访问，并且执行恢复控制。

已经证实，当工作组中同时在LAN上交互的人不超过100个时，双层客户机/服务器架构是一种良好的分布式计算解决方案。但是，由于服务器即使在无工作要做时也会借助“保活(keep-alive)”消息而与每个客户机保持连接，因此，当用户数量增加时，性能开始降低。双层架构的第二个限制是：使用卖方独有的数据库过程来实现处理管理服务限制了针对应用的RDBMS选择和灵活性。此外，在将程序功能从一台服务器移动(重新分配)到另一台服务器时，双层架构的实现表现出有限的灵活性。

随后，在90年代出现了三层架构(120)和多层变体，用以克服上述限制。在三层架构中，在用户系统接口客户机环境(122)与数据库管理服务器环境(124)之间添加了一个中间层(126)。虽然存在用于实现这种架构以及中间层的多种方式，但是后者往往负责排队、应用执行以及数据库分级(database staging)。通常，由于中间层应该访问数据并且向客户机返回应答，因此，客户机将其请求递送到中间层然后脱离。此外，中间层还会为进行中的工作添加调度和优先区分。

在三层架构的上述变体中，客户机即第一层可以仅实现用户接口，也就是验证输入；在这种情况下，中间层具有所有业务逻辑并且执行数据处理，而服务器即第三层则执行数据验证并且控制数据库访问。

三层客户机/服务器架构已经显示出改进了具有大量用户(通常多达一千个，即双层架构的10倍)的组的性能，并且尤其与双层方法相比，由于不必在层间共享应用代码，因此这种架构还提高了灵活性。三层客户机/服务器架构导致了如下的环境，与具有直接的客户机到服务器连接的双层架构相比，该环境的可扩展性明显更大。它提供了在单个事务中更新多个不同的RDBMS的能力，并且可以与包括平面文件、非关系型数据库管理系统的各种数据源相连，此外，它还可以与现在常用作功能强大的数据库服务器的大型机相连。由此，三层和多层架构最适合大型分布式客户机/服务器环境。举个例子，机票预订公司必须部署以为其顾客提供服务的环境，即全世界的旅行社，其中需要诸如异构数据库(也就是航空运输费用和可用性数据库)的共享资源以及处理规则。

如果多层数据中心成为提供此类服务的主要需求，那么要想进一步提高性能及可扩展性的话，降低计算和通信开销是至关重要的。在多层数据中心的不同层中缓存动态内容是一种用于减少计算和通信开销的公知方法，由此，由于在命中时不必从上位层中再次提取数据，因此可以为甚至更多的顾客同时提供服务。但是，对在中间层和前端层中进行缓存来说，其自身是存在问题的。因此，缓存相容性和缓存一致性成为必须处理的问题。尤其对于无法接受过时航线可用性值的机票预订来说，强的相容性和一致性是必不可少的。

发明内容

因此，本发明的宽泛目的是提供一种用于保持多层软件架构中的动态缓存内容的一致性的方法和系统。

本发明的一个更具体的目的是本发明必须适合多层架构，例如为机票预订系统而部署的架构，并且该架构的特征在于：来自客户机侧的非常高等级的事务，以及由航空公司和其它此类服务供应方提供的费用和可用性数据库的频繁更新。

对本领域技术人员来说，通过参考附图来详读后面的描述，可以清楚了解本发明的其它目的、特征和优点。任何附加的优点都应被包括在本文中。

描述了一种用于保持多层软件架构中的缓存内容的一致性的方法和系统。该架构包括：卫星服务器组成的前端层，每个卫星服务器都操作一个本地缓存；和中心服务器组成的中间层，每个中心服务器都操作一个中心缓存。中心服务器通过数据库服务器与数据库对接以检索用于构造对象的数据元素。一旦构造了对象，对象就被赋予生存时间(TTL)并且被存储在中心缓存中，然后被转发到卫星服务器，在卫星服务器中，在被递送到已经请求这些对象的软件应用之前，这些对象被存储在本地缓存中。在所有可用的中心服务器上对来自卫星服务器的请求进行负载平衡。对于每个请求，选择一个中心服务器进行处理。新构造的对象从所选择的中心服务器被复制到所有其它中心服务器中。每当对象在本地缓存中不找到或过期时，则从所选择的中心缓存请求该对象。每当被请求对象在所选择的中心缓存中不找到时，在所选择的中心服务器中触发被请求对象的构造处理。如果被请求对象已经存在于中心缓存中并且没有过期，则跳过构造处理。一个中心服务器被指定为主中心服务器，并且所有其它中心服务器是备份中心服务器。每当发现被请求对象过期时，由无效处理机在主中心服务器中触发构造处理。在将所发现的过期对象的TTL转发给发起请求的卫星服务器之前，该过期对象的TTL被设置成一个低值。在数据库中用于构造所述对象的至少一个所述数据元素一经修改，就使存储在中心缓存和本地缓存中的对象无效，然后确定哪些对象受到影响，向所有中心服务器的无效处理机广播无效命令。这些无效处理机使中心缓存中的相应对象无效，然后将无效命令传播到所有本地缓存，本地缓存继而无效并删除本地缓存中的相应对象。中心缓存中的被无效对象被删除或被重建。在后一种情况下，重建的对象被复制到所有备份中心缓存中。

附图说明

图1论述了现有技术，即二层与多层软件架构的对比。

图2显示了最适合应用本发明的总体的多层软件架构。

图3描述了由应用程序处理终端用户请求而导致的对象提取的各种情况以及中心服务器中的对象构造处理。

图4论述了本地和中心缓存中的对象的时效。

图5描述了在数据库中修改了数据元素时缓存中的对象的无效处理。

图6论述了被无效对象的重建处理。

图7描述了在辅助存储器中存储必须从中心缓存中移除的未过期对象的处理。

具体实施方式

本发明的以下详细描述是参考附图进行的。虽然描述包含了示例性实施例，但是其它实施例也是可行的，并且在没有脱离本发明的精神和范围的情况下，可对这些实施例是进行改变。

图2描述了最适合应用本发明的总体的多层软件架构。

上层(200)是最终数据源，其中通常至少一个数据库服务器(202)与多个数据库(204)对接，例如由来自世界各地的旅行承运商或此类服务的其它提供商提供的可用性和费用数据库。这些数据库被其用户(也就是负责更新和维护其内容的用户)(206)频繁更新，这些更新往往是通过包括因特网的专用网络和公用网络(208)的组合进行的。总的来说，每天都会记录数以百万计的事务，这涉及大量的数据。

在这里，中间层(210)被示出为包含两个服务器，在下文中将这些服务器称为中心数据服务器或CDS。通常，出于冗余的考虑，存在一个主服务器(212)和一个备份服务器(214)。但是，在一个(无冗余)与多个服务器之间的任何配置都是可行的。此外，例如为了便于系统维护，或者由于指定的主CDS发生故障，中心服务器有时候必须被配置成独立服务器。另外，在必要时，指定的备份服务器必须暂时作为主服务器运转。在本发明的后面的描述中会对此进行进一步论述。

对该架构来说，在中间层中具有多个服务器是常用实践。可能有与主服务器起相同作用的一个以上的冗余服务器，或者运行不同应用程序的专用服务器。当需要更大的处理能力时，一种实现可扩展性的方式包括添加中间服务器，从而可以通过在更多的中间层服务器上对前端层(220)的请求进行负载平衡来处理更多的客户机事务。因此，每个CDS都具有其自己的缓存(216，218)，这些缓存被称为中心缓存，它们必须始终保持相干的内容。

在本发明所考虑的应用类型中，在下文中将存在于缓存中的数据实体宽泛地称为软件对象或者简称为对象。一般来说，通过查询而从数据库获取的许多数据元素需要被放置在一起，以创建这些数据元素。因此，举例来说，根据本发明的对象是曾由CDS从数据元素中构造的特定旅费，所述数据元素是通过数据库服务器(202)而从数据库(204)获取的。如果如背景技术部分所述，数据库是关系型数据库，那么该处理可以通过以下方式实现：向数据库发出至少一个(通常是许多个)SQL请求，从而能够在CDS中收集到构造对象(例如，在该具体示例中为旅费)所需的所有数据元素。由此，根据本发明的对象被假定为需要处理能力并且使用与数据服务器的通信带宽而被置于可用形式的详细对象。只要在数据库中尚未修改用于构造对象的源信息，这些对象就可以保持在缓存中。对于重建来说，由于重建耗费了处理能力并且使用了与数据库服务器及其数据库的部分可用通信带宽，因此重建是昂贵的。就一致性而言，例如存在于主CDS(216)的中心缓存中的特定对象必须与其在备份CDS中心缓存(218)中的克隆体完全相同，并且其内容必须与构造了这些内容的数据库(204)的数据元素相容。在本发明的后面的描述中将会对此进行进一步的论述。

前端层(220)是由多个卫星服务器构成，卫星服务器运行用于其终端用户的软件应用。在用于说明本发明的该示例中，这些软件应用通常是定价或费用搜索引擎。这些软件应用可以直接在卫星客户机服务器(222)上运行，或者在包含服务器群(225)的独立的前端层卫星服务器(224)上运行，而前端层卫星服务器(224)继而由远程用户(226)使用标准浏览器以及因特网上最广泛的应用(万维网或web)通过例如因特网的专用或公用网络(228)来进行访问。在这两种情况下，所述应用实质上都利用本地缓存(230)来减少前端层与连接到所有卫星服务器的中间层的CDS之间的通信开销。由此，在必要时，上述对象也会被引入不同的本地缓存。因此，如果被请求对象实际处于其本地缓存中，那么本地应用就不必访问CDS或数据服务器。这样做的主要优点是保护数据库服务器(202)，即，防止这些服务器接收到来自终端用户(226)的、不这样做的话就会到达这些服务器的无数请求。

由于软件应用是以实现良好的缓存命中率(hit ratio)为目标而进行设计的，因此可以发现它们的性能得到了显著提高。此外，这显著减少了层间的通信开销，并且最终允许在同一基础架构上接纳更多的终端用户。如上面已论述的，所有这些都假设保持缓存一致性，这一点会在后面的附图中进行进一步论述。

图3描述了由应用程序处理终端用户请求而导致的对象提取的各种情况。

当例如定价程序(300)的位于前端层服务器中的应用程序需要对象(305)来计算旅行价格时，首先询问本地缓存(310)。如果命中，则简单地从本地缓存中取回对象(315)。由于整个处理只涉及运行该应用的服务器，因此，这是取回对象的最有效的方式。

但是，当在本地缓存中不存在被请求对象时，即未找到(320)。这时必须引入对象，这里首先假设对象存在于主CDS(340)的中心缓存中，通过在下文中进一步描述的负载平衡功能向主CDS(340)发出请求(390)。如果确实是这种情况(345)，那么数据处理机功能(350)的目标是从中心缓存中取回该对象，并且将其转发(330)到请求服务器的本地缓存，在那里所述对象被存储。在这样做之后，被请求对象最终可被递送到应用程序。因此，本地缓存又多包含了一个可能用于进一步的请求的对象(325)。

当被请求对象既不存在于本地缓存(350)也不存在于主CDS的中心缓存(355)时，必须在CDS中构造该对象并且将其存储在中心缓存中。这是通过已提及的数据处理机(350)实现的，该处理机必须从数据库(365)收集构造被请求对象(355)所需的所有数据元素(360)。构造该对象可能是一个复杂的处理，该处理可能需要向数据库发出很多请求(例如SQL查询)。一旦将其置于一起，则执行彻底的检查以确保它确实可供发起请求的应用使用。这包括对象描述语言的句法和语法检查以及利用应用采样代码的测试。如果新对象如正常时那样通过了该验证阶段，则将其存储在中心缓存中。在存储之前，将生存时间(TTL)或者届满日期附于对象，从而，当对象如图4中进一步论述的那样过期时可以移除该对象。一旦执行了该处理，那么新对象就被转发到已经请求该对象的服务器的本地缓存，该对象首先被存储在所述本地缓存中，然后被递送(375)到需要该对象的软件应用。但是，如果新构造的对象的验证失败，那么该对象将被拒绝，由此不会将其存储在中心缓存或转发给本地缓存(357)。

当在主CDS中创建了新对象时，还在备份服务器(342)中复制(380)该对象，从而也可以从其它中心服务器缓存取回这个新对象。如上所述，为了提供冗余和可扩展性，多个中间层服务器可以同时活动，以使来自前端层服务器的请求在这组可用中心数据服务器上是负载平衡的。对在图3中描绘的负载平衡来说，提及了存在负载平衡功能(385)，该功能根据与众所周知的循环复用(round-robin)功能同样简单的特定逻辑或算法来分派前端层请求(390)，除此之外，不会进一步讨论负载平衡功能，这超出了本发明的范围。在这种情况下，输入的前端层请求被按顺序接连发送到每个活动的中心服务器，直至到达最后一个为止。然后，下一个请求被再次发送到编号为第一个的中心服务器，以此类推。这种简单的算法通常是非常有效的。但是，存在某些更为复杂的算法，比如如下的算法：测量每个服务器的实际负载并且设法向最不忙的服务器发送输入请求。

因此，提及向主CDS缓存请求未找到对象的先前描述必须加以修正。根据负载平衡功能(385)作出的决定，由于在活动服务器中复制(380)了新构造的对象，因此也可以向备份中心缓存请求未找到对象。在这种情况下，如果在所选择的备份中心缓存中不存在该对象，则必须像选择了主CDS那样如上所述地构造该对象。当出现这种情况时，备份CDS暂时作为主CDS运转，这意味着一旦构造了对象，那么该对象将被从该备份CDS复制到所有活动CDS，以使得在所有的中间层中心缓存中都可得到新对象。在图6中也论述了本发明的此方面，其中备份CDS可以暂时充当主CDS。

图4论述了缓存中的对象的时效。如上所述，所有构造的对象都具有附于其的规定生存时间(TTL)或届满日期，从而可以从缓存中移除过期的元素，并且这些元素不会永远保持在存储器中。

当软件应用(400)在本地缓存中提取到过期对象(405)时，该对象将被移除，并且因此不会将其返回给发起请求的应用。这会触发对中间层CDS(由负载平衡功能选择的中间层CDS，未示出，如图3所述)的询问。如果该对象存在于中心缓存中(445)并且没有过期，那么如先前所述，数据处理机(450)将其转发到调用应用的本地缓存，在本地缓存中该对象被存储(425)，并且将从所述本地缓存将该对象递送(435)到发起请求的应用。这样就结束了替换本地缓存中的过期对象的处理。如果在中心缓存中很容易就可以得到被请求对象的新拷贝，那么这很可能是由以下事实导致的：使用另一个本地缓存的另一个应用已经需要相同的对象，由此先前在CDS中已经重建了该对象。

但是，如果情况并非如此，也就是说，如果被请求对象在中心缓存中也过期了(455)，那么必须重建该对象。如图3所述，该处理是由数据处理机从数据库(465)执行的，该数据处理机还通过无效处理机(460)功能来请求使过期对象无效(470)。由此，在中心缓存中，过期对象最终被新构造的对象替换(475)，并且如图3所示，该新构造的对象在所有中间层CDS中被复制。在这里注意到以下一点很重要：如果向其已经请求过期对象(455)的CDS不是主CDS，而是备份CDS，那么作为图3中提到的负载平衡功能进行的选择的结果，重建实际上并不是由备份数据处理机执行的。更确切的说，对象无效请求被转发(480)到主CDS无效处理机，从而是主CDS执行了重建处理并且在所有备份CDS中复制了重建的对象，由此最终更新了包括接收到原始请求的中间层CDS的所有中间层CDS。

由于重建可能是一个冗长的过程，因此，原来请求的对象随已经过期(455)但仍被递送到发起请求的本地缓存(485)，从而使发起请求的应用(400)不被阻塞。但是在递送之前，对象的TTL将被设置成非常低的值。由此，如上所述，在重建正在进行时，对象仍旧可以用于当前请求。因此，在短的TTL届满之后接收到的其它请求将使用新的重建的对象。该操作方式与本发明考虑的应用的类型相兼容，其中，机票费用是定期更新的，但是更新时间是灵活的，这是因为在大型网络上部署一组新的机票费用无论如何都要花费很多时间。

图5描述了在数据库(500)中修改了数据元素时缓存中对象的无效处理。每当数据库被其用户(505)(也就是负责更新和管理其内容的用户)更新时就发生该处理。数据库服务器能够检测哪些用于构造对象的数据元素发生了变化。然后，确定受影响的对象的集合，以便使这些对象无效，并且可能在中心缓存中重建这些对象。为此，数据库向所有CDS(也就是主CDS和备份CDS)广播(510)对象无效命令，在这些CDS中，所有受影响的对象被无效(515，525)。

在主CDS(520)上，无效处理机(530)首先必须判定应该删除还是重建无效对象。实际上，仍旧存在于中心缓存中的对象未必需要重建。举例来说，如果长时间没有使用或者很少使用该对象，或者所述对象被频繁无效，那么无效处理机可以简单地判定删除该对象，从而不会无用地占用缓存存储器，并且节省了重建所需的处理能力和通信带宽。该判定是根据预定义的设置而作出的。无效处理机的行为是由CDS管理员定义和设置的。

然后，如果作出了删除对象的判定，则释放相应的缓存存储器空间。但是，如果无效处理机判定必须重建该对象，那么以与如图3所述的方式相似的方式从数据库完成该处理。一旦得以重建(535)，那么该对象在所有CDS中被复制(540)，从而可以使其同步，并且可以从所有中心缓存(545)中得到新拷贝。

无论执行的是对象删除还是对象重建，主CDS无效处理机都将对象无效传播到所有卫星(550)，以防止前端层服务器的软件应用(555)使用过时对象(560)。当软件应用再次需要被无效对象并且因此在本地缓存中无法得到该对象时，将会如图3所述地从CDS中提取对象并且可能重建该对象。

此外，当完成了对象删除或重建时，从主CDS向备份CDS通知(570)所述无效。如下一幅图所述，该处理是通过管理无效处理机使用的进展表而完成的。

图6进一步论述了被无效对象的重建。

当如图5所示必须执行被无效对象的重建时，在CDS中将会存在进展表(600)，该表在接收到对象无效请求时被更新。对进行中的操作、也就是被无效对象的重建(605)来说，该操作被记录在主CDS的表(610)中并且也被转发到备份进展表(625)。此外，被无效的当前对象的TTL或届满日期被变为一个低值，从而如先前所述，该对象在新对象正在被重建时仍然可用。

如果该操作正常完成，那么对象会被正常重建并通过所有验证和检查(640)。在这种情况下，如先前所述，该对象被转发(615)到备份CDS，从而在所有中心缓存中都可得到该对象。同时，进行中的操作的记录被从主进展表中擦除，并且也从接收到重建对象(615)的备份CDS(620)的进展表中擦除。

但是，这些操作未必会在没有长期影响CDS的良好操作的情况下正常结束。

要考虑的第一种情况是如下的情况：例如因为没有从数据库正确传送所有必要的数据元素而没有完整重建主CDS中的对象(630)。必须重新尝试重建操作，该操作的开端将被记录在进展表(500)中。由此，未决操作将会被监视和定性检查进展表的清道夫进程(635)检测到。对于进展表中记录的未决操作，无效处理机尝试进行的重试次数明显是有限制的。在正常情况下，其中的一次重试成功，并且操作如上所述正常地继续进行。

要考虑的第二种情况是没有将刚重建对象(610)正常地传送到任意数量的备份CDS。这是以与在主CDS中的方式相似的方式检测到的，因为备份CDS也都具有进展表(620)。因此，备份清道夫进程检测由于从数据库广播的对象无效而被记录的未决操作。期望主CDS重建被无效对象的备份CDS通常不会承担任何对象重建。但是，当清道夫进程报告了问题时，这可以由备份无效处理机(650)例外地触发。在遇到这种情况时，备份无效处理机最终为其自身的缓存重建(655)被无效对象，暂时作为主CDS运转。这需要从数据库重新传送必要的数据元素(传送到备份CDS)。此后，进展表的未决项可被移除，并且受影响的备份CDS的操作可以正常地继续进行。

图7简要描述了本发明的可选特征。

由于缓存是由其所处于的中心服务器的可用活动存储器构造的，因此该缓存的大小必然是有限的。因此，缓存可能变满：没有剩余足够的存储器用以构造新的被请求对象。于是，针对缓存的标准实践是移除最近最少使用(LRU)的对象，以为新对象腾出空间。其它替换算法也可以应用。无论使用哪种算法，近来未使用的选择要移除的对象可能仍然是有效对象，也就是说，该对象并未过期。如已经指出的，根据本发明的对象是需要用服务器中央处理器(CPU)的极大处理能力来构造并且还需要多次访问后台数据库(700)的复杂对象。因此，对象重建是昂贵的，如果对象在从缓存中移除时没有过期，那么应该避免丢弃该对象。

在主CDS(720)或任一备份CDS(730)中的中心缓存已满(760)，并且例如要移除的LRU对象已被选择(770)的时候，如果该对象没有过期(792)，那么可以将该对象存储(775)到易于从服务器访问的辅助存储器(740，750)中，而不是将其丢弃(780)。但是，如果对象过期(794)，则必须丢弃该对象。辅助存储器通常是来自附于服务器的硬盘的专用存储空间。因此，可以避免未过期对象的重建。为了这样做，CDS追踪存储在辅助存储器中的对象。当应用再次需要其中的一个对象时，从相应的辅助存储器中取回该对象，而不是重建该对象。如果搜索不成功，或者如果该对象由于被存储在辅助存储器中而过期，那么相同的机制也适用，也就是说，LRU对象被从缓存中移除以便为被请求对象腾出空间，在重建该被请求对象之前首先在辅助存储器中进行搜索。