基于动态漏桶算法的实时音视频服务的通话方法

1.一种基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：包括以下步骤：
S1、收集用户请求数据及已上线的坐席人员数据；
S2、根据所述用户请求数据判断所述用户请求数据的优先级并进行标注；采用漏桶算法，根据所述已上线的坐席人员数据判断漏桶最大承载量，将标记后的用户请求数据进入漏桶，根据用户请求数据的优先级安排出桶顺序；
S3、当新的用户请求数据a超出漏桶最大承载量时，比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法；
S4、服务器分配所述用户请求数据与所述坐席人员数据进行匹配，坐席人员确认服务器发送的确认指令后，服务器为用户和坐席人员打通连接，此后便可进行点对点的音视频通话；
其中，所述步骤S3内比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法具体为：
若所述新的用户请求数据a的优先级高于漏桶内的原有数据b的优先级，则将所述新的用户请求数据插入到漏桶内并排放于所述原有数据b之前，将漏桶中最后一个数据c从漏桶中溢出，给予用户友好提示并不再处理所述漏桶中最后一个数据c，需要用户重新提出请求数据；若漏桶内没有优先级低于所述新的用户请求数据a的数据，则给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据；
在执行步骤S2及S3时，系统会根据新的用户请求数据及已上线的坐席人员数据动态更新漏桶最大承载量及漏桶内用户请求数据的顺序。
2.根据权利要求1所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述已上线的坐席人员数据存储于redis缓存数据库内，所述漏桶内的用户请求数据也存储于redis缓存数据库内。
3.根据权利要求1至2任一权利要求所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述漏桶中的用户请求数据采用链表结构。
4.根据权利要求1所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述漏桶最大承载量由所述已上线的坐席人员数据决定，所述漏桶最大承载量为已上线的坐席人员数量的5倍。
5.根据权利要求1所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述用户请求数据包括请求人，请求时间，请求事项编码，请求唯一标识UUID；系统根据所述请求事项编码判断所述用户请求数据的优先级。
6.根据权利要求5所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述优先级分三级：一般，紧急，非常紧急。
7.根据权利要求1所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：所述已上线的坐席人员数据包括坐席姓名，坐席编号，等待处理请求数。
8.根据权利要求7所述的基于动态漏桶算法的实时音视频服务的通话方法，其特征在于：还包括步骤S5，通话结束后，所述已上线的坐席人员数据更新，所述等待处理请求数的数量减1，用户请求数据中的对应记录删除，之后返回步骤S4。

基于动态漏桶算法的实时音视频服务的通话方法\n技术领域\n[0001] 本发明涉及通信方法技术领域，尤其涉及一种灵活性高，可以快速处理紧急请求的基于动态漏桶算法的实时音视频服务的通话方法。\n背景技术\n[0002] 现有老百姓办事都要本人去政务中心，对镇村级或者地域广的地区，如新疆，内蒙古的人来说很不方便，可通过实时音视频可实现24小时在线服务，大大方便民众办事，并提高办事效率。但是在实现过程中存在一些难题：\n[0003] 难题1：当有大量用户同时进行视频请求时，如何高效的将用户的呼叫请求随机分发给坐席人员，避免长时间等待的情况？\n[0004] 难题2：用户请求量已超出系统处理范围，没有足够的坐席人员来处理，如何处理再进来呼叫的请求？\n[0005] 难题3：当有新的坐席人员上线，或者在线的坐席人员掉线，在等待中的用户请求如何处理？\n[0006] 现有的Webrtc是在浏览器端实现音视频通话的通话标准，只能实现如打电话类似的点对点通话服务，在多用户端呼叫多坐席端接收时，需要额外实现呼叫分发的功能，否则音视频服务将无法高效流畅的运转。\n[0007] 因此，有必要提出一种新的基于动态漏桶算法的实时音视频服务的通话方法以克服现有技术缺点。\n发明内容\n[0008] 本发明的目的是解决现有技术中的问题，提供一种可以快速处理紧急请求的基于动态漏桶算法的实时音视频服务的通话方法，保证音视频服务高效流畅地运转。\n[0009] 本发明的技术方案是：一种基于动态漏桶算法的实时音视频服务的通话方法，包括以下步骤：S1、收集用户请求数据及已上线的坐席人员数据；S2、根据所述用户请求数据判断所述用户请求数据的优先级并进行标注；采用漏桶算法，根据所述坐席人员数据判断漏桶最大承载量，将标记后的用户请求数据进入漏桶，根据用户请求数据的优先级安排出桶顺序；S3、当新的用户请求数据a超出漏桶最大承载量时，比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法；S4、服务器分配所述用户请求数据与所述坐席人员数据进行匹配，坐席人员确认服务器发送的确认指令后，服务器为用户和坐席人员打通连接，此后便可进行点对点的音视频通话。\n[0010] 作为一种优选的技术方案，所述步骤S3内比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法具体为：若所述新的用户请求数据a的优先级高于漏桶内的原有数据b的优先级，则将所述新的用户请求数据插入到漏桶内并排放于所述原有数据b之前，将漏桶中最后一个数据c从漏桶中溢出，给予用户友好提示并不再处理所述漏桶中最后一个数据c，需要用户重新提出请求数据；若漏桶内没有优先级低于所述新的用户请求数据a的数据，则给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据。\n[0011] 作为一种优选的技术方案，在执行步骤S2及S3时，系统会根据新的用户请求数据及已上线的坐席人员数据动态更新漏桶最大承载量及漏桶内用户请求数据的顺序。\n[0012] 作为一种优选的技术方案，所述已上线的坐席人员数据存储于redis缓存数据库内，所述漏桶内的用户请求数据也存储于redis缓存数据库内。\n[0013] 作为一种优选的技术方案，所述漏桶中的用户请求数据采用链表结构。\n[0014] 作为一种优选的技术方案，所述漏桶的最大承载量由所述已上线的坐席人员数据决定，所述漏桶的最大承载量为已上线的坐席人员数量的5倍。\n[0015] 作为一种优选的技术方案，所述用户请求数据包括请求人，请求时间，请求事项编码，请求唯一标识UUID；系统根据所述请求事项编码判断所述用户请求数据的优先级。\n[0016] 作为一种进一步优选的技术方案，所述优先级分三级：一般，紧急，非常紧急。\n[0017] 作为一种优选的技术方案，所述已上线的坐席人员数据包括坐席姓名，坐席编号，等待处理请求数。\n[0018] 作为一种进一步优选的技术方案，还包括步骤S5，通话结束后，所述已上线的坐席人员数据更新，所述等待处理请求数的数量减1，用户请求数据中的对应记录删除，之后返回步骤S4。\n[0019] 本发明的基于动态漏桶算法的实时音视频服务的通话方法，可以根据用户请求数据的优先级实时更新漏桶内数据队列，保证优先级高的用户请求得到优先处理，同时，对用户请求判断是否已经超出处理的最大承载量，若超出则进行友好提示后忽略，保证音视频服务的高效流畅运转。本发明的基于动态漏桶算法的实时音视频服务的通话方法，可以避免用户长时间等待，通过漏桶算法保证整个系统高效流畅运行，实时漏桶内数据队列更新，保证漏桶内的数据最大承载量的实时更新及高优先级用户请求优先处理。\n附图说明\n[0020] 图1为本发明基于动态漏桶算法的实时音视频服务的通话方法具体实施方式流程图；\n[0021] 图2为本发明基于动态漏桶算法的实时音视频服务的通话方法具体实施方式中用户请求数据处理流程图；\n[0022] 图3为本发明基于动态漏桶算法的实时音视频服务的通话方法具体实施方式中用户请求数据优先级判断及漏桶内漏桶内用户请求数据队列更新方法流程图。\n具体实施方式\n[0023] 为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。\n[0024] 在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。\n[0025] 应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。\n[0026] 应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述XXX，但这些XXX不应限于这些术语。这些术语仅用来将XXX彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一XXX也可以被称为第二XXX，类似地，第二XXX也可以被称为第一XXX。\n[0027] 取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。\n[0028] 还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。\n[0029] 如图1所示为本发明的一种基于动态漏桶算法的实时音视频服务的通话方法，包括以下步骤：S1、收集用户请求数据及已上线的坐席人员数据；S2、根据所述用户请求数据判断所述用户请求数据的优先级并进行标注；采用漏桶算法，根据所述坐席人员数据判断漏桶最大承载量，将标记后的用户请求数据进入漏桶，根据用户请求数据的优先级安排出桶顺序；S3、当新的用户请求数据a超出漏桶最大承载量时，比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法；S4、服务器分配所述用户请求数据与所述坐席人员数据进行匹配，坐席人员确认服务器发送的确认指令后，服务器为用户和坐席人员打通连接，此后便可进行点对点的音视频通话。通过该方法，可以根据用户请求数据的优先级实时更新漏桶内数据队列，保证优先级高的用户请求得到优先处理，同时，对用户请求判断是否已经超出处理的最大承载量，若超出则进行友好提示后忽略，保证音视频服务的高效流畅运转。本发明的基于动态漏桶算法的实时音视频服务的通话方法，可以避免用户长时间等待，通过漏桶算法保证整个系统高效流畅运行；当漏桶本身的流速需要调整或出现优先级较高的用户请求数据时，实时漏桶内数据队列更新，保证漏桶内的数据最大承载量的实时更新及高优先级用户请求优先处理。\n[0030] 在执行步骤S2及S3时，系统会根据新的用户请求数据及已上线的坐席人员数据动态更新漏桶最大承载量及漏桶内用户请求数据的顺序。\n[0031] 为了保证数据存储和获取的高效，作为优选方案，本实施例内上述已上线的坐席人员数据存储于redis缓存数据库内，所述漏桶内的用户请求数据也存储于redis缓存数据库内。此时，如图2所示，用户请求数据处理流程为，根据用户请求数据判断是否超出漏桶最大承载量，若超出，系统给予用户友好提示，不会将用户请求数据保存到队列中，若未超出，用户请求数据进入漏桶内，保存于redis缓存数据库内，等待连接。\n[0032] 本实施例内，步骤S3内比较所述新的用户请求数据a的优先级与漏桶内原有数据的优先级以判断所述新的用户请求数据a的处理方法具体为：若所述新的用户请求数据a的优先级高于漏桶内的原有数据b的优先级，则将所述新的用户请求数据插入到漏桶内并排放于所述原有数据b之前，将漏桶中最后一个数据c从漏桶中溢出，给予用户友好提示并不再处理所述漏桶中最后一个数据c，需要用户重新提出请求数据；当然，在实际应用中，若数据b是漏桶中的最后一个数据，此时上述原有数据b与漏桶中最后一个数据c为同一个数据，该数据从漏桶中溢出。若漏桶内没有优先级低于所述新的用户请求数据a的数据，则给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据。作为优选的实施方案，本实施例内将用户数据的优先级分三级：一般，紧急，非常紧急。此时如图3所示，当有新的用户请求数据a时，判断其优先级类别：\n[0033] 若为一般优先级，会根据漏桶内最大承载量进行判断若漏桶已满，系统会给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据；若漏桶未满，则将其放到队列最后。\n[0034] 若为紧急优先级，会判断漏桶内是否有一般优先级的用户请求数据，若无，则根据漏桶内最大承载量进行判断若漏桶已满，若漏桶已满系统会给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据；若漏桶内有一般优先级的用户请求数据，则将新的用户请求数据a放到最早的一般优先级的用户请求数据的前一个，此时，实时更新漏桶算法，若已超出漏桶最大承载量，则一般优先级的用户请求队列中的最后一个数据b从漏桶中溢出，给予用户友好提示并不再处理原有数据b，需要用户重新提出请求数据。\n[0035] 若为非常紧急优先级，会判断漏桶内是否有紧急优先级的用户请求数据，若无，则根据漏桶内最大承载量进行判断若漏桶已满，若漏桶已满系统会给予用户友好提示，不会将所述新的用户请求数据进行处理，需要用户一段时间后重新提出请求数据；若漏桶内有一般紧急优先级的用户请求数据，则将新的用户请求数据a放到最早的紧急优先级的用户请求数据的前一个，此时，实时更新漏桶算法，若已超出漏桶最大承载量，则将漏桶内用户请求数据队列中的最后一个数据b从漏桶中溢出，给予用户友好提示并不再处理原有数据b，需要用户重新提出请求数据。\n[0036] 在用户请求优先级使用的场景上，当有新的请求数据进入漏桶时，如果请求的优先级为“紧急”或者“非常紧急”，系统会对漏桶中的数据进行重新排序。如果这种情况出现较多，系统会频繁的做重新排序的动作。当系统中漏桶内的用户请求数据队列中的数据重新排序情况出现较多时，为了便于快速做新数据的插入和删除操作，使得排序能够快速完成，作为优选方案，漏桶中的用户请求数据采用链表结构。\n[0037] 上述所述漏桶最大承载量由所述已上线的坐席人员数据决定，作为优选方案，所述漏桶最大承载量为已上线的坐席人员数量的5倍。\n[0038] 在实际操作中，本实施例的用户请求数据包括请求人，请求时间，请求事项编码，请求唯一标识UUID；系统根据所述请求事项编码判断所述用户请求数据的优先级。所述已上线的坐席人员数据包括坐席姓名，坐席编号，等待处理请求数。\n[0039] 当执行完步骤S1至S4后，还可以包括步骤S5，通话结束后，所述已上线的坐席人员数据更新，所述等待处理请求数的数量减1，用户请求数据中的对应记录删除，之后返回步骤S4。也即，此时本发明基于动态漏桶算法的实时音视频服务通话方法的流程步骤为：\n[0040] 步骤1：坐席人员通过注册、登录功能上线后，将“上线”指令发送到服务器上，服务器记录坐席人员的状态。刚上线的坐席此时的等待处理请求数为0。\n[0041] 步骤2：普通用户通过注册、登录功能上线后，选择需要咨询的事项后，发送请求呼叫的指令到服务器。\n[0042] 步骤3：服务器根据用户请求进行判断，如果没有超出漏桶的最大承载量，系统会完成分配，即redis的音视频请求记录的“处理坐席编码”字段会设置对应的坐席编码。如果超出承载范围，系统给予用户提示“前面等待用户超出5个，请选择继续等待或者退出”。\n[0043] 步骤4：坐席人员在接收到“请求”指令时，确认接收。\n[0044] 步骤5：服务器为用户和坐席人员打通连接，此后便可进行点对点的音视频通话。\n[0045] 步骤6：通话结束后，redis中坐席人员数据记录中“等待处理请求数”字段数量减\n1。用户请求数据中的对应记录需要删除。返回步骤4。\n[0046] 综上所述仅为本发明较佳的实施例，并非用来限定本发明的实施范围。即凡依本发明申请专利范围的内容所作的等效变化及修饰，皆应属于本发明的技术范畴。