享位平台性能优化方案

标签：网关 缓存 JAVA 性能 享位 ipv4 测试 tcp 优化

目录

享位平台性能优化方案

作者：xxx

1. 组网图

2. 网元说明：

2.1.1. 防火墙：

2.1.2. LVS(Linux虚拟服务器)外网负载均衡(ELB)：

2.1.3. NGINX内网负载均衡器:

2.1.4. 应用网关TOMCAT(SpringBoot)：

2.1.5. DUBBO服务：

2.1.6. 存贮层：

2.1.7. EMQX消息队列：

2.1.8. 前置机：

2.1.9. 道闸系统:

2.1.10. 运维监控

3. 组网说明

4. 当前生产环境和未来考虑的配置点：

5. 业务模型

6. 业务场景

6.1. 注册登录

6.2. 送券活动管理

6.3. 商家管理与优惠券核销

6.4. 预约

6.5. 临停

6.6. 用户画像

6.7. 增值营销

6.8. 结算统计

7. 关键指标测试：

7.1. MYSQL主库同时insert、query, 给出性能指标;

7.2. MYSQL同时主库insert、从库query, 给出性能指标;

7.3. 支付的性能指标：准备好一批订单，然后单独测试支付（钱包支付）的性能;

7.4. JMETER测试EMQX的性能指标;

7.5. NGINX测试一个简单的静态网页,给出性能指标;

7.6. 图片服务器--测试发票查看的性能指标。

8. 性能优化点概述:

8.1. 存贮层：

8.2. Nginx WEB服务器与负载均衡：

8.3. 应用网关层：

8.4. 服务层

8.5. 消息队列

8.6. 运维监控

享位平台性能优化方案

作者：xxx

二〇一九年十月二十日

本案以APP端接口为优化重点。从架构、代码、JAVA虚拟机、数据库、操作系统LINUX核心多个方面优化。测试依据此案测试出合理的组网和优化后的配置参数，研发优先解决性能差的常用场景。对于小范围优化，通过问题单由普通工程师实施，对于重要的架构等调整研发高级工程师或者架构师应给出具体落地方案设计，评审后再分发实施。

测试报告依据此案组网记录测试结果，并记录所有网元的配置信息, 同时给出性能优化的建议, 对于性能极差的场景需要分析原因。

系统的性能优化涉及业务架构与技术架构，本案优先考虑技术架构，对于业务架构与产品需求对技术架构的约束如需要则加以描述，为后续业务架构调整作准备。（12306一开始设计成秒杀系统，从而引发系统崩溃，实际完全可以分散时间段购票）

1. 组网图

1. 网元说明：
   1. 1. 防火墙：

由阿里云提供。

1. 1. 1. LVS(Linux虚拟服务器)外网负载均衡(ELB)：

前端4层负责均衡接入，

从吞吐量来说，LVS-DR高，LVS-NAT低

从配置方便性： LVS-NAT低，LVS-DR, LVS-Tun复杂

测试可以先配置LVS-NAT, 如果达不到性能要求可以配置LVS-DR。

生产环境可以直接购买阿里云的负载均衡，未来系统容量扩大也可以考虑NetScaler设备。

集成开源工具（或者购买第三方服务），没有开发工作量，只要合理配置、由测试给出符合要求的最简组网。

1. 1. 1. NGINX内网负载均衡器:

 内部分发负载均衡器，静态网页服务器、反向代理功能。多nginx解决单点故障。

1. 1. 1. 应用网关TOMCAT(SpringBoot)：

实现应用接入、鉴权、安全日志功能，包括APP网关、云平台管理端、物业端、保安端(PAD)、商家端。

1. 1. 1. DUBBO服务：

目前包括系统设置CENTER,和核心服务SERVICE等服务。理论上dubbo服务可以无限扩展，提供核心计算能力，和定期批量处理能力。

1. 1. 1. 存贮层：

MYSQL：

系统关键网元，性能的瓶颈。

主从读写分离，分库分表，提升性能，同时备机提高可靠性，主备切换。

通过缓存等减少mysql压力，使用简单sql,复杂计算由应用服务层完成。

REDIS:

小数据量、多读少写场景适应，如全局配置项。可集群扩展。

ES搜索引擎：

适合模糊查询，大数据量， 非实时，或者对实时要求不高的场景。

如订单、场库、支付流水等。

可集群扩展,支持海量数据的查询。

图片服务器:

使用开源fastDfs搭建，可以集群扩展，目前主要是用户发票和商家资质、以及场库资源的图片服务器。

未来可以考虑使用go-fastDfs,或者直接使用第三方云服务。

备选方案:

MEMCACHED：

暂无使用，对于较大数据量的高速缓存， 作为备选方案

mongodb=mysql+ES

可以实现mysql的实时、ES的查询，和MYSQL的统计分析能力。

可集群扩展支持海量数据。

1. 1. 1. EMQX消息队列：

享位预约停车系统物联网核心，车位锁、前置机、云平台调度中心都是通过消息队列通讯。

MQTT物联网协议，保证弱网络下高可靠传输。可水平扩展。

1. 1. 1. 前置机：

负责车位锁与云平台的通讯，云平台调度中心执行器, 控制锁的升降和状态报告。

1. 1. 1. 道闸系统:

对接享位或者第三方道闸系统，实现停车计费。

1. 1. 1. 运维监控

采用开源ZABBIX监控体系, 性能测试与生产环境数据收集。

1. 组网说明

此组网为测试组网，生产环境根据策略和公司运营规划会有所调整。

1. 当前生产环境和未来考虑的配置点：

每台机器设置统一成亚洲/上海时区，每台机器配置ntp,统一时钟;

MYSQL主从监控要接入Zabbix。

1. 业务模型

享位的主营业务是预约车位，本质上是聚合资源的平台，toB toC的纽带。

人们的需求是享位存在的唯一理由。

为人们带来一条龙消费便捷体验, 同时充分利用社会资源。

物业有停车场，停车场有车位、充电桩，停车场周边有消息场所：商圈。

享位平台和商圈提供优惠券作为促销手段。

1. 业务场景
   1. 注册登录
   2. 送券活动管理

1. 1. 1. 送券活动使用场景图

邀请码注册活动送券与预约送券，

邀请码注册活动：商家与活动绑定，停车场与活动绑定，个人用户邀请自动绑定平台注册活动。

预约送券：停车场与活动绑定

1. 1. 1. 邀请码注册

邀请码注册赠送优惠券：

1. 个人邀请送平台发的预约券
2. 停车场邀请送：预约券（停车场）

      权益券（停车场商圈）

1. 商家邀请送预约券（平台）、

权益券（自家）

邀请码注册绑定活动与事件实现送券规则。

个人邀请码绑定平台注册活动与事件

停车场绑定停车场注册活动与事件

商家绑定商家注册活动与事件

1. 1. 1. 用户预约送券:

通过停车场商圈送权益券,

停车场绑定商家形成商圈关系。

停车场绑定停车场预约送券活动与事件实现送券规则。

停车场预约送券活动绑定商圈内商家的优惠券。

1. 1. 1. 送券活动模板管理
      2. 优惠券模板管理
   2. 商家管理与优惠券核销

1. 1. 预约
   2. 临停
   3. 用户画像
   4. 增值营销
   5. 结算统计

1. 关键指标测试：
   1. MYSQL主库同时insert、query, 给出性能指标;
   2. MYSQL同时主库insert、从库query, 给出性能指标;
   3. 支付的性能指标：准备好一批订单，然后单独测试支付（钱包支付）的性能;

1. 1. JMETER测试EMQX的性能指标;
   2. NGINX测试一个简单的静态网页,给出性能指标;
   3. 图片服务器--测试发票查看的性能指标。
2. 性能优化点概述:
   1. 存贮层：
      1. MYSQL:

1. MYSQL配置顶优化：

Innodb_buffer_pool_size:

缓冲池是数据和索引被缓存的地方，

32G内存配置25G，128G配置100-120G内存

Innodb_log_file_size:

Redo log的大小，redo log保证写入速度和故障恢复。

Innodb_log_file_size=512M,频繁写入的数据库，Innodb_log_file_size=4GB

max_connections:

对于4C服务器配置200-500个连接数,8C配置500-1000, dubbo服务连接池也要相应修改。

每个连接对应系统的一个线程开销。

Innodb 引擎设置:

Innodb_flush_log_at_trx_ccommit:1

对于低速硬盘改为2，

query_cache_size = 0 禁用查询缓存,有时间可以配置测试一下性能对比。

show_query_log:1,启用慢查询日志

long_query_time:1秒

show_query_log_file指定慢查询日志的文件。

1. DB服务器LINX核心参数

/etc/sysctl.conf

vm.swappiness=60

配置vm.swappiness=0禁用虚拟内存。

1. SSD硬盘：

慢查询日志可以设置0.5秒，如果超过0.5秒。0.5秒在SSD上最少走了50个IO,就有可能没有用到索引。0.5秒还是有点问题：如果从8000W中找一条记录，如果加上order 等计算耗时，比较小。

  SSD线上参数设置:

磁盘调度算法改为Deadline
echo deadline > /sys/block/sda/queue/scheduler  # deadline适用于数据库，HDD也建议改成Deadline

MySQL参数 innodb_log_file_size=4G 该参数设置的尽可能大

innodb_flush_neighbors=0
性能更平稳，且至少有15%的性能提升

innodb_io_capacity = 4000

innodb_io_capacity_max = 8000

innodb_page_size = 4096 /4K的大小，设置4k 缓存粒度更小

innodb_flush_neighbors = 0 

1. MYSQL启动关闭顺序：

先停主机，再停从机，

先启动从机，再启动主机。

保证主从机数据一致性。

1. MYSQL备份策略：

由于硬盘（固态盘）都有一定的生命周期，可以使用raid磁盘阵列容错，但备份是必须的。

1. MYSQL应用代码优化

应用接口分离：

APP端和管理端

目前app端和管理端网关安装时分开，代码库是一份，

应用读写分离：

可通过用户车牌作试点，修改测试OK后再进一步优化其它APP接口。

应用分库：

按应用可划分用户（场库），泊位资源库，订单库。

表索引优化：

根据查询条件，合理建立索引， 不重复，一个表最多三个左右索引， 索引字段不要有null值。

Int,long数字型优于字符型，对于枚举型字段不建索引。

SQL：

对于SQL关联的语句，在APP端不使用，通过dubbo服务层进行连接。

优化sql语句，大数据量表确保使用索引。

1. 1. 1. ES搜索引擎:

服务器有32G,配置一半给ES，另一半ES会用到作为缓存。

配置 export ES_HEAP_SIZE=16g

或者启动的时候设置参数，确保Xmx和Xms大小相等:

./bin/elasticsearch -Xmx16g -Xms16g

目前只有场库资源入了ES,

预约订单、临停订单、支付流水加入搜索引擎。

原接口的增删改代码是操作mysql,现在需要同步修改ES。

APP查询订单和流水使用ES的接口。

1. 1. 1. Redis

服务器32G配置24G给redis使用

可通过用户车牌作试点，修改测试OK后再进一步优化其它APP接口。

1. 1. Nginx WEB服务器与负载均衡：

突破高并发的性能优化

NGINX配置:

启用压缩

启用缓存

长连接：保持30秒

1）nginx进程数，建议按照cpu数目来指定，一般跟cpu核数相同或为它的倍数。
worker_processes 8;

2）为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

3）下面这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是系统的最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n的值保持一致。
worker_rlimit_nofile 65535;

4）使用epoll的I/O模型，用这个模型来高效处理异步事件
use epoll;

5）每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。
worker_connections 65535;

6）http连接超时时间，默认是60s，功能是使客户端到服务器端的连接在设定的时间内持续有效，当出现对服务器的后继请求时，该功能避免了建立或者重新建立连接。切记这个参数也不能设置过大！否则会导致许多无效的http连接占据着nginx的连接数，终nginx崩溃！
keepalive_timeout 60;

7）客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
client_header_buffer_size 4k;

8）下面这个参数将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=102400 inactive=20s;

9）下面这个是指多长时间检查一次缓存的有效信息。
open_file_cache_valid 30s;

10）open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。
open_file_cache_min_uses 1;

11）隐藏响应头中的有关操作系统和web server（Nginx）版本号的信息，这样对于安全性是有好处的。
server_tokens off;

12）可以让sendfile()发挥作用。sendfile()可以在磁盘和TCP socket之间互相拷贝数据(或任意两个文件描述符)。Pre-sendfile是传送数据之前在用户空间申请数据缓冲区。之后用read()将数据从文件拷贝到这个缓冲区，write()将缓冲区数据写入网络。sendfile()是立即将数据从磁盘读到OS缓存。因为这种拷贝是在内核完成的，sendfile()要比组合read()和write()以及打开关闭丢弃缓冲更加有效(更多有关于sendfile)。
sendfile on;

13）告诉nginx在一个数据包里发送所有头文件，而不一个接一个的发送。就是说数据包不会马上传送出去，等到数据包最大时，一次性的传输出去，这样有助于解决网络堵塞。
tcp_nopush on; 

14）告诉nginx不要缓存数据，而是一段一段的发送--当需要及时发送数据时，就应该给应用设置这个属性，这样发送一小块数据信息时就不能立即得到返回值。
tcp_nodelay on;
比如：
http { 
server_tokens off; 
sendfile on; 
tcp_nopush on; 
tcp_nodelay on; 
......
} 

15）客户端请求头部的缓冲区大小，这个可以根据系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。 
client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个可以根据系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。 
分页大小可以用命令getconf PAGESIZE取得。
[root@test-huanqiu ~]# getconf PAGESIZE 
4096
但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。

16）为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=65535 inactive=60s;

17）open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。
open_file_cache_min_uses 1;

18）指定多长时间检查一次缓存的有效信息。
open_file_cache_valid 80s;

对应linux核心参数修改：

内核参数的标准配置
[root@dev-huanqiu ~]# cat /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1            //这四行标红内容，一般是发现大量TIME_WAIT时的解决办法
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0           //在net.ipv4.tcp_tw_recycle设置为1的时候，这个选择最好加上
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 0           //开启此功能可以减少TIME-WAIT状态，但是NAT网络模式下打开有可能会导致tcp连接错误，慎重。
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_conntrack_max = 6553500

1. 1. 应用网关层：

Tomcat网关(SpringBoot)优化：

主要的业务处理逻辑在服务层，网关主要负责消息接入和鉴权等预处理，

对于IO高，CPU不密集的网元可以配置更多线程，建议500，

测试可以通过配置200-1000来测试找到最优的配置。

包括APP网关App Controller、云管理网关Manager、商家端Coupon、物业端Merchant、保安端Controller。

测试机是三台4c+16G机器,

1. APP功能入口:

APP网关JAVA启动参数：JAVA_OPTS=-server -Xms4096M -Xmx12298M -Xss1M

测试APP接口性能时可以调节此参数

1. Manager管理网关JAVA启动参数：JAVA_OPTS=-server -Xms512M -Xmx1024M -Xss1M

测试管理接口性能时可以调节此参数

1. 商家端网关JAVA启动参数：JAVA_OPTS=-server -Xms256M -Xmx1024M -Xss1M

测试商家端接口性能时可以调节此参数

1. 物业端网关JAVA启动参数：JAVA_OPTS=-server -Xms512M -Xmx1024M -Xss1M

测试物业端接口性能时可以调节此参数

1. 保安端网关JAVA启动参数：JAVA_OPTS=-server -Xms256M -Xmx1024M -Xss1M

测试保安端接口性能时可以调节此参数

1. 1. 服务层

目前的微服务拆分还不够细化，后续按功能垂直拆分，方便核心服务水平扩展。

主要有CENTER服务：包括文件上传、系统设置等功能；SERVICE包括了核心的预约、临停等功能，还有云管理能力、定时任务。

测试机是三台4c+32G机器, 机器上同时安装了Zookeeper。

1. CENTER JAVA启动参数：JAVA_OPTS=-server -Xms512M -Xmx2048M -Xss1M

测试文件上传时可以适当配大一些JAVA_OPTS=-server -Xms1024M -Xmx4096M -Xss1M

数据库连接池配置最少5个，最多10个;这个压力没有，文件上传不使用我们的数据库连接。

1. SERVICE JAVA启动参数：JAVA_OPTS=-server -Xms20480M -Xmx1024M -Xss1M

测试APP接口性能时可以调节此参数 ,

数据库连接池配置最少100个，最多300个;

测试可以从50-300选取几个，测试出最佳的配置。

数据库4C理论上并发不能太多，一个连接就是一个线程, 50、100、200

4C也可以改为8C再测试，配置100、200、300。

1. 1. 消息队列

物联网核心，测试出目前的性能，根据业界的标准能满足现有需求。可集群。

1. 1. 运维监控

采用开源ZABBIX监控体系，能满足80%以上的监控需求(主要的工作在运维、研发协助)，对于20%余下的关键网元，后续进一步补充完善方案（研发分析、运维落地）。

实时监控系统性能，为性能优化提供帮助。

标签：网关,缓存,JAVA,性能,享位,ipv4,测试,tcp,优化
From： https://blog.csdn.net/leijmdas/article/details/139181872