KasheemLew

KasheemLew 查看完整档案

武汉编辑华中师范大学  |  计算机科学与技术 编辑Muxi Studio  |  后端 编辑 kasheemlew@github.io 编辑
编辑

Pythoner || Gopher
Back-end Developer
@Muxi-Studio

个人动态

KasheemLew 发布了文章 · 2020-09-29

Redis 持久化

Redis 所有的数据和状态存储在内存中,为了避免进程退出而导致数据丢失,需要将数据和状态保存到硬盘上。

为了达到这一目的,通常有两种实现方式:

  1. 将 Redis 当作一个状态机,记录每一次的对 Redis 的操作,也就是状态转移。需要恢复时再从初始状态开始,依次重放记录的操作,这样的方式称作逻辑备份
  2. 将 Redis 完整的状态保存下来,待必要时原样恢复,这样的方式称作物理备份

Redis 也实现了这两种持久化方式,分别时 AOF 和 RDB

AOF

AOF 通过保存 Redis 服务器执行的写命令记录数据库状态。

AOF 配置

Redis 源码中的配置文件示例: redis.conf

AOF 配置示例

https://github.com/redis/redi...

重要参数:

appendonly yes # 是否开启 AOF,如果开启了 AOF,后续恢复数据库时会优先使用 AOF,跳过 RDB
appendfsync everysec # 持久化判断规则
appendfilename appendonly.aof # AOF 文件位置

void flushAppendOnlyFile(int force) {
ssize_t nwritten;
...
// 调用 write 写入文件
nwritten = write(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));
...
// 成功写入后
server.aof_current_size += nwritten;
...
// 根据 appndfsync 条件判断是否同步到 AOF 文件
if (server.aof_fsync == AOF_FSYNC_ALWAYS) {
...
// 这里强制执行同步用的是 aof_fsync,是因为 aof_fsync 已经被定义成了 fsync
// 具体位置在 config.h:https://github.com/redis/redis/blob/48e24d54b736b162617112ce27ec724b9290592e/src/config.h#L89
aof_fsync(server.aof_fd);
...
// 成功后记录下时间,用于下一次同步条件检查
server.aof_last_fsync = server.unixtime;
} else if ((server.aof_fsync == AOF_FSYNC_EVERYSEC &&
server.unixtime > server.aof_last_fsync)) {
// 在另一个线程中后台执行
if (!sync_in_progress) aof_background_fsync(server.aof_fd);
server.aof_last_fsync = server.unixtime;
}
}

# RDB 配置示例
# https://github.com/redis/redis/blob/48e24d54b736b162617112ce27ec724b9290592e/redis.conf#L125

# 重要参数:
dbfilename dump.rdb
dir /var/lib/redis

// https://github.com/redis/redis/blob/48e24d54b736b162617112ce27ec724b9290592e/src/redis.c#L1199

// 开始检查自动保存条件前会先检查是否有正在后台执行的 RDB 和 AOF 进程
if (server.rdb_child_pid != -1 || server.aof_child_pid != -1) {
// 已有后台的 RDB 或 AOF 进程
} else {
// 遍历 saveparams 链表中所有的配置条件
for (j = 0; j < server.saveparamslen; j++) {
struct saveparam *sp = server.saveparams+j;

/* 满足自动保存的标准:
1. 从上次完成 RDB 到现在的数据库修改次数(dirty)已经达到了 save 配置中 changes 的值
2. 距上一次完成 RDB 的时间(lastsave)已经达到了 save 配置中 seconds 的值
3. 上一次 RDB 已经成功,或者距上一次尝试 RDB 的时间(lastbgsave_try)已经达到了配置的超时时间(REDIS_BGSAVE_RETRY_DELAY)
*/
if (server.dirty >= sp->changes &&
server.unixtime-server.lastsave > sp->seconds &&
(server.unixtime-server.lastbgsave_try >
REDIS_BGSAVE_RETRY_DELAY ||
server.lastbgsave_status == REDIS_OK))
{
redisLog(REDIS_NOTICE,"%d changes in %d seconds. Saving...",
sp->changes, (int)sp->seconds);
rdbSaveBackground(server.rdb_filename);
break;
}
}
}

写多读少的场景下,使用 RDB 备份的风险

Ref


解决方法:全量快照后只做增量快照,但是需要记住修改的数据,下次全量快照时再写入,但这需要在内存中记录修改的数据。因此 Redis 4.0 提出了混合使用 AOF 和全量快照,用 aof-use-rdb-preamble yes 设置。这样,两次全量快照间的修改会记录到 AOF 文件

  1. 全量数据写入磁盘,磁盘压力大。快照太频繁,前一个任务还未执行完,快照任务之间竞争磁盘带宽,恶性循环
  2. fork 操作本身阻塞主线程,主线程内存越大,阻塞时间越长,因为要拷贝内存页表

频繁执行全量快照的问题

利用 COW 机制,fork 出子进程共享主线程的内存数据。在主线程修改数据时把这块数据复制一份,此时子进程将副本写入 rdb,主线程仍然修改原来的数据

如何保证写操作正常执行

value 结构

备注

示例

类型

编码,值

表示可以用 8 位整数表示的字符串

REDIS_RDB_ENC_INT8,123

REDIS_RDB_TYPE_STRING

表示字符串

REDIS_ENCODING_RAW, 5, hello

元素个数,列表元素

其中会记录每个元素的长度

3, 5, "hello", 5, "world"

REDIS_RDB_TYPE_LIST

元素个数,集合元素

其中会记录每个元素的长度

3, 5, "hello", 5, "world"

REDIS_RDB_TYPE_SET

键值对个数,键值对

其中会记录每个键值对 key, value 的长度

2, 1, "a", 5, "apple", 1, "b", 6, "banana"

REDIS_RDB_TYPE_HASH

元素个数,member 和 score 对

其中会记录 member 的长度,member 在 score 前面

2, 2, "pi", 4, "3.14", 1, "e", 3, "2.7"

REDIS_RDB_TYPE_ZSET

转化成字符串对象的整数集合

读取 RDB 时需要将字符串对象转化回整数集合

REDIS_RDB_TYPE_SET_INTSET

转化成字符串对象的压缩列表

读取时需要转化成列表

REDIS_RDB_TYPE_LIST_ZIPLIST

转化成字符串对象的压缩列表

读取时需要转化成哈希

REDIS_RDB_TYPE_HASH_ZIPLIST

转化成字符串对象的压缩列表

读取时需要转化成有序集合

REDIS_RDB_TYPE_ZSET_ZIPLIST

各类型对应的 value 结构如下:

这个类型会影响读取数据时如何解释后面 value 代表的值,而 key 则总是被当作 REDIS_RDB_TYPE_STRING 类型

这些编码常量所对应的值都可以在rdb.h 中查看

数据结构类型

编码常量

字符串

REDIS_RDB_TYPE_STRING,值为 0

列表

REDIS_RDB_TYPE_LIST,值为 1

集合

REDIS_RDB_TYPE_SET,值为 2

有序集和

REDIS_RDB_TYPE_ZSET,值为 3

哈希

REDIS_RDB_TYPE_HASH,值为 4

使用压缩列表实现的列表

REDIS_RDB_TYPE_LIST_ZIPLIST

使用整数集合实现的集合

REDIS_RDB_TYPE_SET_INTSET

使用压缩列表实现的有序集合

REDIS_RDB_TYPE_ZSET_ZIPLIST

使用压缩列表实现的哈希

REDIS_RDB_TYPE_HASH_ZIPLIST

key_values 中保存了所有的键值对,主要包括 key,value 和 value 的类型,对于设置了过期时间的 key,还有 EXPIRETIME_MS 常量(值为 374)和用 unix 时间戳表示的过期时间。其中类型可以是下表中的值,分别对应了 Redis 数据结构的类型:

数据文件中存储了所有的数据。开头的 SELECTDB 常量(值为 376)和紧接着的编号,指示了读取 RDB 文件时,后续加载的数据将会被写入哪个数据库中。

RDB 文件主要由五个部分构成:

RDB 文件格式(以版本“0006”为例)

Redis 使用int serverCron 函数执行定时任务,这些任务包括自动保存条件检查、更新时间戳、更新 LRU 时钟等。serverCron 每隔 100 ms 执行一次,其中检查自动保存条件的代码如下:

[](https://github.com/redis/redi...struct redisServerlong long dirty 用来保存从上一次 RDB 持久化之后数据库修改的次数,set <key> <value> 会对 dirty 加一,而 sadd <set-name> <value1> <value2> <value3> 会对 dirty 加 3。time_t lastsave 记录了上一次完成 RDB 持久化的时间

如何判断是否满足自动保存的条件?

Redis 启动式根据用户设定的保存条件开启自动保存。在/etc/redis/redis.conf 配置文件中加上 save <seconds> <changes> 表示在 seconds 秒内对数据库进行了 changes 次修改,BGSAVE 命令就会执行。这个配置会被加载到struct redisServerstruct saveparam 参数中。saveparam 是一个链表,当配置多个 save 条件时,这个条件都会被加入链表中。

自动执行持久化

载入 RDB 文件时实际工作由rdb.c/rdbLoad 完成,载入期间主线程处于阻塞状态。

Redis 启动时,会根据 /etc/redis/redis.conf 配置文件中的 dirdbfilename 加载 RDB 文件。如果已经开启了 AOF 持久化,Redis 会优先使用 AOF 来恢复数据库,配置文件例如:

SAVEBGSAVE 都会调用rdb.c/rdbSave 执行真正的持久化过程。

在 Redis 6.0 以前,虽然 Redis 处理处理请求是单线程的,但 Redis Server 还有其他线程在后台工作,例如 AOF 每秒刷盘、异步关闭文件描述符这些操作

其中 SAVE 阻塞主线程,在 RDB 文件生成完之前不能处理任何请求。而BGSAVE 则会 fork 一个子进程,在子进程中创建 RDB 文件,父进程仍然能够处理客户端的命令。但是 BGSAVE 执行过程中,新的 SAVEBGSAVE 命令会被拒绝,因为会产生竞争条件,BGWRITEAOF 命令会被延迟到 BGSAVE 结束之后。作为对比,BGWRITEAOF 执行过程中,BGSAVE 命令会被拒绝,这里拒绝 BGSAVE 是出于性能考虑,两者实际上不存在竞争冲突

Redis 的 RDB 持久化功能通过 SAVEBGSAVE 两个命令可以生成压缩的二进制 RDB 文件,通过这个文件可以还原生成文件时数据库的状态。

手动执行持久化

RDB

AOF 重写完成后,子进程会向父进程发送一个完成信号。父进程收到后将 AOF 重写区的内容追加到新 AOF 文件中,然后将 AOF 改名,覆盖原来的 AOF 文件

AOF 重写过程中,Redis 服务器仍然要接收客户端的写入请求,为了保证数据安全,使用了子进程执行 AOF 重写,此时如果执行写入命令,子进程并不知道父进程所做的修改,AOF 完成之后会出现 AOF 文件中的数据与实际数据库中的数据不一致的情况。因此在 AOF 重写期间,客户端接收到的命令除了写入 AOF 缓冲区,还要写入 AOF 重写缓冲区

AOF 缓冲

对于有多个元素的 key,例如大列表、大集合,简单的将所有元素的写入合并到一条语句中可能会形成一条过大的写入语句,在后续执行命令时导致客户端输入缓冲区溢出。因此 Redis 配置了一个REDIS_AOF_REWRITE_ITEMS_PER_CMD 常量,当一条命令中的元素超过这个数量时,会被拆分成多条语句

AOF 重写的过程中并不会读取原有的 AOF 文件,而是直接根据数据库当前的状态生成一份新的 AOF 文件,类似于 SQL 导出数据时直接生成 INSERT 语句。

由于 AOF 文件是依次记录客户端发来的写入命令,在写入较多的情况下,AOF 文件会快速膨胀,因此需要 AOF 重写精简其中的命令。

AOF 重写

  1. Redis 创建一个不带网络连接的伪客户端
  2. 从 AOF 文件中依次读出命令并交给伪客户端执行。这个过程和正常的 Redis 客户端从网络中依次读取命令然后执行效果一致

AOF 文件载入

AOF 判断过程如下:

flushAppendOnlyFile 行为

appndfsync 选项

总是将 aof_buf 缓冲区中的内容写入内存缓冲区,并同步到 AOF 文件

always

将 aof_buf 缓冲区中的内容写入内存缓冲区,如果距离上一次同步超过一秒,则同步到 AOF 文件

everysec

只写入到内存缓冲区,由 OS 后续决定何时同步到 AOF 文件

no

如果只执行了第一步,从 redis 的视角来看,数据已经写入了文件,但实际上并没有写入,如果此时停机,数据仍然会丢失,因此可以使用 OS 提供的 fsyncfdatasync 强制将缓冲区中的数据写入磁盘

  1. 调用 OS 的 write 函数,将 aof_buf 中的命令保存到内存缓冲区
  2. OS 将 内存缓冲区中的写入磁盘

flushAppendOnlyFile 中根据配置文件中的 appendfsync 参数判断是否写入 AOF 文件。将 aof_buf 中的命令写入 AOF 文件分为两个步骤:

AOF 写入条件判断规则

  1. 服务器在执行完命令后,会将命令写入到 struct redisServersds aof_buf` 缓冲区末尾
  2. Redis 进程每一次事件循环(处理客户端请求的循环)末尾都会调用void flushAppendOnlyFile 检查时候需要将缓冲区中的命令写入 AOF 文件

AOF 持久化执行步骤

  1. 刚执行完命令,还没写入,此时宕机,这个命令和相应的数据有丢失的风险
  2. 避免了当前命令的阻塞,但是可能阻塞下一个命令

风险:

  1. 可以保证日志中记录的命令都是正确的
  2. 命令执行后才记录到日志,不会阻塞当前写操作

AOF 是写后日志,与写前日志(Write Ahead Log, WAL)相反,写入命令执行完成后才会记录到 AOF 日志。这样设计是因为 AOF 记录的是接收到的命令,并且记录时不会进行语法检查(保证性能),使用写后日志有 2 个优点

命令执行完成后才会写入 AOF 日志

查看原文

赞 0 收藏 0 评论 0

KasheemLew 发布了文章 · 2020-08-31

Redis 哨兵模式(Sentinel) 原理

Redis 哨兵模式(Sentinel) 原理

Redis 高可用相关的技术:

  • 持久化:单机备份(从内存到硬盘的备份)
  • 主从复制:多机热备、负载均衡、故障恢复
  • 哨兵:自动化的故障恢复
  • 集群:写操作负载均衡,存储能力水平扩展

为什么需要哨兵模式(Sentinel)

  1. 只依靠持久化方案,在服务器下线后无法恢复服务
  2. 使用主从复制,在 master 节点下线后,可以手动将 slave 节点切换为 master,但是不能自动完成故障转移

哨兵模式(Sentinel)

<img data-original="https://i.loli.net/2020/08/28/IUVAXdZJCS8hlL3.png" style="zoom:67%;background-color:" />

主要功能

  1. 监控(Monitoring):Sentinel会不断的检查你的主节点和从节点是否正常工作。
  2. 通知(Notification):被监控的Redis实例如果出现问题,Sentinel可以通过API(pub)通知系统管理员或者其他程序。
  3. 自动故障转移(Automatic failover):如果一个 master 离线,Sentinel 会开始进行故障转移,master 下的一个slave 会被选为新的 master,其他的 slave 会开始复制新的 master。应用可以通过 Redis 服务的通知机制更新新的master 地址。
  4. 配置提供(Configuration provider):客户端可以把 Sentinel 作为权威的配置发布者来获得最新的 master 地址。如果发生了故障转移,Sentinel 集群会通知客户端新的 master 地址,并刷新 Redis 的配置。

主要配置

  1. sentinel monitor <master-name> <ip> <redis-port> <quorum>: 监控的 redis 主节点

    sentinel 是 redis 配置的提供者,而不是代理,客户端只是从 sentinel 获取数据节点的配置,因此这里的 ip 必须是 redis 客户端能够访问的。

    redis 源码中提供了 sentinel 配置的模板:sentinel.conf

Sentinel 启动

$ redis-server sentinel.conf --sentinel
  1. 初始化一个普通的 redis 服务器
  2. 加载 Sentinel 专用配置,例如命令表、参数等,Sentinel 使用 sentinel.c 中的命令表、函数等配置,普通 Redis 则使用 redis.c 中的配置
  3. 除了保存服务器一般状态之外,Sentinel 还会保存 Sentinel 相关状态

准备

Sentinel 与 master: Sentinel 监控 master,并通过 master 发现其他 Sentinel 和 slaves

建立两个异步网络连接:

  1. 命令连接:用于向 Redis master 数据节点发送命令,例如通过 INFO 命令了解:

    1. master 本身运行信息,用于更新本地的 master 字典(Redis Hash 的实现中用到字典使用的的也是这个数据结构)
    2. slaves 信息(角色、IP、Port、连接状态、优先级、复制偏移量),用于更新本地的 slave 字典
  2. 订阅连接:订阅 __sentinel__:hello 频道,用于发现其他 Sentinel,频道中信息包括:

    1. Sentinel 自身信息(IP、Port、RunID、Epoch)
    2. 监视的 Master 节点的信息(Name、IP、Port、Epoch)
<img data-original="https://i.loli.net/2020/08/28/3nwK61RyB2aIfoY.png" style="zoom:67%;" />

Sentinel 与 slave:Sentinel 自动发现 Slave

  1. Sentinel 向 master 节点发送 INFO 命令后获取到所有 slave 的信息

    <img data-original="https://i.loli.net/2020/08/28/kN6uVhI8DYOMHbW.png" style="zoom:67%;" />

  2. Sentinel 与 slave 建立命令连接订阅连接

    <img data-original="https://i.loli.net/2020/08/28/KdbCoQJOw1uPH7W.png" style="zoom:67%;" />

Sentinel 之间:自动发现机制

  1. Sentinel 利用 pub/sub(发布/订阅)机制,订阅了每个 master 和 slave 数据节点的 __sentinel__:hello 频道,去自动发现其它也监控了统一 master 的 sentinel 节点
  2. Sentinel 向每 1s 向 __sentinel__:hello 中发送一条消息,包含了其当前维护的最新的 master 配置。如果某个sentinel发现自己的配置版本低于接收到的配置版本,则会用新的配置更新自己的 master 配置
  3. 与发现的 Sentinel 之间相互建立命令连接,之后会通过这个命令连接来交换对于 master 数据节点的看法

监控

  1. 定时监控 Redis 数据节点

    1. 每 10 秒每个 sentinel 向 master、slaves 节点发送 INFO 命令
    2. 每 2 秒每个 sentinel 通过 master 节点的 channel(名称为 __sentinel__:hello) 交换信息(pub/sub),信息包括:
    3. 每 1 秒每个 sentinel 对其他 sentinel 和 redis master, slave 发送 PING 命令,用于心跳检测,作为节点存活的判断依据
  2. 主观下线和客观下线(发现故障)

    1. 主观下线(subjectively down,SDOWN):当前 Sentinel 实例认为某个 redis 服务为”不可用”状态。Sentinel 向 redis master 数据节点发送消息后 30s(down-after-milliseconds) 内没有收到有效回复(+PONG、-LOADING 或者 -MASTERDOWN),Sentinel 会将 master 标记为下线(打开 master 结构中 flags 的 SRI_S_DOWN 标记)
    2. 客观下线(objectively down,ODOWN):多个 Sentinel 实例都认为 master 处于 SDOWN 状态,那么此时 master 将处于 ODOWN, ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制。向其他 sentinel 节点发送 sentinel is-master-down-by-addr 消息询问数据节点情况,得知达到 quorum 数量的 sentinel 节点认为数据节点已经下线

处理

  1. Sentinel 选举(基于 Raft 算法),选出一个 Leader

    投票:修改本地 leader 和 leader_epoch

    1. 对于已经投过票,身份变为 Follower,在 2 倍故障转移时间内不再进行选举(故障转移的超时时间默认是3分钟);没投过票的变为 Candidate,执行第 2 步
    2. 更新故障转移状态为start,epoch + 1,更新超时时间为 1s 内随机时间
    3. 向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch
    4. 2 倍故障转移时间内选举
**Sentinel 选举算法与 Raft 的区别:**

1. 每次需要进行故障转移前才进行选举
2. 增加了 quorum 参数,Candidate 需要的票数不仅要超过一半,还要达到 quorum 参数配置的值
3. Leader 不会将自己成为 Leader 的消息发给其他 Sentinel,其他 Sentinel 等待Leader 从 slave 选出 master后,检测到新的 master 正常工作后,就会去掉旧的 master 客观下线的标识,从而不需要进入故障转移流程

⚠️ 

1. 在只有少数 Sentinel 进程正常运作的情况下, Sentinel 是不能执行自动故障迁移的。

2. 正常情况下要配置奇数哨兵,避免切换时候票数相同,出现竞争

   **两个节点出现竞争的投票过程**

   | Sentinel 1           | Sentinel 2           |
   | -------------------- | -------------------- |
   | 投给自己             |                      |
   |                      | 投给自己             |
   | 让 S2 给自己         |                      |
   |                      | 让 S1 投给自己       |
   | 收到 S2 的请求,拒绝 | 收到 S1 的请求,拒绝 |
  1. 故障转移(切换 Redis master 数据节点)

    1. sentinel master 选择合适的 redis slave 成为 master

      slave 选择标准:

      1. 健康的节点:

        1. 在线的
        2. 最近成功通信过的(5s 内回复过 PING 命令)
        3. 数据比较新的(与 master 失联时间不超过 10*down-after-milliseconds)
      2. slave-priority(slave节点优先级)最高的slave节点
      3. 复制偏移量最大的 slave 节点(复制的最完整)
      4. 选择 runId 最小的 slave 节点(启动最早的节点)
    2. 执行 SLAVEOF no one(不会删除已有数据,只是不再接受主节点新的数据变化) 命令让其成为新的 master 节点。每秒 Sentinel 向其发送一次 INFO 命令,直到成功变为 master
    3. 向剩余的 slave 节点发送 SLAVEOF 新master 命令,让他们成为新 master 节点的 slave 节点
    4. 让剩余的 slave 复制新 master 的数据,通过配置 sentinel parallel-syncs(sentinel.conf) 规定了每次向新的主节点发起复制操作的从节点个数,parallel-syncs 取值越大,slave 完成复制的时间越快,但是对主节点的网络负载、硬盘负载造成的压力也越大,slave 加载 master 发来的 rdb 的过程中不可用
    5. 更新原来master 节点配置为 slave 节点,并保持对其进行关注,一旦这个节点重新恢复正常后,会命令它去复制新的master节点信息
    6. 全部故障转移工作完成后,Leader Sentinel 就会推送 +switch-master 消息,同时重置 master,重置操作会释放掉原来 master 全部的 slave 对象和监听该 master 的其他 Sentinel 对象,然后创建出新的 slave 对象

      故障迁移过程中 slave 能否返回数据给客户端取决于 slave-serve-stale-data(redis.conf)

    7. 持续关注旧的 master,并在他重新上线后将它设置为新 master 的 slave

在 sentinel 中执行 sentinel failover master 可以强制该 sentinel 节点执行故障转移,不与其他节点进行选举

Sentinel 缺陷

  1. Sentinel 模式下,写操作仍然只能在 Sentinel 提供的 master 数据节点上执行,无法负载均衡
  2. 持久化时 master 节点刷盘阻塞,服务请求成功率下降
  3. slave 节点存储能力受到单机的限制
  4. 分区问题:原 master redis 3 断开与 redis 1 和 redis 2 的连接,此时 redis 1 和 redis 2 执行故障转移,达到大多数,选择 redis 1 为 master。这样,redis 1 和 redis 3 都能接受写请求,但数据无法同步,数据不一致

为什么不用集群模式(Cluster)

  1. 需要客户端实现 Smart Client,完成重定向等工作
  2. 批量操作限制,不支持跨 slot 查询,所以批量操作支持不友好
  3. Key 事务操作支持有限,只支持多 key 在同一节点上的事务操作,当多个 Key 分布于不同的节点上时无法使用事务功能
  4. Key 作为数据分区的最小粒度,不能将一个很大的键值对象如 hash、list 等映射到不同的节点
  5. 不支持多数据库空间,单机下的 redis 可以支持到 16 个数据库,集群模式下只能使用 1 个数据库空间,即 db 0

参考

  1. Redis Sentinel Documentation
  2. 深入学习Redis(4):哨兵
  3. Redis 设计与实现
  4. Redis 深度历险:核心原理与应用实践
查看原文

赞 0 收藏 0 评论 0

KasheemLew 发布了文章 · 2020-07-21

MySQL Online DDL 原理和踩坑

MySQL 的 DDL(Data Definition Language) 包括增减字段、增减索引等操作。在 MySQL 5.6 之前,MySQL 的 DDL 操作会按照原来的表复制一份,并做相应的修改,例如,对表 A 进行 DDL 的具体过程如下:

  1. 按照表 A 的定义新建一个表 B
  2. 对表 A 加写锁
  3. 在表 B 上执行 DDL 指定的操作
  4. 将 A 中的数据拷贝到 B
  5. 释放 A 的写锁
  6. 删除表 A
  7. 将表 B 重命名为 A

在 2-4 的过程中,如果表 A 数据量比较大,拷贝到表 B 的过程会消耗大量时间,并占用额外的存储空间。此外,由于 DDL 操作占用了表 A 的写锁,所以表 A 上的 DDL 和 DML 都将阻塞无法提供服务。

因此,MySQL 5.6 增加了 Online DDL,允许在不中断数据库服务的情况下进行 DDL 操作。

用法

ALTER TABLE tbl\_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

ALTER 语句中可以指定参数 ALGORITHM 和 LOCK 分别指定 DDL 执行的方式和 DDL 期间 DML 的兵法控制

  1. ALGORITHM=INPLACE 表示执行DDL的过程中不发生表拷贝,过程中允许并发执行DML(INPLACE不需要像COPY一样占用大量的磁盘I/O和CPU,减少了数据库负载。同时减少了buffer pool的使用,避免 buffer pool 中原有的查询缓存被大量删除而导致的性能问题)。

    如果设置 ALGORITHM=COPY,DDL 就会按 MySQL 5.6 之前的方式,采用表拷贝的方式进行,过程中会阻塞所有的DML。另外也可以设置 ALGORITHEM=DAFAULT,让 MySQL 以尽量保证 DML 并发操作的原则选择执行方式。

  2. LOCK=NONE 表示对 DML 操作不加锁,DDL 过程中允许所有的 DML 操作。此外还有 EXCLUSIVE(持有排它锁,阻塞所有的请求,适用于需要尽快完成DDL或者服务库空闲的场景)、SHARED(允许SELECT,但是阻塞INSERT UPDATE DELETE,适用于数据仓库等可以允许数据写入延迟的场景)和 DEFAULT(根据DDL的类型,在保证最大并发的原则下来选择LOCK的取值)

不过并不是所有的 DDL 操作都能用 INPLACE 的方式执行,具体的支持情况可以在 MySQL Reference Manual — Online DDL Operations 中查看。

例如 Table 14.10 中显示修改列的数据类型不支持 INPLACE

OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies Metadata
Changing the column data typeNoYesNoNo

这时尝试将原类型为 FLOAT 的 column_name 改为 INT

ALTER TABLE tbl\_name MODIFY COLUMN column\_name INT, ALGORITHM=INPLACE, LOCK=NONE;

会报错

ERROR: 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

执行过程

  1. 初始化:根据存储引擎、用户指定的操作、用户指定的 ALGORITHM 和 LOCK 计算 DDL 过程中允许的并发量,这个过程中会获取一个 shared metadata lock,用来保护表的结构定义
  2. 执行 DDL:根据第一步的情况决定是否将 shared metadata lock 升级为 exclusive metadata lock(仅在语句准备阶段),然后生成语句并执行。执行期间的 shared metadata lock 保证了不会同时执行其他的 DDL,但 DML 能可以正常执行
  3. 提交:将 shared metadata lock 升级为 exclusive metadata lock,然后删除旧的表定义,提交新的表定义

Online DDL 过程中占用 exclusive MDL 的步骤执行很快,所以几乎不会阻塞 DML 语句。

不过,在 DDL 执行前或执行时,其他事务可以获取 MDL。由于需要用到 exclusive MDL,所以必须要等到其他占有 metadata lock 的事务提交或回滚后才能执行上面两个涉及到 MDL 的地方。

踩坑

前面提到 Online DDL 执行过程中需要获取 MDL,MDL (metadata lock) 是 MySQL 5.5 引入的表级锁,在访问一个表的时候会被自动加上,以保证读写的正确性。当对一个表做 DML 操作的时候,加 MDL 读锁;当做 DDL 操作时候,加 MDL 写锁。

为了在大表执行 DDL 的过程中同时保证 DML 能并发执行,前面使用了 ALGORITHM=INPLACE 的 Online DDL,但这里仍然存在死锁的风险,问题就出在 Online DDL 过程中需要 exclusive MDL 的地方。

例如,Session 1 在事务中执行 SELECT 操作,此时会获取 shared MDL。由于是在事务中执行,所以这个 shared MDL 只有在事务结束后才会被释放。

# Session 1
> START TRANSACTION;
> SELECT \* FROM tbl\_name;
# 正常执行

这时 Session 2 想要执行 DML 操作也只需要获取 shared MDL,仍然可以正常执行。

# Session 2
> SELECT \* FROM tbl\_name;
# 正常执行

但如果 Session 3 想执行 DDL 操作就会阻塞,因为此时 Session 1 已经占用了 shared MDL,而 DDL 的执行需要先获取 exclusive MDL,因此无法正常执行。

# Session 3
> ALTER TABLE tbl\_name ADD COLUMN n INT;
# 阻塞

通过 `show processlist` 可以看到 ALTER 操作正在等待 MDL。

+----+-----------------+------------------+------+---------+------+---------------------------------+-----------------+
| Id | User            | Host             | db   | Command | Time | State                           | Info            |
│----+-----------------+------------------+------+---------+------+---------------------------------+-----------------+
| 11 | root            | 172.17.0.1:53048 | demo | Query   |    3 | Waiting for table metadata lock | alter table ... |
+----+-----------------+------------------+------+---------+------+---------------------------------+-----------------+

由于 exclusive MDL 的获取优先于 shared MDL,后续尝试获取 shared MDL 的操作也将会全部阻塞

# Session 4
> SELECT \* FROM tbl\_name;
# 阻塞

到这一步,后续无论是 DML 和 DDL 都将阻塞,直到 Session 1 提交或者回滚,Session 1 占用的 shared MDL 被释放,后面的操作才能继续执行。

上面这个问题主要有两个原因:

  1. Session 1 中的事务没有及时提交,因此阻塞了 Session 3 的 DDL
  2. Session 3 Online DDL 阻塞了后续的 DML 和 DDL

对于问题 1,不少 ORM(例如 pymysql)都默认将用户语句封装成事务执行,如果客户端程序中断退出,还没来得及提交或者回滚事务,就会出现 Session 1 中的情况。这时可以在 infomation_schema.innodb_trx 中找出未完成的事务对应的线程,并强制退出

> SELECT * FROM information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 421564480355704
                 trx_state: RUNNING
               trx_started: 2020-07-21 01:49:41
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 0
       trx_mysql_thread_id: 9
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 0
     trx_lock_memory_bytes: 1136
           trx_rows_locked: 0
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL
1 row in set (0.0025 sec)

可以看到 Session 1 正在执行的事务对应的 trx_mysql_thread_id 为 9,然后执行 KILL 9 即可中断 Session 1 中的事务。

对于问题 2,在查询很多的情况下,会导致阻塞的 session 迅速增多,对于这种情况,可以先中断 DDL 操作,防止对服务造成过大的影响。也可以尝试在从库上修改表结构后进行主从切换或者使用 pt-osc 等第三方工具。

查看原文

赞 0 收藏 0 评论 2

KasheemLew 赞了文章 · 2018-04-08

理解 Python 的 LEGB

理解 Python 的 LEGB

名字空间


Python 的名字空间是 Python 一个非常核心的内容。
其他语言中如 C 中,变量名是内存地址的别名,而在 Python 中,名字是一个字符串对象,它与他指向的对象构成一个{name:object}关联。
Python 由很多名字空间,而 LEGB 则是名字空间的一种查找规则。

作用域


Python 中name-object的关联存储在不同的作用域中,各个不同的作用域是相互独立的。而我们就在不同的作用域中搜索name-object

举个栗子,来说明作用域是相互独立的。


In [11]: i = "G" In [12]: def test(): i = "L" print i, "in locals" ....: In [13]: test() L in locals In [14]: print i, "in globals" G in globals

在上面的栗子中,我们定义了两次 i,在 test 函数中是 i-L,在外面是 i-G。为什么在 test 函数中,我们 i 指向的是对象 L,而在外面,i 指向的则是 G?这就是 LEGB 的作用。

简述


简而言之,LEGB 代表名字查找顺序: locals -> enclosing function -> globals -> __builtins__

  • locals 是函数内的名字空间,包括局部变量和形参
  • enclosing 外部嵌套函数的名字空间(闭包中常见)
  • globals 全局变量,函数定义所在模块的名字空间
  • builtins 内置模块的名字空间

所以,在 Python 中检索一个变量的时候,优先回到 locals 里面来检索,检索不到的情况下会检索 enclosing ,enclosing 没有则到 globals 全局变量里面检索,最后是到 builtins 里面来检索。

当然,因为 builtins 的特殊性,我们可以直接在 builtins 里面添加变量,这样就可以在任意模块中访问变量,不过这种方法太过于变态,不推荐这么做。

locals,globals


函数的形参跟内部变量都存储在 locals 中。

In [1]: def f(x):
   ...:     a = x
   ...:     print a
   ...:     print locals()
   ...:


In [2]: f("hello")
hello
{'a': 'hello', 'x': 'hello'}

不过在函数内部调用global 声明的时候,可以将变量存储在 globals 中

In [6]: def f(x):
   ...:     global a
   ...:     a = x
   ...:     print a
   ...:     print locals()
   ...:

In [7]: f("hello")
hello
{'x': 'hello'}

In [8]: print a
hello

In [9]: print x
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-9-2d264e11d975> in <module>()
----> 1 print x

NameError: name 'x' is not defined

如上面栗子中那样,在函数中声明 a 为全局变量,则函数 f 的 locals只有参数 x,而没有变量,而在外部可以使用变量 a,而使用 x 的时候则是NameError

Enclosed


Enclosing 是外部嵌套函数的名字空间。我们经常在闭包中用到。在 Python3中提供了一个 nonlocal关键字来修改外部嵌套函数的名字空间,但是要使用 Python3才有,我等使用 Python2的只能眼馋一下。

In [11]: def outer():
   ....:     a_var = 'enclosed value'
   ....:     print a_var
   ....:     def inner():
   ....:         a_var = 'local value'
   ....:         print(a_var)
   ....:     inner()
   ....:     print a_var
   ....:

In [12]: outer()
enclosed value
local value
enclosed value

下面的栗子简单示范一下 nonlocal 的用法,实在 Python3下面才可以正常运行的:

In [1]: a_var = 'global value'

In [2]: def outer():
   ...:     a_var = "local value"
   ...:     print("outer befor", a_var)
   ...:     def inner():
   ...:         nonlocal a_var
   ...:         a_var = "inner value"
   ...:         print("in inner():", a_var)
   ...:     inner()
   ...:     print("outer inner:", a_var)
   ...:

In [3]: outer()
outer befor local value
in inner(): inner value
outer inner: inner value

In [4]: print(a_var)
global value

builtins


builtins 则是内置模块,轻易不要修改

In [19]: b
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-19-3b5d5c371295> in <module>()
----> 1 b

NameError: name 'b' is not defined

In [20]: __builtins__.b = "builtins"

In [21]: b
Out[21]: 'builtins'

上面栗子中在第一次调用b的时候报错NameError,之后我们修改 builtins 的名字空间,将名字b与值"builtins"进行关联,就可以正常调用了。这种非常规用法不建议使用。

查看原文

赞 5 收藏 10 评论 1

KasheemLew 赞了文章 · 2018-03-31

Linux IO模式及 select、poll、epoll详解

注:本文是对众多博客的学习和总结,可能存在理解错误。请带着怀疑的眼光,同时如果有错误希望能指出。

同步IO和异步IO,阻塞IO和非阻塞IO分别是什么,到底有什么区别?不同的人在不同的上下文下给出的答案是不同的。所以先限定一下本文的上下文。

本文讨论的背景是Linux环境下的network IO。

一 概念说明

在进行解释之前,首先要说明几个概念:
- 用户空间和内核空间
- 进程切换
- 进程的阻塞
- 文件描述符
- 缓存 I/O

用户空间与内核空间

现在操作系统都是采用虚拟存储器,那么对32位操作系统而言,它的寻址空间(虚拟存储空间)为4G(2的32次方)。操作系统的核心是内核,独立于普通的应用程序,可以访问受保护的内存空间,也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核(kernel),保证内核的安全,操心系统将虚拟空间划分为两部分,一部分为内核空间,一部分为用户空间。针对linux操作系统而言,将最高的1G字节(从虚拟地址0xC0000000到0xFFFFFFFF),供内核使用,称为内核空间,而将较低的3G字节(从虚拟地址0x00000000到0xBFFFFFFF),供各个进程使用,称为用户空间。

进程切换

为了控制进程的执行,内核必须有能力挂起正在CPU上运行的进程,并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说,任何进程都是在操作系统内核的支持下运行的,是与内核紧密相关的。

从一个进程的运行转到另一个进程上运行,这个过程中经过下面这些变化:
1. 保存处理机上下文,包括程序计数器和其他寄存器。
2. 更新PCB信息。
3. 把进程的PCB移入相应的队列,如就绪、在某事件阻塞等队列。
4. 选择另一个进程执行,并更新其PCB。
5. 更新内存管理的数据结构。
6. 恢复处理机上下文。

注:总而言之就是很耗资源,具体的可以参考这篇文章:进程切换

进程的阻塞

正在执行的进程,由于期待的某些事件未发生,如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等,则由系统自动执行阻塞原语(Block),使自己由运行状态变为阻塞状态。可见,进程的阻塞是进程自身的一种主动行为,也因此只有处于运行态的进程(获得CPU),才可能将其转为阻塞状态。当进程进入阻塞状态,是不占用CPU资源的

文件描述符fd

文件描述符(File descriptor)是计算机科学中的一个术语,是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数。实际上,它是一个索引值,指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时,内核向进程返回一个文件描述符。在程序设计中,一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

缓存 I/O

缓存 I/O 又被称作标准 I/O,大多数文件系统的默认 I/O 操作都是缓存 I/O。在 Linux 的缓存 I/O 机制中,操作系统会将 I/O 的数据缓存在文件系统的页缓存( page cache )中,也就是说,数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。

缓存 I/O 的缺点:
数据在传输过程中需要在应用程序地址空间和内核进行多次数据拷贝操作,这些数据拷贝操作所带来的 CPU 以及内存开销是非常大的。

二 IO模式

刚才说了,对于一次IO访问(以read举例),数据会先被拷贝到操作系统内核的缓冲区中,然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。所以说,当一个read操作发生时,它会经历两个阶段:
1. 等待数据准备 (Waiting for the data to be ready)
2. 将数据从内核拷贝到进程中 (Copying the data from the kernel to the process)

正式因为这两个阶段,linux系统产生了下面五种网络模式的方案。
- 阻塞 I/O(blocking IO)
- 非阻塞 I/O(nonblocking IO)
- I/O 多路复用( IO multiplexing)
- 信号驱动 I/O( signal driven IO)
- 异步 I/O(asynchronous IO)

注:由于signal driven IO在实际中并不常用,所以我这只提及剩下的四种IO Model。

阻塞 I/O(blocking IO)

在linux中,默认情况下所有的socket都是blocking,一个典型的读操作流程大概是这样:
clipboard.png

当用户进程调用了recvfrom这个系统调用,kernel就开始了IO的第一个阶段:准备数据(对于网络IO来说,很多时候数据在一开始还没有到达。比如,还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来)。这个过程需要等待,也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。而在用户进程这边,整个进程会被阻塞(当然,是进程自己选择的阻塞)。当kernel一直等到数据准备好了,它就会将数据从kernel中拷贝到用户内存,然后kernel返回结果,用户进程才解除block的状态,重新运行起来。

所以,blocking IO的特点就是在IO执行的两个阶段都被block了。

非阻塞 I/O(nonblocking IO)

linux下,可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时,流程是这个样子:
clipboard.png

当用户进程发出read操作时,如果kernel中的数据还没有准备好,那么它并不会block用户进程,而是立刻返回一个error。从用户进程角度讲 ,它发起一个read操作后,并不需要等待,而是马上就得到了一个结果。用户进程判断结果是一个error时,它就知道数据还没有准备好,于是它可以再次发送read操作。一旦kernel中的数据准备好了,并且又再次收到了用户进程的system call,那么它马上就将数据拷贝到了用户内存,然后返回。

所以,nonblocking IO的特点是用户进程需要不断的主动询问kernel数据好了没有。

I/O 多路复用( IO multiplexing)

IO multiplexing就是我们说的select,poll,epoll,有些地方也称这种IO方式为event driven IO。select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select,poll,epoll这个function会不断的轮询所负责的所有socket,当某个socket有数据到达了,就通知用户进程。

clipboard.png

当用户进程调用了select,那么整个进程会被block,而同时,kernel会“监视”所有select负责的socket,当任何一个socket中的数据准备好了,select就会返回。这个时候用户进程再调用read操作,将数据从kernel拷贝到用户进程。

所以,I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符,而这些文件描述符(套接字描述符)其中的任意一个进入读就绪状态,select()函数就可以返回。

这个图和blocking IO的图其实并没有太大的不同,事实上,还更差一些。因为这里需要使用两个system call (select 和 recvfrom),而blocking IO只调用了一个system call (recvfrom)。但是,用select的优势在于它可以同时处理多个connection。

所以,如果处理的连接数不是很高的话,使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server性能更好,可能延迟还更大。select/epoll的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接。)

在IO multiplexing Model中,实际中,对于每一个socket,一般都设置成为non-blocking,但是,如上图所示,整个用户的process其实是一直被block的。只不过process是被select这个函数block,而不是被socket IO给block。

异步 I/O(asynchronous IO)

inux下的asynchronous IO其实用得很少。先看一下它的流程:
clipboard.png

用户进程发起read操作之后,立刻就可以开始去做其它的事。而另一方面,从kernel的角度,当它受到一个asynchronous read之后,首先它会立刻返回,所以不会对用户进程产生任何block。然后,kernel会等待数据准备完成,然后将数据拷贝到用户内存,当这一切都完成之后,kernel会给用户进程发送一个signal,告诉它read操作完成了。

总结

blocking和non-blocking的区别

调用blocking IO会一直block住对应的进程直到操作完成,而non-blocking IO在kernel还准备数据的情况下会立刻返回。

synchronous IO和asynchronous IO的区别

在说明synchronous IO和asynchronous IO的区别之前,需要先给出两者的定义。POSIX的定义是这样子的:
- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
- An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于synchronous IO做”IO operation”的时候会将process阻塞。按照这个定义,之前所述的blocking IO,non-blocking IO,IO multiplexing都属于synchronous IO。

有人会说,non-blocking IO并没有被block啊。这里有个非常“狡猾”的地方,定义中所指的”IO operation”是指真实的IO操作,就是例子中的recvfrom这个system call。non-blocking IO在执行recvfrom这个system call的时候,如果kernel的数据没有准备好,这时候不会block进程。但是,当kernel中数据准备好的时候,recvfrom会将数据从kernel拷贝到用户内存中,这个时候进程是被block了,在这段时间内,进程是被block的。

而asynchronous IO则不一样,当进程发起IO 操作之后,就直接返回再也不理睬了,直到kernel发送一个信号,告诉进程说IO完成。在这整个过程中,进程完全没有被block。

各个IO Model的比较如图所示:
clipboard.png

通过上面的图片,可以发现non-blocking IO和asynchronous IO的区别还是很明显的。在non-blocking IO中,虽然进程大部分时间都不会被block,但是它仍然要求进程去主动的check,并且当数据准备完成以后,也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而asynchronous IO则完全不同。它就像是用户进程将整个IO操作交给了他人(kernel)完成,然后他人做完后发信号通知。在此期间,用户进程不需要去检查IO操作的状态,也不需要主动的去拷贝数据。

三 I/O 多路复用之select、poll、epoll详解

select,poll,epoll都是IO多路复用的机制。I/O多路复用就是通过一种机制,一个进程可以监视多个描述符,一旦某个描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作。但select,poll,epoll本质上都是同步I/O,因为他们都需要在读写事件就绪后自己负责进行读写,也就是说这个读写过程是阻塞的,而异步I/O则无需自己负责进行读写,异步I/O的实现会负责把数据从内核拷贝到用户空间。(这里啰嗦下)

select

int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 函数监视的文件描述符分3类,分别是writefds、readfds、和exceptfds。调用后select函数会阻塞,直到有描述副就绪(有数据 可读、可写、或者有except),或者超时(timeout指定等待时间,如果立即返回设为null即可),函数返回。当select函数返回后,可以 通过遍历fdset,来找到就绪的描述符。

select目前几乎在所有的平台上支持,其良好跨平台支持也是它的一个优点。select的一 个缺点在于单个进程能够监视的文件描述符的数量存在最大限制,在Linux上一般为1024,可以通过修改宏定义甚至重新编译内核的方式提升这一限制,但 是这样也会造成效率的降低。

poll

int poll (struct pollfd *fds, unsigned int nfds, int timeout);

不同与select使用三个位图来表示三个fdset的方式,poll使用一个 pollfd的指针实现。

struct pollfd {
    int fd; /* file descriptor */
    short events; /* requested events to watch */
    short revents; /* returned events witnessed */
};

pollfd结构包含了要监视的event和发生的event,不再使用select“参数-值”传递的方式。同时,pollfd并没有最大数量限制(但是数量过大后性能也是会下降)。 和select函数一样,poll返回后,需要轮询pollfd来获取就绪的描述符。

从上面看,select和poll都需要在返回后,通过遍历文件描述符来获取已经就绪的socket。事实上,同时连接的大量客户端在一时刻可能只有很少的处于就绪状态,因此随着监视的描述符数量的增长,其效率也会线性下降。

epoll

epoll是在2.6内核中提出的,是之前的select和poll的增强版本。相对于select和poll来说,epoll更加灵活,没有描述符限制。epoll使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。

一 epoll操作过程

epoll操作过程需要三个接口,分别如下:

int epoll_create(int size);//创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

1. int epoll_create(int size);
创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大,这个参数不同于select()中的第一个参数,给出最大监听的fd+1的值,参数size并不是限制了epoll所能监听的描述符最大个数,只是对内核初始分配内部数据结构的一个建议
当创建好epoll句柄后,它就会占用一个fd值,在linux下如果查看/proc/进程id/fd/,是能够看到这个fd的,所以在使用完epoll后,必须调用close()关闭,否则可能导致fd被耗尽。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
函数是对指定描述符fd执行op操作。
- epfd:是epoll_create()的返回值。
- op:表示op操作,用三个宏来表示:添加EPOLL_CTL_ADD,删除EPOLL_CTL_DEL,修改EPOLL_CTL_MOD。分别添加、删除和修改对fd的监听事件。
- fd:是需要监听的fd(文件描述符)
- epoll_event:是告诉内核需要监听什么事,struct epoll_event结构如下:

struct epoll_event {
  __uint32_t events;  /* Epoll events */
  epoll_data_t data;  /* User data variable */
};

//events可以是以下几个宏的集合:
EPOLLIN :表示对应的文件描述符可以读(包括对端SOCKET正常关闭);
EPOLLOUT:表示对应的文件描述符可以写;
EPOLLPRI:表示对应的文件描述符有紧急的数据可读(这里应该表示有带外数据到来);
EPOLLERR:表示对应的文件描述符发生错误;
EPOLLHUP:表示对应的文件描述符被挂断;
EPOLLET: 将EPOLL设为边缘触发(Edge Triggered)模式,这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT:只监听一次事件,当监听完这次事件之后,如果还需要继续监听这个socket的话,需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等待epfd上的io事件,最多返回maxevents个事件。
参数events用来从内核得到事件的集合,maxevents告之内核这个events有多大,这个maxevents的值不能大于创建epoll_create()时的size,参数timeout是超时时间(毫秒,0会立即返回,-1将不确定,也有说法说是永久阻塞)。该函数返回需要处理的事件数目,如返回0表示已超时。

二 工作模式

 epoll对文件描述符的操作有两种模式:LT(level trigger)ET(edge trigger)。LT模式是默认模式,LT模式与ET模式的区别如下:
  LT模式:当epoll_wait检测到描述符事件发生并将此事件通知应用程序,应用程序可以不立即处理该事件。下次调用epoll_wait时,会再次响应应用程序并通知此事件。
  ET模式:当epoll_wait检测到描述符事件发生并将此事件通知应用程序,应用程序必须立即处理该事件。如果不处理,下次调用epoll_wait时,不会再次响应应用程序并通知此事件。

1. LT模式

LT(level triggered)是缺省的工作方式,并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了,然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作,内核还是会继续通知你的。

2. ET模式

ET(edge-triggered)是高速工作方式,只支持no-block socket。在这种模式下,当描述符从未就绪变为就绪时,内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如,你在发送,接收或者接收请求,或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误)。但是请注意,如果一直不对这个fd作IO操作(从而导致它再次变成未就绪),内核不会发送更多的通知(only once)

ET模式在很大程度上减少了epoll事件被重复触发的次数,因此效率要比LT模式高。epoll工作在ET模式的时候,必须使用非阻塞套接口,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

3. 总结

假如有这样一个例子:
1. 我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2),并且它会返回RFD,说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)......

LT模式:
如果是LT模式,那么在第5步调用epoll_wait(2)之后,仍然能受到通知。

ET模式:
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志,那么在第5步调用epoll_wait(2)之后将有可能会挂起,因为剩余的数据还存在于文件的输入缓冲区内,而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第5步的时候,调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。

当使用epoll的ET模型来工作时,当产生了一个EPOLLIN事件后,
读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小,那么很有可能是缓冲区还有数据未读完,也意味着该次事件还没有处理完,所以还需要再次读取:

while(rs){
  buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
  if(buflen < 0){
    // 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读
    // 在这里就当作是该次事件已处理处.
    if(errno == EAGAIN){
        break;
    }
    else{
        return;
    }
  }
  else if(buflen == 0){
     // 这里表示对端的socket已正常关闭.
  }

 if(buflen == sizeof(buf){
      rs = 1;   // 需要再次读取
 }
 else{
      rs = 0;
 }
}

Linux中的EAGAIN含义

Linux环境下开发经常会碰到很多错误(设置errno),其中EAGAIN是其中比较常见的一个错误(比如用在非阻塞操作中)。
从字面上来看,是提示再试一次。这个错误经常出现在当应用程序进行一些非阻塞(non-blocking)操作(对文件或socket)的时候。

例如,以 O_NONBLOCK的标志打开文件/socket/FIFO,如果你连续做read操作而没有数据可读。此时程序不会阻塞起来等待数据准备就绪返回,read函数会返回一个错误EAGAIN,提示你的应用程序现在没有数据可读请稍后再试。
又例如,当一个系统调用(比如fork)因为没有足够的资源(比如虚拟内存)而执行失败,返回EAGAIN提示其再调用一次(也许下次就能成功)。

三 代码演示

下面是一段不完整的代码且格式不对,意在表述上面的过程,去掉了一些模板代码。

#define IPADDRESS   "127.0.0.1"
#define PORT        8787
#define MAXSIZE     1024
#define LISTENQ     5
#define FDSIZE      1000
#define EPOLLEVENTS 100

listenfd = socket_bind(IPADDRESS,PORT);

struct epoll_event events[EPOLLEVENTS];

//创建一个描述符
epollfd = epoll_create(FDSIZE);

//添加监听描述符事件
add_event(epollfd,listenfd,EPOLLIN);

//循环等待
for ( ; ; ){
    //该函数返回已经准备好的描述符事件数目
    ret = epoll_wait(epollfd,events,EPOLLEVENTS,-1);
    //处理接收到的连接
    handle_events(epollfd,events,ret,listenfd,buf);
}

//事件处理函数
static void handle_events(int epollfd,struct epoll_event *events,int num,int listenfd,char *buf)
{
     int i;
     int fd;
     //进行遍历;这里只要遍历已经准备好的io事件。num并不是当初epoll_create时的FDSIZE。
     for (i = 0;i < num;i++)
     {
         fd = events[i].data.fd;
        //根据描述符的类型和事件类型进行处理
         if ((fd == listenfd) &&(events[i].events & EPOLLIN))
            handle_accpet(epollfd,listenfd);
         else if (events[i].events & EPOLLIN)
            do_read(epollfd,fd,buf);
         else if (events[i].events & EPOLLOUT)
            do_write(epollfd,fd,buf);
     }
}

//添加事件
static void add_event(int epollfd,int fd,int state){
    struct epoll_event ev;
    ev.events = state;
    ev.data.fd = fd;
    epoll_ctl(epollfd,EPOLL_CTL_ADD,fd,&ev);
}

//处理接收到的连接
static void handle_accpet(int epollfd,int listenfd){
     int clifd;     
     struct sockaddr_in cliaddr;     
     socklen_t  cliaddrlen;     
     clifd = accept(listenfd,(struct sockaddr*)&cliaddr,&cliaddrlen);     
     if (clifd == -1)         
     perror("accpet error:");     
     else {         
         printf("accept a new client: %s:%d\n",inet_ntoa(cliaddr.sin_addr),cliaddr.sin_port);                       //添加一个客户描述符和事件         
         add_event(epollfd,clifd,EPOLLIN);     
     } 
}

//读处理
static void do_read(int epollfd,int fd,char *buf){
    int nread;
    nread = read(fd,buf,MAXSIZE);
    if (nread == -1)     {         
        perror("read error:");         
        close(fd); //记住close fd        
        delete_event(epollfd,fd,EPOLLIN); //删除监听 
    }
    else if (nread == 0)     {         
        fprintf(stderr,"client close.\n");
        close(fd); //记住close fd       
        delete_event(epollfd,fd,EPOLLIN); //删除监听 
    }     
    else {         
        printf("read message is : %s",buf);        
        //修改描述符对应的事件,由读改为写         
        modify_event(epollfd,fd,EPOLLOUT);     
    } 
}

//写处理
static void do_write(int epollfd,int fd,char *buf) {     
    int nwrite;     
    nwrite = write(fd,buf,strlen(buf));     
    if (nwrite == -1){         
        perror("write error:");        
        close(fd);   //记住close fd       
        delete_event(epollfd,fd,EPOLLOUT);  //删除监听    
    }else{
        modify_event(epollfd,fd,EPOLLIN); 
    }    
    memset(buf,0,MAXSIZE); 
}

//删除事件
static void delete_event(int epollfd,int fd,int state) {
    struct epoll_event ev;
    ev.events = state;
    ev.data.fd = fd;
    epoll_ctl(epollfd,EPOLL_CTL_DEL,fd,&ev);
}

//修改事件
static void modify_event(int epollfd,int fd,int state){     
    struct epoll_event ev;
    ev.events = state;
    ev.data.fd = fd;
    epoll_ctl(epollfd,EPOLL_CTL_MOD,fd,&ev);
}

//注:另外一端我就省了

四 epoll总结

在 select/poll中,进程只有在调用一定的方法后,内核才对所有监视的文件描述符进行扫描,而epoll事先通过epoll_ctl()来注册一 个文件描述符,一旦基于某个文件描述符就绪时,内核会采用类似callback的回调机制,迅速激活这个文件描述符,当进程调用epoll_wait() 时便得到通知。(此处去掉了遍历文件描述符,而是通过监听回调的的机制。这正是epoll的魅力所在。)

epoll的优点主要是一下几个方面:
1. 监视的描述符数量不受限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。select的最大缺点就是进程打开的fd是有数量限制的。这对 于连接数量比较大的服务器来说根本不能满足。虽然也可以选择多进程的解决方案( Apache就是这样实现的),不过虽然linux上面创建进程的代价比较小,但仍旧是不可忽视的,加上进程间数据同步远比不上线程间同步的高效,所以也不是一种完美的方案。

  1. IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式,而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。

如果没有大量的idle -connection或者dead-connection,epoll的效率并不会比select/poll高很多,但是当遇到大量的idle- connection,就会发现epoll的效率大大高于select/poll。

参考

用户空间与内核空间,进程上下文与中断上下文[总结]
进程切换
维基百科-文件描述符
Linux 中直接 I/O 机制的介绍
IO - 同步,异步,阻塞,非阻塞 (亡羊补牢篇)
Linux中select poll和epoll的区别
IO多路复用之select总结
IO多路复用之poll总结
IO多路复用之epoll总结

查看原文

赞 597 收藏 1054 评论 64

KasheemLew 赞了文章 · 2018-03-15

防雪崩利器:熔断器 Hystrix 的原理与使用

前言

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择.

服务雪崩效应的定义

服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用 逐渐放大 的过程.如果所示:

图片描述

上图中, A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了.

服务雪崩效应形成的原因

我把服务雪崩的参与者简化为 服务提供者服务调用者, 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因:

  1. 服务提供者不可用

  2. 重试加大流量

  3. 服务调用者不可用

图片描述

服务雪崩的每个阶段都可能由不同的原因造成, 比如造成 服务不可用 的原因有:

  • 硬件故障

  • 程序Bug

  • 缓存击穿

  • 用户大量请求

硬件故障可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问.
缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用.
在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用.

而形成 重试加大流量 的原因有:

  • 用户重试

  • 代码逻辑重试

在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单.
服务调用端的会存在大量服务异常后的重试逻辑.
这些重试都会进一步加大请求流量.

最后, 服务调用者不可用 产生的主要原因是:

  • 同步等待造成的资源耗尽

当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.

服务雪崩的应对策略

针对造成服务雪崩的不同原因, 可以使用不同的应对策略:

  1. 流量控制

  2. 改进缓存模式

  3. 服务自动扩容

  4. 服务调用者降级服务

流量控制 的具体措施包括:

  • 网关限流

  • 用户交互限流

  • 关闭重试

因为Nginx的高性能, 目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制, 由此而来的OpenResty也越来越热门.

用户交互限流的具体措施有: 1. 采用加载动画,提高用户的忍耐等待时间. 2. 提交按钮添加强制等待时间机制.

改进缓存模式 的措施包括:

  • 缓存预加载

  • 同步改为异步刷新

服务自动扩容 的措施主要有:

  • AWS的auto scaling

服务调用者降级服务 的措施包括:

  • 资源隔离

  • 对依赖服务进行分类

  • 不可用服务的调用快速失败

资源隔离主要是对调用服务的线程池进行隔离.

我们根据具体业务,将依赖服务分为: 强依赖和若依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止.

不可用服务的调用快速失败一般通过 超时机制, 熔断器 和熔断后的 降级方法 来实现.

使用Hystrix预防服务雪崩

Hystrix [hɪst'rɪks]的中文含义是豪猪, 因其背上长满了刺,而拥有自我保护能力. Netflix的 Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力.

Hystrix的设计原则包括:

  • 资源隔离

  • 熔断器

  • 命令模式

资源隔离

货船为了进行防止漏水和火灾的扩散,会将货仓分隔为多个, 如下图所示:

图片描述

这种资源隔离减少风险的方式被称为:Bulkheads(舱壁隔离模式).
Hystrix将同样的模式运用到了服务调用者上.

在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如:
商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务. 如图所示:

图片描述

调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩. 如图所示:

图片描述

Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩.
如下图所示, 当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.

图片描述

熔断器模式

熔断器模式定义了熔断器开关相互转换的逻辑:

图片描述

服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.

  1. 当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于设定阈值, 开关则切换为打开状态.

  2. 当熔断器开关打开时, 请求被禁止通过.

  3. 当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.

熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.

命令模式

Hystrix使用命令模式(继承HystrixCommand类)来包裹具体的服务调用逻辑(run方法), 并在命令模式中添加了服务调用失败后的降级逻辑(getFallback).
同时我们在Command的构造方法中可以定义当前服务线程池和熔断器的相关参数. 如下代码所示:

public class Service1HystrixCommand extends HystrixCommand<Response> {
  private Service1 service;
  private Request request;

  public Service1HystrixCommand(Service1 service, Request request){
    supper(
      Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup"))
          .andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query"))
          .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool"))
          .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
            .withCoreSize(20))//服务线程池数量
          .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
            .withCircuitBreakerErrorThresholdPercentage(60)//熔断器关闭到打开阈值
            .withCircuitBreakerSleepWindowInMilliseconds(3000)//熔断器打开到关闭的时间窗长度
      ))
      this.service = service;
      this.request = request;
    );
  }

  @Override
  protected Response run(){
    return service1.call(request);
  }

  @Override
  protected Response getFallback(){
    return Response.dummy();
  }
}

在使用了Command模式构建了服务对象之后, 服务便拥有了熔断器和线程池的功能.
图片描述

Hystrix的内部处理逻辑

下图为Hystrix服务调用的内部逻辑:
图片描述

  1. 构建Hystrix的Command对象, 调用执行方法.

  2. Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法.

  3. 若熔断器开关关闭, 则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法.

  4. 若线程池接受请求, 则Hystrix开始执行服务调用具体逻辑run方法.

  5. 若服务执行失败, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.

  6. 若服务执行超时, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.

  7. 若服务执行成功, 返回正常结果.

  8. 若服务降级方法getFallback执行成功, 则返回降级结果.

  9. 若服务降级方法getFallback执行失败, 则抛出异常.

Hystrix Metrics的实现

Hystrix的Metrics中保存了当前服务的健康状况, 包括服务调用总次数和服务调用失败次数等. 根据Metrics的计数, 熔断器从而能计算出当前服务的调用失败率, 用来和设定的阈值比较从而决定熔断器的状态切换逻辑. 因此Metrics的实现非常重要.

1.4之前的滑动窗口实现

Hystrix在这些版本中的使用自己定义的滑动窗口数据结构来记录当前时间窗的各种事件(成功,失败,超时,线程池拒绝等)的计数.
事件产生时, 数据结构根据当前时间确定使用旧桶还是创建新桶来计数, 并在桶中对计数器经行修改.
这些修改是多线程并发执行的, 代码中有不少加锁操作,逻辑较为复杂.

图片描述

1.5之后的滑动窗口实现

Hystrix在这些版本中开始使用RxJava的Observable.window()实现滑动窗口.
RxJava的window使用后台线程创建新桶, 避免了并发创建桶的问题.
同时RxJava的单线程无锁特性也保证了计数变更时的线程安全. 从而使代码更加简洁.
以下为我使用RxJava的window方法实现的一个简易滑动窗口Metrics, 短短几行代码便能完成统计功能,足以证明RxJava的强大:

@Test
public void timeWindowTest() throws Exception{
  Observable<Integer> source = Observable.interval(50, TimeUnit.MILLISECONDS).map(i -> RandomUtils.nextInt(2));
  source.window(1, TimeUnit.SECONDS).subscribe(window -> {
    int[] metrics = new int[2];
    window.subscribe(i -> metrics[i]++,
      InternalObservableUtils.ERROR_NOT_IMPLEMENTED,
      () -> System.out.println("窗口Metrics:" + JSON.toJSONString(metrics)));
  });
  TimeUnit.SECONDS.sleep(3);
}

总结

通过使用Hystrix,我们能方便的防止雪崩效应, 同时使系统具有自动降级和自动恢复服务的效果.

查看原文

赞 100 收藏 171 评论 16

KasheemLew 收藏了文章 · 2018-02-12

如何面试前端工程师:GitHub 很重要

12月30日 2013年,作者 Alex MacCaw, 翻译:myownghost

编者注:下面这篇文章从面试官的角度介绍到面试时可能会问到的一些问题。

我在Twitter和Stripe的一部分工作内容是面试前端工程师。其实关于面试你可能很有自己的一套,这里我想跟你们分享一下我常用的方法。

不过我想先给你们一个忠告,招聘是一件非常艰巨的任务,在45分钟内指出一名侯选人是否合适是你需要完成的任务。不过面试的最大问题是每个人都会想着去雇佣他们自己,任何通过我面试的人想法大都跟我差不多(注:因为你总会问你自己关心和知道的问题),这其实不是一件好事。因此我之前的决定都有很大碰运气的成分。不过,这也是一个良好的开端。

最理想的情况下是侯选人有一个全面的Github“简历”,这样我们可以同时通过他们的开源项目了解他们。我经常会浏览他们的代码然后针对一些特定的代码设计问一些问题。如果侯选人有非常好的开源项目记录,接下来的面试会直接去检验他们的团队协作精神。否则,我不得不去问他们一些代码方面的问题了。

我的面试非常有实践性,全部是写代码。没有抽象和理论上的东西(注:作者是个行业派),其他的面试官很可能会问这些问题,但是我认为他们前端编程的能力是值得商榷的。我问的问题大多看上去非常简单,但是每组问题都能让我考查侯选人某一方面JavaScript的知识。

第一部分:Object Prototypes (对象原型)

刚开始很简单。我会让侯选人去定义一个方法,传入一个string类型的参数,然后将string的每个字符间加个空格返回,例如:

spacify('hello world') // => 'h e l l o  w o r l d'    

尽管这个问题似乎非常简单,其实这是一个很好的开始,尤其是对于那些未经过电话面试的侯选人——他们很多人声称精通JavaScript,但通常连一个简单的方法都不会写。

下面是正确答案,有时侯选人可能会用一个循环,这也是一种可接受的答案。

function spacify(str) {
  return str.split('').join(' ');
}

接下来,我会问侯选人,如何把这个方法放入String对象上面,例如:

'hello world'.spacify();

问这个问题可以让我考察侯选人是否对function prototypes(方法原型)有一个基本的理解。这个问题会经常引起一些有意思的讨论:直接在对象的原型(prototypes)上添加方法是否安全,尤其是在Object对象上。最后的答案可能会像这样:

String.prototype.spacify = function(){
  return this.split('').join(' ');
};

到这儿,我通常会让侯选人解释一下函数声明和函数表达式的区别。

第二部分:参数 arguments

下一步我会问一些简单的问题去考察侯选人是否理解参数(arguments)对象。我会让他们定义一个未定义的log方法作为开始。

log('hello world')

我会让侯选人去定义log,然后它可以代理console.log的方法。正确的答案是下面几行代码,其实更好的侯选人会直接使用apply.

function log(msg) {
  console.log(msg);
}

他们一旦写好了,我就会说我要改变我调用log的方式,传入多个参数。我会强调我传入参数的个数是不定的,可不止两个。这里我举了一个传两个参数的例子。

log('hello', 'world');

希望你的侯选人可以直接使用apply。有时人他们可能会把apply和call搞混了,不过你可以提醒他们让他们微调一下。传入console的上下文也非常重要。

function log(){
  console.log.apply(console, arguments);
};

接下来我会让侯选人给每一个log消息添加一个"(app)"的前辍,比如:

'(app) hello world'

现在可能有点麻烦了。好的侯选人知道arugments是一个伪数组,然后会将他转化成为标准数组。通常方法是使用Array.prototype.slice,像这样:

function log(){
  var args = Array.prototype.slice.call(arguments);
  args.unshift('(app)');

  console.log.apply(console, args);
};

第三部分:上下文

下一组问题是考察侯选人对上下文和this的理解。我先定义了下面一个例子。注意count属性不是只读取当前下下文的。

var User = {
  count: 1,

  getCount: function() {
    return this.count;
  }
};

我又写了下面几行,然后问侯选人log输出的会是什么。

console.log(User.getCount());

var func = User.getCount;
console.log(func());

这种情况下,正确的答案是1和undefined。你会很吃惊,因为有很多人被这种最基础的上下文问题绊倒。func是在winodw的上下文中被执行的,所以会访问不到count属性。我向侯选人解释了这点,然后问他们怎么样保证User总是能访问到func的上下文,即返回正即的值:1

正确的答案是使用Function.prototype.bind,例如:

var func = User.getCount.bind(User);
console.log(func());

接下来我通常会说这个方法对老版本的浏览器不起作用,然后让侯选人去解决这个问题。很多弱一些的侯选人在这个问题上犯难了,但是对于你来说雇佣一个理解apply和call的侯选人非常重要。

Function.prototype.bind = Function.prototype.bind || function(context){
  var self = this;

  return function(){
    return self.apply(context, arguments);
  };
}

第四部分:弹出窗口(Overlay library)

面试的最后一部分,我会让侯选人做一些实践,通过做一个‘弹出窗口’的库。我发现这个非常有用,它可以全面地展示一名前端工程师的技能:HTML,CSS和JavaScript。如果侯选人通过了前面的面试,我会马上让他们回答这个问题。

实施方案是由侯选人自己决定的,但是我也希望他们能通过以下几点来实现:

在遮罩中最好使用position中的fixed代替absolute属性,这样即使在滚动的时侯,也能始终让遮罩始盖住整个窗口。当侯选人忽略时我会提示他们这一点,并让他们解释fixed和absolute定位的区别。

.overlay {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  top: 0;
  background: rgba(0,0,0,.8);
}

他们如何让里面的内容居中也是需要考察的一点。一些侯选人会选择CSS和绝对定位,如果内容有固定的宽、高这是可行的。否则就要使用JavaScript.

.overlay article {
  position: absolute;
  left: 50%;
  top: 50%;
  margin: -200px 0 0 -200px;
  width: 400px;
  height: 400px;
}

我也会让侯选人确保当遮罩被点击时要自动关闭,这会很好地考查事件冒泡机制的机会。通常侯选人会在overlay上面直接绑定一个点击关闭的方法。

$('.overlay').click(closeOverlay);

这是个方法,不过直到你认识到点击窗口里面的东西也会关闭overlay的时侯——这明显是个BUG。解决方法是检查事件的触发对象和绑定对象是否一致,从而确定事件不是从子元素里面冒上来的,就像这样:

$('.overlay').click(function(e){
  if (e.target == e.currentTarget)
    closeOverlay();
});

其他方面

当然这些问题只能覆盖前端一点点的知识的,还有很多其他的方面你有可能会问到,像性能,HTML5 API, AMD和CommonJS模块模型,构造函数(constructors),类型和盒子模型(box model)。根据侯选人的情况,我经常会随机提些问题。


原文:Interviewing a front-end developer
转载自:OurJS

查看原文

KasheemLew 赞了文章 · 2017-11-28

redis 学习笔记

这篇 redis 学习笔记主要介绍 redis 的数据结构和数据类型,并讨论数据结构的选择以及应用场景的优化。

redis 是什么?

Redis是一种面向“键/值”对类型数据的分布式NoSQL数据库系统,特点是高性能,持久存储,适应高并发的应用场景。

Redis 数据结构

  • 动态字符串 (Sds)
  • 双端列表 (LINKEDLIST)
  • 字典
  • 跳跃表 (SKIPLIST)
  • 整数集合 (INTSET)
  • 压缩列表 (ZIPLIST)

动态字符串

Sds (Simple Dynamic String,简单动态字符串)是 Redis 底层所使用的字符串表示,它被用 在几乎所有的 Redis 模块中

Redis 是一个键值对数据库(key-value DB),数据库的值可以是字符串、集合、列表等多种类 型的对象,而数据库的键则总是字符串对象

在 Redis 中, 一个字符串对象除了可以保存字符串值之外,还可以保存 long 类型的值当字符串对象保存的是字符串时,它包含的才是 sds 值,否则的话,它就 是一个 long 类型的值

动态字符串主要有两个作用:
  1. 实现字符串对象(StringObject)
  2. 在 Redis 程序内部用作 char * 类型的替代品

双端列表

双端链表还是 Redis 列表类型的底层实现之一,当对列表类型的键进行操作——比如执行 RPUSH 、LPOP 或 LLEN 等命令时,程序在底层操作的可能就是双端链表

双端链表主要有两个作用:
  • 作为 Redis 列表类型的底层实现之一;
  • 作为通用数据结构,被其他功能模块所使用;

字典

字典(dictionary),又名映射(map)或关联数组(associative array), 它是一种抽象数据结 构,由一集键值对(key-value pairs)组成,各个键值对的键各不相同,程序可以将新的键值对 添加到字典中,或者基于键进行查找、更新或删除等操作

字典的应用
  1. 实现数据库键空间(key space);
  2. 用作 Hash 类型键的其中一种底层实现;

Redis 是一个键值对数据库,数据库中的键值对就由字典保存:每个数据库都有一个与之相对应的字典,这个字典被称之为键空间(key space)。

Redis 的 Hash 类型键使用字典和压缩列表两种数据结构作为底层实现

跳跃表

跳跃表(skiplist)是一种随机化的数据,由 William Pugh 在论文《Skip lists: a probabilistic alternative to balanced trees》中提出,这种数据结构以有序的方式在层次化的链表中保存元素,它的效率可以和平衡树媲美——查找、删除、添加等操作都可以在对数期望时间下完成, 并且比起平衡树来说,跳跃表的实现要简单直观得多

和字典、链表或者字符串这几种在 Redis 中大量使用的数据结构不同,跳跃表在 Redis 的唯一作用,就是实现有序集数据类型
跳跃表将指向有序集的 score 值和 member 域的指针作为元素,并以 score 值为索引,对有序集元素进行排序。

整数集合

整数集合(intset)用于有序、无重复地保存多个整数值,它会根据元素的值,自动选择该用什么长度的整数类型来保存元素

Intset 是集合键的底层实现之一,如果一个集合:

  1. 只保存着整数元素;
  2. 元素的数量不多;
    那么 Redis 就会使用 intset 来保存集合元素。

压缩列表

Ziplist 是由一系列特殊编码的内存块构成的列表,一个 ziplist 可以包含多个节点(entry),每个节点可以保存一个长度受限的字符数组(不以 0 结尾的 char 数组)或者整数

Redis 数据类型

RedisObject

redisObject 是 Redis 类型系统的核心,数据库中的每个键、值,以及 Redis 本身处理的参数,都表示为这种数据类型

redisObject 的定义位于 redis.h :

/*
* Redis 对象
*/
typedef struct redisObject {
    // 类型
    unsigned type:4;
    // 对齐位
    unsigned notused:2;
    // 编码方式
    unsigned encoding:4;
    // LRU 时间(相对于 server.lruclock)
    unsigned lru:22;
    // 引用计数
    int refcount;
    // 指向对象的值
    void *ptr;
} robj;

type 、encoding 和 ptr 是最重要的三个属性。

type 记录了对象所保存的值的类型,它的值可能是以下常量的其中一个

/*
* 对象类型
*/
#define REDIS_STRING 0 // 字符串
#define REDIS_LIST 1   // 列表
#define REDIS_SET 2    // 集合
#define REDIS_ZSET 3   // 有序集
#define REDIS_HASH 4   // 哈希表

encoding 记录了对象所保存的值的编码,它的值可能是以下常量的其中一个

/*
* 对象编码
*/
#define REDIS_ENCODING_RAW 0    // 编码为字符串
#define REDIS_ENCODING_INT 1    // 编码为整数
#define REDIS_ENCODING_HT 2     // 编码为哈希表
#define REDIS_ENCODING_ZIPMAP 3 // 编码为 zipmap(2.6 后不再使用)
#define REDIS_ENCODING_LINKEDLIST 4 // 编码为双端链表
#define REDIS_ENCODING_ZIPLIST 5    // 编码为压缩列表
#define REDIS_ENCODING_INTSET 6     // 编码为整数集合
#define REDIS_ENCODING_SKIPLIST 7    // 编码为跳跃表

ptr 是一个指针,指向实际保存值的数据结构,这个数据结构由 type 属性和 encoding 属性决定。

当执行一个处理数据类型的命令时,Redis 执行以下步骤:

  1. 根据给定key,在数据库字典中查找和它像对应的redisObject,如果没找到,就返回 NULL 。
  2. 检查redisObject的type属性和执行命令所需的类型是否相符,如果不相符,返回类 型错误。
  3. 根据redisObject的encoding属性所指定的编码,选择合适的操作函数来处理底层的 数据结构。
  4. 返回数据结构的操作结果作为命令的返回值。

字符串

REDIS_STRING (字符串)是 Redis 使用得最为广泛的数据类型,它除了是 SET 、GET 等命令 的操作对象之外,数据库中的所有键,以及执行命令时提供给 Redis 的参数,都是用这种类型 保存的。

字符串类型分别使用 REDIS_ENCODING_INT 和 REDIS_ENCODING_RAW 两种编码

只有能表示为 long 类型的值,才会以整数的形式保存,其他类型 的整数、小数和字符串,都是用 sdshdr 结构来保存

哈希表

REDIS_HASH (哈希表)是HSET 、HLEN 等命令的操作对象

它使用 REDIS_ENCODING_ZIPLIST和REDIS_ENCODING_HT 两种编码方式

Redis 中每个hash可以存储232-1键值对(40多亿)

列表

REDIS_LIST(列表)是LPUSH 、LRANGE等命令的操作对象

它使用 REDIS_ENCODING_ZIPLIST和REDIS_ENCODING_LINKEDLIST 这两种方式编码

一个列表最多可以包含232-1 个元素(4294967295, 每个列表超过40亿个元素)。

集合

REDIS_SET (集合) 是 SADD 、 SRANDMEMBER 等命令的操作对象

它使用 REDIS_ENCODING_INTSET 和 REDIS_ENCODING_HT 两种方式编码

Redis 中集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是O(1)。

集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)

有序集

REDIS_ZSET (有序集)是ZADD 、ZCOUNT 等命令的操作对象

它使用 REDIS_ENCODING_ZIPLIST和REDIS_ENCODING_SKIPLIST 两种方式编码

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是O(1)。 集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)

Redis各种数据类型_以及它们的编码方式

Redis各种数据类型_以及它们的编码方式

过期时间

在数据库中,所有键的过期时间都被保存在 redisDb 结构的 expires 字典里:

typedef struct redisDb {
    // ...
    dict *expires;
    // ...
} redisDb;

expires 字典的键是一个指向 dict 字典(键空间)里某个键的指针,而字典的值则是键所指 向的数据库键的到期时间,这个值以 long long 类型表示

过期时间设置

Redis 有四个命令可以设置键的生存时间(可以存活多久)和过期时间(什么时候到期):

  • EXPIRE 以秒为单位设置键的生存时间;
  • PEXPIRE 以毫秒为单位设置键的生存时间;
  • EXPIREAT 以秒为单位,设置键的过期 UNIX 时间戳;
  • PEXPIREAT 以毫秒为单位,设置键的过期 UNIX 时间戳。

虽然有那么多种不同单位和不同形式的设置方式,但是 expires 字典的值只保存“以毫秒为单位的过期 UNIX 时间戳” ,这就是说,通过进行转换,所有命令的效果最后都和 PEXPIREAT 命令的效果一样。

如果一个键是过期的,那它什么时候会被删除?

下边是参考答案

  1. 定时删除:在设置键的过期时间时,创建一个定时事件,当过期时间到达时,由事件处理 器自动执行键的删除操作。
  2. 惰性删除:放任键过期不管,但是在每次从 dict 字典中取出键值时,要检查键是否过 期,如果过期的话,就删除它,并返回空;如果没过期,就返回键值。
  3. 定期删除:每隔一段时间,对expires字典进行检查,删除里面的过期键

Redis 使用的过期键删除策略是惰性删除加上定期删除

应用场景

  • 缓存
  • 队列
  • 需要精准设定过期时间的应用

比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳,那么就可以简单地通过过期时间排序,定时清除过期数据了,不仅是清除Redis中的过期数据,你完全可以把Redis里这个过期时间当成是对数据库中数据的索引,用Redis来找出哪些数据需要过期删除,然后再精准地从数据库中删除相应的记录

  • 排行榜应用,取TOP N操作

这个需求与上面需求的不同之处在于,前面操作以时间为权重,这个是以某个条件为权重,比如按顶的次数排序,这时候就需要我们的sorted set出马了,将你要排序的值设置成sorted set的score,将具体的数据设置成相应的value,每次只需要执行一条ZADD命令即可

  • 统计页面访问次数

使用 incr 命令 定时使用 getset 命令 读取数据 并设置新的值 0

  • 使用set 设置标签

例如假设我们的话题D 1000被加了三个标签tag 1,2,5和77,就可以设置下面两个集合:

$ redis-cli sadd topics:1000:tags 1
(integer) 1
$ redis-cli sadd topics:1000:tags 2
(integer) 1
$ redis-cli sadd topics:1000:tags 5
(integer) 1
$ redis-cli sadd topics:1000:tags 77
(integer) 1
$ redis-cli sadd tag:1:objects 1000
(integer) 1
$ redis-cli sadd tag:2:objects 1000
(integer) 1
$ redis-cli sadd tag:5:objects 1000
(integer) 1
$ redis-cli sadd tag:77:objects 1000
(integer) 1

要获取一个对象的所有标签:

$ redis-cli smembers topics:1000:tags
1. 5
2. 1
3. 77
4. 2

获得一份同时拥有标签1, 2,10和27的对象列表。
这可以用SINTER命令来做,他可以在不同集合之间取出交集

内存优化

问题: Instagram的照片数量已经达到3亿,而在Instagram里,我们需要知道每一张照片的作者是谁,下面就是Instagram团队如何使用Redis来解决这个问题并进行内存优化的。

具体方法,参考下边这篇文章:节约内存:Instagram的Redis实践

参考链接

最后,感谢女朋友支持。

欢迎关注(April_Louisa)请我喝芬达
欢迎关注请我喝芬达
查看原文

赞 10 收藏 69 评论 1

KasheemLew 回答了问题 · 2017-10-20

linux centos polipo如何设置某些IP或域名不走代理?

Ubuntu, Debian, Mint:

$ sudo vi /etc/environment
http_proxy="http://proxy.com:8000"
no_proxy="127.0.0.1, localhost, *.cnn.com, 192.168.1.10, domain.com:8080"

CentOS, Fedora, RHEL:

$ sudo vi /etc/profile.d/proxy.sh
export http_proxy="http://proxy.com:8000"
export no_proxy="127.0.0.1, localhost, *.cnn.com, 192.168.1.10, domain.com:8080"

关注 2 回答 1

KasheemLew 发布了文章 · 2017-08-18

Nginx配置浅析

Nginx是Igor Sysoev用C语言编写的一个web服务器,通常用于负载均衡、反向代理和HTTP缓存等。Nginx用异步的事件驱动(event-driven)的方式来处理请求,因此负载能力很强。

Nginx使用Block(如 server block, location block)来组成配置文件的层级结构,并在接收到客户端请求之后根据请求的域名(domain name)端口(port)IP地址判断处理该请求的server block,然后根据请求的资源URI决定处理该请求的location block

Server Block

管理员可以定义多个server block作为不相关的虚拟web服务器实体,然后通过listenserver_name决定处理请求的server block

listen指令

Nginx首先会检查请求的IP地址和端口,并根据所有server block建立一个列表来处理请求。每个server block中的listen定义了这个server block能处理的IP和端口(root用户运行默认为0.0.0.0:80,非root用户运行的为0.0.0.0:8080)

listen后可以指定:

  1. IP:port的IP地址和端口
  2. 仅IP(端口将默认为80)
  3. 仅port,将监听所有接口的这个port
  4. 到某个Unix socket的路径(在服务器间转发请求的时候会用到)

在将listen的值与请求进行匹配之前,Nginx会先将listen的值中所缺省的部分补充完整。然后将优先匹配准确的IP,如果不存在完全准确匹配的IP才会匹配到0.0.0.0,如果有多个IP:port匹配度相同,Nginx将会继续检查server_name

server_name指令

Nginx将server_name与请求头中的Host进行匹配,匹配的顺序:

  1. 优先选择第一个精确匹配到的block。

    server {
        listen 80;
        server_name host.example.com;
        ...
    }
  2. 选择以*开头的进行匹配,并优先选择最长的。

    server {
        listen 80;
        server_name *.example.com;
        ...
    }
  3. 选择以*结尾的进行匹配,并优先选择最长的。

    server {
        listen 80;
        server_name www.example.*;
        ...
    }
  4. 选择以~开头的用正则表达式进行匹配,并优先选择第一个。

    server {
        listen 80;
        server_name ~^(www|host).*\.example\.com$;
        ...
    }
  1. 如果以上规则都无法匹配,则选择default_server定义的默认的server_block(每个server_block只能有一个default_server),默认的default_serverlocalhost

    server {
        listen 80 default_server;
        server_name _;
        ...
    }

Location Block

location blockserver block的一部分,决定了如何处理请求的URI,格式:

location [modifier] location_match {
    ...
}

modifier

modifier是一个可选的参数,决定了如何解析后面的location matchmodifier可选的值有:

  1. (none)

    前缀匹配, 如

    location /site {
        ...
    }

    将匹配以/site开头的URI

  2. =(equal sign)

    完整匹配,如

    location = /page {
        ...
    }

    将匹配/page,而不会响应/page/index.html的请求

  3. ~(tilde)

    大小写敏感的正则匹配, 如

    location ~ \.(jpe?g|png|gif|ico)$ {
    ...
    }

    将匹配以.jpg/.jpeg/.png/.gif/.ico结尾的URI, 但不会响应.JPG

  4. ~*(tilde + asterisk)

    大小写无关的正则匹配, 如

    location ~* \.(jpe?g|png|gif|ico)$ {
        ...
    }

    .jpg.JPG都会匹配

  5. ^~(carat + tilde)

    非正则匹配,如

    location ^~ /page {
        ...
    }

    能够匹配/page/index.html

匹配顺序

Nginx优先选择正则表达式进行匹配,但是使用=^~这两个modifier可以覆盖这一特性。排序对匹配过程也有一定的影响,因为Nginx在匹配到最长最精确的location之后就会停止匹配。

  1. 将所有非正则表达式的location_match与请求的URI进行对比。
  2. modifier=的进行完整匹配。
  3. 选择最长location_match前缀进行匹配,如果modifier^~则匹配成功。
  4. 进行正则表达式匹配
  5. 用其他前缀匹配

其他指令

  1. index

    语法:index file ...; 默认为index index.html;

    index指令指定了被作为index的文件,比如上面的index.html

    但是在下面这种情况下,对/index.html的请求将会被第二个location block处理,因为第一个与/index.html并不是完全匹配。

    location = / {
        index index.html;
    }
    
    location / {
        ...
    }
  2. try_files

    root /var/www/main;
    location / {
        try_files $uri $uri.html $uri/ /fallback/index.html;
    }
    
    location /fallback {
        root /var/www/another;
    }

    /page的请求将会首先进入第一个location, 然后尝试在/var/www/main 下依次查找page, page.html, page/,如果都没有找到的话将会被重定向到/fallback/index.html,并由第二个location提供/var/www/another/fallback/index.html

  3. rewrite

    通过Perl兼容的正则表达式改变请求的URI,语法:rewrite regex replacement [flag];

    flag的值可以是:

    • last

    结束当前的rewrite指令,并用修改过的URI去匹配其他的location block

    • break

    结束当前的rewrite指令。

    • redirect

    当替换的URI(replacement)不以 “http://”, “https://”, “$scheme”开头时进行状态码为302的暂时性的重定向。

    • permanent

    返回一个状态码为301的永久重定向。

  4. error_page

    root /var/www/main;
    
    location / {
        error_page 404 /another/whoops.html;
    }
     
    location /another {
        root /var/www;
    }

    除了/another之外的请求都会在/var/www/main查找请求的资源,如果没有找到相关资源将会重定向到/another/whoops.html,由第二个location block处理,查找/var/www/another/whoops.html

查看原文

赞 0 收藏 11 评论 0

认证与成就

  • 获得 6 次点赞
  • 获得 6 枚徽章 获得 0 枚金徽章, 获得 2 枚银徽章, 获得 4 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2016-03-01
个人主页被 436 人浏览