Daggry House

分类HTTP 状态码是由服务器返回给客户端的一种标识，用于表示服务器对请求的处理结果。它由三位数字组成，分成五个不同的类别，每个类别代表了不同的意义。 2xx： 200（成功）：请求已成功，请求所希望的响应头或数据体将随此响应返回 201（已创建）：请求成功并且服务器创建了新的资源 202（已创建）：服务器已经接收请求，但尚未处理 203（非授权信息）：服务器已成功处理请求，但返回的信息可能来自另一来源 204（无内容）：服务器成功处理请求，但没有返回任何内容 205（重置内容）：服务器成功处理请求，但没有返回任何内容 206（部分内容）：服务器成功处理了部分请求 3xx 300（多种选择）：针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择 301（永久移动）：请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置 302（临时移动）：服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求 303（查看其他位置）：请求者应当对不同的 ...

背景在复杂的分布式系统中，往往需要对大量的数据进行唯一标识，比如在对一个订单表进行了分库分表操作，这时候数据库的自增ID显然不能作为某个订单的唯一标识。除此之外还有其他分布式场景对分布式ID的一些要求： 趋势递增：由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 单调递增：保证下一个ID一定大于上一个ID，例如排序需求。 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了；如果是订单号就更危险了，可以直接知道我们的单量。所以在一些应用场景下，会需要ID无规则、不规则。就不同的场景及要求，市面诞生了很多分布式ID解决方案。本文针对多个分布式ID解决方案进行介绍，包括其优缺点、使用场景及代码示例。 雪花算法是 Twitter 开源的分布式 ID 生成算法 常见解决方案数据库MySQL关系型数据库。数据库自增主键表： CREATE TABLE `sequence_id` (`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,`stub` char(10) NOT N ...

如何理解 Linux 中 CPU 轮流分配给多任务， 而在每个任务运行前，CPU 都需要知道任务从哪里加载、从哪里开始运行，需要系统事先设置好 **CPU 寄存器**和**程序计数器**。 CPU 寄存器是 CPU 内置的容量小、速度极快的内存。 而程序计数器则是用来存储 CPU 正在执行的指令位置、或即将执行的下一条指令位置。 它们都是 CPU 在运行任务前必须依赖的环境，也被叫做 CPU 上下文。 上下文切换，就是先把前一个任务的 CPU 上下文保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳到程序计数器所指的新位置，运行新任务。而这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来。这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。 根据任务的不同，CPU 的上下文切换可以分为几个不同的场景，也就是： 进程上下文切换、 线程上下文切换、 中断上下文切换。 3 种场景进程上下文切换系统调用系统调用的过程中并不会涉及虚拟内存等进程用户态的资源，也不会切换进程，这和平时说的进程上下文切换是不一样的： 进程上下文切换，是指 ...

单元测试过程中的一些总结，记录如何利用 Mockito 和 JUnit 来编写单元测试。 认识一下🚀 什么是单元测试？单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证，这些测试有助于验证代码是否正常运行并识别任何错误或错误。至于“单元”的大小或范围，并没有一个明确的标准，“单元”可以是一个函数、方法、类、功能模块或者子系统。这种类型的测试完全孤立地集中在整个应用程序的一部分上。通常，它是单个类或函数。理想情况下，该装置没有任何副作用。以便尽可能容易地对其进行隔离和测试。单元测试是自动化测试。换句话说，单元测试是由软件（例如单元测试框架或单元测试工具）执行的，而不是由开发人员手动执行的。这意味着单元测试允许自动化、可重复、连续的测试。作为开发人员，一旦编写完一段代码，就会编写单元测试。我们可能会问，这不是测试员的工作吗？在某种程度上，是的，测试人员负责测试软件。但是，覆盖每一行代码给测试人员增加了很大的压力。因此，开发人员为自己的代码编写测试也是最佳实践。 😘优点： 质量问题识别：单元测试有助于识别与安全性、保密性和可靠性相关的缺陷，确保更高的代码质 ...

单元测试包含的基本的东西包括：测试的环境准备，就是 mock 出来的对象，规定对象要发生的行为，最重要的是要进行断言，看这个行为返回的结果是否符合预期。 在要编写测试类的类中右键选择 基础知识Mockito一、为什么需要 mock ？Mock 可以理解为一个虚假的对象，模拟出一个对象，在测试环境中用来替换掉真实的对象，以达到我们可以：1、验证该对象某些方法的调用情况，调用了多少次，参数是什么。2、给这个对象的行为做一个定义，来指定返回结果或者是指定特定的动作。 二、Mock方法Mockito.mock(类)：Mock 方法模拟出一个对象或者接口 三、验证和断言Mockito.verify()方法：校验待验证的的对象是否发生过某些行为。verify 配合 time() 方法可以校验某些操作发生的次数：Mockito.verify(对象, Mockito.times(1)).nextInt() 四、给 Mock 对象打桩意思就是给 mock 对象的行为做定义，让 mock 对象执行操作后返回提前规定好的值。Mockito.when(对象. 方法). 要求的相应。 五、@Mock 注解可以理 ...

分布式理论CAP 理论CAP理论的适用前提是多个节点之间是相同的服务，即多个副本节点组成的集群。在这种情况下，当发生网络分区时，副本节点之间的数据同步会受到影响，需要在一致性（Consistency）和可用性（Availability）之间进行权衡。 CAP理论适用于具有相同服务的多副本集群，而不适用于多个不同服务的分布式系统。 在分布式系统中，当网络分区发生时，节点之间的通信可能受阻或丢失，导致节点之间无法进行数据同步和协调。这时，系统需要具备一定的分区容错性，以保证系统的可用性。 一旦出现网络分区，即节点之间的通信被中断，系统必须在一致性和可用性之间进行权衡。 分区容错性？ 当谈论分区容错性时，我们指的是分布式系统在发生网络分区的情况下，仍然能够正常运行并对外提供服务。 网络分区是指在分布式系统中，节点之间的通信被中断或者延迟非常严重，导致节点无法互相通信。这可能是由于网络故障、网络拥塞、节点故障等原因引起的。 为了实现分区容错性，分布式系统通常采取以下策略： 副本复制：将数据在多个节点之间进行复制，以保证数据的可用性和冗余。当发生网络分区时，即使某些节点无法与其他节 ...

为什么要使用消息队列消息队列提供了一种高效、可靠、灵活的通信机制，能够帮助解决系统之间的耦合、流量突发和可靠传递等问题，提高系统的性能、可维护性和可扩展性。因此，在分布式系统、微服务架构和大规模数据处理等场景中，使用消息队列是一种常见的解决方案。一个消息队列可以被一个或多个消费者消费，一般包含以下元素： Producer：消息生产者，负责产生和发送消息到 Broker。 Broker：消息处理中心，负责消息存储、确认、重试等，一般其中会包含多个 Queue。 Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理。 使用消息队列的好处使用消息队列有以下几个好处： 异步通信：消息队列可以实现异步通信机制，发送方将消息发送到队列后即可继续处理其他任务，而不需要等待接收方的响应。这样可以提高系统的响应速度和吞吐量。 解耦合：消息队列可以将消息的发送方和接收方解耦，它们不需要直接交互。发送方只需要将消息发送到队列中，而接收方则从队列中获取消息进行处理。这种解耦合的设计可以降低系统的复杂性，增强系统的可维护性和可扩展性。 削峰填谷：消息队列可以用于平滑处理系统中的峰 ...

CAP理论CAP理论是对分布式系统的特性进行高度抽象，提出了三个指标： 一致性（Consistency） 可用性（Availability） 分区容错性（Partition Tolerance） 一致性（C）： 一致性要求无论客户端进行读取操作时访问哪个节点，都应该读取到相同的最新数据，或者读取失败。 一致性可以被视为分布式系统对客户端的一种承诺：无论访问哪个节点，系统都会返回绝对一致的数据，否则读取操作将失败。因此，一致性强调的是各节点之间的数据一致性，而非数据完整性。可用性（A）： 可用性要求任何来自客户端的请求，无论访问哪个节点，都能得到响应数据，但不保证是同一份最新数据。 可用性可以被视为分布式系统对客户端的另一种承诺：尽力返回数据，不会不响应，但不保证每个节点返回的数据都是最新的。该指标强调的是服务可用性，而非数据一致性。分区容错性（P）： 当节点间出现任意数量的消息丢失或高延迟时，系统仍然能够提供服务。 换句话说，分布式系统向访问客户端保证：无论出现何种内部数据同步问题，系统都将持续运行并提供服务。该指标强调集群对分区故障的容错能力。 如何使用CAP理论 鉴于网 ...

分布式事务在数据系统的残酷现实中，很多事情都可能出错： 数据库软件、硬件可能在任意时刻发生故障（包括写操作进行到一半时）。 应用程序可能在任意时刻崩溃（包括一系列操作的中间）。 网络中断可能会意外切断数据库与应用的连接，或数据库之间的连接。 多个客戶端可能会同时写入数据库，覆盖彼此的更改。 客戶端可能读取到无意义的数据，因为数据只更新了一部分。 客戶端之间的竞争条件可能导致令人惊讶的错误。 为了实现可靠性，系统必须处理这些故障，确保它们不会导致整个系统的灾难性故障。但是实现容错机制工作量巨大。需要仔细考虑所有可能出错的事情，并进行大量的测试，以确保解决方案真正管用。 数十年来， 事务（transaction） 一直是简化这些问题的首选机制。事务是应用程序将多个读写操作组合成一个逻辑单元的一种方式。从概念上讲，事务中的所有读写操作被视作单个操作来执行：整个事务要么成功 提交 （commit），要么失败 中止 （abort）或 回滚 （rollback）。如果失败，应用程序可以安全地重试。对于事务来说，应用程序的错误处理变得简单多了，因为它不用再担心部分失败的情况了，即某些操作成功，某 ...

数据一致性复制意味着在通过网络连接的多台机器上保留相同数据的副本。我们希望能复制数据，可能出于各种各样的原因： 使得数据与用戶在地理上接近（从而减少延迟） 即使系统的一部分出现故障，系统也能继续工作（从而提高可用性） 伸缩可以接受读请求的机器数量（从而提高读取吞吐量） 本章将假设你的数据集非常小，每台机器都可以保存整个数据集的副本。后续章节中将放宽这个假设，讨论对单个机器来说太大的数据集的分割（分片）。我们将讨论复制数据系统中可能发生的各种故障，以及如何处理这些故障。 如果复制中的数据不会随时间而改变，那复制就很简单：将数据复制到每个节点一次就万事大吉。复制的困难之处在于处理复制数据的 变更（change） ，这就是本章所要讲的。我们将讨论三种流行的变更复制算法： 单领导者（singleleader，单主） ， 多领导者（multileader，多主） 和 无领导者（leaderless，无主） 。几乎所有分布式数据库都使用这三种方法之一。 在复制时需要进行许多权衡：例如，使用同步复制还是异步复制？如何处理失败的副本？这些通常是数据库中的配置选项，细节因数据库而异，但原理在许多不同 ...