項目實際開發過程中，往往有很多場景需要設計實現。而且如果設計不得當，後期會出現很多問題，甚至有可能會導致項目延期或者失敗。今天給大家介紹我們項目的幾個應用場景，當然不一定是最完美的方案，童鞋們一定要根據實際情況酌情處理。
想學習分佈式、微服務、JVM、多線程、架構、java、python的童鞋，千萬不要掃碼，否則後果自負~
應用場景：
1.用戶分潤結算場景：
業務背景： 用戶可以將自己的積分存入積分寶（類餘額寶），平臺每天凌晨需要給用戶結算，前一天的分潤金額。
技術實現： 通過elastic-job分佈式調度框架來實現分佈式定時任務，因爲涉及到整個平臺的用戶積分的分潤，用戶量大的情況下面，可能會有海量的數據，如果只在一臺機器上面執行的話，耗時又耗力，通過將任務均勻的分配到不同的服務器上面，可以有效的解決類似的問題，後期也可以通過增加服務器來橫向擴容。
2.商品首頁過期數據處理：
業務背景： app商品首頁的數據是通過後臺配置的，但是這些配置的商品有可能會被下架或者刪除，所以需要及時清理掉這些失效的數據。
技術實現： 因爲需要循環遍歷首頁配置的商品列表，如果是實時同步的話，會影響性能，所以這邊採用定時任務的方式，定期清理過期的數據。這邊需要注意的是：因爲數據量比較少，只需要單個服務跑定時任務就可以了，但是生產中一個服務會部署多個實例，所以需要限制只在一個服務實例跑就可以了，否則就會重複跑相同的任務了。
3.es商品數據更新：
業務背景： app商品搜索有綜合排序功能，需要將用戶的銷售量、評論數、更新時間、好評率等綜合一起進行排序。
技術實現：
方案一： 在es商品表中增加一個用於綜合排序的字段，如果只是修改商品個別商品的銷售量、評論數、更新時間、好評率等，只需要發一個MQ消息，異步的去刷新es的商品數據（還有一種比較野蠻的方式，不管商品修改多少個，定期跑定時任務全量更新所有商品數據，但這樣太損耗性能了）。但是如果是排序的規則發生變化，則需要同步所有的es商品數據（所以儘量不要頻繁修改排序規則）。
方案二： es商品表中不增加額外的綜合排序字段，如果只是修改商品個別商品的銷售量、評論數、更新時間、好評率等，只需要發一個MQ消息，異步的去刷新es的商品數據（也可以將需要更新的商品數據先記錄下來，然後在用戶流量少的時刻，統一進行更新操作），如果是修改商品排序規則，則直接修改排序的公式，不需要修改任何的es數據。這種方案相對優於第一種方案。
4.商品數據庫數據和redis數據不一致
業務背景： app商品詳情頁面從redis獲取，運營後臺數據從數據庫中獲取，二者數據不一致。
技術實現： redis數據最害怕就是和數據庫不一致，因爲你不知到底是哪一條數據不一致。進行全量更新明顯不太現實，所以很多時候都是發現錯誤的時候，進行數據矯正。當然我們需要知道數據不一致的根源，如果數據庫操作在一個事務裏面，事務出錯回滾，redis沒有做相應的回滾處理，那肯定就會出現數據不一致。所以一定要保證數據庫更新操作和redis一致，出錯一起回滾，但是這種方式會增加系統的複雜度，有可能還是會出現問題，最好的方式是在修改數據的時候，直接清空redis數據，然後查詢的時候，如果數據不存在，就將數據同步到redis上面，這樣就會大大的提高安全性，又不會增加系統複雜度。
5.二維碼收款需要實時顯示付款信息
業務背景： 二維碼收款時候，收款方要實時顯示付款的結果給賣家。
技術實現：
方案一： app端不斷的進行接口請求，直到付款結果出來或者用戶退出二維碼收款碼頁面。這種方式缺點很明顯，損耗性能，如果同一時刻收款人數非常多，就會造成高併發，優點是技術實現成本低。
方案二： 通過長連接來實時顯示付款結果，比如用Netty、websocket、tcp之類的，這樣就可以避免第一種缺陷，不管同一時刻商家有多少個，都不會有併發的風險，但是技術實現難度會比第一種要大。
6.多個賬戶財務數據對應不上
業務背景： 用戶有積分分潤的賬戶、商品分銷收益的賬戶、用戶餘額的賬戶。其中分潤賬戶和分銷賬戶可以轉賬給餘額賬戶，餘額賬戶是可以真正提現的賬戶。每個賬戶都有自己的記錄表，但是各自的賬戶金額有些數據對應不上。
技術實現： 在設計的時候儘量將這些賬戶體系放在同一個服務中，這樣就不會有分佈式事務的問題了。如果實在不行，必須分爲多個服務，那就要保證數據先入一個服務，在插入到其它服務中，簡而言之就是要先保證有一個賬戶裏面的數據是對的，而且有交易流水日誌之類的。最重要的是要定期進行程序對賬，千萬不要等測試或者用戶反饋這些問題，要防患於未然。
7.多人審覈重複點擊產生多條數據
業務背景： 運營後臺進行數據審覈的時候，會發生多人同時審覈同一條記錄的情況，造成產生兩條數據的結果。
技術實現： 基於這種情況一般要做兩手準備，一個是在操作的時候需要加併發鎖（可以用redis鎖來控制），這樣可以保證在同一時間只有一個人在操作，但是一定要注意鎖的顆粒，千萬不要太大。第二步，在插入數據之前，要先查詢一遍，不要直接插入，保證數據庫沒有相同的數據。
8.用戶積分更新數據有誤
業務背景： 用戶購買商品成功之後，積分更新數據和這個商品設置的積分數據對應不上。
技術實現： 原因可能會有多個，一種可能是當時商品那一刻發生變化，所以導致積分和最新的商品積分對應不上。還有一種情況可能是因爲積分是直接前端傳過來的，並不是後臺直接查詢的，所以插入如果能從後臺取，一定要從後臺取，不要過分信賴前端帶過來的數據。
林老師帶你學編程：https://wolzq.com
