pcr專案中，上位機採用非同步readfile()的方法讀取下位hid資料。在讀取頁顯示資料時，會出現丟失某些行的現象。
分析原因如下：
readfile()函式不能直接讀取下位機的資料，和下位機hid通訊的是windows hid driver。driver根據下位機自定義hid描述符設定的時間，輪詢發出in包讀取下位機的資料，將讀到的資料暫存在dirver自身的buffer中。readfile()讀取資料是從driver的buffer中讀取。
參考：readfile 的呼叫不會引起裝置的任何反應，即 hid 裝置與主機之間的中斷 in 傳輸不與 readfile 打交道。實際上主機會在最大間隔時間（由裝置的端點描述符來指定）內輪詢裝置，發出中斷 in 傳輸的請求。「讀取」即意味著從某個 buffer 裡面取回資料，實際上這個 buffer 就是 hid 裝置驅動中的 buffer 。這個buffer 的大小可以通過 hidd_setnuminputbuffers 來改變。在 xp 上預設值是 32 （個報告）。
下位機傳送資料也是一樣：下位機程式將要傳送的資料傳送到自身usb_sie的buffer中（buffer大小等特性由選用的usb晶元決定）。
如果下位機的buffer個數小於12（pcr專案一頁的行數），當下位機程式連續發12行的資料時，如果上位機輪詢時間比下位機程式傳送每行的時間慢，那就會出現某些行的資料在下位機usb_sie buffer中被沖掉，造成丟失。
解決辦法：
1. 延長下位機程式向其usb_sie buffer傳送資料的時間，本例中在傳送完一行資料後加乙個時間delay。只要delay時間可以保證，下位機程式向其usb_sie buffer寫每行的時間大於上位機輪詢的時間，即可保證資料不會丟失。
2. 更改下位機usb_sie buffer的個數，如本例中將其更改為12，但這要根據usb晶元硬體實際情況決定，晶元支援才可。
總結：注意上位機hid driver buffer的個數是可以通過hidd_setnuminputbuffers 設定的，本例中要設的大於12，如小於12也會出現丟資料現象。
在pcr project中的buffer size部分，將上述的hid dirver buffer個數定義成常量hidbufsize 65，將readfile()和writefile()函式呼叫的buffer size定義成常量hidreportnum 130。
kafka資料丟失問題
1 消費端弄丟了資料 唯一可能導致消費者弄丟資料的情況，就是說，你那個消費到了這個訊息，然後消費者那邊自動提交了offset，讓kafka以為你已經消費好了這個訊息，其實你剛準備處理這個訊息，你還沒處理，你自己就掛了，此時這條訊息就丟咯。這不是一樣麼，大家都知道kafka會自動提交offset，那麼...
Kafka 資料丟失問題
kafka的ack機制 在kafka傳送資料的時候，每次傳送訊息都會有乙個確認反饋機制，確保訊息正常的能夠被收到，其中狀態有0,1，1。producer.type sync request.required.acks 1producer.type async request.required.ack...
Flume丟失資料的問題
在一些網路資料中有看到當flume的資料量達到70mb s以上時，就會出現丟失資料的情況。但是根據flume的架構原理，採用filechannel的flume是不可能丟失資料的，因為其內部有完善的事務機制 acid 這兩個環節都不可能丟失資料。唯一可能丟失資料的是channel採用memorycha...