好程式設計師大資料培訓分享redis與kafka的區別，kafka與redis pub/sub之間較大的區別在於kafka是乙個完整的系統，而redis pub/sub只是乙個套件(utility)——沒有冒犯redis的意思，畢竟它的主要功能並不是pub/sub。
另外一點，redis 發布訂閱除了表示不同的 topic 外，並不支援分組，比如kafka中發布乙個東西，多個訂閱者可以分組，同乙個組裡只有乙個訂閱者會收到該訊息，這樣可以用作負載均衡。
redis，它首先是乙個記憶體資料庫，其提供的pub/sub功能把訊息儲存在記憶體中(基於channel)，因此如果你的訊息的永續性需求並不高且後端應用的消費能力超強的話，使用redis pub/sub是比較合適的使用場景。比如官網說提供的乙個網路聊天室的例子：模擬irc，因為channel就是irc中的伺服器。使用者發起連線，發布訊息到channel，接收其他使用者的訊息。這些對於永續性的要求並不高，使用redis pub/sub來做足矣。
而kafka是乙個完整的系統，它提供了乙個高吞吐量、分布式的提交日誌(由於提供了kafka connect和kafka streams，目前kafka官網已經將自己修正為乙個分布式的流式處理平台，這裡也可以看出kafka的野心：-)。除了p2p的訊息佇列，它當然提供pub/sub方式的訊息模型。而且，kafka預設提供了訊息的持久化，確保訊息的不丟失性(至少是大部分情況下)。另外，由於消費元資料是儲存在consumer端的，所以對於消費而言consumer被賦予極大的自由度。consumer可以順序地消費訊息，也可以重新消費之前處理過的訊息。這些都是redis pub/sub無法做到的。
redis pub/sub使用場景：
1. 訊息永續性需求不高
2. 吞吐量要求不高
3. 可以忍受資料丟失
4. 資料量不大
kafka使用場景：
上面以外的其他場景：）
1. 高可靠性
2. 高吞吐量
3. 永續性高
4. 多樣化的消費處理模型
好程式設計師大資料培訓技術分享 Hadoop集群同步
好程式設計師 分享 hadoop集群同步 分享 是技術突飛猛進的很好體驗 在 好程式設計師 學習大資料技術 開始學會了分享，班裡五十個人，每個人就能得到49份不同技術 每次到分享的時刻，總會收穫不同的想法.一 同步方式 選擇乙個機器，作為時間伺服器 這裡選擇hadoop01 所有的機器與這台集群時間...
好程式設計師大資料培訓分享 HBase知識點集中總結
hfile，hbase中keyvalue資料的儲存格式，hfile是hadoop的二進位制格式檔案，實際上storefile就是對hfile做了輕量級包裝，即storefile底層就是hfile。hlog file，hbase中wal write ahead log 的儲存格式，物理上是hadoop...
好程式設計師分享自學大資料入門乾貨
首先，提及大資料一詞的概念。大資料本質還在於資料，但是它有著新的特徵亮點。包括 資料 廣，資料格式多樣化 結構化資料 非結構化資料 excel檔案 文字檔案等 資料量大 最少也是tb級別的 甚至可能是pb級別 資料增長速度快等等。擴充套件講大資料的4個基本特徵，我們將進行下面額思考 1.資料 廣？廣...