mysql读写分离的坑

读写分离的主要目标是分摊主库的压力，由客户端选择后端数据库进行查询。还有种架构就是在MYSQL和客户端之间有一个中间代理层proxy，客户端之连接proxy，由proxy根据请求类型和上下文决定请求的分发路由。

• 客户端直连方案：因为少"text-align: center">

  如图：先执行trx1，再执行一个查询请求的逻辑，要保证能够查到正确的数据，我们可以使用
  

  这个逻辑

  1. trx1事物更新完成后，马上执行show master status得到当前主库执行到的File和Position；
  

  2. 选定一个从库执行查询语句；
  

  3. 在从库上执行select master_pos_wait(File, Position, 1)；
  

  4. 如果返回值是>=0的正整数，则在这个从库执行查询语句；
  

  5. 否则，到主库执行查询语句。
  

  这里我们假设，这条select查询最多在从库上等待1秒。那么，如果1秒内master_pos_wait返回
  一个大于等于0的整数，就确保了从库上执行的这个查询结果一定包含了trx1的数据。

  5到主库执行查询语句，是这类方案常用的退化机制。因为从库的延迟时间不可控，不能无
  限等待，所以如果等待超时，就应该放弃，然后到主库去查。按照我们设定不允许过期读的要求，就只有两种选择，一种是超时放弃，一种是转到主库查询。

  并发连接和并发查询
  

  innodb_thread_concurrency参数是控制innodb的并发线程上限。一旦超过这个数值，新请求就会进入等待。

  • show processlist看到的几千个连接，是值并发连接，而当前正在执行的语句，才是并发查询。并发连接影响不大，只是会多占内存，而并发查询才是CPU杀手。
  • 在线程进入锁等待以后，并发线程的计数会建议，也就是等行锁的线程是不算在并发查询里的。因为所等待已经不吃CPU了

  以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。