MySQL的应用架构
包含三部分：
- mysql实例，大多配置4c8g，高配8c16g，支持连接数1w+；可以包含单库，也有分库（一般十库十表）；
- mysql的连接配置，都是库维度：jdbc:mysql://xxx:3306/pay-config；大都最大连接数配置为20；
- web应用服务，对每个单服务维护一个库的连接池；
思考：为啥一般最大连接数这么小 20？
一般生产上的千万级别以下的表，单个sql查询也就5ms左右（各种索引）；
按照4c8g的服务10台，配置的数据库最大连接数20，每条sql平均10ms来算：
可以支持最大qps：1/10ms *20 *10 = 2w ！！！
但是20个线程并不能同时运行，毕竟4c机器，按照4线程同时运行来算：
可以支持最大qps：1/10ms *4 *10 = 4k ✅
刚好和阿里云的4c8g的配置，能支持最大连接数6k相吻合 ~~~
思考：BC应用不拆分，连同一个数据库有啥问题？
这个问题就很大，如果B侧逻辑有很多大事务，那么就会造成C侧逻辑时线程不够用，甚至线程池满了而拿不到连接；
常见的：B侧逻辑文件导入时大事务处理、B侧逻辑事务处理时调用多方下游进行校验等。
（话外：B侧逻辑有内存OOM的话，也殃及C侧逻辑，毕竟机器都嗝屁了）
思考：BC应用拆分，连同一个数据库有啥问题？
这个一般没啥问题，只有BC侧应用对同一个表有锁竞争时会影响性能；
最终形态：BC应用拆分，且连不同数据库 ✅
B侧负责复杂的crud，当数据真正ready后再同步给C侧应用， 举例：
- 活动未上线前都为草稿数据，不同步C侧；
- 商品未上线前都为草稿数据，不同步C侧；
思考：下游交互时，要减少网络调用次数，那么它究竟有多耗时？
比如：在DB、Redis交互时，如果有批量数据操作，我们一般都会选择批处理命令，来减少网络调用次数。
网上有很多分析的文章...
那我们来点实际的，在应用服务器上ping一下DB和Redis实例看看：
