Sharding-JDBC

我在网上陆陆续续的也看了一些有关于分库分表的文章，可发现网上同质化的资料有点多，而且知识点又都比较零碎，还没有详细的实战案例。 为了更深入的学习下，我在某些平台买了点付费课程，看了几节课发现有点经验的人看还可以，但对于新手入门来说，其实学习难度还是蛮大的。 为了让新手也能看得懂，有些知识点我可能会用更多的篇幅加以描述，希望大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源出去，能帮一个算一个吧！如果发现文中有哪些错误或不严谨之处，欢迎大家交流指正。 具体实践分库分表之前在啰嗦几句，回头复习下分库分表的基础概念。 什么是分库分表 其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。 分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。 如何分库分表 分库分表的核心理念就是对数据进行切分（ Sharding ），以及切分后如何对数据的快速定位与查询结果整合。而分库与分表都可以从： 垂直 （纵向）和 水平 （横向）两种纬度进行切分。 分库分表 下边我们就以订单相关的业务举例，看看如何做库、表的 垂直 和

大家都知道，做我们开发这行的，最核心的竞争力就是学习能力。技术一直在变化，框架一直在更新，学还是不学。 不学，你会落伍，学，太累了，根本学不过来。学习只要找对了方法，也没那么累。 最好的学习方式那就是兴趣驱使你去学习，但这种几乎很少，还有一种就是群体学习，就是大家一起学习，有问题一起讨论，这样的方式学起来会很轻松，这条路上的人多了，并不孤单。 知识星球是干嘛的？ • 知识星球是我跟大家分享，交流技术的小圈子。 • 在这里可以交流技术，工作中遇到的问题。 • 我也会定期分享自己的心得和技术文章。 • 核心就是一起学习，讨论后端技术。主要是Java方向的哈！ 有个圈子可以组队学习新技术，分享学习经验，面试经验，工作经验，理财经验等有益于成长的知识。这是我对知识星球的理解。 我希望加入星球的朋友们可以养成习惯，每日打卡，分享自己每天的学习成果，久而久之，学习将不再是一种负担，而是一种习惯。 后续计划 如果真的有更多的朋友愿意加入进来，后面我们可以一起学习，现在就已经开始了，第一个主题是阿里的Sentinel ，目前就我一个人在打卡，还没见到其他球友的打开记录，不过目前人也比较少。 还有就是我会通过各种激励的方式鼓励大家去学习，去分享，去总结，然后用奖品的方式来支持大家，比如赠书，发红包等方式，当然这个取决于后面星球的规模，规模大的话次数多点，规模小的话次数少点，但是肯定会做下去的

来源 | https://urlify.cn/jemaym 使用命令发现磁盘使用率为100%了，还剩几十兆。 一系列神操作 备份数据库，删除实例、删除数据库表、重启mysql服务，结果磁盘空间均没有释放。 怎么办 网上查了很多资源，说要进行磁盘碎片化整理。原因是datafree占据的空间太多啦。具体可以通过这个sql查看。 SELECT CONCAT ( TRUNCATE ( SUM (data_length)/ 1024 / 1024 , 2 ), 'MB' ) AS data_size, CONCAT ( TRUNCATE ( SUM (max_data_length)/ 1024 / 1024 , 2 ), 'MB' ) AS max_data_size, CONCAT ( TRUNCATE ( SUM (data_free)/ 1024 / 1024 , 2 ), 'MB' ) AS data_free, CONCAT ( TRUNCATE ( SUM (index_length)/ 1024 / 1024 , 2 ), 'MB' ) AS index_size FROM information_schema.tables WHERE TABLE_NAME = 'datainfo' ; 这个是后来的图了，之前的图没有留，当时显示一张表里的data_free都达到了20个G。

一、常见问题 1、为什么要分库分表（设计 高并发 系统的时候， 数据库层面 该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们是如何对数据库进行垂直拆分或水平拆分。 2、如何设计可以动态扩容的分库分表方案？ 3、分库分表之后，ID如何处理。 二、为啥要分库分表 其实，这块肯定是扯到高并发了，因为分库分表一定是为了支撑高并发、数据量大两个问题。而且现在说实话，尤其是互联网公司类的公司面试，基本上都会来这么一下。分库分表如何普通的技术问题，不问实在不行，而如果你不知道那也实在说不过去。 说白了，分库分表是两回事，大家可别搞混了，可能光分库不分表，也可能光分表不分库。都有可能，先给大家抛出一个问题。 随着用户量的增长，每天活跃用户数上千万。每天单表新增数据，多个50万。目前1个表的总容量都已经达到两三千万啦！数据库磁盘容量不断消耗掉，高峰期并打达到了5000-8000。单机系统支撑不到现在。公司业务发展越好，用户就越多，数据量越大，请求量越大。那单个数据库一定扛不住。 假设把MySQL从单机变成了三机。 ① MySQL从单机变成了三机，现在可以承受的并发增加了3倍。 ② 将原来3千万数据从1个库分到了3个库，每个库就1/3的数据量，数据库服务器的磁盘使用率大大降低。 ③ 原来1个单表是3千万数据，一个SQL要花3秒去跑，拆分之后，每个库的每个表就1千万数据

一、读写分离背景 分库分表虽然可以优化数据库操作，但是要实现高并发，主从架构就应运而生了。数据库的主从复制架构，将数据库的写操作定位到主库中进行，主库和从库之间通过异步复制、半同步复制保持数据一致。所有的读操作都在主库的N个从库上进行。通过负载均衡使得每一次查询均匀的落在每一个从库上。 一主n从，做读写分离（数据写入主库，通过mysql数据同步机制将主库数据同步到从库–>程序读取从库数据），多个从库之间可以实现负载均衡。次外，ShardingSphere-ShardingJdbc可手动强制部分读请求到主库上。(因为主从同步有延迟，对实时性要求高的系统，可以将部分读请求也走主库) MySQL配置主从同步可参考另一篇博客： https://blog.csdn.net/u014553029/article/details/108832268 二、读写分离实现 2.1 环境准备 程序环境：SpringBoot+MyBatis-plus 数据库环境： 数据库ip 数据库 作用 127.0.0.1 ShardingSphere master 127.0.0.1 ShardingSphere1 slave1 127.0.0.1 ShardingSphere2 slave2 2.2 添加ShardingSphere依赖 <!--shardingsphere数据分片、脱敏工具-->

# 前言 像我这样的菜鸟，总会有各种疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工作几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？其实是老生常谈的话题：服务的扩容问题。 # 正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和 RPC 的问题有点类似：数据库连接过多！！！ 通常，我们的 RPC

大家好，我是小富~ 之前有不少刚入坑 Java 的粉丝留言，想系统的学习一下分库分表相关技术，可我一直没下定决心搞，眼下赶上公司项目在使用 sharding-jdbc 对现有 MySQL 架构做分库分表的改造，所以借此机会出一系分库分表落地实践的文章，也算是自己对架构学习的一个总结。 我在网上陆陆续续的也看了一些有关于分库分表的文章，可发现网上同质化的资料有点多，而且知识点又都比较零碎，还没有详细的实战案例。为了更深入的学习下，我在某些平台买了点付费课程，看了几节课发现有点经验的人看还可以，但对于新手入门来说，其实学习难度还是蛮大的。 为了让新手也能看得懂，有些知识点我可能会用更多的篇幅加以描述，希望大家不要嫌我啰嗦，等这分库分表系列文章完结后，我会把它做成 PDF 文档开源出去，能帮一个算一个吧！如果发现文中有哪些错误或不严谨之处，欢迎大家交流指正。 具体实践分库分表之前在啰嗦几句，回头复习下分库分表的基础概念。 什么是分库分表 其实 分库 和 分表 是两个概念，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。 分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。按照一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快）

1. 前言 4月25号，Sentinel 1.6.0 正式发布，带来 Spring Cloud Gateway 支持、控制台登录功能、改进的热点限流和注解 fallback 等多项新特性，该出手时就出手，紧跟时代潮流，昨天刚发布，今天我就要给大家分享下如何使用！ 2. 介绍（本段来自Sentinel文档） Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块，此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑： GatewayFlowRule：网关限流规则，针对 API Gateway 的场景定制的限流规则，可以针对不同 route 或自定义的 API 分组进行限流，支持针对请求中的参数、Header、来源 IP 等进行定制化的限流。 ApiDefinition：用户自定义的 API 定义分组，可以看做是一些 URL 匹配的组合。比如我们可以定义一个 API 叫 myapi，请求 path 模式为 /foo/ 和 /baz/ 的都归到 myapi 这个 API 分组下面。限流的时候可以针对这个自定义的 API 分组维度进行限流。 其中网关限流规则 GatewayFlowRule 的字段解释如下： • resource：资源名称，可以是网关中的 route 名称或者用户自定义的 API 分组名称。 •

每个服务都有自己的接口，通过Swagger来管理接口文档。在服务较多的时候我们希望有一个统一的入口来进行文档的查看，这个时候可以在Zuul中进行文档的聚合显示。 下面来看下具体的整合步骤以及采坑记录。Cloud版本：Finchley.SR2， Boot版本：2.0.6 加入Swagger的依赖： 1. <!-- Swagger --> 2. <dependency> 3. <groupId>io.springfox</groupId> 4. <artifactId>springfox-swagger-ui</artifactId> 5. <version>2.9.2</version> 6. </dependency> 7. <dependency> 8. <groupId>io.springfox</groupId> 9. <artifactId>springfox-swagger2</artifactId> 10. <version>2.9.2</version> 11. </dependency> 增加聚合代码： 1. @EnableSwagger2 2. @Component 3. @Primary 4. public class DocumentationConfig implements SwaggerResourcesProvider { 5. 6.

开源 Spring Boot 中 Mongodb 多数据源扩展框架 原创 尹吉欢 猿天地 2019-04-25 在日常工作中，我们通过Spring Data Mongodb来操作Mongodb数据库，在Spring Boot中只需要引入spring-boot-starter-data-mongodb即可。 然后配置连接信息如下： 1. spring.data.mongodb.uri=mongodb://localhost:27017/test 或者 1. pring.data.mongodb.authentication-database= # Authentication database name. 2. spring.data.mongodb.database=test # Database name. 3. spring.data.mongodb.host=localhost # Mongo server host. 4. spring.data.mongodb.password= # Login password of the mongo server. 5. spring.data.mongodb.port=27017 # Mongo server port. 6. spring.data.mongodb.username= # Login user of the