Yuchen You

Linux 的系统调用在内核中的入口函数都是 sys_... 但是实际上找不到 sys_ 开头的函数的定义, 因为Linux的系统调用对应的函数全部都是由 SYSCALL_DEFINE 相关的宏来定义的 在路径 /include/linux/syscalls.h 中可以看到对 SYSCALL_DEFINE 的宏定义, 123456#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)#define SYSCALL_DEFINE5(name, ...) ...

Goroutine 在 java/c++ 中我们要实现并发编程的时候, 我们通常需要自己维护一个线程池, 并且需要自己去包装一个又一个的任务, 同时需要自己去调度线程执行任务并维护上下文切换, 这一切通常会耗费程序员大量的心智;那么能不能有一种机制, 程序员只需要定义很多个任务, 让系统去帮助我们把这些任务分配到 CPU 上实现并发执行呢? goroutine 的概念类似于线程, 但 goroutine 是由 Go 的运行时(runtime)调度和管理的;Go 程序会智能地将 goroutine 中的任务合理地分配给每个 CPU; 它在语言层面已经内置了调度和上下文切换的机制 在 Go 语言编程中你不需要去自己写进程, 线程, 协程, 你的技能包里只有一个技能–goroutine, 当你需要让某个任务并发执行的时候, 你只需要把这个任务包装成一个函数, 开启一个 goroutine 去执行这个函数就可以了, 就是这么简单粗暴; 用法 只需要在调用函数的时候在前面加上 go 关键字, 就可以为一个函数创建一个 goroutine; 一个 goroutine 必定对应一个函数, 可以创建多 ...

什么是分布式系统? 一个分布式系统, 从物理上说是 用户 -network- 多台服务器主机 形成的一个特殊的系统 如果对这个模型进行抽象, 其实就是 单个terminal 和 多个 process 之间的通信, 其中, 这些 process 空间上分离, 通过网络进行通信, 不应该存在明显延迟, 并且命运不同(一台主机挂了不应该影响其他主机) 从上面的抽象系统目标, 我们还可以更加抽象出分布式系统的设计目标: High availability: 整体的分布式系统应当永远可用 Low latency: 用户请求的响应时间应当足够低 Scalability: 系统支持同时服务多个用户 … 银行后端为例 分布式系统设计的困难可以分为以下几个难点: concurrency: 多个 process 之间的并发控制, 但是之间的网络不可靠, 主机状态不可靠 inconsistency: 数据交换一定会存在可见延迟 ambiguity: 一个存款请求需要等待下游主机反馈 ACK, 但是如果没有收到, 如何判断是哪一步出了问题? 存款是否成功? channel 管道实现的同步 rendez ...

DBMS (Database Management System) A software package designed to store and manage databases. Often loosely called a database. 传统的数据管理, 往往是结合 csv 格式文件来将数据存储起来, 并且允许通过各种约束条件查找, 但是假设存在一个学生数据库系统, 包括 姓名, 年龄, id, 成绩等字段, 如果原始数据的存储方式是分成两个 文件, 一个存储 姓名到 id 的映射, 另一个存储 id 到成绩的映射, 那么采用传统的 c++ 等语言来查找数据, 会存在很多问题, 例如, atomic 的操作, 很难在确保 performance 的前提下能保证 consistency 因此, 为了避免上述问题, 需要一个软件系统来管理数据的存储和访问,确保有以下设计目标: Data Independence: 即客户端需要看到的只是数据的逻辑结构而非实际存储结构 Efficiency Centralized Management Security adn integri ...

tc 流量控制 qdisc qdisc (队列规则 queueing discipline) 是 Linux 中用于管理网络流量的机制;它允许用户定义如何处理和调度网络数据包, 我们可以将其看作一个具有一定规则的队列; 当tc处理网络包时, 会将包入队到qdisc中, 这些包会根据指定的规则被内核按照一定顺序取出 例如执行 ip l 的时候, 可以看到一些类似的信息: 12341: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether d4:6d:50:cf: ...

Paxos 共识算法 在 90 年代 Lamport 大师提出了 一种基于消息传递且具有高度容错特性的共识(consensus)算法 注意这里的 共识算法 并不是 一致性算法 (consistency algo), 二者的区别在于: 一致性算法: 主要关注数据的一致性, 确保所有节点(node/replica)在某个时间点看到相同的数据状态; 副本之间看到的值是否一样 如何解决多个副本间的写入冲突(如 last-write-wins, vector clocks) 共识算法: 多个节点就某个单一值(如某次写入, 谁是leader)达成一致的过程 分布式系统中的 节点就"某个值"进行投票与确认 通常用于 领导选举, 分布式日志, 状态同步 如 Paxos, Raft, PBFT(Practicle Byzantine Fault Tolerance Algo) 共识算法是实现强一致性的一种机制, 但不是一致性算法的全部 强一致性: 无论何时, 所有用户读取某个数据项时, 都能看到最后一次成功写入的值 分布式系统中的节点通信存在两种模型: 共享内存 ...

Paxos 共识算法 在 90 年代 Lamport 大师提出了 一种基于消息传递且具有高度容错特性的共识(consensus)算法 注意这里的 共识算法 并不是 一致性算法 (consistency algo), 二者的区别在于: 一致性算法: 主要关注数据的一致性, 确保所有节点(node/replica)在某个时间点看到相同的数据状态; 副本之间看到的值是否一样 如何解决多个副本间的写入冲突(如 last-write-wins, vector clocks) 共识算法: 多个节点就某个单一值(如某次写入, 谁是leader)达成一致的过程 分布式系统中的 节点就"某个值"进行投票与确认 通常用于 领导选举, 分布式日志, 状态同步 如 Paxos, Raft, PBFT(Practicle Byzantine Fault Tolerance Algo) 共识算法是实现强一致性的一种机制, 但不是一致性算法的全部 强一致性: 无论何时, 所有用户读取某个数据项时, 都能看到最后一次成功写入的值 分布式系统中的节点通信存在两种模型: 共享内存 ...

Kernel-Bypass 内核旁路技术 主要是为了解决超大并发下内核态与用户态之间的性能问题, 技术代表有 DPDK, eBPF等 随着移动互联网的发展, 云架构中复杂的服务治理已经将C10K的问题发展到C10M(单机并发 1000 万);一个大规模集群内, 面对东西向规模性的Gbp/s数据流量, 关键节点的挑战是用户态协议栈和多核并发问题 这个时候Linux 网络协议栈进行的各种优化策略, 基本都没有太大效果;网络协议栈的冗长流程才是最主要的性能负担 内核瓶颈限制 基于系统内核的数据传输会面临如 中断处理, 内存拷贝, 上下文切换, 局部性失效, CPU亲和性, 内存管理等等影响, 在高并发的场景下这些机制是非常大的瓶颈所在; 如图所示, 可以知道 L1, L2 层级的 cache 并不会在不同的 core 之间共享, 但是, L3 层级是允许不同 core 之间共享的, 也就是说在进行 switch context 操作的时候, L1 L2 层级的 cache 会发生 cache miss, 这无法避免, 并且在 超高并发的背景下, 上下文切换是非常频繁的, 因此 缓存 mis ...