Consul 简介

Consul 解决了各种规模的组织在微服务架构中遇到的挑战。包括各种分布式环境下及跨地理位置下的所有应用程序流量的保护，它关注计算网络层。

Consul 是一个服务网格解决方案，它的核心功能主要包含：

• Service Discovery - 服务发现：Consul 的客户端可以注册服务，例如 api 或 mysql，其他客户端可以使用 Consul 发现给定服务的提供者。使用 DNS 或 HTTP，应用程序可以轻松找到它们所依赖的服务。
• Health Checking - 健康检查：Consul 客户端可以提供任意数量的健康检查，或者与给定服务相关联（“网络服务器是否返回 200 OK”），或者与本地节点相关联（“内存利用率是否低于 90%”）。操作员可以使用此信息来监控集群的健康状况，服务发现组件使用它将流量路由到健康的主机。
• KV Store - KV 存储：应用程序可以将 Consul 的分层键/值存储用于任意数量的目的，包括动态配置、特征标记、协调、领导者选举等。简单的 HTTP API 也使其易于使用。
• Secure Service Communication - 安全服务通信：Consul 可以为服务生成和分发 TLS 证书以建立相互 TLS 连接。Intentions 可用于定义允许通信的服务。可以通过实时更改意图轻松管理服务分段，而不是使用复杂的网络拓扑和静态防火墙规则。
• Multi Datacenter - 多数据中心：Consul 开箱即用地支持多个数据中心。这意味着 Consul 的用户不必担心构建额外的抽象层以扩展到多个区域。

Consul 旨在对 DevOps 社区和应用程序开发人员都友好，使其非常适合现代、弹性的基础设施。

本文为 KIP-98 - Exactly Once Delivery and Transactional Messaging 的部分翻译

动机

本文档概述了增强 Kafka 消息交付语义的提议。这建立在之前已经完成的重要工作的基础上，特别是在幂等生产者和Kafka 中的事务性消息传递。

Kafka 目前提供至少一次（at least once）语义，即。 在针对可靠性进行调整时，用户可以保证每次写入的消息将至少持久化一次，而不会丢失数据。 由于生产者重试，流中可能会出现重复。 例如，代理可能会在提交消息和向生产者发送确认之间崩溃，导致生产者重试，从而导致流中出现重复的消息。

消息传递系统的用户极大地受益于更严格的幂等生产者语义，即。每个消息写入都将被持久化一次，不会重复，也不会丢失数据 - 即使在客户端重试或代理失败的情况下也是如此。这些更强的语义不仅使编写应用程序更容易，而且也让更多的应用程序可以使用给定消息传递系统。
但是，幂等生产者不为跨多个 TopicPartition 的写入提供保证。为此，人们需要更强的事物保证，即。能够以原子方式写入多个 TopicPartition。原子地，我们的意思是能够将一组消息作为一个单元跨 TopicPartitions 提交：要么提交所有消息，要么都不提交。

本文为 MySQL 8.0 官方文档 The InnoDB Storage Engine 的部分翻译。

InnoDB 简介

InnoDB 是一个兼顾高可靠性和高性能的通用存储引擎。在 MySQL 8.0 中，InnoDB 是默认的 MySQL 存储引擎。除非您配置了不同的默认存储引擎，否则发出不带 ENGINE 子句的 CREATE TABLE 语句默认会创建一个 InnoDB 表。

InnoDB 的主要优势

• 它的 DML(data manipulation language) 操作遵循 ACID 模型，事务具有提交、回滚和崩溃恢复功能，以保护用户数据。请参阅第 15.2 节，“InnoDB 和 ACID 模型”。
• 行级锁定和 Oracle 风格的一致性读取提高了多用户并发性和性能。请参阅第 15.7 节，“InnoDB 锁定和事务模型”。
• InnoDB 表将您的数据排列在磁盘上以优化基于主键的查询。每个 InnoDB 表都有一个称为聚集索引的主键索引，用于组织数据以最小化主键查找的 I/O。请参阅第 15.6.2.1 节，“聚集索引和二级索引”。
• 为了保持数据完整性，InnoDB 支持外键 FOREIGN KEY 约束。使用外键检查插入、更新和删除以确保它们不会导致相关表之间的不一致。

本文为 MySQL 8.0 官方文档 InnoDB Locking and Transaction Model 的翻译，所述的锁和事物模型针对于 InnoDB 存储引擎。

要实现大规模、繁忙或高可靠的数据库应用程序，或调优 MySQL 性能，了解 InnoDB 锁和 InnoDB 事务模型很重要。

InnoDB 和 ACID 模型

ACID 模型是一组数据库设计原则，强调对业务数据和任务关键型应用程序很重要的可靠性方面。MySQL 包括 InnoDB 存储引擎等组件，它们与 ACID 模型密切相关，因此数据不会损坏，结果不会因软件崩溃和硬件故障等异常情况而失真。当您依赖符合 ACID 的特性时，您不需要重新发明一致性检查和崩溃恢复机制的轮子。如果您有额外的软件保护措施、超可靠的硬件、或者可以容忍少量数据丢失或不一致的应用程序，您可以调整 MySQL 设置以换取一些 ACID 可靠性以获得更高的性能或吞吐量。

以下部分讨论 MySQL 特性，特别是 InnoDB 存储引擎，如何与 ACID 模型的类别交互：

• A：atomicity - 原子性

  事务通常由多个语句组成。原子性保证每个事务都被视为一个“单元”，要么完全成功，要么完全失败：如果构成事务的任何语句未能完成，则整个事务失败，数据库数据保持不变。原子系统必须保证在每一种情况下的原子性，包括电源故障、错误和崩溃。保证原子性可以防止对数据库的更新仅部分发生，这可能会导致比完全拒绝整个系列更大的问题。

• C：consistency - 一致性/正确性

  一致性确保事务只能将数据库从一种有效状态带到另一种有效状态，维护数据库不变性：根据所有定义的规则，写入数据库的任何数据都必须有效，包括约束、级联、触发器及其任意组合。这可以防止非法事务导致数据库损坏，但不能保证事务是正确的。

• I：isolation - 隔离型

  事务通常是并发执行的（例如，多个事务同时读取和写入一个表）。隔离确保事务的并发执行使数据库处于与顺序执行事务时获得的状态相同。隔离是并发控制的主要目标；根据所使用的方法，不完整事物的影响甚至可能对其他事物不可见。

• D：durability - 持久性

  持久性保证一旦事务被提交，即使在系统故障（例如，断电或崩溃）的情况下它也将保持提交。这通常意味着已完成的事物（或它们的影响）被记录在非易失性存储器中。

Atomicity

ACID 模型的原子性方面主要涉及 InnoDB 事务。相关的 MySQL 功能包括：

• 自动提交（autocommit）设置。
• COMMIT 语句。
• ROLLBACK 语句。

延迟队列定义

首先，队列这种数据结构相信大家都不陌生，它是一种先进先出的数据结构。普通队列中的元素是有序的，先进入队列中的元素会被优先取出进行消费；

延时队列相比于普通队列最大的区别就体现在其延时的属性上，普通队列的元素是先进先出，按入队顺序进行处理，而延时队列中的元素在入队时会指定一个延迟时间，表示其希望能够在经过该指定时间后处理。

延时队列的应用

延时队列在项目中的应用还是比较多的，尤其像电商类平台：

1、订单成功后，在30分钟内没有支付，自动取消订单

2、外卖平台发送订餐通知，下单成功后 60s 给用户推送短信。

3、如果订单一直处于某一个未完结状态时，及时处理关单，并退还库存

4、淘宝新建商户一个月内还没上传商品信息，将冻结商铺等

。。。。

上边的这些场景都可以应用延时队列解决。

下面的最佳实践都是从性能角度证明双向关联的正确性。

映射 @OneToMany 双向关联

一个作者对应多本发行书，Parent 端 为 Author，Child 端为 Book。

Java Instrumentation API，提供允许 Java 编程语言代理人（Agent）Instrument 在 JVM 上运行的程序的服务。

Agent：代理，以下文章中的所述代理都是指 Java Agent。

Instrumentation/Instrument：直译仪器，在计算机术语中也有植入、插桩、编排、性能测量的意思。

Instrument 设计的目的是将字节码添加到方法中，收集工具使用的数据。出于这个目的，因为更改纯粹是附加的，因此这些工具不会修改应用程序状态或行为。此类良性工具的示例包括监控代理、分析器、覆盖分析器和事件记录器。

由于这种检测机制提供了修改现有已编译 Java 类的字节码或添加字节码的能力，所以我们也可以用来动态修改运行的程序代码。

用锁来做什么？

在计算机科学中，锁是多线程环境中防止不同线程对同一资源进行操作的机制。锁的目的是确保在可能尝试执行同一工作的多个节点中，只有一个节点实际执行此操作（至少一次只有一个）。这项工作可能是将一些数据写入共享存储系统、执行一些计算、调用一些外部 API 等。概括而言，您可能需要在分布式应用程序中锁定的原因有两个：为了效率或为了正确性。为了区分这些情况，您可以询问如果锁定失败会发生什么：

• 效率 - Efficiency：获取锁可以避免你不必要地做同样的工作两次（例如一些昂贵的计算）。
• 正确性 - Correctness：使用锁可以防止并发进程相互干扰并破坏系统状态。如果锁失败，两个节点同时处理同一份数据，结果是文件损坏，数据丢失，永久性不一致、错误的执行结果或其他一些严重问题。

两者都是需要锁的有效情况，但您需要非常清楚您正在处理的是两者中的哪一个。

安全性和活跃性保证

我们将仅使用三个属性对我们的设计进行建模，从我们的角度来看，这是以有效方式使用分布式锁所需的最低保证。

1. 安全特性：互斥。在任何给定时刻，只有一个客户端可以持有锁。
2. 活跃性属性 A：无死锁。最终总是有可能获得锁，即使锁定资源的客户端崩溃或被分区。
3. 活跃性属性 B：容错。只要大多数 Redis 节点都已启动，客户端就可以获取和释放锁。

从 1.4 版本开始，Java 提供了另一套 I/O 系统，称为 NIO(New I/O 的缩写)。NIO 支持面向缓冲区的、基于通道的 I/O 操作。随着 JDK7 的发布，Java 对 NIO 系统进行了极大扩展，增强了对文件处理和文件系统特性的支持。缘于 NIO 文件类提供的功能，NIO 预期会成为文件处理中越来越重要的部分。

NIO 包含下面几个核心的组件：

• Channels
• Buffers
• Selectors

还有基于文件的几个核心组件：

• Path
• FileSystem

下面我们就以核心组件展开来说。

从桌面上的小 applet 到大型服务器上的 Web 服务，各种各样的应用程序都使用 Java。为了支持这种多样化的部署场景，Java HotSpot VM 提供了多个垃圾收集器，每个垃圾收集器旨在满足不同的需求。Java 根据运行应用程序的计算机的类别选择最合适的垃圾收集器。但是，此选择可能并非对每个应用程序都是最佳的。具有严格性能目标或其他要求的用户，开发人员和管理员可能需要明确选择垃圾回收器并调整某些参数以实现所需的性能水平。本文档提供了有助于完成这些任务的信息。

首先，在串行，stop-the-world 收集器的上下文中描述了垃圾收集器的一般功能和基本的调整选项。然后介绍了其他收集器的特定功能以及选择收集器时要考虑的因素。