测试情况分析
Mysql配置信息如下(docker容器默认配置)：
binlog_cache_size 32768
binlog_row_event_max_size 8192
binlog_stmt_cache_size 32768
binlog_transaction_dependency_history_size 25000
bulk_insert_buffer_size 8388608
connection_memory_chunk_size 8912
delayed_queue_size 1000
histogram_generation_max_mem_size 20000000
host_cache_size 279
innodb_buffer_pool_chunk_size 134217728
innodb_buffer_pool_size 134217728
innodb_change_buffer_max_size 25
innodb_ddl_buffer_size 1048576
innodb_doublewrite_batch_size 0
innodb_ft_cache_size 8000000
innodb_ft_max_token_size 84
innodb_ft_min_token_size 3
innodb_ft_total_cache_size 640000000
innodb_log_buffer_size 16777216
innodb_log_file_size 50331648
innodb_log_write_ahead_size 8192
innodb_max_undo_log_size 1073741824
innodb_online_alter_log_max_size 134217728
innodb_page_size 16384
innodb_purge_batch_size 300
innodb_sort_buffer_size 1048576
innodb_sync_array_size 1
join_buffer_size 262144
key_buffer_size 8388608
key_cache_block_size 1024
large_page_size 0
max_binlog_cache_size 18446744073709547520
max_binlog_size 1073741824
max_binlog_stmt_cache_size 18446744073709547520
max_heap_table_size 16777216
max_join_size 18446744073709551615
max_relay_log_size 0
myisam_data_pointer_size 6
myisam_max_sort_file_size 9223372036853727232
myisam_mmap_size 18446744073709551615
myisam_sort_buffer_size 8388608
ngram_token_size 2
optimizer_trace_max_mem_size 1048576
parser_max_mem_size 18446744073709551615
performance_schema_accounts_size -1
performance_schema_digests_size 10000
performance_schema_error_size 5153
performance_schema_events_stages_history_long_size 10000
performance_schema_events_stages_history_size 10
performance_schema_events_statements_history_long_size 10000
performance_schema_events_statements_history_size 10
performance_schema_events_transactions_history_long_size 10000
performance_schema_events_transactions_history_size 10
performance_schema_events_waits_history_long_size 10000
performance_schema_events_waits_history_size 10
performance_schema_hosts_size -1
performance_schema_session_connect_attrs_size 512
performance_schema_setup_actors_size -1
performance_schema_setup_objects_size -1
performance_schema_users_size -1
preload_buffer_size 32768
profiling_history_size 15
query_alloc_block_size 8192
query_prealloc_size 8192
range_alloc_block_size 4096
range_optimizer_max_mem_size 8388608
read_buffer_size 131072
read_rnd_buffer_size 262144
rpl_read_size 8192
select_into_buffer_size 131072
sort_buffer_size 262144
thread_cache_size 9
tmp_table_size 16777216
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
持续请求4秒
根据测试，单体jvm+单体mysql，对于插入操作最好的并发数量为200，当数据量超过50万进行插入操作时，最大操作时长变得无法接受（此时jvm所在服务器的cpu使用率为24%），与tomcat(默认连接数量为200)的最大连接数量相一致，接下来尝试将tomcat连接数量设置为300进行测试。
经过测试，300并发量和200并发量对于cpu的影响不是很大，300并发请求的cpu占用为26%，但是性能却没有过多的提升，怀疑是mysql的瓶颈，Mysql服务器cpu在300并发请求下cpu使用率为40%，查询mysql的连接配置，最大连接请求数发现并未达到设置的上限，因此现在考虑添加一个tomcat来处理请求。
show variables like "%max_connections%";
show global status like 'Max_used_connections';
以下的测试数据均为每秒持续请求
针对用户量很少的情况(单秒并发数量25-100以内，单体架构4核mysql+4核java应用)完全够用，这种情况下用每分用户要在250-1000。
如果想提升性能，对于统计之类的查询最好借助于redis进行，因为mysql查询统计速度不高。单体redis对于2000并发量的请求还是可以应对的，所以在开发项目过程中能够使用redis缓存则使用redis缓存，根据性能统计，mysql的单秒写入可以达到200左右并发，如果可以将查询之类的全部放在redis中进行，将mysql的主要性能将只是放在写入和修改上面，程序可以在如何应对写入和修改上面下功夫。这时候应用的新增操作的每分钟需要有250-2000用户，那么总的用户量需要20万人。
针对下单服务->库存服务，这样的并发量可以达到300左右(如果java服务器启动多台)，主要也是mysql写入特性决定的。
针对如上测试结果，对结构设计和代码有哪些帮助：
1.代码中尽量思考如何使用redis进行代码编写；
2.对于记录日志之类的操作，可以考虑使用队列，让监听应用去对日志进行记录，数据库日志做业务分离；
3.使用网关来访问应用，其目的是进行请求的限流，以防止突然流量请求导致项目崩溃，同时还可以在请求达到峰值的时间来进行记录；