tl;dr: 當不想一遍又一遍地建立生產者( producer )時，你需要熱的 observable 。
// 冷的
var cold = new observable((observer) => );複製**
// 熱的
var producer = new producer();
var hot = new observable((observer) => );複製**
observables 是將觀察者和生產者聯絡起來的函式。僅此而已。它們並不一定要建立生產者，它們只需建立觀察者來監聽生產者，並且通常會返回乙個拆卸機制來刪除該***。
生產者是 observable 值的**。它可以是 web socket、dom 事件、迭代器或在陣列中迴圈的某種東西。基本上，這是你用來獲取值的任何東西，並將它們傳遞給observe.next（value）。
如果底層的生產者是在訂閱期間建立並啟用的，那麼 observable 就是「冷的」。這意味著，如果 observables 是函式，而生產者是通過呼叫該函式建立並啟用的。
建立生產者
啟用生產者
開始監聽生產者
單播 下面的示例 observable 是「冷的」，因為它在訂閱函式(在訂閱該 observable 時呼叫)中建立並監聽了 websocket :
const source = new observable((observer) => );複製**source的訂閱都會得到自己的 websocket 例項，當取消訂閱時，它會關閉 socket 。這意味著source是真正的單播，因為生產者只會傳送給乙個觀察者。這是用來闡述概念的基礎 jsbin 示例。
如果底層的生產者是在 訂閱¹ 外部建立或啟用的，那麼 observable 就是「熱的」。
共享生產者的引用
開始監聽生產者
多播(通常情況下²)
如果我們沿用上面的示例並將 websocket 的建立移至 observable 的外部，那麼 observable 就會變成「熱的」:
const socket = new websocket('ws://someurl');
const source = new observable((observer) => );複製**
source的訂閱都會共享同乙個 websocket 例項。它實際上會多播給所有訂閱者。但還有個小問題: 我們不再使用 observable 來執行拆卸 socket 的邏輯。這意味著像錯誤和完成這樣的通知不再會為我們來關閉 socket ，取消訂閱也一樣。所以我們真正想要的其實是使「冷的」 observable 變成「熱的」。這是用來展示基礎概念的 jsbin 示例。
從上面展示冷的 observable 的第乙個示例中，你可以發現所有冷的 observables 可能都會些問題。就拿一件事來說，如果你不止一次訂閱了 observable ，而這個 observable 本身建立一些稀缺的資源，比如 websocket 連線，你不想一遍又一遍地建立這個 websocket 連線。實際上真的很容易建立了乙個 observable 的多個訂閱而卻沒有意識到。假如說你想要在 websocket 訂閱外部過濾所有的「奇數」和「偶數」值。在此場景下最終你會建立兩個訂閱:
source.filter(x => x % 2 === 0)
.subscribe(x =>
console.log('even', x));
source.filter(x => x % 2 === 1)
.subscribe(x =>
console.log('odd', x));複製**
它是 observable 。它的結構類似 observable 並擁有 observable 的所有操作符。
它是 observer 。它作為 observer 的鴨子型別。當作為 observable 被訂閱時，將作為 observer 發出next的任何值。
它是多播的。所有通過subscribe()傳遞給它的 observers 都會被新增到內部的觀察者列表。
當它完成時，就是完成了。subjects 在取消訂閱、完成或發生錯誤後無法被復用。
它通過自身傳遞值。需要重申下第2點。如果next值給它，值會從它 observable 那面出來。
rx 中的 subject 之所以叫做 「subject」 是因為上面的第3點。在 gof (譯註: 大名鼎鼎的《設計模式》一書) 的觀察者模式中，「subjects」 通常是有addobserver的類。在這裡，我們的addobserver方法就是subscribe。這是用來展示 rx subject 的基礎行為的 jsbin 示例。
了解了上面的 rx subject 後，我們可以使用一些功能性的程式將任何「冷的」 observable 變成「熱的」:
function
makehot(cold) 複製**
makehot接收任何冷的 observable 並通過建立由所得到的 observable 共享的 subject 將其變成熱的。這是用來演示 jsbin 示例。
還有一點問題，就是沒有追蹤源的訂閱，所以當想要拆卸時該如何做呢？我們可以新增一些引用計數來解決這個問題:
function
makehotrefcounted(cold) ;
});}複製**
refs會變成0，我們將取消冷的源 observable 的訂閱。這是用來演示的 jsbin 示例。
你可能不應該使用上面提及的任何makehot函式，而是應該使用像publish()和share()這樣的操作符。將冷的 observable 變成熱的有很多種方式和手段，在 rx 中有高效和簡潔的方式來完成此任務。關於 rx 中可以做此事的各種操作符可以寫上一整篇文章，但這不是文字的目標。本文的目標是鞏固概念，什麼是「熱的」和「冷的」 observable 以及它們的真正意義。
在 rxjs 5 中，操作符share()會產生乙個熱的，引用計數的 observable ，它可以在失敗時重試，或在成功時重複執行。因為 subjects 一旦發生錯誤、完成或取消訂閱，便無法復用，所以share()操作符會重複利用已完結的 subjects，以使結果 observable 啟用重新訂閱。
這是 jsbin 示例，演示了在 rxjs 5 中使用share()將源 observable 變熱，以及它可以重試。
鑑於上述一切，人們能夠看到 observable 是怎樣的，它只是乙個函式，實際上可以同時是「熱的」和「冷的」。或許它觀察了兩個生產者？乙個是它建立的而另乙個是它復用的？這可能不是個好主意，但有極少數情況下可能是必要的。例如，多路復用的 websocket 必須共享 socket ，但同時傳送自己的訂閱並過濾出資料流。
如果在 observable 中復用了生產者的共享引用，它就是「熱的」，如果在 observable 中建立了新的生產者，它就是「冷的」。如果兩者都做了…。那它到底是什麼？我猜是「暖的」。
注釋¹ (注意: 生產者在訂閱內部「啟用」，直到未來某個時間點才「建立」出來，這種做法是有些奇怪，但使用**的話，這也是可能的。) 通常「熱的」 observables 的生產者是在訂閱外部建立和啟用的。
² 熱的 observables 通常是多播的，但是它們可能正在監聽乙個只支援乙個***的生產者。在這一點上將其稱之為「多播」有點勉強。
Hadoop的冷備 熱備
冷備份 hadoop1.x namenode 主 secondarynamenode 從 在hadoop1.x中，secondarynamenode會按照時間閾值 比如24小時 或者edits日誌大小閾值 比如1g 週期性的將fsimage和edits合併成新的fsimage並替換，然後將最新的fs...
Oracle的冷備份和熱備份
一 冷備份 冷備份發生在資料庫已經正常關閉的情況下，當正常關閉時會提供給我們乙個完整的資料庫。冷備份時將關鍵性檔案拷貝到另外的位置的一種說法。對於備份oracle 資訊而言，冷備份時最快和最安全 的方法。冷備份的優點是 是非常快速的備份方法 只需拷檔案 容易歸檔 簡單拷貝即可 容易恢復到某個時間點上...
關於冷備份與熱備份的對比
一 冷備份 冷備份發生在資料庫已經正常關閉的情況下，當正常關閉時會提供給我們乙個完整的資料庫。冷備份時將要害性檔案拷貝到另外的位置的一種說法。對於備份oracle資訊而言，冷備份時最快和最安全的方法。冷備份的優點是 是非常快速的備份方法 只需拷檔案 輕易歸檔 簡單拷貝即可 輕易恢復到某個時間點上 只...