Mycat原理：
Mycat原理中最重要的一个动词就是“拦截”，它拦截了用户发过来的sql语句，首先对sql语句做一些特定的分析：如分片分析，路由分析，读写分离分析，缓存分析等，然后将此sql发往后端真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
分片规则：分片字段（sharding column）+分片函数（rule function）。
Mycat应用场景：
-
单纯的读写分离，此时配置最为简单，支持读写分离，主从切换
-
分表分库，对于超过 1000 万的表进行分片，最大支持 1000 亿的单表分片
-
多租户应用，每个应用一个库，但应用程序只连接 Mycat，从而不改造程序本身，实现多租户化
-
报表系统，借助于 Mycat 的分表能力，处理大规模报表的统计
-
替代 Hbase，分析大数据
-
作为海量数据实时查询的一种简单有效方案，比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果， 除了基于主键的查询，还可能存在范围查询或其他属性查询，此时 Mycat 可能是最简单有效的选择。
Linux环境部署mycat日志分析：
Wrapper日志：
目前 Mycat 的启动是经过 warapper 封装成启动脚本，所以日志也会有其相关的日志文件： ${MYCAT_HOME}/logs/warapper.log,再启动时候如果系统环境配置错误或缺少配置时，导致 Mycat 无法启动可以通过查看 warrpper.log 查看具体错误原因。
Mycat日志：
可以看到配置的数据源相关信息，上面是两个数据源连接 datahost，Mycat 的缓存信息及动态类加载信息，Mycat 线程池、buffer、连接池等等所有的配置信息，通过该启动项可以得知当前运行的 Mycat 个参数调整情况，生产环境下需要做部分参数调整，可以根据该日志分析参数情况，Mycat 启动端口，Mycat后端连接池的初始化过程，心跳检测到连接异常关闭后端连接的日志，可以通过该日志查看后端数据连接状态。
Debug模式下分析sql执行：
通过该日志可以看到 Mycat 整个执行的计划。 其中最重要的是 sql 路由的计划，可以看到 sql 具体被分配到那个分片执行，如果日志异常原因为 sql 错误导致 sql 解析器无法解析 sql，通过分析错误日志可以找到具体的出错原因。 Mycat 日志很重要，当发现 SQL 执行有异常的时候，大多数情况下，都可以通过分析 Mycat 日志来定位错误。
动态数据源核心配置：
在Spring 2.0.1中引入了AbstractRoutingDataSource, 该类充当了DataSource的路由中介, 能有在运行时, 根据某种key值来动态切换到真正的DataSource上。
步骤：
1.项目中需要集成多个数据源分别为读和写的数据源，绑定不同的key。
2.采用AOP技术进行拦截业务逻辑层方法，判断方法的前缀是否需要写或者读的操作
3.如果方法的前缀是写的操作的时候，直接切换为写的数据源，反之切换为读的数据源
也可以自己定义注解进行封装
动态数据源与多数数据源区别：
-
多数据源---以分包形式
-
动态数据在jvm进行不断地进行切换
-
数据库集群如何考虑数据库自增唯一性
Mycat分片集群分表分库策略
在数据库集群环境下，默认自增方式存在问题，因为都是从1开始自增，可能会存在重复，应该设置每台节点自增步长不同。
查询自增的步长
SHOW VARIABLES LIKE 'auto_inc%'
修改自增的步长
SET @@auto_increment_increment=10;
修改起始值
SET @@auto_increment_offset=5;
假设有两台mysql数据库服务器
节点①自增 1 3 5 7 9 11 ….
节点②自增 2 4 6 8 10 12 ….
注意:在最开始设置好了每台节点自增方式步长后，确定好了mysql集群数量后，无法扩展新的mysql，不然生成步长的规则可能会发生变化。
数据库分表分库策略：
垂直拆分：
就是根据不同的业务，分为不同的数据库，比如会员数据库、订单数据库、支付数据库等，垂直拆分在大型电商系统中用的非常常见。
优点：
拆分后业务清晰，拆分规则明确，系统之间整合或扩展容易。
缺点：
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度存在分布式事务问题。
水平拆分：
相对于垂直拆分，水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中 的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中
主要有分表，分库两种模式
该方式提高了系统的稳定性跟负载能力，但是跨库join性能较差。
网友评论