揚帆起航 繼續前進4
熱數據的處理（統計分析-->storm、spark） 緩存雪崩的時的系統可用性和穩定性(hystrick)
zookeeper 分佈式鎖
1.什麼是storm
mysql：TB、PB數據，尷尬 數據量太大怎麼辦？ 分佈式mysql
hadoop:海量數據，分佈式存儲、分佈式計算，最終計算結果彙總 ---->非實時性，當下性能消耗低
每天將所有的數據收集起來，第二天凌晨統一批量計算
離線處理，批量計算
storm:每一條數據立即計算，實時計算技術
國內技術JStorm 阿里的
特點：實時項目、擴容方便、數據不丟失、重複計算、穩定性和可用性很高、使用便捷
storm集羣架構：nimbus（集羣架構的主節點）、supervisor、worker、executor、task
任務分割
storm核心概念：Topology：spout+bolt 拓撲 幾個wroker
Spout：數據源的代碼組件 幾個excutor，幾個task
bolt：一個業務處理組件，spout會將數據傳遞給bolt，各種bolt還可以串聯成一個計算鏈條 幾個excutor，幾個task
tuple：就是一條數據
stream：一個流，源源不斷的tuple形成stream
並行度和流分組：
並行度是task，每個bolt，spout副本運行在task下
流分組：task數據與數據之間的流向
流分組策略：shuffle Grouping: 隨機發射，負載均衡
Fields Grouping:根據一個fileds，或者多個
2.實踐
實戰：純手工WordCount
storm集羣的搭建，以及項目的部署。。。。
建議博客：https://www.cnblogs.com/hd3013779515/p/6961293.html
zookeeper集羣：
server.0=172.16.55.131:2888:3888
server.1=172.16.55.132:2888:3888
server.2=172.16.55.133:2888:3888
export PATH=.:$STORM_HOME/bin:$PATH
storm.zookeeper.servers:
- "eshop-cache01"
- "eshop-cache02"
- "eshop-cache03"
3.深入理解storm的可靠性
完全處理：完全處理的意思是該MessageId綁定的源Tuple以及由該源Tuple衍生的所有Tuple都經過了Topology中每一個應該到達的Bolt的處理。
Acker組件的任務就是跟蹤從某個task中的Spout流出的每一個messageId所綁定的Tuple樹中的所有Tuple的處理情況。
多個源Tuple可以共用同一個MessageId，表示這多個源Tuple對用戶來說是同一個消息單元，它們會被放到同一棵tuple樹中，
aker 是怎麼知道每一個spout tuple交給哪個task處理？
當一個spout發射一個新的tuple， 它會簡單的發一個消息給一個合適的acker，並且告訴acker它自己的id(taskid)， 這樣storm就有了taskid-tupleid的對應關係。 當acker發現一個樹完成處理了， 它知道給哪個task發送成功ack的消息，否則fail
aker的高效：
顯示更總tuple樹太消耗資源
tuplid一直亦或，到0，說明結束了
亦或瞭解下：
0 ^ first
^ first ^second
^second ^third
......
^last = 0
storm怎麼怎麼避免數據的丟失：
- 由於對應的task掛掉了，一個tuple沒有被ack： storm的超時機制在超時之後會把這個tuple標記爲失敗，從而可以重新處理。
- Acker掛掉了： 這種情況下由這個acker所跟蹤的所有spout tuple都會超時，也就會被重新處理。
- Spout掛掉了： 在這種情況下給spout發送消息的消息源負責重新發送這些消息。比如Kestrel和RabbitMQ在一個客戶端斷開之後會把所有”處理中“的消息放回隊列。
調整可靠性：
去掉可靠性，減少跟蹤的損耗：Config.TOPOLOGY_ACKERS 設置成 0；發射tuple的時候不指定messageid來達到不跟蹤某個特定的spout tuple的目的
吞吐量不達標，可以增加acker