MySQL Router架构实践
MySQL Router作为InnoDB Cluster（MySQL 7.X）的一部分，它是一个轻量级的中间，可以在Application与下游的MySQL Server之间提供透明的路由方式，它主要用以解决数据库主从库集群的高可用、易于扩展性等。
MySQL Router可以脱离InnoDB Cluster而单独实施，即MySQL 5.6等版本数据库仍然可以使用Router作为其中间代理曾，Router的核心原理为：
1、Router作为一个流量转发层，它的架构层面，位于Application与MySQL Servers之间。
2、其功能角色，类似于Nginx、LVS等，MySQL Servers作为Router的“upstream”（NAT模式）；Application不再直连MySQL Servers，而是与Router相连。根据Router的配置，将会把应用程序的READ、WRITE请求转发给下游的MySQL Servers。
3、当下游有多个MySQL Servers，无论主、从，那么它可以对READ、WRITE请求进行负载均衡。（loadbalance）
4、当下游某个Server失效时，Router可以将其从Active列表中移除，当其online后再次加入Active列表，即提供了Failover特性。
5、当MySQL Servers集群拓扑变更时，比如增减Slaves节点，我们只需要修改Router的配置即可，无需修改Application中JDBC URL配置，因为Application配置的为Router地址而非MySQL Servers的原始地址；即“数据库集群迁移”对Application是透明的。
6、Router支持集中式部署，即一个Group通常有多个Router节点，但是MySQL官方并没有提供集群的HA，即Router每个节点均为独立，它们之间互不通信，无Leader角色，无选举机制。那么当某个Router节点失效，Application层面需要借助MySQL Connector的高级特性，比如：failover、loadbalance等协议来实现Failover功能。简单而言，Router中间件与Connector的高级协议互相协作，才能够实现请求在Router集群之间的负载均衡、Failover等。
7、Router中间件，本身不会对请求“拆包”（unpackage），所以我们无法在Router中间件上实现比如“SQL审计”、“隔离”、“限流”、“分库分表”等。但是Router提供了plugin机制，你可以开发自己的plugin来扩展Router的额外特性。（C语言）
8、如果你的MySQL Servers为5.7+版本，且构建为InnoDB Cluster模式，那么Router还能基于metaCache（metaServers）机制，感知MySQL Servers的主从切换、从库增减等集群拓扑变更，而且基于变更能够实现Master自动切换、Slaves列表自动装配等。比如Master失效后，Cluster将会自动选举一个新的Master，此时Router不需要任何调整、可以自动发现此新Master进而继续为Application服务。
9、考虑到Router集中式部署可能引入“额外的部署成本”、“性能降级”、“连接数上限”等问题，我们通常建议大家基于“Agent”方式部署，即部署在Application宿主机器上，潜在的问题就是自动化运维设施需要即备。
10、Router通常是解决“MySQL集群规模性迁移”：比如跨机房部署、流量迁移、异构兼容，或者解决MySQL集群规模性宕机时快速切换等。如果仅仅是为了解决日常的节点增减、读写分离、Failover等，我们仍然建议使用mysql-connector-j支持的“replication”、“loadbalance”协议来实现，基于客户端，而且轻量级。
MySQL Router目前已知的“局限性”：
1、不支持比如“分库分表”、“SQL审计”等。
2、在非InnoDB Cluster架构模式下，如果主从库拓扑变更，需要手动修改Router配置。且Router不支持“reload”，修改配置后需要重启，这在一定程度上会影响Application的服务可用性。但是Router的重启非常快，我们通过验证，通常在秒级别。（5S）。
3、MySQL Router非常轻量级，与直连Servers相比，其性能损耗低于1%，我们通过压力测试，100W读写请求总耗时只增长了200多秒。不过摆在Router面前的问题，就是其对链接数的支撑能力，原则上我们一个Router节点限定在500个TCP链接。Router本身CPU、内存、磁盘消耗都极低，但是我们要求Router节点对网络IO的支撑能力应该较强，考虑到Router底层为“异步IO”，如果条件允许，我们应该构建在较高版本的Linux平台下，且给予合理的CPU资源。（目前我们线上为8Core、16G，万兆网卡）。
备注：MySQL Router在2.1.4版本以下，内核基于select() IO模型，存在连接数500上限、较大SQL请求导致CPU过高，以及并发连接过高时Router假死等问题，建议升级到2.1.6+。
4、Router对连接的管理是基于“粘性”方式，即Application与Router的一个TCP连接，将对应一个Router与MySQL Server的连接，当Application与Router的连接失效时，Router也将断开其与MySQL Server的连接；只要Router上下游网络联通性正常，那么Router将不会主动断开与Application的连接，也不会切换其与Server的连接。即当Application与Router创建一个新连接时，Router将根据负载均衡算法，选择一个Server并与其建立连接，此后将唯一绑定，直到此Server失效时触发重新选择其他Server。
这就引入一个问题，如果某个连接上发生了“繁重”的SQL操作，那么将会导致下游Server伴随高负载而无法“负载均衡”，或许这就是基于TCP NAT代理模式的通病吧。比较有幸的是，我们通常使用DataSource Pool，且MySQL Connector在面对这样的问题时，也有相应的解决办法，参见下文“loadBalanceAutoCommitStatementThreshold”。
5、不能设定权重，即按照权重负载均衡。
MySQL Router部署方案参考（非InnoDB Cluster模式）
针对一组MySQL M-S架构集群，通过有一个Master和多个Slave：
1、针对Master，我们只需要一个Router集群即可，此集群接收WRITE操作。（当然也可以接收读）对于应用而言，它们统一将WRITE操作发给此Router集群，建议三个Router节点。（主要为了避免一个Router节点失效后，至少还有2个节点承载服务，当然节点数量应该与MySQL Server的请求量来综合权衡）
2、考虑到不同的Application可能使用不同的slaves，即按照常规设计，不同的Application使用不同的slaves也是考虑隔离，比如某个Application因为操作不当（慢SQL）不至于将所有的slaves都压垮。那么对于Router集群而言，我们也可以按照Application或者业务组来分割，隔离力度因人而异，建议Router集群的数量不要太多，否则对Router也是浪费、此外运维Router也是一个比较繁杂的事情。
针对Slaves的Router集群，每个集群建议2个节点，当然节点数可以根据slaves个数、请求量等综合考虑。
Router配置参考（${mysqlrouter}/mysqlrouter.conf）
[DEFAULT] logging_folder=/data/mysql-router/log runtime_folder=/data/mysql-router/run data_folder=/data/mysql-router/data [logger] level = INFO [routing:router_rw] bind_address=0.0.0.0 bind_port=3306 destinations=127.0.0.1:3306,127.0.0.1:3406 client_connect_timeout=6 connect_timeout=3 max_connections=2048 ##如果你的master为单节点master，可以使用read-only模式 ##当需要master切换时，手动修改此配置文件并重启 mode=read-write protocol=classic [routing:router_ro] bind_address=0.0.0.0 bind_port=4306 destinations=127.0.0.1:4306,127.0.0.1:4307 client_connect_timeout=6 connect_timeout=3 max_connections=1024 mode=read-only protocol=classic
对于READ、WRITE两种操作，对应两种“mode”，因为Router不对请求拆包，所以它无法判断请求的读写类型，我们只能在配置文件中，分别为读写设定不同的配置：读写使用绑定不同的端口，比如示例中“3306”端口接收到的请求都会转发给master，“4306”端口接收的请求会转发给slaves。当然具体“destinations”中是master还是slave地址，由你来决定，最好保持对应。
原则上，“destinations”中可以指定多个Servers地址，以“,”分割。
1、对于read-write模式：将采用“首个可用”算法，优先使用第一个server，当第一个server（即3306）不可达时，将会Failover到第二个server（3307）；依次进行。如果都不可达，那么此端口上的请求将会被中断，不可用，且此时Router将不可用（主要是此port将不能服务）。（需要注意，此算法只遍历一次列表，即逐个验证destinations中的Server，不会循环）
特别注意，一旦所有的Servers依次验证且不可用后，Router将不能继续服务，内装状态设定为aborted，即使此后Servers恢复上线，也不能继续对Client提供服务，因为它不会与Servers保持心跳检测；对于Router而言，直接拒绝Client连接请求，只有重启Router节点才能解决。（我认为这是个Router完全可以解决的问题，不知道为什么却如此设计）
2、对于read-only模式：将采用“轮询”算法，依次选择server新建连接，如果某个Server不可达，将会重试下一个Server，如果所有的Server都不可达，那么此端口上的请求将中断，即READ操作将不可用。同时Router将会持续与每个Server保持心跳探测，当恢复后重新加入Active列表，此后那些新建连接请求将可以分发给此Server。
但是比较遗憾，Router不会将已有的连接重新分配给“新加入”列表的Server，比如Router有2个Server地址（S1,S2），某时刻S1不可达，那么在S1上粘性的客户端连接也将被断开，新建连接将会全部在S2上，此后S1恢复正常，那么在S2上的旧的连接将不会迁移到S1上，此时S1只会接收新的连接，如果没有新连接请求，那么S1将会在一段时间看起来是“不提供服务”的。为了解决此问题，我们要求Connection Pool有管理“连接生命周期”的相关控制，比如一个connection被创建X秒以后在返回连接池时应该被主动关闭，这个参数在tomcat-jdbc-pool中为“maxAge”。
如果你的应用程序中，部署方式是单Master、多Slaves（而不是多Master方式或者metaCache + MySQL Cluster架构），我们完全可以在承接“master”请求的Router节点上，也配置为“read-only”模式，那么此单master节点失效重启后，可以不需要重启Router节点即可继续服务。
因为Router不会对TPC拆包，所有“read-write”、“read-only”并不会干扰实际的SQL执行结果，严格来说，这两种mode映射两种“路由算法”：“首个可用”、“轮询”；除此之外，再无特殊含义。（仅限：单Master、多Slave模式，常规HA架构）
Application接入方案
1、mysql-connector-j版本至少在5.1.27以上，建议为5.1.43+。短期内不建议升级为mysql-connector-j 8.x。
2、连接池组件，优选tomcat-jdbc-pool，建议为8.0.x+，通常与你的tomcat版本互相兼容即可。建议为8.5+。
3、建议使用JDBC replication协议：此协议有非常多的高级特性，可以认为是客户端级的路由组件，支持“负载均衡”、“failover”等。JDBC URL中地址使用Router集群的地址，Router集群的高可用将借助于replication协议实现，当某个Router节点失效，replication协议可以将请求Failover到URL列表中的其他Router节点。
<bean id="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource" destroy-method="close">
<property name="url" value="jdbc:mysql:replication://.../test"/>
<property name="username" value="root"/>
<property name="password" value="root"/>
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="maxIdle" value="12"/>
<property name="minIdle" value="2"/>
<property name="maxActive" value="32"/>
<property name="maxWait" value="6000"/>
<property name="initialSize" value="2"/>
<property name="testOnBorrow" value="true"/>
<property name="testOnReturn" value="true"/>
<!-- 必须为true -->
<property name="defaultAutoCommit" value="true"></property>
<property name="removeAbandoned" value="true"/>
<property name="removeAbandonedTimeout" value="60"/>
<property name="validationQuery" value="SELECT 1"/>
<property name="validationInterval" value="30000"/>
<property name="testWhileIdle" value="true"/>
<property name="timeBetweenEvictionRunsMillis" value="30000"/>
<property name="minEvictableIdleTimeMillis" value="300000"/>
<!-- 此参数很重要，建议1分钟 -->
<property name="maxAge" value="60000"/>
<property name="jmxEnabled" value="true"/>
</bean>我们需要特别注意“maxAge”、“defaultAutoCommit”、“testOnBorrow”参数，适度兼容Router的局限性才能更好的发挥作用。
4、JDBC URL范式
jdbc:mysql:replication://address=(type=master)(host=mr1)(port=mp1),address=(type=master)(host=mr2)(port=mp2),address=(type=slave)(host=sr1)(port=sp1)../database
根据上文约定，良好架构下，针对WRITE操作的Router集群应该有3个节点，那么我们需要在URL中指定三个“type=master”的Router地址；此外“type=slave”的地址为接收READ操作的Router节点地址，需要多个。
根据replication协议的设计原理，对于WRITE、READ操作将会在相应的Router节点之间“负载均衡”，默认策略为“轮询”；当其中某个Router失效，replication协议提供了Failover机制，将会把请求路由到同一type的其他Router节点。
此外有几个可以参考的参数，我们配合replication协议：
1）autoReconnect：设置为false，遵循默认值。
2）failOverReadOnly：此参数只会在autoReconnect为true时生效，建议保持默认值“true”。
3）roundRobinLoadBalance：此参数只会在autoReconnect为true、failOverReadOnly为false时生效，建议保持默认值。
4）readFromMasterWhenNoSlaves：当“type=slave”的所有地址都不可达时，是否可以将read请求转发给master，默认值为“false”，这个值根据实际情况设定，如果你的master可以承载所有的read请求，可以设置为true。
5）loadBalanceStrategy：可选值为“random”、“bestResponseTime”、“serverAffinity”，默认值为“random”。
6）loadBalanceAutoCommitStatementThreshold：当请求状态为“autoCommit”时，在一个连接上操作一定次数的请求后，触发“负载均衡”，选在其他Server。（参见源码）。
7）allowMasterDownConnections：默认值为false，在replication协议中，如果Master无法连接时是否允许Client创建或者获取连接（包括获取Slave的连接）。“false”表示当Master无法连接时，将不能创建任何连接，包括Slave读操作。在基于Router集群时，建议设置为true。
8）allowSlaveDownConnections：默认为false，同上。