基于一致性哈希算法和Ckafka技术的IMS电话实时录音系统①

江 凇,王宝海,赵金城,宋 江,段佳秀

1(国网江苏省电力有限公司 信息通信分公司,南京 210024)

2(南京南瑞信息通信科技有限公司,南京 210003)

3(南京邮电大学,南京 210003)

基于电力IMS[1]交换网的电话业务是国家电网公司内部重要的通信业务之一,为国家电网员工提供了高效便捷的语音通话服务.在一些重要的部门、岗位以及重要的电话会议等场景中,通常要求对通话进行录音,以记录来电的内容.通话录音的内容既可以用于追踪业务的进度,也可用于事后回溯以避免业务纠纷.因此,在电力IMS 交换网实施电话录音的行为可以完善电网内部的电话管理制度,提高业务的监管水平.

随着电话交换技术由电路交换向分组交换演进,三网融合需求的呼声越来越高,而IP 多媒体子系统(IMS)技术可以支持话音,电视媒体,数据这三种业务的传输,还具有统一的平台和接口,分层的架构设计,集中的业务控制与管理,可保证的QOS 等优点.此外,传统的基于电路交换的电话录音技术因其系统复杂,存储的不便捷和非实时性的特点,已经无法满足新时代行政办公对高效,统一,即时的通话录音需求.因此,本文设计出一种基于电力IMS 交换网的电话实时录音系统,该系统可为电力IMS 交换网中的各类终端(IP,POTS,PC 等)提供即时、高动态、高质量的录音服务,并通过系统后台将录音记录即时推送至软件终端,以便IMS 终端用户随时查阅录音.

1 基于IMS 的电话录音系统设计

该系统借助基于IMS 核心交换机的端口镜像技术实现对整个网络的监控管理,并能够及时抓取所需要的数据,借助一致性哈希算法来查找缓存服务器,利用Ckafka 高性能消息队列来保证消息消费的有序性和负载均衡.最终,设计与实现一种基于会话初始(SIP)协议[2]的高动态即时录音系统,其系统框图如图1所示.

图1 系统框图

系统的实现流程如下:

步骤1.主叫话机A 向被叫话机B 发起呼叫请求,主叫话机A 经由核心交换机、SBC(边界会话控制器)、电力IMS 交换网、再回到核心交换机,向被叫话机B 发送SIP 协议中的invite 信令[3].

步骤2.在被叫话机B 接收到invite 信令后,给主叫话机A 发送应答消息,主叫话机A 确认应答消息后,开启与被叫话机B 的通话.

步骤3.IMS 软件终端与被叫话机B 联动,当主叫话机A 与被叫话机B 的通话开启时,IMS 软件终端通知录音服务器开启录音.

步骤4.录音服务器从核心交换机的镜像端口获取信令包,再根据from、to 等标签,对信令包进行SIP 包解析,获取主被叫话机号码、IP、媒体端口及语音编码.解析RTP(媒体流)报文后,针对g.711a、g.711u、g.729、g.726、iLBC 等不同编码方式[4,5],将录音文件解码,通过Ckafka 消息队列将解码的数据缓存至高性能缓存服务器.

步骤5.通话需要结束时,主叫话机A 经由核心交换机、SBC(边界会话控制器)、电力IMS 交换网、再回到核心交换机,向被叫话机B 发送SIP 协议中的bye 信令.

步骤6.被叫话机B 接收到bye 信令后,给主叫话机A 发送应答消息,主叫话机A 确认应答消息后,结束与被叫话机B 的通话.

步骤7.录音服务器取时间或集将主被叫话机的录音进行混音并存储为PCM 格式.录音服务器将通过系统后台将录音记录即时推送至PC/Web 终端,以便用户随时查阅通话录音.

2 基于一致性哈希算法和Ckafka 技术的录音服务器设计

通过对SIP 报文中信令的解析,并从媒体端口得到通话双方的音频流,采用Ckafka 消息队列构建实时数据通道,同时提供对数据流的处理,然后将得到的音频流传送至高性能内存数据库以保存数据.在数据库和录音服务器之间插入分布式缓存[6],使录音服务器不必频繁访问数据库,而是直接从缓存存取数据,从而缩短了数据的访问时间,提高了数据库的访问性能.对于分布式缓存服务器的查找采用的是一致性哈希算法,它极大的提高了缓存命中率,以及减少在增删节点时数据迁移的成本.

2.1 Ckafka 技术

Ckafka 技术[7]是一种消息队列的技术,它基于Apache Kafka 消息队列引擎,具有强大的吞吐量和可扩展性能强的特点,主要用于高性能的流式处理、消息传输等场景,并且完全兼容Kafka.其详细特性如下:

(1)可扩展性:该框架可轻松扩展,无需停机.

(2)高容量:旨在处理大量数据,并能对数据进行压缩.

(3)可靠性:具有可恢复能力和一定的容错能力.(4)数据转换:可以把从信息源获取的数据流转化成要求的数据流格式.

(5)低延迟:专注于传统消息传递以实现低时延.

(6)顺序读写:和大部分的消息队列一致,Ckafka可以保证数据按照顺序进行处理,极大提升磁盘效率.

(7)异步通信:在无需立即处理消息的场景下,当访问量高时Ckafka 仅将消息放入队列中,等访问量降低后再对消息进行处理,以降低系统负荷[8].

本系统为集中录音系统,要求并行处理的能力强,由上面的介绍可知Ckafka 消息队列具有强大的吞吐量,多线程的流式处理,具备数据压缩的特性以节约存储空间,对于高并发数据流,支持在线的水平扩展和消息的自平衡,在最佳的情况下,插入和删除数据的时间复杂度能降为O(1),这极大的降低系统的复杂度,提高系统运行的稳定性,同时结合一致性哈希算法可以实现对服务器集群请求的均衡处理,所以本文采用该技术来对录音系统的信令流和音频流进行处理,可轻松实现毫秒级的消息处理,极大的降低系统的时延,提高系统的实时性.

2.2 一致性哈希算法

一致性哈希算法最初是由Karger D 等提出的一种散列算法.其最初是为了解决服务器集群中的热点问题,整个算法的过程如图2所示[9,10],但是该算法具有一定的局限性,当服务器的节点数较少,那么对于多个请求可能会导致散列环上的数据倾斜以及服务器分配不均的问题,因此在散列空间和物理节点之间加入虚拟节点[11],通过对虚拟节点的分配,把多个虚拟节点与相对应的物理节点进行映射,并在散列环上分布恰当的虚拟节点数目,从而每台服务器都能达到均衡处理请求的目的.

本文提出的一致性哈希算法是在普通哈希算法上进行改进,因为环形散列环大小为232,因此对目标利用哈希函数运算之后,再进行模232运算,即可将目标的Key分布在整个散列环上,如式(1)所示.

图2 一致性哈希算法

在SIP 报文中,Call-ID 可以作为这通会话的全局识别号,因此可以作为该通电话的唯一标识符;而对于不同的缓存服务器,其IP 地址也都不同,因此可以利用缓存服务器的IP 地址作为它的唯一标识符.在不考虑虚拟节点的情况下,本文提出的一致性哈希算法的步骤如下:

步骤1.利用每一台缓存服务器的IP 地址作为哈希运算的对象并进行哈希运算,然后把得到的结果进行模232运算,得到相应的键值Ks1,Ks2,···,Ksn,至此,已经将每一台缓存服务器都映射到散列环[12]上,对于3 台服务器在散列环上映射情况如图3所示.

图3 3 台服务器映射到散列环

步骤2.对当前打进来的某一通电话的Call-ID 进行哈希运算,然后再对运算结果进行模232运算,得到对应的键值Kc,并映射到步骤1 所示的散列环上,现将缓存服务器和某一通电话都映射到散列环上,其映射情况如图4所示.

步骤3.从该通电话在散列环上映射的位置开始,按顺时针方向,找到最近的那一台服务器A,那么该通电话的媒体流就缓存到服务器A,如图5所示.

图5 寻找缓存服务器过程

对于多路通话,亦可采用上述方法快速寻找到对应的缓存服务器.若多路通话均映射到散列环相对固定的位置,那么最终他们都会按顺时针寻找到最近的那台服务器缓存数据,这将导致另外两个服务器空闲,而当前服务器负载量过大甚至宕机.对此,采用虚拟节点技术[13],根据通话映射在散列表的位置关系,利用物理节点复制出多个虚拟节点,然后在散列环中安放多个虚拟节点.随着虚拟节点的增多,散列环上总的节点数就越多,节点均匀分布的可能性就越大,当多个请求同时到来时,缓存服务器的负载就能更加均衡[14–16],如图6所示,深色的表示物理节点,浅色的表示复制出的虚拟节点.由图分析可得:若不引入虚拟节点技术,将会有五通电话的请求将直接流向服务器A,一通电话的请求流向服务器B,服务器C 处于空闲状态,这样的分配方式极不平衡,这将导致服务器A 的负荷过大,系统处理能力降低,而引入虚拟节点技术,每台服务器都分到2 个请求,这样可以充分发挥每台服务器的性能,提高系统的处理能力.

图6 虚拟节点

3 录音服务器的性能分析与评价

为了验证录音服务器的性能,本文通过运行多台虚拟机来模拟录音服务器、缓存服务器集群以及数据库服务器集群,并将采用一致性哈希算法和Ckafka 消息队列技术的服务器与采用普通的哈希算法的服务器进行比较,利用JMeter 工具来模拟用户的通话录音请求,并根据服务器的响应时间、吞吐量、容错能力以及录音推送至客户端的最大时延这4 项指标作为其评估性能的依据,最后根据测试结果,使用Matlab 绘制相应的图表进行分析,结果如图7所示.

图7显示出录音服务器中同时录音的请求数与其响应时间的关系,由图可得请求数在900 以下,采用一致性哈希算法和Ckafka 技术的响应时间与采用普通哈希算法的响应时间基本一致,但随着同时录音请求数的增多,这两种方案响应时间的差距开始变大,当录音请求数达到1300 时,采用一致性哈希算法和Ckafka技术的录音服务器明显要好于另一种方案,说明本设计的录音服务器对于高并发的处理能力要强于一般服务器,其负载调度也更为合理.

图8显示出分布式录音服务器系统中服务器个数对整个系统吞吐量的关系,由图可得服务器个数在4 个以内,两种方案的吞吐量基本一致,当服务器个数大于4 时,随着服务器个数增多两者性能差距越来越明显,服务器个数为8 时,两者差距最大,约为14.29%,说明本设计的录音服务器适合做成大规模的分布式系统,其系统吞吐量的优势越显著.

图7 请求数与响应时间关系

图8 服务器个数与吞吐量的关系

对于服务器集群停机情况,本文构建了一个包含6 个服务器的集群.当群集正常接收模拟请求时,突然关闭一个录音服务器,并观察群集无法正常响应的错误率趋势.实验结果如图9所示.模拟错误发生的时间在1 s 时刻,从图中可以看出,两个方案在1 s 到3 s 的错误率处于上升阶段,基本上没有差别.然而,在3 s到5 s 内,采用普通哈希算法的服务器集群错误率几乎不变,但采用一致性哈希算法+Ckafka 技术的录音服务器的错误率显著降低.5 s 后,两个方案的错误率开始下降,直到错误率为0%.因此,可以得出结论:当集群系统有部分服务器停机时,采用一致性哈希算法和Ckafka 技术的录音服务器可以在一定程度上降低集群错误率.

当通话结束,录音服务器取时间或集将主叫和被叫通话的语音进行混音,并保存为PCM 格式,随后立即将语音消息推送至PC/Web 终端.利用通用定时器,记录从通话结束开始到PC/Web 终端收到语音消息所用的最大时延,并控制录音时间相同的通话个数,绘制服务器同时处理通话数与终端收到推送的最大时延的关系图,如图10所示.由图分析可得:当通话数小于150 时,两种方案基本保持一致,当通话数大于150 时,差距开始拉大,并且随着通话数的增多,差距越来越大.当通话数达到350 时,基于一致性哈希算法和Ckafka技术的录音服务器的最大时延为600 多毫秒,而另一种方案的最大时延已经远超过1 s,实时性得不到保证.通过以上分析,再结合图7录音请求数和响应时间的关系,可以得出结论:相比于传统电话终端录音的推送慢,查找难,不便捷的缺点,本系统在一定通话数下的响应、处理、推送时间可以控制在1 s 以内,突显出其实时性强的特点,又因为是集中式录音,不存在终端修改录音的情况,其安全性也得到了保障.

图9 服务器发生错误持续时间与错误率关系

图10 同时处理通话数与最大时延的关系

4 结论与展望

本文通过分析电力IMS 交换网中电话终端的实时录音业务需求,借助基于IMS 核心交换机的端口镜像技术、一致性哈希算法和Ckafka 高性能数据缓存技术,设计出一种基于电力IMS 交换网的即时录音系统.该即时录音系统为旁路系统,实现静默录音,不会对生产系统产生影响,可以为电力IMS 交换网的IP 终端、POTS 终端及软件终端(PC,Web)等各类终端提供即时、无差异的录音服务[17],并通过系统后台将录音记录即时推送至软件终端,以便IMS 终端用户随时查阅录音.文章最后,将基于一致性哈希算法和Ckafka 技术的服务器与基于普通哈希算法的服务器就响应时间、吞吐量、容错能力和推送的最大时延这四项指标对其进行比较,分析得出,本文设计的录音服务器具有高并发的数据处理能力,高吞吐量,响应时间短,容错力和实时性强并能实现负载均衡.此外本文的算法还可用于大规模分布式服务器的查找,分布式存储等领域[18].