1.定时器 
        采用nginx自身的定时器管理机制，具体细节待学习过nginx源码后加以补充 
2.channel的生成周期

（0）、初始（诞生） 
        发布、订阅均有可能产生channel

• 发布：向channel以post的形式发布消息时，如果不存在channel则产生
• 订阅：模块配置允许订阅产生channel的情况下，如果向一个不存在的channel上订阅时则产生

channel自诞生之日期就是在无奈的等死。。。只要channel被使用一次（发布、订阅）则其寿命被延长一次，保持状态处于“初始” 
（1）、死缓 
        模块每隔一段时间（默认为11s）会进行内存回收——ngx_http_push_stream_collect_expired_messages_and_empty_channels。如果一个channel既没有存储信息也没有订阅者，那它就是废物了，标记为deleted，设定过期时间为当前时间+一段时间（默认为30s），并将该channel移动到垃圾回收站。。。等死吧，不过别慌，你还有活的可能 
（2）保外就医 
        如果有人关心你（订阅、发布、统计channel信息）则将处于死缓状态的channel从垃圾堆中还原 
（3）、死刑 
        除了死缓，还有种机制可以直接将channel判为死刑——以DELETE的方式请求发布通道，则无视该channel的任何亲属关系（存储的信息、订阅者）则直接将其标记为deleted，扔入unrecoverable_channels队列。。。别幻想了，系统会ngx_http_push_stream_alert_worker_delete_channel，通知为该通道工作的ngx worker诛九族（清理该channel的订阅者、存储信息等系统资源） 
（4）处决 
        执行周期性内存清理时，除了ngx_http_push_stream_collect_expired_messages_and_empty_channels外，还会执行ngx_http_push_stream_free_memory_of_expired_messages_and_channels将过期的channel彻底删除；未过期的channel仍处于死缓状态

3.MSG的生成周期

（0）、初始（诞生） 
        发布消息时产生，同时预设其死亡时间（如果配置中设定msg_ttl则预设生命期为此值，否则 
（2）、死刑生存期为0——生成即死亡）；设定一个buffer清理定时器（默认为1s）来清理msg。 
（1）、死缓 
        诞生时即等死，在清理buffer时（默认设置为msg诞生1s后）将该消息标记为deleted，扔入messages_to_delete.queue；新队列超长则执行FIFO，最老的MSG判为死刑（标记为deleted，扔入messages_to_delete.queue）。 
（3）（4）执行 
        对于死缓信息，在下一次垃圾清理（ngx_http_push_stream_free_memory_of_expired_messages_and_channels）时将该过期msg彻底删除。对于死刑信息，在buffer清理定时器到期时将其清除