“厉害了,Word哥” 强力推荐 “短信通知机制解析”
|
走过路过,不要错过!“Word哥”又在赔钱赚吆喝了! 你是否还在为每月流量、配额使用担心超限而发愁? 故事发生在一个黄昏: 遥记得那天,太阳的余晖割破天空,晚霞如血。 “Word哥”背着手,慢慢地踱着步子,在线听着周星驰的“无敌是多么寂寞“, 这时突然来了一条短信。 尊敬的用户,您好,截止到3月16号20点20分,您本月已使用1600.00MB数据流量,您本月的数据流量包共2000.00MB,剩余400.00M。查询流量使用情况,请拨******。 看完短信后,”Word哥“陷入了沉思。他在思考,短信是怎么产生的呢?又是怎么发送的呢?后来他找到了答案,写了一本秘籍,流传世间。 以下是部分节选 1.1 总体流程用户通知的模块间处理流程,主要包括通知产生、通知抑制、通知发送和通知重发,如图1-1所示。 图1-1 用户通知的内部处理流程
1.2 通知产生通知的产生有三种方式: l 在线业务触发; l 离线业务触发; l 业务发放触发。 具体触发流程如下: 1.2.1 在线业务触发:用户在线使用业务的过程中,UPCC根据来自PCEF的用户信息来判断是否触发通知。例如若PCEF上报的流量报告、用户余额等达到阈值,且该阈值存在对应通知,则触发UPCC内部SPU模块产生通知内容。在线通知产生过程如图1-2所示。 图1-2 在线业务触发
1.2.2 离线业务触发用户在离线状态下,UPCC支持定期检测用户业务信息,当检测到用户签约的业务或套餐生效、失效时,若该业务或套餐存在对应通知,则会触发MPU模块产生通知内容。离线通知产生过程如图1-3所示。 图1-3 离线业务触发
离线业务是否能触发通知由命令SET SCANSW和软参VRM_OFFLINESRVSWITCH设置。 l 业务发放触发:用户通过营帐系统签约或修改业务/套餐时,若该业务/套餐存在对应的通知,会触发UPCC内部MPU模块产生通知内容。业务发放通知产生过程如图1-4所示。 图1-4 业务发放触发
1.2.3 通知抑制从通知产生的流程可以看出,通知抑制的判断机制在MPU_MNR(离线场景)和SPU_MNR(在线场景)模块内部进行。离线场景和在线场景的通知抑制的判断机制相同,现在以在线场景为例作说明。具体过程如图1-5所示。 图1-5 通知抑制的判断机制
1. SPU根据通知抑制表(P_NotifyRestriction)中的记录,判断是否存在还未发送成功(sending状态)的相同通知。 a. 如果存在,则终止处理、不发送该短信; b. 否则,转到步骤2。 2. 判断该通知文件是否配置了通知抑制。 a. 如果配置了通知抑制,则转到步骤3; b. 否则,将该待发通知发送给PAU。具体过程如下: i. 向“通知抑制表(P_NotifyRestriction)”插入1条新的通知记录,发送结果为Sending(发送中); ii. 删除“通知抑制表(P_NotifyRestriction)”中超期的记录和每个用户超出最大记录数的通知记录; iii. 并将组装好的通知,立即发送给PAU。 3. SPU进行“通知抑制”逻辑判断,根据通知抑制表(P_NotifyRestriction)中的记录,判断待发通知与未过期的已发通知的“通知类型”、“唯一键”和“关联的通知模板”三者是否完全相同。 a. 若三者完全相同,则该待发通知被抑制,不发送该通知; b. 否则,将该待发通知发送给PAU。
特殊的,SPU模块支持通过设置软参BLC_NOTIFYSENDINTERVAL来判断短时间内的重复通知抑制。当运营商需要对在很短的时间内产生的两条相同通知消息进行抑制时,可以设置该软参。 例如:主从用户共享配额,如果消息发送的对象都设置为主用户时,主用户可能会收到两条重复的通知。通过设置该软参可以实现一段时间间隔内不重复发送相同通知。 1.2.4 通知发送当通知产生后,PAU模块将通知先保存到了本地的“通知待发文件(NotifyWaitted_PAUMID_SN.txt)”中,并不立即发送。什么时候才会真正发送,由已有待发通知的多少以及PMS对通知的发送速度决定的。 MPU离线业务通知触发流程与SPU在线业务通知触发流程相似,现在以SPU在线业务触发的通知发送为例说明。SPU触发的用户通知发送原理如图1-6所示。 图1-6 通知发送原理
1. 用户在线使用业务触发短信通知产生。例如,某一用户的配额消耗达到了设定的阈值,并且该阈值关联了短信通知,则会触发SPU产生短信通知。 2. SPU判断通知是否被抑制,判断的具体过程请参考通知抑制。若该待发通知未被抑制,则SPU将该通知记录到通知抑制表(P_NotifyRestriction),同时将待发通知发送给PAU。
l SPU对多个激活态的PAU轮询发送。 l PAU根据通知类型(短信、邮件、SOAP),将通知分别存放在不同的“通知待发文件(NotifyWaitted_PAUMID_SN.txt)”中。 l 每个用户保存的通知记录最大条数由VRM_NOTIFYMSGMAXRECORDPERSUB决定。 3. PMS上设置的定时器超时时,向PAU请求获取通知。 4. PAU从本地缓存中提取100条待发通知,发送给PMS。
l PAU将待发通知返回给PMS的同时,也会读取配置的链路信息一起返回。 l 当软参VRM_NTFSENDCONTROL取值为“1”时,PAU在提取待发通知前会判断当前重发通知文件大小及变化,根据重发堆积情况决定是否继续发送待发通知。 5. PMS将短信通知逐条发送给SMSC。 6. SMSC将通知发送给终端后,将发送结果返回给PMS。 7. PMS将发送结果发送给PAU。PAU根据发送结果,更新“通知抑制表(P_NotifyRestriction)”和“用户通知历史文件(NotifyLog_PAUMID.txt)”。 a. 如果发送成功,则: i. 更新“通知抑制表(P_NotifyRestriction)”中相应通知的发送时间,结果为Success; ii. 将通知发送日志,记录到本地的“用户通知历史文件(NotifyLog_PAUMID.txt)”中; b. 如果发送失败,则进行“通知重发”判断: i. 如果需要重发,则更新“通知抑制表(P_NotifyRestriction)”中相应通知的发送时间,结果仍为Sending;并向“通知待发表”插入1条记录,已发送次数为1。 ii. 如果不需要重发,则更新“通知抑制表(P_NotifyRestriction)”中相应通知的发送时间,结果为Fail;并将通知发送日志,记录到本地的“用户通知历史文件(NotifyLog_PAUMID.txt)”中。 通知重发 对发送失败且需要重发的通知,PAU将其保存到了“通知重发文件”中。PMS会定时触发对发送失败通知的重发。 通知重发原理如图1-7所示。 图1-7 通知重发原理
1. PMS上设置的定时器超时时,向PAU请求获取待重发短信通知。 2. PAU收到PMS发来的重发通知请求后,会从重发文件中提取重发记录返回给PMS进行发送。每次最多提取100条记录。当提取记录时,PAU只向PMS返回满足以下条件的重发通知记录: a. 当前系统时间与记录中的上次发送时间的间隔大于等于重发时间间隔(由软参VRM_NOTIFYRESENDINTERVAL(用户通知重发时间间隔)控制,默认值为600秒)。 b. 记录中的重发次数未达到重发次数上限(由软参VRM_NOTIFYRESENDINTERVAL(用户通知重发时间间隔)控制,默认为3次)。 c. 当前系统时间与记录中的上次发送时间的间隔未超过重发通知有效期(由软参VRM_NTFRESENDTIMERANGE(重发通知有效期)控制,默认为43200分钟)
PAU将待发通知返回给PMS的同时,也会读取配置的链路信息一起返回。 3. PMS按照时间先后顺序将通知逐条发送给SMSC。 4. SMSC将通知发送给终端后,将发送结果返回给PMS。 5. PMS将发送结果发送给PAU。PAU根据发送结果,更新通知相关数据库和本地“用户通知历史文件(NotifyLog_PAUMID.txt)”。
你觉得“Word哥“这本秘籍如何,可以在下面留言哦。欢迎讨论。
|

Favorite (1)





顶!