IPTV双AAA中应用缓存提升业务响应速度的探索与实践

为贯彻全国IPTV建设管理工作会议精神，落实国家广播电视总局和地方广电局《关于开展IPTV专项治理的通知》要求，实现IPTV集成播控平台、传输服务系统的规范对接，我司于2019启动计费及运营系统的建设，即AAA平台的建设。众所周知，AAA是认证（Authentication）、授权（Authorization）和计费（Accounting）的简称，提供认证、授权和计费三种服务。认证是第一道大门，认证速度的快慢以及是否正常直接影响到用户的第一感知。而授权的要求也是非常高，若每次打开某个视频，网络正常的情况下，转了几分钟都出不来画面；或者明明订购了某部影片，播放的时候却提示无法观看，体验感就特别差。所以AAA系统必须是响应速度快、信息准确度高、稳定性高的系统。下面介绍一下AAA系统是怎么从准实时、到秒级再到毫秒级的提升之路。1.IPTV业务介绍IPTV即交互式网络电视，是一种利用宽带有线电视网，集互联网、多媒体、通讯等多种技术于一体，向家庭用户提供包括数字电视在内的多种交互式服务的崭新技术，也是国家三网融合的产物之一。IPTV业务具有独特的行业特殊性，既有传统电视行业严格的安全播出要求，也有互联网行业高效快速的要求，因此要求用户开机时必须先进行用户信息的认证，合法之后才能进入首页，播放任何一部影片之前，都需要进行鉴权，鉴权通过后方可播放。这要求在认证和鉴权既要准确也要快速。相较于互联网电视营销常用的一个VIP影视大包不同，IPTV目前的影片产品包超级多，例如分为电影包、电视剧包、少儿包等等，这给用户订购和鉴权增加了复杂度。另外用户和可订购的产品包之间，不是直接的对应关系，中间存在一个服务的概念，一个产品可以包含多个服务，一个服务也可以属于多个产品，是N对N的关系，当用户进行播放鉴权时，传的参数是影片ID和服务ID，以及用户的订购产品，这个时候需要进行查询，影片对应的服务ID是否包含在已订购的产品中，如果已经订购，则鉴权通过，都不存在已订购的产品中，则鉴权失败，系统部件多、鉴权逻辑复杂。产品、服务、用户以及影片的对接关系如图1所示。图1产品、服务、用户以及影片的对接关系2.缓存应用场景提升业务响应速度的探索与实践根据总局和区局的文件精神要求，我司制定了IPTV规范对接方案，用于规范和指导IPTV的内容下发、EPG页面发布和认证计费鉴权等流程中播控侧和传输侧的配合和分工。一开始进行规范对接时，我们遇到的难题就是如何既要规范对接，又要双方系统快速响应，不影响用户的体验感受。双AAA对接的有串行和并行方式可选。通过不断的研究和调测，由于认证的特殊性，认证只有在开机时进行认证，开机本来就需要时间，所以认证的响应时长对用户的体验感知上影响不大，所以双认证采用串行的方式，先通过电信的认证后，再到播控平台进行认证。如果电信认证不成功，则不会向播控AAA发起认证请求。目前认证在EPG上设置有token机制，token有效期设置为24小时，24小时内只要不重启都不会重新发起认证。超过24小时，token失效返回EPG首页则会再次触发认证请求。难点在于双鉴权上，鉴权是发生在用户点击播放内容的时候，鉴权需要立即响应，否则用户体验上就会出现点击播放后卡顿、转圈、黑屏等现象，非常影响体验效果。而因为内容、用户、产品、影片的多对多关系，数据量非常的大，鉴权响应速度总是提升不上来。考虑到鉴权串行模式的话，响应时长是两边响应时长的总时长、并行则响应时长为单边最长的响应时长，经过不断的研究和调测，最终把鉴权定为并行模式。下一步就是如何攻破提升响应速度这一难点了。双鉴权模式流程如图2所示。图2IPTV双鉴权模式流程图2.1初始的1.0模式在系统部署中，我们节目缓存选择为Memcache，用户信息缓存为Redis，用户订购信息为Memcache，至于为什么有的选择Memcache，有的选择Redis，这里不再赘述。一开始觉得既然要快，那么所有的信息就都放到缓存中，不用到数据库中进行查询，这个速度肯定快。于是把用户的所有信息字段以及16位标识符的对应关系放到缓存中，用户进行认证时，首先到缓存进行查询，有该用户，且状态正常，则认证通过，没有则进一步查询数据，数据库再没有，则认证失败。认证的模式基本没有问题。鉴权的缓存，参考其他同行的新媒体模式，即影片、产品、服务以及用户订购都放到缓存大池中，跳过产品和服务，按照{用户：可观看的节目}进行缓存，每个用户为一个小缓存。后来发现速度并没有提升，鉴权大约需要3秒钟的时间，体验效果不好。最后发现不能完全参考该省的模式，因为该省的AAA平台只鉴权增值业务的影片，而增值影片数量不是很大，而我们需要鉴权基础包月包的影片，也需要鉴权增值业务的影片，因此影片个数不是一个数量级的，所有的影片加起来上百万，用户也是几百万，因此缓存的数量非常多，缓存查询次数多，查询慢，导致鉴权慢。2.22.0模式在1.0模式的基础上，我们考虑了本省的实际情况，所有的IPTV用户都是只要交了IPTV基础费用之后，就可以播放所有基础包月中的影片，所有用户的基础包中的影片都是一模一样的。因此把缓存分为两个集合，一个为“公用收费节目缓存集合”，另一个为“个人购买的增值收费节目缓存集合”。当用户进行播放鉴权的时候，首先去“公共收费节目缓存集合”进行查询，如果有该节目，则鉴权通过，无须再去“个人购买的增值收费节目缓存集合”查询，速度明显提升，基础包的内容鉴权速度提升到毫秒级别。但是这个时候又发现了另外一个问题，增值的内容更新服务绑定之后，鉴权不能及时通过，无法及时播放，但是过一段时间又可以播放了。经过核查发现当前现有的“个人购买的增值收费节目缓存集合”为定时更新，更新时间是4小时更新一次，所以当有新节目和服务绑定关系发生时，不会立即更新缓存，这样会造成部分节目在小于4小时的时间内鉴权结果无法和实际需求结果匹配。2.33.0模式鉴于2.0模式的4小时问题，我们又进行了进一步的优化，考虑到产品、节目、用户之间的关系，进行了如下的优化：⑴修改收费节目信息缓存存储机制。⑵建立三组缓存关系：{节目：产品}，{用户：产品}，以及产品为单次状态下的{用户：单点节目}。⑶当用户针对节目鉴权时，首先查找节目对应的产品信息，如果产品不是单次产品，则查找用户订购产品信息，如果有交集，则认为该用户满足；如果产品是单次产品，则查找用户对应的单点节目缓存关系。⑷如按照以上方式处理，需要注意以下几点：①用户订购时需要更新用户订购缓存{用户：产品}。②用户退订时需要监测是否更新对应缓存。③后台管理系统操作添加服务和内容绑定关系时需要更新节目与产品关系缓存{节目：产品}。④下发节目和服务绑定关系时需要更新节目与产品关系缓存。优化之后，目前的AAA平台对用户播放的鉴权效果基本达到了要求，缓存命中率达到99.9%以上，鉴权速度也是200毫秒左右波动，基本符合的业务要求。2.4当前的4.0模式2019年我们又进行了整体的系统升级，进行了数据分层管理、内存管理，需要存放在Redis中的配置和实例数据，通过全量或增量方式进行内存刷新，数据分为两种：表数据和关系数据。图3为数据分层架构图。支持横向扩展的数据层服务，提供用户数据的定位和管理。图3数据分层架构图通过发布接口的方式提供前台调用，包括开户、商品订购、商品退订、账号信息变更等业务接口。通过对Redis的交互，进行请求数据转发到目标数据库服务，由目标数据库服务进行数据业务处理，并返回结果。维护全局的用户定位的内存数据，保证用户和商品信息可以被快速定位和访问。目前通过Redis进行用户快速定位，需要将用户数据实时刷新到内存。数据层包含全局数据层和私有数据层，全局数据层提供面向系统所有客户的定位，私有数据层面向单个数据库的用户信息。全局数据层由单独的服务器提供，数据来源于所有子数据库节点。私有数据层部署在子数据库节点上，数据来源于所在的数据库。包含的同步接口如下：2.4.1客户信息（全局）【作用】根据账号定位出客户ID、客户信息、手机号码、证件信息等关键数据。根据客户ID来定位业务所属的子数据库。【KEY】账号【VALUE】客户ID、客户名称、手机号码、证件类型、证件号码实现逻辑：（1)扫描客户表对应的iog表，按照主键顺序获取。（2)根据Custid查询客户表的客户资料。（3)调用Redis接口设置对应的key-value值。（4)删除iog表的记录。2.4.2商品信息（全局）【作用】用于快速查询商品核心信息。【KEY】商品SKU-ID【VALUE】商品名称、产品名称、商品价格、包月/季/年/天、其他信息。2.4.3用户定位（私有）【作用】记录每个账号对应的用户ID，可能有多个账号属于同一用户，形成统一计费关系。【KEY】账号【VALUE】用户ID实现逻辑：（1)扫描用户表对应的iog表，按照主键顺序获取。（2)据Servid查询用户对应的账号信息。（3)调用Redis接口设置对应的key-value值。（4)删除iog表的记录。2.4.4用户订购信息（私有）【作用】记录用户与计费信息的关系，用户信息包含所属年月、累计点播次数、累计点播额度。用于快速计费，快速加载用户当月实时账单（点播使用情况）信息。【KEY】用户ID【VALUE】所属年月、在用商品SKUID、到期时间、累计点播次数、累计点播额度实现逻辑：（1)扫描用户产品表对应的iog表，按照主键顺序获取。（2)根据prodid查询产品表的商品信息，根据用户ID获取计费表信息（目前可以写初始值为0）。（3)调用Redis接口设置对应的key-value值。（4)删除iog表的记录。进行了数据分层管理以及内存管理之后，我们的鉴权和认证响应速度都得到了很大的