「十项全能」的 ChatGPT ，用起来感受如何？

之前，作为 ChatGPT Plus 用户，如果你集齐下面这五个模式，就会成为别人羡慕的对象。

但现在，人们更加期盼的，是下面这个提示的出现：

这个提示，意味着你的 GPT-4 已经不再是「一专」（只能使用某一模式），而是「多能」（根据需要自动调用不同模式的功能）。

例如你可以让 ChatGPT 看到一幅图（原本的基础模式），然后让它自动理解总结图片的内容，并且要求它绘制出类似的图片（原本的 DALLE）模式。当然，你还可以让它自动编程（原本的 Data 模式）或者访问网络（原本的 Browse with Bing 或者插件模式）。

这样一来，用户的想象力就可以变成特别有趣有用的实践过程。例如王佩老师，就让 ChatGPT 绘制简笔画。他对绘制结果很满意。

见贤思齐，于是我又把自己的微信头像传上去了。要求 ChatGPT (GPT-4 All Tools）：

画成皮克斯风格

于是，我获得了这样的图像：

呃，除了人物不像我，以及背景多了一只狐狸，我没有啥可抱怨的……

同时生成的，还有另外一幅作品。咱们也放大看看。

可这…… 也太不像我了啊。于是，我提出了这样的要求：

画成皮克斯风格，注意人物一定要像。

这次 GPT-4 全模式 (All Tools) 的绘图结果是这样的：

这个…… 你要非得说像我，我无话可说。

我查看了对应的提示词：

Photo of a man , wearing a light blue polo shirt and a . He is Asian, with short black hair, smiling warmly with a of covered with green and reddish trees under a cloudy sky. The image should be into a Pixar-style , the and of the person, but with the and typical of Pixar .

对应的翻译为：

一张快乐男子在户外的照片，他穿着浅蓝色的 Polo 衫，背着背包。他是亚洲人，有短黑发，背景是山脉，山上覆盖着绿色和红色的树木，天空多云。他的笑容温暖。这张图片应该被转化为皮克斯风格的动画，保持人物的相似性和表情，但具有皮克斯动画典型的迷人和异想天开的特点。

我旋即明白了，图片画得不像我，就是 ChatGPT 识图后总结提示词的原因。这里只描述为「亚洲人」、「快乐男子」和「短黑发」，至于脸型、五官之类的，丝毫没有涉及，那当然没有办法「完美复刻」了。

我在视频中提到了这个问题。有观众提示我说可能是在上传人像的时候，ChatGPT自动做了面部模糊化处理以保护人物肖像权，我觉得非常有道理。回头我准备找个卡通头像上传上去试试看。

看完了这个有趣的例子，咱们该讲讲严肃的事儿了 —— 如何利用 GPT-4 全模式 (All Tools) 帮助你更好地学习和工作？

学习

咱们先从一个最常见的场景开始 —— 上课的时候，看到课件里面的英文不会，该怎么办？

这时候，你可以拍张照或者截屏，让 GPT-4 全模式 (All Tools) 帮助你来翻译。上面这张幻灯截图，它的翻译如下：

描述了使用大语言模型（LLM）时的提示（）能做什么。图片中提到，如果给一个刚刚毕业的大学生一些指导，他们是否能够完成任务。为了更加清晰明了，假设情况如下：

没有互联网或其他资源的访问权限

对你的公司 / 业务没有特定的培训

没有完成先前任务的记忆

每次都会得到一个不同的新毕业的大学生

图片旨在探讨在没有额外资源和指导的情况下，一个新毕业的大学生是否能够根据给定的指导完成任务。

你可能对此不屑一顾 —— 这简单的翻译功能，我手机上的 XX 应用，早就有了。

没错，但是 ChatGPT 可不仅仅会翻译哦。你看到一页幻灯，如果对其中内容有不清楚的地方，可以立即呼唤你的这个「私人助教」来帮忙总结和解答。例如下面这页幻灯，是吴恩达老师在新课程 AI for 中对「监督学习」应用的总结。

我截图发给 GPT-4 全模式 (All Tools) ，要求用中文总结图中内容。

这是 GPT-4 的回答：

这张图片是 Andrew Ng 在讲解监督学习的应用。图片中列出了不同的输入、输出和相应的应用场景。例如，输入可以是电子邮件，输出是判断这封邮件是否为垃圾邮件，应用场景是垃圾邮件过滤。其他的应用还包括在线广告、自动驾驶车辆的其他车辆位置识别、医疗诊断、视觉检测、语音识别和餐厅评论的情感分析等。每个应用都涵盖了将输入数据（如图像、广告和用户信息、音频记录等）转换为有意义输出（如诊断、缺陷检测、文本转录等）的过程。

你看，ChatGPT 打通各个模式之后，拿来当助教非常合适，讲解耐心不厌其烦。更妙的是，你不仅可以让它识别幻灯帮你讲解，还能要求它立即给你写出对应例子的程序代码来。

编程

例如我刚刚听完 GPT-4 全模式 (All Tools) 的总结，依然对监督学习没有形象的概念。于是我下面的提示语为：

就找上面的一个例子，给我写一段监督学习的 Python 代码

ChatGPT 就立即开始干活儿了。

在你看到代码之后，是不是对监督学习的模型训练流程概念理解更加清晰了呢？有了这种快速支援，相信你学东西会更加扎实，疑问也能更及时得到解决。

况且你不要忘了，GPT-4 全模式 (All Tools) 还包含了 Data 模式，也就是可以把程序直接作用在数据集上面，帮助你实验，甚至解决实际的问题。下面我们就来看看如何用 ChatGPT 来「看到」实际的数据，并且进行分析。

数据分析

我这里举的例子，也来自于吴恩达老师的新课。他提到了很有意思的问题 ——LLM 对结构化数据处理不好。

我觉得这个观察很有意思，但是将信将疑，于是立即就把数据截取出来尝试。我问 ChatGPT ：

这个表格里面有对应的面积和价格，那么 900 sqft 的房子，对应的价格是多少？请一步步思考，并且详细说明你的解题过程

下面是 ChatGPT 的回答：

你看，要公式有公式，要代码有代码。数据齐全，分析清晰。只可惜，这个线性插值计算方法并不完美，因为利用数据太少了。为了帮助 ChatGPT 改进结果，咱们还可以这样来追问：

好，但是你能否充分利用上全部数据来建模并且测算呢？

ChatGPT 旋即给了答案。

如果你希望了解 ChatGPT 如何计算，还可以点开被折叠的工作区，查看对应代码。

你看，原先表格中的所有数据，确实都被使用了进来。但是，这个计算的结果是否正确？希望你能够检验一下，然后在留言区给出自己的判定答案。

论文阅读

下面这个功能，更是很多小伙伴期待已久的 —— 你可以直接把 PDF 格式的文档扔给 ChatGPT 了。GPT-4 全模式 (All Tools) 可以自动识别其中的内容，并且进行分析和回答你提出的问题。

例如，我从 下载了 MemGPT 论文的全文。

然后，我把它扔给 GPT-4 全模式 (All Tools) ，提出的要求为：

给我介绍一下这篇文章的亮点

这是 ChatGPT （速度很快）读过文章后，给出的结果。

我们让 ChatGPT 简单翻译一下前面几段：

论文《MemGPT: 朝着作为操作系统的 LLMs》介绍了一种旨在克服当前大型语言模型（LLMs）的有限上下文窗口限制的新系统。以下是其亮点的详细说明：

1.虚拟上下文管理：作者引入了一种技术，通过借鉴传统操作系统中的分层存储系统，扩展了LLMs的可用上下文范围，超越了标准固定长度上下文窗口的限制。这种技术被称为虚拟上下文管理，通过在快速和慢速存储层之间的数据移动，实现了更大内存的幻象。

2.MemGPT系统：基于这种技术，派生出了MemGPT系统，它利用分层存储结构和中断来管理LLM、存储器和用户之间的数据流和控制。该系统可以在任务进行过程中调整上下文，更有效地利用有限的上下文。

3.在文档分析和对话代理方面的性能：论文展示了MemGPT在文档分析和多会话聊天领域的增强性能。它能够分析大量文档并保持长期交互，超越了LLM的上下文窗口限制。

很好，这至少证明 ChatGPT 看懂了 PDF 论文全文内容。你也可以就文本内容提出问题，让它来回答。不过类似的内容，我在讲 Chatdoc 的时候都演示过了。这回咱们要充分利用它的全模式功能，搞点儿新花样。

我要求：

把上述内容，用图展示出来，要求让一个中学生能够看懂

于是 ChatGPT 这样绘制：

我们放大一下第一张图。

这张图非常有趣。它知道论文主角是一个机器大脑，要解决的问题是记忆体的限制。图中主体设计成一种类似操作系统的架构，上面是个戴学士帽的机器人。联接的小图都是与上下文、记忆体、检索能力相关，还提到了「快速」等特性。另外还有很多相关的文字作为讲解介绍。

当然了，这个图的毛病，也是显而易见的。例如说里面出现了很多奇怪的单词，都像是半文盲写的 —— 有很多拼写错误。不过你不用担心，这只是个开始。你要相信 LLM 的演进速度。

绘图做完了，咱们尝试一下表格数据的读取。这里我选择了 Table 2 的内容作为样例。

我要求 ChatGPT 来总结其内容，并且进行可视化：

这里咱们看看其操作过程的细节。

首先， ChatGPT 确实在上传的 PDF 里面，找到了表格 2 对应的位置和内容。

然后，ChatGPT 进行了编程计算，最终给出了下图的结果。

初看这张图，你可能会很不以为然。没错，这张图确实画错了。F1, 和 Recall 如果真的这么惨不忍睹，也就没有汇报的必要了。但是，这错误也是有原因的。

原始论文中，对 （准确率）和其他三个指标，表现形式就不一样 —— 前者是百分数，后者是小数。目前 ChatGPT 对于同一表格不同列数据这种转换，还没有做到灵活自如，因此才会出这样的纰漏。

但是你看到，不论是模型类型、图例说明和对应数据，ChatGPT 在读取表格的时候，确实已经尽可能做到了一一对应。因此，只要你在后续对话中稍加提示，绘图效果就会大不一样。

所以，现在的 GPT-4 全模式 (All Tools) 确实是可以「看到」图和表，这对于我们来说，意义很大 —— 论文中出现的数据，你至少可以更为灵活自如地进行二次分析与验证了。

小结

本文我为你介绍了自己使用 GPT-4 全模式 (All Tools) 来辅助工作和学习的一些心得体会。总体来说，ChatGPT 全模式打通之后，可以更方便调用各种「艺能」。它可以帮助你更快速理解消化新信息、按照你的个性化要求给出样例，根据上下文做出总结问答，并且帮你进行自动数据分析。希望这些功用的分享，可以帮助你更高效地完成任务，获得新知。

祝（更强悍的）AI 工具使用愉快！

点赞 +「在看」，转发给你身边有需要的朋友。收不到推送？那是因为你只订阅，却没有加星标。

欢迎订阅我的小报童付费专栏，每季度更新不少于10篇文章。订阅一整年价格优惠。

如果有问题咨询，或者希望加入社群和热爱钻研的小伙伴们一起讨论，订阅知识星球吧。不仅包括小报童的推送内容，还可以自由发帖与提问。之前已经积累下的帖子和问答，就有数百篇。足够你好好翻一阵子。知识星球支持72小时内无条件退款，所以你可以放心尝试。

若文中部分链接可能无法正常显示与跳转，可能是因为微信公众平台的外链限制。如需访问，请点击文末「阅读原文」链接，查看链接齐备的版本。

Redis中一个你绝对没用过，但是特别好用性能炸裂的数据结构，分享！

你没看错，在删除一个 key 时，如果姿势不对，也有可能影响到 Redis 性能。

删除一个 key，我们通常使用的是 DEL 命令，回想一下，你觉得 DEL 的时间复杂度是多少？

O(1) ？其实不一定。

当你删除的是一个 String 类型 key 时，时间复杂度确实是 O(1)。

但当你要删除的 key 是 List/Hash/Set/ZSet 类型，它的复杂度其实为 O(N)，N 代表元素个数。

也就是说，删除一个 key，其元素数量越多，执行 DEL 也就越慢！

原因在于，删除大量元素时，需要依次回收每个元素的内存，元素越多，花费的时间也就越久！

而且，这个过程默认是在主线程中执行的，这势必会阻塞主线程，产生性能问题。

那删除这种元素比较多的 key，如何处理呢？

我给你的建议是，分批删除：

没想到吧？一个小小的删除操作，稍微不小心，也有可能引发性能问题，你在操作时需要格外注意。

6) 批量命令代替单个命令

当你需要一次性操作多个 key 时，你应该使用批量命令来处理。

批量操作相比于多次单个操作的优势在于，可以显著减少客户端、服务端的来回网络 IO 次数。

所以我给你的建议是：

7) 避免集中过期 key

Redis 清理过期 key 是采用定时 + 懒惰的方式来做的，而且这个过程都是在主线程中执行。

如果你的业务存在大量 key 集中过期的情况，那么 Redis 在清理过期 key 时，也会有阻塞主线程的风险。

想要避免这种情况发生，你可以在设置过期时间时，增加一个随机时间，把这些 key 的过期时间打散，从而降低集中过期对主线程的影响。

8) 使用长连接操作 Redis，合理配置连接池

你的业务应该使用长连接操作 Redis，避免短连接。

当使用短连接操作 Redis 时，每次都需要经过 TCP 三次握手、四次挥手，这个过程也会增加操作耗时。

同时，你的客户端应该使用连接池的方式访问 Redis，并设置合理的参数，长时间不操作 Redis 时，需及时释放连接资源。

9) 只使用 db0

尽管 Redis 提供了 16 个 db，但我只建议你使用 db0。

为什么呢？我总结了以下 3 点原因：

在一个连接上操作多个 db 数据时，每次都需要先执行 SELECT，这会给 Redis 带来额外的压力

使用多个 db 的目的是，按不同业务线存储数据，那为何不拆分多个实例存储呢？拆分多个实例部署，多个业务线不会互相影响，还能提高 Redis 的访问性能

Redis Cluster 只支持 db0，如果后期你想要迁移到 Redis Cluster，迁移成本高

10) 使用读写分离 + 分片集群

如果你的业务读请求量很大，那么可以采用部署多个从库的方式，实现读写分离，让 Redis 的从库分担读压力，进而提升性能。

如果你的业务写请求量很大，单个 Redis 实例已无法支撑这么大的写流量，那么此时你需要使用分片集群，分担写压力。

11) 不开启 AOF 或 AOF 配置为每秒刷盘

如果对于丢失数据不敏感的业务，我建议你不开启 AOF，避免 AOF 写磁盘拖慢 Redis 的性能。

如果确实需要开启 AOF，那么我建议你配置为 ，把数据持久化的刷盘操作，放到后台线程中去执行，尽量降低 Redis 写磁盘对性能的影响。

12) 使用物理机部署 Redis

Redis 在做数据持久化时，采用创建子进程的方式进行。

而创建子进程会调用操作系统的 fork 系统调用，这个系统调用的执行耗时，与系统环境有关。

虚拟机环境执行 fork 的耗时，要比物理机慢得多，所以你的 Redis 应该尽可能部署在物理机上。

13) 关闭操作系统内存大页机制

Linux 操作系统提供了内存大页机制，其特点在于，每次应用程序向操作系统申请内存时，申请单位由之前的 4KB 变为了 2MB。

这会导致什么问题呢？

当 Redis 在做数据持久化时，会先 fork 一个子进程，此时主进程和子进程共享相同的内存地址空间。

当主进程需要修改现有数据时，会采用写时复制（Copy On Write）的方式进行操作，在这个过程中，需要重新申请内存。

如果申请内存单位变为了 2MB，那么势必会增加内存申请的耗时，如果此时主进程有大量写操作，需要修改原有的数据，那么在此期间，操作延迟就会变大。

所以，为了避免出现这种问题，你需要在操作系统上关闭内存大页机制。

好了，以上这些就是 Redis 「高性能」方面的实践优化。如果你非常关心 Redis 的性能问题，可以结合这些方面针对性优化。

我们再来看 Redis 「可靠性」如何保证。

如何保证 Redis 的可靠性？

这里我想提醒你的是，保证 Redis 可靠性其实并不难，但难的是如何做到「持续稳定」。

下面我会从「资源隔离」、「多副本」、「故障恢复」这三大维度，带你分析保障 Redis 可靠性的最佳实践。

1) 按业务线部署实例

提升可靠性的第一步，就是「资源隔离」。

你最好按不同的业务线来部署 Redis 实例，这样当其中一个实例发生故障时，不会影响到其它业务。

这种资源隔离的方案，实施成本是最低的，但成效却是非常大的。

2) 部署主从集群

如果你只使用单机版 Redis，那么就会存在机器宕机服务不可用的风险。

所以，你需要部署「多副本」实例，即主从集群，这样当主库宕机后，依旧有从库可以使用，避免了数据丢失的风险，也降低了服务不可用的时间。

在部署主从集群时，你还需要注意，主从库需要分布在不同机器上，避免交叉部署。

这么做的原因在于，通常情况下，Redis 的主库会承担所有的读写流量，所以我们一定要优先保证主库的稳定性，即使从库机器异常，也不要对主库造成影响。

而且，有时我们需要对 Redis 做日常维护，例如数据定时备份等操作，这时你就可以只在从库上进行，这只会消耗从库机器的资源，也避免了对主库的影响。

3) 合理配置主从复制参数

在部署主从集群时，如果参数配置不合理，也有可能导致主从复制发生问题：

在这方面我给你的建议有以下 2 点：

设置合理的 repl-backlog 参数：过小的 repl-backlog 在写流量比较大的场景下，主从复制中断会引发全量复制数据的风险

设置合理的 slave client-output-buffer-limit：当从库复制发生问题时，过小的 buffer 会导致从库缓冲区溢出，从而导致复制中断

4) 部署哨兵集群，实现故障自动切换

只部署了主从节点，但故障发生时是无法自动切换的，所以，你还需要部署哨兵集群，实现故障的「自动切换」。

而且，多个哨兵节点需要分布在不同机器上，实例为奇数个，防止哨兵选举失败，影响切换时间。

以上这些就是保障 Redis「高可靠」实践优化，你应该也发现了，这些都是部署和运维层的优化。

除此之外，你可能还会对 Redis 做一些「日常运维」工作，这时你要注意哪些问题呢？

日常运维 Redis 需要注意什么？

如果你是 DBA 运维人员，在平时运维 Redis 时，也需要注意以下 6 个方面。

1) 禁止使用 KEYS//FLUSHDB 命令

执行这些命令，会长时间阻塞 Redis 主线程，危害极大，所以你必须禁止使用它。

如果确实想使用这些命令，我给你的建议是：

2) 扫描线上实例时，设置休眠时间

不管你是使用 SCAN 扫描线上实例，还是对实例做 bigkey 统计分析，我建议你在扫描时一定记得设置休眠时间。

防止在扫描过程中，实例 OPS 过高对 Redis 产生性能抖动。

3) 慎用 MONITOR 命令

有时在排查 Redis 问题时，你会使用 MONITOR 查看 Redis 正在执行的命令。

但如果你的 Redis OPS 比较高，那么在执行 MONITOR 会导致 Redis 输出缓冲区的内存持续增长，这会严重消耗 Redis 的内存资源，甚至会导致实例内存超过 ，引发数据淘汰，这种情况你需要格外注意。

所以你在执行 MONITOR 命令时，一定要谨慎，尽量少用。

4) 从库必须设置为 slave-read-only

你的从库必须设置为 slave-read-only 状态，避免从库写入数据，导致主从数据不一致。

除此之外，从库如果是非 read-only 状态，如果你使用的是 4.0 以下的 Redis，它存在这样的 Bug：

从库写入了有过期时间的数据，不会做定时清理和释放内存。

这会造成从库的内存泄露！这个问题直到 4.0 版本才修复，你在配置从库时需要格外注意。

5) 合理配置 timeout 和 tcp- 参数

如果因为网络原因，导致你的大量客户端连接与 Redis 意外中断，恰好你的 Redis 配置的 参数比较小，此时有可能导致客户端无法与服务端建立新的连接（服务端认为超过了 ）。

造成这个问题原因在于，客户端与服务端每建立一个连接，Redis 都会给这个客户端分配了一个 client fd。

当客户端与服务端网络发生问题时，服务端并不会立即释放这个 client fd。

什么时候释放呢？

Redis 内部有一个定时任务，会定时检测所有 client 的空闲时间是否超过配置的 timeout 值。

如果 Redis 没有开启 tcp- 的话，服务端直到配置的 timeout 时间后，才会清理释放这个 client fd。

在没有清理之前，如果还有大量新连接进来，就有可能导致 Redis 服务端内部持有的 client fd 超过了 ，这时新连接就会被拒绝。

针对这种情况，我给你的优化建议是：

不要配置过高的 timeout：让服务端尽快把无效的 client fd 清理掉

Redis 开启 tcp-：这样服务端会定时给客户端发送 TCP 心跳包，检测连接连通性，当网络异常时，可以尽快清理僵尸 client fd

6) 调整 时，注意主从库的调整顺序

Redis 5.0 以下版本存在这样一个问题：从库内存如果超过了 ，也会触发数据淘汰。

在某些场景下，从库是可能优先主库达到 的（例如在从库执行 MONITOR 命令，输出缓冲区占用大量内存），那么此时从库开始淘汰数据，主从库就会产生不一致。

要想避免此问题，在调整 时，一定要注意主从库的修改顺序：

直到 Redis 5.0，Redis 才增加了一个配置 replica-ignore-，默认从库超过 不会淘汰数据，才解决了此问题。

好了，以上这些就是「日常运维」Redis 需要注意的，你可以对各个配置项查漏补缺，看有哪些是需要优化的。

接下来，我们来看一下，保障 Redis「安全」都需要注意哪些问题。

Redis 安全如何保证？

无论如何，在互联网时代，安全问题一定是我们需要随时警戒的。

你可能听说过 Redis 被注入可执行脚本，然后拿到机器 root 权限的安全问题，都是因为在部署 Redis 时，没有把安全风险注意起来。

针对这方面，我给你的建议是：

不要把 Redis 部署在公网可访问的服务器上

部署时不使用默认端口 6379

以普通用户启动 Redis 进程，禁止 root 用户启动

限制 Redis 配置文件的目录访问权限

推荐开启密码认证

禁用/重命名危险命令（KEYS//FLUSHDB/CONFIG/EVAL）

只要你把这些做到位，基本上就可以保证 Redis 的安全风险在可控范围内。

至此，我们分析了 Redis 在内存、性能、可靠性、日常运维方面的最佳实践优化。

除了以上这些，你还需要做到提前「预防」。

如何预防 Redis 问题？

要想提前预防 Redis 问题，你需要做好以下两个方面：

合理的资源规划

完善的监控预警

先来说资源规划。

在部署 Redis 时，如果你可以提前做好资源规划，可以避免很多因为资源不足产生的问题。这方面我给你的建议有以下 3 点：

保证机器有足够的 CPU、内存、带宽、磁盘资源

提前做好容量规划，主库机器预留一半内存资源，防止主从机器网络故障，引发大面积全量同步，导致主库机器内存不足的问题

单个实例内存建议控制在 10G 以下，大实例在主从全量同步、RDB 备份时有阻塞风险

再来看监控如何做。

监控预警是提高稳定性的重要环节，完善的监控预警，可以把问题提前暴露出来，这样我们才可以快速反应，把问题最小化。

这方面我给你的建议是：

做好机器 CPU、内存、带宽、磁盘监控，资源不足时及时报警，任意资源不足都会影响 Redis 性能

设置合理的 slowlog 阈值，并对其进行监控，slowlog 过多及时报警

监控组件采集 Redis INFO 信息时，采用长连接，避免频繁的短连接

做好实例运行时监控，重点关注 、、 指标，这些指标短时突增可能会有阻塞风险

总结

好了，总结一下，这篇文章我带你全面分析了 Redis 最佳实践的优化路径，其中包括内存资源、高性能、高可靠、日常运维、资源规划、监控、安全 7 个维度。

这里我画成了思维导图，方便你在实践时做参考。

我还把这些实践优化，按照「业务开发」和「运维」两个维度，进一步做了划分。

并且以「强制」、「推荐」、「参考」3 个级别做了标注，这样你在实践优化时，就会更明确哪些该做，哪些需要结合实际的业务场景进一步分析。

这些级别的实施规则如下：

如果你是业务开发人员，你需要了解 Redis 的运行机制，例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等，使用合理的命令，并结合业务场景进行优化。

如果你是 DBA 运维人员，你需要在资源规划、运维、监控、安全层面做到位，做到未雨绸缪。

欢迎扫码加入儒猿技术交流群，每天晚上20:00都有Java面试、Redis、MySQL、、、Java架构等技术答疑分享，更能跟小伙伴们一起交流技术

另外推荐儒猿课堂的1元系列课程给您，欢迎加入一起学习~

互联网Java工程师面试突击课

（1元专享）

零基础入门到项目实战

（1元专享）

亿级流量下的电商详情页系统实战项目

（1元专享）

Kafka消息中间件内核源码精讲

（1元专享）

12个实战案例带你玩转Java并发编程

（1元专享）

零基础入门到精通

（1元专享）

基于Java手写分布式中间件系统实战

（1元专享）

基于的分库分表实战课

（1元专享）