red5伺服器搭建

『壹』 視頻會議中使用的錄播伺服器工作原理/流程是如何的

先將本地音視頻採集後，編碼、混流、發送到流媒體伺服器上，然後其它要接收的參會人員從流媒體伺服器上直播當前的數據；
自己可能用下列軟體搭個平台試試就知道了；
Adobe Media Encoder CS4（採集，編碼，發送功能）
RED5 FLV流媒體伺服器，它有幾個DEMO，你運行後打開頁面看下，發布，訂閱就明白了。

『貳』 linux 下怎麼解決red5 的內存溢出

Red5作為多媒體的開源的框架，實現了RTMP協議，完成了視頻，音頻和多媒體數據的傳輸和解析，很多的產品都在使用它。我們同樣在用他們的服務，但是遇到一個內存泄漏的問題，這個內存泄漏是如何發現的呢：

現象：伺服器跑了兩天左右，出現了兩種情況 ：
1.內存溢出
2.內存沒有溢出，但是提供不了任何服務，伺服器不能接收任何request

分析：
1.擴大虛擬機的內存，結果伺服器跑長了點時間，照樣內存溢出
2.Dump出Heap快照，並用Eclispse Memory Analyzer進行分析，發現RTMPMinaConnection對象大量存在ConcurrentHashMap對象裡面，為什麼會出現大量的connnection？即使是大量的客戶端請求，為什麼內存沒有釋放？
3.分為三個問題考慮：
1)為什麼會出現大量的connnection？連接從哪裡來的
2)大量的connection為什麼會沒有釋放？
3)為什麼connection達到一定的數量，伺服器即使在內存充裕的情況下，仍然提供不了任何服務？

根據大量的觀測，發現red5 伺服器，我們用Haproxy代理了rtmp請求，而HA即使沒有請求的情況下，仍然試圖連接，以探測代理的伺服器是否存活，而red5的keepalive時間一過，會試圖關閉連接，關閉之後，通過查看源代碼發現，connection雖然關閉了，但是沒有從concurrentHashupMap裡面remove掉，而真是這種Ha的不停的通過創建心跳連接來探測red5是否處於活的狀態，而red5關閉連接之後，並沒有從concurrentHashMap裡面移除，從而造成了最終的內存溢出，同時由於沒有移除inactive的連接達到了red5設定的最大的允許的inactivity連接的數量，默認為60000個連接，從而造成我們剛才看到的現象-即使內盯渣存充裕的情況下，仍然提供不了任何服務的情況。

查找這個錯誤的過程是痛苦的，甚至沒有一點頭緒，還好通過大量的測試和源代碼分析，發現了這個問題。我們現在已經升級到red5 0.9.1的版本了，目前情況良好，同時為了確保伺服器的穩定性，我們也查閱了相關的源代碼，可以確定0.9.1版本中已經fix了這個問題。相信red5 server在我們的產品上線後會處於非常穩定的狀態。

發現這個問題，一些工具的使用是關鍵的：
首先，要會分析heap快照，而eclipse memory analyzer確實是很強大的工具。幫我們提供了大量有用的信息核則首。
其次，開源軟體是不可靠的，只有我們對它們的代碼有深入的分析才會得出好的結果。還好，源代碼開放也為我們提供了查找問題來龍去脈的根據。而我們也可以對開源軟體進行優化，在以後的內容里，我也會記錄我們優化red5 server的整個過程，相信還有很多地方，我們仍然可改數以優化它。

網上找的~~