## 臨時筆記 人無法同時把精力集中在多個地方，所以我現在應該集中精力放在后端，然后再來前端，各個擊破才是王道，不然徘徊不前，左右不是，這種處境很糟糕。 * * * * * 第一步實現系統，第二部就要開始做性能優化了，比如加索引 * * * * * 方案報價 價格 方案執行 價格（白總可以修改的價格） 新客戶：沒有做過廣告 || 沒拜訪記錄 “新/老”不是針對于個人，而是客戶屬性 白總分配行業給副總，副總就得到行業下的客戶，副總一下，包括副總都可以看到這些客戶。 * * * * * // 定時任務一分鐘執行一次。 // 執行時打一個點，上次的點如果不存在，則以90天前為點 // 再次執行時，獲取當前時間，到上一個點內的更新訂單，并再次打點 // 在分頁過程取的過程中，要發出多次請求，多次請求的參數時間區間是一樣的，也就是區間固定了，只是每次頁碼不同，首先明確這點很重要 // 此接口返回訂單列表的排序時按照最后更新時間倒序排序的 // 上面說過，訂單散落在時間線上，是有排序規則，并且更新時會向前移動的 // 這個很重要，這里面的細節是關鍵，包含了依據此接口同步訂單的基本原理 // 先來想一個問題，可能容易忽略的問題，訂單為什么會發生更新呢？它自己更新嗎？什么時候更新呢？ // 這是這個問題的關鍵，理解這個問題了，你就徹底理解這種根據最后時間（區間）增量查詢訂單的精髓了。 // 訂單之所以會更新是因為狀態發生變化了，它自己肯定不能自動更新，肯定是操作使它狀態發生改變，比如用戶支付，系統自動關閉等等，是這些操作改變了訂單狀態。 // 那這些操作在什么時候發生呢？這個操作時間也可以理解為訂單的最后更新時間，一般操作成功了就變更最后更新時間為當前操作時間。 // 事實是沒人知道這個操作在什么時候發生，你無法預測用戶什么時候取消訂單，什么時候支付。 // 毫無疑問，這個問題無解。 // 但我們換一個思路想一下，我們是不是可以確定這個操作只會發生在：{過去某一時刻的時間點，當前時間點}，這是毋庸置疑的吧，沒有會穿越未來做操作吧。 // 這有回到了區間問題。 // 還記得上面說到的 [向前推移的當前時間點]嗎，這個點劃過的足跡，都有可能是操作出現的位置，而宏觀傻上任何操作都不可能發生在過去或是未來，只在當前此時發生，這看似哲學的問題，揭示的是事物的基本原理。所以可以這樣理解，這個移動的時間點就是一只手，在向前移動的時候可能會把需要更新的訂單拉到當前位置，所有的操作都是這么發生的，訂單就是這樣被更新的。反復理解這句話，你就能明白這個理論的重要性。 // 當我們固定區間后，但是時間點還是在繼續向前移動，此時我們區間的訂單有可能被拉過去，也就是說，現在我們面臨的分頁問題不是傳統的total增多，而是減少，并且排序是不變的。 // 此時再去理解 “使用最后更新時間范圍增量同步時，必須采用倒序的分頁方式（從最后一頁往回取）才能避免漏單問題。” 這句話的含義就能理解了 // 如果我們服務器時間比拼多多慢的話，會導致區間落后，造成獲取訂單永遠延時，如果比拼多多快的話可能造成區間總是過前，導致總是取不到訂單，所以服務器時間只能慢不能快 // 我們不漏單核心原因： // 1. 接口返回數據是按照 最后更新時間倒序的，即： order_modify_at desc // 2. 從最后一頁往回取即表示是這樣處理數據的：order_modify_at asc ，即 早先變化的，先處理，比較符合邏輯 // 3. 區間為 過去時間 ~ 當前時間 之間，如果分頁過程中有訂單發生了變化，變化訂單就會向右脫離這個區間（注意不會在區間內移動，而是直接脫離），此時 total 減小 // 4. 分頁過程中 total 不可能增多的原因是，因為要增多，只能從左邊進入（新增訂單/訂單變化），但這是不可能的，因為沒有人能回到過去去下單和更新訂單 // 其實這樣來看的話，從第一頁和最后一頁開始取，對于漏單是沒有影響的，都可以。因為我們區間規則的原因決定了。 // 官方：“從最后一頁往回取才能不漏單”核心原因： // 務必盡早的處理久遠的訂單，因為它們更可能發生更新（會脫離區間）。 // ！！！！！！！為了防止時間快了，這里左區間每次都向后擴展慢1分鐘，模擬服務器時間比拼多多慢（暫不需要這樣） ---- last update：2017-6-30 23:53:06