1八、生鮮電商平臺-性能優化以及服務器優化的設計與架構

說明：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+

 

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

 

轉載自-- https://www.cnblogs.com/jurendage/p/9081062.html