高并发系统数据库篇

　本文摘要：作者:西红柿炒蛋出处:https://juejin.im/post/6877815196509798408一、数据库毗连池1. 分析数据库毗连的历程第一部门前三个数据包：第一个数据包是客户端向服务端发送的一个“SYN”包，第二个包是服务端回给客户端的“ACK”包以及一个“SYN”包，第三个包是客户端回给服务端的“ACK”包。（三次握手）第二部门是 MySQL 服务端校验客户端密码的历程。

作者:西红柿炒蛋出处:https://juejin.im/post/6877815196509798408一、数据库毗连池1. 分析数据库毗连的历程第一部门前三个数据包：第一个数据包是客户端向服务端发送的一个“SYN”包，第二个包是服务端回给客户端的“ACK”包以及一个“SYN”包，第三个包是客户端回给服务端的“ACK”包。（三次握手）第二部门是 MySQL 服务端校验客户端密码的历程。其中第一个包是服务端发给客户端要求认证的报文，第二和第三个包是客户端将加密后的密码发送给服务端的包，最后两个包是服务端回给客户端认证 OK 的报文。

从图中，你可以看到整个毗连历程或许消耗了 4ms可以看出数据库建设毗连的历程还是比力耗时。每次执行sql，并频繁的建立毗连，其实是比力耗时的。

2. 数据库毗连池数据库毗连池有两个最重要的设置：最小毗连数和最大毗连数，它们控制着从毗连池中获取毗连的流程：如果当前毗连数小于最小毗连数，则建立新的毗连处置惩罚数据库请求；如果毗连池中有空闲毗连则复用空闲毗连；如果空闲池中没有毗连而且当前毗连数小于最大毗连数，则建立新的毗连处置惩罚请求；如果当前毗连数已经大于即是最大毗连数，则根据设置中设定的时间（C3P0 的毗连池设置是 checkoutTimeout）等候旧的毗连可用；如果等候凌驾了这个设定时间则向用户抛堕落误。一般在线上我建议最小毗连数控制在 10 左右，最大毗连数控制在 20～30 左右即可。（唐扬）3. 维护数据毗连池（1）C3P0启动一个线程来定期检测毗连池中的毗连是否可用，好比使用毗连发送“select 1”的下令给数据库看是否会抛出异常，如果抛出异常则将这个毗连从毗连池中移除，而且实验关闭。

现在 C3P0 毗连池可以接纳这种方式来检测毗连是否可用，也是我比力推荐的方式。（2）DBCP在获取到毗连之后，先校验毗连是否可用，如果可用才会执行 SQL 语句。好比 DBCP 毗连池的 testOnBorrow 设置项，就是控制是否开启这个验证。

这种方式在获取毗连时会引入多余的开销，在线上系统中还是只管不要开启，在测试服务上可以使用。二、线程池1、线程池的执行流程JDK 1.5 中引入的 ThreadPoolExecutor 就是一种线程池的实现，它有两个重要的参数：coreThreadCount 和 maxThreadCount。

如果线程池中的线程数少于 coreThreadCount 时，处置惩罚新的任务时会建立新的线程；如果线程数大于 coreThreadCount 则把任务丢到一个行列内里，由当前空闲的线程执行；当行列中的任务聚集满了的时候，则继续建立线程，直到到达 maxThreadCount；当线程数到达 maxTheadCount 时另有新的任务提交，那么我们就不得不将它们抛弃了。【提示】固然网上有越发全面的线程池执行流程，可以参考！2、CPU麋集型、I/O麋集型的线程池执行流程革新针对差别类型的系统，可以实验革新线程池的处置惩罚流程。首先， JDK 实现的这个线程池优先把任务放入行列暂存起来，而不是建立更多的线程，它比力适用于执行 CPU 麋集型的任务，也就是需要执行大量 CPU 运算的任务。

这是为什么呢？因为执行 CPU 麋集型的任务时 CPU 比力忙碌，因此只需要建立和 CPU 核数相当的线程就好了，多了反而会造成线程上下文切换，降低任务执行效率。所以当前线程数凌驾焦点线程数时，线程池不会增加线程，而是放在行列里等候焦点线程空闲下来。可是，我们平时开发的 Web 系统通常都有大量的 IO 操作，例如说查询数据库、查询缓存等等。

任务在执行 IO 操作的时候 CPU 就空闲了下来，这时如果增加执行任务的线程数而不是把任务暂存在行列中，就可以在单元时间内执行更多的任务，大大提高了任务执行的吞吐量。所以你看 Tomcat 使用的线程池就不是 JDK 原生的线程池，而是做了一些革新，当线程数凌驾 coreThreadCount 之后会优先建立线程，直到线程数到达 maxThreadCount，这样就比力适合于 Web 系统大量 IO 操作的场景了，你在实际使用历程中也可以参考借鉴。3、建议（1）线程池中行列中任务的聚集数量需要监控。

（2）建议不要设置线程池的任务行列为无界行列，大量的任务聚集会占用大量的内存空间，一旦内存空间被占满就会频繁地触发 Full GC，造成服务不行用。（3）使用线程池时就需要预先初始化所有的焦点线程。如果池子未经由预热可能会导致系统重启后发生比力多的慢请求。

（4）池化技术焦点是一种空间换时间优化方法的实践，所以要关注空间占用情况，制止泛起空间过分使用泛起内存泄露或者频繁垃圾接纳等问题三、数据库优化方案单机部署的数据库，依据一些云厂商的 Benchmark 的效果，在 4 核 8G 的机械上运行 MySQL 5.7 时，或许可以支撑 500 的 TPS 和 10000 的 QPS。当查询请求增加时，应该如何做主从读写分散来解决问题。1. 主从复制首先从库在毗连到主节点时会建立一个 IO 线程，用以请求主库更新的 binlog，而且把吸收到的 binlog 信息写入一个叫做 relay log 的日志文件中，而主库也会建立一个 log dump 线程来发送 binlog 给从库；同时，从库还会建立一个 SQL 线程读取 relay log 中的内容，而且在从库中做回放，最终实现主从的一致性。这是一种比力常见的主从复制方式。

无限制地增加从库的数量就可以反抗大量的并发呢？实际上并不是的。因为随着从库数量增加，从库毗连上来的 IO 线程比力多，主库也需要建立同样多的 log dump 线程来处置惩罚复制的请求，对于主库资源消耗比力高，同时受限于主库的网络带宽，所以在实际使用中，一般一个主库最多挂 3～5 个从库。【注意】主从除了带来部署的庞大度之外，还会存在主从同步延时的情况。

一般我们会把从库落伍的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落伍的时间到达了秒级别就需要告警了。（监控字段的key：slave_behind_master）2.读写分散数据源拦截器拦截sql请求判断本次sql请求是读请求还是写请求，然后转发给差别的库。3.会见数据库我们已经使用主从复制的技术将数据复制到了多个节点，也实现了数据库读写的分散，这时，对于数据库的使用方式发生了变化。

以前只需要使用一个数据库地址就好了，现在需要使用一个主库地址和多个从库地址，而且需要区分写入操作和查询操作，如果联合分库分表，庞大度会提升更多。为了降低实现的庞大度，业界涌现了许多数据库中间件来解决数据库的会见问题，这些中间件可以分为两类。第一类以淘宝的 TDDL（ Taobao Distributed Data Layer）为代表，以代码形式内嵌运行在应用法式内部。

你可以把它看成是一种数据源的署理，它的设置治理着多个数据源，每个数据源对应一个数据库，可能是主库，可能是从库。当有一个数据库请求时，中间件将 SQL 语句发给某一个指定的数据源来处置惩罚，然后将处置惩罚效果返回。

（仅支持Java语言）另一类是单独部署的署理层方案，这一类方案代表比力多，如早期阿里巴巴开源的 Cobar，基于 Cobar 开发出来的 Mycat，360 开源的 Atlas，美团开源的基于 Atlas 开发的 DBProxy 等等。它一般使用尺度的 MySQL 通信协议，所以可以很好地支持多语言。由于它是独立部署的，所以也比力利便举行维护升级，比力适合有一定运维能力的大中型团队使用。

它的缺陷是所有的 SQL 语句都需要跨两次网络：从应用到署理层和从署理层到数据源，所以在性能上会有一些损耗。而且需要单独维护，比力贫苦。

4.分库分表数据库分库分表的方式有两种：一种是垂直拆分，另一种是水平拆分。垂直拆分，顾名思义就是对数据库竖着拆分，也就是将数据库的表拆分到多个差别的数据库中，专库专用。

对数据库举行垂直拆分是一种偏通例的方式，这种方式其实你会比力常用，不外拆分之后，虽然可以暂时缓解存储容量的瓶颈，但并不是万事大吉，因为数据库垂直拆分后依然不能解决某一个业务模块的数据大量膨胀的问题，一旦你的系统遭遇某一个业务库的数据量暴增，在这个情况下，你还需要继续寻找可以弥补的方式。这时候可以思量水平拆分。

和垂直拆分的关注点差别，垂直拆分的关注点在于业务相关性，而水平拆分指的是将单一数据表根据某一种规则拆分到多个数据库和多个数据表中，关注点在数据的特点。拆分规则：（1）根据某一个字段的哈希值做拆分（2）根据某一个字段的区间来拆分分库分表引入的问题（1）分区键从分库分表规则中你可以看到，无论是哈希拆分还是区间段的拆分，我们首先都需要选取一个数据库字段，这带来一个问题是：我们之后所有的查询都需要带上这个字段，才气找到数据所在的库和表。（2）join 代码层面控制（3）count() 单独的数据表或是redis做计数控制固然，虽然分库分表会对我们使用数据库带来一些未便，可是相比它所带来的扩展性和性能方面的提升，我们还是需要做的，因为，履历太过库分表后的系统，才气够突破单机的容量和请求量的瓶颈作者:西红柿炒蛋出处:https://juejin.im/post/6877815196509798408。

本文关键词：贝博app体育,高并发,高,并发,系统,数据库,篇,作者,西红柿

本文来源：贝博ballbet体育-www.riyerenzhong.com