Java开源生鲜电商平台-性能优化以及服务器优化的设计与架构(源码可下载）

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+

其实我需要的互相学习，互相进步，仅此而已。