Back Pressure是流處理系統(tǒng)中递胧，非常經(jīng)典常見(jiàn)的問(wèn)題屈张，它是讓流系統(tǒng)能對(duì)壓力變化能夠呈現(xiàn)良好抗壓性的關(guān)鍵所在
各個(gè)開(kāi)源實(shí)時(shí)處理系統(tǒng)官疲，在中后期泳叠，都開(kāi)始有對(duì)背壓機(jī)制有完善的考慮和設(shè)計(jì)耀怜，基本原理一致恢着。實(shí)現(xiàn)方式各有千秋。
舉例Spark Streaming
這句話(huà)怎么理解财破？掰派？？
首先左痢，服務(wù)中心的服務(wù)能力是有限的靡羡，要處理的事件時(shí)多時(shí)少，資源浪費(fèi)?資源不夠?
在系統(tǒng)架構(gòu)設(shè)計(jì)中俊性，要思考2個(gè)問(wèn)題：
1略步、服務(wù)中心要抗住峰值事件（max問(wèn)題）
2、這些事件如何有效被服務(wù)中心分配消費(fèi)（match問(wèn)題）
常用經(jīng)典的排隊(duì)理論定页，可以解決max問(wèn)題趟薄，服務(wù)中心不會(huì)被壓垮，
為了服務(wù)中心能正常服務(wù)典徊，就需要多維護(hù)一個(gè)隊(duì)列
- 原來(lái)只維護(hù)一個(gè)東西杭煎，就是服務(wù)中心
- 現(xiàn)在維護(hù)兩東西，一個(gè)服務(wù)中心卒落，一個(gè)隊(duì)列
體現(xiàn)這種設(shè)計(jì)理念的經(jīng)典設(shè)計(jì)模式之一(理論=> 模式)羡铲，生產(chǎn)者-消費(fèi)者模式
但match問(wèn)題沒(méi)解決，根本目的：
你事件多儡毕，我給資源多也切，處理能力夠
你事件少，我給資源少，處理能力夠
總結(jié)一句話(huà)就是 合適最重要
為了解決match問(wèn)題,業(yè)界提出Reactive Stream的設(shè)計(jì)模式雷恃，生產(chǎn)者-消費(fèi)者模式 + 迭代器
消費(fèi)者告訴生產(chǎn)者消費(fèi)數(shù)量疆股，服務(wù)中心每個(gè)機(jī)器能吃多少飯，都是已知的褂萧，如果量大押桃，吃不下，Spark就會(huì)動(dòng)態(tài)調(diào)節(jié)（動(dòng)態(tài)Executor模型）,但怎么個(gè)調(diào)法导犹？這個(gè)時(shí)候背壓的概念和設(shè)計(jì)就出來(lái)了
背壓就是背能背的起壓力唱凯，從input到output，上游總給下游可承受的量谎痢，難點(diǎn)就是上游要知道下游能背多少磕昼？？节猿？
SparkStreaming
基于SparkCore提供micro-batch處理的實(shí)時(shí)流式處理框架票从，就是批處理的批是很小的一批，
這個(gè)小批叫DStream（數(shù)據(jù)流 -> 轉(zhuǎn)成DStream -> RDD機(jī)制處理）
SparkCore = Driver + Executor
上圖是SparkStreaming的系統(tǒng)核心模塊滨嘱，和背壓特性相關(guān)的峰鄙，主要是模塊3：數(shù)據(jù)的產(chǎn)生和導(dǎo)入。
基于前面的排隊(duì)理論太雨，Spark Streaming每一批次的處理時(shí)長(zhǎng)（batch_process_time）需要小于批次間隔batch_interval吟榴，否則batch_process_time > batch_interval，程序的處理能力不足囊扳，積累的數(shù)據(jù)越來(lái)越多吩翻，最終會(huì)造成Executor的OOM。
Spark Steaming從1.5版本開(kāi)始锥咸，開(kāi)始引入背壓機(jī)制狭瞎，第一個(gè)相關(guān)問(wèn)題是經(jīng)典的SPARK-7398。其大體的思路是：
通過(guò)在Driver端進(jìn)行速率估算搏予，并將速率更新到Executor端的各個(gè)Receiver熊锭，從而實(shí)現(xiàn)背壓
1、速率控制
2雪侥、速率估算
3球涛、速率更新
- 速率控制
整個(gè)背壓機(jī)制的核心，就是Drvier端的RateContoller校镐，它作為控制核心，繼承自StreamingListener捺典，監(jiān)聽(tīng)Batch的完成情況鸟廓，記錄下它們的關(guān)鍵延遲，然后傳遞給computeAndPublish方法，遍歷Executor并進(jìn)行估算和更新
- 速率估算
PIDRateEstimator是目前RateEstimator的唯一官方實(shí)現(xiàn)引谜，基本上也沒(méi)誰(shuí)去重新實(shí)現(xiàn)一個(gè)牍陌，因?yàn)榇_實(shí)好用。PID(Proportional Integral Derivative员咽，比例積分差分控制算法)是工控領(lǐng)域中毒涧，經(jīng)過(guò)多次的驗(yàn)證是一種非常有效的工業(yè)控制器算法。Spark Streaming將它引入贝室，作為根據(jù)最新的Rate契讲，以及比例（Proportional) 積分（Integral）微分（Derivative）這3個(gè)變量，來(lái)確定最新的Rate滑频，實(shí)現(xiàn)簡(jiǎn)潔明了捡偏，也非常好理解。
- 速率更新
計(jì)算完新Rate峡迷，就該把它發(fā)布出去了银伟。RateController通過(guò)ReceiverTracker，利用RPC消息绘搞，發(fā)布Rate到Receiver所在的節(jié)點(diǎn)上彤避，該節(jié)點(diǎn)上的ReceiverSupervisorImpl會(huì)接收消息，并把速率更新到BlockGenerator上夯辖，從而以控制每個(gè)批次的數(shù)據(jù)生成琉预。
仔細(xì)閱讀這兩個(gè)類(lèi)的代碼，可以發(fā)現(xiàn)它們充分利用了Scala的特性和高性能網(wǎng)絡(luò)通信庫(kù)楼雹，非常的簡(jiǎn)潔模孩，一點(diǎn)都不拖泥帶水。無(wú)論是發(fā)送端的UpdateRateLimit的case class消息類(lèi)構(gòu)建贮缅，還是接收端的receive的偏函數(shù)特性榨咐，都充分的體現(xiàn)了Scala的代碼之美。
參考資料
xxx
