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清理定时器到期时将其清除