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

          1.  程式碼層面。

          2.  資料庫層面。

          3.  伺服器層面

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

1. Java程式碼層面優化

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

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

   那麼如何進行監控呢？又怎麼樣進行監控呢？

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

看以下程式碼：

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

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

/**
     * 支付返回
     * @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+

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