一个正在运行的 Docker 容器，其实就是一个启用了多个 Linux Namespace 的应用进程，而这个进程能够使用的资源量，则受 Cgroups 配置的限制。

下面通过一个小实验证明这句话

可以按照服务的数量以及对应的数据源的使用数量来划分分布式事务，例如单个服务使用多数据源称作全局事务可以使用2、3段提交，多个服务使用单数据源则称作共享事务可以使用共享数据库连接，还有一种就是多服务多数据源，这种一般称作在分布式服务环境下的事务处理机制。

全局事务

准备阶段：又叫作投票阶段，在这一阶段，协调者询问事务的所有参与者是否准备好提交，参与者如果已经准备好提交则回复 Prepared，否则回复 Non-Prepared。这里所说的准备操作跟人类语言中通常理解的准备并不相同，对于数据库来说，准备操作是在重做日志中记录全部事务提交操作所要做的内容，它与本地事务中真正提交的区别只是暂不写入最后一条 Commit Record 而已，这意味着在做完数据持久化后并不立即释放隔离性，即仍继续持有锁，维持数据对其他非事务内观察者的隔离状态。

提交阶段：又叫作执行阶段，协调者如果在上一阶段收到所有事务参与者回复的 Prepared 消息，则先自己在本地持久化事务状态为 Commit，在此操作完成后向所有参与者发送 Commit 指令，所有参与者立即执行提交操作；否则，任意一个参与者回复了 Non-Prepared 消息，或任意一个参与者超时未回复，协调者将自己的事务状态持久化为 Abort 之后，向所有参与者发送 Abort 指令，参与者立即执行回滚操作。对于数据库来说，这个阶段的提交操作应是很轻量的，仅仅是持久化一条 Commit Record 而已，通常能够快速完成，只有收到 Abort 指令时，才需要根据回滚日志清理已提交的数据，这可能是相对重负载的操作。

缺点很明显，容易单点、性能问题、一致性风险

共享事务

理论可行，因为该方案是与实际生产系统中的压力方向相悖的，一个服务集群里数据库才是压力最大而又最不容易伸缩拓展的重灾区。

分布式事务

原文链接: https://alexhuihui.github.io/index.html

版权声明: 转载请注明出处.

大家肯定对@Transactional这个注解很熟悉，也对事务有着详细的了解，也知道多个数据库操作需要通过事务来保证一致性和原子性。但是很少会关注事务是否生效、有没有出错。这类问题也比较难在测试阶段发现，当出现线上问题的时候不可避免的会产生大量脏数据。所以这次我分享的内容就是帮助大家理清楚使用@Transactional的思路，避免使用不当产生bug。

本文介绍如果通过搭建ELK收集springboot的日志。

原文链接: https://alexhuihui.github.io/index.html

版权声明: 转载请注明出处.

标题：优化延迟队列任务消费时间的技术分享

作者：汪永晖

日期：2023-10-19

延迟队列在实际应用中是一项重要的技术，可以用于任务调度、定时提醒、消息重试等多种场景。然而，延迟队列的任务有时会在过期时间之后才得以执行，这可能导致应用程序的性能问题和不确定性。在本技术分享中，我将介绍一个优化延迟队列任务消费时间的解决方案，以及如何实现这一解决方案。

Kafka 的基本使用

消息引擎系统介绍

1. Apache Kafka是一款开源的消息引擎系统。根据维基百科的定义，消息引擎系统是一组规范。企业利用这组规范在不同系统之间传递语义准确的消息，实现松耦合的异步式数据传递。通俗来讲，就是系统A发送消息到消息引擎系统，系统B从消息引擎系统中读取A发送的消息。

2. 消息引擎系统要设定具体的传输协议，常见的有2种：点对点模型；发布订阅模型。Kafka同事支持这两种。

3. 主要作用是削峰填谷，避免下游系统因突发流量而崩溃。

​

原文链接: https://alexhuihui.github.io/index.html

版权声明: 转载请注明出处.

Go使用的是CSP并发模型，而JAVA使用的是基于传统的内存访问控制的并发模型。他们有以下区别。我们通过示例代码来比对一下Go和 Java的并发编程

所谓重构（refactoring）是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。这本书告诉你如何以一种可控制且高效率的方式进行重构，如何有条不紊地改进程序结构，而且不会引入错误。