Java开发面试技能介绍，mysql主从配置原理

迷南。 2021-07-20 14:40 312阅读 0赞

# 前言 #

今天中午收到我司安全部发了一封邮件：Jackson存在安全漏洞。查了一下，这件事并不算很新鲜了（已经过了5天的样子），本文来聊聊吧。

说起来还蛮戏剧化：阿里云向Jackson官方提交了一个Jackson序列化安全漏洞。众所周知，在国内关于JSON库使用有两大主要阵营：**国际著名的Jackson库**和**国内阿里巴巴出品的Fastjson**。

同样的功能定位，不存在竞争想想也觉得不可能嘛。所以当我看到这个漏洞竟是阿里云上报的，就觉得这关系还蛮微妙呢，默默的腹黑了3秒钟，哈哈。

附：FasterXML/jackson-databind是一个简单基于Java应用库，Jackson可以轻松的将Java对象转换成json对象和xml文档，同样也可以将json、xml转换成Java对象。Jackson是美国FasterXML公司的一款适用于Java的数据处理工具。jackson-databind是其中的一个具有数据绑定功能的组件。

### 分布式锁的坑 ###

**高并发场景下的问题**

以下问题不是说在并发不高的场景下不容易出现，只是在高并发场景下出现的概率更高些而已。

**性能问题来自于以下两方面：**

\*\*①获取锁的时间上。\*\*如果 Redlock 运用在高并发的场景下，存在 N 个 Master 节点，一个一个去请求，耗时会比较长，从而影响性能。

这个好解决，通过上面描述不难发现，从多个节点获取锁的操作并不是一个同步操作，可以是异步操作，这样可以多个节点同时获取。

即使是并行处理的，还是得预估好获取锁的时间，保证锁的 TTL>获取锁的时间+任务处理时间。

\*\*②被加锁的资源太大。\*\*加锁的方案本身就是会为了正确性而牺牲并发的，牺牲和资源大小成正比，这个时候可以考虑对资源做拆分。

**拆分的方式有如下两种：**

\*\*①从业务上将锁住的资源拆分成多段，每段分开加锁。\*\*比如，我要对一个商户做若干个操作，操作前要锁住这个商户，这时我可以将若干个操作拆成多个独立的步骤分开加锁，提高并发。

\*\*②用分桶的思想，将一个资源拆分成多个桶，一个加锁失败立即尝试下一个。\*\*比如批量任务处理的场景，要处理 200w 个商户的任务，为了提高处理速度，用多个线程，每个线程取 100 个商户处理，就得给这 100 个商户加锁。

如果不加处理，很难保证同一时刻两个线程加锁的商户没有重叠，这时可以按一个维度。

比如某个标签，对商户进行分桶，然后一个任务处理一个分桶，处理完这个分桶再处理下一个分桶，减少竞争。

\*\*重试的问题：\*\*无论是简单实现还是 Redlock 实现，都会有重试的逻辑。

如果直接按上面的算法实现，是会存在多个 Client 几乎在同一时刻获取同一个锁，然后每个 Client 都锁住了部分节点，但是没有一个 Client 获取大多数节点的情况。

解决的方案也很常见，在重试的时候让多个节点错开，错开的方式就是在重试时间中加一个随机时间。这样并不能根治这个问题，但是可以有效缓解问题，亲试有效。

**节点宕机**

对于单 Master 节点且没有做持久化的场景，宕机就挂了，这个就必须在实现上支持重复操作，自己做好幂等。对于多 Master 的场景，比如 Redlock，我们来看这样一个场景：

*  假设有 5 个 Redis 的节点：A、B、C、D、E，没有做持久化。
 *  Client1 从 A、B、C 这3 个节点获取锁成功，那么 client1 获取锁成功。
 *  节点 C 挂了。
 *  Client2 从 C、D、E 获取锁成功，client2 也获取锁成功，那么在同一时刻 Client1 和 Client2 同时获取锁，Redlock 被玩坏了。

怎么解决呢？最容易想到的方案是打开持久化。持久化可以做到持久化每一条 Redis 命令，但这对性能影响会很大，一般不会采用，如果不采用这种方式，在节点挂的时候肯定会损失小部分的数据，可能我们的锁就在其中。

另一个方案是延迟启动。就是一个节点挂了修复后，不立即加入，而是等待一段时间再加入，等待时间要大于宕机那一刻所有锁的最大 TTL。

但这个方案依然不能解决问题，如果在上述步骤 3 中 B 和 C 都挂了呢，那么只剩 A、D、E 三个节点，从 D 和 E 获取锁成功就可以了，还是会出问题。

那么只能增加 Master 节点的总量，缓解这个问题了。增加 Master 节点会提高稳定性，但是也增加了成本，需要在两者之间权衡。

**任务执行时间超过锁的 TTL**

之前产线上出现过因为网络延迟导致任务的执行时间远超预期，锁过期，被多个线程执行的情况。

这个问题是所有分布式锁都要面临的问题，包括基于 Zookeeper 和 DB 实现的分布式锁，这是锁过期了和 Client 不知道锁过期了之间的矛盾。

在加锁的时候，我们一般都会给一个锁的 TTL，这是为了防止加锁后 Client 宕机，锁无法被释放的问题。

但是所有这种姿势的用法都会面临同一个问题，就是没法保证 Client 的执行时间一定小于锁的 TTL。

虽然大多数程序员都会乐观的认为这种情况不可能发生，我也曾经这么认为，直到被现实一次又一次的打脸。

![c5d2858e4cfde453a750608a62a8ee30.png][]

Martin Kleppmann 也质疑过这一点，这里直接用他的图：

*  Client1 获取到锁。
 *  Client1 开始任务，然后发生了 STW 的 GC，时间超过了锁的过期时间。
 *  Client2 获取到锁，开始了任务。
 *  Client1 的 GC 结束，继续任务，这个时候 Client1 和 Client2 都认为自己获取了锁，都会处理任务，从而发生错误。

Martin Kleppmann 举的是 GC 的例子，我碰到的是网络延迟的情况。不管是哪种情况，不可否认的是这种情况无法避免，一旦出现很容易懵逼。

如何解决呢？一种解决方案是不设置 TTL，而是在获取锁成功后，给锁加一个 watchdog，watchdog 会起一个定时任务，在锁没有被释放且快要过期的时候会续期。

### 最后 ###

在面试前我整理归纳了一些面试学习资料，文中结合我的朋友同学面试美团滴滴这类大厂的资料及案例  
**感兴趣的朋友可以[点击Java学习][Java]免费获取。**  
![36ef8d8d505c44f7db24ff52340e0e48.png][]

![MyBatis答案解析][MyBatis]  
**由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！**

大家看完有什么不懂的可以在下方留言讨论也可以关注。

觉得文章对你有帮助的话记得关注我点个赞支持一下！

料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！\*\*

大家看完有什么不懂的可以在下方留言讨论也可以关注。

觉得文章对你有帮助的话记得关注我点个赞支持一下！

[c5d2858e4cfde453a750608a62a8ee30.png]: /images/20210720/5ea0dda6ee014b98aff6aa0b3294f52e.png
[Java]: https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB
[36ef8d8d505c44f7db24ff52340e0e48.png]: /images/20210720/ab22e1ca000346b192d7f5b466e9101b.png
[MyBatis]: /images/20210720/c460394ce606472eb6ecc09e809bf622.png