Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構(源碼可下載）

Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構(源碼可下載）說明：Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構，我採用以下三種維度來講解 1. 代碼層面。 2. 資料庫層面。 3. 伺服器層面誠然，性能優化這個方面的確是一個長期的過程，並不是大伙們看了我的文章後就覺 ...

Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構(源碼可下載）

說明：Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構，我採用以下三種維度來講解

1. 代碼層面。

2. 資料庫層面。

3. 伺服器層面

誠然，性能優化這個方面的確是一個長期的過程，並不是大伙們看了我的文章後就覺得可以做的很好的，我這邊只是起一個拋磚引玉的作用，給大伙一種解決問題的思路與方向。

1. Java代碼層面優化

補充說明：Java代碼層面優化，你需要知道的是，那些代碼需要優化，我們知道八二定律告訴我們，80%的性能問題出在20%的代碼上，我們需要的是找到那些20%的代碼進行針

對性的優化，這樣才能把服務的質量優化得最好。

那麼如何進行監控呢？又怎麼樣進行監控呢？可以先看前一篇文章：<Java開源生鮮電商平臺-監控模塊的設計與架構(源碼可下載）>. 具體情況大家可以去看。

我列舉幾個常見的優化方案：用實戰來說明一切。

看以下代碼：

我們知道，買家在支付成功後，支付寶或者微信會服務端回調，然後我們處理自己的業務。

相應的業務，我們在訂單伺服器層創建一個方法：

    /**
     * 支付返回
     * @return orderInfo 訂單信息
     */
    public void payReturn(OrderInfo orderInfo,PayLogs payLogs);

業務實現有以下需要註意的，（我只分享核心內容，非核心的大家自己去看源代碼即可）

1. 更新支付狀態，變成已付款，

2.更新配送狀態，待配送。

3. 更改交易日誌表，變成已經付款。

4. 更新訂單明細表，記錄所有的訂單明細都有效。

5.更新用戶的餘額為0,

6. 記錄相關的操作日誌等等。

相應的代碼如下：（spring 事物控制在服務層，如果以上6個步驟有一個錯誤，則全部回滾。）

    @Override
    public void payReturn(OrderInfo orderInfo, PayLogs payLogs) {
        orderInfoDao.payReturn(orderInfo);
        orderItemDao.updateOrderItemByOrderNumber(orderInfo.getOrderNumber());
        buyerDao.updateBuyerBalanceToZero(orderInfo.getBuyerId());
        payLogsDao.updatePayLogs(payLogs);
        logDao.insertOperatorLogs(orderInfo,payLogs);
    }

我們發現，以上6補需要採用5個資料庫連接才可以完成，而且在同一個事務裡面，因為需要保證數據的一致性。

我們發現，整個業務的操作需要2s完成，對於我們監控業務在500ms的目標，相距太遠了，怎麼辦？

以上代碼，究竟那塊的性能最差呢？

orderInfoDao.payReturn(orderInfo); 花費：100ms

orderItemDao.updateOrderItemByOrderNumber(orderInfo.getOrderNumber()); 花費300ms

buyerDao.updateBuyerBalanceToZero(orderInfo.getBuyerId()); 花費200ms

payLogsDao.updatePayLogs(payLogs); 花費800ms

logDao.insertOperatorLogs(orderInfo,payLogs); 花費600ms

綜合以上分析，我們需要把同步改成非同步，分析出問題的關鍵。

payLogsDao.updatePayLogs(payLogs); 這塊代碼進行了優化。

我們驚奇的發現，用戶存在刷單的情況，就是不停的支付，就是不支付，對於線上1000多個買家而言，平均每天2單-5單，每單平均訂單數在1-10之間

那麼一個月的訂單日誌記錄就是：1000*30*5*10=1500000記錄，我的天，問題出在這裡。日誌表也有巨大的量。

最終解決方案：同步改非同步進行處理。用redis隊列處理，最終性能提高到了500ms內。

一個核心的思想就是：找出問題，解決問題，分而治之的原理進行處理。但是大部分人都輸在找問題在，不是找問題難，而是找到核心出問題的代碼難。監控那篇文章大伙可以再看看。

2. 資料庫方面

補充說明：資料庫方面無外乎就是關聯查詢的時候，增加索引，使查詢性能更高。那麼到底如何做呢？

查詢優化:
1.使用慢查詢日誌去發現慢查詢。
2. 使用執行計划去判斷查詢是否正常運行。
3. 總是去測試你的查詢看看是否他們運行在最佳狀態下 –久而久之性能總會變化。
4. 避免在整個表上使用count(*),它可能鎖住整張表。

相關的優化理論，我已經整理到以前的一篇文章了，這邊就不再列舉

查看《Mysql性能優化》---https://www.cnblogs.com/jurendage/p/3798703.html

3. 伺服器監控

說明:我們所說的伺服器優化，很大部分是指的tomcat的優化，而不是大家所說的Linux本身的優化，當然這樣文章很多，筆者只是用實際說話，看看我們的B2B電商平臺如何進行伺服器性能的優化。

3.1 tomcat的JVM優化。

這個根據大家自己的電腦進行配置，具體情況需要大家百度自己研究，說來話長

#!/bin/sh
JAVA_OPTS="-server -Xms1024M -Xmx1024M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/buyer/gcdump -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true"

這個是筆者的阿裡雲的伺服器的優化。

3.2 tomcat的連接池優化

    <Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol"
                           connectionTimeout="20000"
                           maxConnections="1000"
                           maxThreads="100"
                           minSpareThreads="50"
                           acceptCount="500"
                           enableLookups="false"
                           compression="on"
                           URIEncoding="UTF-8"
                           redirectPort="8443" />

相關的優化方案可能很多，但是這些都是筆者1年半的實戰總結，可能又不算很好的地方，但是穩定性壓倒一切，希望分享出來，一起努力。。

總結：優化是一個長期的過程，無外乎就是代碼級別，資料庫級別，伺服器級別，負載均衡等等手段

我寫文章的目的也跟大家說下，以免大家誤會

第一，項目生產環境運行了一年半了.

第二，這個是技術分享.

第三，我忍不是很頑固，是很執著。

第四，我想讓更多的人學習好技術一起奮鬥，所以我堅持，天天寫，日日寫，月月寫。

第五，如果你寫過博客，你就知道堅持是很難的一件事情，

第六，你要知道我每篇文章都是cnblogs的頭條，而且每篇文章的都是精華，訪問量都到3000+

其實我需要的互相學習，互相進步，僅此而已。

Java開源生鮮電商平臺-性能優化以及伺服器優化的設計與架構((源碼可下載），如果需要下載的話，可以在我的github下麵進行下載。