1月31日 · 2021年
面试 6 家公司，拿下三个大厂 offer
4189 11 3
11月23日 · 2020年
基于 Redisson 实现切面分布式锁（升级版）
2483 5 0
11月8日 · 2020年
使用 Feign 调用分页接口报错：Method has too many Body parameters
4626 5 2
11月29日 · 2019年
数据迁移后的一致性校验
10863 20 2
9月2日 · 2020年
多数据源下的单元测试优化
1985 3 0
12月5日 · 2019年
MySQL 中 redo log、undo log、binlog 的总结
21988 30 8
3月17日 · 2020年
Redis中通过scan命令获取key、value【Java实现】
11771 19 6
12月1日 · 2019年
本站事故复盘
2856 61 2
9月7日 · 2020年
Sharding-JDBC 支持动态扩容及刷新 ActualDataNodes
13686 21 6
12月18日 · 2019年
异步并发利器：CompletableFuture、parallelStream
4677 8 0
Java 开发More
前面写过一篇通过 Jdbc + Job 解决跨库大表数据迁移，那只是个初始版本，后面对其进行了优化改造，数据迁移性能大幅度提升。优化点单实例 Job 优化为多实例 Job单线程优化为多线程普通偏移优化为分段偏移... 
线上 JVM 堆内存不足引发BeanCreationNotAllowedException背景某个周六的中午，领导突然找我说线上有大量报错，让我看一下。我发现日志中出现了很多下面的报错信息，而且持续了一段时间（后面才发现收到了告警邮件，但是当时手机没有提醒，强行甩锅...）：... 
七层负载均衡：基于虚拟的 URL 或主机 IP 的负载均衡 。在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的 Web 服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如 HTTP 协议 URI 或 Cookie 信息，实现七层负载均衡。此种负载均衡器能理解应用协议。... 
将 scala 项目重构为 Java 微服务，在进行读迁移时，其中有一块业务数据量是亿级别的，需要进行跨库数据迁移（注意：表结构发生了很大变化），并且在迁移过程中尽量做到不停服迁移。针对亿级别的数据量级，肯定不能使用脚本迁移的方式迁移，更不可能使用 mysqldump 命令进行导入导出进行数据迁移。网上还有以导入导出文件的形式迁移百万级数据，但是这个操作需要修改 mysql 的配置，保险起见，直接 pass ...最终，选择通过 Jdbc 配合 Job 在双写阶段进行数据迁移，待数据迁移基本完毕，并且数据一致性校验没问题后，再进行读迁移的上线（此时，只需要业务方上线，将读切换到现在的微服务即可）。... 
一个 @Transactional 修饰的方法A 的内部要调用另一个用 @Async 修饰的方法B，并且方法B 要在方法A 的事务提交之后，异步执行，大概就是下面代码这样。方法A 和 方法B 假如在同一个类中，则方法B 的 @Async 注解会失效：首先解释下 @Transactional 注解失效的原因：Spring 在扫描 bean 的时候会扫描方法上是否包含 @Transactional 注解，如果包含..... 水平分表完成业务代码后，在运行单元测试时，出现了以下两个问题：事务不回滚性能极差：200 个单元测试方法，分表之前，平均耗时 12 分钟左右，分表之后，耗时 50 分钟左右...解释下，分表之前耗时 12 分钟左右的大概原因：对于持久层代码，没有 mock，直接走的 DB单元测试未使用 H2 等内存数据库，因为有一些操作 H2 不支持其它历史问题，下面会提及...
3月20日 · 2020年
[升级版]通过 Jdbc + Job 解决跨库大表数据迁移
2620 10 0
3月29日 · 2020年
线上 JVM 堆内存不足引发BeanCreationNotAllowedException
2674 10 0
8月15日 · 2020年
OSI七层模型、TCP/IP四层模型
1311 2 0
1月27日 · 2020年
通过 Jdbc + Job 解决跨库大表数据迁移
3564 6 0
1月9日 · 2020年
@Transactional 事务提交之后执行 @Async 修饰的方法
6510 8 0
9月2日 · 2020年
多数据源下的单元测试优化
1985 3 0
数据库More目前正在对 scala 项目(某块业务)重构，重构成 Java 微服务，业务、表设计都有些许变化，其中涉及到数据迁移，简单来说就是从老表迁到新表(表结构发生了变化)。为了保证迁移前后数据的一致性，需要进行一些必要的验证。本文主要讨论下自己在进行数据一致性校验时用到的方法，仅仅作为一种数据验证的思路，分享给大家，内容可能有一些瑕疵，欢迎大家指正。... 
今天在用 JOOQ 生成代码的时候，即运行 mvn clean install 命令时，出现以下错误，代码中指定的驱动明明是“com.mysql.jdbc.Driver”，但是报错信息中显示的确是驱动“com.mysql.cj.jdbc.Driver”。经搜索，com.mysql.jdbc.Driver 是 mysql-connector-java 5 中的com.mysql.cj.jdbc.Driver 是 mysql-connector-java 6 及以上版本中的..... 
移动互联网时代，随着软件用户量的不断增长，由此产生的数据量也在飞速增长，比如，用户表、订单表、聊天消息表等。据统计，MySQL单表可以存储10亿级数据，只是这时性能比较差，业界公认MySQL单表容量在1KW量级是最佳状态，因为这时它的BTREE索引树高在3~5之间。既然一张表无法搞定，那么就想办法将数据放到多个地方，目前比较普遍的方案有3个：分区要求数据不是海量（分区数有限，存储能力就有限）业务并发能力要求不高分库分表互联网行业处理海量数据的通用方法发展几十年的RDBMS（关系型数据库）具有生态完善、绝对稳定、事务特性的优点，只要有软件的地方，它都是核心存储的首选NoSQL/NewSQLNoSQL/NewSQL宣传的无论多厉害，就现在各大公司对它的定位，都是RDBMS的补充，而不是取而代之... 本文主要总结下重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）的概念。redo log 是物理日志，undo log 和 binlog 是逻辑日志，物理日志的恢复速度远快于逻辑日志。innodb 事务日志包括 redo log 和 undo log，redo log 是重做日志，提供前滚操作，undo log 是回滚日志，提供回滚操作。... 将 scala 项目重构为 Java 微服务，在进行读迁移时，其中有一块业务数据量是亿级别的，需要进行跨库数据迁移（注意：表结构发生了很大变化），并且在迁移过程中尽量做到不停服迁移。针对亿级别的数据量级，肯定不能使用脚本迁移的方式迁移，更不可能使用 mysqldump 命令进行导入导出进行数据迁移。网上还有以导入导出文件的形式迁移百万级数据，但是这个操作需要修改 mysql 的配置，保险起见，直接 pass ...最终，选择通过 Jdbc 配合 Job 在双写阶段进行数据迁移，待数据迁移基本完毕，并且数据一致性校验没问题后，再进行读迁移的上线（此时，只需要业务方上线，将读切换到现在的微服务即可）。... 
前段时间，在 scala 项目的某块业务迁移到微服务上线前，测试环境意外地发生了两次死锁问题，触发死锁的原因不同，一次是因为数据迁移不到位，由更新操作导致，解决方式是重写 update 方法。另一个是因为前人写的代码太过于随意，一个事务中包含了多个模版方法，由不同的子类去实现方法，后人在实现时，有可能并不知道自己实现的方法是被嵌套在事务中的，从而扩展了很多操作，操作中不乏有耗时的远程调用，从而一个小事务被慢慢积累成一个大事务，最终导致了死锁，由于老业务（scala 项目）很复杂，当时解决的方式是将死锁的方法异步处理。从那之后，自己断断续续做了一些关于 MySQL 并发相关的笔记，本文先梳理下 MySQL 控制并发访问的两种手段（MVCC 和几种常用锁）。...
11月29日 · 2019年
数据迁移后的一致性校验
10863 20 2
12月15日 · 2019年
Error running jOOQ code generation tool: com.mysql.cj.jdbc.Driver..
3534 8 0
9月29日 · 2020年
谈谈分库分表的几个核心流程
2652 10 0
12月5日 · 2019年
MySQL 中 redo log、undo log、binlog 的总结
21988 30 8
1月27日 · 2020年
通过 Jdbc + Job 解决跨库大表数据迁移
3564 6 0
12月10日 · 2019年
MySQL 常用锁和 MVCC 总结
4510 12 0
中间件More
一、ES 分布式架构原理 ES设计的理念是分布式搜索引擎，底层实现基于Lucene，核心思想是在多台机器上启动多个ES进程实例，组成一个ES集群。 概念描述 接近实时：ES是一个接近实时的搜索平台，这就意味着，从存入一个文档直到文档能够被搜索到有一个轻微的延迟 集群（cluster）：一个集群由多个节点（服务器）组成，所有节点一起保存全部数据，每一个集群有一个唯一的名称标识... 需求：通过 Job 每秒去 Redis 中获取 Key 前缀为：“message:xxx:yyy:id: ”的所有 Value，Value以字符串类型存储，键值对存储量级：几百万。 Redis中有一个经典的问题，在巨大的数据量的情况下，做类似于查找符合某种规则的 Key 的信息，有两种方式：1、通过 keys 命令，简单粗暴，由于Redis单线程这一特性，keys 命令以阻塞的方式执行。keys 命令通过遍历查找，时间复杂度是 O(n）。Redis 库中 key 的数量越多，查找实现的代价越大，产生阻塞的时间越长。2、通过 scan 命令，以非阻塞的方式实现 key 值的查找，绝大多数情况下是可以替代 keys 命令的，可选性更强。... 
在完成 MQ 的发送方代码后，通过单元测试(mock 方式)发现发送方代码是没有问题的，但是通过 JOB 发送消息就一直提示“Listener not registered..”，又通过 http 直接调用接口来发送消息，也是提示“Listener not registered..”，然后各种检查配置、各种谷歌都无济于事，最后只能 debug 源码了。... 
分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁实现，如果不同的系统或同一个系统的不同主机之间共享了某个资源时，往往需要互斥来防止彼此干扰来保证一致性。由于线上出现了并发问题，导致出现了很多脏数据，分布式环境下，考虑到乐观锁无法解决，也只能请教于分布式锁了。实现分布式锁的方式有：数据库乐观锁、基于 Redis 的分布式锁..... 之前使用过Redis作为分布式锁，但是因为本身特性的局限性，存在很多隐患，故将Redis替换成了Redisson。（由于公司直接买的腾讯云的Redis，对于开发者来说，它是单实例的，屏蔽了内部的底层实现，故本文暂且只考虑Redis是单实例的场景，如果想要了解在多实例情况下，基于Redis/Redisson作为分布式锁，可以自行搜索RedLock的具体实现，也很简单）。...
11月1日 · 2020年
Elasticsearch 常规概念及底层原理
2390 5 0
3月17日 · 2020年
Redis中通过scan命令获取key、value【Java实现】
11771 19 6
11月29日 · 2019年
RabbitMQ 发消息报错 Listener not registered
55996 19 1
12月7日 · 2019年
基于 Redis 实现分布式锁
2969 6 0
11月23日 · 2020年
基于 Redisson 实现切面分布式锁（升级版）
2483 5 0
算法相关More
朋友圈 班上有 N 名学生。其中有些人是朋友，有些则不是。他们的友谊具有是传递性。如果已知 A 是 B 的朋友，B 是 C 的朋友，那么我们可以认为 A 也是 C 的朋友。所谓的朋友圈，是指所有朋友的集合。给定一个 N * N 的矩阵 M，表示班级中学生之间的朋友关系。如果M[i][j] = 1，表示已知第 i 个和 j 个学生互为朋友关系，否则为不知道。你必须输出所有学生中的已知的朋友圈总数。来源：力扣（LeetCode）链接：https://leetcode-cn.com/problems/friend-circles著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。... 
一、路径总和 I 递归 public boolean hasPathSum(TreeNode root, int sum) { if (root == null) { return false; } if (root.left == null && root.right == null) { return root.val == sum; } return hasPathSum(root.left, sum - root.val) || hasPathSum(root.right, sum - root.val);}...
11月1日 · 2020年
朋友圈问题
1532 2 0
10月25日 · 2020年
路径总和问题
1485 5 0
