MySQL生产经验

生产数据库一般用什么配置的机器

首先要明确的一点, 如果系统是一个没什么并发访问量, 用户就几十个人或者几百个人的系统, 那么其实选择什么样的机器去部署数据库, 影响不大. 哪怕是个人笔记本电脑去部署一个MySQL数据库, 其实也能支撑地并发系统的运行.

因为这种系统可能每个几分钟才会有一波请求发到数据库上, 而且数据库里一张表也许就几百条, 几千条或者是几万条. 数据量很小, 并发量很小, 操作频率很低, 用户量很小, 并发量很小, 只不过可能系统的业务逻辑很复杂而已. 对于这类系统的数据库机器选型, 什么样都可以.

普通的Java应用系统部署在机器上能抗多少并发

通常来说, Java应用系统部署的时候常选用的机器配置大致是2核4G和4核8G的较多一些, 数据库部署的时候常选用的机器配置最低在8核16G以上, 正常在16核32G.

那么以大量的高并发线上系统的生产经验观察下来而言, 一般Java应用系统部署在4核8G的机器上, 每秒钟抗下500左右的并发访问量, 差不多是比较合适的. 当然这个也不是绝对的, 假设每个请求花费1s可以处理完, 那么一台机器每秒也许只可以处理100个请求, 但是如果每个请求只要花费100ms就可以处理完, 那么一台机器每秒也许就可以处理几百个请求.

所以一台机器能抗下每秒多少请求, 往往是跟每个请求处理耗费多长时间关联的. 但是大体上来说, 根据大量的经验观察而言, 4核8G的机器部署普通的Java应用系统, 每秒大致能抗下几百的并发访问, 从每秒一两百请求到每秒七八百请求, 都是有可能的, 关键是每个请求耗费多长时间.

高并发场景下, 数据库应该用什么样的机器

对于数据库而言, 上文也说了, 通常推荐的数据至少是选用8核16G以上的机器更加合适.

因为要考虑一个问题, 对于我们的Java应用系统, 主要耗费时间的是Java系统和数据库之间的网络通信. 对Java系统自己而言, 如果仅仅只是系统内部运行一些普通的业务逻辑, 纯粹在自己内存中完成一些业务逻辑, 这个性能是极高极高的.

对于Java系统受到的每个请求, 耗时最多的还是发送网络请求到数据库上去, 等待数据库执行一些SQL语句, 返回结果给Java系统. 所以其实常说的Java系统压力很大, 负载很高. 其实主要的压力和复杂都是集中在依赖的那个MySQL数据库上!

因为执行大量的增删改查的SQL语句的时候, MySQL数据库需要对内存和磁盘文件进行大量的IO操作, 所以数据库往往是负载最高的!

通过经验而言, 一般8核16G的机器部署的MySQL数据库, 每秒抗个一两千并发请求是没问题的, 但是如果并发量再高一些, 假设每秒有几千并发请求, 那么可能数据库就会有危险了, 因为数据库的CPU、磁盘、IO、内存的负载都会很高, 弄不好数据库压力过大就会宕机. 对于16核32G的机器部署的MySQL数据库而言, 每秒两三千, 甚至三四千的并发也都是可以的, 但是如果达到每秒上万请求, 也是会有宕机的危险.

如果可以的话, 数据库机器周最好用SSD的硬盘而不是机械硬盘.

申请机器机器之后做好心中有数, 交给专业的DBA部署

数据库机器申请下来之后, 作为架构师要对机器做到心中有数. 比如申请的是8核16G的机器, 心里大致就该知道这个数据库每秒抗个一两千请求是可以的, 如果申请的是16核32G的机器, 那心里知道妥妥可以抗个每秒两三千, 甚至三四千的请求.

其次, 申请一台机器下来之后, 接着这台机器在有一定规模的公司里, 一定是交给公司专业的DBA去安装、部署和启动MySQL的. DBA这个时候会按照他国王的经验, 用自己的MySQL生产调优参数模板, 直接放到MySQL里去, 然后用一个参数模板去启动这个MySQL, 往往这里很多参数都是调优过的.

而且DBA还可能对linux机器一些OS内核参数进行一定的调整, 比如说最大文件句柄之类的参数, 这些参数往往也都是需要调整的.

0%