作者回复: 你好,MyCAT我最近也关注的比较少，只是借此分析了一下分库分表的一些发展。也感谢你给大家提供了更新的技术，号称解决了传统分库分表类似跨库JOIN，值得深入研究。

作者回复: 这位兄台一定用过MyCat，MyCat这款中间件对我的职场有极大的推动作用，但要在生产环境中进行数据库分库分表，我也不会选择mycat，如果目前公司已经使用了mycat，通常要推动用户进行sql规范，通常数据量大的场景，建议实时业务使用单表操作，尽量避免使用join，查询可以通过异构，降低对数据库的依赖。

作者回复: 嗯，对的，通常建议是代码中使用shardjdbc就好，但在运维管理层面，可以部署一套shardingsphere，方便进行数据查找。

作者回复: 你好，你们公司技术还是可以的，不过我在想你们自己实现的这个类库，要实现复杂的sql语句，应该有点难度吧，例如多层嵌套sql等。这个数字，其实就是一个 hashcode % total,这个total用1000，100还是1024，本质上没有啥差别的，我们公司1024张表，分布在16个物理库上。

作者回复: 首先我觉得你说的没错，如果只是实现订单表一个单表的路由一个类缺少很容易。但一个表的语法不只单表插入与查找，还有各种各样的join、子查询，分组等，要实现这些功能，就比较困难了，再者说我们项目中肯定不只一个表，要完成多个表，而且随着场景的增多，你这个类的维护就会比较困难，后面容易被这个技术需求所拖累，进而影响业务功能。我的想法是专业的人做专业的事情，一些共性的技术需求交给专门研究这方面的大牛写出来的中间件。

作者回复: 你好，你这么说也没错，当然如果说的比较严谨的话，我觉得可以再细分一下。 其实RocketMQ的主从同步，我们可以通过多主多从一样可以实现高可用，我们将一主一从当成一个复制组，如果主节点宕机，写入流量会转移到其他主节点，并且从节点可以继续消费。 当然多副本，比主从同步更加厉害的一点是，在复制组内可用进行主从切换，可以避免因一个复制组宕机而给其他复制组带来更大的流量压力。

作者回复: 你好，你的理解没有错。上面是指没有使用shardingjdbc这样分库分表组件时需要做的事情，也就是抛出分库分表的一些共性需求，后面业界大神找到了很多通用的解决方案，shardingjdbc,mycat这样优秀的中间件营应运而生。