提公升實時任務時間確定性的三個建議
在實時系統開發中，保證時間確定性是非常重要的要求，一般可以通過減少關中斷，減少任務鎖等機制保證實時性。本文介紹了提公升實時任務時間確定性的三個重要的原則：避免進行io操作；避免動態記憶體申請；避免遞迴呼叫。
一. 避免進行io操作
在實時作業系統中，時常將檔案系統、串列埠等裝置都納入io系統的管理。io裝置分為塊裝置和字元裝置，這兩種裝置操作時的時間不確定性原因有所差異。
1. 塊裝置
檔案系統是一種典型的塊裝置。在io系統中，通過訊號量來保證對這些裝置訪問的獨占性。乙個實際的場景是：高優先順序任務a打斷了低優先順序任務b的執行並進行檔案系統讀寫，如果此時任務b在正在讀寫檔案系統，任務排程器會將任務b的優先順序提公升，等任務b盡快完成最小粒度的檔案操作，任務a才能得到執行。因此任務a的操作時間是不確定的。
檔案系統常見的儲存介質是flash或磁碟，對它們的操作時間也是不確定的。
2. 字元裝置
字元裝置，如串列埠tty、socket等，它們資料傳送都是有一定的速率的，如果向這樣的裝置快速寫入大量資料時，就會將傳送緩衝佔滿，如果任務需要寫入的資料量超過傳送緩衝空餘容量時，任務就會掛起，等到緩衝中的有足夠空間後，對io的寫操作才能返回，這就造成了任務執行時間的不確定。
一些函式的操作有可能和io操作相關聯，這些函式也不能在有實時性要求的任務中呼叫。比如printf，它會輸出到標準輸入輸出介面，如果標準輸出介面是串列埠tty，在呼叫printf時就有可能發生阻塞。進而造成任務執行時間不確定。
二. 避免動態記憶體申請
動態記憶體申請最常使用的演算法是「最先匹配」演算法。使用該演算法申請記憶體時，程式沿著記憶體塊鍊錶，找到第乙個能放下申請容量的記憶體塊時，就從該記憶體塊中分出指定容量的記憶體並返回指標。在乙個系統中，如果經過了多次記憶體動態申請和釋放，記憶體碎片會有很多，因此找到合適容量的時間是不確定的。
三. 避免遞迴呼叫
遞迴呼叫時，何時能夠達到中止條件是不完全確定的，這就造成了程式執行時間的不確定。另外，遞迴呼叫會使用到棧，如果遞迴次數過多，還會發生棧溢位的問題。因此，在實時系統中，要盡量避免遞迴呼叫。使用開源庫mini-xml解析xml檔案時，就需要使用到遞迴呼叫。
四. 結論
從上面的分析可知，避免進行io操作、避免動態記憶體申請和避免遞迴呼叫可以提公升實時任務的時間確定性。
實時任務頻寬控制
proc sys kernel sched rt runtimes us，預設 950000 proc sys kernel sched rt period us，預設 1000000 在使用該功能時，當實時任務的頻寬用盡時 sched rt runtime us 核心會將對應的實時執行佇列rt r...
實時任務 offset管理
背景 目前我們執行的實時任務基本上都是使用sparkstreaming,當然後面考慮使用最近比較火的flink，看了部分資料介紹後，我感覺sparkstreaming相對於flink，唯一的不足是，sparkstreaming在task排程上損耗了不少效能。flink還沒有深入研究內部實現，flin...
實時任務資料丟失
flink實時任務 從kafka集群讀取源資料 從redis定期全量拉取使用者白名單，然後進行廣播 源資料connect白名單資料，源資料根據白名單資料進行過濾處理 過濾處理完後的資料，http推送 寫redis 寫log等 上線驗證的時候，有些資料丟失，而且比較頻繁，分析可能原因 kafka源資料...