当前位置：首页 > news >正文

娱乐论坛网站建设方案范文分销商系统

news 2025/10/19 5:19:29

娱乐论坛网站建设方案范文,分销商系统,西安做效果图的公司,电子商务网站建设分析论文美团2面#xff1a;如何保障 MySQL 和 Redis 的数据一致性#xff1f; 说在前面在尼恩的#xff08;50#xff09;读者社群中#xff0c;经常遇到一个非常、非常高频的一个面试题#xff0c;但是很不好回答#xff0c;类似如下#xff1a; 如何保障 MySQL 和 Redis…美团2面如何保障 MySQL 和 Redis 的数据一致性说在前面在尼恩的50读者社群中经常遇到一个非常、非常高频的一个面试题但是很不好回答类似如下如何保障 MySQL 和 Redis 的数据一致性如何保障 MySQL 和 Cache 的数据一致性最近有个小伙伴美团2面又遇到了这个问题。这里尼恩基于自己的《Java高并发核心编程卷3加强版》注意是加强版以及自己的 3高架构知识体系3高架构宇宙给大家梳理一个科书式的答案。通过此答案使得大家可以充分展示一下大家雄厚的 “技术肌肉”让面试官爱到 “不能自已、口水直流”。也一并把题目以及参考答案收入咱们的《尼恩Java面试宝典》 V55供后面的小伙伴参考提升大家的 3高架构、设计、开发水平。注本文以 PDF 持续更新最新尼恩架构笔记、面试题的PDF文件请从这里获取码云首先什么是Cache-Aside Pattern旁路缓存模式 Cache-Aside Pattern旁路缓存模式又叫旁路路由策略在这种模式中读取缓存、读取数据库和更新缓存的操作都是在应用程序中完成。此模式是业务系统最常用的缓存策略。旁路缓存又模式分为读缓存和写缓存。旁路缓存模式在读的时候先读缓存缓存命中的话直接返回数据如果缓存没有命中的话就去读数据库从数据库取出数据放入缓存后同时返回响应。 Cache-Aside Pattern旁路缓存模式读操作流程具体如下 step 1应用程序接收用户的数据查询的请求 step 2应用程序优先从缓存查找数据 step 3如果存在cache hit从缓存上查询出来返回查询到数据 Step 4如果不存在cache miss从数据库中查询数据并存入缓存中返回查询到数据。 Cache-Aside Pattern旁路缓存模式读操作流程具体如下图所示图Cache-Aside Pattern旁路缓存模式读操作流程 Cache-Aside Pattern旁路缓存模式写操作流程具体如下 step 1接收用户的数据写入的请求 step 2先写入数据库 step 3再写入缓存。 Cache-Aside Pattern旁路缓存模式写操作流程具体如下图所示图Cache-Aside Pattern旁路缓存模式写操作流程数据什么时候从数据库如Mysql集群加载到缓存如Redis集群呢有以下两种加载模式可被选择懒汉模式、饿汉模式。懒汉模式、饿汉模式可以理解为及时加载模式、延迟加载模式。所谓懒汉模式就会在使用时临时加载缓存。具体来说就是当需要使用数据时就从数据库中把它查询出来然后写入缓存。第一次查询之后后续的请求都能从缓存中查询到数据。所谓饿汉模式就是提前预加载缓存。具体来说在项目启动的时候预加载数据到缓存。当需要使用数据时能直接从缓存获取数据而不需要从数据获取。饿汉模式提前预加载数据到缓存的时机能极大地提升请求处理的性能力极大地提升系统的吞吐量。此模式适合于缓存那些不是经常变更的数据例如商品类目数据或者那些访问非常频繁的极热数据例如秒杀商品数据。说明懒汉模式、饿汉模式这组名词来自于Java的单例模式关于Java的单例模式的详细介绍请参考《Java高并发核心编程卷2加强版》注意是加强版。 Cache-Aside如何保证双写的数据一致性 Cache-Aside是日常开发中使用最多的缓存层高并发访问模式。所以面试官也喜欢围绕这种模式进行发问。一个非常高频的问题是Cache-Aside在写入的时候为什么是删除缓存而不是更新缓存呢。而且很多大厂也喜欢问这个领域的问题下面就是一道来自于社群的美团真题。美团面试题 Cache-Aside如何保证DB和Cache双写的数据一致性要完美的回答这个问题咱们把Cache-Aside模式旁路缓存模式下的DB和Cache双写的策略做一个系统化的梳理大概分为如下五大策略。策略一先更数据库再更缓存策略二先删缓存再更新数据库策略三先更数据库再删缓存策略四延迟双删策略策略五逻辑删除策略策略六先更数据库再基于队列删缓存如果能在面试的时候把其中每一种策略的角色功能、适用场景、执行流程、优势弱点、改进策略进行系统化、体系化的陈述无论是那个厂无论是什么顶级的大厂一定会对候选人的能力有十分的认可。这里的内容来自于《Java高并发核心编程卷3加强版》有关6中策略的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略一先更数据库再更缓存在实际的业务场景中一种常见的并发场景是微服务Provider实例A、B同时进行同一个数据的更新操作。按照先更数据库再更缓存的策略则微服务Provider实例A、B可能会出现下面的执行次序 l step 1微服务A去执行update DB l step 2微服务B去执行update DB l step 3微服务B去执行update Cache l step 4微服务A去执行update Cache 上面的执行流程具体如下图所示图:先更数据库再更缓存的并发执行案例上面的执行流程是典型的并发写入场景。在图中的并发写入的场景中Provider A进行数据的写入Provider B也进行数据的写入。最终的结果是DB中的数据是Provider B的数据Cache中的数据是Provider A的数据出现DB和Cache数据不一致问题。具体的原因是Provider B的更新在Cache中的数据被Provider A的更新在Cache中的数据覆盖了。DB的更新次序先A后B理论上Cache中的数据更新也应该是先A后B。理论上最终Cache中的数据应该是Provider B的数据而不是Provider A的数据。所以在流程执行完毕后缓存中的Provider A的数据为脏数据。而之出现这个问题是因为以上流程中step 3与step 4的执行均为操作缓存都是高并发的操作很难保证先后次序所以缓存出现脏数据的概率很大。为何不更新缓存而是删除缓存核心面试题一个非常高频的问题是Cache-Aside在写入的时候为什么是删除缓存而不是更新缓存呢回到上一节的例子在图中的并发写入的场景中Provider A进行数据的写入Provider B也进行数据的写入。在这个例子中写入DB的次序如下 l Provider A先发起一个写操作第一步先更新数据库 l Provider B再发起一个写操作第二步更新了数据库现在由于分布式系统无法保证并发操作的有序性写入Cache的次序可能如下 l Provider B先发起一个Cache写操作第一步先更新Cache l Provider A再发起一个Cache写操作第二步更新了Cache 这时候Cache保存的是Provider A的数据老数据DB保存的是B的数据新数据于是发生了DB和Cache数据不一致Cache中出现脏数据。如果使用删除操作取代更新操作则Cache不会出现上面的脏数据问题。具体如下图所示图:为何不更新缓存而是删除缓存除了能够减少脏数据之外更新缓存相对于删除缓存还有两点劣势 1如果写入Cache的值是经过复杂计算才得到的话。更新缓存频率高的话就会大大降低性能。 2及时更新缓存属于饿汉模式适用于数据读取高频的场景。在写多读少的情况下数据很多时候还没被读取到又被更新了这也浪费了Cache的空间也降低了性能。这里的内容来自于《[Java高并发核心编程卷3加强版]《Java高并发核心编程卷3加强版》注意是加强版的策略1 策略1的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略二先删缓存再更新数据库在实际的业务场景中一种常见的并发场景是微服务Provider实例A进行数据的写入而服务Provider实例 B同时进行同一个数据的读取操作。按照先删缓存再更新数据库的策略则微服务Provider实例A、B可能会出现下面的执行次序 l step 1微服务A去执行delete Cache l step 2微服务B去执行load from DB l step 3微服务B去执行update Cache l step 4微服务A去执行update DB 上面的执行流程具体如下图所示图:先删缓存再更新数据库的并发执行案例上面的执行流程是典型的并发读写场景。在图中的并发读写的场景中Provider A进行数据的写入Provider B进行数据的查询。最终DB中的数据是Provider A的更新数据Cache中的数据是Provider B从DB加载的数据而这个数据已经过时出现DB和Cache数据不一致问题。具体的原因是Provider B查询Cache的时候Cache中的数据被删除Provider B只能去DB查找然后将数据更新在Cache。而Provider A在Provider B查完之后竟然更新了DB导致了DB和Cache的不一致。出现这个DB和Cache的不一致问题的根本原因大致如下写操作是先删Cache操作1再写DB操作2如果在此期间发生并发读读取的动作很容易发生操作1、操作2的中间从而读取到过时的数据最终导致Cache和DB不一致。更为严重的时候读操作把过期数据刷入Cache后会导致后面比较长时间的不一致。这个时间一直持续到缓存过期如说4个小时以项目中的配置时间为准。上面的Cache和DB不一致将导致一个严重的后面后续的读取操作都会使用Cache中的数据所以后面的读取操作都会使用过时数据。这里的内容来自于《[Java高并发核心编程卷3加强版]《Java高并发核心编程卷3加强版》注意是加强版的策略2 策略2的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略三先更数据库再删缓存先更数据库再删缓存基本上可以解决并发读写场景中Cache和DB数据不一致的问题。但是在一些特殊的场景中还是会存在数据不一致的问题。一种非常特殊的并发场景是微服务Provider实例A进行数据的写入操作先写DB操作1再删Cache操作2如果由于某种原因出现了卡顿没有及时把数据放入Cache或者说放入Cache的操作简单的说操作2发生了滞后。此时服务Provider实例 B进行一个数据的读取操作读取的次序仍然是先读Cache再读DB很容易发生DB和Cache的不一致性。按照先更数据库再删缓存的策略则微服务Provider实例A、B可能会出现下面的执行次序 l step 1微服务A去执行update DB l step 2微服务B去执行load from Cache l step 3微服务A去执行delete Cache但是发生了延迟上面的执行流程具体如下图所示图:先更数据库再删缓存的并发执行案例在图中的并发读写的场景中Provider A进行数据的写入Provider B进行数据的查询。微服务Provider实例A先写DB操作1再删Cache操作2如果Provider实例A发生卡顿、或者网络延迟等异常的问题导致操作2严重滞后。在操作2执行完成之前DB和Cache的数据是不一致的。在此期间其他的数据读取操作都会读取Cache中的过期数据出现DB和Cache数据不一致问题。出现这个DB和Cache的不一致问题的根本原因大致如下写操作是先写DB操作1再删Cache操作2如果在此期间发生并发读读操作很容易发生操作1、操作2的中间从而并发读操作从Cache读取到过时的数据最终导致Cache和DB不一致。但是等到写操作删除Cache操作2的动作执行完成之后Cache和DB的数据会恢复一致性。无论如何策略三先写DB再删Cache比策略二先删Cache再写DB发生数据不一致的时间短。相比较而言推荐大家使用策略三而不是策略二。那么策略三的问题是啥呢 1写DB操作1和删Cache操作2之间存在短时间的数据不一致 2如果删Cache失败存在较长时间的数据不一致这个时间会一直持续到Cache过期如何解决策略三中Cache删除失败所导致的DB和Cache较长时间的数据不一致呢可以使用策略四延迟双删。这里的内容来自于《[Java高并发核心编程卷3加强版]《Java高并发核心编程卷3加强版》注意是加强版的策略3 策略3的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略四延迟双删策略什么是延迟双删呢延迟双删是基于策略二进行改进就是先删Cache后写DB最后延迟一定时间再次删Cache。在实际的业务场景中一种常见的并发场景是微服务Provider实例A进行数据的写入而服务Provider实例 B同时进行同一个数据的读取操作。按照先删Cache后写DB最后延迟一定时间再次删Cache策略则微服务Provider实例A、B可能会出现下面的执行次序 l step 1微服务A去执行delete Cache l step 2微服务B去执行load from DB l step 3微服务B去执行update Cache l step 4微服务A去执行update DB l step 5微服务A去执行 delay delete Cache 上面的执行流程具体如下图所示图先删Cache后写DB再次延迟删Cache的并发执行案例在图中的并发读写的场景中Provider A进行数据的写入Provider B进行数据的查询。微服务Provider实例A先删Cache操作1再写DB操作2最后再二次延迟删除Cache操作3。在操作2之前如果发生并发读从DB读取到过时数据可能出现DB和Cache数据不一致问题。出现这个DB和Cache的不一致问题的根本原因大致如下写操作是先删Cache操作1再写DB操作2如果在此期间发生并发读读操作容易发生操作1、操作2的中间从DB读到过时数据最终导致Cache和DB不一致。但是这一轮的数据不一致持续时间不会太长。为啥呢写操作还有一个兜底的动作二次延迟删除Cache操作3从而保证数据一致。所以延迟双删也会存在数据不一致不过是持续时间比较短而已。那么策略四的问题是啥呢 1如果写操作比较频繁可能会对Redis造成一定的压力 2极端情况下第二次延迟删Cache失败操作的效果退化到策略二。DB和Cache存在较长时间的数据不一致这个时间会一直持续到Cache过期比如说4个小时以项目中的配置时间为准。如何解决策略四的以上两个问题呢可以使用策略五先更数据库再基于队列删缓存。这里的内容来自于《[Java高并发核心编程卷3加强版]《Java高并发核心编程卷3加强版》注意是加强版的策略4 策略4的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略五逻辑删除/逻辑过期的问题首先什么是逻辑过期时间呢。逻辑代表什么假的删除不是真正的删除。而是空间换时间设置一些额外的标志比如在存储数据的时候加个字段比如 logicExpireTime 给它设置值。这个值跟我们缓存key的有效时间肯定不一样。比如永不过期比如当前时间再加上几个小时转为时间戳的方式跟数据一起存入redis。逻辑过期时间业务过期时间物理过期时间逻辑过期时间高并发冗余时间查询的时候检查 logicExpireTime 如果发现到时间了另外有一个缓存的重建线程进行异步重建更新的时候更改逻辑过期时间当前时间这里在写《Java高并发核心编程卷3加强版》注意是加强版的时候没有介绍没有写逻辑删除策略策略5的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操策略六先更数据库再基于队列删缓存来到策略六先更数据库再基于队列删缓存。那么如何基于任务队列删缓存呢实质上策略六是基于策略三进行改进。首先回顾一下策略三的问题 1写DB操作1和删Cache操作2之间存在短时间的数据不一致 2如果删Cache失败存在较长时间的数据不一致这个时间会一直持续到Cache过期策略六主要的操作次序和策略三保持一致依然是先写DB后删除Cache。不同的是策略六引入队列把删Cache的操作加入队列后台会有一个异步线程、或者进程去异步消费队列中的删除任务去执行删Cache的操作。基于队列删缓存可以细分为第1种细分的方案基于内存队列删除缓存第2种细分的方案基于消息队列删除缓存第3种细分的方案基于binlog消息队列删除缓存首先来看第一种细分的方案基于内存队列删除缓存。此策略把删Cache的操作加入任务队列后台会有一个异步线程去异步消费任务队列里面的删除任务去执行删Cache的操作如果缓存删除失败可以重试多次确保删除成功。在实际的业务场景中一种常见的并发场景是微服务Provider实例A进行数据的写入而服务Provider实例 B同时进行同一个数据的读取操作。Provider实例A先写DB然后将删Cache加入任务队列Provider实例 B则是先读缓存没有数据再读DB。微服务Provider实例A、B可能会出现下面的执行次序 step 1微服务A去执行update DB step 2微服务A将delete Cache操作进入任务队列 step 3微服务B去执行load from Cache step 4消费线程从任务队列提取delete Cache操作执行删除Cache的操作直到删除成功。上面的执行流程具体如下图所示图:先更数据库后基于内存队列删缓存的并发执行案例在图中的并发读写的场景中Provider A进行数据的写入Provider B进行数据的查询。微服务Provider实例A先写DB操作1再将删Cache操作加入任务队列操作2。在删除Cache操作真正执行完成之前其他的数据读取操作都会读取Cache中的过期数据出现DB和Cache数据不一致问题。但是这种不一致是短暂的。任务队列的消费线程会异步执行删除Cache的任务并且会不断重试确保成功删除Cache之后DB和Cache数据不一致问题就会得到解决。说明保存删除Cache任务的队列建议使用阻塞队列。任务队列的消费线程可参考Rocketmq源码中的ServiceThread异步服务线程其设计思想和执行性能都非常优越。后面尼恩会通过视频介绍一下基于队列删除缓存的实操。策略六也会出现这个DB和Cache的不一致问题尤其是如果写操作非常频繁队列的任务比较多可能消费会比较慢导致DB和Cache的不一致的时间会延长。在这种情况下可以根据任务队列的拥塞程度开启多个线程提升并发执行的效率。与策略四相比策略六的优势是 1在写操作比较频繁的场景策略四有两次删Cache操作可能会对Redis造成一定的压力策略六只有一次删Cache操作Redis压力小一半。 2策略四如果删Cache失败没有引入重试策略策略六会多次重试确保删Cache成功如果重试多次仍然不成功可以执行运维预警。 3策略四将写DB、删Cache这两个操作耦合在了一起没有很好的做到单一职责策略六将写DB、删Cache两个操作解耦模块职责更加单一。那么策略六的问题是啥呢 1如果写操作非常频繁队列的任务比较多可能消费会比较慢需要引入多线程机制加快消费速度。 2程序复杂度成倍上升引入消费线程、任务队列并且还需要不断进行性能优化。 3内存队列是JVM进程的内部队列如果JVM崩溃内存队列没有来得及处理的Cache记录删除任务会丢失这些数据的Cache记录和DB记录会长时间不一致。其次来看第二种细分的方案基于消息队列删除缓存。在前面的第一种细分方案中将删除Cache的任务保存在内存队列并不是高可靠的。为了保证高可靠的删除Cache记录这里引入高可用的独立组件——Rocketmq消息队列。需要注意的是这里引入的RocketMq消息队列是高可用的类型消息队列不是单节点的类型消息队列从而保障消息记录的高可用保障Cache的删除操作只要没有被执行成功就不会丢失。引入高可用RocketMq消息队列之后执行双写操作的Provider A的操作流程有小幅度的调整。Provider A需要将删除Cache的操作序列化成Rocketmq消息然后写入高可用Rocketmq消息队列中间件即可。然后由专门的消费者Cache Delete Consumer进行消息的消费根据消息内容执行Cache记录删除工作。 DB和Redis双写的场景下Provider A先更数据库后基于消息队列删缓存的并发执行案例的执行流程具体如下图所示图:先更数据库后基于消息队列删缓存的并发执行案例引入高可用的独立组件RocketMq消息队列之后Provider A的写入逻辑变得很简单删Cache的时候只需要发送消息到RocketMq即可大大简化了Provider A程序的写入逻辑。只是为了保证消息的高可靠传递这里Provider A在发送消息的时候需要使用同步发送模式而不能使用异步发送的模式。在消息投递的环节由RocketMq高可用组件的ACK机制保证消息的高可靠投递。如果消息第一次消费失败RocketMq会重复多次进行投递确保消息被正常消费如果一直不能被成功消费在重复投递一定的次数之后默认16次消息会进入死信队列。系统的监控程序会对死信队列进行监控一旦发现死信消息监控程序会进行运维告警由运维人员解决最终的缓存删除问题。除非Redis集群崩溃一般都不会出现这样的极端情况。和基于内存队列删除缓存基于消息队列删除缓存的方案的优势是增加了Cache删除的可靠性避免了因JVM崩溃所导致的内存队列中的记录丢失的问题。那么Provider在执行DB和Cache双写时能不能进一步减少双写的负担将发送删除Cache消息的操作从双写逻辑中剥离交给其他的组件去完成呢答案是可以的。具体来说就是使用基于基于binlog消息队列去删除Cache的方案。最后来看第三种细分的方案基于binlog消息队列删除缓存。以Mysql为例可以使用阿里的Canal中间件采集在数据写入Mysql时生成的binlog日志然后将日志发送到RocketMq队列。在消费端可以编写一个专门的消费者Cache Delete Consumer完成缓存binlog日志订阅筛选出其中的更新类型log解析之后进行对应Cache的删除操作并且通过RocketMq队列ACK机制确认处理这条更新log保证Cache删除能够得到最终的删除。 DB和Redis双写的场景下Provider A先更数据库后基于基于binlog消息队列删除缓存的并发执行案例的执行流程具体如下图所示图:先更数据库后基于消息队列删缓存的并发执行案例基于binlog消息队列去删除Cache的方案的优势是微服务Provider在执行DB和Cache双写时只需要执行写入DB的操作就可以了大大简化了微服务Provider的业务逻辑。Cache的删除工作已经完全被Canal、RocketMq、专门的消费者Cache Delete Consumer三者相互结合去接管了。如何选型呢这么多的Cache-Aside如何保证双写的数据一致性方案改如何选型呢只有更合适、没有最合适。大家可以根据项目和团队的情况选择最合适的。具体的方案选型大家可以在高并发社群——疯狂创客圈的微信群里边交流。这里对应到《Java高并发核心编程卷3 加强版的策略5》写书的时候没有写逻辑删除策略策略6的代码实操介绍请参见尼恩的 100Wqps三级缓存组件实操基于队列的方案主要有两种第2种细分的方案基于消息队列删除缓存第3种细分的方案基于binlog消息队列删除缓存如何选型呢很多小伙伴选择基于binlog消息队列删除缓存但是这种方案在很多场景下是不可以使用的。具体原因比较复杂请参考尼恩的 100Wqps三级缓存组件实操里边有详细的介绍。从CAP视角分析DB与Cache的数据一致性 CAP理论作为分布式系统的基础理论它描述的是一个分布式系统在以下三个特性中一致性Consistency 可用性Availability 分区容错性Partition tolerance 分布式系统最多满足其中的两个特性要么满足CA要么CP要么AP无法同时满足CAP。也就是说AP和CP是一组天敌要满足AP高性能只能舍弃CP。在DB和Cache的分布式架构中加入分布式Cache的目的是为了获得高性能、高吞吐就是为了获得分布式系统的AP特性。所以如果需要数据库和缓存数据保持强一致强CP特性就不适合使用缓存。所以从CAP的理论出发使用缓存提升性能就是会有数据更新的延迟就会产生数据的不一致。使用分布式Cache可以通过一些方案优化保证弱一致性最终一致性的。我们只能通过不断的方案迭代减少不一致性的时间长度。这需要Cache设计时结合业务仔细思考是否适合用缓存结合业务仔细思考缓存过期时间。缓存一定要设置过期时间这个时间太短、或者太长都不好。如果过期时间太短请求可能会比较多的落到数据库上这也意味着失去了缓存的优势。如果过期时间太长缓存中的脏数据会使系统长时间处于一个延迟的状态而且系统中长时间没有人访问的数据一直存在内存中不过期浪费内存。为啥DB和Cache没有办法强一致呢主要是写DB和删Cache是两个独立的操作两个操作并没有保证原子性。如果一定要强CP就需要非常复杂的低性能方案保证写DB和删Cache两个操作的原子性比如引入分布式锁并且需要引入CP类型的Zookeeper分布式锁或者引入CP类型的Redis RedLock而不是引入AP类型的普通Redis分布式锁。所以如果一定要强CP就需要非常复杂的低性能方案有点得不偿失。说在后面如果遇到难题可以来找尼恩给大家做起底式、绞杀式、系统化梳理帮大家真正让面试官爱到死去活来。参考文献尼恩的10Wqps秒杀架构笔记尼恩的10Wqps三级缓存架构笔记推荐阅读《吃透8图1模板人人可以做架构》《干翻 nio 王炸 io_uring 来了图解史上最全》《SpringCloudDubbo3 王炸》《响应式圣经10W字实现Spring响应式编程自由》《4次迭代让我的 Client 优化 100倍泄漏一个人人可用的极品方案》《100亿级订单怎么调度来一个大厂的极品方案》《Linux命令大全2W多字一次实现Linux自由》《阿里一面你做过哪些代码优化来一个人人可以用的极品案例》《网易二面CPU狂飙900%该怎么处理》《阿里二面千万级、亿级数据如何性能优化教科书级答案来了》《峰值21WQps、亿级DAU小游戏《羊了个羊》是怎么架构的》《场景题假设10W人突访你的系统如何做到不雪崩》《2个大厂 100亿级超大流量红包架构方案》《Nginx面试题史上最全持续更新》《K8S面试题史上最全持续更新》《操作系统面试题史上最全、持续更新》《Docker面试题史上最全持续更新》《Springcloud gateway 底层原理、核心实战 (史上最全)》《Flux、Mono、Reactor 实战史上最全》《sentinel 史上最全》《Nacos (史上最全)》《TCP协议详解 (史上最全)》《分库分表 Sharding-JDBC 底层原理、核心实战史上最全》《clickhouse 超底层原理高可用实操史上最全》《nacos高可用图解秒懂史上最全》《队列之王 Disruptor 原理、架构、源码一文穿透》《环形队列、条带环形队列 Striped-RingBuffer 史上最全》《一文搞定SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系史上最全》《单例模式史上最全》《红黑树图解秒懂史上最全》《分布式事务秒懂》《缓存之王Caffeine 源码、架构、原理史上最全10W字超级长文》《缓存之王Caffeine 的使用史上最全》《Java Agent 探针、字节码增强 ByteBuddy史上最全》《Docker原理图解秒懂史上最全》《Redis分布式锁图解 - 秒懂 - 史上最全》《Zookeeper 分布式锁 - 图解 - 秒懂》《Zookeeper Curator 事件监听 - 10分钟看懂》《Netty 粘包拆包 | 史上最全解读》《Netty 100万级高并发服务器配置》《Springcloud 高并发配置一文全懂》

查看全文

http://www.tj-hxxt.cn/news/230321.html