发表于

在分布式系统中，数据不是存储在单个节点中的，所以分布式系统面临数据的一致性问题，就比如 DNS 系统中，域名的更新一样。为了解决这个问题，出现了 paxos 算法，paxos 算法其实是一个共识算法。系统的最终一致性，不仅需要达成共识，还会取决于 client 的行为。

发表于

  1. 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；

  2. 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；

  3. 丢弃重复数据：对于重复数据，能够丢弃重复数据；

  4. 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

  5. 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

  6. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

发表于

Redis中采用两种算法进行内存回收，引用计数算法 以及LRU算法，在操作系统内存管理一节中，我们都学习过LRU算法(最近最久未使用算法),那么什么是LRU算法呢

LRU算法作为内存管理的一种有效算法,其含义是在内存有限的情况下，当内存容量不足时，为了保证程序的运行，这时就不得不淘汰内存中的一些对象，释放这些对象占用的空间，那么选择淘汰哪些对象呢？LRU算法就提供了一种策略，告诉我们选择最近一段时间内，最久未使用的对象将其淘汰，至于为什么要选择最久未使用的，可以想想，最近一段时间内使用的东西，我们是不是可能一会又要用到呢~，而很长一段时间内都没有使用过的东西，也许永远都不会再使用~

在操作系统中LRU算法淘汰的不是内存中的对象，而是页,当内存中数据不足时，通过LRU算法，选择一页(一般是4KB)将其交换到虚拟内存区(Swap区)

阅读全文 »

发表于

异常的一些基本知识

  • 异常的架构

　　异常的继承结构：Throwable为基类，Error和Exception继承Throwable。Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。

image-20191011140924190

  • Error异常

　　Error表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行，例如JAVA 虚拟机出现错误。Error是一种unchecked Exception，编译器不会检查Error是否被处理，在程序中不用捕获Error类型的异常。一般情况下，在程序中也不应该抛出Error类型的异常。

  • RuntimeException异常

　　Exception异常包括RuntimeException异常和其他非RuntimeException的异常。
　　RuntimeException 是一种Unchecked Exception，即表示编译器不会检查程序是否对RuntimeException作了处理，在程序中不必捕获RuntimException类型的异常，也不必在方法体声明抛出　RuntimeException类。RuntimeException发生的时候，表示程序中出现了编程错误，所以应该找出错误修改程序，而不是去捕获RuntimeException。

  • Checked Exception异常

　　Checked Exception异常，这也是在编程中使用最多的Exception，所有继承自Exception并且不是RuntimeException的异常都是checked Exception，上图中的IOException和ClassNotFoundException。JAVA 语言规定必须对checked Exception作处理，编译器会对此作检查，要么在方法体中声明抛出checked Exception，要么使用catch语句捕获checked Exception进行处理，不然不能通过编译。

发表于

HTTP 状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。

状态码 类别 含义
1XX Informational（信息性状态码） 接收的请求正在处理
2XX Success（成功状态码） 请求正常处理完毕
3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
4XX Client Error（客户端错误状态码） 服务器无法处理请求
5XX Server Error（服务器错误状态码） 服务器处理请求出错

1XX 信息

  • 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

  • 200 OK
  • 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
  • 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

  • 301 Moved Permanently ：永久性重定向
  • 302 Found ：临时性重定向
  • 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
  • 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
  • 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
  • 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4XX 客户端错误

  • 400 Bad Request ：请求报文中存在语法错误。
  • 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
  • 403 Forbidden ：请求被拒绝。
  • 404 Not Found

5XX 服务器错误

  • 500 Internal Server Error ：服务器正在执行请求时发生错误。
  • 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

发表于
  1. InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
  2. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；
  3. InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。
  4. MyISAM 可以被压缩后进行查询操作
  5. MyISAM 支持表级锁，InnoDB支持表，行锁。
  6. InnoDB 不支持全文索引，而 MyISAM 支持全文索引，5.7 以后InnoDB 支持全文索引。
  7. InnoDB 必须有主键，MyISAM 可以没有。

发表于

Redis的字典使用哈希表作为底层实现，一个哈希表里面可以有多个哈希表节点，而每个哈希表节点就保存了字典中的一个键值对。

哈希表

1
2
3
4
5
6
7
8
9
10
11
typedef struct dictht {
  // 哈希表数组
  dictEntry **table;
  // 哈希表大小
  unsigned long size;
  // 哈希表大小掩码，用于计算索引值
  // 总是等于size-1
  unsigned long sizemask;
  // 哈希表已经有的节点数量
  unsigned long used;
} dictht;

发表于

消费者和消费者群组

Kafka 消费者从属于消费者群组。一个群组里的消费者订阅的是同一个主题，每个消费者 接收主题一部分分区的消息。

假设主题 T1 有 4 个分区，我们创建了消费者 C1，它是群组 G1 里唯一的消费者，我们用 它订阅主题 T1。消费者 C1 将收到主题 T1 全部 4 个分区的消息，如图 4-1 所示

image-20190831174741523

如果在群组 G1 里新增一个消费者 C2，那么每个消费者将分别从两个分区接收消息。我们 假设消费者 C1 接收分区 0 和分区 2 的消息，消费者 C2 接收分区 1 和分区 3 的消息，如图 4-2 所示。

image-20190831174807588

如果群组 G1 有 4 个消费者，那么每个消费者可以分配到一个分区，如图 4-3 所示。

image-20190831174829692

如果我们往群组里添加更多的消费者，超过主题的分区数量，那么有一部分消费者就会被 闲置，不会接收到任何消息，如图 4-4 所示。

image-20190831174853617

往群组里增加消费者是横向伸缩消费能力的主要方式。

不要让消费者的数 量超过主题分区的数量，多余的消费者只会被闲置。一个分区只能由同一个消费组内一个消费者消费。

除了通过增加消费者来横向伸缩单个应用程序外，还经常出现多个应用程序从同一个主题 读取数据的情况。

在上面的例子里，如果新增一个只包含一个消费者的群组 G2，那么这个消费者将从主题 T1 上接收所有的消息，与群组 G1 之间互不影响。群组 G2 可以增加更多的消费者，每个 消费者可以消费若干个分区，就像群组 G1 那样，如图 4-5 所示。总的来说，群组 G2 还是 会接收到所有消息，不管有没有其他群组存在。

image-20190831175858358

消费者群组和分区再均衡

分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再均衡。

在再均衡期间，消费者无法读取消 息，造成整个群组一小段时间的不可用。

它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢 应用程序。

消费者通过向被指派为群组协调器的 broker（不同的群组可以有不同的协调器）发送心跳 来维持它们和群组的从属关系以及它们对分区的所有权关系。

消费者会在轮询消息 （为了获取消息）或提交偏移量时发送心跳。如果消费者停止发送心跳的时间足够长，会 话就会过期，群组协调器认为它已经死亡，就会触发一次再均衡。

分配分区是怎样的一个过程

当消费者要加入群组时，它会向群组协调器发送一个 JoinGroup 请求。第一 个加入群组的消费者将成为“群主”。群主从协调器那里获得群组的成员列 表（列表中包含了所有最近发送过心跳的消费者，它们被认为是活跃的）， 并负责给每一个消费者分配分区。它使用一个实现了 PartitionAssignor 接 口的类来决定哪些分区应该被分配给哪个消费者。 Kafka 内置了两种分配策略，在后面的配置参数小节我们将深入讨论。分配 完毕之后，群主把分配情况列表发送给群组协调器，协调器再把这些信息发 送给所有消费者。每个消费者只能看到自己的分配信息，只有群主知道群组 里所有消费者的分配信息。这个过程会在每次再均衡时重复发生。

提交和偏移量

每次调用 poll() 方法，它总是返回由生产者写入 Kafka 但还没有被消费者读取过的记录， 我们因此可以追踪到哪些记录是被群组里的哪个消费者读取的。

发表于

Kafka 是一款基于发布订阅的消息系统。一般被称为 分布式消息提交日志，或者 分布式流平台。文件系统或数据库提交日志用来提供所有食物的持久记录，通过重放这些日志可以重建系统的状态。Kafka 的数据是按照一定的顺序持久化保存的，可以按需读取。

消息和批次

Kafka 的数据单元被称为消息。

消息由字节数组组成，所以 对于 Kafka 来说，消息里的数据没有特别的格式或含义。消息可以有一个可选的元数据， 也就是键。键也是一个字节数组，与消息一样，对于 Kafka 来说也没有特殊的含义。当消 息以一种可控的方式写入不同的分区时，会用到键。最简单的例子就是为键生成一个一致 性散列值，然后使用散列值对主题分区数进行取模，为消息选取分区。这样可以保证具有 相同键的消息总是被写到相同的分区上。

为了提高效率，消息被分批次写入 Kafka。批次就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传 输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时 间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升 数据的传输和存储能力，但要做更多的计算处理。

主题和分区

Kafka 的消息通过主题进行分类。主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分为若干个分区，一个分区就是一个提交日志。消息以追加的方式写入分区，然 后以先入先出的顺序读取。要注意，由于一个主题一般包含几个分区，因此无法在整个主 题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

image-20190831153254776

图 1-5 所示的主题有 4 个分区，消息被追加写入每个分区的尾部。Kafka 通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。

我们通常会使用流这个词来描述 Kafka 这类系统的数据。很多时候，人们把一个主题的数 据看成一个流，不管它有多少个分区。流是一组从生产者移动到消费者的数据。

生产者和消费者

Kafka 的客户端就是 Kafka 系统的用户，它们被分为两种基本类型：生产者和消费者。

生产者创建消息。在其他发布与订阅系统中，生产者可能被称为发布者或写入者。一般情 况下，一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到 主题的所有分区上，而并不关心特定消息会被写到哪个分区。不过，在某些情况下，生产 者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生 成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到 同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分 区。

消费者读取消息。在其他发布与订阅系统中，消费者可能被称为订阅者或读者。消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区 分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息 时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费 者把每个分区最后读取的消息偏移量保存在 Zookeeper 或 Kafka 上，如果消费者关闭或重 启，它的读取状态不会丢失。

消费者是消费者群组的一部分，也就是说，会有一个或多个消费者共同读取一个主题。群 组保证每个分区只能被一个消费者使用。如果一个消费者失效，群组 里的其他消费者可以接管失效消费者的工作。

image-20190831154148369

broker和集群

一个独立的 Kafka 服务器被称为 broker。broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松处理数 千个分区以及每秒百万级的消息量。 broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色（自动 从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给 broker 和监控 broker。在集群中，一个分区从属于一个 broker，该 broker 被称为分区的首领。一个分区 可以分配给多个 broker，这个时候会发生分区复制（见图 1-7）。这种复制机制为分区提供 了消息冗余，如果有一个 broker 失效，其他 broker 可以接管领导权。不过，相关的消费者 和生产者都要重新连接到新的首领。

image-20190831154752072

保留消息（在一定期限内）是 Kafka 的一个重要特性。Kafka broker 默认的消息保留策略 是这样的：要么保留一段时间（比如 7 天），要么保留到消息达到一定大小的字节数（比 如 1GB）。当消息数量达到这些上限时，旧消息就会过期并被删除，所以在任何时刻，可 用消息的总量都不会超过配置参数所指定的大小。

为什么选择Kafka

  • 多个生产者
  • 多个消费者
  • 基于磁盘的数据存储
  • 伸缩性
  • 高性能