通知发送方法和装置与流程

本申请涉及数据处理领域，具体而言，涉及一种通知发送方法和装置。

背景技术：

现有的许多系统(例如，网站数据分析系统)都具有发送邮件的功能，例如，周期报表就是由用户在系统中进行配置，系统在每天的固定时刻运行这些报表，查询数据库中数据，然后将数据输出到报表模板中，生成报表，最后将报表通过邮件发送给指定用户。通常每个系统都会配置多个周期报表，这些周期报表都是并行执行的。

在报表数量非常多的情况下，例如，高达上千个报表，这些报表并发执行时，可能会存在几百个报表需要同时发送邮件。而邮件服务器对每个邮箱发送邮件的并发度是有限制的，通常并发度都非常低，例如，同时只能发10封邮件，这样会导致发送报表邮件大量堵塞，一段时间后还会超时，超时后会重试，如果大量报表发送邮件都重试的话，会进一步加剧邮件服务器负担，陷入恶性循环，进一步拉低邮件服务器性能。此外，短消息、微信消息等在需要高并发的情况下同样也存在上述问题。

针对相关技术中并行发送的通知数量过多造成通知发送堵塞的问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请的主要目的在于提供一种通知发送方法和装置，以解决相关技术中并行发送的通知数量过多造成通知发送堵塞的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种通知发送方法。该方法包括：从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知。

进一步地，在判断出发送线程的数量不小于最大并发度时，该方法还包括：等待第一预设时间，重新判断发送线程的数量是否小于最大并发度。

进一步地，在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知之后，方法还包括：检测发送待发送通知是否存在 异常；以及在检测出发送待发送通知存在异常时，将待发送通知重新添加至消息队列中。

进一步地，在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知之后，该方法还包括：检测发送待发送通知是否存在异常；在检测到发送待发送通知存在异常时，判断待发送通知的发送次数是否达到预设值；在判断出待发送通知的发送次数未达到预设值时，将待发送通知的发送次数加1，并将待发送通知重新添加至消息队列中；以及在判断出待发送通知的发送次数达到预设值时，记录待发送通知，并输出异常信息。

进一步地，在从消息队列中获取待发送通知之前，该方法还包括：检测运行开关的状态，其中，运行开关的状态包括开启状态和关闭状态，开启状态用于指示执行通知发送操作，关闭状态用于指示停止执行通知发送操作；以及在检测出运行开关处于开启状态时，判断消息队列是否为空，其中，在判断出消息队列不为空时，从消息队列中获取待发送通知，在判断出消息队列为空时，等待第二预设时间，重新判断消息队列是否为空。

进一步地，在将所有待发送通知均添加至消息队列之后，该方法还包括：判断消息队列是否为空；以及在判断出消息队列为空时，将运行开关的状态设置为关闭状态。

为了实现上述目的，根据本申请的另一方面，提供了一种通知发送装置。该装置包括：获取单元，用于从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；第一判断单元，用于判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及发送单元，用于在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知。

进一步地，该装置还包括：第二判断单元，用于在判断出发送线程的数量不小于最大并发度时，等待第一预设时间，重新判断发送线程的数量是否小于最大并发度。

进一步地，该装置还包括：第一检测单元，用于检测发送待发送通知是否存在异常；第三判断单元，用于在检测到发送待发送通知存在异常时，判断待发送通知的发送次数是否达到预设值；添加单元，用于在判断出待发送通知的发送次数未达到预设值时，将待发送通知的发送次数加1，并将待发送通知重新添加至消息队列中；以及输出单元，用于在判断出待发送通知的发送次数达到预设值时，记录待发送通知，并输出异常信息。

进一步地，该装置还包括：第二检测单元，用于检测运行开关的状态，其中，运行开关的状态包括开启状态和关闭状态，开启状态用于指示执行通知发送操作，关闭 状态用于指示停止执行通知发送操作；以及第四判断单元，用于在检测出运行开关处于开启状态时，判断消息队列是否为空，其中，在判断出消息队列不为空时，从消息队列中获取待发送通知，在判断出消息队列为空时，等待第二预设时间，重新判断消息队列是否为空。

本申请通过从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知，本申请通过将待发送通知预先添加至消息队列中进行排队，并通过将当前发送线程的数量与最大并发度比较确定是否创建新的发送线程，从而可以避免通知服务器同时发送过多的通知造成通知发送堵塞，解决了相关技术中并行发送的通知数量过多造成通知发送堵塞的问题，进而达到了避免通知发送堵塞的效果。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的通知发送方法的流程图；

图2是根据本申请又一实施例的通知发送方法的流程图；以及

图3是根据本申请实施例的通知发送装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语 “包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例，提供了一种通知发送方法。图1是根据本申请实施例的通知发送方法的流程图，如图1所示，该方法包括如下的步骤s102至步骤s106：

步骤s102，从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中。

本申请实施例的待发送通知可以是邮件、短信息、qq信息、微信信息等，以下本申请实施例均有待发送邮件为例进行说明。

本申请实施例在需要发送通知时，预先将待发送通知添加至消息队列中进行排队。具体地，以网站数据分析系统定时向用户发送周期报表为例，网站数据分析系统在需要向用户发送周期报表时，查询数据库中数据，然后将数据输出到报表模板中，生成报表，并根据报表生成待发送邮件添加至消息队列中；在同时需要向多个用户发送报表时，分别生成各个用户对应的报表，并分别根据各个报表生成多个待发送邮件，并将多个待发送邮件均添加至消息队列中进行排队。

本申请实施例在将待发送通知均预先添加至消息队列中之后，从消息队列中依次获取各个待发送通知进行发送。

步骤s104，判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程。

本申请实施例的最大并发度是指可以并行发送通知的最大数量，可选地，最大并发度的数值可以根据通知服务器发送通知的并发度进行设置，例如，在发送邮件时，邮件服务器发送邮件的并发度为10，则可以将最大并发度的数值置为10，从而可以最大限定的利用邮件发送器，以提高邮件发送效率。

具体地，发送线程的数量可以通过设置一个计数器进行统计，也可以是预先创建一个空的发送线程集合，并限定该发送线程集合中元素的数量为最大并发度，在每次创建发送线程后，均将该发送线程添加至发送线程集合中，在该发送线程完成通知发送后从发送线程集合中删除该发送线程，从而通过统计发送线程集合中发送线程的数量即可以快速得到当前发送线程的数量。

本申请实施例通过判断发送线程的数量是否达到最大并发度来确定能否创建新的发送线程以发送通知，从而可以避免并行发送过多的通知造成通知发送堵塞。

步骤s106，在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知。

具体地，以发送邮件为例进行说明，在判断出发送线程的数量小于最大并发度时，说明当前邮件服务器未处于最大负荷状态，此时可以创建新的发送线程，并通过该新的发送线程将当前从消息队列中获取的待发送邮件发送出去，在判断出发送线程的数量不小于最大并发度时，即说明当前邮件服务器处于最大负荷状态，为了避免邮件服务器运行崩溃，此时不应该创建新的发送线程以发送邮件。可选地，在判断出发送线程的数量不小于最大并发度时，该方法还包括：等待第一预设时间，重新判断发送线程的数量是否小于最大并发度。

由于发送线程在完成通知发送时，会自动释放资源，因此，发送线程的数量是实时更新的，在当前判断出发送线程的数量不小于最大并发度时，可以等待第一预设时间(例如，等待5秒)，重新判断发送线程的数量是否小于最大并发度，重复上述过程直至发送线程的数量小于最大并发度。

本申请实施例通过从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知，本申请通过将待发送通知预先添加至消息队列中进行排队，并通过将当前发送线程的数量与最大并发度比较确定是否创建新的发送线程，从而可以避免通知服务器同时发送过多的通知造成通知发送堵塞，解决了相关技术中并行发送的通知数量过多造成通知发送堵塞的问题，进而达到了避免通知发送堵塞的效果。

优选地，为了避免因通知发送异常造成通知漏发的问题，在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知之后，该方法还包括：检测发送待发送通知是否存在异常；以及在检测出发送待发送通知存在异常时，将待发送通知重新添加至消息队列中。

由于每次发送通知并不一定能够成功，为了避免因通知发送异常造成通知漏发的问题，本申请实施例在通过发送线程发送通知之后，检测待发送通知发送是否存在异常，例如，待发送通知是否成功发送至收件地址，在检测出待发送通知发送存在异常时，将该待发送通知重新添加至消息队列中重新排队以再次发送，删除发送异常的待发送通知对应的发送线程。需要说明的是，在检测出待发送通知发送成功时，可以直接释放该待发送通知对应的发送线程。

本申请实施例可以在每次待发送通知发送异常时将该待发送通知重新添加至发送 队列中再次发送，从而可以避免因通知发送异常造成通知漏发的问题。

优选地，为了避免因通知发送异常造成通知漏发的问题，在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知之后，该方法还包括：检测发送待发送通知是否存在异常；在检测到发送待发送通知存在异常时，判断待发送通知的发送次数是否达到预设值；在判断出待发送通知的发送次数未达到预设值时，将待发送通知的发送次数加1，并将待发送通知重新添加至消息队列中；以及在判断出待发送通知的发送次数达到预设值时，记录待发送通知，并输出异常信息。

由于存在一些通知，就算发送多次还是发送失败，例如，发送地址错误，此时，无休止的重复发送并不能解决问题，反而会占用通知服务器资源，影响通知服务器发送通知的效率。在本申请实施例中，对通知发送次数进行了限制，在检测到发送待发送通知存在异常时，首先判断该待发送通知的发送次数是否达到预设值，例如，设置预设值为3，如果该待发送通知的发送次数没有达到预设值，则将该待发送通知重新添加至消息队列中，并将其发送次数加1；如果该待发送通知的发送次数已达到预设值，则记录该待发送通知，并输出异常信息，从而操作人员即可以根据该异常信息分析该待发送通知发送失败的原因，可以人工的发送该待发送通知，一方面可以避免该发送异常的待发送通知长期占用通知服务器资源，另一方面也可以完全避免通知漏发的问题。

需要说明的是，本申请实施例可以在每次待发送通知发送存在异常时，记录异常信息，例如，记录在日志中，并将每次的异常信息添加至该待发送通知对应的异常集合中，在该待发送通知的发送次数达到预设值时，组合异常集合中的全部异常并输出。

优选地，在从消息队列中获取待发送通知之前，该方法还包括：检测运行开关的状态，其中，运行开关的状态包括开启状态和关闭状态，开启状态用于指示执行通知发送操作，关闭状态用于指示停止执行通知发送操作；以及在检测出运行开关处于开启状态时，判断消息队列是否为空，其中，在判断出消息队列不为空时，从消息队列中获取待发送通知，在判断出消息队列为空时，等待第二预设时间，重新判断消息队列是否为空。

为了便于控制通知的发送，本申请实施例设置了一个运行开关，只有在该运行开关处于开启状态时，才执行通知的发送操作，因此，在需要发送通知时，需要先打开该运行开关。

本申请实施例中，在从消息队列中获取待发送通知进行发送之前，先检测运行开关的状态，在检测出运行开关处于开启状态时，说明此时可以发送通知，则继续判断 消息队列是否为空，其中，在判断出消息队列不为空时，从消息队列中获取待发送通知，在判断出消息队列为空时，等待第二预设时间，例如，10秒，重新判断消息队列是否为空；在检测出运行开关处于关闭状态时，可以打开该运行开关以发送通知，也可以是直接结束。需要说明的是，系统可以是在预设时间段内不断的将待发送通知添加至消息队列中，因此，在运行开关处于打开状态时，系统还尚未将待发送通知添加至消息队列中，即消息队列为空，此时，可以等待第二预设时间重新判断消息队列是否为空。

优选地，在将所有待发送通知均添加至消息队列之后，该方法还包括：判断消息队列是否为空；以及在判断出消息队列为空时，将运行开关的状态设置为关闭状态。

具体地，本申请实施例在完成将所有待发送通知均添加至消息队列之后，通过判断消息队列是否为空结束通知的发送，具体地，在判断出消息队列不为空时，则从消息队列中依次取待发送通知进行发送，在判断出消息队列不为空时，即当前时间段需要发送的所有待发送通知均已发送，此时可以将运行开关的状态设置为关闭状态，结束通知发送，从而可以避免程序空运行，占用系统资源。

图2是根据本申请又一实施例的通知发送方法的流程图，如图2所示，该方法包括如下步骤：

步骤s201，打开运行开关。

步骤s202，创建发送线程集合。

发送线程集合中元素的数量为最大并发度指定的数量。

本申请实施例在通过步骤s202创建发送线程集合之后，通过后台线程开始循环扫描，每次扫描步骤如下步骤s203至步骤s219：

步骤s203，判断运行开关是否打开。

即允许开关是否处于开启状态。在判断出允许开关打开时，执行步骤s204，否则结束。

步骤s204，判断消息队列是否为空。

具体地，本申请实施例可以预先定义通知实体，通知实体中包含通知信息、发送次数和异常集合，其中，通知信息包括发送地址、通知(即具体发送的内容)等信息，发送次数指该待发送通知的发送次数，异常集合用于记录待发送通知的异常。在每次需要发送通知时，都先将通知实体添加至消息队列中进行排队。

本申请实施例在判断出消息队列为空时，说明当前消息队列中没有通知实体需要 发送，执行步骤s205；在判断出消息队列不为空时，说明当期消息队列中存在通知实体需要发送，执行步骤s206。

步骤s205，等待10秒。

步骤s206，取出一个通知实体。

步骤s207，判断发送线程集合中发送线程数量是否小于最大并发度。

具体地，在判断出发送线程集合中发送线程数量不小于最大并发度时，执行步骤s208，即等待5秒，重新判断发送线程集合中发送线程数量是否小于最大并发度；在判断出发送线程集合中发送线程数量小于最大并发度时，执行步骤s209。

步骤s208，等待5秒。

步骤s209，创建新的发送线程。

步骤s210，将新的发送线程添加至发送线程集合。

步骤s211，发送通知。

即根据通知信息开始发送通知。

步骤s212，判断是否有异常。

即判断发送通知是否存在异常，例如，发送失败等。在判断出存在发送异常时，执行步骤s213，否则执行步骤s219。

步骤s213，判断发送次数是否达到最大发送次数。

在判断出发送次数达到最大发送次数时，执行步骤s214，在判断出发送次数未达到最大发送次数时，执行步骤s216。

步骤s214，将通知实体的异常集合中异常组合成一个新的异常并抛出。

步骤s215，日志中记录异常。

步骤s216，发送次数加1。

步骤s217，将异常添加至通知实体的异常集合中。

步骤s218，将通知实体重新添加到消息队列中。

步骤s219，将发送线程从发送线程集合中删除。

即发送完成后，将发送线程从线程集合中删除。

需要说明的是，本申请实施例在通过后台线程循环扫描时，同时循环判断消息队列是否为空，在判断出消息队列为空时，将运行开关关闭，后续后台扫描线程执行完一次循环后，检查到该运行开关已关闭，扫描线程就会退出循环。

优选地，为了方便程序调用，本申请实施例可以预先定义通知管理器，在该通知管理器中定义了如下成员：通知上下文，上下文包含发送通知需要的常用配置；最大并发度；通知实体队列；发送线程集合；是否运行开关；发送通知方法，参数为通知实体，该方法将通知实体添加到通知实体队列中进行排队。

从以上的描述中，可以看出，一般邮件服务器的邮件发送并发度是非常低，远远不能满足需求，在很多地方都需要邮件的高并发，采用本申请实施例可以解决之前因为系统高并发和邮件发送低并发之间的矛盾，最终减少发送邮件争用资源的情况，并使得实际邮件发送的效率更高。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本申请实施例的另一方面，提供了一种通知发送装置，该通知发送装置可以用于执行本申请实施例的通知发送方法，本申请实施例的通知发送方法也可以通过本申请实施例的通知发送装置来执行。

图3是根据本申请实施例的通知发送装置的示意图，如图3所示，该装置包括：获取单元10、第一判断单元20和发送单元30。

获取单元10，用于从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中。

第一判断单元20，用于判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程。

发送单元30，用于在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知。

本申请通过获取单元10从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；第一判断单元20判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及发送单元30在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知，本申请通过将待发送通知预先添加至消息队列中进行排队，并通过将当前发送线程的数量与最大并发度比较确定是否创建新的发送线程，从而可以避免通知服务器同时发 送过多的通知造成通知发送堵塞，解决了相关技术中并行发送的通知数量过多造成通知发送堵塞的问题，进而达到了避免通知发送堵塞的效果。

可选地，该装置还包括：第二判断单元，用于在判断出发送线程的数量不小于最大并发度时，等待第一预设时间，重新判断发送线程的数量是否小于最大并发度。

优选地，该装置还包括：第一检测单元，用于检测发送待发送通知是否存在异常；第三判断单元，用于在检测到发送待发送通知存在异常时，判断待发送通知的发送次数是否达到预设值；添加单元，用于在判断出待发送通知的发送次数未达到预设值时，将待发送通知的发送次数加1，并将待发送通知重新添加至消息队列中；以及输出单元，用于在判断出待发送通知的发送次数达到预设值时，记录待发送通知，并输出异常信息。

优选地，该装置还包括：第二检测单元，用于检测运行开关的状态，其中，运行开关的状态包括开启状态和关闭状态，开启状态用于指示执行通知发送操作，关闭状态用于指示停止执行通知发送操作；以及第四判断单元，用于在检测出运行开关处于开启状态时，判断消息队列是否为空，其中，在判断出消息队列不为空时，从消息队列中获取待发送通知，在判断出消息队列为空时，等待第二预设时间，重新判断消息队列是否为空。

所述通知发送装置包括处理器和存储器，上述获取单元、第一判断单元和发送单元等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来发送通知。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)，存储器包括至少一个存储芯片。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序代码：从消息队列中获取待发送通知，其中，所有待发送通知均预先添加至消息队列中；判断发送线程的数量是否小于最大并发度，其中，发送线程为用于执行通知发送操作的线程；以及在判断出发送线程的数量小于最大并发度时，创建新的发送线程，并通过新的发送线程发送待发送通知。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有 详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。