有三個 es 索引: trade_state, trade_buyer, trade_seller ，各自同時監聽 trade_order 訊息，通過幾乎一樣的處理邏輯，更新索引裡的訂單資料。 又乙個索引對比任務，會在訂單訊息延遲 10 分鐘後將該條訊息重新放入，去比較這三個索引的訂單狀態資料。 發現少數訂單的 trade_buyer 在比較的時候總是狀態有些滯後，親自去查的時候，狀態又是對的，甚是奇怪。
由於資料對比不一致任務能夠及早發現問題和發出警告，而這個似乎屬於「誤報軍情」，因此甚為干擾。如果不是問題，需要找出其中的原因並消除它。
通過日誌發現 ： 假設時刻 t 訂單狀態更新為 state = 3，時刻 t+20s 更新為 state = 6， 那麼時刻 t+10min ，對比查詢到的 trade_buyer 的訂單狀態依然是 state = 3。怕是有什麼環節有梗，我打出了對比查詢時的 trade_buyer 索引裡的所有資料， state = 3 !
檢視 trade_buyer 的寫入日誌，明明在時刻 t+20s 已經成功寫入 state = 6 的日誌啊，應該覆寫了 state = 3 的資料才對，怎麼會又出現 state = 3 ？ es 同學懷疑是不是 state = 6 的訂單資料又被覆寫了。 然而，訂單狀態更新是有嚴格遞增的版本號更新控制的，不會從 state = 6 倒退到 state = 3（除非重新強制更新 db 裡的訂單狀態，但線上是不會有這種情況的）；而且，在 t+20s - t+10min 時刻之間，並沒有 trade_buyer state = 3 的寫入日誌，這個 state = 3 究竟是從**來的 ？ 真令人百思不得其解。
繼續仔細閱讀日誌內容，突然發現，查詢時的 trade_buyer 的 buyer_id 與寫入時的 buyer_id 不一樣。不會吧 ？ 於是我根據這兩個不同的 buyer_id 去 trade_buyer 索引裡搜尋這個訂單， 竟然兩個都有 ！ 其中必有蹊蹺。 於是，我去諮詢為什麼訂單的 buyer_id 會變化，確實有這樣的下單場景。
訂單的 buyer_id 會變化，就可以講通了： trade_buyer 是根據 buyer_id 分片的，根據不同的 buyer_id 及訂單號，查到的是不同的兩條訂單資料。 假設在 t 時刻狀態更新為 state = 3 , buyer_id = x , 而在 t+20s 時刻，buyer_id 已經變為了 y ，那麼， t+20s 更新的是 buyer_id = y 的那條訂單資料，而不是 buyer_id = x 的那條，也就是： buyer_id = y && state = 6, buyer_id = x && state = 3。 在 t+10min 延遲後的那條訊息與 t 的訊息是一樣的， buyer_id = x ，這樣，在 t+10min 進行對比查詢時拿到的是 buyer_id = x 的那條資料，也就是未更新的髒資料。真相大白 ！
解決方法也比較簡單：在對比查詢時，取最新的 buyer_id 而不是原來的那條訊息裡的 buyer_id 。
其實，對比程式也報告了 buyer_id 的不一致。但我總覺得難以置信，因此有意忽略了。沒想到，這不起眼的細節，正是解開問題的關鍵鑰匙 ！ 可見，細節不可忽視啊 ！
經此一事，我明白了：奇怪之事必有緣由 ！ 如果發現了難以置信的事情，也許已經離真相很近了。再走近一步步。 此外，不可放過不起眼的細節。
總有人辜負，總有人付出
小小和之延在一起的時候，愛的那麼痴狂，傾其所有的愛著。然而，蒼天總是喜歡開善良人的玩笑，讓陷入愛情的人從跌跌撞撞到相遇相愛和相知，最終走向分離。小小分手後抱著我一邊痛哭一邊大罵之延狼心狗肺。我聽了個大概，之延得到出國深造的機會，於是和小小分手，可恨的是他和小 我不會放棄這個機會，我們分手吧，你會有另...
奇怪奇怪的問題
由於需求，我自己寫了乙個mydialog extends dialog 在dialog裡面寫了乙個handler，用來更新dialog上的字。第二次更新介面，需要dialog比第一次變大點。可是dialog在activity裡面顯示，如果activity不掛後台的話，更新很正常。但是我把activi...
總有人會看懂
總有人會看懂你的朋友圈 在大城市裡生活了幾年後，我越來越覺得，表達情緒是一件很困難的事情，有時候明明很想說點什麼，大但話到了嘴邊，想了想，還是算了。哪怕是發一條吐槽向的朋友圈，也可能引起一系列的連鎖反應 有人說，乙個人成熟的標誌，是學會控制自己的情緒，但在這個被社交網路籠罩的世界裡，所謂的控制情緒，...