论文部分内容阅读
摘要：本文着重介绍了高清播出网络中接口服务器的使用，对接口服务器的特点和部署进行了说明，详细讲解了在使用过程接口消息服務可能出现的若干问题和解决办法。
关键词：消息服务器;分布式系统;MSMQ;C/S结构;高清播出
概述
重庆广播电视集团（总台）高清播总控项目由大洋公司进行软件开发和系统集成。根据实际需求，结合系统地域分散和内外网互联互通、分布式系统的情况，大洋公司在系统内核保持较少改变的基础上，通过接口消息系统定制开发，保持软件系统可靠性和稳定性，满足我台需求，达到内外网系统互联互通。对大洋软件工程师而言，使用接口消息服务器既做到了满足客户需求，精减高效，又达到灵活、稳定、安全、快捷的目的。
在内网播出机房范围内，为高效安全专用机房环境，使用C/S结构，直接与数据库进行读写操作，直接与消息服务进行通信。在外网环境中，相对比较复杂，使用虚伪专网、B/S结构，通过接口消息服务器传递播出系统内各个数据库内表格的信息更新，满足播出、编单、上载、节目代码申请等不同的业务需求。
一.接口服务器介绍
接口服务器作为网络中的节点，专门用来存储、转发相关数据、信息。它是网络上一种为客户端计算机提供各种消息类服务的高性能的计算机，它的高性能主要体现在高速度运算能力、可靠性、强大的外部数据吞吐能力等。
为什么会需要消息服务器？
主要原因是由于在高并发、分布式系统中，由于数据来不及实时同步处理，请求往往会发生堵塞，直接导致无数的行锁表锁，从而触发连接错误。通过使用消息队列，我们可以异步处理请求，缓解系统压力。
根据我台内外网结构，编播实时互动，地域分散，高安全性的特点，唯有在分布式系统才能满足需求，这也开创一个国内少有的精编排、布式部署、全高清播总控大系统，满足13个电视频道的高清播出。分布式系统部署优缺点：一方面是分布式调用的各模块高效、独立，另一方面是系统自身存在的数据库同步缺陷。无论是何种开发平台，都因为驻留在不同进程空间的分布式组件，而引入额外的复杂度，并可能对系统的效率、可靠性等诸多方面的负面影响。然而，不可否认的是在应用系统领域，我们总是会面对不同系统之间的通信、集成与整合，尤其当面临异构系统时，这种分布式的调用与通信变得困难，但它在架构设计中又有不可被取代的独特的价值。从业务分析与架构质量的角度来讲，我们也希望在系统架构中尽可能地形成对服务的重用，通过独立运行在进程中服务的形式，彻底实现客户端与服务端的耦合。这常常是架构演化的必然道路。认为可以通过“将独立的模块放入独立的进程”来解决架构因为代码规模变大而腐化的问题。比如我台的播出软件，已经被大洋公司整合进了它的播出架构中，为整个几十上百个的小系统中的一个，从软件规模上讲，极其腐化，最多只用几十分之一的代码。
我们需要一种技术能将在设计时并未考虑互操作的应用集成起来，打破它们之间的隔阂，获得比单个应用更多的效益。这或许是分布式架构存在的主要意义，这就是消息服务所存在的意义。
消息服务器，是位于应用服务器和数据库服务器之间的一个服务器。消息队列服务器作为一个缓冲，接收应用服务器发送过来的数据库操作命令，然后按照自己的配置，依次发送给对应的不同的服务器来执行。这种数据库执行的方式，我们称之为异步写入数据库。增加消息队列服务器有以下几点好处：
1，由于消息队列服务器的速度远远高于数据库服务器，所以能够快速处理并返回数据;
2，消息队列服务器具有更好的扩展性;
3，在高并发的情况下，延迟写入数据库，可以有效降低数据库的压力;
凡事都会有利有弊，消息队列也不例外，所谓知己知彼，百战不怠。我们要想把消息队列用的炉火纯青，消息队列的“弊端”也要铭记于心。
由于消息队列是在写入消息队列服务器之后，马上返回给用户，此时数据并没有真正的写入到数据库，后续的数据库操作可能会执行失败，这显然是有问题的。我们的做法是通过业务的手段来解决异步带来的不一致问题。比如我们可以稍微修改一下业务流程，在写入消息队列后，不立即返回成功信息，而是等待消息队列里的进程真正的执行完以后，再通知当前业务成功。如果业务允许，也可在业务上设计重发机制。在我台，使用的是重发机制。
消息队列有特殊的应用场景，就是要从中进行取舍，拿出一套权衡利弊之后的解决方案，解决项目中遇到的问题。特别是在新媒体等视音频业务中磁盘IO的速度与内存的速度差距太大，数据读写通常都会成为系统的瓶颈，而升级硬件成本较高，所以通常都会采取软件的方法来解决这类问题。通常就采用消息队列的方式来处理。另外，从业务方面来考虑，有些用户不是很关心的业务，可以从主流程中剥离出来，降低系统的复杂性。随着电视台内系统的扩大，系统的复杂性会越来越大，我们都知道，越是复杂的系统，越难维护。消息队列对解决这种应用场景，也是一个不错的选择。各个系统都要调用核心接口，请求核心接口的数据，这种系统，正是通过消息队列来实现的。消息队列的使用，可以减少联调和开发的工作量。
二.接口服务器的部署
安装消息服务器程序，在所有与消息相关的计算机中配置MicroSoft Message Queue微软消息队列，在大洋D3系统配置软件中的模块公共配置中，设置消息服务器、消息队列名和系统队列名。
如下图，所有消息日志必须经接口服务器与消息服务器进行通讯，传递播出系统内各个数据库内表格的信息更新，满足播出、编单、上载、节目代码申请等不同的业务需求。
消息类别：
1.节目整备类
2.节目上载后播出刷新
3.上载完成后节目整备
4.播出值班员节目单更新
5.广告审查后频道编单 三.消息服务的故障和解决方案
所有消息客戶端都是在操作系统MicroSoft Message Queue微软消息队列中配置调用，在播出系统中第一次调用大洋软件时，将SysConfig配置的消息服务器，消息类别与操作系统通讯，调入在线进程中。
播控消息服务工作异常，表现为打开素材播控软件素材管理器时，显示“打开消息队列错误”，或者提交一条素材同步，迁移或回迁任务时，任务查看窗口中显示“未处理”。
节目编单消息服务工作异常，表现为广告已审核通过的广告，频道节目编单显示为广告未审核，不能使用。
消息服务器故障分析：
运维工作本身就是“路漫漫其修远兮 吾将上下而求索”，在今年的5-6月份，连续出现了多次消息服务器的问题，一次比一次严重，先是消息服务器有短时堵塞，接着是有时延，最后是完全不通。这个过程让我们一次又一次加深了对消息服务器的理解，明白了它固有的优势和劣势，发现了现有播出系统存在的缺陷和解决之道，也算“塞翁失马，焉知非福”，最终收获满满。
通过消息服务器的观察，常态的消息日志约为几秒一条，最多的消息处理速度为一秒十条这个数量级，如果消息太多，消息服务器就会有排队，导致消息处理堵塞，在出现问题时，会发现消息显示和消息日志记录的量呈现数量级爆炸式增长，进一步抓包分析，怀疑可能是系统内某台电脑持续发送消息引起。在消息机制有时延的情况下，退出中止消息服务器工作后，还能正常运行，但在严重堵塞时，只有重启消息服务器，将所有未处理的消息事务全部抛弃才能解决问题。如图所示，2018年7月8日到12日测试堵塞的情况，MSG_CIIPMGR就非常多的日志记录，7月13日到16日正常时，MSG_CIIPMGR就很少的日志记录。如下图的文本TXT，文件大小可很清楚。
这就是分布式系统中固有的问题，如同蝴蝶效应般，一个小的BUG，通过系统放大，可能影响整个系统安危。我们通过屏蔽禁用软件的某些功能，防止问题再次出现。处理措施：
1.重新启动消息服务器上的消息服务
2.重启消息服务器
3.在SysConfig中修改消息服务器的IP指向为冷备消息服务器。
日常工作中，可以通过不定期的检查，观察消息服务器的运行界面，核查屏幕上的显示记录，可以在一定程度上判断是否正常，提前处理。消息服务器的定期重启也有助于服务器正常运行。
四、总结
经过两年的使用，我们很好的理解了消息服务器的运行规律，经历了实战的风雨，经历住了时间的考验，相信在接下来的时间内，我们的运行维护水平会有更进一步的提高。
参考文献
[1]徐晓东.数字播控系统若干技术问题的分析[J].西部广播电视，2015（22）
[2]孙国峰.电视台播出系统的构建分析[J].科技传播，2014（23）
关键词：消息服务器;分布式系统;MSMQ;C/S结构;高清播出
概述
重庆广播电视集团（总台）高清播总控项目由大洋公司进行软件开发和系统集成。根据实际需求，结合系统地域分散和内外网互联互通、分布式系统的情况，大洋公司在系统内核保持较少改变的基础上，通过接口消息系统定制开发，保持软件系统可靠性和稳定性，满足我台需求，达到内外网系统互联互通。对大洋软件工程师而言，使用接口消息服务器既做到了满足客户需求，精减高效，又达到灵活、稳定、安全、快捷的目的。
在内网播出机房范围内，为高效安全专用机房环境，使用C/S结构，直接与数据库进行读写操作，直接与消息服务进行通信。在外网环境中，相对比较复杂，使用虚伪专网、B/S结构，通过接口消息服务器传递播出系统内各个数据库内表格的信息更新，满足播出、编单、上载、节目代码申请等不同的业务需求。
一.接口服务器介绍
接口服务器作为网络中的节点，专门用来存储、转发相关数据、信息。它是网络上一种为客户端计算机提供各种消息类服务的高性能的计算机，它的高性能主要体现在高速度运算能力、可靠性、强大的外部数据吞吐能力等。
为什么会需要消息服务器？
主要原因是由于在高并发、分布式系统中，由于数据来不及实时同步处理，请求往往会发生堵塞，直接导致无数的行锁表锁，从而触发连接错误。通过使用消息队列，我们可以异步处理请求，缓解系统压力。
根据我台内外网结构，编播实时互动，地域分散，高安全性的特点，唯有在分布式系统才能满足需求，这也开创一个国内少有的精编排、布式部署、全高清播总控大系统，满足13个电视频道的高清播出。分布式系统部署优缺点：一方面是分布式调用的各模块高效、独立，另一方面是系统自身存在的数据库同步缺陷。无论是何种开发平台，都因为驻留在不同进程空间的分布式组件，而引入额外的复杂度，并可能对系统的效率、可靠性等诸多方面的负面影响。然而，不可否认的是在应用系统领域，我们总是会面对不同系统之间的通信、集成与整合，尤其当面临异构系统时，这种分布式的调用与通信变得困难，但它在架构设计中又有不可被取代的独特的价值。从业务分析与架构质量的角度来讲，我们也希望在系统架构中尽可能地形成对服务的重用，通过独立运行在进程中服务的形式，彻底实现客户端与服务端的耦合。这常常是架构演化的必然道路。认为可以通过“将独立的模块放入独立的进程”来解决架构因为代码规模变大而腐化的问题。比如我台的播出软件，已经被大洋公司整合进了它的播出架构中，为整个几十上百个的小系统中的一个，从软件规模上讲，极其腐化，最多只用几十分之一的代码。
我们需要一种技术能将在设计时并未考虑互操作的应用集成起来，打破它们之间的隔阂，获得比单个应用更多的效益。这或许是分布式架构存在的主要意义，这就是消息服务所存在的意义。
消息服务器，是位于应用服务器和数据库服务器之间的一个服务器。消息队列服务器作为一个缓冲，接收应用服务器发送过来的数据库操作命令，然后按照自己的配置，依次发送给对应的不同的服务器来执行。这种数据库执行的方式，我们称之为异步写入数据库。增加消息队列服务器有以下几点好处：
1，由于消息队列服务器的速度远远高于数据库服务器，所以能够快速处理并返回数据;
2，消息队列服务器具有更好的扩展性;
3，在高并发的情况下，延迟写入数据库，可以有效降低数据库的压力;
凡事都会有利有弊，消息队列也不例外，所谓知己知彼，百战不怠。我们要想把消息队列用的炉火纯青，消息队列的“弊端”也要铭记于心。
由于消息队列是在写入消息队列服务器之后，马上返回给用户，此时数据并没有真正的写入到数据库，后续的数据库操作可能会执行失败，这显然是有问题的。我们的做法是通过业务的手段来解决异步带来的不一致问题。比如我们可以稍微修改一下业务流程，在写入消息队列后，不立即返回成功信息，而是等待消息队列里的进程真正的执行完以后，再通知当前业务成功。如果业务允许，也可在业务上设计重发机制。在我台，使用的是重发机制。
消息队列有特殊的应用场景，就是要从中进行取舍，拿出一套权衡利弊之后的解决方案，解决项目中遇到的问题。特别是在新媒体等视音频业务中磁盘IO的速度与内存的速度差距太大，数据读写通常都会成为系统的瓶颈，而升级硬件成本较高，所以通常都会采取软件的方法来解决这类问题。通常就采用消息队列的方式来处理。另外，从业务方面来考虑，有些用户不是很关心的业务，可以从主流程中剥离出来，降低系统的复杂性。随着电视台内系统的扩大，系统的复杂性会越来越大，我们都知道，越是复杂的系统，越难维护。消息队列对解决这种应用场景，也是一个不错的选择。各个系统都要调用核心接口，请求核心接口的数据，这种系统，正是通过消息队列来实现的。消息队列的使用，可以减少联调和开发的工作量。
二.接口服务器的部署
安装消息服务器程序，在所有与消息相关的计算机中配置MicroSoft Message Queue微软消息队列，在大洋D3系统配置软件中的模块公共配置中，设置消息服务器、消息队列名和系统队列名。
如下图，所有消息日志必须经接口服务器与消息服务器进行通讯，传递播出系统内各个数据库内表格的信息更新，满足播出、编单、上载、节目代码申请等不同的业务需求。
消息类别：
1.节目整备类
2.节目上载后播出刷新
3.上载完成后节目整备
4.播出值班员节目单更新
5.广告审查后频道编单 三.消息服务的故障和解决方案
所有消息客戶端都是在操作系统MicroSoft Message Queue微软消息队列中配置调用，在播出系统中第一次调用大洋软件时，将SysConfig配置的消息服务器，消息类别与操作系统通讯，调入在线进程中。
播控消息服务工作异常，表现为打开素材播控软件素材管理器时，显示“打开消息队列错误”，或者提交一条素材同步，迁移或回迁任务时，任务查看窗口中显示“未处理”。
节目编单消息服务工作异常，表现为广告已审核通过的广告，频道节目编单显示为广告未审核，不能使用。
消息服务器故障分析：
运维工作本身就是“路漫漫其修远兮 吾将上下而求索”，在今年的5-6月份，连续出现了多次消息服务器的问题，一次比一次严重，先是消息服务器有短时堵塞，接着是有时延，最后是完全不通。这个过程让我们一次又一次加深了对消息服务器的理解，明白了它固有的优势和劣势，发现了现有播出系统存在的缺陷和解决之道，也算“塞翁失马，焉知非福”，最终收获满满。
通过消息服务器的观察，常态的消息日志约为几秒一条，最多的消息处理速度为一秒十条这个数量级，如果消息太多，消息服务器就会有排队，导致消息处理堵塞，在出现问题时，会发现消息显示和消息日志记录的量呈现数量级爆炸式增长，进一步抓包分析，怀疑可能是系统内某台电脑持续发送消息引起。在消息机制有时延的情况下，退出中止消息服务器工作后，还能正常运行，但在严重堵塞时，只有重启消息服务器，将所有未处理的消息事务全部抛弃才能解决问题。如图所示，2018年7月8日到12日测试堵塞的情况，MSG_CIIPMGR就非常多的日志记录，7月13日到16日正常时，MSG_CIIPMGR就很少的日志记录。如下图的文本TXT，文件大小可很清楚。
这就是分布式系统中固有的问题，如同蝴蝶效应般，一个小的BUG，通过系统放大，可能影响整个系统安危。我们通过屏蔽禁用软件的某些功能，防止问题再次出现。处理措施：
1.重新启动消息服务器上的消息服务
2.重启消息服务器
3.在SysConfig中修改消息服务器的IP指向为冷备消息服务器。
日常工作中，可以通过不定期的检查，观察消息服务器的运行界面，核查屏幕上的显示记录，可以在一定程度上判断是否正常，提前处理。消息服务器的定期重启也有助于服务器正常运行。
四、总结
经过两年的使用，我们很好的理解了消息服务器的运行规律，经历了实战的风雨，经历住了时间的考验，相信在接下来的时间内，我们的运行维护水平会有更进一步的提高。
参考文献
[1]徐晓东.数字播控系统若干技术问题的分析[J].西部广播电视，2015（22）
[2]孙国峰.电视台播出系统的构建分析[J].科技传播，2014（23）