具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些实施方式使得本发明将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解,并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中,提供许多具体细节从而给出对本发明的实施方式的充分理解。然而,本领域技术人员将意识到,可以实践本发明的技术方案而省略所述特定细节中的一个或更多,或者可以采用其它的方法、组元、系统、步骤等。在其它情况下,不详细示出或描述公知结构、方法、系统、实现、材料或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。
附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器系统和/或微控制器系统中实现这些功能实体。
以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的系统和方法的例子。
图1示意性示出根据本发明示例实施方式的数据处理方法的流程图。
如图1所示,在步骤S10,接收预约请求,根据预约规则判断所述预约请求是否预约成功。
在一些实施例中,所述预约规则可以是按照提交预约请求的时间先后顺序及预约名额来确定当前预约请求是否预约成功,例如哪个用户先预约且此时预约名额未满,则该用户预约成功。
在另一些实施例中,所述预约规则可以设置的更为复杂。例如,预先对用户划分等级,针对不同的用户等级对相应的预约目标的数量进行划分。可以查询用户的历史行为数据,根据历史行为数据对用户进行分类划分,所述历史行为数据例如可以包括:访问页面的地址、下单记录、付款记录、抢购次数、访问某个页面的频率、IP地址、登录习惯等等,恶意用户会具备一些较明显的特征,例如抢购次数多,IP地址更换频繁等特征,这样就可以将恶意用户划分到等级较低的用户中。例如可以将用户由高到低分为A、B、C三个等级,对应的分配预约目标的指定比例为50%、30%、20%,假设预约目标的总量为N,则A等级用户可以预约的数量为50%*N,B等级用户可以预约的数量为30%*N,C等级用户可以预约的数量为20%*N。
目前的电子商务系统中,都有用户行为数据的采集系统和查询接口,本发明可以从该查询接口直接查询需要的用户行为数据。确定与该用户等级对应的预约目标的剩余量,具体包括:预先根据用户等级对预约目标的总量进行分配,每一用户等级对应的预约目标数量占该预约目标总量的指定比例;各个用户等级所占比例的和值等于1,将所述预约请求对应的用户等级对应的预约目标数量减去同用户等级中已经预约成功的预约数量,得到与该用户等级对应的预约目标的剩余量。
类似地,在下述的抢购阶段,也可以根据预约阶段的用户等级划分相应的预约目标的数量。并根据该用户的用户等级对应的预约目标的剩余数量来随机分配该用户是否预约成功。
在步骤S20,在缓存中配置第一队列和第二队列。
其中,所述第一队列可以为未购买商品队列,用于存储预约成功且还未抢购到本次促销的抢购商品的用户的预约信息;所述第二队列可以为已购买商品队列,用于存储已抢购到本次促销的抢购商品的用户的预约信息,且所述未购买商品队列和所述已购买商品队列中的所述预约信息不重复,即某一个用户的预约信息如果存在于所述未购买商品队列中时,则该用户的预约信息就不会存在于所述已购买商品队列中;反之,当某一用户的预约信息如果存在于所述已购买商品队列中时,则该用户的预约信息就不会存在于所述未购买商品队列中。
在示例性实施例中,所述缓存包括redis服务器。当然,本发明并不以此为限,任何采用内存存储形式的缓存均可用于本发明,例如memcached缓存方式。
redis(远程字典服务,Remote Dictionary Service)是一个高性能的key-value键值存储系统。和memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set--有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。与memcached一样,为了保证效率,数据都是缓存在内存中。redis支持不同无序、有序的列表,无序、有序的集合间的交集、并集等高级服务器端原子操作。
redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部分场合可以对关系型数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。
在示例性实施例中,所述缓存采取redis集群形式,包括多个redis服务器。
由于受单个节点所在服务器内存容量限制,在大规模数据缓存/存储场景下,一般由多个节点组成集群,每个节点只负责存储部分数据,称为sharding。集群技术是构建高性能网站架构的重要手段,将redis服务器根据预设规则分布在redis集群中的各个节点,降低单个节点的压力。各个节点通过TCP连接和一个二进制协议建立通信。客户端可访问该redis集群中的节点,以访问对应的redis服务器,查找到对应的数据。客户端根据key和节点的映射关系,将对特定key的请求发送到特定节点。如果使用集群,会使缓存更健壮不容易丢失数据,从而使系统的运行更稳定。在缓存redis集群中配置两个队列,第一队列为未购买商品队列,第二队列为已购买商品队列。在抢购开始前,把预约成功用户的预约信息存储到未购买商品队列。
在示例性实施例中,还包括:在所述redis服务器上配置脚本插件,所述脚本插件用于处理判断逻辑。
利用redis推出了可以编写插件脚本功能,允许开发者使用编写脚本语言上传到缓存redis中进行编译执行。通过缓存redis组件并通过编写该缓存组件的插件,通过lua脚本按照商品抢购业务逻辑编写插件并配置在redis上运行,从而能够达到系统快速响应的目的。一些实施例中,可以利用lua脚本进行插件编写。当然,本发明不以此为限,具体采用何种脚本语言编写缓存的插件,可以根据系统中所采用的缓存类型及该缓存支持的脚本语言类型来决定。
lua动态语言,是一个小巧的脚本语言。其设计目的是为了嵌入应用程序中,从而为应用程序提供灵活的扩展和定制功能。lua由标准C编写而成,几乎在所有操作系统和平台上都可以编译,运行。lua脚本可以很容易的被C/C++代码调用,也可以反过来调用C/C++的函数,这使得lua在应用程序中可以被广泛应用。一个完整的lua解释器不过200k,在目前所有脚本引擎中,lua的速度是最快的。
通过在缓存软件上部署脚本插件,可以减少网络开销。例如原来5次网络请求的操作,如客户端与缓存的交互值判断,可以用1个请求完成,通过脚本插件将原有的取值判断业务逻辑放在redis服务器上完成,减少了交互次数,从而减少了网络往返时延。
在一些实施例中,还可以实现插件脚本复用。例如客户端发送的脚本会永久存储在缓存如redis中,意味着其他业务系统客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。
在一些实施例中,缓存redis会将整个脚本插件作为单线程整体执行,中间不会被其他命令插入,避免原有形式客户端与缓存交互,可能出现多线程并发同时抢占资源问题。让上述整个业务操作过程是原子性地执行。
线程,是程序执行流的最小单元。每一个程序都至少有一个线程,若程序只有一个线程,那就是程序本身。线程是程序中一个单一的顺序控制流程。在单个程序中同时运行多个线程完成不同的工作,称为多线程。单线程在程序执行时,所走的程序路径按照连续顺序排下来,前面的必须处理好,后面的才会执行。
在步骤S30,将预约成功的预约请求中的预约信息存储到所述第一队列中。
其中所述预约信息中可以包括预约成功的用户信息和本次促销的抢购商品信息。所述用户信息例如可以包括用户ID(用户名userId、手机号码、微信号等具有唯一标识作用的字符串、数字、符号等及其组合)、姓名(name)、送货地址、收件人,甚至工作单位信息等。所述抢购商品信息例如可以包括商品编码(goodid)、预约编号(buynum)、金额(money)、商品类别、库存信息等。
在示例性实施例中,还包括:保存预约成功的预约请求中的预约信息到第一数据库中;满足预设时间时,将所述第一数据库中的所述预约信息存储到所述第一队列中。
其中这里判断是否满足预设时间,可以通过预置一定时模块,通过该定时模块判断当前时间离本次促销抢购活动的开始时间距离多久,当离所述抢购活动的开始时间例如还相隔一天或者一周时,将关系型数据库中的预约信息转存到所述第一队列中。当然,本发明不以此为限,所述预设时间可以根据系统需求自主设置。
其中所述第一数据库可以为关系型数据库,这样在抢购活动开始前,便于预约信息的持久化存储。
在步骤S40,接收抢购请求,根据所述第一队列中的预约信息判断发起所述抢购请求的用户是否已经预约成功。
当该发起抢购请求的用户的用户信息存在于所述第一队列中的预约信息中时,则判断该发起抢购请求的用户已经预约成功;当该发起抢购请求的用户的用户信息不存在于所述第一队列中的预约信息中时,则判断该发起抢购请求的用户预约失败。
在步骤S50,当发起所述抢购请求的用户已经预约成功,则判断所述用户是否已经抢购成功。
在一些实施例中,判断该用户是否已经抢购成功可以根据该用户点击下单的时间先后顺序来判断,即在预约成功的用户群中,谁先点击抢购谁就抢购成功。在另一实施例中,对于同时点击的用户可以根据用户等级或者随机抽取的方式来决定谁抢购成功。
在一些实施例中,对于预约成功用户发起的抢购请求,会根据时延条件进行过滤,对恶意用户使用软件频繁地发出的抢购请求会进行有效地过滤,这样可以有效地过滤掉恶意用户发出的抢购请求,降低恶意用户的恶意抢购的成功几率。
在步骤S60,当所述用户抢购成功时,将所述用户对应的所述第一队列中的所述预约信息推送(push)到所述第二队列中。
在示例性实施例中,所述第一队列和/或所述第二队列中的所述预约信息采用json格式。这样便于对预约用户信息结构化处理,如果要取每个属性就按相应的字段+值获取就行。当然,本发明不以此为限,还可以采用其它形式的数据存储格式。
例如,未购买商品队列里是json字符串:
{userId:'789',goodid:'2356214',buynum:'2',money:'300'}
再例如,已购买商品队列里的数据结构类型格式:
HSET userid:100001 name zhangsan
name记录用户id账号的用户名称。
json(JavaScript Object Notation)是一种轻量级的数据交换格式。json采用完全独立于语言的文本格式,但是也使用了类似于C语言家族的习惯(包括C、C++、C#、Java、JavaScript、Perl、Python等)。这些特性使JSON成为理想的数据交换语言。易于人阅读和编写,同时也易于机器解析和生成(一般用于提升网络传输速率)。
在示例性实施例中,所述第二队列中的所述预约信息采用map存储数据结构。
缓存redis集群用一个特定的map数据结构来过滤抢购成功的用户,把抢购成功用户的信息放到已购买商品队列里。
在示例性实施例中,还包括:当发起所述抢购请求的用户没有预约成功;和/或当所述用户抢购失败时,发送提示信息。
抢购商品时,先判断用户是否已经预约成功,如果没预约过或者没有预约成功则直接返回“没有预约不能进行购买!”的提示信息;如果已经预约过且预约成功,则继续判断是否已经购买过,如果已经购买过返回提示信息“您已购买过不得再次购买!”;如果没购买过,则从未购买商品队列中取出对应的抢购商品信息,用户可直接下单进行购买成功,之后再把未购买商品队列中该用户对应的信息push到已购买商品队列中,用来防止同一用户多次抢购。当同一用户再次发起抢购请求时,先在未购买商品队列中进行查询,如果不存在该用户的预约信息则不可以进行后续操作。这样能够防止用户快速点击了多次,或者开了多个浏览器来抢购商品,或者利用其它第三方工具或程序来抢购,可能出现同一用户购买多次本次促销活动的抢购商品的情况。
在示例性实施例中,还包括:将所述第二队列中的所述预约信息转存到一第二数据库中。
其中所述第二数据库例如可为关系型数据库。所述第一数据库和所述第二数据库可以为同一数据库,或者为两个独立的数据库。
在一些实施例中,用一个单线程批量把已购买商品队列里的信息取出来,再批量更新(update)抢购成功的用户信息到关系型数据库里,把抢购成功的用户信息持久化的存储,以方便以后查询操作。
本发明实施方式提供的数据处理方法,基于缓存中的组件redis软件举例说明,并配合自定义脚本语言如编写lua脚本插件来控制对应的系统,并与系统功能相互协作,使系统对于商品抢购能处理大批量用户请求,减少系统的压力,达到良好效果。同时,可以避免同一个账号多次购买。
图2示意性示出根据本发明示例实施方式的数据处理方法中的预约阶段的流程图。
如图2所示,在步骤S11,接收预约用户提交的预约请求。
在步骤S12,判断该预约用户是否预约成功;如果预约成功,则跳转到步骤S14;如果预约失败,则进入步骤S13。
在步骤S13,向该预约请求的预约用户发送预约失败的提示信息,之后跳转到步骤S15。
在步骤S14,保存预约成功的预约请求中的预约信息到第一关系型数据库中。
在步骤S15,判断预约名额是否已满;如果预约名额已满,则进入步骤S16;如果预约名额未满,则跳回到步骤S11继续接收下一个用户的预约请求。
在步骤S16,至此预约阶段结束。
对于所要促销抢购的商品,先进行网上预约,保证在抢购时,只有那些预约成功的用户才有资格进行抢购。系统对于预约成功的用户,把预约信息先存到数据库表中,购买成功状态标志为未购买。
图3示意性示出根据本发明示例实施方式的数据处理方法中的抢购前期准备阶段的流程图。
如图3所示,在步骤S21,在redis服务器上配置lua脚本插件。
在步骤S22,在redis服务器中配置第一队列和第二队列。
在步骤S23,判断离抢购开始的预设时间到达;如果是,则进入步骤S24;反之,继续判断离抢购开始的预设时间是否达到。
在步骤S24,将第一关系型数据库中的预约信息存储到第一队列中。
图4示意性示出根据本发明示例实施方式的数据处理方法中的抢购阶段的流程图。
如图4所示,在步骤S41,判断抢购活动是否开始;如果已经开始,则进入下一步;反之,继续判断抢购活动是否开始。
在步骤S42,接收用户发起的抢购请求。
在步骤S43,判断该用户是否预约成功。如果预约成功,则跳转到步骤S45;反之,进入步骤S44。
在步骤S44,向该抢购请求的用户发送预约失败的提示信息,然后跳转到步骤S48。
在步骤S45,判断该用户是否抢购成功。如果抢购成功,则跳转到步骤S47;反之,进入步骤S46。
在步骤S46,向该抢购请求的用户发送抢购失败的提示信息,然后跳转到步骤S48。
在步骤S47,将该用户对应的第一队列中的预约信息推送到第二队列中.
在步骤S48,判断抢购名额已满。如果抢购名额已满,则进入步骤S49;反之,跳回到步骤S42继续接收下一个用户发起的抢购请求。
在步骤S49,抢购阶段结束。
图5示意性示出根据本发明示例实施方式的数据处理系统的框图。
如图5所示,该数据处理系统10包括:预约模块11、缓存配置模块12、存储模块13、抢购模块14、判断模块15以及推送模块16。
其中所述预约模块11用于接收预约请求,根据预约规则判断所述预约请求是否预约成功。
所述缓存配置模块12用于在缓存中配置第一队列和第二队列。
所述存储模块13用于将预约成功的预约请求中的预约信息存储到所述第一队列中。
所述抢购模块14用于接收抢购请求,根据所述第一队列中的预约信息判断发起所述抢购请求的用户是否已经预约成功。
所述判断模块15用于当发起所述抢购请求的用户已经预约成功,则判断所述用户是否已经抢购成功。
所述推送模块16用于当所述用户抢购成功时,将所述用户对应的所述第一队列中的所述预约信息推送到所述第二队列中。
在示例性实施例中,该系统10还包括:保存模块,用于保存预约成功的预约请求中的预约信息到第一数据库中;调用模块,用于满足预设时间时,调用所述存储模块将所述第一数据库中的所述预约信息存储到所述第一队列中。
在示例性实施例中,所述缓存包括redis服务器。
在示例性实施例中,所述缓存采取redis集群形式,包括多个redis服务器。
在示例性实施例中,该系统10还包括:插件配置模块,用于在所述redis服务器上配置脚本插件,所述脚本插件用于处理判断逻辑。
在示例性实施例中,该系统10还包括:持久化模块,用于将所述第二队列中的所述预约信息转存到一第二数据库中。
本发明实施例中的模块对应上述方法实施例中的内容,在此不再详述。
本发明实施方式还提供一种商品信息抢购系统,包括应用前端、负载均衡服务器、应用服务器、redis集群、以及关系型数据库。
其中所述应用前端用于显示相关界面以及预约、抢购操作,可以包括:商品信息发布页面,主要用来在网站发布抢购商品信息;预约页面,用来填写预约信息,记录预约成功的用户信息;商品抢购页面,用于用户查询抢购成功用户的购买信息;通讯模块,用来配置缓存与该商品信息抢购系统的通讯功能。
例如,用户可以通过应用前端进入预约页面或者商品抢购页面,通过商品抢购页面可进行抢购操作。商品抢购页面可包括抢购商品区域,在该抢购商品区域中可显示当前的抢购商品信息。
负载均衡服务器用于分发抢购操作的请求。负载均衡服务器可以采用NGINX服务器,但是不限于此,也可以采用任何其他负载均衡服务器。由于作为web请求的负载均衡服务器对于本领域技术人员是已知的,所以在此不再进行详细描述。
应用服务器用于直接从redis集群读取数据以及将信息直接存储到redis集群。
例如,当应用服务器接收到负载均衡服务器分发的抢购操作的请求时,其可以直接读取redis集群以获得预约成功和/或抢购成功的用户信息和/或抢购商品信息。
应用服务器将抢购操作的请求中所包括的用户信息与从redis集群获取的用户信息进行比较以确定用户是否预约成功、抢购成功。
应用服务器对于其他业务数据也可以直接读写关系型数据库。例如,当应用服务器要获得历年汇总数据、个人累积数据等时,应用服务器可以直接从关系型数据库中查询统计得出。
在一些实施例中,该商品信息抢购系统还可以包括查询页面,用于用户查询其预约状态和/或抢购状态。例如,用户访问前台的商品抢购页面,前台页面会异步请求查询商品抢购状态或者主动请求查询商品抢购状态,此时后台接收查询抢购状态的请求。
所述后台是指后台服务器或服务器集群,所述前台通常是指与用户交互端,具体可以通过专门的客户端(Client)实现,也可以通过网络浏览器(Browser)来访问服务器的方式实现,即可以采用浏览器/服务器(B/S)结构,也可以采用客户端/服务器(C/S)结构,但是在网络信息飞速发展的年代,系统架构可能还会发展和变化,但不论是什么架构,本发明的核心思想和核心的功能模块是相同的,只是执行具体功能的模块的所处位置不同而已。
本发明实施方式还提供了一种电子设备,包括:处理器;用于存储处理器可执行指令的存储器;其中,所述处理器被配置为:接收预约请求,根据预约规则判断所述预约请求是否预约成功;在缓存中配置第一队列和第二队列;将预约成功的预约请求中的预约信息存储到所述第一队列中;接收抢购请求,根据所述第一队列中的预约信息判断发起所述抢购请求的用户是否已经预约成功;当发起所述抢购请求的用户已经预约成功,则判断所述用户是否已经抢购成功;当所述用户抢购成功时,将所述用户对应的所述第一队列中的所述预约信息推送到所述第二队列中。
所述电子设备可以是计算机系统或者服务器,以通用计算设备的形式表现。计算机系统/服务器的组件可以包括但不限于:一个或者多个处理器或者处理单元,系统存储器,连接不同系统组件(包括系统存储器和处理单元)的总线。
总线表示几类总线结构中的一种或多种,包括存储器总线或者存储器控制器,外围总线,图形加速端口,处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说,这些体系结构包括但不限于工业标准体系结构(ISA)总线,微通道体系结构(MAC)总线,增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。
计算机系统/服务器典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机系统/服务器访问的可用介质,包括易失性和非易失性介质,可移动的和不可移动的介质。
系统存储器可以包括易失性存储器形式的计算机系统可读介质,例如随机存取存储器(RAM)和/或高速缓存存储器。计算机系统/服务器可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例,存储系统可以用于读写不可移动的、非易失性磁介质(通常称为“硬盘驱动器”)。可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器,以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下,每个驱动器可以通过一个或者多个数据介质接口与总线相连。存储器可以包括至少一个程序产品,该程序产品具有一组(例如至少一个)程序模块,这些程序模块被配置以执行本发明各实施例的功能。
具有一组(至少一个)程序模块的程序/实用工具,可以存储在例如存储器中,这样的程序模块包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块通常执行本发明所描述的实施例中的功能和/或方法。
计算机系统/服务器也可以与一个或多个外部设备(例如键盘、指向设备、显示器等)通信,还可与一个或者多个使得用户能与该计算机系统/服务器交互的设备通信,和/或与使得该计算机系统/服务器能与一个或多个其它计算设备进行通信的任何设备(例如网卡,调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口进行。并且,计算机系统/服务器还可以通过网络适配器与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图所示,网络适配器通过总线与计算机系统/服务器的其它模块通信。应当明白,尽管图中未示出,可以结合计算机系统/服务器使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
图1、2、3和4示出根据本发明示例实施方式的数据处理方法的流程图。该方法可例如利用如图5所示的数据处理系统实现,但本发明不限于此。需要注意的是,图1、2、3和仅是根据本发明示例实施方式的方法所包括的处理的示意性说明,而不是限制目的。易于理解,图1、2、3和所示的处理并不表明或限制这些处理的时间顺序。另外,也易于理解,这些处理可以是例如在多个模块/进程/线程中同步或异步执行的。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本发明实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。
本发明实施方式公开的数据处理方法及其系统,利用缓存组件如redis和脚本语言如lua脚本相结合,处理在抢购商品时的高并发业务,可以减少系统压力。同时控制同一个账号购买多次的行为,将使系统交互更加友好,用户体验效果更好,系统更加健壮。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求指出。
以上具体地示出和描述了本发明的示例性实施方式。应可理解的是,本发明不限于这里描述的详细结构、设置方式或实现方法;相反,本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。