ITPub博客

scheduleAtFixedRate的逻辑结论是：如果上一个任务的执行时间大于等待时间，任务结束后，下一个任务马上执行。如果上一个任务的执行时间小于等待时间，任务结束。

如果某个客户端获得锁之后处理时间超过最大约定时间，或者持锁期间内发生了故障导致无法主动释放锁，其持有的锁也能够被其他机制正确释放，并保证后续其它客户端也能加锁，整个处理流程继续正常执行。

Java 中的ThreadLocal类允许程序员创建只能由创建它们的线程访问的变量。这对于创建线程安全代码很有用，因为它确保每个线程都有自己的变量副本并且不会干扰其他线程。

TDDL+ MySQL自增ID的场景下，Seata AT 模式inset记录时，其构建afterImage时会遇到一些麻烦。从源码中梳理可知 Seata AT 模式下，自增ID场景下，采用useGeneratedKeys可规避这个问题。

构建 afterImage的时候，复用了Insert操作的prepareStatement，由于未清空参数，只把 sql 变成了 SELECT LAST_INSERT_ID() ，引发了错误。

面对新冠，要平常心，不管之前接收到多少新冠如何可怕的信息，大脑里是否还回荡着大白这样那样的宣传语，须知这些宣讲是基于当时的抗疫策略来的。现在策略调整了，咱们也得从认知上跟进，科学的看待它，不要太悲观。

没有足够使用经验，对内部机制掌握不够的情况下，全面的掌握 Seata 所提供的安保机制，按需禁用或开启、将新能力和老逻辑划清边界、以最小化测试单元的原则来推进，应该会更加顺利。

传统的分布式锁若归类为重用锁（A 持锁后，B 来抢锁只要没超时就一直重试抢锁，抢到就用），而这种防重入场景下的锁可理解为”一次性“锁（A 持锁后，B 来抢锁只要锁已存在，则立即放弃）。

每个人都有自己的故事，每个人都有一份属于自己的讲述，它并不遥远，可能就在桌上，也可能就在窗外，你讲或不讲它都在那里，因为你努力前行的身形至少会被时光记录。

考虑到即使定制了插件也无通用性、系统自身又要升级迭代、插件的调试更新比较麻烦等几个关键因素，系统负责人更期望通过显式的调用 API 用编码的方式构建 Trace，以满足其快速实现、快速迭代的需求。

考虑到即使定制了插件也无通用性、系统自身又要升级迭代、插件的调试更新比较麻烦等几个关键因素，系统负责人更期望通过显式的调用 API 用编码的方式构建 Trace，以满足其快速实现、快速迭代的需求。

并发场景要解决好原子性问题、可见性问题、重排序问题。JAVA 很友好，多线程间通信、同步机制采用共享内存的方式，并且站在开发者的立场考虑问题，通过 JMM 屏蔽了复杂多样又难以理解的底层技术知识，让开发者只关注如何操作，而忽视底层的复杂实现

大规模可靠的分布式系统中的数据不一致是客观的，是否可以接受取决于客户端应用程序。开发人员需要意识到一致性保证是由存储系统提供的，并且在设计、开发应用程序时需要将其不一致的可能性考虑在内。

ACID 是悲观的且在每个操作结束时强制一致性，BASE 与它截然相反；?BASE 是乐观的并且接受数据库一致性处于不断变化的状态，在BASE看来既然无法做到强一致性，每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

全面介绍 SpringBoot 中要玩转 Feign 需要掌握的如添加 pom 依赖、客户端注解启用、切换底层 HttpClient、配置数据压缩、调整日志级别、定制配置、配置的优先级机制、增加拦截器以及拦截器的追加机制等知识。

Seata 的配置管理并没有按照 Spring 的外部化配置机制来实现，其内部对配置源做了独立的抽象，并以单例的方式ConfigurationFactory#getInstance()提供获取配置信息的入口，将复杂实现隐藏在其实现的内部。

有这么一种说法：以实际效果而言，系统若不能在时限内完成同步，达到数据一致性；就意味着发生了分区的情况，必须就当前操作在一致性和可用性之间做出选择。

歪歪一个剧本杀-悬疑推理风的剧情，讲述因MySQL同步机制的缺陷，导致的主库读到老记录的故事，希望这种形式能够方便大家学习进步。

歪歪一个剧本杀-悬疑推理风的剧情，讲述因MySQL同步机制的缺陷，导致的主库读到老记录的故事，希望这种形式能够方便大家学习进步。

Redis 应该是目前最受欢迎的高性能的缓存数据库，几乎是居家必备，但是用作分布式锁还是有许多细节要注意。