EasyCMS介绍
EasyCMS做为EasyDarwin开源流媒体云平台解决方案的一部分，主要进行的是设备的接入和Session（DeviceSession & ClientSession）管理，同时用户也可以复用做为其他类型项目设备接入与管理的框架，EasyCMS也源于EasyDarwin服务架构，具备一套完整的网络I/O框架以及Utility，开发者很容易在EasyDarwin的基础上开发跨平台服务程序，例如Windows、Linux、Mac、Solaris等系统平台，只要一次熟悉，将会受用终身；
EasyCMS目前在系统中的一个主要功能就是接收EasyClient客户端的RESTful接口请求，然后内部查找对应的具体设备Session，将控制命令（如开始视频直播推送、PTZ动作命令、停止直播流等）通过查找到的DeviceSession发送到具体的设备，DeviceSession收到设备命令的响应后，还需要将响应中的数据结果返回给对应的ClientSession，再由ClientSession响应给客户端设备；
问题描述
如何进行高效率的消息路由，一直是我们在讨论的问题，这里面涉及到几个问题：
1. 服务器如何在内部维护大量已发出的消息请求？
2. 消息响应如何回调反射到对应的ClientSession？
3. 消息超时不响应，EasyCMS服务器中消息请求如何释放，ClientSession如何超时释放？
我们原来的构思中，在每一个DeviceSession中维护一个已发送消息的MsgQueue，其中的每一个Element为一个包含：消息源ClientSession、消息内容、消息Sequence的结构单元，消息发送出去之后，MsgElement将加入DeviceSession::MsgQueue队列，当设备有具体的消息响应之后，再根据具体的消息Sequence遍历查找DeviceSession::MsgQueue队列，找到对应的MsgElement，再通过MsgElement::ClientSession将响应结果发送给客户端；
看似整个设计流程是比较合理的，也解决了消息路由的问题，但是这里会有几个比较严重的问题：每一个DeviceSession维护一个MsgQueue，在系统设备量和客户访问量巨大的时候，可能每一个DeviceSession会维护一个很长的MsgQueue，那么在有消息响应的时候，查找对应的MsgElement就会非常耗时好效率，而且对超时没有得到响应的MsgElement，我们需要定期遍历维护MsgQueue进行处理，或者如果每一个MsgElement都加一个定时器，自己从Queue里面释放自己，释放流程也是非常复杂的；
解决方案
考虑到维护Queue在设备和客户端并发比较高的时候必然会造成非常大的效率消耗，我们通过在EasyDarwin云平台的协议的字段中加入From、Via、To字段来解决这个问题：
1、当ClientSession通过DeviceSession向设备发送命令时：
From: <ClientSession SessionID>
Via: <EasyCMS ServiceID>
To: <DeviceSession SessionID>
2、当设备响应DeviceSession下发的命令时：
From: <DeviceSession SessionID>
Via: <EasyCMS ServiceID>
To: <ClientSession SessionID>
3、当DeviceSession收到响应后，根据To字段对应的ClientSession SessionID，在当前EasyCMS中维护的ClientSessionMap中查找对应的ClientSession，找到后，通过ClientSession进行具体消息的响应，ClientSession为自我维护一个Session的超时时间，超时时间内，没有任何数据请求或者发送的需求，ClientSession会自动析构，所以，如果根据ClientSession SessionID查找不到对应的ClientSession，该消息将自动丢弃；
4、在可靠的消息路由系统中，可以将发送的消息和收到的消息都入库到数据库中，进行消息的再次发送和响应的追溯；
那么按照上面的流程，系统能够非常高效地处理用户的请求和设备的消息，避免了大量的锁处理，结构简单，且可扩展性非常强；
获取更多信息
Github：https://github.com/EasyDarwin
Copyright © EasyDarwin.org 2012-2016
