太卷！Redmi MAX 100英寸電視便宜了：12999元買Redmi史上最大屏
8月5日消息，從小米商城了解到，Redmi MAX 100英寸巨屏電視日前迎來官方優惠，到手價12999元，比發布價便宜了7000元，在大屏電視市場開卷。據了解，Redmi MAX 100
往期文章在熱點數據如何更新的一篇文章中有提到對賬系統。其實我在實際業務場景中是有遇到過類似對賬的優化問題的。說優化之前要掌握一點就是一定要掌握Java并發包的相關特性。本章節對此有很大依賴。
inventory hint,解決熱點數據如何高效更新
CountDownLatch:
經典案例比如門衛休息休要等所有人下班才可以關門休息 CyclicBarrier：
經典案例：比如運動員跑步，需要所有人準備好之后裁判才可以發令讓大家在同一時刻去跑。有依賴關系
有一天，老大匆忙趕來，提到對賬系統最近變得越來越緩慢，希望能迅速進行優化。經過了解對賬系統的業務流程，發現其實相當簡單：用戶通過在線商城下單會生成電子訂單并存儲在訂單數據庫中；隨后物流會生成派送單用于發貨，派送單則保存在派送單庫中。為了避免漏發或重復派送，對賬系統每天會核查是否存在異常訂單。
目前對賬系統的處理邏輯很簡單：首先查詢訂單，然后查詢派送單，接著比對訂單和派送單，將差異記錄寫入差異庫。對賬系統的核心代碼經過抽象后，也并不復雜，主要是在單線程中循環執行訂單和派送單的查詢，進行對賬操作，最后將結果寫入差異庫。
while(存在未對賬訂單){ // 查詢未對賬訂單 pos = getPOrders(); // 查詢派送單 dos = getDOrders(); // 執行對賬操作 diff = check(pos, dos); // 差異寫入差異庫 save(diff);}首先要找出對賬系統的瓶頸所在。目前，由于訂單量和派送單量龐大，導致查詢未對賬訂單 getPOrders() 和查詢派送單 getDOrders() 的速度較慢。是否有一種快速優化的方法呢？目前對賬系統是單線程執行的。對于這樣的串行系統，優化性能的第一個想法是能否利用多線程并行處理。
因此，我們可以看出對賬系統的瓶頸在哪里：查詢未對賬訂單 getPOrders() 和查詢派送單 getDOrders() 是否能夠并行處理呢？很顯然，這兩個操作之間并沒有依賴關系。將這兩個耗時操作并行化后，與單線程執行相比，您會發現在相同時間段內，并行執行的吞吐量接近單線程的兩倍，優化效果頗為明顯。
有了這個思路，接下來我們看看如何用代碼實現。在下面的代碼中，我們創建了兩個線程 T1 和 T2，分別并行執行查詢未對賬訂單 getPOrders() 和查詢派送單 getDOrders() 的操作。主線程則負責執行對賬操作 check()和將差異寫入 save() 的操作。值得注意的是：主線程需要等待線程 T1 和 T2 執行完畢后才能執行 check() 和 save() 這兩個操作。為此，我們通過調用 T1.join() 和 T2.join() 實現等待，當線程 T1 和 T2 結束時，調用了 T1.join() 和 T2.join() 的主線程將從阻塞狀態中解除，隨后執行后續的 check() 和 save() 操作。
while(存在未對賬訂單){ // 查詢未對賬訂單 Thread T1 = new Thread(()->{ pos = getPOrders(); }); T1.start(); // 查詢派送單 Thread T2 = new Thread(()->{ dos = getDOrders(); }); T2.start(); // 等待 T1、T2 結束 T1.join(); T2.join(); // 執行對賬操作 diff = check(pos, dos); // 差異寫入差異庫 save(diff);}經過上述優化，基本上可以向老板報告工作完成了，但仍有一些遺憾之處。我相信您也已經注意到了，在 while 循環中每次都會創建新的線程，而創建線程是一個耗時的操作。因此，最好能夠重復利用已創建的線程。您想到了線程池，確實，線程池能夠解決這個問題。
通過線程池進行優化后：我們首先創建了一個固定大小為2的線程池，并在 while 循環中重復利用這些線程。一切看起來都進行得很順利，但似乎有一個問題無法解決，即主線程如何知道 getPOrders() 和 getDOrders() 這兩個操作何時執行完成。在前面的方案中，主線程通過調用線程 T1 和 T2 的 join() 方法來等待它們退出，但是在線程池方案中，線程根本就不會退出，因此 join() 方法失效了。
那么，如何解決這個問題呢？您可以想出許多方法，其中最直接的方法是使用一個計數器。將其初始值設為2，執行完 pos = getPOrders(); 后減 1，執行完 dos = getDOrders(); 后也減 1。主線程在這之后等待計數器等于0；當計數器等于0時，說明這兩個查詢操作已執行完畢。等待計數器為0實際上是一種條件變量，使用管程實現起來也并不復雜。
然而，我并不建議在實際項目中實施上述方案，因為Java并發包中已經提供了類似功能的工具類：CountDownLatch，我們直接使用即可。在下面的代碼示例中，我們在 while 循環中首先創建了一個CountDownLatch，計數器的初始值為2。在 pos = getPOrders(); 和 dos = getDOrders(); 兩個語句后，通過調用 latch.countDown(); 實現對計數器的減1操作。在主線程中，通過調用 latch.await(); 實現對計數器等于0的等待。
// 創建 2 個線程的線程池Executor executor = Executors.newFixedThreadPool(2);while(存在未對賬訂單){ // 計數器初始化為 2 CountDownLatch latch = new CountDownLatch(2); // 查詢未對賬訂單 executor.execute(()-> { pos = getPOrders(); latch.countDown(); }); // 查詢派送單 executor.execute(()-> { dos = getDOrders(); latch.countDown(); }); // 等待兩個查詢操作結束 latch.await(); // 執行對賬操作 diff = check(pos, dos); // 差異寫入差異庫 save(diff);}經過以上一系列的優化，終于可以松一口氣，準備交付項目。然而，在交付之前，再次審視一番是值得的，或許還存在優化的空間。
前面我們已經實現了將 getPOrders() 和 getDOrders() 這兩個查詢操作并行化，但是這兩個查詢操作與對賬操作 check() 和 save() 之間仍然是串行執行的。很顯然，這兩個查詢操作與對賬操作也可以并行執行，即在執行對賬操作的同時可以進行下一輪的查詢操作。
接下來，我們再思考如何實現這一優化。兩次查詢操作能夠與對賬操作并行執行，而對賬操作又依賴于查詢操作的結果，這明顯具有生產者-消費者模型的特征。兩次查詢操作充當生產者，對賬操作為消費者。為了實現這種模型，我們需要一個隊列來存儲生產者產生的數據，消費者則從隊列中取出數據執行相應操作。
針對這個對賬項目，我設計了兩個隊列，其元素之間存在對應關系。具體來說，訂單查詢操作將訂單查詢結果插入訂單隊列，派送單查詢操作將派送單插入派送單隊列，這兩個隊列的元素之間是一一對應的。使用兩個隊列的好處在于，對賬操作可以每次從訂單隊列取出一個元素和派送單隊列中取出一個元素，然后執行對賬操作，確保數據的一致性。
接下來，讓我們看看如何通過雙隊列實現完全并行化。一個直接的思路是：一個線程 T1 執行訂單查詢工作，另一個線程 T2 執行派送單查詢工作。當線程 T1 和 T2 都各自生產完一條數據時，通知線程 T3 執行對賬操作。這一想法看似簡單，實際上仍然存在一個條件：T1 和 T2 的工作節奏必須一致，保持同步，否則一個快一個慢將影響各自生產數據并通知 T3 的過程。
只有在T1和T2各自生產完一條數據時才能繼續執行，也就是說，T1和T2需要相互等待，保持步調一致。同時，當T1和T2都生產完一條數據時，還需能夠通知T3執行對賬操作。
接下來我們將實現上述方案中提到的方法。該方案的難點在于兩個方面：一是確保線程 T1 和 T2 的步調一致，二是能夠有效通知線程 T3。
在解決這兩個難點的過程中，仍然可以利用一個計數器。將計數器初始化為2，每當線程 T1 和 T2 生產完一條數據時，都將計數器減1。若計數器大于0，則線程 T1 或 T2需要等待。當計數器等于0時，通知線程 T3，喚醒等待的線程 T1 或 T2，并將計數器重置為2。如此，線程 T1 和 T2 在生產下一條數據時，可以繼續使用這個計數器。
建議不要在實際項目中直接實現這一邏輯，因為Java并發包中已經提供了相關的工具類：CyclicBarrier。在下面的代碼中，我們首先創建了一個初始值為2的CyclicBarrier計數器。需要注意的是，在創建CyclicBarrier時，傳入了一個回調函數。當計數器減至0時，該回調函數會被調用。
線程 T1 負責查詢訂單，每查到一條數據，調用barrier.await()將計數器減1，并等待計數器變為0。線程 T2 負責查詢派送單，處理方式與線程 T1 類似。當 T1 和 T2 都調用barrier.await()時，計數器會減至0，此時 T1 和 T2可以繼續執行下一步操作，并調用barrier的回調函數執行對賬操作。
值得一提的是，CyclicBarrier的計數器具有自動重置功能。當計數器減至0時，會自動重新設定為您設置的初始值。這一特性確實方便實用。
// 訂單隊列Vector<P> pos;// 派送單隊列Vector<D> dos;// 執行回調的線程池 Executor executor = Executors.newFixedThreadPool(1);final CyclicBarrier barrier = new CyclicBarrier(2, ()->{ executor.execute(()->check()); }); void check(){ P p = pos.remove(0); D d = dos.remove(0); // 執行對賬操作 diff = check(p, d); // 差異寫入差異庫 save(diff);} void checkAll(){ // 循環查詢訂單庫 Thread T1 = new Thread(()->{ while(存在未對賬訂單){ // 查詢訂單庫 pos.add(getPOrders()); // 等待 barrier.await(); } }); T1.start(); // 循環查詢運單庫 Thread T2 = new Thread(()->{ while(存在未對賬訂單){ // 查詢運單庫 dos.add(getDOrders()); // 等待 barrier.await(); } }); T2.start();}CountDownLatch 和 CyclicBarrier 是Java并發包提供的兩個非常便捷的線程同步工具類。在這里，有必要再次強調它們之間的區別：CountDownLatch 主要用于解決一個線程等待多個線程的情況，可以類比于旅游團團長必須等待所有游客齊集后才能繼續前行；而CyclicBarrier 則是一組線程相互等待，有點像幾個驢友之間的互助合作。此外，CountDownLatch 的計數器不支持重復利用，即一旦計數器降至0，后續調用await()的線程將直接通過。相比之下，CyclicBarrier 的計數器可以循環利用，同時具有自動重置功能，一旦計數器減至0，將會自動重置為設定的初始值。此外，CyclicBarrier 還支持設置回調函數，功能更加豐富。
本文鏈接：http://m.www897cc.com/showinfo-26-84007-0.html電商真實對賬系統是如何設計并優化的
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號