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