CN110750353A

CN110750353A - 号码发放方法、装置、号码发放系统和计算机程序介质

Info

Publication number: CN110750353A
Application number: CN201810821292.3A
Authority: CN
Inventors: 姚晓魁; 朱秀明
Original assignee: Tencent Technology Beijing Co Ltd
Current assignee: Tencent Technology Beijing Co Ltd
Priority date: 2018-07-24
Filing date: 2018-07-24
Publication date: 2020-02-04

Abstract

本公开提供了一种号码发放方法、装置、号码发放系统和计算机程序介质。该方法包括：接收用户的号码发放的请求；为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码；由分配的进程从负责发放的号段中选取一个号码发放给用户。本公开实施例提高了号码发放信息的安全性，且发放效率高。

Description

号码发放方法、装置、号码发放系统和计算机程序介质

技术领域

本公开涉及互联网领域，具体涉及一种号码发放方法、装置、号码发放系统和计算机程序介质。

背景技术

用户在使用一个新应用之前，要在该应用上注册，填写自己的个人信息，然后应用为其分配一个应用号码。注册后，用户在登录时，就可以填写该应用号码进行登录。

目前为用户分配应用号码主要有两种分配机制。第一种分配机制是按顺序分配应用号码，例如先分配00000001，再递增分配00000002。这种分配机制的弱点是根据应用号码很容易获知应用的注册用户量，而且依赖于一个基准号码，无法多个进程同时发放，因此发放效率不高。第二种分配机制是提前生成要发放的号码。用户注册时将提取生成的号码放出，例如随机从生成的号码中抽取。这种分配方式不容易获知应用的注册用户量，而且可以多个进程同时取号码发放，但是需要一个表存储所有还没有用到的号码，并且服务的每个进程同时获取表的时候需要加锁，影响发放号码的并发性，造成发放效率也不高。

发明内容

本公开实施例提出一种号码发放方案，能够提高号码发放信息的安全性，且发放效率高。

根据本公开实施例的第一方面，公开了一种号码发放方法，包括：

接收用户的号码发放的请求；

为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码；

由分配的进程从负责发放的号段中选取一个号码发放给用户。

根据本公开实施例的第二方面，公开了一种号码发放装置，包括：

接收单元，用于接收用户的号码发放的请求；

分配单元，用于为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码；

选取单元，用于由分配的进程从负责发放的号段中选取一个号码发放给用户。

根据本公开实施例的第三方面，公开了一种号码发放系统，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。

根据本公开实施例的第四方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。

本公开实施例中，由多个进程并行发放号码，每个进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同。当接收到用户的号码发放的请求时，为所述请求分配一个进程，该进程发放对应号段的号码，对于外界来说，无法从该号码获知应用的用户量，从而提高了号码发放信息的安全性。另外，通过这种方式，不同进程可以并行发放号码，且由于每个进程发放自己的号段内的号码，不需要访问公共数据库，因而不需要加锁，因此，提高了发放效率。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1A-F示出了根据本公开示例实施方式的号码发放方法应用在应用注册时应用ID的发放的场景下的界面变化图。

图2A-H示出了根据本公开示例实施方式的号码发放方法应用在彩票号码发放的场景下的界面变化图。

图3A-H示出了根据本公开示例实施方式的号码发放方法应用在车辆摇号的场景下的界面变化图。

图4A示出了根据本公开的一个示例实施方式的号码发放方法应用的网络架构的示意图。

图4B是在图4A的基础上详细示出了进程号码配置服务器的内部结构的示意图。

图5示出了根据本公开的一个示例实施方式的号码发放方法的流程图。

图6示出了根据本公开的一个实施方式的图5中步骤220的详细流程图。

图7示出了根据本公开的一个示例实施方式的号码发放方法的流程图。

图8示出了根据本公开的一个示例实施方式的分配进程所在地理区域的号码总数的流程图。

图9示出了根据本公开的一个示例实施方式的图5中步骤230的详细流程图。

图10示出了根据本公开的一个示例实施方式的号码发放方法的流程图。

图11是详细示出了根据本公开的一个示例实施方式的过滤规则匹配部分和运营规则匹配部分的示意图。

图12示出了根据本公开的一个示例实施方式的号码发放装置的框图。

图13示出根据本公开一示例实施方式的号码发放方法的结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本公开实施例中，由多个进程并行发放号码，每个进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，例如一个进程发放 00010001-00020000号段的号码，另一个进程发放00020001-00030000号段的号码。当接收到用户的号码发放的请求时，为所述请求分配一个进程，该进程发放对应号段的号码，对于外界来说，无法从该号码获知应用的用户量。另外，通过这种方式，不同进程可以并行发放号码，且由于每个进程发放自己的号段内的号码，不需要访问公共数据库，因而不需要加锁，因此，提高了发放效率。

下面结合图1A-F、图2A-H。图3A-H，描述下根据本公开示例实施方式的号码发放方法在三种应用场景下的使用。

在应用注册时，一般来说，用户需要填写自己的基本信息，提交后应用为用户分配一个应用ID，以后用户在登录该应用时使用该应用ID登录。在该场景中，发放的号码是用户标识(ID)。不希望用户从分配的应用ID 中看出目前应用的注册用户数，同时希望对于应用ID的发放，具有高效率。

图1A示出了用户下载应用后打开应用出现的注册引导界面。用户要使用一个应用前，首先需要下载应用。下载应用后，需要注册后才能登录使用。在下载应用后，打开应用，出现图1A所示的界面，在界面上出现按钮“开始注册”。用户触摸该按钮“开始注册”，进入到图1B的界面。

图1B示出了用户填写注册信息的界面。在图1B的界面中，要求用户填写姓名、昵称、出生年月、性别、民族、爱好、职业等个人信息，然后用户触摸“确认注册”的按钮，开始注册，应用为用户发放应用ID。

图1C示出了等待应用ID的分配的等待界面。在应用ID没有发放到用户之前，一直显示图1C所示的等待界面，直到向用户成功下发应用ID为止。

图1D示出了显示为用户发放的应用ID的界面。一旦向用户成功下发应用ID，图1C的显示界面就会变成如图1D所示，显示分配的应用ID。用户触摸界面上的“登录”按钮可以以该应用ID直接登录。在以后登录时，用户需要输入该应用ID才能登录。

图1E示出了当应用ID符合预设运营规则时让用户领取红包的界面。如果为用户发放的应用ID恰好符合了预设的运营规则，通知用户领取红包。图1E的界面既显示了为用户发放的应用ID，又通知了用户领取红包。当用户触摸界面上的“领取红包”按钮，开始领取红包。

图1F示出了当应用ID符合预设运营规则时为用户送礼物的界面。如果为用户发放的应用ID恰好符合了预设的运营规则，通知用户领取礼物。图1F的界面既显示了为用户发放的应用ID，又通知了用户查看礼物。当用户触摸界面上的“查看礼物”按钮，开始查看礼物。

在彩票号码发放时，发放的号码是彩票号码。一般来说，用户在应用上申请购买彩票，应用就为用户分配一个彩票号码。在开奖时间，如果分配的彩票号码与后台预设的运营规则(中奖规则)正好匹配，则用户中奖，通知用户领奖。在请求发放彩票时，也希望快速有效率地进行发放，不希望等待时间太长。另外，如果买彩票的人太少，彩票发放机构也不希望用户能看出这一点。

图2A示出了挂靠在微信下的第三方服务模块的显示界面，在这些第三方服务模块中有一个“彩票”模块，用户触摸该模块进入彩票应用。除此之外，用户也可以单独下载一个彩票应用来登录。

无论是用户从图2A所示的界面选择“彩票”模块，还是用户下载彩票应用并登录，都会出现图2B所示的彩票种类选择界面。用户可以在图2B示出的彩票种类中选择其中的一种。

图2C示出了彩票号码分配的等待界面。用户在图2B的界面中选择一种彩票种类，应用开始为应用下发彩票号码。在彩票号码没有发放到用户之前，一直显示图2C所示的等待界面，直到向用户成功下发该彩票号码为止。

图2D示出了立刻开奖的情况下显示为用户发放的彩票号码的界面。一旦向用户成功下发彩票号码，图2C的显示界面就会变成如图2D所示，显示分配的彩票号码。彩票有立刻开奖和定期开奖两种。如果是立刻开奖的彩票，就如图2D所示，在界面上显示“查看是否中奖”的按钮。用户触摸该按钮，就可以查看分配的彩票号码是否中奖。

图2E示出了立刻开奖时当彩票号码符合预设运营规则时通知用户领奖的界面。当用户在图2D的界面触摸“查看是否中奖”按钮，应用将把分配的彩票号码与后台的运营规则(中奖规则)进行匹配，如果匹配，则在界面上通知用户领奖。

图2F示出了定期开奖的情况下为用户发放彩票号码、并通知用户开奖时间的界面。应用计算到当前时间与本期开奖时间的时间差，将该时间差显示在界面上，如“距离开奖时间还有1天12小时38分45秒”。

图2G示出了用户在开奖时间后打开该应用时提示开奖界面。如上例中，如果在1天12小时38分45秒后打开该彩票应用，此时不首先为用户显示图2B所示的界面，而是显示如图2G所示的界面。在界面中，指出用户购买的彩票已经开奖。用户可以触摸界面上的“查看中奖情况”按钮，来查看是否中奖。

图2H示出了用户触摸“查看中奖情况”的按钮后当彩票号码符合预设运营规则时通知用户领奖的界面。当用户触摸“查看中奖情况”后，应用将把分配的彩票号码与后台的运营规则(中奖规则)进行匹配，如果匹配，则在界面上通知用户领奖。

用户购车后，携带购车发票到交管部门核实，由交管部门盖章，在交管部门的引导下，下载摇号应用。摇号应用为用户分配一个摇号ID，该摇号ID供摇号时使用。在确定是否为用户发放车牌号时，应用或后台将分配的摇号ID与预设的运营规则进行匹配，如果匹配，则确定为用户发放车牌号。在这种应用场景下，发放的号码是摇号ID(不是最终的车牌号)。

当用户下载摇号应用后，打开摇号应用时，首先出现图3A所示的显示界面，该界面要求用户将身份证进行拍照。用户触摸“开始拍照”的按钮，利用手机对身份证拍照。拍照完毕后，出现图3B的界面。

图3B示出了身份证拍照后提示用户查看或上传的界面。在界面上有“查看”和“上传”按钮。如果用户触摸“查看”按钮，则向用户显示拍照的身份证。如果用户触摸“上传”按钮，则进行拍照的身份证的上传。

在身份证上传成功后，出现图3C所示的界面，该界面要求用户将交管部门核实盖章的车辆购买发票拍照并上传。用户触摸界面上的“拍照”按钮，开始对交管部门核实盖章的车辆购买发票进行拍照

图3D示出了车辆购买发票拍照后提示用户查看或上传的界面。该界面有两个按钮，即“查看”和“上传”。当用户触摸“查看”按钮后，显示车辆购买发票的拍照。当用户触摸“上传”按钮后，将车辆购买发票的拍照上传。

图3E示出了车辆购买发票拍照并上传后，等待交管部门核实，通知用户获取核实结果的时间的界面。在图3E中，通知用户3天后打开应用，获取核实结果。

当用户3天后打开应用，此时显示屏上出现图3F的界面，该界面示出了交管部门的核实认证已经通过，要求用户领取摇号ID。当用户触摸图3F界面上的“领取”按钮之后，开始为用户发放摇号ID。

图3G示出了在核实结果通过时用户选择领取摇号ID向用户发放摇号 ID的界面，该界面同时通知用户查看该摇号ID是否会获得车牌号资格的时间。该界面通知用户于2018年6月30日打开应用，查看摇号结果，即是否获得领取车牌号资格。

当用户于2018年6月30之后打开应用时，显示屏上首先出现摇号结果，即为用户分配的摇号ID是否获得了领取车牌号资格。图3H的界面显示，为用户分配的摇号ID获得了领取车牌号资格。用户可以触摸界面上的“查看”按钮，查看领取车票号通知，按照通知的要求领取车牌号。

图4A示出了根据本公开的一个示例实施方式的号码发放方法应用的网络架构的示意图。该系统构架包括用户终端110、调度引擎120、具有一个或多个进程1301的放号机130、进程号码配置服务器140。

用户终端110是请求号码发放的终端。在图1A-F的应用注册时的应用 ID发放的应用场景下，用户终端110是请求注册并发放应用ID的终端。在图2A-H的彩票号码发放的应用场景下，用户终端110是购买彩票、请求发放彩票号码的用户终端。在图3A-H的车辆摇号的应用场景下，用户终端110 是购车后参加车辆摇号、请求摇号ID的用户的终端。它可以是专用终端，也可以是安装了应用之后的通用终端，例如台式电脑、手机、PDA、笔记本电脑、车载设备等。在应用注册时的应用ID发放的应用场景下，该安装的应用是要注册的应用。在彩票号码发放的应用场景下，该安装的应用是彩票应用。在车辆摇号应用的应用场景下，该安装的应用是车辆摇号应用。

调度引擎120是响应于用户终端110的放号请求，为该放号请求分配一台放号机130上的一个进程的机器。该调度引擎120可以由单台计算机或单台计算机上的一部分(作为虚拟机)实现，也可以由多台联网的计算机实现，还可以由多台联网的计算机各自一部分联合实现。例如，它可以采用虚拟机集群的形式，即从多台物理机上分别划分出一部分作为虚拟机，集体行使调度引擎120的功能。在云环境下，它可以由云环境中的多台分布式计算设备联合实现。

放号机130是用于为用户发放号码的一台机器。它可以是专用终端，也可以是安装了应用之后的通用终端，例如台式电脑、笔记本电脑等。它也可以是一台终端的一部分(作为虚拟机)。该放号机130运行若干为用户发放号码的进程1301。进程是资源(CPU、内存等)分配的基本单位，它是程序执行时的一个实例。一台放号机130可以运行一个进程1301，也可以运行多个进程1301。

进程号码配置服务器140是为每个进程配置发放的号段的服务器。它可以是一台计算机构成的服务器，也可以由多台联网的计算机实现，还可以由多台联网的计算机各自一部分联合实现。例如，它可以采用虚拟机集群的形式，即从多台物理机上分别划分出一部分作为虚拟机，集体行使进程号码配置服务器140的功能。在云环境下，它可以由云环境中的多台分布式计算设备联合实现。

图4B示出了图4A的进程号码配置服务器140的各组成部分的一个示例。进程号码配置服务器140包括进程标识表1401、号段配置表1402、子号段分配表1403、号码配置引擎1404。当为进程1301分配负责发放的号段时，首先进程1301要在进程标识表1401中获取一个未分配的进程标识。进程标识表1401将该进程标识上报号码配置引擎1404，由号码配置引擎 1404为该进程分配其负责发放的号段，分配号段的具体方法将在后面详细描述。然后，号码配置引擎1404将进程的标识和为其分配的号段相对应地存储在号段配置表1402中。进程1301凭进程标识在号码配置表1402中可以找到其负责发放的号段。同时，号码配置引擎1404会将为进程分配的号段写在子号段分配表中。进程1301知道自己负责发放的号段后，不是整个存储在自己的缓存中进行发放(进程所在的放号机的缓存是有限的)，而是从号段中取出一个一个的子号段进行发放。由于号码配置引擎1404将为进程分配的号段写在子号段分配表中，进程1301从该子号段分配表1403 一个一个取出子号段，取出的子号段放在自己缓存中发放，未取出的子号段仍放在子号段分配表1403中。例如，从进程1301分配的号段是 00010001-00020000。进程1301可以先从子号段分配表1403中取出子号段00010001-00011000进行发放，将00011001-00020000留在子号段分配表1403中以后再取。当进程号码配置服务器140是由多台联网的计算机联合实现时，号码配置引擎1404可以分布在其中一台或多台计算机上。当进程号码配置服务器140是由单台计算机实现时，号码配置引擎1404可以是作为计算机的一部分(例如程序代码段)实现。虽然在图4B中，进程号码配置服务器140包括进程标识表1401、号段配置表1402、子号段分配表1403、号码配置引擎1404，但本领域技术人员应当理解，进程号码配置服务器140 也可以不具有这样的结构区分，而是一体化实现。进程号码配置服务器140 本身具有进程标识表1401、号段配置表1402、子号段分配表1403、号码配置引擎1404的全部功能。

如图5所示，提出了一种根据本公开实施例的号码发放方法。

在图1A-F的应用注册时的应用ID发放的应用场景下，所述号码是指应用注册时的应用ID。在图2A-H的彩票号码发放的应用场景下，所述号码是指彩票号码。在图3A-H的车辆摇号的应用场景下，所述号码是指摇号ID。

在图1A-F的应用注册时的应用ID发放的应用场景下，所述号码发放方法是由要注册的应用的平台服务器执行的。在图2A-H的彩票号码发放的应用场景下，所述号码发放方法是由彩票应用的平台服务器执行的。在图3A-H的车辆摇号的应用场景下，所述号码发放方法是由交管部门负责车辆摇号的服务器执行的。

如图5所示，该方法包括：

步骤210、接收用户的号码发放的请求；

步骤220、为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码；

步骤230、由分配的进程从负责发放的号段中选取一个号码发放给用户。

下面对这些步骤进行详细描述。

在步骤210中，接收用户的号码发放的请求。

在图1A-F的应用注册时的应用ID发放的应用场景下，所述请求是响应于用户在图1B的界面上触摸“确认注册”按钮而产生并发送的。在图2A-H的彩票号码发放的应用场景下，所述请求是用户在图2B的界面上选择一种类型的彩票而触发产生并发送的。在图3A-H的车辆摇号的应用场景下，所述请求是用户在图3F的界面上触摸“领取”按钮而产生并发送的。

用户终端产生的请求发送给平台后，由调度引擎120为其分配服务的进程1301。

在步骤220中，为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码。

号段是指若干号码组成的集合。每个进程负责发放的号段，可以是连续号码的号段，也可以是不连续号码的号段。

连续号码的号段是指号段内的号码连续的号段。例如，为进程A分配号段00010001-00020000，其中包含10000个连续的号码；为进程B分配号段00020001-00040000，其中包含20000个连续的号码。

不连续号码的号段是指号段内的号码不连续的号段，例如按照预定规律变化。例如，将所有符合852X+1(X为正整数)的号码分配给进程A，将富有符合852X+2以及852X+3(X为正整数)的号码分配给进程B。这样做能带来一个有益的技术效果，即从号码的值无法容易地推断出属于哪个号段、以及应由哪个进程发放，从而提高了号码发放的安全性。

因此，在一个实施例中，可以将符合公式Y_i＝AX+i的号码分配给进程i (i＝1,2,3……n),其中A是不小于n的正整数，X为正整数,Y_i为分配给进程i的号码。该实施例的好处是不容易从号码的值推出号码所属的号段，提高号码发放的安全性。

在一个实施例中，从均衡各进程的处理负荷的角度考虑，可以基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程。已分配却未处理是指，已将请求分配给该进程，该进程还未为该请求发放号码。各进程已分配却未处理的请求数可以被认为是进程当前的处理负荷。应当尽可能保证将请求分配到当前处理负荷小的进程中处理，也就是说分配到已分配却未处理的请求数最小的进程中处理，这样有利于负荷均衡，系统的协同处理能力会得到提高。

一种基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程的方法是将已分配却未处理的请求数最小的进程分配给所述请求。例如，有6个进程，已分配却未处理的请求数分别是17、28、57、186、9、 87，则将所述请求分配给已分配却未处理的请求数为9的那个进程。

另一种基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程的方法包括：

从已分配却未处理的请求数低于预定请求数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

例如，有6个进程，已分配却未处理的请求数分别是17、28、57、186、 9、87，预定请求数阈值为30，则17、28和9都低于该阈值，将所述请求可以随机分给这3个进程中的任何一个。

相比于将已分配却未处理的请求数最小的进程分配给所述请求，这种实施方式具有这样的好处：由于各进程的已分配却未处理的请求数是定期采集的，例如每隔5分钟由进程1301向调度引擎120上报，如果每个固定周期内接收到的请求都集中分给一个进程，假设一个固定周期内接收到的请求数很大的话，有可能造成该进程在该固定周期后分配的请求数又变得超多，不利于负荷的均衡分配。而只要已分配却未处理的请求数低于预定请求数阈值，可以认为这样的进程都是处理负荷比较轻的，这样，就可向这些进程均衡分配，避免在一个固定周期过后，原本处理负荷最轻的进程变成处理负荷过重。

例如，在上述6个进程的已分配却未处理的请求数分别是17、28、57、 186、9、87的例子中，每隔5分钟确定一次各个进程的已分配却未处理的请求数。17、28、57、186、9、87是在5分钟之前确定的各个进程的已分配却未处理的请求数。然而，在该5分钟之内，接收到200个号码发放请求，如果将已分配却未处理的请求数最小的进程分配给所述请求，则原本已分配却未处理的请求数为9的进程，在5分钟过后，请求数就会增加200 个，可能由已分配却未处理的请求数最小的进程一跃变成已分配却未处理的请求数最大的进程。而如果这200个请求在已分配却未处理的请求数为 17、28、9的3个进程中随机分配的话，这3个进程中的任何一个进程在5 分钟过去后的已分配却未处理的请求数都不至于过大。

如上所述，每个进程已分配却未处理的请求数可以定期获取。定期获取的一种方式是由各进程在固定周期的末尾向调度引擎120进行上报。定期获取的另一种方式是调度引擎120在每个固定周期的末尾向各进程进行轮询，由各进程在对轮询的响应中携带该请求数。

在一个实施例中，除了基于各进程已分配却未处理的请求数，还基于各进程所在机器的处理能力，为所述请求分配发放号码的进程。

相比于仅基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程，这样做的好处在于，它充分考虑到，每个进程还能承担的负荷，不仅与其已经承担的负荷有关，还与其承担能力有关。有的进程本身处理能力强，它就能够在单位时间处理比其它进程更多的请求，虽然其分配的进程比较多，也不至于影响其处理性能。

各进程所在机器的处理能力是指进程所在的放号机的处理性能，它包括CPU处理性能和存储容量等多个方面。在一个实施例中，可以用CPU处理速度和/或存储器容量来表征各进程所在机器的处理能力。进程所在的机器的CPU的处理速度越快，存储器容量越大，进程已分配却未处理的请求数越少，越应该将请求分配到这样的进程。在一个实施例中，进程分配的优先程度是基于进程所在的机器的CPU的处理速度和存储器容量的增函数、以及进程已分配却未处理的请求数的减函数而产生的，可以通过如下公式确定进程的优先程度分数P：

P＝as/Q+bM/Q公式1

其中，P为进程的优先程度分数，其反映了将其分配给请求的优先程度，s代表进程所在的机器的CPU处理速度，M代表进程所在的机器的存储器容量，Q代表进程已分配却未处理的请求数，a和b分别是为s/Q和M/Q分配的常系数。从公式1中看出，进程所在的机器的CPU的处理速度越快，存储器容量越大，其优先程度分数P越大。进程已分配却未处理的请求数越小，其优先程度分数P越大。

为了防止当Q等于0时，P值变得无限大，可以在公式1的分母中增加常数项q,即：

P＝as/(q+Q)+bM/(q+Q)公式2

公式2可以避免当进程已分配却未处理的请求数接近于0时P值的过大。

在该实施例中，基于上述优先程度分数P，确定为所述请求分配的进程。

一种基于优先程度分数确定为所述请求分配的进程的方法包括：将所述优先程度分数最大的进程分配给所述请求。

另一种基于优先程度分数确定为所述请求分配的进程的方法包括：

从所述优先程度分数高于预定优先程度分数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

相比于将优先程度分数最大的进程分配给所述请求，这种实施方式具有这样的好处：由于公式1中的s和M固定，而Q是定期采集的，例如每隔5分钟由进程1301向调度引擎120上报，因此，优先程度分数P是每个固定周期变化一次。如果每个固定周期内接收到的请求都集中分给一个进程，假设一个固定周期内接收到的请求数很大的话，有可能造成该进程在该固定周期后分配的请求数又变得超多，不利于负荷的均衡分配。而只要优先程度分数高于预定优先程度分数阈值，可以认为这样的进程都是优先程度基本相当的，这样，就可向这些进程均衡分配，避免在一个固定周期过后，原本处理负荷很轻的进程变成处理负荷过重。

在另一个实施例中，如图6所示，步骤220由调度引擎执行，该调度引擎可以是如图4A-B所示的调度引擎120。在该实施例中，步骤220可以包括：

步骤2201、根据进程所在机器的处理能力，确定第一分数；

步骤2202、根据进程已分配却未处理的请求数，确定第二分数；

步骤2203、根据所述第一分数和第二分数，确定所述进程的总分数；

步骤2204、基于所述总分数，确定为所述请求分配的进程；

步骤2205、为所述请求分配确定的进程。

下面对这些步骤进行分别描述。

在步骤2201中，根据进程所在机器的处理能力，确定第一分数。进程所在机器的处理能力越高，第一分数应该越高。进程所在机器的处理能力越低，第一分数应该越低。

如上所述，在一个实施例中，进程所在机器的处理能力包括进程所在机器的CPU处理速度和存储器容量。一个实施例中，可以通过查表的方式确定第一分数。预先设置进程所在机器的CPU处理速度的各种数值区间、存储器容量的各种数值区间与第一分数的对照表。在确定第一分数的过程中，首先确定进程所在机器的CPU处理速度所在的数值区间、以及进程所在机器的存储器容量所在各种数值区间，然后根据确定的两个数值区间，在所述对照表中，查找与确定的两个数值区间对应的第一分数。

在另一个实施例中，第一分数是基于进程所在机器的处理能力的增函数而产生的。如上所述，在一个实施例中，进程所在机器的处理能力包括进程所在机器的CPU处理速度和存储器容量，因此，在一个实施例中，第一分数可以分别是进程所在机器的CPU处理速度和存储器容量的增函数，公式如下：

S₁＝a₁s+b₁M 公式3

其中，S₁代表第一分数，s代表进程所在的机器的CPU处理速度，M代表进程所在的机器的存储器容量，a₁和b₁分别是为s和M分配的权重。

相对于以上通过查表的方式确定第一分数，公式3提高了确定第一分数的准确性，从而分配的进程更科学，提高号码发放效率。

在步骤2202中，根据进程已分配却未处理的请求数，确定第二分数。进程已分配却未处理的请求数越大，第二分数应该越小。进程已分配却未处理的请求数越小，第二分数应该越大。

一个实施例中，可以通过查表的方式确定第二分数。预先设置进程已分配却未处理的请求数的各种数值区间与第二分数的对照表。在确定第二分数的过程中，首先确定进程已分配却未处理的请求数所在的数值区间，然后根据确定的数值区间，在所述对照表中，查找与确定的数值区间对应的第二分数。

在另一个实施例中，第二分数是基于进程已分配却未处理的请求数的减函数而产生的。根据进程已分配却未处理的请求数，确定第二分数的公式如下：

S₂＝c₁/Q 公式4

其中，S₂代表第一分数，Q代表进程已分配却未处理的请求数，c₁是常系数。

相对于以上通过查表的方式确定第二分数，公式4提高了确定第二分数的准确性，从而分配的进程更科学，提高号码发放效率。

为了防止当Q等于0时，S₂值变得无限大，可以在公式4的分母中增加常数项q,即：

S₂＝c₁/(q+Q) 公式5

公式5相对于公式4的优点是，避免了当进程已分配却未处理的请求数接近于0时S₂值的过大。

在步骤2203中，根据所述第一分数和第二分数，确定所述进程的总分数。

根据所述第一分数和第二分数确定所述进程的总分数的一种实现方式是求第一分数和第二分数的和，作为总分数。该实现方式是基于进程所在机器的处理能力、进程已分配却未处理的请求数被认为是同等重要的两个因素而考虑的。

根据所述第一分数和第二分数确定所述进程的总分数的另一种实现方式是求第一分数和第二分数的加权和，作为总分数。该实现方式是基于进程所在机器的处理能力、进程已分配却未处理的请求数的重要程度有所不同而考虑的。即：

S＝p₁S₁+p₂S₂ 公式6

其中，S代表总分数，S₁代表第一分数，S₂代表第二分数，p₁和p₂分别代表为第一分数和第二分数分配的权重，它们是预先根据经验设定的。

相比于求第一分数和第二分数的和作为总分数，公式6的优点是，充分考虑到了进程所在机器的处理能力、进程已分配却未处理的请求数对于进程分配时的有效程度的影响不是同等的，从而将请求更合理地分配给进程，提高号码发放的效率。

在步骤2204中，基于所述总分数，确定为所述请求分配的进程。

一种基于总分数确定为所述请求分配的进程的方法包括：将所述总分数最大的进程分配给所述请求。

另一种基于总分数确定为所述请求分配的进程的方法包括：

从所述总分数高于预定总分数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

相比于将总分数最大的进程分配给所述请求，这种实施方式具有这样的好处：s和M固定，因此第一分数相对固定。而Q是定期采集的，会在每个固定周期变化，因此第二分数会在每个固定周期变化，导致总分数是每个固定周期变化一次。如果每个固定周期内接收到的请求都集中分给一个进程，假设一个固定周期内接收到的请求数很大的话，有可能造成该进程在该固定周期后分配的请求数又变得超多，不利于负荷的均衡分配。而只要总分数高于预定优先程度分数阈值，可以认为这样的进程都是优先程度基本相当的，这样，就可向这些进程均衡分配，避免在一个固定周期过后，原本处理负荷很轻的进程变成处理负荷过重。

在步骤2205中，为所述请求分配所述进程。

在步骤2204中确定为所述请求分配的进程后，在本步骤中，就可以将所述进程分配给所述请求。

不同进程负责发放的号段互不相同，是指没有任何一个号码同时属于多个号段，由多个进程发放。如果有一个号码可以由多个进程发放，会造成发放号码的重复。

各进程并行发放号码，相比于只有一个进程能在同一时间发放号码，大大提高了号码发放的效率。

为请求分配发放号码的进程之后，可能会有多个请求当前都被分配由该进程发放号码，却未被执行，如果多个请求都一起为其发放号码，会造成执行拥塞。为了避免执行拥塞，本公开的一个实施例为每个进程设置一个等待队列，将分配给该进程的请求都放在该队列中排队。当进程为当前正执行的请求发放完号码后，该进程的队列中排在最前面的请求取得下一个执行权，该进程开始为其发放号码。

在该实施例中，在用户终端产生号码发放的请求时，请求中带有请求时间戳，该请求时间戳标识产生所述请求的时间。

如图7所示，在一个实施例中，在步骤220之后，所述方法还包括：步骤225、基于所述请求时间戳，将所述请求放入分配的进程的队列中排队。

在一个实施例中，将所述请求按照请求时间戳的时间顺序从早到晚在队列中排队。

例如，队列中有6个请求，其请求时间戳分别是：

请求1：2018年6月5日11:27:34；

请求2：2018年6月5日11:25:56；

请求3：2018年6月5日11:26:35；

请求4：2018年6月5日11:26:55；

请求5：2018年6月5日11:27:10；

请求6：2018年6月5日11:26:11。

将这6个请求按照请求时间戳的时间顺序从早到晚排序后，形成这样的队列：

请求2：2018年6月5日11:25:56；

请求6：2018年6月5日11:26:11；

请求3：2018年6月5日11:26:35；

请求4：2018年6月5日11:26:55；

请求5：2018年6月5日11:27:10；

请求1：2018年6月5日11:27:34。

请求时间戳表示请求产生的时间，并不是请求到达进程的时间。由于网络传输速度等原因，有可能出现产生较早的请求最后到达进程可能较晚，因此，在一个实施例中，步骤225包括：

将所述请求所述分配的进程的队列中；

对队列中的请求按照时间戳从早到晚的顺序进行重排。

也就是说，将所述请求放到分配的进程的队列中后，不一定该请求的时间戳是整个队列中最晚的，这是因为由于网络原因，有可能有一些产生比该请求晚的请求先到了该队列中，因此，对队列中的进程按照时间戳从早到晚的顺序进行重排。重排的一种方式是：

将所述请求分配在队列中最后的位置；

将所述请求的时间戳依次与其队列中前一个请求的时间戳进行比较，如果所述请求的时间戳早于该前一个请求的时间戳，将进行位置互换，直到所述请求的时间戳晚于该前一个请求的时间戳。

这种重排方式与将队列中的每个请求的时间戳打乱进行重排的方式相比，大大减少了比较的次数，提高了重排的效率。

例如，进程的队列有如上6个带有时间戳的请求。这时，请求7加入该队列。请求7的时间戳是2018年6月5日11:27:04。

先将请求7放在整个队列最后的位置，此时队列变成：

请求2：2018年6月5日11:25:56；

请求6：2018年6月5日11:26:11；

请求3：2018年6月5日11:26:35；

请求4：2018年6月5日11:26:55；

请求5：2018年6月5日11:27:10；

请求1：2018年6月5日11:27:34；

请求7：2018年6月5日11:27:04。

将请求7与队列中其前一个请求(请求1)的时间戳相比，由于其比前一个请求(请求1)的时间戳早，将请求7和请求1的位置互换，此时队列变成：

请求2：2018年6月5日11:25:56；

请求6：2018年6月5日11:26:11；

请求3：2018年6月5日11:26:35；

请求4：2018年6月5日11:26:55；

请求5：2018年6月5日11:27:10；

请求7：2018年6月5日11:27:04；

请求1：2018年6月5日11:27:34。

将请求7与队列中其前一个请求(请求5)的时间戳相比，由于其比前一个请求(请求5)的时间戳早，将请求7和请求5的位置互换，此时队列变成：

请求2：2018年6月5日11:25:56；

请求6：2018年6月5日11:26:11；

请求3：2018年6月5日11:26:35；

请求4：2018年6月5日11:26:55；

请求7：2018年6月5日11:27:04；

请求5：2018年6月5日11:27:10；

请求1：2018年6月5日11:27:34。

将请求7与队列中其前一个请求(请求4)的时间戳相比，由于其比前一个请求(请求4)的时间戳晚，不再位置互换。

该基于请求时间戳排队的方式具有的优点在于，消除了由于网络原因请求晚的请求可能在队列中排到前面的位置带来的不公正。

在另一个实施例中，所述请求中还包含优先级。优先级是指在进程的队列中排队时的优先程度。优先级可以根据各种因素确定。在一个实施例中，它根据所述请求的发出者决定。即，如果号码发放的请求来自一个实体(企业、事业、国家机关、社会团队等)，而非个人，该请求就具有高优先级，在号码发放时优先为其发放。

在一个实施例中，除了根据请求时间戳之外，还根据优先级，将所述请求放入分配的进程的队列中排队。在一个实施例中，其具体可以包括：

将优先级高的请求在队列中排在优先级低的请求的前面；

对于同一优先级的请求，按照请求时间戳的从早到晚的先后顺序将请求在队列中排队。

例如，队列中有6个请求，其请求时间戳和优先级分别是：

请求1：2018年6月5日11:27:34；优先级：高；

请求2：2018年6月5日11:25:56；优先级：低；

请求3：2018年6月5日11:26:35；优先级：高；

请求4：2018年6月5日11:26:55；优先级：低；

请求5：2018年6月5日11:27:10；优先级：低；

请求6：2018年6月5日11:26:11；优先级：低。

由于请求1和3的优先级为高，将它们排在其余4个请求的前面。由于请求3的请求时间戳早于请求1的请求时间戳，将请求3排在请求1的前面。对于4个优先级为低的请求，其请求时间戳从早到晚排序后的顺序是：请求2、请求6、请求4、请求5。队列变成：

请求3：2018年6月5日11:26:35；优先级：高；

请求1：2018年6月5日11:27:34；优先级：高；

请求2：2018年6月5日11:25:56；优先级：低；

请求6：2018年6月5日11:26:11；优先级：低；

请求4：2018年6月5日11:26:55；优先级：低；

请求5：2018年6月5日11:27:10；优先级：低。

由于该实施例既考虑请求时间戳，又考虑优先级，使得对于号码发放的请求的急迫性作了区分，对于一些有必要优先发放到号码的情形，可以优先为其发放，增加了发放方法的灵活性。

在另一个实施例中，根据请求时间戳和优先级，将所述请求放入分配的进程的队列中排队，可以包括：

基于请求时间戳，确定请求时间戳分数；

基于优先级，确定优先级分数；

基于请求时间戳分数和优先级分数，确定排序总分数；

基于排序总分数，将所述请求放入分配的进程的队列中排队。

基于请求时间戳确定请求时间戳分数可以通过查找预设的请求时间戳与当前时间的差与请求时间戳分数对照表进行。确定请求时间戳分数可以每隔预定时间段进行，也可以响应于队列中新进入一个请求而进行。在每隔预定时间段(例如1分钟)确定请求时间戳分数的实施例中，预定时间段结束的时间点就是当前时间。在响应于队列中新进入一个请求而确定请求时间戳分数的实施例中，新进入一个请求的时间点就是当前时间。例如，在2018年6月5日11:29:42队列中新进入一个请求，队列中有一个请求的时间戳是2018年6月5日11:28:37，则时间差为1分5秒。

请求时间戳与当前时间的差与请求时间戳分数对照表的一个例子如下：

请求时间戳与当前时间的差	请求时间戳分数
		0-30秒	0
30-50秒	1
		50-60秒	2
60-70秒	3
		70-80秒	4
80以上	5

表1

当时间差为1分5秒时，其落在60-70秒的区间中，查上表得到其请求时间戳分数为3。

基于优先级确定优先级分数也可以通过查找预设的优先级与优先级分数对照表来进行。在优先级只有高和低两个级别的情况，一个优先级与优先级分数对照表如下：

优先级	优先级分数
		低	0
高	5

表2

在优先级有5个等级的情况下，一级为优先级最高，二级为次之，三级、四级、五级越来越次之，相应的优先级与优先级分数对照表如下：

优先级	优先级分数
		一级	5
二级	4
		三级	3
四级	2
		五级	1

表3

基于请求时间戳分数和优先级分数确定排序总分数的一个实施方式是将请求时间戳分数和优先级分数相加，得到排序总分数。这种实施方式是建立在认为请求时间戳与优先级对于请求的排序应具有同样的影响的基础上。

然而，随着具体应用的不同，请求时间戳和优先级对于请求的排序不一定具有同样的影响。哪种因素影响大，取决于系统设计者的价值取向。因此，在另一个实施方式是将请求时间戳分数和优先级分数的加权和，作为排序总分数。例如，请求时间戳分数为3，优先级分数为5，请求时间戳被赋予的权重为0.6，优先级分数被赋予的权重为0.4，则排序总分数＝3× 0.6+5×0.4＝1.8+2＝3.8。

相比于将请求时间戳分数和优先级分数相加得到排序总分数的实施方式，这种加权和的实施方式考虑到了请求时间戳和优先级对于请求的排序不一定具有同样的影响，使得排序更具有灵活性。

基于排序总分数将所述请求放入分配的进程的队列中排队的一种实施方式是，按照排序总分数由高到低的顺序，将所述请求放入分配的进程的队列中排队。

在一个实施例中，按照排序总分数由高到低的顺序，将所述请求放入分配的进程的队列中排队，包括：

将所述请求所述分配的进程的队列中；

对队列中的请求按照时间戳从早到晚的顺序进行重排。

重排的一种方式是：

将所述请求分配在队列中最后的位置；

将所述请求的排序总分数依次与其队列中前一个请求的排序总分数进行比较，如果所述请求的排序总分数高于该前一个请求的排序总分数，将进行位置互换，直到所述请求的排序总分数低于该前一个请求的排序总分数。

这种重排方式与将队列中的每个请求的排序总分数打乱进行重排的方式相比，大大减少了比较的次数，提高了重排的效率。

例如，进程的队列有6个请求，按总分数从高到低排序分别为：

请求3：4.5分；

请求6：3.7分；

请求5：3.5分；

请求2：3.1分；

请求4：2.9分；

请求1：2.5分。

这时，请求7加入该队列。请求7的总分数是3.0分。

先将请求7放在整个队列最后的位置，此时队列变成：

请求3：4.5分；

请求6：3.7分；

请求5：3.5分；

请求2：3.1分；

请求4：2.9分；

请求1：2.5分；

请求7:3.0分。

将请求7与队列中其前一个请求(请求1)的总分数相比，由于其比前一个请求(请求1)的总分数高，将请求7和请求1的位置互换，此时队列变成：

请求3：4.5分；

请求6：3.7分；

请求5：3.5分；

请求2：3.1分；

请求4：2.9分；

请求7:3.0分；

请求1：2.5分。

将请求7与队列中其前一个请求(请求4)的总分数相比，由于其比前一个请求(请求4)的总分数早，将请求7和请求4的位置互换，此时队列变成：

请求3：4.5分；

请求6：3.7分；

请求5：3.5分；

请求2：3.1分；

请求7:3.0分；

请求4：2.9分；

请求1：2.5分。

将请求7与队列中其前一个请求(请求2)的总分数相比，由于其比前一个请求(请求2)的总分数低，不再位置互换。

如上所述，每个进程负责发放一个号段的号码，每个进程负责发放的号段的号码数可以不同。在一个实施例中，进程负责发放的号段内的号码数目按照所述进程所在地理区域分配的号码总数、该地域区域内的进程数确定。这里的地理区域可以是行政区域，例如规定每个省或直辖市是一个行政区域，或每个县是一个行政区域，也可以是地图上预定长和宽的方格区域，例如将地理划分成10公里×10公里的正方形，每个正方形是一个地理区域。在一个实施例中，在初始分配号段时，进程负责发放的号段内的号码数目等于所述进程所在地理区域分配的号码总数除以该地域区域内的进程数。也就是说，进程所在地理区域分配的号码总数越多，每个进程负责发放的号段内的号码数目可能就越多；该地域区域内的进程数越多，每个进程负责发放的号段内的号码数目可能就越少。因此，为了控制每个进程负责发放的号段内的号码数目均衡，在一些繁华的地区，如北京、上海，如请求量比较庞大，因此要分成该地区比较大的号码总数，因而在该地区需要设比较多的进程来分担。

在上述实施例中，在一个地理区域中，每个进程负责发放的号段内的号码数目是平均分配的，然而，在实际情况中，每个进程的处理能力不一样，即单位时间内为请求发放号码的数目是不一样的。有的进程在单位时间(例如一天、一小时)发放的号码多一些，有的进程在单位时间(例如一天、一小时)发放的号码少一些。为了充分考虑不同进程发放号码的能力，在一个实施例中，进程负责发放的号段内的号码数目按照以下方法确定，该方法由进程号码配置服务器执行，如图4A中的进程号码配置服务器 140。具体地说，该方法由号码配置引擎执行，如图4B中的号码配置引擎 1404。所述方法包括：

获取所述进程所在地理区域分配的号码总数；

获取所述进程所在地理区域每个进程每个单位时间上报的该单位时间发放号码数目；

确定每个进程各单位时间上报的单位时间发放号码数目的平均数；

将所述进程所在地理区域分配的号码总数按每个进程的所述平均数的比进行分配。

获取所述进程所在地理区域分配的号码总数将在后文中详细描述。

获取所述进程所在地理区域每个进程每个单位时间上报的该单位时间发放号码数目可以通过由进程1301每隔单位时间(例如一天、一个小时) 向进程号码配置服务器140进行上报来实现，也可以通过进程号码配置服务器140每隔单位时间(例如一天、一个小时)向各进程1301进行轮询，由各进程1301进行应答来实现。

确定每个进程各单位时间上报的单位时间发放号码数目的平均数可以通过由进程号码配置服务器140将该进程历史上单位时间上报的各单位时间发放号码数目进行平均而实现。

将所述进程所在地理区域分配的号码总数按每个进程的所述平均数的比进行分配可以通过以下公式实现：

M_i＝M×L_i/(L₁+L₂+……+L_n) 公式7

其中，n为所述进程所在地理区域中进程总数，M是所述进程所在地理区域分配的号码总数，M_i是第i个进程(1≦i≦n)分配的号段的号码总数， L_i代表为第i个进程计算的上述平均数。

例如，在某一地理区域中有5个进程，为每个进程计算出的历史上每天上报的当天发放号码数目的平均数分别为12000个、8000个、14000个、6000个、10000个，该地理区域的进程总数为100000个，因此，第三个进程分得的号段的号码总数为：

100000×14000/(12000+8000+14000+6000+10000)＝28000。

该实施例的优点在于，充分考虑不同进程发放号码的能力，将地理区域中号码总数不是平均分配，而是按照不同进程发放号码的能力来分配，有利于整体发放效率的提高。

每个地理区域的号码总数是与该地理区域的号码发放请求数相关的。一般来说，该地理区域越繁华，越容易出现更多的号码发放请求，这时就要分配更大的号码总数。

如图8所示，在一个实施例中，所述进程所在地理区域的号码总数按照如下方法分配。该方法由进程号码配置服务器执行，如图4A中的进程号码配置服务器140。具体地说，该方法由号码配置引擎执行，如图4B中的号码配置引擎1404。所述方法包括：

步骤310、获取待发放号码总数；

步骤320、获取各地理区域历史上单位时间平均请求数；

步骤330、按照各地理区域历史上单位时间平均请求数的比例关系，分配所述待发放号码总数。

下面对这些步骤进行详细描述。

在步骤310中，获取待发放号码总数可以由进程号码配置服务器140 在接收到号码发放任务时从号码发放任务中读出。

在步骤320中，获取各地理区域历史上单位时间平均请求数。它是通过获取各地理区域历史上每个单位时间的请求数，再将该地理区域历史上各单位时间的请求数求平均而得到的。

在一个实施例中，获取各地理区域历史上每个单位时间的请求数可以通过由各进程在每个单位时间的结束向进程号码配置服务器140上报该单位时间接到的号码发放请求数，然后由进程号码配置服务器140将接收到的该地理区域内的进程在该单位时间内上报的号码发放请求数进行相加而实现。

在一个实施例中，获取各地理区域历史上每个单位时间的请求数可以通过由进程号码配置服务器140在每个单位时间的结束向该地理区域内的各进程询问该单位时间内接到的号码发放请求数，由各进程进行应答，然后由进程号码配置服务器140将接收到的该地理区域内的进程在该单位时间内上报的号码发放请求数进行相加而实现。

在步骤330中，按照各地理区域历史上单位时间平均请求数的比例关系，分配所述待发放号码总数。

步骤330可以通过以下公式实现：

F_i＝F×H_i/(H₁+H₂+……+H_l) 公式8

其中i为地理区域的个数，F是待发放号码总数，F_i是第i个地理区域(1≦i≦l)分配的待发放号码总数，H_i代表为第i个地理区域的历史上单位时间平均请求数。

例如，共有5个地理区域，为每个地理区域计算出的历史上单位时间平均请求数110000个、90000个、100000个、130000个、70000个，待发放号码总数为1000000个，对于第三个地理区域，分得的号码总数为：

1000000×100000/(110000+90000+100000+130000+70000)＝200000。

该实施例的优点在于，充分考虑不同地理区域的请求数可能不均衡的特点，按照不同地理区域的实际请求数来分配该地理区域分得的号码数，有利于负载的均衡和整体发放效率的提高。

在步骤230中，由分配的进程从负责发放的号段中选取一个号码发放给用户。

由于进程的缓存往往很小，如果分配的进程将负责发放的号码全部取走，放到其缓存中，可能造成缓存的溢出或进程性能的下降。为了不造成进程缓存的溢出或性能的下降，在一个实施例中，如图9所示，步骤230 包括：

步骤2301、由分配的进程从负责发放的号段中取出一个子号段放入该进程的缓存；

步骤2302、从缓存中的子号段中取出一个号码发放给用户。

上述过程由进程(例如图4A-B中的进程1301)执行。

如图4B所示，当为进程1301分配负责发放的号段时，首先进程1301 要在进程标识表1401中获取一个未分配的进程标识。进程标识表1401将该进程标识上报号码配置引擎1404，由号码配置引擎1404为该进程分配其负责发放的号段，分配号段的方法如上所述。然后，号码配置引擎1404将进程的标识和为其分配的号段相对应地存储在号段配置表1402中。进程 1301凭进程标识在号码配置表1402中可以找到其负责发放的号段。同时，号码配置引擎1404会将为进程分配的号段写在子号段分配表中。进程1301 知道自己负责发放的号段后，不是整个存储在自己的缓存中进行发放(进程所在的放号机的缓存是有限的)，而是从号段中取出一个一个的子号段进行发放。由于号码配置引擎1404将为进程分配的号段写在子号段分配表中，进程1301从该子号段分配表1403一个一个取出子号段，取出的子号段放在自己缓存中发放，未取出的子号段仍放在子号段分配表1403中。

在一个实施例中，进程每次从子号段分配表中取出的子号段是相等大小的。在另一实施例中，进程每次从子号段分配表中取出的子号段是不相等大小的，其可以根据进程当前的处理速度等决定。如果进程最近单位时间(例如每小时)发放的号码较多(可能由于所在机器最近没有处理其它任务，CPU剩余能力和存储器剩余存储容量较大)，则可以取比较大的子号段。如果进程最近单位时间(例如每小时)发放的号码较少(可能由于所在机器最近在处理其它任务，CPU剩余能力和存储器剩余存储容量较小)，则可以取比较小的子号段。

在一个实施例中，取出的子号段包含的号码的数目根据该进程历史上单位时间内平均发放的号码数量确定。在一个实施例中，如下具体实现：

在每个单位时间(例如，一小时)的结束，获取该进程该单位时间发放的号码数量；

将该进程历史上获取的各单位时间发放的号码数量进行平均；

按照各单位时间发放的号码数量的平均数，确定取出的子号段包含的号码的数目。

上述由进程号码配置服务器执行，如图4A中的进程号码配置服务器 140。具体地说，该方法由号码配置引擎执行，如图4B中的号码配置引擎 1404。

在每个单位时间(例如，一小时)的结束，获取该进程该单位时间发放的号码数量，可以通过由各进程在每个单位时间的结束，向进程号码配置服务器140上报进行，也可以通过进程号码配置服务器140在每个单位时间的结束，向各进程进行询问，由各进程进行应答进行。

按照各单位时间发放的号码数量的平均数，确定取出的子号段包含的号码的数目，可以通过以下公式：

D＝αC 公式9

其中，C表示该进程各单位时间发放的号码数量的平均数，α是相应系数，D是取出的子号段包含的号码的数目。

在另一个实施例中，取出的子号段包含的号码的数目也可以根据该进程当前单位时间发放的号码数量确定。在一个实施例中，如下具体实现：

在当前单位时间(例如，一小时)的结束，获取该进程该当前单位时间发放的号码数量；

按照该当前单位时间发放的号码数量，确定取出的子号段包含的号码的数目。

上述过程由进程号码配置服务器执行，如图4A中的进程号码配置服务器140。具体地说，该方法由号码配置引擎执行，如图4B中的号码配置引擎1404。

在当前单位时间(例如，一小时)的结束，获取该进程该当前单位时间发放的号码数量，可以通过由各进程在当前单位时间的结束，向进程号码配置服务器140上报进行，也可以通过进程号码配置服务器140在当前单位时间的结束，向各进程进行询问，由各进程进行应答进行。

按照该当前单位时间发放的号码数量，确定取出的子号段包含的号码的数目，可以通过以下公式：

D＝βC₁ 公式10

其中，C₁表示该进程当前单位时间发放的号码数量，β是相应系数，D 是取出的子号段包含的号码的数目。

由于当前单位时间发放的号码数量更能反映进程当前的处理能力，因此，相对于按照各单位时间发放的号码数量的平均数确定取出的子号段包含的号码的数目的方案，按照该当前单位时间发放的号码数量，确定取出的子号段包含的号码的数目，取出的子号段号码数目更适合进程当前实际状况，有利于发放效率的提高。

在一个实施例中，进程从缓存的子号段取出号码发放可以是按照号码从小到大的顺序来取出号码发放。

在另一个实施例中，进程从缓存的子号段取出号码发放可以是随机取出号码发放，并且在发放后将该号码从缓存中去除。相比于按照号码从小到大的顺序来取出号码发放的实施例，这种随机发放的方式更不容易让攻击者推断出下一个要发放的号码，而且不容易让用户看出目前已发放的号码量，有利于信息安全。

另外，在一个实施例中，步骤230包括：由分配的进程从负责发放的号段中选取一个号码，如果选取的号码不满足预设的过滤规则，将该号码发放给用户。

如图11所示，在步骤220(为所述请求分配发放号码的进程)后，进程130开始为请求执行号码发放。首先，进程130从相应的子号段选取一个号码。它不是立刻将该号码发放，而是送到号码过滤模块2307进行号码的过滤。在过滤时，号码过滤模块2307将该号码与过滤规则2308进行比对。如果该号码符合预设的过滤规则2308，则不进行发放。如果该号码不符合预设的过滤规则2308，则进行发放。

这种技术方案的一个典型应用就是靓号保留。靓号保留就是将一些含有比较多大家认为比较吉利的数字(如6或8)保留起来不对普通请求发放，而是进行不同价位的出售。例如，88888888、66666666、68686868等所有码位都由6或8组成的号码售价最高，14156688,17356868等最后几位由6 或8组成，但前面几位含有其它数字的号码售价没有所有码位都由6或8 组成的号码售价高，但也作为靓号出售。因此，将这些靓号的规则预先设置在过滤规则2308中。它们是不能正常发放的。过滤规则2308可以根据需要事先设置，例如，至少最后四位都由6或8组成。

如图10所示，在一个实施例中，在步骤230之后，所述方法还包括：

步骤240、将发放的号段通知到运营服务器，其中，如果发放的号段与运营服务器的预设运营规则匹配，由运营服务器向用户发活动通知消息。

当由进程将号码发放给用户之后，进程还将发放的号段通知给运营服务器2403。运营服务是指当使用应用的用户满足某一条件或触发了某一条件之后，根据运营需要进行的某种服务。这种服务往往都是对用户有利的服务，它的目的往往是为了增强用户对应用的使用体验，从而增强用户粘着度。

运营服务器2403中的运营服务模块2401将给用户发放的号码与预设运营规则2402进行比较，如果匹配，对用户进行运营活动，例如，送礼物、送红包等等。预设运营规则例如，号码的第2位和第4位加起来等于第6 位。

在如图1A-F所示的应用注册时应用ID的发放的场景下，运营活动是送红包或送礼物。图1E示出了在应用注册时为用户发放完号码后，如果为用户发放的号码与预设运营规则匹配，让用户领取红包的界面。如果用户触摸图1E的“领取红包”按钮，则该用户领取红包。图1F示出了在应用注册时为用户发放完号码后，如果为用户发放的号码与预设运营规则匹配，给用户发礼物，让用户查看该礼物的界面。如果用户触摸图1F的“查看礼物”按钮，则该用户查看礼物详情(包括礼物名称、价格)等，在用户填写地址、邮编等信息后，礼物按照用户填写的地址和邮编向用户进行邮寄。

在如图2A-H所示的彩票号码发放的场景下，运营活动是彩票中奖。运营规则是中奖规则。例如，一等奖一名，号码为28709732；二等奖十名，最后的7位为7679972；三等奖一百名，最后的6位是070837；纪念奖一万名，最后的4位是0452。

在如图3A-H所示的车辆摇号的场景下，运营活动是摇号摇中，即获得领域车牌号的资格。运营规则可能是一个摇号ID的清单。例如，此次摇号中，向1万人下发车牌号。运营规则是1万个摇号ID的清单。该清单可以从由计算机从所有领取了摇号ID的用户中随机抽取的。

在如图1A-F所示的应用注册时应用ID的发放的场景下，将发放的号码通知到运营服务器是在向用户发放选取的号码之后或同时进行的，其是由向用户发放选取的号码这一动作触发的。

在如图2A-H所示的彩票号码发放的场景下，将发放的号码通知到运营服务器是由在如图2D所示的界面上用户触摸“查看是否中奖”而触发的 (立刻开奖的情况)，或者是在如图2G所示的界面上用户触摸“查看中奖情况”而触发的(定期开奖的情况)，它不是与向用户发放选取的号码同时进行的。

在如图3A-H所示的车辆摇号的场景下，将发放的号码通知到运营服务器，是由如图3H所示，用户在规定的查看是否获得领取车牌号资格的时间打开应用这一动作触发的，它也不是与向用户发放选取的号码同时进行的。

根据本公开的一个实施例，还提供了一种号码发放装置，包括：

接收单元410，用于接收用户的号码发放的请求；

分配单元420，用于为所述请求分配发放号码的进程，所述进程负责发放一个号段内的号码，不同进程负责发放的号段互不相同，且各进程并行发放号码；

选取单元430，用于由分配的进程从负责发放的号段中选取一个号码发放给用户。

在一个实施例中，分配单元420进一步用于基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程。

在一个实施例中，分配单元420进一步用于将已分配却未处理的请求数最小的进程分配给所述请求。

在一个实施例中，分配单元420进一步用于从已分配却未处理的请求数低于预定请求数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

在一个实施例中，分配单元420进一步用于还基于各进程所在机器的处理能力，为所述请求分配发放号码的进程。

在一个实施例中，进程所在机器的处理能力包括所述机器的CPU处理速度和存储器容量。分配单元420进一步用于：

通过如下公式确定进程的优先程度分数P：

P＝as/Q+bM/Q

其中，P为进程的优先程度分数，其反映了将其分配给请求的优先程度， s代表进程所在的机器的CPU处理速度，M代表进程所在的机器的存储器容量，Q代表进程已分配却未处理的请求数，a和b分别是为s/Q和M/Q分配的常系数；

基于上述优先程度分数，确定为所述请求分配的进程。

通过如下公式确定进程的优先程度分数P：

P＝as/(q+Q)+bM/(q+Q)

其中，P为进程的优先程度分数，其反映了将其分配给请求的优先程度， s代表进程所在的机器的CPU处理速度，M代表进程所在的机器的存储器容量，Q代表进程已分配却未处理的请求数，a和b分别是为s/Q和M/Q分配的常系数，q为常数项；

基于上述优先程度分数，确定为所述请求分配的进程。

在一个实施例中，所述基于上述优先程度分数，确定为所述请求分配的进程包括：将所述优先程度分数最大的进程分配给所述请求。

在一个实施例中，所述基于上述优先程度分数，确定为所述请求分配的进程包括：从所述优先程度分数高于预定优先程度分数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

在一个实施例中，分配单元420进一步用于：

根据进程所在机器的处理能力，确定第一分数；

根据进程已分配却未处理的请求数，确定第二分数；

根据所述第一分数和第二分数，确定所述进程的总分数；

基于所述总分数，确定为所述请求分配的进程。

在一个实施例中，进程所在机器的处理能力包括进程所在机器的CPU 处理速度和存储器容量。第一分数按如下公式确定：

S₁＝a₁s+b₁M

在一个实施例中，第二分数按照如下公式确定：

S₂＝c₁/Q

在一个实施例中，第二分数按照如下公式确定：

S₂＝c₁/(q+Q)

其中，S₂代表第一分数，Q代表进程已分配却未处理的请求数，c₁是常系数，q为常数项。

在一个实施例中，根据所述第一分数和第二分数，确定所述进程的总分数包括：

将第一分数和第二分数的加权和，作为所述总分数。

在一个实施例中，基于所述总分数，确定为所述请求分配的进程包括：从所述总分数高于预定总分数阈值的进程中，随机选择一个，作为所述请求发放给的进程。

在一个实施例中，为每个进程设置等待队列，所述请求中包含请求时间戳。所述装置还包括：

排队单元(未示)，用于在为所述请求分配发放号码的进程之后，基于所述请求时间戳，将所述请求放入分配的进程的队列中排队。

在一个实施例中，所述基于所述请求时间戳，将所述请求放入分配的进程的队列中排队，包括：

将所述请求所述分配的进程的队列中；

对队列中的请求按照时间戳从早到晚的顺序进行重排。

在一个实施例中，所述重排包括：

将所述请求分配在队列中最后的位置；

在一个实施例中，所述请求中还包含优先级，将所述请求放入分配的进程的队列中排队还基于优先级。

在一个实施例中，基于请求时间戳和优先级，将所述请求放入分配的进程的队列中排队，包括：

将优先级高的请求在队列中排在优先级低的请求的前面；

基于请求时间戳，确定请求时间戳分数；

基于优先级，确定优先级分数；

基于请求时间戳分数和优先级分数，确定排序总分数；

在一个实施例中，所述基于排序总分数，将所述请求放入分配的进程的队列中排队，包括：

将所述请求所述分配的进程的队列中；

对队列中的请求按照时间戳从早到晚的顺序进行重排。

在一个实施例中，所述重排包括：

将所述请求分配在队列中最后的位置；

在一个实施例中，为所述进程分配号段如下实现：将符合公式Y_i＝AX+i 的所有号码作为一个号段，分配给进程i(i＝1,2,3……n),其中A是不小于n的正整数，X为正整数,Y_i为分配给线程i的号码。

在一个实施例中，进程负责发放的号段内的号码数目按照所述进程所在地理区域分配的号码总数、该地域区域内的进程数确定。

在一个实施例中，所述进程所在地理区域的号码总数如下分配：

获取待发放号码总数；

获取各地理区域历史上单位时间平均请求数；

按照各地理区域历史上单位时间平均请求数的比例关系，分配所述待发放号码总数。

在一个实施例中，所述选取单元430进一步用于：

由分配的进程从负责发放的号段中取出一个子号段放入该进程的缓存；

从缓存中的子号段中取出号码发放。

在一个实施例中，取出的子号段包含的号码的数目根据该进程历史上单位时间内平均发放的号码数量确定。

在一个实施例中，所述由分配的进程从负责发放的号段中选取一个号码发放给用户包括：

如果选取的号码不满足预设的过滤规则，才将该号码发放给用户。

在一个实施例中，在所述由分配的进程从负责发放的号段中选取一个号码发放给用户之后，所述装置还包括：

通知单元(未示)，用于将发放的号码通知到运营服务器，其中，如果发放的号码与运营服务器的预设运营规则匹配，由运营服务器向用户发活动通知消息。

根据本公开实施例的号码发放方法可以由图13的号码发放系统500实现。下面参照图13来描述根据本公开实施例的号码发放系统500。图13显示的号码发放系统500仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图13所示，号码发放系统500以通用计算设备的形式表现。号码发放系统500的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图5中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

号码发放系统500也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该号码发放系统500交互的设备通信，和/或与使得该号码发放系统500能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等) 通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，号码发放系统500还可以通过网络适配器860与一个或者多个网络(例如局域网 (LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与号码发放系统500的其它模块通信。应当明白，尽管图中未示出，可以结合号码发放系统500使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM， U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如 Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是 CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims

1.一种号码发放方法，其特征在于，包括：

接收用户的号码发放的请求；

2.根据权利要求1所述的方法，其特征在于，所述为所述请求分配发放号码的进程包括：

基于各进程已分配却未处理的请求数，为所述请求分配发放号码的进程。

3.根据权利要求1所述的方法，其特征在于，所述为所述请求分配发放号码的进程包括：

基于各进程已分配却未处理的请求数和各进程所在机器的处理能力，为所述请求分配发放号码的进程。

4.根据权利要求3所述的方法，其特征在于，所述为所述请求分配发放号码的进程包括：

根据进程所在机器的处理能力，确定第一分数；

根据进程已分配却未处理的请求数，确定第二分数；

根据所述第一分数和第二分数，确定所述进程的总分数；

基于所述总分数，确定为所述请求分配的进程；

为所述请求分配确定的进程。

5.根据权利要求1所述的方法，其特征在于，每个进程具有等待队列，所述请求中包含请求时间戳，

在为所述请求分配发放号码的进程之后，所述方法还包括：

基于所述请求时间戳，将所述请求放入分配的进程的等待队列中排队。

6.根据权利要求5所述的方法，其特征在于，所述请求中还包含优先级，所述基于所述请求时间戳，将所述请求放入分配的进程的等待队列中排队的步骤包括：

基于所述请求时间戳和所述优先级，将所述请求放入分配的进程的等待队列中排队。

7.根据权利要求1所述的方法，其特征在于，所述进程负责发放的号段内的号码数目根据所述进程所在地理区域分配的号码总数和该地理区域内的进程数确定。

8.根据权利要求7所述的方法，其特征在于，所述进程所在地理区域的号码总数按照如下方式分配：

获取待发放号码总数；

获取各地理区域历史上单位时间平均请求数；

9.根据权利要求1所述的方法，其特征在于，所述由分配的进程从负责发放的号段中选取一个号码发放给用户，包括：

从缓存中的子号段中取出一个号码发放给用户。

10.根据权利要求9所述的方法，其特征在于，所述子号段包含的号码的数目根据该进程历史上单位时间内平均发放的号码数量确定。

11.根据权利要求1所述的方法，其特征在于，所述由分配的进程从负责发放的号段中选取一个号码发放给用户包括：

由分配的进程从负责发放的号段中选取一个号码，如果选取的号码不满足预设的过滤规则，将该号码发放给用户。

12.根据权利要求1所述的方法，其特征在于，在所述由分配的进程从负责发放的号段中选取一个号码发放给用户之后，所述方法还包括：

将发放的号码通知到运营服务器，其中，如果发放的号码与运营服务器的预设运营规则匹配，由运营服务器向用户发活动通知消息。

13.一种号码发放装置，其特征在于，包括：

接收单元，用于接收用户的号码发放的请求；

14.一种号码发放系统，其特征在于，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-12中的任一个所述的方法。

15.一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1-12中的任一个所述的方法。