Blogs on NoneBack

CPU Profiling: What, How, and When

Mon, 10 Mar 2025 14:46:54 +0800

What: 什么是CPU Profiling

一种程序CPU性能分析的技术。通过收集程序执行时的详细数据（例如函数调用频率、耗时、调用栈等），帮助开发者识别性能瓶颈，优化代码效率。一般用于性能分析，根因诊断的场景。

How: Profiling 数据是怎么获取的

常见的工具比如perf，用于采集进程堆栈信息。这里工具通过抽样统计的方式，获取在CPU上执行的堆栈样本然后进行性能分析。

mermaid

graph TD
A[采样触发] -->|中断| B[采样]
B -->|perf_event/ebpf| C[进程堆栈地址]
C -->|地址翻译| D[ELF, OFFSET]
D -->|符号翻译| E[调用栈]
E -->|格式化| F[pprof/perf script]
F --> |绘图| G[火焰图/调用图]

触发机制

一般使用定时中断或者基于事件计数的策略。

定时中断: 默认使用固定频率（如 99Hz）的时钟中断（SIGPROF），中断间隔越短，精度越高，但开销越大。如 Linux perf 默认使用 99Hz 频率。定时器每隔 1/99 ≈ 10.1ms 发送一个中断信号（如 SIGPROF）。

事件计数器采样: 基于硬件性能计数器（如 PERF_COUNT_HW_CPU_CYCLES, PERF_COUNT_HW_INSTRUCTIONS），在达到阈值时触发采样。比如Cache_Miss频繁的时候进行采样，这类策略可以基于硬件的负载情况进行采样的调度。

采样方法

一般会使用 OS 内核提供的epbf 或者 perf event 接口进行堆栈采样。

前者可以通过 eBPF 程序（如 bpf_get_stackid）直接捕获完整用户态和内核态调用栈，无需额外堆栈回溯，获取到完整的堆栈IP 信息。

使用 perf_event_open 接口获取指令指针（RIP），比如perf record命令，此时无法获取完整的调用栈，只获取了当前执行的函数地址，所以也只能根据地址找到触发采样的函数名称

shell


 node 3236535 34397396.208842: 250000 cpu-clock:pppH: 110c800 v8::internal::Heap_CombinedGenerationalAndSharedBarrierSlow+0x0 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 node 3236535 34397396.354632: 250000 cpu-clock:pppH: 7f7d63e87ef4 Builtins_LoadIC+0x574 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 node 3236535 34397396.451226: 250000 cpu-clock:pppH: ffffffff889bbb0e syscall_enter_from_user_mode+0xe ([kernel.kallsyms])
 node 3236535 34397397.580029: 250000 cpu-clock:pppH: 18c73f1 uv__metrics_update_idle_time+0x11 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 node 3236535 34397397.649952: 250000 cpu-clock:pppH: 7f7d63e87f0f Builtins_LoadIC+0x58f (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 node 3236535 34397399.340595: 250000 cpu-clock:pppH: 7f7d63e8b353 Builtins_LoadICTrampoline+0x13 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 node 3236535 34397399.340842: 250000 cpu-clock:pppH: 7f7d6ba9022c malloc+0x18c (/usr/lib/x86_64-linux-gnu/libc.so.6)
 node 3236535 34397399.341095: 250000 cpu-clock:pppH: 19d3913 Builtins_FulfillPromise+0x193 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)

通过Stack Unwind（比如libunwind）进行堆栈回溯以此来获取完整的堆栈信息,perf record -g。

stack unwind 参考: https://zhuanlan.zhihu.com/p/460686470

shell


node 3236535 34397238.259753: 250000 cpu-clock:pppH:
 7f7d44339100 [unknown] (/tmp/perf-3236535.map)
 18ea0dc Builtins_JSEntryTrampoline+0x5c (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 18e9e03 Builtins_JSEntry+0x83 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 106692b v8::internal::(anonymous namespace)::Invoke+0x12b (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 10679c4 v8::internal::Execution::Call+0x64 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 f2a09d v8::Function::Call+0x14d (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 c1c738 node::Environment::RunTimers+0x208 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 18c46f2 uv__run_timers+0x22 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 18c8524 uv_run+0x2f4 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 bd3be6 node::SpinEventLoopInternal+0x156 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 d18564 node::NodeMainInstance::Run+0x94 (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 d18ffd node::NodeMainInstance::Run+0xcd (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 c7d43f node::Start+0x58f (/root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node)
 7f7d6ba14d90 __libc_start_call_main+0x80 (/usr/lib/x86_64-linux-gnu/libc.so.6)

地址翻译

采样后得到的地址信息是进程的虚拟地址信息，即：

shell


7f7d44339100
18ea0dc
18e9e03
106692b
10679c4
f2a09d
c1c738
18c46f2
18c8524
bd3be6
d18564
d18ffd
c7d43f
7f7d6ba14d90

我们还需要将虚拟地址翻译成 ELF + OFFSET ，以便下一步进行函数符号的翻译。

利用/proc/pid/maps里记录的信息就可以实现V_ADDR --> (ELF, OFFSET) 的翻译。maps里记录的信息的关键信息有:<地址范围> <权限> <文件偏移> <inode> <文件路径>

procfs maps 参考: https://man7.org/linux/man-pages/man5/proc_pid_maps.5.html

shell


00400000-00b81000 r--p 00000000 fc:03 550055 /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node
00b81000-00b83000 r-xp 00781000 fc:03 550055 /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node
......
7f7d6bf3c000-7f7d6bf3d000 ---p 0021a000 fc:03 67 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7f7d6bf3d000-7f7d6bf48000 r--p 0021a000 fc:03 67 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
7f7d6bf48000-7f7d6bf4b000 rw-p 00225000 fc:03 67 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
......
7f7d6bf52000-7f7d6bf53000 rw-p 00003000 fc:03 3952 /usr/lib/x86_64-linux-gnu/libdl.so.2
......
7f7d6bf56000-7f7d6bf57000 ---p 00000000 00:00 0
7f7d6bf57000-7f7d6bf61000 rw-p 00000000 00:00 0
7f7d6bf61000-7f7d6bf63000 r--p 00000000 fc:03 2928 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7d6bf63000-7f7d6bf8d000 r-xp 00002000 fc:03 2928 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7d6bf8d000-7f7d6bf98000 r--p 0002c000 fc:03 2928 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7d6bf99000-7f7d6bf9b000 r--p 00037000 fc:03 2928 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7f7d6bf9b000-7f7d6bf9d000 rw-p 00039000 fc:03 2928 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

maps里记录了不同ELF段在虚拟内存的映射，以及对应ELF文件基地址。我们使用函数把虚拟地址匹配到ELF段，之后再基于地址偏移我们就可以找到相对ELF文件偏移地址，即offset = 虚拟地址 - 内存段起始地址 + 文件偏移

符号翻译

通过地址翻译，我们现在找到了虚拟地址对应的[ELF, offset]。基于这个信息，我们可以结合符号表以及调试信息翻译出堆栈符号。

使用 ELF 文件中的符号表，或者使用 dwarf debuginfo的信息，我们可以将地址翻译成函数符号。

比如读取动态库的dynsym部分记录的函数符号信息，再根据offset查找。

bash


# nm -D /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node | grep malloc
# <地址> <类型> <符号名>
00000000055f9d18 D ares_malloc
0000000001f1a2a0 T ares_malloc_data
0000000001f1b6e0 T ares_malloc_zero
0000000001bf5680 T CRYPTO_malloc
0000000001bf67d0 T CRYPTO_secure_malloc
0000000001bf66f0 T CRYPTO_secure_malloc_done
0000000001bf62d0 T CRYPTO_secure_malloc_init
0000000001bf67c0 T CRYPTO_secure_malloc_initialized
 U malloc@GLIBC_2.2.5
 U malloc_usable_size@GLIBC_2.2.5
0000000001f5cce0 T nghttp2_mem_malloc
0000000001fdaaa0 T ngtcp2_mem_malloc
00000000020853f0 T uprv_malloc_75

又或者读取ELF的dwarf信息，不仅能找到符号表，还能获取函数在源码中的位置。

dwarf参考：https://www.hitzhangjie.pro/debugger101.io/8-dwarf/

bash


# readelf --debug-dump=info /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node | less
<1><1980>: Abbrev Number: 41 (DW_TAG_subprogram)
 <1981> DW_AT_external : 1
 <1981> DW_AT_name : (indirect string, offset: 0x734): uv__make_close_pending # function name
 <1985> DW_AT_decl_file : 19
 <1986> DW_AT_decl_line : 247
 <1987> DW_AT_decl_column : 6
 <1988> DW_AT_prototyped : 1
 <1988> DW_AT_declaration : 1
 <1988> DW_AT_sibling : <0x1992>
 <2><198c>: Abbrev Number: 21 (DW_TAG_formal_parameter)
 <198d> DW_AT_type : <0x12a8>
 <2><1991>: Abbrev Number: 0
 <1><1992>: Abbrev Number: 42 (DW_TAG_subprogram)
 <1993> DW_AT_external : 1
 <1993> DW_AT_name : (indirect string, offset: 0x1022): __assert_fail
 <1997> DW_AT_decl_file : 18
 <1998> DW_AT_decl_line : 67
 <1999> DW_AT_decl_column : 13
 <199a> DW_AT_prototyped : 1
 <199a> DW_AT_noreturn : 1
 <199a> DW_AT_declaration : 1
 <199a> DW_AT_sibling : <0x19b3>

得到了符号后，部分符号需要做demangle处理，以提升可读性，比如使用c++filt工具：

将C++源程序标识符(original C++ source identifier)转换成C++ ABI标识符(C++ ABI identifier)的过程称为mangle；相反的过程称为demangle。

参考：https://www.cnblogs.com/BloodAndBone/p/7912179.html

bash


# nm -D /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node | grep T | tail 
0000000005611b78 u _ZZN5cppgc8internal14StatsCollector13InternalScopeILNS1_13TraceCategoryE0ELNS1_12ScopeContextE1EE14StartTraceImplEvE28trace_event_unique_atomic448
000000000562bb60 u _ZZNK2v88internal8compiler26SimplifiedLoweringVerifier15InputTruncationEPNS1_4NodeEiE14any_truncation
0000000002875e70 u _ZZNK4node7TCPWrap14MemoryInfoNameEvE20error_and_abort_args
0000000003480720 u _ZZNSt8__detail13__to_chars_16IjEENSt9enable_ifIXsrSt5__or_IJS2_IJSt7is_sameINSt9remove_cvIT_E4typeEaES3_IS7_sES3_IS7_iES3_IS7_lES3_IS7_xES3_IS7_nEEES2_IJS3_IS7_hES3_IS7_tES3_IS7_jES3_IS7_mES3_IS7_yES3_IS7_oEEES3_IcS7_EEE5valueESt15to_chars_resultE4typeEPcSR_S5_E8__digits
000000000281a780 u _ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits
000000000281a6a0 u _ZZNSt8__detail18__to_chars_10_implImEEvPcjT_E8__digits
0000000002122cc0 W _ZZSt9call_onceIRFvvEJEEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv
0000000005600930 u _ZZZN4node14ThreadPoolWork12ScheduleWorkEvENKUlP9uv_work_sE_clES2_E27trace_event_unique_atomic42
0000000005600928 u _ZZZN4node14ThreadPoolWork12ScheduleWorkEvENKUlP9uv_work_sE_clES2_E27trace_event_unique_atomic45
0000000005600920 u _ZZZN4node14ThreadPoolWork12ScheduleWorkEvENKUlP9uv_work_siE0_clES2_iE27trace_event_unique_atomic51

# demangle 处理后
# nm -D /root/.vscode-server/cli/servers/Stable-e54c774e0add60467559eb0d1e229c6452cf8447/server/node | grep T | tail | c++filt
0000000005611b78 u cppgc::internal::StatsCollector::InternalScope<(cppgc::internal::StatsCollector::TraceCategory)0, (cppgc::internal::StatsCollector::ScopeContext)1>::StartTraceImpl()::trace_event_unique_atomic448
000000000562bb60 u v8::internal::compiler::SimplifiedLoweringVerifier::InputTruncation(v8::internal::compiler::Node*, int) const::any_truncation
0000000002875e70 u node::TCPWrap::MemoryInfoName() const::error_and_abort_args
0000000003480720 u std::__detail::__to_chars_16<unsigned int>(char*, char*, unsigned int)::__digits
000000000281a780 u std::__detail::__to_chars_10_impl<unsigned int>(char*, unsigned int, unsigned int)::__digits
000000000281a6a0 u std::__detail::__to_chars_10_impl<unsigned long>(char*, unsigned int, unsigned long)::__digits
0000000002122cc0 W std::call_once<void (&)()>(std::once_flag&, void (&)())::{lambda()#2}::_FUN()
0000000005600930 u node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*)#1}::operator()(uv_work_s*) const::trace_event_unique_atomic42
0000000005600928 u node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*)#1}::operator()(uv_work_s*) const::trace_event_unique_atomic45
0000000005600920 u node::ThreadPoolWork::ScheduleWork()::{lambda(uv_work_s*, int)#2}::operator()(uv_work_s*, int) const::trace_event_unique_atomic51

堆栈输出

按照指定格式组织堆栈信息，比如pprof / perf script 的格式，有时候可以附带上一些辅助集合的元信息（比如容器ID, 业务类型）以便更好的聚合，处理，使用数据

数据展示

上述的堆栈格式通过工具最终都能转换为火焰图和调用图。

When: 什么时候该使用CPU Profiling工具

在相同一段时间内，监控描述了程序运行状态，堆栈代表了程序的具体行为，大部分场景两者可以互相佐证。

mermaid

  graph TD
A[业务异常现象:不可用/性能抖动] --> N[确定需要排查的主体以及异常时间段]
N --> B[观察核心指标: cpu,mem,disk,iops,qps/tps等]
B --> C[排查结论]
B -->|需要进一步分析| D[查看异常时间段堆栈]
D --> C

一般在与CPU有关的根因分析，性能分析这类场景会使用，比如以下场景：

场景分类	典型表现	工具选择	数据采集策略
突发性CPU毛刺	监控图表出现锯齿状CPU峰值	- 持续Profiling系统	峰值前后5分钟上下文捕获 / 常规采样
版本性能回归	新版本发布后QPS/TPS下降	- Differential FlameGraph	A/B版本对比采样
CpuSys高	OS内核态Cpu较高占用，导致主机性能抖动	- FlameGraph or Call-Chain Graph	常规采样，分析内核堆栈

显然，当程序没有在CPU上稳定运行，Profiling得到的数据价值就会大大降低，比如IO Bound，频繁上下文切换，瞬时进程。此时可能需要更换分析工具。

mermaid

graph TD
A[CPU Profiling 不适用场景] --> B[内存瓶颈]
A --> C[I/O 密集型]
A --> D[锁竞争]
A --> E[短生命周期进程]
B -->|特征| B2("高 Page Fault/Swap、GC 停顿明显")
B -->|工具| B3{{"Heap Profiler、vmstat"}}
C -->|特征| C2("低 CPU 利用率 iowait > 30%")
C -->|工具| C3{{"iostat、blktrace"}}
D -->|特征| D2("sys% 高上下文切换频繁")
D -->|工具| D3{{"perf lock、lockstat"}}
E -->|特征| E2("进程存活时间 < 采样间隔")
E -->|工具| E3{{"execsnoop、动态插桩"}}

Ref

代码参考：https://github.com/noneback/doctor
stack unwind: https://zhuanlan.zhihu.com/p/460686470
proc_pid_maps: https://man7.org/linux/man-pages/man5/proc_pid_maps.5.html
dwarf: https://www.hitzhangjie.pro/debugger101.io/8-dwarf/
demange & mangle: https://www.cnblogs.com/BloodAndBone/p/7912179.html

LevelDB MVCC

Sat, 08 Feb 2025 14:06:39 +0800

LevelDB通过 MVCC 实现了 sstable 读写并发以及 Snapshot Read 的功能，让我们来看看它是怎么做到的。

Sequence Number

LevelDB通过Sequence Number作为逻辑时钟，维护了单个 KV 写操作的全序关系。在 InternalKey 的编码里，将Sequence Number 编码到 InternalKey 的最后几个字节里。在写内存时，也确保了数据的有序性。

Versioning

LevelDB每次sstable文件集合变化，都会从一个Version升级成另外一个Version。Version表示DB在某个时刻的状态，每个Version中记录了某个时刻sstable以及compaction 有关的元信息。VersionEdit 描述了版本的变化。

text

Version1 ---VersionEdit--> Version2

VersionSet 被描述为一组有序的 Version 链表，代表了数据库当前以及历史的运行状态。其中LastSeq 和 Version 链表最为关键。

Version链表描述了存储的所有Version以及变化，Version 本身使用 RC 的方式做 GC。Version Chain 描述了不同时间sstable 集合写操作的全序关系。

WAL + Manifest 确保了LastSeq变更的原子性。

Manifest文件作为VersionChange的WAL保证版本变更的Crush Safety, 和 Version Commit操作一起保证了VersionSet最新版本变更的原子性。

plain

Write Done ---> VersionEdit ---> Manifest ---> VersionSet

在整个 Version迁移过程中，写操作导致状态变更由 VersionEdit 记录在内存中，然后写入到 Manifest里，最后再将 VersionSet 指向此 Version，这样的操作保证了 Version 变更的一致性，即Compaction导致的版本变更不会影响到正在进行的读操作。读操作也不会读取到中间状态的 sstable 文件。

cpp


class VersionEdit {
 /** other code */
 typedef std::set<std::pair<int, uint64_t>> DeletedFileSet;

 std::string comparator_;
 uint64_t log_number_;
 uint64_t prev_log_number_;
 uint64_t next_file_number_;
 SequenceNumber last_sequence_;
 bool has_comparator_;
 bool has_log_number_;
 bool has_prev_log_number_;
 bool has_next_file_number_;
 bool has_last_sequence_;

 std::vector<std::pair<int, InternalKey>> compact_pointers_;
 DeletedFileSet deleted_files_;
 std::vector<std::pair<int, FileMetaData>> new_files_;
};

class Version {
 VersionSet* vset_; // VersionSet to which this Version belongs
 Version* next_; // Next version in linked list
 Version* prev_; // Previous version in linked list
 int refs_; // Number of live refs to this version

 // List of files and meta per level
 std::vector<FileMetaData*> files_[config::kNumLevels];

 // Next file to compact based on seek stats. （allowed_seek耗尽导致的compact）
 FileMetaData* file_to_compact_;
 int file_to_compact_level_;

 // Level that should be compacted next and its compaction score.
 // Score < 1 means compaction is not strictly needed. These fields
 // are initialized by Finalize().
 double compaction_score_; // score表示数据不均衡的程度，score越大表示该level数据越不均衡，需要有限compact
 int compaction_level_;
}

class VersionSet {
 Env* const env_;
 const std::string dbname_;
 const Options* const options_;
 TableCache* const table_cache_;
 const InternalKeyComparator icmp_;
 uint64_t next_file_number_;
 uint64_t manifest_file_number_;
 uint64_t last_sequence_;
 uint64_t log_number_;
 uint64_t prev_log_number_; // 0 or backing store for memtable being compacted

 // Opened lazily
 WritableFile* descriptor_file_; // descriptor_ is for manifest file
 log::Writer* descriptor_log_; // descriptor_ is for manifest file
 Version dummy_versions_; // Head of circular doubly-linked list of versions. 正在使用的version的链表
 Version* current_; // == dummy_versions_.prev_

 // Per-level key at which the next compaction at that level should start.
 // Either an empty string, or a valid InternalKey.
 std::string compact_pointer_[config::kNumLevels];
}

MVCC & Snapshot Read

对于memtable的并发读写操作，依赖 skiplist，本身是有锁来处理读写冲突的。对于sstable的并发读写（compaction 和 read ）则依赖 Version 和 Sequence Number 解决。

每次对 sstable 的写操作（minor/major compaction）必然产生新的 sstable 文件，带来 sstable 集合的变化，进而产生新的 Version。而每条KV记录也一定会携带 Sequence Number信息。

每次读操作(Version.Get)会附带上 Sequence Number 以及 Version 信息，Sequence Number 确保了后续的写入对读不可见，关联Version确保了Version关联的sstable在读操作结束前不会被GC。进而确保了读取所用到的sstable文件不会丢失或者更新,同时也能实现 Snapshot Read。

如果 Read 和 Write 在同一个 Version 进行，则必须是Compaction 先完成后，否则 Version 不会变化。此时触发读取操作，此时sstable不会有变化，所以读写并不冲突。如果不是，则只能是先读后写，写对读不可见，更不会有冲突。

Reference

https://leveldb-handbook.readthedocs.io/zh/latest/index.html https://noneback.github.io/zh/blog/zh/leveldb-write/

Prometheus--TSDB

Tue, 31 Dec 2024 01:10:28 +0800

最近晋升，顺便总结一些以前的工作。工作里大规模数据库可观测系统占了很大一部分，不过这个和云原生监控系统Prometheus还是很不一样的。现在来学习一下开源监控的标准系统。

文章主要涉及 Prometheus 自带的单机时序存储。简单写写里面的TSDB设计，不涉及源码分析。

这种项目的源码分析性价比有点低,除非我是专门搞tsdb的，不然分析之后也容易忘，再说了也不是什么很好的代码。

数据+查询模型

一个监控指标被描述为一组与时间有关的数据结构，timeseries。

$$ {timeseries} = \quad\lbrace \quad metric(attached\ with\ a\ set\ of\ labels) \Rightarrow (t_0,\ v_0),\ (t_1,\ v_1),\ (t_2,\ v_2),\ \ldots,\ (t_n, v_n) \quad\rbrace $$

查询使用 ${identifier(metric\ +\ sets\ of\ selected\ labels\ value)}$ 查询得到对应的timeseries

text

series
^
│ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="GET"}
│ . . . . . . . . . . . . . . . . . . . . . . {__name__="request_total", method="POST"}
│ . . . . . . .
│ . . . . . . . . . . . . . . . . . . . ...
│ . . . . . . . . . . . . . . . . . . . . .
│ . . . . . . . . . . . . . . . . . . . . . {__name__="errors_total", method="POST"}
│ . . . . . . . . . . . . . . . . . {__name__="errors_total", method="GET"}
│ . . . . . . . . . . . . . .
│ . . . . . . . . . . . . . . . . . . . ...
│ . . . . . . . . . . . . . . . . . . . .
v
<-------------------- time --------------------->

identifier 的定义很重要。否则 ts 数据容易膨胀，比如容器重建的场景，如果 label 用的不好很容易膨胀。

数据组织方式

对云原生的场景，监控数据有哪些特点？

数据的生命周期短。因为单个容器本身的生命周期就很短（比如扩缩容场景，大量临时任务等场景），timeseries 很容易在一定时间维度上膨胀。
垂直写入，水平查询

带着这些问题看看数据文件的组织方法，如何解决或者避免这些问题。

那么首先看看逻辑的结构

整个 db 由 blocks + HEAD 组成，block 又可以进一步被拆分成 chunks，HEAD 基本上就是内存数据+wal 保障的读写 buffer 区域。chunks 包含多种 timeseries。

对于单个 Block 的磁盘目录结构如下：

text

├── 01BKGV7JC0RY8A6MACW02A2PJD // block 的 ULID
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── chunks_head
│ └── 000001
└── wal
├── 000000002
└── checkpoint.00000001
└── 00000000

block，一个时间段内（默认 2 小时）的所有数据，只读，用 ULID 命名。每一个 block 内主要包括：
- chunks 固定大小（最大 128M）的 chunks 文件
- index 索引文件，主要包含倒排索引的信息
- meta.json 元信息，主要包括 block 的 minTime/maxTime，用于在查询的时候data skip。
chunks_head，当前在写入的 block 对应的 chunks 文件，只读，最多 120 个数据点，时间跨度最大 2 小时。
wal：数据完整性保证

从图上可以知道很多信息，比如wal保障数据完整性；Head 类似 tsdb 的 buffer pool，只不过用 mmap 托管，实现内存数据批量刷盘。Head 到达一定条件（比如时间阈值，数据大小阈值）之后变成 immutable 的结构（block）刷盘。

整体在数据组织上有很多概念和lsm 类存储结构类似。LSM结构也确实很适合 tsdb。

不难看出 Prometheus 的设计思路：

通过数据按时间分片的方式来解决数据生命周期短的问题
通过内存攒批的方式来对应只写最新数据的场景

抛开与 leveldb 类似的地方不谈，我们来看看有什么不一样的地方。

首先，使用的模型上不一样。leveldb 是 kv ，tsdb 是 timeseries，与时间强关联，而时间是单调递增的。很少会去写入过去时间端的数据。其次，查询的模型也不一样。tsdb 会有更多样话的查询方式，比如对label 的各种集合操作对 timeseries 进行过滤，所以会有更多的元信息来标注 timeseries，以便高效的查询。

因为这类的需求，这里引入了一些新结构和功能：倒排索引，checkpoint，tombstone，retention，以及和 lsm kv模型不一样的 compaction 设计。这些让我们和对应的文件 format 一起分析。

文件组织格式

让我们来看看有哪些成分，具体的组织方式不是本文重点。

meta.json

block 的一些信息，关键看 compaction 和 minT,maxT。

minT,maxT 记录block 的时间访问，查询的时候可以用来做 data skip。

companction：记录了block的历史信息，比如经历了几次 compaction(level), 由哪些 block 派生出来(source)。暂时不知道有啥用。可能可以compaction 或者 retention 的时候用到，比如清理重复的 source 里面的 block。

text

{
"ulid": "01EM6Q6A1YPX4G9TEB20J22B2R", #
"minTime": 1602237600000,
"maxTime": 1602244800000,
"stats": {
"numSamples": 553673232,
"numSeries": 1346066,
"numChunks": 4440437
},
"compaction": {
"level": 1,
"sources": [
"01EM65SHSX4VARXBBHBF0M0FDS",
"01EM6GAJSYWSQQRDY782EA5ZPN"
]
},
"version": 1
}

chunks

普通的数据文件，它的索引都在 index 文件里。需要注意的是一个chunk 只能属于一个 timeseries，一个 timeseries 由多个 chunks组成。

text

┌──────────────────────────────┐
│ magic(0x85BD40DD) <4 byte> │
├──────────────────────────────┤
│ version(1) <1 byte> │
├──────────────────────────────┤
│ padding(0) <3 byte> │
├──────────────────────────────┤
│ ┌──────────────────────────┐ │
│ │ Chunk 1 │ │
│ ├──────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────┤ │
│ │ Chunk N │ │
│ └──────────────────────────┘ │
└──────────────────────────────┘
Every Chunk:
┌───────────────┬───────────────────┬──────────────┬────────────────┐
│ len <uvarint> │ encoding <1 byte> │ data <bytes> │ CRC32 <4 byte> │
└───────────────┴───────────────────┴──────────────┴────────────────┘

tombstone

标记删除，tsdb 有时候会有一些删除操作。比如，短时 Job、容器销毁之后，业务上可能希望删除。标记删除主要是为了用追加写代替原地修改。后续可以通过 Compaction 回收这部分磁盘。

当然不删除也没事，会有 TTL 到期删除磁盘过期数据。

text

┌────────────────────────────┬─────────────────────┐
│ magic(0x0130BA30) <4b> │ version(1) <1 byte> │
├────────────────────────────┴─────────────────────┤
│ ┌──────────────────────────────────────────────┐ │
│ │ Tombstone 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Tombstone N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ CRC<4b> │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
Every Tombstone:
┌────────────────────────┬─────────────────┬─────────────────┐
│ series ref <uvarint64> │ mint <varint64> │ maxt <varint64> │
└────────────────────────┴─────────────────┴─────────────────┘

index 文件

包含了读取用到的所有信息。比如倒排索引，timeseries 和 chunks 的映射关系。

里面值得注意的是 Series 和 Postings 两类。

Series 里面记录了Blocks里所有 series 对应 chunks的信息。

Posting Offset Table记录了各个倒排索引的位置。倒排索引具体的内容被放在了 Postings里。

对倒排索引的集合操作，可以快速过滤出来符合条件的 timeseries

text

┌────────────────────────────┬─────────────────────┐
│ magic(0xBAAAD700) <4b> │ version(1) <1 byte> │
├────────────────────────────┴─────────────────────┤
│ ┌──────────────────────────────────────────────┐ │
│ │ Symbol Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Series │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Index 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Index N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings 1 │ │
│ ├──────────────────────────────────────────────┤ │
│ │ ... │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings N │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Label Offset Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ Postings Offset Table │ │
│ ├──────────────────────────────────────────────┤ │
│ │ TOC │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
A Series:
┌──────────────────────────────────────────────────────┐
│ len <uvarint> │
├──────────────────────────────────────────────────────┤
│ ┌──────────────────────────────────────────────────┐ │
│ │ labels count <uvarint64> │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ ref(l_i.name) <uvarint32> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(l_i.value) <uvarint32> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ... │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ chunks count <uvarint64> │ │
│ ├──────────────────────────────────────────────────┤ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ c_0.mint <varint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ c_0.maxt - c_0.mint <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(c_0.data) <uvarint64> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ┌────────────────────────────────────────────┐ │ │
│ │ │ c_i.mint - c_i-1.maxt <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ c_i.maxt - c_i.mint <uvarint64> │ │ │
│ │ ├────────────────────────────────────────────┤ │ │
│ │ │ ref(c_i.data) - ref(c_i-1.data) <varint64> │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ ... │ │
│ └──────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────┤
│ CRC32 <4b> │
└──────────────────────────────────────────────────────┘
A Postings:
┌────────────────────┬────────────────────┐
│ len <4b> │ #entries <4b> │
├────────────────────┴────────────────────┤
│ ┌─────────────────────────────────────┐ │
│ │ ref(series_1) <4b> │ │
│ ├─────────────────────────────────────┤ │
│ │ ... │ │
│ ├─────────────────────────────────────┤ │
│ │ ref(series_n) <4b> │ │
│ └─────────────────────────────────────┘ │
├─────────────────────────────────────────┤
│ CRC32 <4b> │
└─────────────────────────────────────────┘

加速磁盘查询

这里重点讲述一次查询是如何找到符合条件的数据的：

首先在 Posting Offset Table 中，找到对应 label 的 Postings 位置
根据 Postings 中的 series 信息，找到对应的 chunk 位置，即上文中的 series ref
根据timeseries 找到对应的 chunks

Compaction

类似 leveldb，也有 major compaction和 minor compaction。在这里叫 Compaction 和 Head Compaction。

Head Compaction类似把 Head部分持久化成 Chunk 的过程，在这个过程中，mark delete 的tombstone 会被真的删除（毕竟要读到内存里，顺手删了）。

Compaction 就是把 Block 合并的一个过程。这个动作可以回收：

标记删除占用的磁盘资源。
重复的部分信息。比如散落在多个 block 里面的重复 chunk，倒排索引这类的磁盘记录
加速一些查询的处理。比如数据在多个数据块之间overlapping（没处理的话，读出来之后要在内存里处理，不如顺便在 compaction 的时候处理掉，合并之后读取也方便了）

什么时候会 compaction？

官方博客里没咋说清楚，只提到了data overlapping 的时候会触发。不过其他策略也挺多的。比如定时触发，每次 minor 触发的时候判断，基于 tombstone 的大小判断，手动触发这类。可以参考一些 leveldb 的策略。

Retention

没啥说的，就是 Time or Size Based TTL，感觉放到 Compaction 里面做也不是不行。

Snapshot

感觉就是把内存数据 dump 一份到磁盘上而已……。可能是为了平衡大量指标数据磁盘写入以及数据完整性。不然有了 wal 还要它干啥。

Reference

https://web.archive.org/web/20210803115658/https://fabxc.org/tsdb/

https://liujiacai.net/blog/2021/04/11/prometheus-storage-engine/

https://tech.qimao.com/prometheus-tsdb-de-she-ji-yu-shi-xian-2/

https://ganeshvernekar.com/blog/prometheus-tsdb-persistent-block-and-its-index/

https://ganeshvernekar.com/blog/prometheus-tsdb-compaction-and-retention/#compaction

Borg: Large-scale cluster management at Google with Borg

Mon, 19 Feb 2024 11:12:16 +0800

Borg 是一个集群管理系统，类似闭源的k8s。

通过准入控制、高效的任务装箱、超售、机器共享、以及进程级别的性能隔离，实现了高利用率。
为高可用应用提供了可以减少故障恢复时间的运行时特性，以及降低关联故障概率的调度策略。
提供声明式的作业描述语言、域名服务集成、实时作业监控、分析和模拟系统行为的工具。简化用户的使用。

文章本意在介绍系统设计的同时，讲述Google在背后的经验总结。但本文主要关心系统的设计，关注Borg对外提供的服务SLA，关注Borg对负载，资源，调度等方面的抽象。

系统抽象

工作负载上，主要有两种：一是长期运行的服务，二是批处理任务。分别对应两种类型的Job (prod / non-prod)。Job由若干Task组成，不同的Job拥有不同的优先级。

部署架构上，一个Borg Cluster由若干Cell组成，一个Cell由若干机器组成。

任务调度上，一切机器上有限的物理或者逻辑单元都需要被视为资源，如cpu，mem，io等资源。

系统架构

Master-Slave架构，由一个BorgMaster和若干Borglet节点组成，调度器是一个独立的服务。

BorgMaster是一个逻辑节点，负责与外部以及Borglet的交互，以及集群内状态的维护。利用Paxos实现多副本以及ha容错。

Borglet是Cell内没台机器的Borg Proxy。负责启停Task，管理Node的物理资源，上报状态。

Scheduler是负责进行Task调度的服务。使用Master中记录的状态，并基于此异步的去处理Task的调度，并告知Master二次判断。

资源调度

Scheduler是其中的很重要的核心服务。调度算法的好坏决定了资源的利用率，直接与使用成本关联。

基本流程

调度算法有两个部分:

可行性检查，找到一组可以运行任务的机器
评分，从中选择一个合适的机器。

在可行性检查阶段，调度器会找到一组满足任务约束且有足够可用资源的机器，其中可用资源包括已经分配给低优先级任务但可以抢占的资源。

在评分阶段，调度器确定每台可行机器的适宜性。评分考虑了用户特定的偏好，但主要取决于内建的标准：例如最小化被抢占任务的个数和优先级，选择已经有该任务安装包的机器，尽可能使任务分散在不同的供电和故障域，以及装箱(Packing)质量(在单台机器上混合高、低优先级的任务，以允许高优先级任务在负载尖峰扩容)等。

调度器使用一份缓存的 Cell 状态拷贝，重复执行下面的操作:

从选举出来的 Master 获取状态变更(包括已分配的和等待中的工作);更新自己的本地拷贝。
执行一轮调度来分配任务;将分配信息发送给 Master。
Master 会接受并应用这些分配，但如果分配不适合(例如，是基于过时的状态做出的)，就会等待调度器的下一轮调度。

其他

文中还提到了如何提供售卖率以及性能争抢的问题，不过不是本文重点，可以参考一下原文。

Reference

https://www.cnblogs.com/hellojamest/p/16526159.html

Percolator: Large-scale Incremental Processing Using Distributed Transactions and Notifications

Thu, 28 Sep 2023 10:43:23 +0800

好久没学习了，学点想学的。本次内容是分布式事务Percolator, 不翻译论文，没有算法细节，只记录自己的理解。

Percolator 和 2PC

2PC

两阶段提交协议中包含两种角色，Coordinator和Participant。协调者负责整个协议的推进，使得多个参与者最终达到一致的决议。参与者响应协调者的请求，根据协调者的请求完成 prepare 操作及 commit/abort 操作。

2PC协议保证事务的原子性(ACD)，并未对隔离性(I)做任何实现，依赖单机事务(ACD)。Coordinator，显然是关键路径，可能成为单点瓶颈，或者宕机问题阻塞事务流程。

text

 协调者 参与者
QUERY TO COMMIT
-------------------------------->
VOTE YES/NO prepare*/abort*
<-------------------------------
commit*/abort* COMMIT/ROLLBACK
-------------------------------->
ACKNOWLEDGMENT commit*/abort*
<--------------------------------
end

Percolator

本身其实算一种经过优化的二阶段提交的实现，比如：

对锁的使用进行优化，引入Primary-Secondary二级锁，去除了对Coordinator的依赖。
提供了完整的ACID事务语义实现，并且支持MVCC（依赖时间戳服务）

Percolator协议细节

Percolator系统主要有三部分组成：

Client，发起事务的客户端，Client 是整个协议的控制中心，是两阶段提交的协调者（Coordinator）。
TO，Time Observer，分配时间戳，提供全局唯一且递增的时间戳，实现MVCC
Bigtable，提供单机单行事务，数据存储在Bigtable中，包含数据本身以及附带的一些属性。

lock + write + data: for transaction，lock表示cell被事务持有，write表示数据的可见性

notify + ack: for watcher or notifier

从外部看，Percolator以SDK的提供给业务方使用。提供事务以及R/W。模型类似于 Begin Txn → Sets of RW Operations → Commit or About or Rollback其中Bigtable最为持久化组件屏蔽了底层Tablet Server Data Sharding的细节，事务中的每一个写操作或者读后写（统称为Write）操作都视为分布式事务的参与者，而这些操作最后可能会分派到多个Tablet Server节点上。

算法流程

一个事务的所有 Write 在提交之前都会先缓存在 Client，然后在提交阶段一次性写入；Percolator 的事务提交是标准的两阶段提交，分为 Prewrite 和 Commit 。

Prewrite

从TO获取一个时间戳，作为事务的开始时间。
给数据上锁，标记数据被当前事务占有。上锁失败则表示数据被其他事物占有，当前事物失败。

上锁过程利用了Primary-Secondary机制，选择一个 Write 作为 primary，其它 Write 则是 secondary。Secondary的锁记录指向Primary。

显然，Prewrite阶段的数据对其他事务均不可见。

Commit

尝试对Prewrite中的数据进行Commit。Commit的时候先对Primary记录进行Commit，Primary记录的提交时间将作为整个事务的提交时间。首先对记录的锁记录进行检测，如果锁不存在，则表示Prewrite阶段的锁被其他事物清理，则事物执行失败。如果存在，则写记录中的write列，表示数据对系统可见。

异步网络之中，单节点故障，网络延迟很常见。算法需要在发现这些故障的时候，清理掉这些锁记录，避免死锁。所以，在Commit阶段，如果锁不存在，则表示事务的参与者发生了问题当前事务需要被清理。

提交成功之后对锁记录进行清理。显然，锁清理也是可以异步的。

这些设计使得算法去除了中心化Coordinator的依赖。因为过去需要依赖这个中心服务来维护事务各个参与者的信息。而在本算法中，利用Primary-Secondary二级锁以及Write列就可以实现。Write列表示数据对外的可见性以及数据版本链条。Lock列表示数据被事务持有。Primary-Secondary记录了参与者的逻辑从属关系。这样的设计使得Primary记录的提交变成了整个事务的提交点。一但Primary被提交，所有的Secondary记录可以通过检查对应Primary记录的Write列来进行异步提交。

Snapshot Isolation

两阶段提交解决的是事务的原子性。在此基础上，Percolator还提供了Snapshot Isolation的隔离性。简而言之，Snapshot Isolation要求提交的事务不能导致数据冲突，事务的读操作满足Snapshot Read。利用事务开始时间以及Primary记录的提交时间，可以维护一个事务之间的全序关系，这些问题自然就可以解决了。

异步网络的死锁问题

之前提到，异步网络之中，单节点故障，网络延迟很常见。算法需要在发现这些故障的时候，清理掉这些锁记录，避免死锁。故障检测的策略可以很简单，比如超时，故障会导致当前事务失败；节点故障又恢复正常，当时的事务已经失败，则此时需要对节点上相关锁记录进行清理。锁的清理可以异步化，比如在Prewrite上锁时，当发现记录Lock列非空，则去检测其Primary锁是否为空，Primary非空，则表示这个事务为完成，可以清理；为空则表示事务提交，则去找到事务提交时间，并把数据提交，再清理锁记录（RollForward）。

通知机制

通知机制对于异步系统的状态观测和联动很重要。但不是本文重点。

Percolator在TiDB上的使用

基于我们上文的分析，我们可以得出这样的结论：Percolator是一种优化过的2PC分布式事务实现，实现的基础是支持单机事务的存储引擎。

让我们来简单看看TiDB的的基于Percolator算法实现分布式事务。

TiDB和TiKV架构如上。TiDB关系表里的数据最终都被映射到了TiKV中的KV中。TiKV是一个基于Raft+RocksDB的分布式KV。RocksDB是一个支持事务操作的KV。

所以TiDB的事务的执行路径可以是这样：对关系表的事务操作转为对一组KV的事务操作，再基于Percolator去执行，以此实现关系表的事务操作。

当然不可能提供和单机TP数据库一样的事务语义和性能保证。但Share Nothing架构也有自己的优点，所以这个也许并不重要。

参考

两阶段提交的工程实践

PolarDB 数据库内核月报

percolator：在线增量处理系统中文翻译

percolator：在线增量处理系统中文翻译 | 一只小小鸟

二阶段提交 - 维基百科，自由的百科全书

Percolator 和 TiDB 事务算法

两阶段提交 | OceanBase 学习指南

TiDB 整体架构

Dynamo: Amazon’s Highly Available Key-value Store

Tue, 01 Aug 2023 16:15:29 +0800

一篇AWS的老文章，Dynamo到现在已经售卖了很久了，架构应该也早已不像论文中描述的这样。但文章入选了某年的sigmod best paper，依旧是有很多值得学习的地方。

设计

Dynamo是一种NoSQL产品，对外提供KV存储语义。在产品定义上强调Highly Available而非Consistency，所以在架构设计以及技术选型上和其他的产品还是有很多不同之处。

技术

在技术上，Dynamo其实有很多有问题的地方，比如NWR算法本身的一些。但考虑到Dynamo已经经过了很长时间的验证，也许这些问题已经被很好的解决了，只不过论文中语焉不详。所以暂且放下这些，挑一些来说一说。其中我认为值得拿出来说的主要有这几块：

数据的分区

一致性hash算法。传统的一致性hash算法使用hash ring来解决增减节点rehash范围大的问题，但比如数据倾斜，以及异构机器导致的性能倾斜这类问题是无法避免的。 Dynamo实践上，在原有hash ring上引入了虚拟节点，比较优雅的解决了这两个问题。

数据写入问题

一般存储系统会在写的同时保证一定的数据一致性，换取较低的读操作复杂度，代价上写性能降低（延迟等）。但Dynamo选择了另一条路线。 Dynamo的设计目标是提供一个高可用的KV Store，保证always writable，同时只保证最终的一致性。这样的目标使得Dynamo把解决数据冲突之类的操作放到了读操作中，以保证写永远不会被拒绝。总的来说，问题有两个。一个是数据更新冲突问题，显然多client并发的读写同一个Key很容易遇到这样的问题，因为Dynamo只能提供最终一致性，Dynamo Ring 上多个节点的数据不一定一致。二是节点数据空洞的问题。因为Dynamo使用的是NMR这类的gossip算法，这类理论上会出现所有节点上都不包含完整数据集的情况，需要同步副本之间的数据。前者使用版本时钟来标记数据版本，后续在读操作的时候进行读修复合并数据版本；后者有熵逆过程来处理，使用MerkleTree来快速检测副本之间的不一致性，以及最小化转移的数据量。 论文中的这个表格可以清楚的看出Dynamo设计开发需要考虑的方面以及在技术上的选择。剩下这些论文中感觉语焉不详，可以参考原文。

参考

Dynamo 的实现技术和去中心化

Dynamo一个缺陷的架构设计(译) – 后端技术 by Tim Yang

Dynamo: A flawed architecture | Hacker News

MIT6.824 AuroraDB

Tue, 01 Aug 2023 16:11:54 +0800

这篇文章介绍了AWS的数据库产品Aurora的设计考虑，包括存算分离、一写多读、基于Quorum的NRW一致性协议等。同时，文章也提到了PolarDB参考Aurora进行设计，但在网络瓶颈和系统调用方面有所不同。

Aurora是AWS提供的一种数据库产品，主要面向OLTP的业务场景。

设计上，我觉得有这些值得参考的地方：

Aurora设计的前提是，在数据库上云之后，得益于云基础设施的发展，数据库最大的瓶颈从计算和存储变成了网络，这是AWS在设计Aurora的时候一个很重要的前提。基于此前提，Aurora重提Log is Database的论调，只将RedoLog下推至存储层。
存算分离。数据库存储层对接分布式存储底座，通过存储底座提供良好的可靠性和安全性保证。计算和存储层可以独立拓展。同时，存储底座对上层提供的单一数据视图，使得一些核心功能和运维操作效率得到很好的提升（比如备份，数据恢复，HA等）
一些有意思的可靠性保证。比如基于Quorum的NRW一致性协议，存储节点读写都需要多数派的投票。保证双AZ级别的容错；用分片存储减少故障处理时间，以此提升SLA。多数读只发生在数据库恢复的时候，此时数据库需要恢复当前的状态。
一写多读。不同于ShareNothing架构的NewSQL产品，Aurora只提供了单个写节点。数据一致性保证也因此变得简单，因为单写节点可以通过RedoLog LSN作为逻辑时钟，以此维护数据更新操作的偏序关系，只需要把RedoLog下推至所有节点，并基于此顺序对这些操作Apply就可以保证数据的一致性。
事务的实现。由于存储底座对上层提供的单一文件视图，所以对与Aurora来说，其事务的实现几乎与单机事务算法相同，并能提供相同的事务语义。NewSQL的事务一般是基于2PC的分布式事务实现。
后台加速前台处理。类似LevelDB的思路，尽可能将存储节点的一些操作异步化（比如日志Apply），提升前台用户感知性能。这些异步的操作通过维护各种xxLSN来记录当前节点的后台处理进度，比如VLSN，commit-LSN等等

有趣的是，PolarDB虽然是参考Aurora进行的设计，但它的架构设计认为网络并非瓶颈，而是经过OS的各种系统调用拖慢了整体速度。在彼时阿里云存储底座并不稳定的条件下，所以才有了它架构中的PolarStore，用各种硬件以及FUSE等存储技术越过或者优化系统调用，而如今盘古在稳定性和性能上都做的很不错的情况下，弱化PolarStore这个组件也成为了正常的选择。我认为说的不无道理。

另外，为什么他们选择用NWR而不是用Raft之类的一致性协议？目前看上去，NWR在网络上，一次请求的网络比Raft少一轮，可能是这个原因

参考

https://zhuanlan.zhihu.com/p/319806107

http://nil.csail.mit.edu/6.824/2020/notes/l-aurora.txt

论文阅读-Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Database - keys961 | keys961 Blog

MIT6.824-ChainReplication

Wed, 08 Feb 2023 23:05:57 +0800

只是简单写写，有一些具体一点的设计建议去读一下原文。

简介

简单来讲，CR论文介绍了一种用于存储服务的满足线性一致性的复制状态机算法。它通过链式复制来提高算法的吞吐量，通过多副本来保证服务的可用性。

算法的设计很简单巧妙。算法通过链式复制将复制的吞吐均分到所有的CR节点上，每个节点只负责对后续节点的复制。写入请求从头部节向后传播，查询请求交由尾部节点响应。

为了维护Chain上节点之前的前后关系，CR还引入了一个Master服务，用于管理节点之间的关系，以及处理Node Failure的情况。

故障处理

Head Fail：头节点Pending or 没处理完的请求将被丢失，不影响线性一致性，之后将第二个节点设置为头结点
Tail Fail：倒数第二个节点将成为尾节点，此时原来Tail Pending的请求将被提交
Middle Fail：中间节点故障的处理，类比链表的操作。Node_pre 将指向 Node_next，此时我们需要保证故障Node传递的请求被完整的传递下去。每个CR节点会维护一个SendReqList，记录已传递给后续节点的请求，由于请求是从头到尾传播，所以Node_pre只需要Node_next所缺失的数据即可。当Tail接收到请求时，标识数据被提交，此时会从尾至头传递Ack(req)信息，经过的节点都会把req从SendReqList从去除。

优缺点

最大的优点是，可以单节点提高吞吐量，节点的负载比较均衡，同时相对易于实现。整体设计很简洁有效。

但很明显也会有以下缺点。

如果传播链条上有一个节点处理慢，将会拖慢整个处理流程。
除了首尾两个节点，其他节点的数据基本只作为副本存在，而无法提供服务。当然CRAQ里有让中间节点提供只读服务的方法，类似Raft的Read Index，暂不细说。

参考

Chain Replication 论文阅读

CR Paper

MIT6.824-ZooKeeper

Tue, 03 Jan 2023 23:49:41 +0800

本文主要讲了ZooKeeper系统在设计和实践上的考量，如wait-free和lock，一致性的选择，系统提供的API以及特定语义上的抉择，这样的trade-off是本文的最大启发。

定位

wait-free,high-performance 的协调分布式应用的系统。通过提供协调原语（特定语义的API与数据模型）支持分布式应用的协调需求。

设计

关键词

ZK定位中的关键词有两个：高性能，分布式应用协调服务。

ZK的高性能通过WaitFree设计、多副本本地读、Watch机制实现。

WaitFree应该是将请求异步处理来实现的，这样异步处理可能会导致请求重排序，导致状态机和现实的时序不同，所以ZK提供了FIFO Client Order 顺序保证。同时，这样的异步处理有益于数据的batch pipeline处理，进一步提升性能。
Watch机制，当znode变化是通知Client更新，避免Client操作本地缓存的开销。
多副本本地读，ZK使用ZAB协议实现数据共识，保证写操作满足linearizability。读请求副本本地读，不走ZAB共识协议，但读请求只满足Serializaility，可能会读到之前的结果，但提升了性能。

分布式应用协调服务指的是，ZK提供的数据模型以及API语义，分布式应用可以自由使用来满足诸如Group Membership，Distributed Lock等协调需求。

数据模型与API

ZK为使用者提供znode数据节点的抽象，数据节点通过分层的命名空间组织。ZK提供了Regular + Ephemeral两种znode的节点的创建，每个节点都存储数据，并通过标准的UNIX文件系统路径访问。

实际上，znodes 不是为通用数据存储设计的。相反，znodes 映射到客户端应用程序的抽象，通常与用于协调的元数据相对应。

也就是说，使用ZK进行协调时，利用好znode关联的元数据，而不是只将znode当做数据存储。比如，znode 将元数据与时间戳(timestamp)和版本计数器( version counter )关联，客户端可以跟踪对 znode 的更改并根据 znode 的版本执行条件更新。

这套数据模型本质上是一个简化API的文件系统，只支持完整数据的读写。使用者将在ZK提供的语义下实现分布式应用的协调。

Regular 和 Ephemeral 的区别在于Ephemeral可以在Session结束时自动删除。

Client通过API与ZK交互，ZK通过Session管理Clinet连接，在Session中Clinet可以观测到反应其操作的状态变化。

CAP

ZK保证CP，比如在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务。

实现

ZK使用多副本实现高可用。

简单来说，ZK上层使用ZAB协议处理写请求，保证多副本更新的线性一致性，本地处理读请求，读请求保证顺序一致性。下层数据状态机保存到ZK集群机器上的Replicated Database（内存）+ WAL上，并定期snapshot。整个内存数据库通过 Fuzzy Snapshot + WAL Replay的方式保证单机Crash Safe以及重启恢复的速度。

Fuzzy Snapshot 的优势在于不阻塞在线请求。

与Client的交互

更新操作会通知并清除相关znode的Watch。
读请求本地进行，通过zxid定义与写请求的偏序关系，只保证顺序一致性，可能会Read Stale。ZK提供了sync操作，通过 sync + read 一定程度上解决了这个问题。
当Client连接新ZK Server时，会对比两者的最大zxid，落后的ZK Server将不会为Client建立Session。
Client通过心跳维持Session，Server对请求进行幂等处理。

参考

ZooKeeper Paper

MIT6.824-ZooKeeper FAQ

Flink-Iceberg-Connector写入流程

Mon, 10 Oct 2022 10:43:38 +0800

Iceberg社区提供了Flink Connector的官方实现，本章源码阅读正是基于此。

写入提交流程总览

Flink 通过 RowData -> distributeStream -> WriterStream -> CommitterStream，在写入数据提交之前，数据以中间文件形式存在，提交之后对系统可见（写入manifest + snapshot + metadata，数据文件对外部可见）

java


 private <T> DataStreamSink<T> chainIcebergOperators() {
 Preconditions.checkArgument(inputCreator != null,
 "Please use forRowData() or forMapperOutputType() to initialize the input DataStream.");
 Preconditions.checkNotNull(tableLoader, "Table loader shouldn't be null");

 DataStream<RowData> rowDataInput = inputCreator.apply(uidPrefix);

 if (table == null) {
 tableLoader.open();
 try (TableLoader loader = tableLoader) {
 this.table = loader.loadTable();
 } catch (IOException e) {
 throw new UncheckedIOException("Failed to load iceberg table from table loader: " + tableLoader, e);
 }
 }

 // Find out the equality field id list based on the user-provided equality field column names.
 List<Integer> equalityFieldIds = checkAndGetEqualityFieldIds();

 // Convert the requested flink table schema to flink row type.
 RowType flinkRowType = toFlinkRowType(table.schema(), tableSchema);

 // Distribute the records from input data stream based on the write.distribution-mode and equality fields.
 DataStream<RowData> distributeStream = distributeDataStream(
 rowDataInput, table.properties(), equalityFieldIds, table.spec(), table.schema(), flinkRowType);

 // Add parallel writers that append rows to files
 SingleOutputStreamOperator<WriteResult> writerStream = appendWriter(distributeStream, flinkRowType,
 equalityFieldIds);

 // Add single-parallelism committer that commits files
 // after successful checkpoint or end of input
 SingleOutputStreamOperator<Void> committerStream = appendCommitter(writerStream);

 // Add dummy discard sink
 return appendDummySink(committerStream);
 }

写入流程源码分析

WriteStream

java


 private SingleOutputStreamOperator<WriteResult> appendWriter(DataStream<RowData> input, RowType flinkRowType,
 List<Integer> equalityFieldIds) {

 // Fallback to use upsert mode parsed from table properties if don't specify in job level.
 boolean upsertMode = upsert || PropertyUtil.propertyAsBoolean(table.properties(),
 UPSERT_ENABLED, UPSERT_ENABLED_DEFAULT);

 // Validate the equality fields and partition fields if we enable the upsert mode.
 if (upsertMode) {
 Preconditions.checkState(!overwrite,
 "OVERWRITE mode shouldn't be enable when configuring to use UPSERT data stream.");
 Preconditions.checkState(!equalityFieldIds.isEmpty(),
 "Equality field columns shouldn't be empty when configuring to use UPSERT data stream.");
 if (!table.spec().isUnpartitioned()) {
 for (PartitionField partitionField : table.spec().fields()) {
 Preconditions.checkState(equalityFieldIds.contains(partitionField.sourceId()),
 "In UPSERT mode, partition field '%s' should be included in equality fields: '%s'",
 partitionField, equalityFieldColumns);
 }
 }
 }

 IcebergStreamWriter<RowData> streamWriter = createStreamWriter(table, flinkRowType, equalityFieldIds, upsertMode);

 int parallelism = writeParallelism == null ? input.getParallelism() : writeParallelism;
 SingleOutputStreamOperator<WriteResult> writerStream = input
 .transform(operatorName(ICEBERG_STREAM_WRITER_NAME), TypeInformation.of(WriteResult.class), streamWriter)
 .setParallelism(parallelism);
 if (uidPrefix != null) {
 writerStream = writerStream.uid(uidPrefix + "-writer");
 }
 return writerStream;
 }

WriterStream流算子由distriteStream转换而来，以RowData作为输入，WriteResult作为输出，其中转换的逻辑封装在IcebergStreamWriter对象中，处理逻辑见processElement。

java


 private transient TaskWriter<T> writer;
 @Override
 public void processElement(StreamRecord<T> element) throws Exception {
 writer.write(element.getValue());
 }

IcebergStreamWriter将数据的写入委托给TaskWriterFactory（RowDataTaskWriterFactory）创建的TaskWriter（如PartitionedDeltaWriter，UnpartitionedWriter）执行。

java


 public TaskWriter<RowData> create() {
 Preconditions.checkNotNull(outputFileFactory,
 "The outputFileFactory shouldn't be null if we have invoked the initialize().");

 if (equalityFieldIds == null || equalityFieldIds.isEmpty()) {
 // Initialize a task writer to write INSERT only.
 if (spec.isUnpartitioned()) {
 return new UnpartitionedWriter<>(spec, format, appenderFactory, outputFileFactory, io, targetFileSizeBytes);
 } else {
 return new RowDataPartitionedFanoutWriter(spec, format, appenderFactory, outputFileFactory,
 io, targetFileSizeBytes, schema, flinkSchema);
 }
 } else {
 // Initialize a task writer to write both INSERT and equality DELETE.
 if (spec.isUnpartitioned()) {
 return new UnpartitionedDeltaWriter(spec, format, appenderFactory, outputFileFactory, io,
 targetFileSizeBytes, schema, flinkSchema, equalityFieldIds, upsert);
 } else {
 return new PartitionedDeltaWriter(spec, format, appenderFactory, outputFileFactory, io,
 targetFileSizeBytes, schema, flinkSchema, equalityFieldIds, upsert);
 }
 }
 }TaskWriterFactory

TaskWriter又将写入交给RollingWriter（BaseRollingWriter）执行。

java


 public void write(T row) throws IOException {
 PartitionKey partitionKey = partition(row);

 RollingFileWriter writer = writers.get(partitionKey);
 if (writer == null) {
 // NOTICE: we need to copy a new partition key here, in case of messing up the keys in writers.
 PartitionKey copiedKey = partitionKey.copy();
 writer = new RollingFileWriter(copiedKey);
 writers.put(copiedKey, writer);
 }

 writer.write(row);
 }

RollingWriter会持有一个OutputFileFactory生成的OutputFile作为写入文件，并根据一些策略自动切换的新的OutputFile文件.

java


 public void write(T record) throws IOException {
 write(currentWriter, record);
 this.currentRows++;

 if (shouldRollToNewFile()) {
 closeCurrent();
 openCurrent();
 }
 }

java


 private void openCurrent() {
 if (partitionKey == null) {
 // unpartitioned
 this.currentFile = fileFactory.newOutputFile();
 } else {
 // partitioned
 this.currentFile = fileFactory.newOutputFile(partitionKey);
 }
 this.currentWriter = newWriter(currentFile, partitionKey);
 this.currentRows = 0;
 }

OutputFile的命名规则是

LocationProvider.newLocation(partitionId+taskId+operationId+fileCountID+ext)

RollingWriter会把写入交个AppenderFactory构造的DataWriter，对于Flink，默认的DataWriter是ParquetDataWriter。ParquetDataWriter根据不同的数据类型委托给不同的ParquertValueWriter

java


 DataWriter<T> newWriter(EncryptedOutputFile file, StructLike partitionKey) {
 return appenderFactory.newDataWriter(file, format, partitionKey);
 }

java


@Override
public DataWriter<RowData> newDataWriter(EncryptedOutputFile file, FileFormat format, StructLike partition) {
return new DataWriter<>(
 newAppender(file.encryptingOutputFile(), format), format,
 file.encryptingOutputFile().location(), spec, partition, file.keyMetadata());
}

@Override
 public FileAppender<RowData> newAppender(OutputFile outputFile, FileFormat format) {
 MetricsConfig metricsConfig = MetricsConfig.fromProperties(props);
 try {
 switch (format) {
 case AVRO:
 return Avro.writer...
 case ORC:
 return ORC.writer...
 case PARQUET:
 return Parquet.writer...
 default:
 throw new UnsupportedOperationException("Cannot write unknown file format: " + format);
 }
 } catch (IOException e) {
 throw new UncheckedIOException(e);
 }
 }

CommitterStream

CommitterStream 接受 WriteResult 作为输入，无结果输出。WriteResult包含了WriteStream中产生的数据文件。

java


public class WriteResult implements Serializable {
 private DataFile[] dataFiles;
 private DeleteFile[] deleteFiles;
 private CharSequence[] referencedDataFiles;
 ...
}

处理数据文件提交的核心逻辑封装在IcebergFilesCommitter.IcebergFlieCommitter用一个List（writeResultsOfCurrentCkpt）维护正在处理的Ckpt的需要提交的文件集合，用一个SortedMap（dataFilesPerCheckpoint）维护了系统当前Snapshot中所有Ckpt中提交的文件信息，用List of SortedMap 维护了系统所有的Snapshot的文件提交信息。

java


class IcebergFilesCommitter extends AbstractStreamOperator<Void>
 implements OneInputStreamOperator<WriteResult, Void>, BoundedOneInput {
 ...

 // A sorted map to maintain the completed data files for each pending checkpointId (which have not been committed
 // to iceberg table). We need a sorted map here because there's possible that few checkpoints snapshot failed, for
 // example: the 1st checkpoint have 2 data files <1, <file0, file1>>, the 2st checkpoint have 1 data files
 // <2, <file3>>. Snapshot for checkpoint#1 interrupted because of network/disk failure etc, while we don't expect
 // any data loss in iceberg table. So we keep the finished files <1, <file0, file1>> in memory and retry to commit
 // iceberg table when the next checkpoint happen.
 private final NavigableMap<Long, byte[]> dataFilesPerCheckpoint = Maps.newTreeMap();

 // The completed files cache for current checkpoint. Once the snapshot barrier received, it will be flushed to the
 // 'dataFilesPerCheckpoint'.
 private final List<WriteResult> writeResultsOfCurrentCkpt = Lists.newArrayList();

 private transient ListState<SortedMap<Long, byte[]>> checkpointsState;
 ...
 }

java


 @Override
 public void processElement(StreamRecord<WriteResult> element) {
 this.writeResultsOfCurrentCkpt.add(element.getValue());
 }

上游的当前checkpoint的WriteResult一个writeResultsOfCurrentCkpt中。在SnapshotState的时候writeResultsOfCurrentCkpt -> dataFilesPerCheckpoint -> checkpointsState提交。之后通过notifyCheckpointComplete通知Ckpt完成，并将其提交。

java


public void snapshotState(StateSnapshotContext context) throws Exception {
 super.snapshotState(context);
 long checkpointId = context.getCheckpointId();
 LOG.info("Start to flush snapshot state to state backend, table: {}, checkpointId: {}", table, checkpointId);

 // Update the checkpoint state.
 dataFilesPerCheckpoint.put(checkpointId, writeToManifest(checkpointId));
 // Reset the snapshot state to the latest state.
 checkpointsState.clear();
 checkpointsState.add(dataFilesPerCheckpoint);

 jobIdState.clear();
 jobIdState.add(flinkJobId);

 // Clear the local buffer for current checkpoint.
 writeResultsOfCurrentCkpt.clear();
 }

 @Override
 public void notifyCheckpointComplete(long checkpointId) throws Exception {
 super.notifyCheckpointComplete(checkpointId);
 // It's possible that we have the following events:
 // 1. snapshotState(ckpId);
 // 2. snapshotState(ckpId+1);
 // 3. notifyCheckpointComplete(ckpId+1);
 // 4. notifyCheckpointComplete(ckpId);
 // For step#4, we don't need to commit iceberg table again because in step#3 we've committed all the files,
 // Besides, we need to maintain the max-committed-checkpoint-id to be increasing.
 if (checkpointId > maxCommittedCheckpointId) {
 commitUpToCheckpoint(dataFilesPerCheckpoint, flinkJobId, checkpointId);
 this.maxCommittedCheckpointId = checkpointId;
 }
 }

提交逻辑在commitUpToCheckpoint函数中。Iceberg抽象除了SnapshotUpdate接口处理Snapshot的变更。Iceberg使用乐观策略处理提交时的Snapshot并发冲突。当发生并发提交冲突时，会重试commit操作。每次commit都会基于当前最新的metadata产生一个新的Snapshot 对象，将其添加到新的Metadata中，最后尝试通过TableOperation.commit进行提交。

java


 public void commit() {
 // this is always set to the latest commit attempt's snapshot id.
 AtomicLong newSnapshotId = new AtomicLong(-1L);
 try {
 Tasks.foreach(ops)
 .retry(base.propertyAsInt(COMMIT_NUM_RETRIES, COMMIT_NUM_RETRIES_DEFAULT))
 .exponentialBackoff(
 base.propertyAsInt(COMMIT_MIN_RETRY_WAIT_MS, COMMIT_MIN_RETRY_WAIT_MS_DEFAULT),
 base.propertyAsInt(COMMIT_MAX_RETRY_WAIT_MS, COMMIT_MAX_RETRY_WAIT_MS_DEFAULT),
 base.propertyAsInt(COMMIT_TOTAL_RETRY_TIME_MS, COMMIT_TOTAL_RETRY_TIME_MS_DEFAULT),
 2.0 /* exponential */)
 .onlyRetryOn(CommitFailedException.class)
 .run(taskOps -> {
 Snapshot newSnapshot = apply(); // generate a new snapshot based on new added data file and manifest,manifest list
 newSnapshotId.set(newSnapshot.snapshotId());
 TableMetadata.Builder update = TableMetadata.buildFrom(base);
 if (base.snapshot(newSnapshot.snapshotId()) != null) {
 // this is a rollback operation
 update.setBranchSnapshot(newSnapshot.snapshotId(), SnapshotRef.MAIN_BRANCH);
 } else if (stageOnly) {
 update.addSnapshot(newSnapshot);
 } else {
 update.setBranchSnapshot(newSnapshot, SnapshotRef.MAIN_BRANCH);
 }

 TableMetadata updated = update.build();
 if (updated.changes().isEmpty()) {
 // do not commit if the metadata has not changed. for example, this may happen when setting the current
 // snapshot to an ID that is already current. note that this check uses identity.
 return;
 }

 // if the table UUID is missing, add it here. the UUID will be re-created each time this operation retries
 // to ensure that if a concurrent operation assigns the UUID, this operation will not fail.
 taskOps.commit(base, updated.withUUID()); // commit table metadata, may cause commit failure
 });

 } catch (CommitStateUnknownException commitStateUnknownException) {
 throw commitStateUnknownException;
 } catch (RuntimeException e) {
 Exceptions.suppressAndThrow(e, this::cleanAll);
 }

 try {
 LOG.info("Committed snapshot {} ({})", newSnapshotId.get(), getClass().getSimpleName());

 // at this point, the commit must have succeeded. after a refresh, the snapshot is loaded by
 // id in case another commit was added between this commit and the refresh.
 Snapshot saved = ops.refresh().snapshot(newSnapshotId.get());
 if (saved != null) {
 cleanUncommitted(Sets.newHashSet(saved.allManifests(ops.io())));
 // also clean up unused manifest lists created by multiple attempts
 for (String manifestList : manifestLists) {
 if (!saved.manifestListLocation().equals(manifestList)) {
 deleteFile(manifestList);
 }
 }
 } else {
 // saved may not be present if the latest metadata couldn't be loaded due to eventual
 // consistency problems in refresh. in that case, don't clean up.
 LOG.warn("Failed to load committed snapshot, skipping manifest clean-up");
 }

 } catch (Throwable e) {
 LOG.warn("Failed to load committed table metadata or during cleanup, skipping further cleanup", e);
 }

 try {
 notifyListeners();
 } catch (Throwable e) {
 LOG.warn("Failed to notify event listeners", e);
 }
 }

java


private void commitUpToCheckpoint(NavigableMap<Long, byte[]> deltaManifestsMap,
 String newFlinkJobId,
 long checkpointId) throws IOException {
 NavigableMap<Long, byte[]> pendingMap = deltaManifestsMap.headMap(checkpointId, true);
 List<ManifestFile> manifests = Lists.newArrayList();
 NavigableMap<Long, WriteResult> pendingResults = Maps.newTreeMap();
 for (Map.Entry<Long, byte[]> e : pendingMap.entrySet()) {
 if (Arrays.equals(EMPTY_MANIFEST_DATA, e.getValue())) {
 // Skip the empty flink manifest.
 continue;
 }

 DeltaManifests deltaManifests = SimpleVersionedSerialization
 .readVersionAndDeSerialize(DeltaManifestsSerializer.INSTANCE, e.getValue());
 pendingResults.put(e.getKey(), FlinkManifestUtil.readCompletedFiles(deltaManifests, table.io()));
 manifests.addAll(deltaManifests.manifests());
 }

 int totalFiles = pendingResults.values().stream()
 .mapToInt(r -> r.dataFiles().length + r.deleteFiles().length).sum();
 continuousEmptyCheckpoints = totalFiles == 0 ? continuousEmptyCheckpoints + 1 : 0;
 if (totalFiles != 0 || continuousEmptyCheckpoints % maxContinuousEmptyCommits == 0) {
 if (replacePartitions) {
 replacePartitions(pendingResults, newFlinkJobId, checkpointId);
 } else {
 commitDeltaTxn(pendingResults, newFlinkJobId, checkpointId);
 }
 continuousEmptyCheckpoints = 0;
 }
 pendingMap.clear();

 // Delete the committed manifests.
 for (ManifestFile manifest : manifests) {
 try {
 table.io().deleteFile(manifest.path());
 } catch (Exception e) {
 // The flink manifests cleaning failure shouldn't abort the completed checkpoint.
 String details = MoreObjects.toStringHelper(this)
 .add("flinkJobId", newFlinkJobId)
 .add("checkpointId", checkpointId)
 .add("manifestPath", manifest.path())
 .toString();
 LOG.warn("The iceberg transaction has been committed, but we failed to clean the temporary flink manifests: {}",
 details, e);
 }
 }
 }

java


public void commit(TableMetadata base, TableMetadata metadata) {
 // if the metadata is already out of date, reject it
 if (base != current()) {
 if (base != null) {
 throw new CommitFailedException("Cannot commit: stale table metadata");
 } else {
 // when current is non-null, the table exists. but when base is null, the commit is trying to create the table
 throw new AlreadyExistsException("Table already exists: %s", tableName());
 }
 }
 // if the metadata is not changed, return early
 if (base == metadata) {
 LOG.info("Nothing to commit.");
 return;
 }

 long start = System.currentTimeMillis();
 doCommit(base, metadata);
 deleteRemovedMetadataFiles(base, metadata);
 requestRefresh();

 LOG.info("Successfully committed to table {} in {} ms",
 tableName(),
 System.currentTimeMillis() - start);
 }

写入问题

就以上写入以及提交流程，最大的问题有两个：

Lots of Small File

对于流式写入，每次都会生成新的文件。这就会产生大量的小文件。小文件在对象存储其实支持比较好。但是大量的小文件可能会带来Iceberg 元数据读取和更新的额外开销，因为这些数据文件的信息都需要靠iceberg元数据文件中维护，大量的小文件可能导致元数据文件的膨胀，导致读取元数据文件时的处理时间增加。如何解决？

Iceberg Rewrite Action：支持Rewrite Data 和 Metadata 需要Flink / Spark Action 触发
snapshot 过期删除, 支持配置

java


import org.apache.iceberg.flink.actions.Actions;

TableLoader tableLoader = TableLoader.fromHadoopTable("hdfs://nn:8020/warehouse/path");
Table table = tableLoader.loadTable();
RewriteDataFilesActionResult result = Actions.forTable(table)
 .rewriteDataFiles()
 .execute();

https://iceberg.apache.org/docs/latest/flink/https://iceberg.apache.org/docs/latest/maintenance/

高并发写入时的性能问题

Iceberg的写入会导致产生新的snapshot，并使用乐观并法策略处理并法冲突，冲突的提交将被重试。高并发写入场景下，并发冲突会导致很多提交snapshot的请求被重试，会有性能损失。

在准备提交snapshot前，iceberg会读取以前的快照然后创建新的快照，这个过程十分耗时，并且耗时会随着元数据增加而增加。

如何解决？

Batch Commit : 引入缓存层或者一个额外的服务，批量提交到数据湖，降低提交操作并发度。同时缓存层也许可以对多次的数据文件进行compact

https://zhuanlan.zhihu.com/p/472617094 https://www.infoq.cn/article/hfft7c7ahoomgayjsouz

Flink Iceberg Connector不支持隐藏分区，也不支持分区字段预处理。

Apache-ORC调研

Wed, 05 Oct 2022 19:56:01 +0800

iceberg支持ORC和Parquat两种列存格式。相比于Parquat，ORC在查询性能以及ACID支持方面具有一定的优势。于是考虑到后续湖仓查询性能以及数据湖的ACID需求，现对ORC进行调研，以支持后续Flink+iceberg+orc的demo测试。

调研重点：ORC文件的编码以及文件组织方式，索引支持。

File Layout

一个ORC文件总体上可以分为三大部分：

Header：标识文件的类型
Body：包含Row Data和Indexes，如下图
Tail：包含文件级别的信息

ORC Specification v1

File Tail

由于现在的分布式存储一般只提供AppendOnly语义，ORC 文件在文件的尾部有一块区域，用于维护文件级别（Top Level）的信息。 source code

The sections of the file tail are (and their protobuf message type):

encrypted stripe statistics: list of ColumnarStripeStatistics

stripe statistics: Metadata

footer: Footer

postscript: PostScript

psLen: byte

postscript

不允许被压缩，包含了解析文件尾部所需要的信息，比如：Footer和Metadata区域的长度，压缩方法等

protobuf


message PostScript {
 // the length of the footer section in bytes
 optional uint64 footerLength = 1;
 // the kind of generic compression used
 optional CompressionKind compression = 2;
 // the maximum size of each compression chunk
 optional uint64 compressionBlockSize = 3;
 // the version of the writer
 repeated uint32 version = 4 [packed = true];
 // the length of the metadata section in bytes
 optional uint64 metadataLength = 5;
 // the fixed string "ORC"
 optional string magic = 8000;
}

...

enum CompressionKind {
 NONE = 0;
 ZLIB = 1;
 SNAPPY = 2;
 LZO = 3;
 LZ4 = 4;
 ZSTD = 5;
}

Footer包含了文件的schema信息，文件的行数，列级别的统计信息

protobuf


message Footer {
 // the length of the file header in bytes (always 3)
 optional uint64 headerLength = 1;
 // the length of the file header and body in bytes
 optional uint64 contentLength = 2;
 // the information about the stripes
 repeated StripeInformation stripes = 3;
 // the schema information
 repeated Type types = 4;
 // the user metadata that was added
 repeated UserMetadataItem metadata = 5;
 // the total number of rows in the file
 optional uint64 numberOfRows = 6;
 // the statistics of each column across the file
 repeated ColumnStatistics statistics = 7;
 // the maximum number of rows in each index entry
 optional uint32 rowIndexStride = 8;
 // Each implementation that writes ORC files should register for a code
 // 0 = ORC Java
 // 1 = ORC C++
 // 2 = Presto
 // 3 = Scritchley Go from https://github.com/scritchley/orc
 // 4 = Trino
 optional uint32 writer = 9;
 // information about the encryption in this file
 optional Encryption encryption = 10;
 // the number of bytes in the encrypted stripe statistics
 optional uint64 stripeStatisticsLength = 11;
}

Stripe Information Body中的数据会被分为多个Stripe，行数据不允许跨Stripe存储。Stripe包含：**indexes of rows、row data、stripe footer。**indexes和data在stripe中按列存储。

protobuf


message StripeInformation {
 // the start of the stripe within the file
 optional uint64 offset = 1;
 // the length of the indexes in bytes
 optional uint64 indexLength = 2;
 // the length of the data in bytes
 optional uint64 dataLength = 3;
 // the length of the footer in bytes
 optional uint64 footerLength = 4;
 // the number of rows in the stripe
 optional uint64 numberOfRows = 5;
 // If this is present, the reader should use this value for the encryption
 // stripe id for setting the encryption IV. Otherwise, the reader should
 // use one larger than the previous stripe's encryptStripeId.
 // For unmerged ORC files, the first stripe will use 1 and the rest of the
 // stripes won't have it set. For merged files, the stripe information
 // will be copied from their original files and thus the first stripe of
 // each of the input files will reset it to 1.
 // Note that 1 was choosen, because protobuf v3 doesn't serialize
 // primitive types that are the default (eg. 0).
 optional uint64 encryptStripeId = 6;
 // For each encryption variant, the new encrypted local key to use until we
 // find a replacement.
 repeated bytes encryptedLocalKeys = 7;
}

Type Infomation

ORC文件的type schema必须保持一致。嵌套数据类型使用树形结构组织。 Case in Hive DDL：

sql


create table Foobar (
 myInt int,
 myMap map<string,
 struct<myString : string,
 myDouble: double>>,
 myTime timestamp
);

支持的类型：

protobuf


message Type {
 enum Kind {
 BOOLEAN = 0;
 BYTE = 1;
 SHORT = 2;
 INT = 3;
 LONG = 4;
 FLOAT = 5;
 DOUBLE = 6;
 STRING = 7;
 BINARY = 8;
 TIMESTAMP = 9;
 LIST = 10;
 MAP = 11;
 STRUCT = 12;
 UNION = 13;
 DECIMAL = 14;
 DATE = 15;
 VARCHAR = 16;
 CHAR = 17;
 TIMESTAMP_INSTANT = 18;
 }
 // the kind of this type
 required Kind kind = 1;
 // the type ids of any subcolumns for list, map, struct, or union
 repeated uint32 subtypes = 2 [packed=true];
 // the list of field names for struct
 repeated string fieldNames = 3;
 // the maximum length of the type for varchar or char in UTF-8 characters
 optional uint32 maximumLength = 4;
 // the precision and scale for decimal
 optional uint32 precision = 5;
 optional uint32 scale = 6;
}

Column Statistics

有关列的一些简单的statistics，可用于粗粒度过滤以及cbo

protobuf


message ColumnStatistics {
 // the number of values
 optional uint64 numberOfValues = 1;
 // At most one of these has a value for any column
 optional IntegerStatistics intStatistics = 2;
 optional DoubleStatistics doubleStatistics = 3;
 optional StringStatistics stringStatistics = 4;
 optional BucketStatistics bucketStatistics = 5;
 optional DecimalStatistics decimalStatistics = 6;
 optional DateStatistics dateStatistics = 7;
 optional BinaryStatistics binaryStatistics = 8;
 optional TimestampStatistics timestampStatistics = 9;
 optional bool hasNull = 10;
}

...

message IntegerStatistics {
 optional sint64 minimum = 1;
 optional sint64 maximum = 2;
 optional sint64 sum = 3;
}

User Metadata：用户自定的KV信息

protobuf


message UserMetadataItem {
 // the user defined key
 required string name = 1;
 // the user defined binary value
 required bytes value = 2;
}

File Metadata

protobuf


message Metadata {
 repeated StripeStatistics stripeStats = 1;
}

...

message StripeStatistics {
 repeated ColumnStatistics colStats = 1;
}

Stripe

Body部分的数据可以被拆分成Stripes，Stripes are large (typically ~200MB)。包含三个部分：Index Data、Row Data、Stripe Footer

在Stripe中，列数据分别以一组Stream的形式相邻于文件，如：

integer column：由两种数据流构成，PRESENT（代表是否为空） + DATA（具体数值）
string column：PRESENT + DATA + LENGTH

包含列的编码信息，以及流的相关信息

protobuf


message StripeFooter {
 // the location of each stream
 repeated Stream streams = 1;
 // the encoding of each column
 repeated ColumnEncoding columns = 2;
 optional string writerTimezone = 3;
 // one for each column encryption variant
 repeated StripeEncryptionVariant encryption = 4;
}

stream

表示文件中的一段二进制流，每一个stream的数据会根据该列的类型使用特定的压缩算法保存。

protobuf


message Stream {
 enum Kind {
 // boolean stream of whether the next value is non-null
 PRESENT = 0;
 // the primary data stream
 DATA = 1;
 // the length of each value for variable length data
 LENGTH = 2;
 // the dictionary blob
 DICTIONARY_DATA = 3;
 // deprecated prior to Hive 0.11
 // It was used to store the number of instances of each value in the
 // dictionary
 DICTIONARY_COUNT = 4;
 // a secondary data stream
 SECONDARY = 5;
 // the index for seeking to particular row groups
 ROW_INDEX = 6;
 // original bloom filters used before ORC-101
 BLOOM_FILTER = 7;
 // bloom filters that consistently use utf8
 BLOOM_FILTER_UTF8 = 8;

 // Virtual stream kinds to allocate space for encrypted index and data.
 ENCRYPTED_INDEX = 9;
 ENCRYPTED_DATA = 10;

 // stripe statistics streams
 STRIPE_STATISTICS = 100;
 // A virtual stream kind that is used for setting the encryption IV.
 FILE_STATISTICS = 101;
 }
 required Kind kind = 1;
 // the column id
 optional uint32 column = 2;
 // the number of bytes in the file
 optional uint64 length = 3;
}

message ColumnEncoding {
 enum Kind {
 // the encoding is mapped directly to the stream using RLE v1
 DIRECT = 0;
 // the encoding uses a dictionary of unique values using RLE v1
 DICTIONARY = 1;
 // the encoding is direct using RLE v2
 DIRECT_V2 = 2;
 // the encoding is dictionary-based using RLE v2
 DICTIONARY_V2 = 3;
 }
 required Kind kind = 1;
 // for dictionary encodings, record the size of the dictionary
 optional uint32 dictionarySize = 2;
}

索引支持

ORC支持三种级别的索引：

level	位于ORC的哪块	数据内容
file level	file footer	整个文件的列级别的统计
stripe level	file footer	每个stripe的列级别的统计
row level	stripe的最开始部分	每个RowGroup的列级别的统计和每个RowGroup的起始位置

Row Level

行级的索引主要有Row Group Index 和 Bloom Fliter Index

Row Group Index

索引由多个原始类型列的ROW_INDEX stream组成，每个Row Group拥有一个RowIndexEntry。

默认10000行的数据组成一个RowGroup

protobuf


message RowIndex {
 repeated RowIndexEntry entry = 1;
}

message RowIndexEntry {
 repeated uint64 positions = 1 [packed=true];
 optional ColumnStatistics statistics = 2;
}

Bloom Fliter Index

由多个列的BLOOM_FILTER stream组成。每个列拥有一个BloomFilter

protobuf


message BloomFilter {
 optional uint32 numHashFunctions = 1;
 repeated fixed64 bitset = 2;
 optional bytes utf8bitset = 3;
}

message BloomFilterIndex {
 repeated BloomFilter bloomFilter = 1;
}

Bloom filter streams are interlaced with row group indexes.

数据访问路径

Postscript -> Footer -> 获取对于的StripeInfomation -> Stripe Footer -> Stripe Index -> Stripe Row Group -> Column

参考

Apache-Iceberg调研

Wed, 05 Oct 2022 19:55:54 +0800

一种用于大规模分析数据集的表格式。
一种对数据文件和元数据文件的组织规范。
一种介于存储和计算中间的schema语义抽象。
netflix开发开源，旨在提升拓展性、可靠性、以及易用性。

背景

HIVE 上云遇到的一系列问题：

依赖List和Rename语义，无法使用更廉价的OSS代替HDFS。
可拓展性问题。Hive中的Schema信息集中存储于metastore中，可能会成为性能瓶颈
不安全操作、cbo不友好、etc

特性

支持安全高效的schema，partition变更和演进，self-define schema，hidden partition

抽象了自己的schema，不绑定任何计算引擎层面的schema；schema层面维护partition。partition和sort order 提供transformer函数，如 date(timestamp)

支持对象存储，对fs语义依赖少
ACID语义支持，读写并行，写操作串行化: 读写快照分离；乐观处理写并行冲突，重试保证写入
snapshot，支持数据回滚以及时间回溯，支持snapshot过期删除（默认不删除数据文件，但可以定制删除行为(related api doc))。通过对比snapshot差异可以实现增量读取。
查询优化友好，predict pushdown， data file statistics,目前好像不支持compaction, 可以在snapshot过期删除的删除无效文件(deleteWith)
抽象程度高，方便改造优化拓展。catalog，读写路径，文件格式，存储依赖插件化。Iceberg的设计初衷是定义于一个标准、开发且通用的数据组织格式，同时屏蔽底层数据存储格式上的差异，向上提供统一的操作API，使得不同的引擎可以通过其提供的API接入。
其他：文件级别加密解密

生态

社区对OSS & Flink & Spark & Presto均有一定支持
- flink(detail)：支持流式读写和增量读取(基于snapshot)，upsert write(0.13.0-release-notes)
- presto: Iceberg connector
- Aliyun oss: # pr 3689
其他组件对接
- 对接下层存储：只依赖三种语义In-place write，Seekable reads，Deletes，支持AliOSS(# pr 3689)
- 对接其他文件格式：抽象程度高，目前支持avro，parquet，orc
- Catalog：可定制化(Doc:Custom Catalog Implementation),目前支持JDBC，Hive metastore，hadoop等
- 对接计算层：提供原生 JAVA & Python API，抽象程度高，支持大多数计算引擎
社区开放中立，可以参与贡献，提高影响力

表规范

对数据文件和元数据文件的组织规范。

Case：Spark + IceBerg + Local FS

ice-berg 支持parquet，Avro，ORC 三种文件格式

json


# 存储组织
test2
├── data
│ ├── 00000-1-ccff6767-12cc-481c-93fc-db9f1a57438c-00001.parquet
│ └── 00001-2-6c1e5a0b-89fe-4e77-b90a-1773a7fbbcc8-00001.parquet
└── metadata
├── 2c1dc0e8-1843-4cb9-9c55-ae43f800bf3f-m0.avro // manifest file
├── snap-8512048775051875497-1-2c1dc0e8-1843-4cb9-9c55-ae43f800bf3f.avro // manifest list file
├── v1.metadata.json // metadata file
├── v2.metadata.json
 └── version-hint.text // catalog

DataFile

数据文件，列存，parquet，orc

有三种类型的Data File，data file，partition delete file，equality delete file（

Manifest File

索引数据文件，同时包含statistics, partition,

json


[
 {
 "status":1,
 "snapshot_id":{
 "long":1274364374047997583
 },
 "data_file":{
 "file_path":"/tmp/warehouse/db/test3/data/id=1/00000-31-401a9d2e-d501-434c-a38f-5df5f08ebbd7-00001.parquet",
 "file_format":"PARQUET",
 "partition":{
 "id":{
 "long":1
 }
 },
 "record_count":1,
 "file_size_in_bytes":643,
 "block_size_in_bytes":67108864,
 "column_sizes":{
 "array":[
 {
 "key":1,
 "value":46
 },
 {
 "key":2,
 "value":48
 }
 ]
 },
 "value_counts":{
 "array":[
 {
 "key":1,
 "value":1
 },
 {
 "key":2,
 "value":1
 }
 ]
 },
 "null_value_counts":{
 "array":[
 {
 "key":1,
 "value":0
 },
 {
 "key":2,
 "value":0
 }
 ]
 },
 "nan_value_counts":{
 "array":[

 ]
 },
 "lower_bounds":{
 "array":[
 {
 "key":1,
 "value":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 {
 "key":2,
 "value":"a"
 }
 ]
 },
 "upper_bounds":{
 "array":[
 {
 "key":1,
 "value":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 {
 "key":2,
 "value":"a"
 }
 ]
 },
 "key_metadata":null,
 "split_offsets":{
 "array":[
 4
 ]
 },
 "sort_order_id":{
 "int":0
 }
 }
 },
 {
 // another data file meta
 }
]

Snapshot

代表某个时刻Table的状态。通过Manifest List File保存。
每次对Table进行数据变更都会生成一个新的Snapshot。

Manifest List File

包含了一个Snapshot包含的所有Manifest文件的信息，以及Partition stats和Data File Count。
一个Snapshot对应一个Manifest List File，每次提交一个Snapshot会生成一个manifest list file。
乐观并发处理，并发提交snapshot冲突时，后提交的请求会重试保证提交。

Each manifest list stores metadata about manifests, including partition stats and data file counts.

json


[
 {
 "manifest_path":"/tmp/warehouse/db/test3/metadata/f22b748f-a7bc-4e4c-ad6c-3e335c1c0c2b-m0.avro",
 "manifest_length":6019,
 "partition_spec_id":0,
 "added_snapshot_id":{
 "long":1274364374047997583
 },
 "added_data_files_count":{
 "int":2
 },
 "existing_data_files_count":{
 "int":0
 },
 "deleted_data_files_count":{
 "int":0
 },
 "partitions":{
 "array":[
 {
 "contains_null":false,
 "contains_nan":{
 "boolean":false
 },
 "lower_bound":{
 "bytes":"\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 },
 "upper_bound":{
 "bytes":"\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000"
 }
 }
 ]
 },
 "added_rows_count":{
 "long":2
 },
 "existing_rows_count":{
 "long":0
 },
 "deleted_rows_count":{
 "long":0
 }
 },
 {
 // another manifest file
 }
]

Metadata File

包含了表的所有状态。表状态变更的时候会生成一个新的metadata，并替换原有的metadata file，此过程保证原子性。

The table metadata file tracks the table schema, partitioning config, custom properties, and snapshots of the table contents

json


{
 "format-version":1,
 "table-uuid":"175d0b61-8507-40b2-9c19-3338b05f3d48",
 "location":"/tmp/warehouse/db/test3",
 "last-updated-ms":1653387947819,
 "last-column-id":2,
 "schema":{
 "type":"struct",
 "schema-id":0,
 "fields":[
 {
 "id":1,
 "name":"id",
 "required":false,
 "type":"long"
 },
 Object{...}
 ]
 },
 "current-schema-id":0,
 "schemas":[
 {
 "type":"struct",
 "schema-id":0,
 "fields":[
 {
 "id":1,
 "name":"id",
 "required":false,
 "type":"long"
 },
 Object{...}
 ]
 }
 ],
 "partition-spec":[
 {
 "name":"id",
 "transform":"identity",
 "source-id":1,
 "field-id":1000
 }
 ],
 "default-spec-id":0,
 "partition-specs":[
 {
 "spec-id":0,
 "fields":[
 {
 "name":"id",
 "transform":"identity",
 "source-id":1,
 "field-id":1000
 }
 ]
 }
 ],
 "last-partition-id":1000,
 "default-sort-order-id":0,
 "sort-orders":[
 {
 "order-id":0,
 "fields":[

 ]
 }
 ],
 "properties":{
 "owner":"chenlan"
 },
 "current-snapshot-id":1274364374047997700,
 "snapshots":[
 {
 "snapshot-id":1274364374047997700,
 "timestamp-ms":1653387947819,
 "summary":{
 "operation":"append",
 "spark.app.id":"local-1653381214613",
 "added-data-files":"2",
 "added-records":"2",
 "added-files-size":"1286",
 "changed-partition-count":"2",
 "total-records":"2",
 "total-files-size":"1286",
 "total-data-files":"2",
 "total-delete-files":"0",
 "total-position-deletes":"0",
 "total-equality-deletes":"0"
 },
 "manifest-list":"/tmp/warehouse/db/test3/metadata/snap-1274364374047997583-1-f22b748f-a7bc-4e4c-ad6c-3e335c1c0c2b.avro",
 "schema-id":0
 }
 ],
 "snapshot-log":[
 {
 "timestamp-ms":1653387947819,
 "snapshot-id":1274364374047997700
 }

 ],
 "metadata-log":[
 {
 "timestamp-ms":1653387937345,
 "metadata-file":"/tmp/warehouse/db/test3/metadata/v1.metadata.json"
 }
 ]
}

Catalog

记录最新的metadata file路径

特性

ACID语义保证：原子性的表状态变更 + 基于快照读写
分区管理灵活：hidden partition，无感分区变更
支持增量读取：可以根据snapshot来增量读取每一次修改的数据
数据多版本：利好数据回滚
无副作用、安全的schema、partition变更

数据类型

不同数据格式的数据文件，对不同的Type会有不同定义

Nested Types
- struct：a tuple of typed values
- list：a collection of values with some element type
- map：a collection of key-value pairs with a key type and a value type.
Primitive Type

Primitive type	Description	Requirements
`boolean`	True or false
`int`	32-bit signed integers	Can promote to `long`
`long`	64-bit signed integers
`float`	32-bit IEEE 754 floating point	Can promote to double
`double`	64-bit IEEE 754 floating point
`decimal(P,S)`	Fixed-point decimal; precision P, scale S	Scale is fixed [1], precision must be 38 or less
`date`	Calendar date without timezone or time
`time`	Time of day without date, timezone	Microsecond precision [2]
`timestamp`	Timestamp without timezone	Microsecond precision [2]
`timestamptz`	Timestamp with timezone	Stored as UTC [2]
`string`	Arbitrary-length character sequences	Encoded with UTF-8 [3]
`uuid`	Universally unique identifiers	Should use 16-byte fixed
`fixed(L)`	Fixed-length byte array of length L
`binary`	Arbitrary-length byte array

读取 & 写入路径

select：catalog -> manifest list file -> manifest file -> data file -> data group

insert：reverse（catalog -> manifest list file -> manifest file -> data file -> data group）

update：delete & insert， data file + partition delete file + equality delete file，

使用Patition delete file transaction 内同一行数据反复插入删除的语义问题

delete：row level delete

参考

ice-berg spec

Flink+Iceberg的数据湖建设

Flink + Iceberg 全场景实时数仓的建设实践 Flink 中文社区

ice-berg aliyun oss

ice-berg Flink支持

基于Flink+Iceberg构建企业级实时数据湖

Flink 如何实时分析 Iceberg 数据湖的 CDC 数据

iceberg github

alluxio POXIS API

深度对比delta、iceberg和hudi三大开源数据湖方案

LevelDB Write

Tue, 10 May 2022 17:14:14 +0800

LevelDB源码阅读笔记第二章，有关LevelDB的Write流程。本文并不是step by step的源码阅读教程，而是仅仅作为我的学习笔记，简单记录我的问题与思考。

主流程

LevelDB主要的写入逻辑其实比较简单。首先将写入操作封装到WriteBatch中，之后再执行写入。

cpp


Status DB::Put(const WriteOptions& opt, const Slice& key, const Slice& value) {
 WriteBatch batch;
 batch.Put(key, value);
 return Write(opt, &batch);
}

WriteBatch

WriteBatch是对一组更新操作的封装，这一组操作会原子性的应用到状态机上。使用一块内存将用户的更新操作保存。

InMemory Format: | seq_num: 8 bytes | count: 4 bytes | list of records{ type + key + value}

cpp


class WriteBatch {
 ...
 // See comment in write_batch.cc for the format of rep_;
// WriteBatch::rep_ :=
// sequence: fixed64
// count: fixed32
// data: record[count]
// record :=
// kTypeValue varstring varstring |
// kTypeDeletion varstring
// varstring :=
// len: varint32
// data: uint8[len]
 std::string rep_;
}
// some opt
void WriteBatch::Put(const Slice& key, const Slice& value) {
 WriteBatchInternal::SetCount(this, WriteBatchInternal::Count(this) + 1);
 rep_.push_back(static_cast<char>(kTypeValue));
 PutLengthPrefixedSlice(&rep_, key);
 PutLengthPrefixedSlice(&rep_, value);
}

写入流程

写入操作主要有四步：

初始化Writer

Writer实际上就是一次写入操作需要的全部信息。

cpp


// Information kept for every waiting writer
struct DBImpl::Writer {
 explicit Writer(port::Mutex* mu)
 : batch(nullptr), sync(false), done(false), cv(mu) {}

 Status status;
 WriteBatch* batch;
 bool sync;
 bool done;
 port::CondVar cv;
};

Writer调度

LevelDB的写入其实是一种多生产者单消费者的模式，多线程生产Writer，单线程消费Writer。每个Writer由一个线程产生，但可以被多个线程消费。在LevelDB内部维护了一个Writer队列，每个线程的写入删除等更新操作会先将Writer追加到队列末尾，并用锁保证队列的数据安全。Writer被放入队列之后会进入等待，直到出现在队列头部（被调度）或者已完成（被其他线程处理）才会被唤醒。

在消费Writer, 执行具体的更新操作时，LevelDB通过将同类型（根据sync类型）的Writer合并来优化写入任务。

Writers Batches 写入

首先MakeRoomForWrite确保memtable有足够的空间以及WAL保证写入成功。如果当前的memtable有空间则复用，如果空间不足，则新建memtable和WAL，并将原来的memtable转为immemtable，等待触发compaction（minor compaction 是串行的）。
除此之外，函数还会判断L0文件的数量，通过配置以及触发器判断是否需要对写入速率进行限制。其中主要包含两个配置：
- Slowdown Trigger。触发是会让写入线程Sleep，以减缓写入的速度，使得compaction任务得以处理；同时，以此限制Level 0 文件的数量，保证读效率。
- StopWritesTrigger。停止写入线程。
BuildBatchGroup则会将队列从头部开始同类型的Writer任务中需要写入的batches合并，只得到一个batch。
之后则是将合并之后的Batch先写WAL,再写memtable中。

WAL

WAL文件被拆分为Blocks, Blocks由Record组成。格式如下图：

WAL Record Encoding

| Header{ checksum(4 bytes) + len(2 bytes) + type(1 bytes)} | Data |

其中Record主要有五类：Zero，Full，First，Middle，Last。其中Zero是预留给预分配文件。由于有个KV可能长度过长，需要由若干个Chunk记录，于是有了其他四种类型。

写入的流程

memtable

memtable的核心设计有两个：跳表以及KV在跳表中的编码。跳表保证了插入数据的有序性，具体的实现思路可以参考我的另一篇博客。

memtable的Key的编码之后的Key称之为Internal Key,其编码为| Original Key(varstring) + seq num(7 by) + type(1 byte) |

SeqNum 是在每次更新操作时生成的一个递增的序号，作为逻辑时钟标记操作的新旧。基于SeqNum可以实现基于快照（版本号）的读取。

Reference

LevelDB handbook

MIT6.824-RaftKV

Fri, 15 Apr 2022 10:49:57 +0800

之前因为想试一试GSOC，所以看了看Casbin-Mesh的代码，这是基于Raft的一个分布式Casbin应用。这个MIT6.824里的RaftKV很类似，所以正好借此机会写下这篇博客。

实验相关

Lab03的内容是在Raft基础上构建一个分布式KV服务。我们需要实现此服务的Server和Client。

RaftKV的结构和各个模块的交互如图所示：

相比于上个实验难度低了不少，实现上可以参考这篇大佬的实现，我就不多写了。

Raft 相关

接下来说说Raft中有关客户端交互有关的内容。

路由与线性化语义

想要在Raft之上构建允许客户端访问的服务，首先要解决路由和线性化语义的问题。

路由

Raft是一个Strong Leader的共识算法，读写请求一般都需要通过Leader执行。客户端反问Raft集群时，一般会随机访问集群中一个节点，如果它不是Leader, 那么它会将保存的leader信息返回给客户端，客户端会将请求重定向到Leader节点重试。

线性化语义

此为，目前的Raft只支持At Least Once的语义，对于客户端的一次请求，Raft状态机可能会应用多次命令，而这样的语义特别不适用于基于共识的系统。

为了实现线性化语义，很显然，我们需要让发出的请求实现幂等。

一个基本的思路是客户端给每个请求分配UID, 而服务端利用这个UID维护一个Session,对成功请求的Response进行缓存。当有重复的请求到达服务端时，它可以直接利用Session缓存的Response相应，这样就实现了请求幂等。

当然这带来了Session管理的问题，但这个并非本文重点。

只读优化

解决了上面两个问题之后，我们得到了一个可用的基于Raft的服务。

但我们会发现，无论是读或是写请求，我们的应用都需要经过Leader 发起一次AppendEntries的通信，在收到了Quorum成功的ACK，以及附加的落盘操作，在Log Committed再之后才能将结果返回给客户端。

写操作会改变数据状态机，所以对于写请求这些是必要的。但读操作并不会改变状态机，我们可以对只读请求进行一些优化，让只读请求绕过Raft日志，以便减少同步写操作带来的磁盘IO开销。

问题在于，如果没有其他的措施，绕过Raft日志的只读查询结果可能是过时的。

比如，旧集群Leader和一个选出新Leader的集群发生了分区，此时客户端在旧Leader上的查询结果可能会过时。

Raft论文中提到了Read Index和Lease Read两种方法来绕过Raft日志，优化只读请求。

Read Index

Read Index方案需要解决几个问题：

旧任期遗留的已提交的日志

如old leader提交Log后，没来的及发送心跳就崩溃了。此时其他节点选中为新Leader，但根据Raft论文，新leader并不会主动提交旧leader时的日志。

为了解决这个问题，我们需要在新Leader当选后提交一个no-op日志，将旧Log提交。

CommitIndex和AppliedIndex的间隔

引入readIndex变量，领导者将当前commitIndex保存在局部变量readIndx，以此作为查询时AppliedIndex的界限，当只读请求到来时，需要先将Log应用到readIndex记录的位置，之后Leader才能查询状态机，提供读服务。

在提供只读服务时候保证Leader不发生切换

为了解决这个问题，我们在收到读请求后，Leader会先进行心跳，并需要收到Quorum数量的Ack，保证在此时不存在其他任期更大的Leader，保证readIndex是集群中的最大提交索引。

具体的流程以及Batch和Follower Read的优化可以参考Raft作者的博士论文，在此不再赘述。

Lease Read

Read Index的方案其实只优化了磁盘IO的开销，它依旧需要进行一轮集群的网络通信。但实际上，这部分开销也是可以进行优化的，于是就有了Lease Read的方案。

Lease Read方案的核心思路是利用一次Leader Election至少需要经过一轮ElectionTimeout时间。在此期间，系统不会进行重新选举。这样就避免了提供只读服务时Leader切换的问题。所以我们可以利用时钟优化网络IO。

实现

在实现上，为了让时钟代替网络信息交互，我们需要额外提供一种租约机制。一旦Quorum数量的集群认可了领导者的Heartbeat，Leader可以认为在ElectionTimeout期间没有其他人能成为Leader，它可以相应的延长其租约。但Leader持有租约时，它可以直接服务只读查询而不需要额外的网络通信。

但其实服务器中间可能会存在时钟偏移，这样Follower就无法保证在Leader持有租约时不会超时。这就引出了Lease Read的关键设计：用什么策略延长租期呢？

论文中，假设$ClokcDrift$是有界的，每次心跳成功更新租约时，租约延长到$start + \frac{ElectionTimeout}{ClockDriftBound}$ 。

$ClokcDriftBound$代表了集群时钟漂移的界限，但是这个界限的发现和维护十分困难，因为导致时钟漂移的原因有很多，并且具有实时性。

如GC，虚拟机调度，云服务机器扩缩容等

实践上，一般会牺牲一定的安全性来换取LeaseRead的性能。一般使用$StatrTime +ElectionTimeout - \Delta{t}$来延长租期。$\Delta{t}$是一个正数，这就使得每次延长租约的时间小于ElectionTimeout，在网络IO开销和安全性之间Trade Off。

总结

Raft构建服务时，首先需要设计好访问服务以及路由和幂等机制。

对于只读操作，优化手段主要有两种，Read Index 和 Lease Read。其中前者优化了读操作时的磁盘IO，后者利用时钟优化了网络IO。

参考

Implimetation doc

Raft Paper

MIT6.824 Official

Consensus: Bridging Theory and Practice - zh

Tikv lease-read

LevelDB 启动

Sat, 09 Apr 2022 14:43:25 +0800

之前就听LevelDB是所有搞存储的人都会读的一个代码库。最近正好忙完了搞完了毕设的代码，稍微闲了一些，于是也打算看看LevelDB的源码。

这是LevelDB源码阅读笔记第一章，有关LevelDB的启动流程。本文并不是step by step的源码阅读教程，而是仅仅作为我的学习笔记，简单记录我的问题与思考。

带注释的代码库之后应该也会放在github上供大家学习参考。

预备知识

数据库文件

编码和命名等等等设计的相关的细节暂时不论（我也没看到那部分），先专注与文件的意义与作用

shell


├── 000005.ldb
├── 000008.ldb // sst or ldb 都是 sst文件
├── 000009.log // WAL
├── CURRENT // 记录了使用的manifest文件的名字也用于表示数据库存在
├── LOCK // 空文件，用于保证只有一个db实例操作数据库
├── LOG // level打印的日志
├── LOG.old
└── MANIFEST-000007 // descriptor_file, 元数据文件

值得深究的问题，之后也许会写相关博客，暂时先抛出：

LOCK怎么保证只有一个DB实例持有数据库

其实本质上是利用fcntl系统调用，在LOCK文件上设置写锁

各种文件的编码问题

之后会有相关博客说说leveldb的编码设计

DB State

Leveldb是一种嵌入式数据库，一般作为一些应用的组件存在（比如用于分布式存储系统中元数据节点的数据落盘）。这些应用可能会crush或者优雅退出，此时会有遗留的leveldb数据文件存在，所以我们一般需要在启动时恢复原先数据库的状态。故而我们需要明确一个db实例的状态信息，以便在使用时确保这些数据crush save，在启动时能及时回复数据状态机。

那么第一个问题是DB state应该包括什么？leveldb是一个LSM存储引擎，本质上是LSM Tree 数据结构 + 各种读写和存储优化，基于此，结合leveldb的文档，DB state包含的需要持久化信息至少有：

每层Level对应相关的sst文件，每个sst文件对应的key range

key range 主要是为了避免不必要的IO
全局逻辑时钟，last_seq_number

数据更新都有个seq_num 标记更新操作的新旧, 并与排序相关
compaction相关的参数 (file_to_compact, score, point)

compact 相关, 以便在crush之后出发compaction
cmp name

db初始化后，数据的排序逻辑就确定了，不允许被更改，用此名字作为凭证
log_number, next_file_number

wal的编号和下一个可用的file编号
deleted_files 和 add_files

compaction 或者 ref == 0 等原因导致的需要删除和添加的sst文件

具体实现上，每次leveldb的元数据变更行为（一般由Compact导致）都会被记录在VersionEdit这个数据结构之中，所以leveldb的DB State实际上是初始状态 + list of Applied VersionEdit。

版本控制

既然说到了VersionEdit, 那就顺带说一说启动流程里有关LevelDB的版本控制相关的设计，主要涉及Version, VersionEdit,VersionSet三种数据结构。

为什么需要版本控制？简单来说就是leveldb使用了MVCC机制来避免使用大锁来提高性能。

命令记录级别的快照读是通过sequence_number来实现的，所有操作都会附带当前的sequence_number，以此判断当前操作允许读取的数据，大于命令seq_number的记录对于操作将不可见。

sst文件级别的MVCC是通过Version链实现的，主要为了避免以下场景的冲突：正在读取某个文件时，而后台major compaction试图删除此文件。

Manifest Content

上文我们说到Manifest是leveldb的元数据文件，保存了数据库需要持久化的状态。leveldb在启动流程中，可能需要通过已有的数据文件回复原有db的状态。除此之外，但出现版本变更时，leveldb会生成VersionEdit, VersionEdit记录的元数据变动也需要及时持久化到manifest中，以此保证leveldb MVCC多版本状态的Crush Safe。所以Manifest的中编码布局十分重要。

在Manifest内部，元数据状态机编码成SnapshotSessionRecord +list of SessionRecords，本质上是初始状态 + list of Applied VersionEdit。

一个Manifest内部包含若干条Session Record，其中第一条Session Record记载了当时leveldb的全量版本信息，其余若干条Session Record仅记录每次更迭的变化情况。

一个Session Record可能包含以下字段：

Comparer的名称；

最新的WAL文件编号；

下一个可以使用的文件编号；

数据库已经持久化数据项中最大的sequence number；

新增的文件信息；

删除的文件信息；

compaction记录信息

Menifest写入版本变更

对于leveldb来说，增减某些sstable文件需要作为一个原子性操作，状态变更前后需要保持数据库的一致性。

原子性

原子性体现在：整个操作的完成标志为manifest文件中完整的写入了一条session record，在此之前，即便某些文件写入失败导致进程退出，数据库重启启动时，仍然能够恢复到崩溃之前正确的状态，而将这些无用的sstable文件删除，重新进行compaction动作。

一致性

一致性体现在：leveldb状态变更的操作都是以version更新为标记，而version更新是整个流程的最后一步，因此数据库必然都是从一个一致性的状态变更到另外一个一致性的状态。

从Manifest中恢复DB

随着leveldb运行时间的增长，一个manifest中包含的session record会越来越多，故leveldb在每次启动时都会重新创建一个manifest文件，并将第一条session record中记录当前version的快照状态。

其他过期的manifest文件会在下次启动的recover流程中进行删除。

leveldb通过这种方式，来控制manifest文件的大小，但是数据库本身没有重启，manifest还是会一直增长。

DB State恢复流程

检查上锁情况，创建数据目录
检查lockfile，判断是否有其他db实例
检查Current file是否存在
从manifest中恢复记录的元数据
从wal里回复last_seq_number和file_number

主体的Open流程

新建默认DB，VersionEdit实例
加锁
从manifest和wal中恢复元数据
如果新db实例没有memtable,新建memtable和wal file
将VersionEdit apply, 并落盘到manifest中
尝试删除无用文件
尝试进行compact

参考

MIT6.824-Raft

Mon, 21 Feb 2022 01:26:46 +0800

这个寒假可算把搁置许久的Lab02给做完了。之前一直被卡在Test 2B的一个case里，寒假时候重新看看大佬们的实现思路，可算是完成了所有内容，于是简单记录一下。

算法简介

共识算法的基础是复制状态机，即按照相同顺序执行相同的确定性指令最终必然达到一致状态。Raft是一种代替Paxos的分布式共识算法，相比Paxos更利于学习与理解。

Raft算法核心内容可以分为三个部分： $Leader Election + Log Replication + Satety$ 。

集群机器初始为Follower，一旦一定时间内未接收到来自Leader的心跳，机器将成为Candidate并触发选举，请求剩下Follower投票。获得半数以上选票的Candidate成为Leader。

Raft是一种强领导人的强一致性的分布式共识算法，它使用Term作为逻辑时钟，一个任期中只能有领导人。领导人需要周期性发送心跳以维护其地位，同时需要处理复制提交日志。

复制日志时，Leader首先将日志复制到其他Follower上，直到半数以上的Follower成功复制，Leader才会提交此日志。

安全性主要有五个部分，与实现相关的最核心的内容我认为有两个。一个是领导人只追加原则，不允许修改已提交的日志；另一个是选举安全性，避免脑裂问题，同时保证新Leader拥有比较新的日志。

剩下的其他内容请参考论文原文。

实现思路

实现的思路大体上是参考了一篇大佬的博文（见参考），算法的细节很多也在原Paper的Figure2中，故而以下只讲一下实现各个功能时需要注意的地方。

领导人选举

发起选举+选举结果处理

发起选举是会开启多个goroutine后台发送RPC请求到其他结点，所以处理RPC response的时候需要确定当前结点为Candidate，以及请求未过期，即rf.state == Candidate && req.Term == rf.currentTerm。选举成功需要立即发送心跳，通知其他结点选举结果。

如果发现失败的Responseresp.Term > rf.currentTerm,此时需要切换到Follower状态，更新任期，并重置投票信息。

实际上一旦更新了任期，就需要重置投票信息。如果不重置votedFor信息，会有一些测试通过不了

请求投票RPC

前置逻辑过滤过期req.Term < rf.currentTerm以及当前任期的重复投票请求。之后再按照算法描述的逻辑处理，注意如果成功投票，需要重置选举计时器。

在 grant 投票时才重置选举超时时间，这样有助于网络不稳定条件下选主的 liveness 问题

状态切换

注意在切换角色时处理不同的计时器状态(stop or reset)，切换到Leader时需要重置matchIndex以及nextIndex的值。

日志复制

Raft算法的核心，需要注意的地方最多。

我的实现是使用多个replicator和applier线程异步复制和apply的方式。

日志复制RPC

前置逻辑过滤掉req.Term < rf.currentTerm过期的请求。之后处理日志不一致以及日志被压缩以及重复日志的情况，之后复制日志再处理commitIndex。

发起日志复制+请求结果处理

发起日志复制需要判断是直接复制日志或者发送快照。

请求结果处理重点是如何处理matchIndex和nextIndex以及commitIndex。

matchIndex用来记录其他节点成功复制的最新日志，nextIndex是记录发送给其他节点的下一个日志。commitIndex通过排序matchIndex来更新。再决定是否需要触发applier更新appliedIndex。

请求失败则可以回退nextIndex或者切换到Follower状态。

异步Apply

实际上就是一个后台goroutine，通过条件变量控制，使用Channel通信。每次触发会把log[lastApplied:commitIndex]发送给上层，并更新appliedIndex。

持久化

在需要持久化状态的属性更新时及时的刷盘。

安装快照

主要就是Leader触发的Snapshot以及RPC。应用Snapshot的时候需要先判断其新旧以及更新log[0]和appliedIndex以及commitIndex。

坑

Defer

首先是Golang的defer关键字。我比较喜欢在RPC开头使用defer关键字直接打印出结点的一些数据：defer Dprintf("%+v", raft.currentTerm)，这样在调用结束时能打印出log，但实际上，在运行到defer这一行的代码时，打印的内容已经固定。正确的使用方式应该是defer func(ID int) { Dprintf("%+v", id) }()

Log Dummy Header

Log处最好预留一个位置用于存放快照保存的Index和Term，不然Snapshot那部分的重构很痛苦。

Lock

参看guidance的用锁建议。使用一个大锁，而不是用多个锁。算法的正确性比性能重要。在发送RPC以及使用Channel时不要加锁，不然可能会超时。

参考

Raft wikepedia

Raft Official Website

Raft Paper

MIT6.824 Official

Potato’s Implimentation Doc

Arch+DWM生产力套餐尝试

Sat, 15 Jan 2022 23:13:16 +0800

本来想把原来的Manjaro的KDE换DWM试一试，最后卡在开机界面外加修复的时候把引导搞坏了，于是破罐子破摔，打算全部格式化磁盘，尝试一下Arch + DWM的开发环境。写个博客记录一下，以便之后修复以及换设备使用。

本文不是step by step的教程，只是我对这次折腾的一个精简记录。

安装Arch Linux

前期准备

安装Arch需要的环境

16g以上U盘 + rufus + windows + arch linux iso制作启动盘。之后从启动盘启动Arch Liunx。

联网+镜像

使用iwctl连接wifi，之后更新系统时间以及修改pacman的镜像

安装ArchLinux

配置硬盘分区

分区需要分出三个主要部分：引导区+交换分区+主分区

挂载点	分区	分区类型	建议大小
`/mnt/boot` 或 `/mnt/efi`	`/dev/efi_system_partition（efi 系统分区）`	EFI 系统分区	至少 260 MiB
`[SWAP]`	`/dev/swap_partition（交换空间分区）`	Linux swap (交换空间)	大于 512 MiB
`/mnt`	`/dev/root_partition（根分区）`	Linux x86-64 根目录 (/)	剩余空间

shell

fdisk -l 查看硬盘信息
利用cfdisk /dev/nvme 对硬盘分区

分区格式化

shell


mkfs.ext4 ${root}
mkswap ${swap}
mkfs.fat -F 32 ${efi}

分区配置和安装系统

挂载Root mount /dev/${root_partition} /mnt
挂载EFI mount /dev/${efi_partiton} /mnt/boot/efi
开启交换分区 swapon /dev/${swap_partition}
安装内核以及必要软件包pacstrap /mnt base linux linux-firmware
生成fstab配置 genfstab -U /mnt >> /mnt/etc/fstab + 检查fstab配置文件正确性

至此系统应该已经安装完毕，但没有引导程序，所以无法启动。我们需要安装grub引导工具。

启动前的其他配置

Change Root到新安装的系统

shell


mount /dev/${root_partition} /mnt
arch-chroot /mnt

设置时区，同步时间
配置语言需要配置locale.gen和locale.conf
网络配置，配置hostname 和 hosts
设置Root用户密码
安装引导程序grub + efibootmgr 并配置grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB
安装并启动iwd,以便连接wifi
启动ArchLinux

启动之后的配置

安装必要软件

用途	软件
蓝牙	bluetoothctl
网络	iwd
日常	nvim + ranger + zsh
声音	alsamixer
输入法	fcitx5-im + fcitx5-chinese-addons
代理	clash

安装桌面环境

安装xorg软件

Xorg 项目提供了一个 X 窗口系统(图形化用户界面的基础)的开源实现。

xorg-server + xorg-apps + xrandr + xinit

安装桌面配套软件

使用suckless全套的平铺式桌面环境dwm + slock + st + dmenu + slim + slstatus

编写xinitc配置以及xprofile

在xinitc中添加

shell


# .xinitc
fcitx5 &
xautolock -time 10 -locker slock &

autorandr -l home
picom -b
feh --bg-fill --randomize /home/noneback/Picture/wallpaper/*.jpg
exec slstatus &
exec dwm

# .xprofile
export INPUT_METHOD=fcitx5
export GTK_IM_MODULE=fcitx5
export QT_IM_MODULE=fcitx5
export XMODIFIERS=@im=fcitx5

美化以及易用

用途	软件名
壁纸	feh
窗口特效	picom
锁屏	xautolock
多屏幕配置	autorandr
电池优化	tlp

其他

很多省略的细节请参考官方安装文档

参考

arch linux install wiki

x server wiki

personal dwm desktop

How to Implement SkipList

Sun, 21 Nov 2021 15:28:42 +0800

之前闲来无事，打算尝试写一个简单的LSM存储引擎的模型。简单实现了一下SkipList和BloomFilter，BitSet之后，因为一些工作上紧急的需求以及下班后只想躺平摸鱼之类的原因，暂时搁置了下来。如今想起已经有些忘记了，于是姑且记录一下。

什么是SkipList

SkipList，跳表，是一种有序的数据结构，可以作为平衡树的一种替代。本质上是一种利用稀疏索引加速链表查询的一组数据+索引的结构。

平衡树一般指BST和红黑树等数据结构，这种数据结构解决了排序树的不平衡问题，但带来了旋转，变色等问题，在并发场景下锁的粒度很大，会一定程度上影响性能，并且实现比较复杂。相对而言，SkipList避免了这些问题。

实现

跳表一般基于有序链表实现。首先是链表的排序问题，对于链表的来说，排序的问题其实等价于怎么找到新增节点的在有序链表中插入位置。

对于数组而言，只需要利用二分法查找到对应的位置，然后插入，并移动之后的元素，主要的开销在于拓展内存以及移动元素。

链表没法这么处理。链表的优势在于插入后无需移动后续元素，但无法跳跃查询，主要开销在于定位插入位置。

结合两者实际上就是跳表的基本思想：底层数据用有序链表维护，方便数据插入；在底层数据节点之上构建多层不同的稀疏索引（比如从上往下不断变密集），加速节点的查询，快速定位。

比如底层索引6节点，第一层索引在中点处[ (0 + 6) / 2]添加索引，第一层索引将底层分成两个分区，第二层索引再在两个分区的中点添加索引，以此类推。

索引节点+数据节点就是跳表的核心，但这又有了另一个问题：怎么样便利的维护索引节点？

显然，将每层的分区的中点作为索引节点是不合适的，因为节点的增减是一种常见需求，每次数据节点的增减都会导致索引节点的变化，带来不少额外的开销。我们需要一种与数据节点数量无关的、确定索引节点位置的方法。

基本的思路就是使用随机化。在每次增加节点时确定是否需要此节点上建立索引节点。

比如对于一个最高$X$层的跳表，设底层$N$个数据节点。每次添加节点时，以$1/(2^n)$判断是否要在前$n$层添加索引节点(只有本层有索引节点才能往上层添加索引节点)。

对于第$K$层，将有$N / 2^k$个节点，与取分区中点作为索引节点等价。

数据结构

go


type SkipListNode struct {
 data *codec.Entry
 nextPtrs []*SkipListNode
}

type SkipList struct {
 header, tail *SkipListNode
 level int
 size int
 rwmtx *sync.RWMutex
 maxSize int
}

操作

值得关注的只有查询和插入节点两个操作。

查询

最核心的步骤是由上至下，利用每层的稀疏索引二分查找定位到需要的节点，或者位置。

go


// findPreNode find the node before node.key
func (sl *SkipList) findPreNode(key []byte) (*SkipListNode, bool) {
 // from top to bottom
 h := sl.header
 for i := sl.level - 1; i >= 0; i-- {
 for h.nextPtrs[i] != nil && bytes.Compare(h.nextPtrs[i].data.Key, key) != 1 {
 if bytes.Equal(h.nextPtrs[i].data.Key, key) {
 return h, true
 }
 h = h.nextPtrs[i]
 }
 }

 return nil, false
}

插入

首先要定位到插入的位置，插入，再随机化创建索引。

go


func (sl *SkipList) randomLevel() int {
 ans := 1
 rand.Seed(time.Now().Unix())
 for rand.Intn(2) == 0 && ans <= defaultMaxLevel {
 ans++
 }
 return ans
}


func (sl *SkipList) Insert(data *codec.Entry) *SkipListNode {
 sl.rwmtx.Lock()
 defer sl.rwmtx.Unlock()

 h := sl.header
 updateNode := make([]*SkipListNode, defaultMaxLevel) // stores the node before newNode
 // search form the top level
 for i := sl.level - 1; i >= 0; i-- {
 // loop: 1. current nextPtrs is not empty && data is small than inserted one, curData < insertedData
 for h.nextPtrs[i] != nil && h.nextPtrs[i].data.Less(data) {
 h = h.nextPtrs[i]
 }
 updateNode[i] = h
 }
 // choose level to insert
 lvl := sl.randomLevel()
 if lvl > sl.level {
 // Insert into higher level, we need to create header -> tail
 for i := sl.level; i < lvl; i++ {
 updateNode[i] = sl.header
 }
 sl.level = lvl
 }
 // insert after updatedNote
 n := NewSkipListNode(lvl, data)
 for i := 0; i < lvl; i++ {
 n.nextPtrs[i] = updateNode[i].nextPtrs[i]
 updateNode[i].nextPtrs[i] = n
 }
 sl.size++
 return n
}

参考

跳跃列表（Skip List）与其在Redis中的实现详

Redis: zskiplist

wikipedia

spongecaptain’s blog

Kylin概述

Wed, 10 Nov 2021 23:45:27 +0800

之前就想着能做一个有意思的毕设，奈何周围都没有合适的老师。之前在学院启动选题之前找好了一个感觉不错的老师，但没想到最后把我鸽了。不过之前老师的方向也并不是那么感兴趣，于是也就作罢。最近学院的毕设流程启动了，也在选题里看到了感兴趣的题目，于是便联系老师接了下来。

我选的题目是 《基于差分隐私的数据库查询算法的设计与实现》，方向是Differential Privacy + OLAP，具体一点就是为Kylin添加Differential Privacy的Feature。

总的来说就是如此，至于细节，也许在之后的博客中会写到。这是此系列博客的第一篇。

简介

Kylin是一种分布式的OLAP数据仓库，基于Hbase和Parquet等列存数据库以及Hadoop和Spark等运算调度框架，支持超大规模数据的多维分析。

它采用cube预计算的方法，把前台的实时查询变成了查询预计算结果，利用闲时的计算资源以及存储空间换取查询时间的优化，能极大的减少查询数据的时间。

背景

在Kylin之前，一般使用Hadoop来对大规模数据进行批处理，并将结果存储在Hbase等列式存储中。其中OLAP相关的技术便是大数据并行处理和列式存储。

大规模并行处理：实际上可以调用多台机其来并行处理计算任务，本质上是利用线性增长的计算资源来换取计算时间的线性下降。
列式存储：将记录按照列来存储。这方面主要是和OLAP的查询有关的，OLAP一般是对数据做统计等计算，一般都是同类型的列数据。列式存储使得查询时可以只访问需要的列并且可以充分利用顺序IO，提高性能。

以上两个技术使得Hadoop等平台上对于大数据的SQL查询达到了分钟级。但实际上，分钟级别的SQL查询依旧没法满足交互式分析的需要，效率依旧低下。

其中本质的原因在于，无论是并行计算或者是列式存储，都没有改变查询本身的时间复杂度，没有改变查询时间和数据量的线性增长关系。于是只能通过增加计算资源和利用局部性原理来对查询进行优化，这两种方法在数据量不断增长的情况下，都能明显的预见其成本上和理论上的瓶颈。

基于此，Kylin提出预计算策略，通过对不同的维度进行预计算生成多维cube(实际上就是一个数据表),后续的查询直接基于预计算的结果进行。经过预计算,物化视图的规模就只由维度的基数来决定,而不再随着数据量的增长呈线性增长。

这个策略本质上是利用空闲的计算资源以及额外的存储资源来换取查询时的响应速度，改变了查询时间与数据量之间的正比关系，从而提高效率。

核心概念

Apache Kylin 的工作原理本质上是MOLAP(Multidimensional Online Analytical Processing)Cube,多维立方体分析技术。

维度和度量

维度指用于审视，聚合数据的一种角度，一般是数据记录的某一个属性。度量是基于数据计算出来的具体数值。通过维度来聚合计算出度量值 $$D_1,D_2,D_3,… => S_1,S_2，…$$

cube理论

Data Cube，数据立方体，其主要涉及构建和查询两种操作，构建时对原始数据建立多维度索引以及预计算，以加速查询。

Cuboid: 指在某一维度组合下所计算出的数据
Cube Segment：Cube Segment是Cube的最小构建单位，一个Cube能被拆分为多个Cube Segment。
Cube增量构建：一般来说，增量构建Cube时是基于时间属性来触发的
Cube基数：Cube中所有维度的基数可以体现Cube的复杂度。复杂度高,Cube膨胀的概率会变高（IO,存储放大）。

架构设计

整个Kylin系统分为在线查询和离线构建两部分。

离线构建：主要有数据源，构建引擎，存储引擎三大抽象。从数据源拉取数据构建Cube在存储到列式存储引擎中。
在线查询：主要有接口层和查询引擎，对外部屏蔽Cube等底层概念。外部应用通过Rest API讲查询并转发给查询引擎，查询引擎查询与相关的数据返回结果。

总结

作为一个OLAP引擎，Kylin充分利用了并行计算，列式存储，预计算等优化技术提高其在线查询和离线构建性能，故而有如下几个明显的优缺点：

优点: 标准SQL接口，查询速度快,可拓展架构，BI系统友好
缺点:依赖的外部系统过多，运维困难；预计算与Cube构建导致的IO和存储放大；数据模型以及Cube基数的局限。

参考

美团 : Apache Kylin的实践与优化

Kylin官方文档

Kylin权威指南

DFS-Haystack

Wed, 06 Oct 2021 22:44:01 +0800

组内的主要项目便是一种提供POXIS文件系统语义的DFS，其中解决losf(lots of small files)的思路就是对小文件单独处理。里面的思想来源应该就是Haystack。于是大致阅读了一下这篇论文，写下学习笔记。笔记依旧不深究具体细节，仅仅记录对问题的思考以及设计的思路。

介绍

HayStack是Facebook为了小文件设计的一种存储系统。之前的DFS，对于文件的寻址路径一般是都会使用Cache来缓存元数据，以便减少磁盘交互提高寻址效率。一个文件就需要一个维护一类元数据，文件数决定了元数据量。在高并发场景下，我们要减少磁盘IO，一般会选择将寻址需要的元数据缓存在内存中。

在大量小文件场景下，会有大量的元数据。考虑到在内存元数据维护带来的开销，这种方案变得不可用。于是便有了为小文件特别优化的HayStack。它核心思想是将多个小文件聚合成一个大文件，以减少元数据。

背景

论文中的小文件其实是特指图片数据。

Facebook是以社交起家的公司。在社交场景中，图片的上传和读取是常见需求。当业务发展到一定的程度，就需要有专门的服务支撑图片的大量高并发读写请求。

在社交场景下，这类数据的特点是written once, read often, never modified, and rarely deleted.基于此，Facebook开发了HayStack来支持图片分享服务。

设计

传统的设计

论文中给出了两种历史设计：基于CDN和基于NAS的方案

基于CDN的方案

这个方案的核心其实就是利用CDN对热点图片数据进行缓存，减少网络传输。

常用的设计，对于热点图片的优化很显著。但问题也很明显，一是CDN价格昂贵容量有限；二是图片分享场景，也会有很多less popular的图片数据，这就会导致长尾效应，拖慢速度。

CDN其实一般服务于静态数据的，并且一般都是在活动之前进行预热，并不适合作为一种图片缓存服务使用。很多的less popular的数据其实并未进入CDN，故而导致长尾效应。

基于NAS的方案

这是facebook最初的设计方案，本质和基于CDN的方案区别不大，属于它的一种实现。

引入NAS横向拓展存储，引入文件系统语义，同时也会有磁盘IO存在。和本地文件类似，对于未读取过的数据，至少需要三次磁盘IO：

Read directory metadata into memory
Load the inode into memory
Read the content of the file

PhotoStore作为一层缓存使用，缓存一些元数据如file handle等，以加速寻址过程。

基于NAS的设计并没有解决元数据过多导致不适合全量缓存这个关键问题，一但文件数量到达临界值，不可避免的需要进行磁盘IO。

更本质的问题其实是文件与寻址元数据一一对应的关系，使得元数据量随着文件数的变化而变化。

所以，优化的关键是，改变文件与寻址元数据一一对应的关系，降低寻址过程中磁盘IO出现的频率。

基于HayStack的方案

此方案最核心的思路是将多个小文件聚合成大文件，并只维护一份元数据。本质上是改变了元数据与文件数的映射关系，使将所有元数据保存在内存的方案成为可能。

只维护聚合后的大文件的元数据，小文件在大文件中的位置需要另外维护映射

实现

Haystack主要有三个组件，Haystack Directory、Haystack Cache、Haystack Store

文件映射与数据落盘

文件数据最终保存在logic volume上，一个logic volume对应多机器上的多个physical volume。

用户首先访问Directory来获取访问路径，之后再通过Directory生成的URL访问其他组件，获取需要的数据。

组件

Haystack Directory

属于Haystack的接入层，主要负责文件寻址以及访问控制。

读写请求首先访问Directory。对于读请求，Directory会生成一个访问URL，URL包含了访问的路径：http://{cdn}/{cache}/{machine id}/{logicalvolume,Photo}。对于写请求，它会指定一个可以写入的volume提供用户写入。

详细点来说，最主要有四个功能：

负载均衡，平衡读写请求，
决定请求的访问路径，比如是否通过CDN访问，生产访问URL
元数据与映射管理，如logic attr and logic volume => list of phycial volume mapping
logic volume读写管理，logic volume可能是Readonly或者WriteEnabled

这部分设计和数据特点有关，write once and read more。可以提高并发度。

基于此，Directory就必须记录一些必须的元数据，file to volume，logical to phycial mapping、logical volume attr（size，owner、etc）。

依赖分布式KV落盘元数据和缓存服务加速访问，以此保证容错可用以及低延迟。

Proxy，Metadata Mapping，Access Control

Haystack Cache

Cache作为缓存用于优化寻址以及图像获取。核心的设计是Cache Rule，判断什么样的数据需要被缓存以及Cache Miss的处理。

Haystack中，被缓存的图片数据需要满足这两个特点：

The request comes directly from a user and not the CDN
The photo is fetched from a write-enabled Store machine

当出现Cache Miss时，它会从Store上获取图片数据并同步推送至浏览器以及CDN中。

这样的策略是基于图片请求的场景与特点决定的。

首先，在CDN中Miss的请求，很大概率上也会在Cache中miss，所以重CDN重定向的请求的数据不会被Cache。其次，图片往往在刚刚写入后不久时间内会被频繁的访问，所以这样的数据理应被Cache。

CDN可以被视为一个External Cache。

Haystack Store

Store属于Haystack的存储层，负责数据存储相关操作。

首先是它的寻址抽象：filename + offset => logical volume id + offset => data。

多个Physical Volume组成Logical Volume，并作为实际落盘单位进行维护。在Store中，小文件被抽象成Needle，交由Physical Volume进行管理和维护。

Needle实际上是对小文件的一种封装，以及对Volume的分块管理。

Store的数据访问一般是以Needle维度进行的。为了加速文件寻址，一般会在内存中维护一个用于寻址元信息的Map：key/alternate key => needle's flag/offset/other attribute

这些Map最后会被持久化到磁盘中的Index File中，做为In-Memory Mapping的一种Checkpoint存在，用于Crash后寻址元数据的快速恢复。

每个Volume会维护一个自己的In-Memory Mapping和Index File

在我们更新In-Memory Mapping的时候（比如修改文件、新增文件），会异步更新Index File。但在文件删除时，我们只异步标记文件删除，而不会修改Index File。

Index只是作为加速查找的手段，无Index的Needles依旧是可以被寻址的，故而上述策略是有效的。但是由于异步更新和不删除对应文件的Index的设计，引入了Orphan Index和Deleted Index的问题。

Orphan Index是指无索引记录的Needle，一般Store会检查出这些Needle并为其添加Index。

Deleted Index一般就直接在查询是检测出文件是Deleted的，并且是Mark Deleted的状态，此时会告知上层为查询到文件，同时及时更新In-Memory Mapping。这样的设计加速了文件NotFound的情况下的查询时间。

工作负载

读

(Logical Volume ID, key, alternate key, cookies) => photo

当接收到从Cache收到读请求时，Store会去查询In-Memory Mapping查询对应的Needle。如果查询到，则根据volume + offset获取文件数据，并校验文件的cookie和完整性；否则返回错误。

Cookie是在Directory生成URL的时候随机生成的字符串，在寻址的时候带上并校验可以有效防止恶意攻击。

写

(Logical Volume ID, key, alternate key, cookies， data) => result

Haystack不支持文件的覆盖写入，只支持追加写。当收到写请求时，Store会异步Append文件数据到Needle中并更新In-Memory Mapping。如果这是一个老文件，那么Directory会更新它保存的元数据，以便后续的访问不会访问老版本的文件。

除了Directory的元信息之外，怎么去判断数据版本的新旧？

答案是根据volume以及offset。老的volume会被冻结为ReadOnly，新的volume的写入是追加的，所以offset大的必然更新。

删除

采取Mark Delete + Compact GC的方式处理删除请求。

容错设计

对于Store使用监控 + 热备的方式，Directory和Cache可以使用Raft等一致性算法保证数据副本一致与容错。

优化

优化手段主要有三点：Compaction、Batch Load、In Memory。

总结

优化的抽象：异步、批处理、缓存
要发现主要问题，比如大量小文件最主要的问题是元数据带来的管理负担。

参考

Finding a needle in Haystack: Facebook’s photo storage

MIT6.824-Bigtable

Thu, 16 Sep 2021 22:54:59 +0800

之前在网上找到了别人翻译的BigTable论文，就顺手保存了下来，但一直没开始看。最近发现BigTable和目前组内做的项目有很多设计上相似的地方，于是用周末的时间快速的阅读了一遍。

这是Google分布式三大论文的最后一篇，本不属于MIT6.824课程的阅读材料的。但姑且先如此分类。

笔记依旧不深究具体细节，仅仅记录对问题的思考以及设计的思路。

介绍

Bigtable 是一个分布式的结构化数据存储系统，构建于GFS之上，用于存储大量的结构化，半结构化数据。它属于NoSql数据存储，优势在于可拓展性和性能，以及基于GFS上的可靠容错。

Design Goal：Wide Applicability、Scalability、High Performance、High Availability

数据模型

Bigtable的数据模型属于No Scheme的设计，仅提供了一个简单的数据模型，它将所有的数据视为字符串，数据的编解码交由上层业务方决定。

实际上，Bigtable 是一个稀疏的、分布式的、持久化存储的多维度排序 Map。Map的索引是Row Key，Column Key以及TimeStamp。Map中的每一个Value就是一个无结构的Byte数组。

go


// 映射抽象
(row:string, column:string,time:int64)->string
// 一个Row Key实际上是 {Row , Column, Timestamp} 组成的多维结构。

论文对数据模型原文阐述如下：

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

Sparse，实际上是说同个Table中的Column属性是可以置空的，并且置空比较常见。

Row	Columns
Row1	{ID，Name，Phone}
Row2	{ID，Name，Phone，Address}
Row3	{ID，Name，Phone，Email}

Distributed，此处分布式关键在于拓展性和容错性，也就是Replication和Sharding。Bigtable通过GFS的Replica实现副本容错，使用Tablet对数据分区，以实现拓展性。

Persistent Multidimentsional Sorted，持久化说明最终需要数据落盘，Bittable相关的设计有WAL，LSM优化前台读写时延，优化落盘速度。

BigTable的开源实现就是HBase，是一种行列数据库

Rows

Bigtable通过行关键字的字典序来组织数据，Row Key可以是任意的字符串。对于单行的读写操作是原子的。

字典序的好处在于可以将相关的行记录聚合

可以参考Mysql的实现，利用undo log的方式实现行操作的原子性

Column Family

Column Keys 组成的集合叫做 Column Family，一个Column Family下的数据往往属于同一种类型。

一个Column Key由 Column Family : Qualifier组，列族的名字必须是可打印的字符串,而限定词的名字可以是任意的字符串。

论文中有提到：

Access control and both disk and memory accounting are performed at the column-family level.

原因在于，业务方取得数据实际上更多的是以Column为单位取得相关的数据，比如读取网页content等操作。实践上，往往也将列数据压缩存储。基于此，Column Family显然是一个比Row更合适的Level。

如我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据(甚至可能因为隐私的原因不能浏览所有数据) 。

Time Stamp

TimeStamp主要是为了维护不同时间的不同数据版本，属于一种逻辑时钟。同时它也作为索引，不同版本的数据可以通过时间戳索引查询。

设计上，一般按时间新旧排序，推测在数据版本少的时候可以利用一个指向上一个时间版本的指针来维护数据时间视图，在数据版本多的时候需要进化为索引结构。

显然基于时间戳必然有范围查询的需求，选择可排序数据结构作为索引比较合

但TimeStamp需要Table额外维护一个数据版本视图，带来一定的管理负担。一般的解决方法是限制数据版本的数量，将过期的数据进行GC处理。

Tablet

Bigtable在存储设计上，采用的是range-based的数据分片方式，而Tablet是Bigtable中data sharding 和 load balance的基本单位。

Tablet其实就是有若干个Row组成的一块数据，并由一个Tablet Server进行管理。行数据在Bigtable系统内最终保存在一个Tablet上，并在适当的时候进行Tablet拆分合并，在Tablet Server之间负载均衡。

Range Base的分片方式的好处是有利于范围查询，与之相对的是Hash分片的方式。

SSTable

SSTable 是一个持久化的、排序的、不可更改的Map 结构,而 Map 是一个 key-value 映射的数据结构,key 和 value 的值都是任意的 Byte 串。

Tablet实际上是Bigtable系统中对外的存储单位，实际上，内部的存储文件是Google SSTable格式的。

从内部看，SSTable 是一系列的数据块(通常每个块的大小是 64KB)，通过索引加速定位数据。读取时先读索引，二分查索引，在读取数据块。

API

原文中的API如下，主要是为了体现和RDB不同的地方。

cpp


// Writing to Bigtable
// Open the table Table *T = OpenOrDie("/bigtable/web/webtable"); // Write a new anchor and delete an old anchor
RowMutation r1(T, "com.cnn.www");
r1.Set("anchor:www.c-span.org", "CNN"); r1.Delete("anchor:www.abc.com");
Operation op; Apply(&op, &r1)


 // Reading from Bigtable
Scanner scanner(T); ScanStream *stream;
stream = scanner.FetchColumnFamily("anchor");
stream->SetReturnAllVersions();
scanner.Lookup("com.cnn.www");
for (; !stream->Done(); stream->Next()) {
 printf("%s %s %lld %s\n",
 scanner.RowName(),
 stream->ColumnName(),
 stream->MicroTimestamp(),
 stream->Value());
}

架构设计

外部组件

Bigtable是基于Google内部其他组件之上构建的，这极大的简化了Bigtable的设计。

GFS

GFS是Bigtable底层的GFS，可以提供Replication，提供一定的数据容错性。

可以参考上一篇笔记内容

Chubby

Chubby是一个高可用的分布式锁组件，它提供了一个NameSpace，其中的目录和文件均可作为一个分布式锁来使用。

高可用是指维护了多个可提供服务副本，并使用paxos算法保证副本间的一致性。同时使用租约机制，防止失效的Chubby客户端一直持有锁。

为什么需要Chubby？它的作用是什么？

原文中提到的功能有：

存储Bigtable的Column Family信息
存储ACL。ACL 是一种机制，用于定义用户访问存储对象的权限
存储了元数据的起始位置，也就是Root Tablet的位置信息

Bigtable使用了一个三层的类B+树的存储数据结构，Chubby中保存了Root Tablet的位置信息，Root Tablet保存了其他MetaData的Tablet信息，其他MetaData的Tablet则保存着其他用户的Tablet集合信息。

在Bigtable启动时，会先从Chubby中获取Root tablet，然后再获取其他映射信息。
Tablet Server的生命周期监控

Tablet Server在启动时，会在Chubby指定目录下生成一个唯一名称的文件，并获取此文件的排它锁。当Tablet Server失效时，会释放锁。

Master通过监控这个目录中的文件以及持有锁的状态，来监控集群中的Tablet的状态以及配置变更

总结一下，Chubby的功能其实主要分为两类。一是利用Chubby作为高可用高可靠的存储节点来存储关键元信息；二是利用其提供的分布式锁服务来管理维护存储节点（Tablet Server）。

在GFS中，这些功能其实是由Master去负责管理维护的。在Bigtable中，由Chubby接管，这样简化了Master的设计，并减轻了Master的负载。

抽象意义上，Chubby也能视为Master节点的一部分。

内部组件

Master

Bigtable也属于Master-Slave的架构，这点个GFS以及MR的设计很像。不同之处在于，Bigtable将元数据交给了Chubby + Tablet Server去存储与管理，Master只负责调度需要的信息，不存储Tablet位置信息。

Tablet分配，GC；Tablet Server监控，负载均衡；表的元数据修改等

所以调度需要的信息包含：

所有Tablet的信息，用于分析分配和分布情况

Tablet Server的状态信息，判断是否满足分配条件

Tablet Server

Tablet Server 管理一系列的Tablet，负责处理Tablet的数据读写，以及Tablet的拆分合并等操作。

Master不保存元信息，Client读取信息直接与Chubby和Tablet Server交互。

Tablet的拆分由Tablet Server主动发起，并及时通知Master。这一步可能会消息丢失，所以最好使用WAL+重试的方式保证操作不丢失

Client SDK

作为Bigtable的接入层，业务方使用ClientSDK接入Bigtable。Client SDK作为Bigtable的入口，优化的关键在于怎么样可以减少获取元数据的次数。一般使用cache以及prefetch的思路去减少网络的交互，充分利用时间和空间局部性。

缓存的使用势必会带来不一致问题，需要设计合适的方案解决此问题。如不一致时重新寻址。

存储相关

映射关系、寻址

Bigtable的数据实际上是由(Table, Row, Column)三元组唯一确定的，保存在Tablet中，Tablet最终保存在GFS SSTable中。

Tablet逻辑上可以理解为Bigtable的落盘实体，实际上是交由Tablet Server去管理维护，那么这样就需要Bigtable去维护一定的映射关系。

基于原文描述，可能需要维护的映射：

cpp


 Mapping {
 Table => list of Tablets //
 Tablet => Tablet handle

 struct Tablet handle {
 list of Rows // Tablet contains
 Tablet Server // where Tablet shores
 ...
 list of SSTable // where the tablet stores in GFS
 }

 // Indexes
 Row or Column Key => Tablet Location => SSTable
 }

Bigtable通过Root Tablet + METADATA Table进行Tablet寻址。Chubby存储了Root Tablet的位置信息，METADATA Table则由Tablet Server负责维护。

Root Tablet中保存了其他METADATA Tablet的位置信息。而METADATA Table的每一个Tablet包含了一系列的User Tablets的位置信息（可以理解为UserTable handle）, 每个Tablet的位置信息保存在METADATA的Row中。

METADATA Table 中的Row :

(TableID,encoding of last row in Tablet) => Tablet Location

系统采用了类似B+树的三层结构来维护tablet location信息

调度和监控

调度

其实主要就是对Tablet的调度，包括分配和负载均衡。

其实两种归根到底都是分配问题。在任何一个时刻, 一个 Tablet 只能分配给一个 Tablet 服务器。Master保存了Tablet Server 相关的状态信息，当有Tablet需要分配时，就发送请求将Tablet分配出去。

Master不维护寻址相关的状态信息，但需要维护Tablet Server的状态信息（持有的Tablets数量、状态、剩余资源等），可以通过心跳周期上报到Master。所以说，Master其实是无状态的，负载也比较轻。

监控

监控是由Chubby + Master来完成的。

Tablet Server在启动时，会在Chubby指定目录下生成一个唯一名称的文件，并获取此文件的排它锁。当Tablet Server断开连接，lease失效后会自动释放文件锁。

Tablet Server通过唯一文件决定是否对外提供服务。此文件可能被Master删除

Tablet Server可能由于网络因素重新连接，此时只要文件存在，Tablet重连时又会重新尝试去获取这个文件的排他锁。

如果不存在，当原Tablet Server重连是，应当自动退出集群。

Master首先要在Chubby获取一个唯一文件排他锁保证Master节点的唯一性，并指定一个Tablet Server文件目录。

然后Master通过不断监控这个目录中的文件以及持有锁的状态，来监控集群中的Tablet的状态以及配置变更，并获取正在运行的Tablet Server列表。

一但发现有Tablet Server失效，Master就会把Chubby属于原Tablet Server的唯一文件删除，并把原来这个Tablet Server维护的Tablet集合重新分配给其他Tablet Server。

Tablet Server失效有两种情况，一种是无法与Chubby连接，二是成为孤岛或者宕机。前者可以通过文件锁状态判断，后者通过Master发送心跳。其余情况，可能是Chubby无法提供服务。

之后在和所有Active的Tablet Server进行通信，获取Tablet Server的状态信息；扫描METADATA表获取未分配的Tablet信息。

监控的目的其实就是为了调度。

Compaction

Bigtable对外提供读写服务，并且使用了LSM的结构对写性能进行优化。对于一个写操作，首先通过Chubby中保存的ACL信息，判断用户的权限；通过之后再以WAL的方式顺序写记录操作再CommitLog和Memtable中，并且最后会被持久化到SSTable中；

由图中可以看出，memtable是保存在内存中的，无法无限的增加。所以Bigtable在memtable增长到一定大小的时候会进行一次Minor Compaction，将memtable的数据写入一个SSTable中，并写入GFS。

实际上，memtable在转为SSTable之前会先转换成immutable memtable，并生成新的memtable支持前台写入。这样的中间状态其实是为了Minor Compaction不影响前台写。

Bigtable在处理写入数据时提出了Compaction概念，加速前台写。所有的前台随机写被转换为顺序写。并在后台的Compact进程中再次对数据进行写入。以读写放大为代价，优化前台感知到的写性能。

所谓Compaction，本质上就是对数据的一次再次扫描，在扫描写入过程中，对数据进行合并压缩和GC。

一般Compaction以多个不可变数据作为输入，Compact之后会将数据重新写入另一个新的只读有序结构(如SSTable)或者随机写落盘。

前台写对Compaction的参与数据不影响，这使得Compaction步骤原生支持并行。

原文中提到了三种Compaction：

Minor Compaction：将memtable转化成SSTable的过程就是Minor Compaction，写入过程中会丢弃被删除的数据，并只保留数据的终态。

Minor Compaction的目的在于减少Tablet Server的内存使用，以及CommitLog的大小。

Merge Compaction：Memtable和SSTable一起Compact得到一个新的SSTable

Major Compaction：多个SSTable也可能需要Compact成一个SSTable 但对于读请求，我们可能需要聚合Memtable以及一定的SSTable来做读查询，因为查询的数据可能存在于memtable或者SSTable中。

原文中引入了二级缓存和Bloom Filter来加速读查询。

Tablet Server有两级缓存。第一层是扫描缓存，主要缓存从SSTable读取过的的KV pair；第二级是Block缓存，缓存读取的SSTable Block。

对于经常要重复读取相同数据的应用程序来说,扫描缓存非常有效；对于经常要读取刚刚读过的数据附近的数据的应用程序来说，Block 缓存更有用。

Bloom Filter简单来说就是可以判断某个Key是否不存在。

可以为全局或者每个Tablet Server，以及SSTable分别维护一个Bloom Filter，用于加速读查询，减少到SSTable的查询；对于可能存在的Key，利用二分法查询

优化

除了上文中说的到优化方式，原文还提到了几种优化手段。

局部性

通过配置或者自动等方式，把高频使用的列数据组合生成一个SSTable存储，减少分开Fetch的时间。

空间换时间，充分利用局部性原理

压缩

将SSTable中的分块进行二级压缩处理。本质其实是为了减少网络传输的带宽和时延，但需要额外的压缩和解压计算。

分块压缩是为了减少编解码的时间以及提高并行效率

CommitLog 设计

关键其实是Log的粒度问题。Tablet粒度下，会有大量的Log文件。在并行写入GFS中会有大量的磁盘Seek操作，并且不利于Batch化。集群单独一个CommitLog会带来恢复上的高复杂度。

Bigtable中是每个Tablet Server一个Commit Log。但由于Tablet Server维护了多个Tablet，这就使得Bigtable必须维护LogEntry到TabletID的映射以及顺序，以便在恢复时使用。对一个Tablet的数据恢复可能会导致扫描整个CommitLog，

此处Bigtable的优化是将Log按照(Table, row, log seq num)并行分块排序，使得同一个Tablet的LogEntry聚合。

总结

不要过渡设计，Simple is Better Than Complex。

对于分布式服务，集群监控非常重要。Google三篇论文中对集群状态的监控都是不可缺少的一环。监控的意义也在于支持集群的调度。

设计时不要对其他系统做出任何假设，出现的不仅仅是常见的网络问题，现实中可能会遇到各类问题。

利用后台处理加速前台感知。利用简单的机制处理前台请求，再开启后台进程善后。

参考

MIT6.824-GFS

Thu, 09 Sep 2021 00:44:24 +0800

之前对GFS的理解并不能支持我写出满意的内容，于是一直搁置。最近刚转岗某司存储部门实习，回想起此文，于是在无所事事之时写下这个笔记。

这是鸽了许久的Distributed System学习笔记的第二章。笔记并没有记录详细的具体操作，仅仅记录了对问题的思考与设计思路。

介绍

GFS是Google使用的分布式文件系统。它使用大量机器为数据密集型应用构建了一个可靠的分布式文件服务。

最早出现在在2003年发表的一篇论文。

背景

首先,组件失效被认为是常态事件，而不是意外事件。

使用大量的廉价机器搭建可靠的服务。每台机器一定概率失效，整体失效概率满足二项分布。

基于此，我们需要为系统组件设计容错保障机制，使得组件能够被监测，能够发现故障，并及时自动fail over，保证系统的可用性（HA)。

文件非常巨大。数 GB 的文件非常普遍。

相对于传统标准而言。对于一个分布式存储系统，我们应该尽量使用大文件为粒度对文件进行维护。

过多的小文件，意味需要更多的inode等数据结构记录元数据，有效的磁盘存储空间会减少。

其次，分布式文件寻址一般需要网络通信，寻址结果需要缓存，更多的文件意味着更多的缓存项，这也会造成空间浪费。

绝大部分文件的修改是采用在文件尾部追加数据,而不是覆盖原有数据的方式，对文件的随机写入操作在实际中几乎不存在。一旦写完之后,对文件的操作就只有读,而且通常是按顺序读

这是GFS对使用场景的考量和trade_off。

Google内部大部分操作都是 append，因此 GFS 系统优化的中心也放在 record append 操作上，对于随机写则不保证数据的一致性。

同时顺序IO写也会比随机IO的读写性能好很多。

第四，应用程序和文件系统API的协同设计提高了整个系统的灵活性

协同设计，提供类似POXIS文件系统API接口。提供客户端Lib帮助业务方屏蔽底层细节。

设计预期

存储能力

预期会有几百万文件,文件的大小通常在100MB或者以上。数个GB大小的文件也是普遍存在,并且要能够被有效的管理。

系统也必须支持小文件,但是不需要针对小文件做专门的优化。

工作负载

读工作负载

主要由大规模流式读取和小规模随机读取组成。

大规模流式读取：大规模的磁盘顺序IO读取数据
小规模随机读取：小规模磁盘随机IO（任意偏移量）读取数据

对于小规模的随机读有一定的优化，比如对读请求排序，再批量处理，而非来回随机读取。

写工作负载

主要是大规模的顺序写操作。将数据append到文件的末尾。

系统必须高效的、行为定义明确的实现多客户端并行追加数据到同一个文件里的语意。这要求系统提供并发写支持。操作的原子性以及同步开销是主要性能衡量指标。

带宽与延迟

高持续带宽（High sustained bandwidth）比低延迟更重要

这是由GFS的使用背景决定的。大多数GFS的业务方更关心高效率的处理数据，而非延迟。

容错设计

系统必须持续监控自身的状态,它必须将组件失效作为一种常态,能够迅速地侦测、冗余并恢复失效的组件。

参考背景一

操作与接口

对外提供了传统的文件系统接口，但是出于效率和使用性的角度，并没有实现标准的文件系统 POSIX API。

目录树、文件增删改查、快照、Atomic Record Append。

快照指创建文件和目录树的副本

Atomic Record Append指保证原子性的记录追加操作

架构设计

核心问题是：接入，寻址，管理，容错，一致。这些问题决定我们怎样去设计一个DFS的整体架构

GFS采用Master-Slave架构。

一个GFS集群包含一个单独的Master Node，多台Chunk Server，以及若干Client。

此处Master和Chunk Server实际上都是逻辑上的概念，实际上对应的只是用户态的一个进程，而非指具体物理机器。

单Master设计简化了GFS的设计，但有一定的单点故障的风险，属于设计上的trade_off

GFS通过lib的形式提供给业务方使用、接入GFS。

文件数据最终以chunk为单位保存在chunk server的磁盘中，并且chunk以replica的形式提供可靠服务。

master管理着GFS上所有的元数据（目录树，mapping，chunk metadata，etc）以及相关系统行为（监控，GC，snapshot，etc）。

用户通过Client，以filename + offset访问Master获取chunk元信息，再根据原信息访问对应chunk server获取具体的数据，执行操作。

组件设计

Client

Client在GFS中实际上只是使用了GFS SDK/LIB的一个应用进程。GFS提供SDK/LIB让业务方接入GFS，并尽可能的屏蔽底层细节，让业务方对GFS无感知。

因此，Client作为接入层需要提供以下功能：

缓存：缓存从Master处获取的元信息，减少网络通信的次数。

缓存也可能会导致元信息不一致的问题，需要设计合理的机制。论文中并未详细说明。

封装：屏蔽底层操作，如文件操作失败重试，命令spilt，数据checksum以及校验等
操作优化：batch，load balance等
映射：将参数filename + offset 映射为chunk index + offset

Master

Master管理着GFS所有的元数据，在GFS中属于计算层，负责文件以及文件系统的调度与管理。

其中元信息其实是保存在Master的内存中的，并未持久化，通过chunk server的上报来维护更新。

此处也是Trade_off, 简化Master和ChunkServer交互设计，但可能有数据丢失的风险，但为Master扩大内存以便为GFS提供其拓展性，代价比较小，设计者认为这也是可以接受的。

同时，设计者认为chunk的位置实际上是由chunk server决定，故而不对元信息进行持久化。

基于此，Master需要提供以下功能：

监控机制：Master节点管理这Chunk Server，并且元信息只保存在内存中，并且ChunkServer和其保存的文件均可能失效，因此需要监控Chunk Server的状态，并收集其保存的文件信息，并持续监控。

一般利用心跳机制，可以双向也可以只从ChunkServer到Master。

目录树管理：文件以分层目录的形式管理，因此需要管理名称空间，也需要考虑到并发安全等问题

一般可以将目录树前缀压缩，减少磁盘空间使用。

加锁，设计合理的加锁策略，提高并发度。比如，写文件时，对文件目录加读锁，只对文件加写锁

映射管理：Master接收Client传入的参数，返回其需要的元信息。需要维护两种映射关系：
- Table1：filename => list of chunk ID (nv)
- Table2：chunk ID => chunk handler

chunk handler是一个数据结构，包含

cpp


struct ChunkHandler {
 list of ChunkLocation(v);// 标识replica所在的机器
 version(nv); // 数据的逻辑时钟，标记数据版本
 primary(v); // 用于标记primary chunk，用于分配操作顺序
 lease expire(v); // 租约过期时间，防止ChunkServer长期持有primary
}

此处的映射实际上就是Master需要维护的数据结构（元信息），其中有一部分是需要持久化保证重启不丢失，以nv（non-volatile)标记。

Table1适合使用HashMap作为索引结构去查询，Table2则更适合使用B+Tree等数据结构做索引，因为其应该会设计范围查询。

容错：Master可能会失效，需要容错机制。

Master使用Raft多副本容错，影子热备，定时CheckPoint备份元信息，以便快速回复内存数据、operation log记录对元信息的修改做持久化记录，WAL保证操作不丢失。

系统调度：集群上chunk replica数量会不满足容错要求，这个时候就要新建副本。

如Chunk Server失效，配置变更

数据被删除或者发现孤儿Chunk（不包含数据的Chunk）时，Master需要负责GC。

一般删除的流程为：标记删除+ 延迟清理，降低前台处理时延，但会有一段时间窗口，占用磁盘的有效空间，也是trade_off

快照创建时，也需要Master的参与。

会先释放chunk的lease，再以COW的方式生成快照

Chunk数据的分布可能不满足，Master需要调度，使得数据分布满足可靠容错的要求。

分配Lease，选择Primary Chunk，管理Version等

Chunk Server

ChunkServer属于存储层，负责具体的数据以Linux文件的格式储存。

Client从Master获取元信息之后，再找到对应的ChunkServer，通过Chunk Index + Offset对文件进行寻址，再对文件进行操作。同时它需要及时上报ChunkServer的运行信息，以及它维护的Chunk的信息，以便Master维护系统的元数据。

系统内部设计与交互

讲一件上面没有涉及的关键设计思路，并不涉及具体细节

Chunk

chunk属于GFS管理数据逻辑最小单元，设计Chunk的关键是Chunk Size。

Chunk Size过小，在相同有效数据下，会产生大量元信息，加重Master的管理（元数据，cache，调度等）负担；其次，加重了Client和Master之间的网络通信的次数；没有很好的利用局部性原理。

ChunkSize过大，导致对数据的管理粒度过大，空间碎片化，降低磁盘优先使用；其次，被频繁访问的数据可能集中在同一个Chunk上，造成热点问题，并发读写时同步开销大。

基于上述原因，GFS中的ChunkSize最终被定为64MB，用一个64位全局唯一ID标识。

目前的DFS对小文件的优化实际上也就是将小文件聚合管理，减少其Master处元信息，转而将其元信息以payload的形式写入更小数据单元的header中，以便后续读写。

还有一个问题是，为什么大文件要分块管理？分块主要是为了提高大文件处理并发度。

Lease

Lease机制主要是为了保证多副本间数据变更的一致性。

当有并发顺序写请求时，Master会分配Chunk Lease给Chunk涉及的一个ChunkServer上，作为Primary节点。被选中的Primary节点会对并发写请求进行排序，安排处理数据的顺序，保证并发数据安全。并将顺序返回给Master节点。

只有再有Master节点将处理数据通知其余的Secondaries，它们只能按照此顺序处理数据。

这样的设计减少了Master的管理开销，也保证了线程数据安全，将排序交由ChunkServer处理。但ChunkServer可能随时会失效，需要防止Lease被失效的机器长期占有，故而定一个Lease Time，限制单次Lease使用的时间。

Primary节点可以通过申请延长Lease时间，满足数据处理的需求。

Version

Version主要是用来标记数据的版本，在分配Lease，选择出primary后递增并告知primary，收到ack后再持久化记录后生效。只有最新版的数据才能证有效，失效的数据需要及时处理。

ChunkServer可能短暂的失效重连，在这之间对数据的操作就可以通过Version来判断数据的新旧。

控制流和数据流

GFS中控制流和数据流是解耦的。数据流和控制流分开推送到所有设计的ChunkServer中，最后再按照Primary决定的处理顺序执行控制指令。

解耦的好处是数据流可以基于网络拓扑规划，提高机器带宽利用率，避免网路欧瓶颈和高延时。

数据流实际上是以Pipeline的形式推送到所有相关的ChunkServer中的。推送到机器上后，保存在LRU缓存中，再由此机器推送到其他机器，充分利用每一台机器的资源。

数据安全性

数据完整性

GFS把Chunk分割为64KB大小的Block，每个Block对应一个32位的Chucksum，用于校验数据的完整性。

Chuncsum和数据和用户数据分开存储，保存在内存中，并最终通过WAL持久化。

机器磁盘损坏，重复的数据append等都会导致数据完整性有问题

冗余存储

Chunk多副本异架异地存储，单副本丢失不会影响系统可用性。

一致性

我暂时没法很好的理解GFS的一致性模型，于是选择将原文奉上：

“ The state of a file region after a data mutation depends on the type of mutation, whether it succeeds or fails, and whether there are concurrent mutations.

A file region is consistent if all clients will always see the same data, regardless of which replicas they read from. A region is defined after a file data mutation if it is consistent and clients will see what the mutation writes in its entirety.

When a mutation succeeds without interference from concurrent writers, the affected region is defined (and by implication consistent): all clients will always see what the mutation has written.

Concurrent successful mutations leave the region undefined but consistent: all clients see the same data, but it may not reflect what any one mutation has written. Typically, it consists of mingled fragments from multiple mutations.

A failed mutation makes the region inconsistent (hence also undefined): different clients may see different data at different times ”

总之，GFS无法保证数据强一致，它的一致性模型非常宽松。

Lease机制虽然能够使得并发顺序写入得到合理的操作顺序，但实际的数据Atomic Record Append采用的事At least Once消息模型，确保写入成功，但可能重复写入。随机写也无法保证数据一致。

总结

一切的系统设计都是需求和业务驱动的，设计中必然涉及对场景、业务、需求、实现等多方面的trade_off。

分布式系统的可扩展性的重要性要远远高于单机性能。

以上。

参考

Google File System-GFS 论文阅读

Epoll and IO复用

Sun, 15 Aug 2021 21:47:45 +0800

先从epoll说起。

epoll是Linux内核的可拓展IO事件通知机制，设计的目的是取代select和poll，是为了处理大量文件描述符而改进的poll，支持打开文件描述符上限是系统最大文件打开数目，性能优异。

使用

API

epoll相关的系统调用有三个

cpp


/** epoll_create
 * 创建一个epoll句柄，返回错误码
 * 使用之后需要被关闭，因为epfd也会消耗系统fd数量。
 * size : 标识epfd监听fd的数量
 */
int epoll_create(int size);

/** epoll_ctl
 * 添加epoll监控对象，epoll事件的注册函数，返回错误码
 * epfd : epoll fd
 * op : 操作类型
 * EPOLL_CTL_ADD : 注册新的fd到epfd中
 * EPOLL_CTL_MOD : 修改已经注册的fd的监听事件
 * EPOLL_CTL_DEL : 从epfd中删除一个fd
 * fd : 需要监听的fd
 * event : 需要监听的事件
 * EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
 * EPOLLOUT：表示对应的文件描述符可以写；
 * EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
 * EPOLLERR：表示对应的文件描述符发生错误；
 * EPOLLHUP：表示对应的文件描述符被挂断；
 * EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
 * EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里
 */
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

/** epoll_wait
 * 收集已经触发了的事件，返回触发事件的数目，0代表超时
 * epfd : epoll fd
 * events : epoll将触发的事件赋值到events数组中
 * maxevent : 告知kernel events数组的大小，不得大于epoll_create 中的 size
 * timeout : 等待超时时间，0，立即返回，-1 一直阻塞，> 0 等待对应时间
 */
int epoll_wait(int epfd, struct epill_event* events,int timeout);

处理过程

epoll_create

当一个进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体

cpp


struct eventpoll {
 /* Protect the this structure access */
 spinlock_t lock;

 /*
 * This mutex is used to ensure that files are not removed
 * while epoll is using them. This is held during the event
 * collection loop, the file cleanup path, the epoll file exit
 * code and the ctl operations.
 */
 struct mutex mtx;

 /* Wait queue used by sys_epoll_wait() */
 /* 阻塞在epoll_wait()当前epoll实例的用户被链接到这个等待队列 */
 wait_queue_head_t wq;

 /* Wait queue used by file->poll() */
 /* epoll文件也可以被epoll_wait() */
 wait_queue_head_t poll_wait;

 /* List of ready file descriptors */
 /* 已经ready的epitem的链表 */
 struct list_head rdllist;

 /* RB tree root used to store monitored fd structs */
 struct rb_root rbr;

 /*
 * This is a single linked list that chains all the "struct epitem" that
 * happened while transfering ready events to userspace w/out
 * holding ->lock.
 */
 /* 见ep_poll_callback()以及ep_scan_ready_list()中的注释 */
 struct epitem *ovflist;

 /* The user that created the eventpoll descriptor */
 /* 创建当前epoll实例的用户 */
 struct user_struct *user;

 struct file *file;

 /* used to optimize loop detection check */
 int visited;

 struct list_head visited_list_link;//双向链表中保存着将要通过epoll_wait返回给用户的、满足条件的事件
};

在epoll_create中，epoll向内核注册了一个红黑树，用于存储上述的被监控socket。当你调用epoll_create时，就会在这个rb tree里创建一个file结点，通过rb tree查询对应的socket fd。

同时，它还会创建一个双向链表用于存储准备就绪的事件。

epoll_ctl

在epoll中，对于每一个事件都会建立一个epitem结构体：

cpp


/*
 * Each file descriptor added to the eventpoll interface will
 * have an entry of this type linked to the "rbr" RB tree.
 */
struct epitem {
 /* RB tree node used to link this structure to the eventpoll RB tree */
 /* eventpoll内部的红黑树的挂载点 */
 struct rb_node rbn;

 /* List header used to link this structure to the eventpoll ready list */
 /* 所有已经ready的epitem都会被挂载到eventpoll的rdllist中 */
 struct list_head rdllink;

 /*
 * Works together "struct eventpoll"->ovflist in keeping the
 * single linked chain of items.
 */
 /* 配合eventpoll->ovflist使用 */
 struct epitem *next;

 /* The file descriptor information this item refers to */
 /*
 * 作为evetnpoll内部的红黑树节点的key
 */
 struct epoll_filefd ffd;

 /* Number of active wait queue attached to poll operations */
 /* 监听队列挂载数 */
 /* 难道一个epitem还能同时挂载到多个监听队列？ */
 int nwait;

 /* List containing poll wait queues */
 /* 链接当前epitem对应的eppoll_entry结构 */
 struct list_head pwqlist;

 /* The "container" of this item */
 /* 关联当前epitem所属的epollevent */
 struct eventpoll *ep;

 /* List header used to link this item to the "struct file" items list */
 /* 与所监听的struct file进行链接 */
 struct list_head fllink;

 /* The structure that describe the interested events and the source fd */
 /* 通过epoll_ctl从用户空间传过来的数据，表示当前epitem关心的events */
 struct epoll_event event;
};

在调用epoll_ctl时，除了将socket fd注册到eventpoll的rb tree，它还会给内核中断处理程序注册一个回调函数。当这个fd的中断到了，就把它放入就绪链表中。当一个socket上有数据到了，内核在把网卡上的数据copy到内核中后就来把socket插入到准备就绪链表里了。

epoll_wait

当epoll_wait调用时，仅仅观察这个list链表里有没有数据即eptime项即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。

Epoll使用模型

cpp


for( ; ; )
 {
 nfds = epoll_wait(epfd,events,20,500);
 for(i=0;i<nfds;++i)
 {
 if(events[i].data.fd==listenfd) //有新的连接
 {
 connfd = accept(listenfd,(sockaddr *)&clientaddr, &clilen); //accept这个连接
 ev.data.fd=connfd;
 ev.events=EPOLLIN|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev); //将新的fd添加到epoll的监听队列中
 }

 else if( events[i].events&EPOLLIN ) //接收到数据，读socket
 {
 n = read(sockfd, line, MAXLINE)) < 0 //读
 ev.data.ptr = md; //md为自定义类型，添加数据
 ev.events=EPOLLOUT|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);//修改标识符，等待下一个循环时发送数据，异步处理的精髓
 }
 else if(events[i].events&EPOLLOUT) //有数据待发送，写socket
 {
 struct myepoll_data* md = (myepoll_data*)events[i].data.ptr; //取数据
 sockfd = md->fd;
 send( sockfd, md->ptr, strlen((char*)md->ptr), 0 ); //发送数据
 ev.data.fd=sockfd;
 ev.events=EPOLLIN|EPOLLET;
 epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev); //修改标识符，等待下一个循环时接收数据
 }
 else
 {
 //其他的处理
 }
 }
 }

阻塞IO、非阻塞IO、IO复用

阻塞IO意味着线程在数据未到达时需要等待数据到达，阻塞的进程是不应当占用CPU的，此时需要让出CPU，调入新的task占用CPU。知道数据到达，再重新获取将这个task调入CPU执行。用户进程独立处理业务

cpp


 printf("Calling recv(). \n");
 ret = recv(socket, recv_buf, sizeof(recv_buf), 0);
 printf("Had called recv(). \n");

基于此，当大量task出现读写请求时，大量的CPU上下文切换，task调度，效率可能会低下

非阻塞IO

当用户线程发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送IO操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。

cpp


while(1)
{
 printf("Calling recv(). \n");
 ret = recv(socket, recv_buf, sizeof(recv_buf), 0);
 if (EAGAIN == ret) {continue;}
 else if(ret > -1) { break;}
 printf("Had called recv(), retry.\n");
}

对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。

IO复用

阻塞IO的问题是，业务交由线程处理，阻塞导致大量的资源被占用；阻塞与恢复会可能会导致大量的上下文切换,效率低下；

非阻塞IO的问题是，在不使用监视器的情况下，依靠死循环完成一次 IO 操作。但是这样做的效率实在是太低了，完全没有实际意义；

实际上，task的运行是不可避免的，有数据需要处理，就需要CPU去执行。所以可以优化的点在于，如何减少运行处理业务的线程以减少上下文调度开销和等待线程资源占用，以及减少CPU无意义的空转。

IO复用的基本思想就是，在一个线程中管理监听多个fd事件，减少上下文切换；采用事件通知机制，减少CPU的空转；

由此衍生出的select，poll，epoll，不过此乃他话，姑且不论。

参考

Linux下的I/O复用与epoll详解

深入理解 epoll

Linux Cgroups简介

Tue, 08 Jun 2021 22:26:17 +0800

Linux Cgroups(Control Groups)供了对一组进程及将来子讲程的资源限制、控制和统计的能力。这些资源包括CPU、内存、存储、网络等。通过 Cgroups,可以方便地限制某个进程的资源占用,并且可以实时地监控进程的监控和统计信息。

Cgroups中的三个组件

cgroup

对进程分组管理的一种机制,一个 cgroup包含一组进程,并可以在这个 cgroup 上增加 Linux subsystem的各种参数配置,将一组进程和一组 subsystem的系统参数关联起来
subsystem

一组资源控制的模块

每个 subsystem会关联到定义了相应限制的 cgroup上,并对这个cgroup中的进程做相应的限制和控制。
hierarchy

hierarchy的功能是把一组 cgroup串成一个树状结构,一个这样的树便是一个hierarchy

通过这种树状结构, Groups可以做到继承。

场景：系统对一组定时的任条进程通过 cgroup1限制了CPU的使用率,然后其中有一个定时dump日志的进程还需要限制磁盘IO

为了避免限制了磁盘IO之后影响到其他进程,就可以创建 cgroup2,但其继承于 cgroup1并制磁盘的1O,这样 cgroup2便继承了 cgroup1中对CPU使用率的限制,并且增加了磁盘IO的限制而不影响到 Cgroup1中的其他进程。

三者的相互关系

系统在创建了新的 hierarchy之后,系统中所有的进程都会加入个 hierarchy的 Cgroup 根节点,这个 Cgroup节点是 hierarchy默认创建的
一个subsystem只能附加到一个hierarchy上面
一个hierarchy可以附加多个subsystem
一个进程可以位于多个从属与不同的hierarchy的cgroup中
fork出的子进程是和父进程在同一个cgroup中的。也可以之后移动到其他cgroup中

内核接口

Groups中的hierarchy是一种树状的组织结构, Kernel为了使对Cgroups的配置更直观,是通过一个虚拟的树状文件系统配置 Cgroups的,通过层级的目录拟出 Cgroups

创建挂载hierarchy，新建子cgroup

bash


mkdir cgroup # 创建挂载点
sudo mount -t cgroup -o none,name=cgroup-test cgroup-test ./cgroup-test # 挂载hierarchy
sudo mkdir cgroup-1
sudo mkdir cgroup-2
tree

.
├── cgroup-1
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── notify_on_release
│   └── tasks
├── cgroup-2
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── notify_on_release
│   └── tasks
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
└── tasks

不同文件的含义

在cgroup中添加和移动进程（将进程pid移入对应tasks文件中）

bash


sudo sh -c "echo $$ >> ./cgroup-1/tasks" # 将终端进程移入cgroup-1中
cat /proc/$$/cgroup

>>
name=cgroup-test:/cgroup-1
memory:/user.slice/user-1002.slice/session-12331.scope
perf_event:/
cpuset:/
freezer:/
blkio:/user.slice
rdma:/
hugetlb:/
pids:/user.slice/user-1002.slice/session-12331.scope
cpu,cpuacct:/user.slice
net_cls,net_prio:/
devices:/user.slice
name=systemd:/user.slice/user-1002.slice/session-12331.scope
:/user.slice/user-1002.slice/session-12331.scope

通过subsystem限制cgroup中进程的资源

首先将hierarchy关联到subsystem，系统默认将hierarchy关联到memory hierarchy

bash


# 首先,在不做限制的情况下,启动一个占用内存的stress进程
stress --vm-bytes 200m --vm-keep -m 1
sudo mkdir test-limit-memory && cd test-limit-memory # 创建一个cgroup
sudo sh -c "echo "100m" > memory.limit" # 设置最大cgroup占用为100m
sudo sh -c "echo $$ > tasks" # 将当前进程移入cgroup
stress --vm-bytes 200m --vm-keep -m 1

最后可以观测到进程占用的内存被限制了

分布式事务

Thu, 20 May 2021 23:55:11 +0800

事务与分布式事务

事务

事务是数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。数据库需要确保事务操作的原子性：当事务成功时，意味着事务的所有操作全部都执行完成；但事务失败时，数据库将所有执行过的SQL操作回滚。

数据库单机事务主要拥有四个特性：

原子性，事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行
一致性，事务应确保数据库的状态从一个一致状态转变为另一个一致状态，一致状态的含义是数据库中的数据应满足完整性约束
隔离性，多个事务并发执行时，一个事务的执行不应影响其他事务的执行
持久性，已被提交的事务对数据库的修改应该永久保存在数据库中

分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

随着微服务架构的普及，大型业务域往往包含很多服务，一个业务流程需要由多个服务共同参与完成。在特定的业务场景中，需要保障多个服务之间的数据一致性。

例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。

所以本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

使用场景

在电商系统中，典型的使用场景有：

下单扣减库存

下单时，需要的操作有生成订单记录，扣减商品库存等操作。两者同上是独立的微服务，所以严格来说，需要分布式事务保证下单操作的原子性。
第三方支付

微服务架构下，支付与订单都是独立的服务。订单的支付状态依赖于财经服务的通知。财经服务又依赖于第三方支付服务的通知。

一个经典的场景如图：

从图中可以看出有两次调用，第三方支付调用支付服务，以及支付服务调用订单服务，这两步调用都可能出现调用超时的情况，此处如果没有分布式事务的保证，就会出现用户订单实际支付情况与最终用户看到的订单支付情况不一致的情况。

实现方案

两阶段提交

一次事务的提交主要分为两个阶段：

准备阶段：
- TM开始事务，记录事务开始的日志，并向参与事务的RM询问是否能够执行提交操作，并等待RM响应
- RM执行本地事务，记录Redo/Undo日志，向TM返回执行结果，但不提交事务
提交/回滚阶段

（ 1 ）如果所有参与的RM执行成功，进入提交阶段
- TM记录事务提交日志，并向所有RM发送提交事务指令
- RM收到指令后，提交本地事务，向TM返回执行结果
- TM记录事务结束
（ 2 ）如果准备或提交任一RM执行失败或者超时
- TM记录回滚记录，并向所有RM发送回滚指令
- RM回滚本地事务，向TM返回结果
- TM记录事务结束

特性

- 原子性：支持
- 一致性：强一致
- 隔离性：支持
- 持久性：支持

弊端

- 同步阻塞：当参与事务者存在占用公共资源的情况，其中一个占用了资源，其他事务参与者就只能阻塞等待资源释放，处于阻塞状态。
- 单点故障：一旦事务管理器出现故障，整个系统不可用
- 数据不一致：如果事务管理器只发送了部分 commit 消息，此时网络发生异常，那么只有部分参与者接收到 commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。
- 不确定性：当事务管理器发送 commit 之后，并且此时只有一个参与者收到了 commit，那么当该参与者与事务管理器同时宕机之后，重新选举的事务管理器无法确定该条消息是否提交成功。

本地消息表

事务发起方维护一张**本地消息表**，业务表与本地消息表的操作处于同一个本地事务内，通过异步的**定时任务**扫描消息表并投递到下游。
广义的本地消息表方案中，下游通知方式并不局限于消息投递，也可以通过RPC调用等方式通知。
![https://i.loli.net/2021/05/19/tmNeiALsdof24PW.png](https://i.loli.net/2021/05/19/tmNeiALsdof24PW.png)
1. 事务发起者执行本地事务，同时操作业务表和本地消息表
2. 定时任务定时扫描待发送的本地消息(本地消息表中)，将其发送到消息队列
- 发送成功，则将本地消息标记为已发送
- 发送失败，则重试直至成功
3. 消息队列投递消息至下游
4. 下游事务参与者收到消息后，执行本地事务
- 本地事务执行失败，不返回ACK，消息队列重复投递消息
- 本地事务执行成功，则向消息队列返回ACK，全局事务结束
- 消息或ACK丢失，消息队列重复投递消息

异常场景

- 消息发送丢失，通过定时任务重复发送解决
- 投递到下游的消息丢失，通过重复投递机制解决，需保障下游操作幂等
- 下游回复的ACK丢失，通过重复投递机制解决，需保障下游操作幂等

优点与问题

优点：
- 系统吞吐量高，通过消息中间件解耦，下游事务异步化
- 业务侵入度适中，需要实现本地消息表和定时任务
问题：
- 事务支持不完备，不接受下游分支事务的回滚，只能重试

特性

- 原子性：支持
- 一致性：最终一致
- 隔离性：不支持（分支事务提交之后对其它事务可见）
- 持久性：支持

尽最大努力通知

最大努力通知是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果 不影响主动方的处理结果。
这个方案的大致意思就是：
1. 系统 A 本地事务执行完之后，发送个消息到 MQ；
2. 这里会有个专门消费 MQ 的服务，这个服务会消费 MQ 并调用系统 B 的接口；
3. 要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B, 反复 N 次，最后还是不行就放弃。

优点与问题

优点：
- 实现简单
问题：
- 无补偿机制，不保证送达
- 幂等要求，需要提供接口保证一致性与原子性，系统无法保证

特性

- 原子性：不支持(需要额外接口保证)
- 一致性：不支持(需要额外接口保证)
- 隔离性：不支持（分支事务提交之后对其它事务可见）
- 持久性：支持

经典场景

支付回调：
支付服务收到第三方服务支付成功通知后，先更新自己库中订单支付状态，然后同步通知订单服务支付成功。如果此次同步通知失败，会通过异步脚步不断重试地调用订单服务的接口。
![https://xiaomi-info.github.io/2020/01/02/distributed-transaction/try-best-notify.jpg](https://xiaomi-info.github.io/2020/01/02/distributed-transaction/try-best-notify.jpg)

参考

分布式事务，这一篇就够了

服务发现基本原理

Wed, 12 May 2021 22:37:30 +0800

服务发现是什么？基本的实现思路？

总览

服务发现的角色组成

服务发现由三种角色组成：

服务提供者：服务的实际提供者，提供对应的微服务
服务消费者：使用服务提供者提供的微服务，一般是其他上游微服务
服务中介：用于联系服务的提供者与消费者的一个服务，一般为KV存储，以服务名作为Key，以服务提供者IP作为Value，在有服务提供者状态变化的时候需要及时的更新与通知。

基本的流程是：首先创建一个服务提供者(微服务)，服务提供者将自身的服务地址(一般为IP:PORT)和服务名称注册到服务中介；服务消费者在调用其他微服务时，去服务中介查找服务地址，进行调用。

服务中介

服务中介是服务发现的核心，除了支持服务注册与查找等基本功能，它还需要解决几个核心的问题：

服务提供者Crash后，无法主动通知中介，怎么处理？如何保证服务列表的有效性。
- 客户端心跳：服务提供者每隔一定时间主动发送“心跳”的方式来向服务端表明自己的服务状态正常，或者维护一个长连接
  
  只说明了链路的正常，不代表服务的正常
- 服务端主动探测：服务中介主动调用服务节点的某个接口进行健康检查
  
  服务注册中心主动调用服务的某个接口无法做到通用性。在很多场景下服务注册中心到服务发布者的网络是不通的，服务端无法主动发起健康检查，那么往往需要在宿主机器上部署一个 agent 来代替服务端的接口探测
服务列表更改之后，如何及时通知服务消费者

有一下集中机制处理：
- 消费者轮询中介 + 服务列表版本号
- 消费中介推送：TCP长连接推送 or Http Polling
- 推拉结合：消费者主动拉取，中介主动推送
服务发现分布式，避免单点问题

采用分布式KV存储，如etcd等

常见服务发现工具

ECTD
ZooKeeper
Consul

参考

知乎:服务发现基本原理

InfoQ:聊一聊微服务架构中的服务发现系统

CPU伪共享

Sun, 02 May 2021 13:47:30 +0800

起因只是因为面试时被问到的一个问题：什么是CPU伪共享？

CPU缓存

让我们先从CPU缓存讲起。

CPU Cache是计算机为了解决CPU和主存之间的速度差异，引入的一种存储介质。在金字塔式存储体系中它位于自顶向下的第二层，仅次于CPU寄存器。其容量远小于内存，但速度却可以接近处理器的频率。

缓存的有效实际上是依托于程序的时空局部性原理。

使用场景上，当处理器发出内存访问请求时，会先查看缓存内是否有请求数据。如果存在（命中），则不经访问内存直接返回该数据；如果不存在（失效），则要先把内存中的相应数据载入缓存，再将其返回处理器。

CPU缓存架构

CPU与主存之间通常有三级缓存，缓存靠近CPU缓存的速率就越快，同时容量也越小。CPU获取数据时，它先去 L1 查找所需的数据，再去 L2，然后是 L3，最后如果这些缓存中都没有，所需的数据就要去主内存拿。

其中：

L1 紧靠着在使用它的 CPU 内核。L1，L2只能被一个单独的 CPU 核使用。
L3 能够被单个插槽上的所有 CPU 核共享。

CPU缓存块

缓存实际上是以缓存块（或者称之为缓存行）为最小存取单位进行存取的，通常是64个字节，它有效引用了主存中的一块地址（64字节）。

缓存的更新一次性至少更新一个缓存块。

这样加载缓存的好处是，如果我们需要的数据正好彼此相邻，那么就不需要再次更新缓存；

坏处在于可能会导致CPU的伪共享问题。

CPU伪共享

假设这么一个场景：

首先，我们有个 long 类型的变量 a，它不是数组的一部分，而是一个单独的变量，并且还有另外一个 long 类型的变量 b 紧挨着它，那么当加载 a 的时候将免费加载 b。
这个时候，一个 CPU 核心的线程在对 a 进行修改，另一个 CPU 核心的线程却在对 b 进行读取。
当前者修改 a 时，会把 a 和 b 同时加载到前者核心的缓存行中，更新完 a 后其它所有包含 a 的缓存行都将失效，因为其它缓存中的 a 不是最新值了。
而当后者读取 b 时，发现这个缓存行已经失效了，需要从主内存中重新加载。

我们的缓存都是以缓存行作为一个单位来处理的，所以失效 a 的缓存的同时，也会把 b 失效，反之亦然。

这样就出现了问题：

b 和 a 完全不相干，每次却要因为 a 的更新需要从主内存重新读取，它被缓存未命中给拖慢了。

CPU的伪共享：当多线程修改互相独立的变量时，如果这些变量共享同一个缓存行，就会无意中影响彼此的性能，这就是伪共享。

避免CPU伪共享

让数据内存分布不相邻
编译时让变量对齐

参考

杂谈:什么是CPU伪共享

wikipedia

MySQL索引浅析

Sun, 21 Mar 2021 20:41:33 +0800

数据库索引，是DBMS中一个排序的数据结构，以协助快速查询、更新数据库中数据。一般来说，用于构建索引的数据结构有B树，B+树，哈希表等。

MySQL中使用的是B+树构建索引。理由是B+树的一个节点可以存储更多的数据，并且B+树中，仅有叶子节点存储数据，非叶子节点仅存储索引，故而能将索引尽量多的保存在内存中，减少了树高，也降低了查询索引时进入磁盘IO的次数，极大提高查询的效率。

Innodb中的索引

聚簇索引与非聚簇索引

索引按照叶子节点保存的数据可分为聚簇索引和非聚簇索引两种

聚簇索引：叶子节点直接保存了数据行，能够直接查询到用户数据
非聚簇索引：叶子节点保存了主键的值，通过回表，查询主键索引查询用户数据

Innodb引擎是利用主键索引组织表中的数据，每个表中一定需要有主键，利用主键构造B+树，得到主键索引，其中主键索引就是聚簇索引，其余的二级索引都是非聚簇索引

联合索引

联合索引是由多个字段组成的索引。

sql

create index index_name on table_name (col_1,col_2...)

相比与单值索引，主要区别在于其遵守最左前缀匹配原则

最左前缀匹配原则：使用联合索引时，索引按照索引字段从左到右的顺序对索引值进行排序

使用索引优化查询性能

由于索引有序，故而能极大的提高查询的效率。使用索引进行查询优化时要遵守一些原则

最左前缀匹配原则

使用联合索引时，索引按照索引字段从左到右的顺序对索引值进行排序。查询索引时，我们也需要满足最左前缀匹配，否则数据的排列是无序的，会导致全表的扫描。

使用 col1,col2,col3构建索引，按照最左前缀匹配，在设计查询语句时我们需要按照col1 -> col2 -> col3的顺序去设计判断条件。

select * from table_name where col1 = 1 and col2 = 2; 走索引

select * from table_name where col2 = 1 and col3 = 2; 不走索引

注：MySQL查询时，会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配

索引覆盖原则

索引覆盖，指通过查询索引可以直接查询到需要的值，而不需要回表等操作。设计合理的索引，可以减少回表的次数。

对联合索引(col1,col2,col3)

查询语句 select col1,col2,col3 from test where col1=1 and col2=2可以直接查到col1-col3的值，无需回表，因为他们的值已经被保存在二级索引中了。

HTTPS浅析

Sun, 21 Feb 2021 16:48:55 +0800

HTTPS(HTTP over SSL)是为了解决HTTP中可能存在的信息窃听和身份伪装等安全问题而诞生的HTTP加密版本，通常使用 SSL 或者 TLS 来加密客户端和服务器之间所有的通信

HTTP的问题

通信使用明文，内容可能会被窃听
无法验证通信方的身份，因此可能遭遇伪装(如Dos,Denial of Service attack)
无法证明报文的完整性，报文可能在通信中被篡改(如MITM,Man-in-the-Middle attack)

为了解决以上等问题，我们需要

加密处理，防止被窃听

可以对内容加密，或者对通信加密以简历安全通信线路
需要验证通信方的身份，防止伪装攻击

如利用证书验证身份
要能确定报文的完整性，防止被篡改

常用的有MD5和SHA-1散列值校验的方法等

HTTPS

为了统一解决上诉的问题，需要在HTTP上再加上加密处理、认证、完整性保护等机制，我们称之为HTTP Secure or HTTP over SSL

$HTTP + 加密 + 认证 + 完整性保护 = HTTPS$

HTTPS over SSL

HTTPS并非是应用层的新协议，它只是HTTP通信接口部分使用SSL和TSL协议代替。它在HTTP与TCP协议中添加了一个SSL协议，使HTTP拥有HTTPS的加密、证书、完整性保护等功能。

SSL独立于HTTP的协议，应用层SMTP和Telnet等协议均可与之搭配使用，并获得加密等功能。

加密机制

HTTPS采用共享密钥和公开密钥加密两者并用的混合加密机制，充分利用两者各自的优势

利用公开密钥加密机制加密共享密钥(Pre-master secret)，避免共享密钥被窃取
通信时，则利用共享密钥加密机制，保证性能

两者主要差别：

公开密钥：非对称加密，安全，但处理复杂，效率低

共享密钥：对称加密机制，相对不安全，传输密钥时可能被窃取，但效率更高

认证机制

使用共享密钥加密时，需要证明公开密钥本身就是货真价实，未被替换，所以我们在传输公钥之前对通信方认证。

HTTPS通过使用证书来对通信方进行验证。

使用由数字证书认证机构(CA，Certificate Authority)和其颁发的公开密钥证书，认证公开密钥。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

服务器首先将公钥证书利用公开密钥加密的方式发送给客户端
客户端收到后，利用数字认证机构的公开密钥，对此证书的数字千米进行验证，如通过，则可证明：
- 数字证书认证机构后真实有效
- 服务端的公开密钥可信
通信双方利用这对公钥私钥进行加密和解密，得到共享的密钥

数字认证机构的公开密钥一般事先在浏览器内部植入

完整性保护机制

HTTPS主要使用摘要算法来保护报文的完整性

摘要算法

又称哈希算法、散列算法。它通过一个函数，把任意长度的数据转换为一个长度固定的数据串，常见的有MD5，SHA-2等

摘要算法不是加密算法，不能用于加密（因为无法通过摘要反推明文），只能用于防篡改，但是它的单向计算特性决定了可以在不存储明文口令的情况下验证用户口令。

应用层发送数据时会附加Message Authentication Code报文摘要。MAC能查知报文是否遭到了篡改，从而保护报文的完整性。

HTTPS 通信流程

其他

由于需要加密解密处理以及SSL握手等过程，需要更多的网络负载，以及CPU资源性能上HTTPS比HTTP慢很多

一般利用SSL加速器(专用服务器)来改善问题
浏览器客户端访问同一个https服务器，可以不必每次都进行完整的TLS Handshake。

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥(Pre-Master secret)传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作。

如果没有此ID，则需要完整的进行TLS Handshake

参考

MDN
wikipeida
cxuan’s blog
《图解HTTP/HTTPS》

Linux中的Fork

Thu, 18 Feb 2021 15:56:31 +0800

这原本是大二时学习操作系统是写下的一篇博客，近几日对它稍微添加了一些COW的内容。

前言

最近最学习操作系统，在《operating system concept》的进程一章节中中有这样一段代码:

c


#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main(){
 pid_t pid;
 pid=fork();
 if(pid<0){
 //create process failed
 printf("Failed\n");
 exit(-1);
 }else if(pid==0){
 //child process;
 printf ("Child pid %d\n",getpid());
 execlp("/bin/ls","ls",NULL);
 }else{
 //parent process;
 printf("Parent pid %d\n",getpid());
 wait(NULL);
 printf ("Child complete\n");
 return 0;
 }
}

查阅了些资料，看了几回才稍微看懂一点fork()的用法，于是写下这篇博客记录一下。

fork()函数介绍

简介：建立一个新的进程

表头文件：

c

#include <uistd.h>

定义函数：

c

pid_t vfork(void);

函数说明：

vfork()会产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。Linux 使用copy-on-write(COW)技术，只有当其中一进程试图修改欲复制的空间时才会做真正的复制动作，由于这些继承的信息是复制而来，并非指相同的内存空间，因此子进程对这些变量的修改和父进程并不会同步。此外，子进程不会继承父进程的文件锁定和未处理的信号。注意，Linux不保证子进程会比父进程先执行或晚执行，因此编写程序时要留意死锁或竞争条件的发生。

返回值：

如果vfork()成功则在父进程会返回新建立的子进程代码(PID)，而在新建立的子进程中则返回0。如果vfork 失败则直接返回-1，失败原因存于errno中。

错误代码：

EAGAIN 内存不足。ENOMEM 内存不足，无法配置核心所需的数据结构空间。

函数使用分析

首先我们看看开头代码的运行结果：

Linux中进程是通过链表进行组织的，所以本文中使用 ParentProcess->ChildrenProcess的格式展示。

下面开始上面分析结果：

首先，fork()函数会调用两次，第一次在父进程中返回，返回子进程的pid(一般大于零），第二次是在子进程中调用，返回0;当fork()失败时，返回一个负数。
父进程开使执行，调用fork()，返回一个子进程pid(>0)，执行打印Parent pid 25974,然后等待子进程。
子进程在父进程调用fork()后开始执行，在子进程中fork()返回０（并不是实际意义上的调用之后返回，而是在子进程中直接返回了０,在后面在解释），执行父进程fork()后面的语句，即execlp("/bin/ls",“ls”,NULL)，即调用ls，打印当前目录的文件，子进程结束。
父进程接受信号，结束主进程。

理解fork的执行

现在我们来看看这一段代码：

c


/*
 * @Description: In User Settings Edit
 * @Author: NoneBack
 * @Date: 2019-09-30 01:00:29
 * @LastEditTime: 2019-09-30 22:52:24
 * @LastEditors: NoneBack
 */
#include <stdio.h>
#include <unistd.h>
int main(void) {
 int i = 0;
 printf("i son/pa ppid pid fpid\n");
 // ppid指当前进程的父进程pid
 // pid指当前进程的pid,
 // fpid指fork返回给当前进程的值
 for (i = 0; i < 2; i++) {
 pid_t fpid = fork();
 if (fpid == 0)
 printf("%d child %4d %4d %4d\n", i, getppid(), getpid(), fpid);
 else
 printf("%d parent %4d %4d %4d\n", i, getppid(), getpid(), fpid);
 wait(NULL); //等待子进程
 }
 return 0;
}

下面是它的执行结果：

下面我们来看看为什么会有这样的结果：

１．首先父进程中，i=0时，打印0 parent 26826 26917 26918，随后父进程等待子进程执行。

子进程接着拷贝父进程（连同ＰＣ），接着父进程中i=0时fork()之后的代码运行，打印0 child 26917 26918 0，此时子进程在i=0时的fork()返回０。

子进程i=1时候的fork()接着生成一个孙子进程，并返回其pid,子进程打印1 parent 26917 26918 26919，生成的孙子进程中从i=1的fork()出接着执行，此处的fork()返回０，打印1 child 26918 26919 0。第一个子进程结束。

２.父进程中i=1时，执行fork()，生成子进程，打　印1 parent 26826 26917 26920。

子进程接着执行1=1时，fork()之后的代码,打印1 child 26917 26920 0。进程结束。

至于为什么父进程是１,这是另一方面的知识，暂且不管。

Fork里的COW机制

一开始便说了，fork执行之后,产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。这里的复制使用了COW（Copy on Write）机制。

什么是Copy On Write

COW本质上是一种Lazy Copy的思想。

写入时复制（英语：Copy-on-write，简称COW）是一种计算机程序设计领域的优化策略。

其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的（transparently）。

此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被建立，因此多个调用者只是读取操作时可以共享同一份资源。

在使用fork创建子进程时，只有当有进程需要修改的时候才会真正的执行数据的拷贝，之后再在进程自己的数据段修改数据。否则，如果进程只有读请求的话，实际上不需要不执行资源的复制，只需要在不同进程之间维护对资源的引用即可。

fork中COW技术实现原理

fork()之后，kernel把父进程中所有的内存页的权限都设为read-only，然后子进程的地址空间指向父进程。当父子进程都只读内存时，相安无事。

当其中某个进程写内存时，CPU硬件检测到内存页是read-only的，于是触发页异常中断（page-fault），陷入kernel的一个中断例程。

中断例程中，kernel就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份，之后进程再修改对应的数据。

总结

fork()会返回两次，第一次在父进程中返回fork()出的子进程的pid,第二此在子进程中返回０，接着从fork()处之后的代码开始执行。

fork()会产生一个新的子进程，其子进程会复制父进程的数据与堆栈空间，并继承父进程的用户代码，组代码，环境变量、已打开的文件代码、工作目录和资源限制等。

复制资源的核心是COW思想。

好处

COW技术可减少分配和复制大量资源时带来的瞬间延时。
COW技术可减少不必要的资源分配。比如fork进程时，并不是所有的页面都需要复制，父进程的代码段和只读数据段都不被允许修改，所以无需复制。

缺点

如果在fork()之后，父子进程都还需要继续进行写操作，那么会产生大量的分页错误(页异常中断page-fault)，这样就得不偿失。

参考

vfork

fork函数详解

MIT6.824-MapReduce

Fri, 22 Jan 2021 17:02:44 +0800

大三上学期课程有点硬核，一直没时间去继续6.824的学习，于是学习进度一直停在了Lab 1。寒假时间稍微充裕了点，于是打算继续推进。之后的每一个论文或者实验都会记录在文章中。

本文Distributed System学习笔记的第一章。

论文相关

论文最核心的内容是提出的MapReduce分布式计算模型，以及实现Distributed MapReduce System的思路，包括Master数据结构，容错以及一些refinement等内容。

MapReduce计算模型

模型接受一系列的键值对作为输入，并输出一系列键值对作为结果。用户通过设计Map和Reduce函数来使用MapReduce System

Map：接受输入数据，生成一组中间键值对
Reduce：接受中间键值对作为输入，将所有相同key的数据合并并作为结果输出。

cpp


map(String key, String value):
 // key: document name
 // value: document contents
 for each word w in value:
 EmitIntermediate(w, “1”);


reduce(String key, Iterator values):
 // key: a word
 // values: a list of counts
 int result = 0;
 for each v in values:
 result += ParseInt(v);
 Emit(AsString(result));

MapReduce执行过程

Distrubuted MapReduce System采用主从的设计，在MapReduce计算过程中，一般有一个Master，以及若干个Worker。

Master：负责Map以及Reduce任务的创建、分配、调度等
Worker：负责执行Map以及Reduce任务

更详细的描述为:

1.MapReduce的整个执行过程包含M个Map Task 和R个Reduce Task，分为两个执行阶段Map Phase 和Reduce Phase。

2.输入的文件被拆分为M个split，计算进入Map Phase阶段，Master分配Map Task给空闲Worker。分配了Task的Worker读取对应的split data，执行Task。直到所有的Map Task都完成，Map Phase结束。利用Partition函数（一般为hash(key) mod R)得到R组中间键值对，保存在文件中，并将文件路径告知Master，以便Reduce Task的操作。

3.计算进入Reduce Phase阶段，Master分配Reduce Task，每个Worker读取对应的中间键值对文件，执行Task。所有Reduce执行完成后，计算完成。结果保存到结果文件中。

MapReduce 容错机制

由于 Google MapReduce 很大程度上利用了由 Google File System 提供的分布式原子文件读写操作，所以 MapReduce 集群的容错机制实现相比之下便简洁很多，也主要集中在任务意外中断的恢复上。

Worker容错

在集群中，Master 会周期地向每一个 Worker 发送 Ping 信号。如果某个 Worker 在一段时间内没有响应，Master 就会认为这个 Worker 已经不可用。

任何分配给该 Worker 的 Map 任务，无论是正在运行还是已经完成，都需要由 Master 重新分配给其他 Worker，因为该 Worker 不可用也意味着存储在该 Worker 本地磁盘上的中间结果也不可用了。Master 也会将这次重试通知给所有 Reducer，没能从原本的 Mapper 上完整获取中间结果的 Reducer 便会开始从新的 Mapper 上获取数据。

如果有 Reduce 任务分配给该 Worker，Master 则会选取其中尚未完成的 Reduce 任务分配给其他 Worker。鉴于 Google MapReduce 的结果是存储在 Google File System 上的，已完成的 Reduce 任务的结果的可用性由 Google File System 提供，因此 MapReduce Master 只需要处理未完成的 Reduce 任务即可。

如果集群中有某个 Worker 花了特别长的时间来完成最后的几个 Map 或 Reduce 任务，整个 MapReduce 计算任务的耗时就会因此被拖长，这样的 Worker 也就成了落后者（Straggler）。

MapReduce 在整个计算完成到一定程度时就会将剩余的任务进行备份，即同时将其分配给其他空闲 Worker 来执行，并在其中一个 Worker 完成后将该任务视作已完成。

Master容错

整个 MapReduce 集群中只会有一个 Master 结点，因此 Master 失效的情况并不多见。

Master 结点在运行时会周期性地将集群的当前状态作为保存点（Checkpoint）写入到磁盘中。Master 进程终止后，重新启动的 Master 进程即可利用存储在磁盘中的数据恢复到上一次保存点的状态。

Partition Function

于Map Phase阶段使用，将中间键值对按照规则分配到R个文件中保存

Combiner

在某些情形下，用户所定义的 Map 任务可能会产生大量重复的中间结果键，Combiner 函数以对中间结果进行局部合并，减少 Mapper 和 Reducer 间需要传输的数据量。

实验相关

实验内容主要是设计实现Master和Worker，补全Simple MapReduce System的主要功能。

实验中通过Rpc调用实现单Master以及多Worker的模型，通过Go Plugin运行Map和Reduce函数组成的不同应用。

Master&Worker功能

Master

任务的创建，调度等
Worker的注册，为其分配Task
接受Worker当前的运行状态
监听Task运行状态

worker

在Master中注册
获取任务并处理
报告运行状态

注：Master通过Rpc提供相应功能给Worker调用

主要数据结构

数据结构的设计是主要的工作，良好的设计结构有助于功能的实现。此处之展示数据结构相关代码，具体的功能实现见GitHub

Master

go


type Master struct {
 // Your definitions here.
 nReduce int
 taskQueue chan Task
 tasksContext []TaskContext
 lock sync.Mutex
 files []string
 phase PhaseKind
 done bool
 workerID int
}

Worker

go


type worker struct {
 ID int
 mapf func(string, string) []KeyValue
 reducef func(string, []string) string
 nReduce int
 nMap int
}

Task & TaskContext

go


type Task struct {
 ID int
 Filename string
 Phase PhaseKind
}

type TaskContext struct {
 t *Task
 state ContextState
 workerID int
 startTime time.Time
}

Rpc Args & Reply

go


type RegTaskArgs struct {
 WorkerID int
}

type RegTaskReply struct {
 T Task
 HasT bool
}

type ReportTaskArgs struct {
 WorkerID int
 TaskID int
 State ContextState
}
type ReportTaskReply struct {
}

type RegWorkerArgs struct {
}

type RegWorkerReply struct {
 ID int
 NReduce int
 NMap int
}

Constant & Type

go


const (
 RUNNING ContextState = iota
 FAILED
 READY
 IDEL
 COMPLETE
)

const (
 MAX_PROCESSING_TIME = time.Second * 5
 SCHEDULE_INTERVAL = time.Second
)

const (
 MAP PhaseKind = iota
 REDUCE
)

type ContextState int

type PhaseKind int

运行与测试

运行

bash


# In main directory
cd ./src/main
# Master
go run ./mrmaster.go pg*.txt
# Worker
go build -buildmode=plugin ../mrapps/wc.go && go run ./mrworker.go ./wc.so 

测试

bash

cd ./src/main

sh ./test-mr.sh

优化

这些优化是在我完成实验之后，回顾自己代码时想到的可以优化的一些设计。

热点问题

这里的热点问题是，可能会有一个热点数据频繁的出现在数据集中。Map阶段的中间结果值K-V形式的，这样会导致在shuffle步骤的时候，一个Key频繁的出现，进而导致有个别机器的磁盘IO和网络IO被大量的占用。

这个问题的本质在于，MapReduce中的Shuffle在设计上是强依赖于数据的。

它的设计目的就是为了聚合中间结果数据以便Reduce阶段能够更好的进行处理。基于此，在数据极度分布不均的时候，自然会有热点问题。

实际上，问题本质是，大量的Key在Hash处理后被分配到以一个磁盘文件中，作为后续Reduce的输入。

同一个Key的Hash值理当是相同的，所以问题可以变形为：如何让相同的Key的Hash分桶到不一样机器中？

目前我想到的可行方式就是在Shuffle的Hash计算中，为Key添加随机salt，使得Hash的值不相同，减少哈希分桶到同一个机器的概率，进而解决热点问题。

容错问题

对于容错问题其实论文中已经有了一些解决方案。这个问题的场景是：Worker节点的机器突然Crash，并在重启之后重新连接。Master观测到Worker的Crash并将其任务重新分配给其他节点执行，这是Worker节点重新连接，之前的执行还在继续，双方都执行，可能导致生成两份结果文件。

这里的潜在问题是，这两份文件可能会导致结果出现错误。同时，重新连接的Worker继续执行原有的任务，浪费CPU，IO资源。

基于此，我们需要标明生成结果文件的新旧，只有最新的文件才能够被作为结果统计，这样就解决了文件冲突；同时，为Worker节点添加一个Rpc接口，使得其重新连接的时候，Master可以调用以清除原有任务。

长尾问题

长尾问题，就是指某个Task执行时间长，导致MapReduce无法迅速完成。其实本质上就是热点问题和Worker的Crash处理问题，可以参考上述博客。

参考

MIT6.824 Distributed System

Lab Official Site

MapReduce: Simplified Data Processing on Large Clusters

Google MapReduce 论文详解

算术表达式语法分析

Sun, 22 Nov 2020 20:53:19 +0800

编译原理的第二次实验，使用 LR 方法实现对算术表达式的语法分析

text

文法：
E->E+T|E-T|T
T->T*F|T/F|F
F->(E)|num

DFA

首先要根据文法构建一个 DFA

构造拓广文法 G(s)

text

拓广文法G：
S->E
E->E+T|E-T|T
T->T*F|T/F|F
F->(E)|num

构造有效项目集和相应 DFA

SLR

从 DFA 中可以观察到使用 LR(0)将会有 Shift-Reduce 冲突，所以最终使用 SLR 分析。

构造 SLR 需要在 LR(0)的基础上计算出 First 和 Follow 集合

构造 FIRST 和 FOLLOW 集合

	E	T	F
First	(,num	(,num	(,num
Follow	+,-,#,)	+,-,#,*,/,)	+,-,#,*,/,)

构造 SLR 分析表

规约时，需要判断下一个的符号是否属于被规约状态的 Follow 集合中。在 Follow 集合中才允许被规约

编写代码

相对于之前构造 DFA 和分析表，代码的实现显得则更为简单。但要注意代码的质量。

算法

实现

实现的关键在于：

Action,ActionKind

cpp


struct Action { ActionKind kind; int id;};// id is for reduce and shift
enum ActionKind { Error, Shift, Reduce, Accpet };

保存 ActionMap 和 GotoMap,产生式

cpp


typedef unordered_map<string, Action> ActionMap;//需要16个，与状态数对应
typedef unordered_map<string, State> GotoMap;//需要16个，与状态数对应


const pair<string, string> producers[] = {
 {"T", "T*F"},
 //...

 //将产生式填入
};

void initialMaps(vector<ActionMap> &am, vector<GotoMap> &gm) {
const string actions[16][11]{
 {"s4", "", "", "", "", "", "s5", ""},
 {"", "", "s7", "s6", "", "", "", "a11"},
 //...
};

const int gotos[16][3] = {
 {1, 2, 3},
 //...
};

 // （ ） - + * / num $
 // E T F

 for (int i = 0; i < 16; i++) {
 ActionMap a;
 GotoMap g;
 for (int j = 0; j < 8; j++) {
 a[T[j]] = parse2Action(actions[i][j]);
 }

 for (int k = 0; k < 3; k++) {
 g[V[k]] = gotos[i][k];
 }
 am.push_back(a);
 gm.push_back(g);
 }
}


//从表中解析出Action
// string s format:a char+digits,like s1,r2,a1
Action parse2Action(string s) {
 if (s.length() == 0 || s.length() > 3) {
 return Action{Error, Error};
 }
 char kind = tolower(s[0]);
 int id = stoi(s.substr(1, s.length() - 1));

 switch (kind) {
 case 'r':return Action{Reduce, id};
 case 's':return Action{Shift, id};
 case 'a':return Action{Accpet, Accpet};
 default:return Action{Error, Error};
 }
}

Lexer

由于是语法分析实验，所以词法分析写的比较简单

cpp


// simple lex,suppose that there is no error in token while lexing
//
// return like{"(","num",")"}
vector<string> lex2Str(string sourceStr) {
 vector<string> ans;
 for (int i = 0; i < sourceStr.length(); i++) {
 string cur = string{sourceStr[i]};
 if (T.find(cur) != T.end()) {
 ans.push_back(cur);
 } else {
 // parse num
 ans.push_back("num");
 i += 2;
 }
 }
 return ans;
 }

StatesStack,EnteredStack,CharacterQueue 三个关键数据结构的维护与 Parse 函数的编写

cpp


class DigitExpressionParser {
 private:
 stack<string> entered;
 queue<string> characters;
 unordered_set<string> T{"(", ")", "-", "+", "*", "/", "num", "$"};
 unordered_set<string> V{"E", "T", "F"};
 stack<State> states;
 vector<ActionMap> am;
 vector<GotoMap> gm;

 vector<string> lex2Str(string sourceStr)
 // function overload for different container to pop numofEle
 void pop(queue<string> &q, int num)

 void pop(stack<string> &s, int num)

 void pop(stack<State> &s, int num)

 // initial parser
 bool _init(string sourceString)

 public:
 DigitExpressionParser() { initialMaps(am, gm); }

 // parse
 bool parse(string sourseStr) {
 if (!_init(sourseStr)) {
 cerr << "Error:source string empty or wrong token" << endl;
 return false;
 }

 while (true) {
 State curState = states.top();
 string curCharacter = characters.front();

 auto &action = am[curState][curCharacter];

 switch (action.kind) {
 case Shift:states.push(action.id);
 entered.push(curCharacter);
 characters.pop();
 break;

 case Reduce: {
 // use producer[id] to reduce
 printProducer(action.id);
 auto producer = producers[action.id];
 int popNum = producer.second == "num" ? 1 : producer.second.size();
 pop(states, popNum);
 pop(entered, popNum);
 entered.push(producer.first);

 states.push(gm[states.top()][producer.first]);
 }
 break;

 case Error:cerr << "Error while parsing" << endl;
 return false;

 case Accpet:cout << "Accepted" << endl;
 return true;
 }
 }
 }
};

优化

实验上有一些是可以优化(卷)的

First 和 Follow 集合，有效项目集，分析表能够使用代码自动生成
num 的可以使用数字代替，解析为 token

如果觉得不够卷还可以

可视化(呸)
写一个计算器

LC406 根据身高重建队列

Mon, 16 Nov 2020 00:52:04 +0800

今天的每日一题是LC406 根据身高重建队列,属于贪心算法的一题，以此记录解题思路。

描述

题目描述如下：

假设有打乱顺序的一群人站成一个队列。每个人由一个整数对(h, k)表示，其中h是这个人的身高，k是排在这个人前面且身高大于或等于h的人数。编写一个算法来重建这个队列。
text
示例
输入:
[[7,0], [4,4], [7,1], [5,0], [6,1], [5,2]]
输出:
[[5,0], [7,0], [5,2], [6,1], [4,4], [7,1]]

分析

完成这题最主要的就是要明白每个元素顺序对k的影响。

1.首先将元素排序。$h$大的放在前面，如果$h$相同，则把$k$大的放前面。

2.将排序后的元素放入队列中。

第 $0, \cdots, i-10,⋯,i−1 $个人已经在队列中被安排了位置，他们只要站在第 $i$ 个人的前面，就会对第 $i$ 个人产生影响，因为他们都比第 $i$ 个人高；

而第 $i+1, \cdots, n-1$ 个人还没有被放入队列中，并且他们无论站在哪里，对第 $i$ 个人都没有任何影响，因为他们都比第 $i$ 个人矮。

也就是说，当我们放入第 $i$ 个人时，只需要将其插入队列中，使得他的前面恰好有 $k_i$ 个人即可。

代码

go


/*
 * @lc app=leetcode.cn id=406 lang=cpp
 *
 * [406] 根据身高重建队列
 */

// @lc code=start
#include <bits/stdc++.h>
using namespace std;
class Solution {
 public:
 vector<vector<int>> reconstructQueue(vector<vector<int>>& people) {
 sort(people.begin(), people.end(),
 [](const vector<int>& u, const vector<int>& v) {
 return u[0] > v[0] || (u[0] == v[0] && u[1] < v[1]);
 });

 vector<vector<int>> ans;
 for (const vector<int>& person : people) {
 ans.insert(ans.begin() + person[1], person);
 }
 return ans;
 }
};
// @lc code=end

参考

题解

LC406 根据身高重建队列

LC402 移除K位数字

Sun, 15 Nov 2020 00:00:00 +0000

今天的每日一题是 LC402 移除 K 位数字,最终看题解完成，记录一下思路。

描述

题目的描述如下

给定一个以字符串表示的非负整数 num，移除这个数中的 k 位数字，使得剩下的数字最小。

注意:
num 的长度小于 10002 且 ≥ k。 num 不会包含任何前导零。
go
示例 1 :

输入: num = "1432219", k = 3
输出: "1219"
解释: 移除掉三个数字 4, 3, 和 2 形成一个新的最小的数字 1219。

分析

这个题的关键是判断那一些位的数字需要被丢弃，以此组成一个最小的数字。

所以我们需要：

1.数字大小的比较。

2.怎么判断数字是否需要被丢弃

数字大小的比较

我们判断两个数字大小时，是通过其不相同的最高位数字大小来比较的。

1.首先判断数的位数，相同则进行下一步。否则位数多的大。

a=12xxx,b=11xxxx,显然 a<b

2.位数相同时，一位一位比较，从高到低。相同的则跳过，直到有一位能分出大小。

a=12xxxxx,b=13xxxxx,此时由于第二位 2<3,所以有 a>b

判断数字是否丢弃

丢弃条件

贪心策略:

对数字$D_1D_2…D_x$,如果有位置$i$,使得$D_i<D_{i-1}$,此时要把$D_{i-1}$丢弃。

如果不存在,说明整个数字序列单调不降（像 123456789），此时删去最后一个数字即可。

下面对题目简单的模拟:

设 num=1432219,n=3,遍历 num,每次只与左边数的进行比较，如果比左边大则放入，反之则丢弃左边数字，并继续和左边的数比较、放入、丢弃步骤。

最后的结果必然是数字序列单调不降，所以我们使用一个单调栈来保存未被丢弃的数字。

如果此时丢弃的数位依旧不足，则丢弃最后的几位数字。

代码

go


/*
 * @lc app=leetcode.cn id=402 lang=cpp
 *
 * [402] 移掉K位数字
 */

// @lc code=start
// 单调栈+贪心
#include <bits/stdc++.h>
using namespace std;
class Solution {
 public:
 string removeKdigits(string num, int k) {
 vector<char> ret;

 for (auto& ch : num) {
 while (ret.size() > 0 && k && ret.back() > ch) {
 ret.pop_back();
 k--;
 }
 ret.push_back(ch);
 }
 // 处理未处理的k,此时数据已是单调增，去除最后几位

 while(k--){
 ret.pop_back();
 }

 string ans = "";
 bool begWithZero = true;
 for (auto& digit : ret) {
 if (digit == '0' && begWithZero) {
 continue;
 }
 begWithZero = false;
 ans += digit;
 }

 return ans == "" ? "0" : ans;
 }
};
// @lc code=end

参考

LC402

官方题解

单调栈

实现简单的SQL数据库--前端

Tue, 10 Nov 2020 00:00:00 +0000

一直想去完成pingcap的tanlent Plan里面的tinySql路径，但一直没有开始。最近论坛上发现了pingcap创始人的tanlent plan入坑贴，下面的学长提示了这个从零实现数据库博客入门比较合适，于是写下这个博客。

前端

与编译器类似，一个数据库软件也分为前端和后端。前端部分主要是SQL语句的解析以及一个REPL。

获取tokens

go


type token struct {
 value string
 kind tokenKind
 loc location
}

模拟cursor扫描语句，将sql语句解析为一个一个token，token中包括了单词的种类，位置，值。

获取单个token时，每次扫描结束，如果成功，更新光标，并返回一个新token地址以及更新后的光标位置，ok=true。

如果失败，则返回nil,传入的初始化的光标位置不变，ok=false。

最终处理所有语句，得到token地址数组

go


// 主要流程
func lex(source string) ([]*token, error) {
 tokens := []*token{}
 cur := cursor{}

 for cur.pointer < uint(len(source)) {
 lexers := []lexer{lexKeyword, lexSymbol, lexString, lexNumeric, lexIdentifier}
 isMatched := false
 for _, l := range lexers {
 if token, newCursor, ok := l(source, cur); ok {
 cur = newCursor

 // Omit nil tokens for valid, but empty syntax like newlines
 if token != nil {
 tokens = append(tokens, token)
 }
 isMatched = true
 break
 }
 }

 if isMatched {
 // match the next one
 continue
 }

 hint := ""
 if len(tokens) > 0 {
 hint = " after " + tokens[len(tokens)-1].value
 }
 return nil, fmt.Errorf("Unable to lex token%s, at %d:%d", hint, cur.loc.row, cur.loc.col)
 }
 return tokens, nil
}

获得Ast

第二步，从tokens中，解析出一个抽象语法树。

Ast有statement[]组成，目前的解析器只解析select，insert，create三种语句。

go


type Ast struct {
 Statement []*Statement
}

type Statement struct {
 SelectStatement *SelectStatement
 CreateStatement *CreateStatement
 InsertStatement *InsertStatement
 Kind AstKind
}

解析的思路是按照不同的sql语句，分析出相应的语法成分，最后形成最后的语法树

SELECT语句

语法成分：

SELECT ${ expression[] }$ FROM $ tableName $

example：select id,age,name from students

1.解析出keyword SELECT

2.解析expression[]

3.解析出keyword FROM

4.解析identifier $tableName$

其中重点在于对expressions的理解与解析

go


// parse the token at cursor and return an expression containing literal val and its kind
func parseExpression(tokens []*token, initialCursor uint, _ token) (*expression, uint, bool) {
 cursor := initialCursor

 kinds := []tokenKind{identifierKind, numericKind, stringKind}

 for _, kind := range kinds {
 t, newCursor, ok := parseToken(tokens, cursor, kind)
 if ok {
 return &expression{
 literal: t,
 kind: literalKind,
 }, newCursor, true
 }
 }

 return nil, initialCursor, false
}

expression 只包括了stringKind，numericKind，identifierKind的字符集合。parseexpression读入一个token，如果cursor超出了tokens的长度或者Kind不是这三种，则返回错误的结果，遇到分隔符delimiter则正常返回。

CREATE语句

语法成分

CREATE TABLE $tableName$ ( $columnDef$ )

example:CREATE TABLE students(id string, age int, name string)

1.解析出keyword CREATE

2.解析出keyword TABLE

3.解析identifier $tableName$

4.解析 symbol (

5.解析$columndef$

6.解析symbol )

解析CREATE的语句关键是对$columnDef$的解析

go


//column
type columnDefinition struct {
 name token
 datatype token
}

解析columnDefinitions

1.循环解析token，直到cur超出tokens范围或者解析出现错误

首先解析identifier $name$,keyword $datatype$

解析分隔符 symbol ,

go


// parse col def
//
func parseColumnDefinitions(tokens []*token, initialCursor uint, delimiter token) (*[]*columnDefinition, uint, bool) {
 cursor := initialCursor

 cds := []*columnDefinition{}
 for {
 if cursor >= uint(len(tokens)) {
 return nil, initialCursor, false
 }

 // Look for a delimiter
 current := tokens[cursor]
 if delimiter.equals(current) {
 break
 }

 // Look for a comma
 // col devided by comma
 if len(cds) > 0 {
 if !expectToken(tokens, cursor, tokenFromSymbol(commaSymbol)) {
 helpMessage(tokens, cursor, "Expected comma")
 return nil, initialCursor, false
 }

 cursor++
 }

 // Look for a column name
 id, newCursor, ok := parseToken(tokens, cursor, identifierKind)
 if !ok {
 helpMessage(tokens, cursor, "Expected column name")
 return nil, initialCursor, false
 }
 cursor = newCursor

 // Look for a column type
 //like col_name type
 ty, newCursor, ok := parseToken(tokens, cursor, keywordKind)
 if !ok {
 helpMessage(tokens, cursor, "Expected column type")
 return nil, initialCursor, false
 }
 cursor = newCursor

 cds = append(cds, &columnDefinition{
 name: *id,
 datatype: *ty,
 })
 }

 return &cds, cursor, true
}

INSERT语句

语法成分

INSERT INTO VALUES ( $expression[]$ )

example: INSERT INTO VALUES(1,20,Kate)

1.解析keyword INSERT

2.解析keyword INTO

3.解析keyword VALUES

4.解析symbol (

5.解析 $expression[]$

6.解析symbol )

主函数parse

主函数分号作为分隔符解析三种sql语句

go


func Parse(source string) (*Ast, error) {
 tokens, err := lex(source)
 if err != nil {
 return nil, err
 }

 ast := Ast{}
 cursor := uint(0)
 for cursor < uint(len(source)) {
 //parse each statement divide by ';' and add to ast
 stmt, newCursor, ok := parseStatement(tokens, cursor, tokenFromSymbol(semicolonSymbol))
 if !ok {
 helpMessage(tokens, cursor, "Expected statement")
 return nil, errors.New("Failed to parse,exit")
 }
 cursor = newCursor
 ast.Statement = append(ast.Statement, stmt)

 atLeastOneSemicolon := false
 for expectToken(tokens, cursor, tokenFromSymbol(semicolonSymbol)) {
 cursor++
 atLeastOneSemicolon = true
 }

 if !atLeastOneSemicolon {
 helpMessage(tokens, cursor, "Expected semi-colon delimiter between statements")
 return nil, errors.New("Missing semi-colon between statements")
 }
 }
 return &ast, nil
}

简易后端

本文重点在于解析sql语句以及前端的编写思路，这次仅仅使用一个map in memory 作为后端。

go


// backend in memory
type MemoryBackend struct {
 tables map[string]*table
}

// table
type table struct {
 columns []string
 columnTypes []ColumnType
 rows [][]MemoryCell
}

//Result
type Results struct {
 Columns []struct {
 Type ColumnType
 Name string
 }
 Rows [][]Cell
}

REPL

下面是一个简单的REPL设计思路

go


func main() {
 mb := NewMemoryBackend()

 reader := bufio.NewReader(os.Stdin)
 fmt.Println("Welcome to ")
 for {
 fmt.Print("# ")
 text, err := reader.ReadString('\n')
 text = strings.Replace(text, "\n", "", -1)

 ast, err := Parse(text)
 if err != nil {
 panic(err)
 }

 for _, stmt := range ast.Statements {
 switch stmt.Kind {
 case CreateKind:

 case InsertKind:

 case SelectKind:

 }
 }
}

其他剩余代码见github

参考

Writing a SQL database from scratch in Go

PostgreSQL documentation

gosql

基于朴素贝叶斯的中文垃圾电子邮件分类

Wed, 06 May 2020 00:00:00 +0000

基于朴素贝叶斯的中文垃圾电子邮件分类

训练数据和测试数据

本次主要使用了github上的开源数据

数据处理

首先使用正则表达式对训练集中的中文邮件的内容进行过滤，去除其中中文之外的其他字符，再将剩下的内容使用jieba进行分词，过滤掉中文停用字表中的内容。将垃圾邮件以及正常邮件的处理结果分别存放。

用两个字典spam_voca和normal_voca用于保存不同邮件中不同词语的词频，数据处理完成。

训练与预测

训练和预测的过程主要使计算$ P(Spam|word_1,word_2,…,word_n) $的概率，当这个概率大于某个阈值的时候，这个邮件被分类为垃圾邮件。

根据朴素贝叶斯的条件独立假设，并设先验概率$P(s)=P(s^{’})=0.5$,则有： P(s|w_1,w_2,…,w_n)=$\frac {P(s,w_1,w_2,…,w_n)}{P(w_1,w_2,…,w_n)}$

=$\frac {P(w_1,w_2,…,w_n|s)P(s)}{P(w_1,w_2,…,w_n)}$=$\frac {P(w_1,w_2,…,w_n|s)P(s)}{P(w_1,w_2,…,w_n|s)\cdot p(s)+P(w_1,w_2,…,w_n|s^{’})\cdot p(s^{’})}\qquad\qquad$

因为P(spam)=P(not spam),则有

$\frac {\prod\limits_{j=1}^nP(w_j|s)}{\prod\limits_{j=1}^nP(w_j|s)+\prod\limits_{j=1}^nP(w_j|s^{’})}$ 再利用贝叶斯$P(w_j|s)=\frac{P(s|w_j)\cdot P(w_j)}{P(s)}$,式子化为 $\frac {\prod\limits_{j=1}^nP(s|w_j)}{\prod\limits_{j=1}^nP(s|w_j)+\prod\limits_{j=1}^nP(s^{’}|w_j)}$

具体流程

对测试集中的每一封邮件做同样的处理，并计算得到$P(s|w)$最高的n个词，在计算过程中，若该词只出现在垃圾邮件的词典中，则令$P(w|s^{’})=0.01$，反之亦然；若都未出现，则令$P(s|w)=0.4$。PS.这里做的几个假设基于前人做的一些研究工作得出的。
对得到的每封邮件中重要的15个词利用式2计算概率，若概率$>$阈值$\alpha(一般设为0.9)$，则判为垃圾邮件，否则判为正常邮件。

具体的代码细节可以参见附加的代码。

结果

通过调整预测是使用的词汇的数量，针对本次数据集，最佳的结果是

python

选择29个词汇 : 0.9642857142857143

附加

项目结构 ├── data │ ├── 中文停用词表.txt │ ├── normal │ ├── spam │ └── test ├── main.py ├── normal_voca.json ├── pycache │ └── utils.cpython-36.pyc ├── spam_voca.json └── utils.py

具体代码

python


# utils.py
import jieba
import numpy
import re
import os
import json
from collections import defaultdict

spam_file_num=7775
normal_file_num=7063

#todo 原始邮件数据的预处理
'''
获取中文的停用词表
【停用词】（https://zh.wikipedia.org/wiki/%E5%81%9C%E7%94%A8%E8%AF%8D）
'''

def get_stopwords():
 return [
 i.strip() for i in open('./data/中文停用词表.txt', encoding='gbk')
 ]


'''
 读取原始文件，进行简单的处理和分词，返回分词列表

'''


def get_raw_str_list(path):
 stop_list = get_stopwords()
 with open(path, encoding='gbk') as f:
 raw_str = f.read()
 pattern = '[^\u4E00-\u9FA5]' #中文的unicode编码的范围
 regex = re.compile(pattern)
 ret = regex.findall(raw_str)
 handled_str = re.sub(pattern, '', raw_str)
 str_list = [
 word for word in jieba.cut(handled_str) if word not in stop_list
 ]
 return str_list

#分词以及统计词频，得到词汇表
'''
返回一个字典，记录了分词后的词汇表
path:k可以使dir或者file路径，默认为存放文本的dir
is_file_path:表示输入路径是不是文件

'''


def get_voca(path, is_file_path=False):
 if is_file_path:
 return read_voca_from_file(path)

 voca = defaultdict(int)
 # 获取垃圾邮件列表
 file_list = [file for file in os.listdir(path)]
 #获得词汇表
 for file in file_list: #测试用
 raw_str_list = get_raw_str_list(path + str(file))
 for raw_str in raw_str_list:
 voca[raw_str] = voca[raw_str] + 1

 return voca



'''
 将得到的词汇表保存到json文件中，以便下次读取
 voca:词汇表字典
 path:文件的保存路径
 sort_by_value:是否按value值排序

'''


def save_voca2json(voca, path, sort_by_value=False,indent_=4):
 if sort_by_value:
 sorted_by_value(voca)

 with open(path, 'w+') as f:
 f.write(json.dumps(voca, ensure_ascii=False, indent=indent_))


'''
从json文件中读取voca
'''

def read_voca_from_file(path):
 voca = None
 with open(path) as f:
 voca = json.load(f)
 return voca


'''
将字典基于value排序
'''

def sorted_by_value(_dict):
 _dict = dict(sorted(spam_voca.items(), key=lambda x: x[1], reverse=True))


#计算 P(Spam|word)

'''
 计算邮件和邮件分类最相关词语及其 P(spam|word)
 words_size:最终使用词语的数量，用于最后的预测

'''

def get_top_words_prob(path,spam_voca,normal_voca,words_size=30):
 critical_words=[]
 for word in get_raw_str_list(path):
 if word in spam_voca.keys() and word in normal_voca.keys():
 # 如果word在两边都出现
 p_w_s=spam_voca[word]/spam_file_num
 p_w_n=normal_voca[word]/normal_file_num
 p_s_w=p_w_s/(p_w_n+p_w_s)

 elif word in spam_voca.keys() and word not in normal_voca.keys():
 # 如果word只在spam出现
 p_w_s=spam_voca[word]/spam_file_num
 p_w_n=0.01
 p_s_w=p_w_s/(p_w_n+p_w_s)

 elif word not in spam_voca.keys() and word in normal_voca.keys():
 # 如果word只在normal出现
 p_w_s=0.01
 p_w_n=normal_voca[word]/normal_file_num
 p_s_w=p_w_s/(p_w_n+p_w_s)
 else:
 #如果都不出现
 p_s_w=0.4
 #以上设定的数值均是基于前人的研究得到的数据
 critical_words.append([word,p_s_w])

 return dict(sorted(critical_words[:words_size],key=lambda x:x[1],reverse=True))

'''
 计算贝叶斯概率
 words_prob：包含词汇以及其P(spam|word)概率的一个字典
 spam_voca:垃圾邮件词汇表
 normal_voca:正常邮件词汇表
'''


def caculate_bayes(words_prob,spam_voca,normal_voca):
 p_s_w=1
 p_s_nw=1
 for word,prob in words_prob.items():
 p_s_w*=prob
 p_s_nw*=(1-prob)

 return p_s_w/(p_s_w+p_s_nw)

def predict(bayes,threshold=0.9):
 return bayes>=threshold


'''
 返回文件名和label
'''

def get_files_labels(dir_path,is_spam=True):
 raw_files_list=os.listdir(dir_path)
 files_list= [dir_path+file for file in raw_files_list]
 labels=[is_spam for i in range(len(files_list))]
 return files_list,labels


'''
 预测测试集结果并打印
 file_list：测试集文件路径集合
 y:测试集结果标签
 word_size：预测的指标
'''

def predict_result(file_list,y,spam_voca,normal_voca,word_size=30):
 ret=[]
 right=0
 for file in file_list:
# raw_strs=get_raw_str_list(str(file))
 words_prob=get_top_words_prob(file,spam_voca,normal_voca,words_size=word_size)
 bayes=caculate_bayes(words_prob,spam_voca,normal_voca)
 ret.append(predict(bayes))
 for i in range(len(ret)):
 if ret[i]==y[i]:
 right+=1

 print(right/len(y))

python


#main.py
from utils import *

if __name__=='__main__':
 #获取词典并保存，一遍下次读取
 spam_voca=get_voca('./spam_voca.json',is_file_path=True)
 normal_voca=get_voca('./normal_voca.json',is_file_path=True)
 #保存方便下次读取
 save_voca2json(spam_voca,'./spam_voca.json')
 save_voca2json(normal_voca,'./snormal_voca.json')
 #预处理测试数据
 s_x,s_y=get_files_labels('./data/test/spam/')
 n_x,n_y=get_files_labels('./data/test/normal/',is_spam=False)
 x,y=list(s_x+n_x),s_y+n_y
 #预测结果

 for i in range(10,40):
 print(str(i)+' : ',end='')
 predict_result(x,y,spam_voca,normal_voca,word_size=i)

源码

github

C++中左值和右值的区别

Fri, 01 Nov 2019 00:00:00 +0000

C++中左值和右值的区别

最近在复习C++的语法，有一些忘记了的东西，想在这里记录一下

什么是左值和右值

抽象解释

In C++ an lvalue is something that points to a specific memory location. On the other hand, a rvalue is something that doesn’t point anywhere. In general, rvalues are temporary and short lived, while lvalues live a longer life since they exist as variables.

参考：Understanding the meaning of lvalues and rvalues in C++

具体

左值实际上就是有变量名的变量，变量名实际上指向了这个变量分配的内存地址，这个变量名在作用域内可以长期保存
右值实际上是没有变量名的临时变量，变量的内存地址没有实际的变量名去保存，所以说它是临时的，生命周期短的
左值可以转换成右值，反之，则不行

cpp


int a=10;
std::string str="Hello";
//此处的a和str是左值，它们有实际的变量名，并保存其内存的地址，而 10 和 "Hello"则是右值，他们只是临时变量。
int &b=&a;
int *a_p=&a;
//左值往往可以进行取地址操作，而右值则不行
int *a_ptr=&10;//error

//左值转右值
int x = 10;
int y = 10;
int z = x+y;
//这里 x,y本来是左值的，但放在右边相加之后的结果是一个临时的变量，成为了一个右值

左值右值作为函数的返回值

cpp


//左值作为函数返回值
int tem=0;

int& getlZero(){
 return tem;
}
getlZero() = 10 //works

//右值最为返回值
int getrZero(){
 return 0;
}

getrZero() = 10//fails

左值引用和右值引用

定义

左值引用就是对一个左值进行引用的类型。右值引用就是对一个右值进行引用的类型

右值引用和左值引用都是属于引用类型。无论是声明一个左值引用还是右值引用，都必须立即进行初始化。

而其原因可以理解为是引用类型本身自己并不拥有所绑定对象的内存，只是该对象的一个别名。左值引用是具名变量值的别名，而右值引用则是不具名（匿名）变量的别名。

对引用变量的修改会作用到原变量上。

通常左值引用通常也不能绑定到右值，但右值可以借用const+左值引用变量来引用

cpp


//左右值引用的语法
int a=10;
int &b=a; //b是a的引用，左值引用
b=20; //此时a=b=20

int &&c=10; //c是右值‘10’的引用
c=20 //此时c变成了‘20’的引用

b=10；//error。 10是一个右值，所以报错
c=a; //error。a是一个左值

const int& a=10; //works
// 在后台，编译器会创建一个隐藏变量（即左值），以在其中存储原始文字常量，然后将该隐藏变量绑定到引用中

引用作为函数的参数

cpp


int getSelfL(int& a){
 return a;
}

int getSelfR(int&& b){
 return b;
}

int getSelfLR(const int& a){
 return a;
}

int a=10;
getSelfL(a); //works
getSelfL(10); //fails

getSelfR(10); //works
getSelfR(a); //fails

getSelfRL(10); //works

将亡值

在C++11之前的右值和C++11中的纯右值是等价的。C++11中的将亡值是随着右值引用的引入而新引入的。

换言之，“将亡值”概念的产生，是由右值引用的产生而引起的，将亡值与右值引用息息相关。所谓的将亡值表达式，就是下列表达式：

1）返回右值引用的函数的调用表达式

2）转换为右值引用的转换函数的调用表达式

在C++11中，我们用左值去初始化一个对象或为一个已有对象赋值时，会调用拷贝构造函数或拷贝赋值运算符来拷贝资源, 此处的拷贝可能是浅拷贝，取决于拷贝构造函数的实现方式。

而当我们用一个右值（包括纯右值和将亡值）来初始化或赋值时，会调用移动构造函数或移动赋值运算符来移动资源，从而避免拷贝，提高效率。

当该右值完成初始化或赋值的任务时，它的资源已经移动给了被初始化者或被赋值者，同时该右值也将会马上被销毁（销毁，实际上是说这块内存区域变成了未初始化的状态）。也就是说，当一个右值准备完成初始化或赋值任务时，它已经“将亡”了。而上面1和2两种表达式的结果都是不具名的右值引用，它们属于右值

Java 多线程编程

Fri, 01 Nov 2019 00:00:00 +0000

昨天晚上再看梁勇的java进阶中的《多线程与并行程序设计》，今天想趁着写博客的机会，把我了解的记录下来。

Java 多线程编程

Java 给多线程编程提供了内置的支持。

一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。
多线程是多任务的一种特别的形式，但多线程使用了更小的资源开销。
进程：一个进程包括由操作系统分配的内存空间，包含一个或多个线程。一个线程不能独立的存在，它必须是进程的一部分。一个进程一直运行，直到所有的非守护线程都结束运行后才能结束。
多线程能满足程序员编写高效率的程序来达到充分利用 CPU 的目的。

线程的状态

线程是一个动态执行的过程，它也有一个从产生到死亡的过程（状态）。

1.新建状态: 使用 new 关键字和 Thread 类或其子类建立一个线程对象后，该线程对象就处于新建状态。它保持这个状态直到程序 start() 这个线程。

2.就绪状态: 当线程对象调用了start()方法之后，该线程就进入就绪状态。就绪状态的线程处于就绪队列中，要等待JVM里线程调度器的调度。

3.运行状态: 如果就绪状态的线程获取 CPU 资源，就可以执行 run()，此时线程便处于运行状态。处于运行状态的线程最为复杂，它可以变为阻塞状态、就绪状态和死亡状态。

4.阻塞状态: 如果一个线程执行了sleep（睡眠）、suspend（挂起）等方法，失去所占用资源之后，该线程就从运行状态进入阻塞状态。在睡眠时间已到或获得设备资源后可以重新进入就绪状态。可以分为三种：

5.等待阻塞：运行状态中的线程执行 wait() 方法，使线程进入到等待阻塞状态。

6.同步阻塞：线程在获取 synchronized 同步锁失败(因为同步锁被其他线程占用)。

7.其他阻塞：通过调用线程的 sleep() 或 join() 发出了 I/O 请求时，线程就会进入到阻塞状态。当sleep() 状态超时，join() 等待线程终止或超时，或者 I/O 处理完毕，线程重新转入就绪状态。

8.死亡状态: 一个运行状态的线程完成任务或者其他终止条件发生时，该线程就切换到终止状态。

创建任务类与线程

任务就是一种对象，其必须实现Runable接口（Runable接口中只有run()函数），并且需要重写run()，以便线程创建时调用。
线程的创建是通过Thread类来构造的，Thread类中还包含了控制线程的方法。

一个线程的创建必须基于某个任务，即：

java


 Thread thread=new Thread（new TaskClass）
 /**
 *调用thread.start()时立即调用TaskClass中的run（）
 */

Thread中的其他方法

yield()：为其他线程临时让出cpu时间
sleep()：为线程设定休眠时间，以便其他线程的执行

sleep()可能抛出一个InterruptException异常，这是一个必检异常，java强制捕获，故而sleep函数必须在try代码块中。

线程的优先级

线程是有优先级的。java虚拟机总是优先执行优先级高的线程。若所有的优先级相同，则系统依照循环队列分配相同的cpu资源，即循环调度。

Thread类中的setPriority()可设定线优先级

线程池

对于大型任务数,如果必须为每个任务创建一个线程，那么启动新线程每个任务都可能限制吞吐量并导致性能不佳。而使用线程池是理想的管理并发执行的任务数的方法。 Java 提供Exexutor接口来执行线程池中任务，用ExecutorService接口来管理和控制任务。执行器服务是执行器的子接口。通过静态方法获得Executor对象，newFixedThreadPool(int)用于创建固定数目的线程池，newCachedThreadPool()则是自动创建线程。

demo:

java


import java.util.concurrent.*;
public class ExecutorDemo {public static void main(String[] args) {
// Create a fixed thread pool with maximum three threads
ExecutorService executor = Executors.newFixedThreadPool(3);
// Submit runnable tasks to the executor
executor.execute(new PrintChar('a', 100));
executor.execute(new PrintChar('b', 100));
executor.execute(new PrintNum(100));
// Shut down the executor
executor.shutdown();
}
}

线程池提供了一种更好的管理线程的方法。线程池主要用来解决线程生命周期开销问题和资源不足问题。

线程池减少了在创建和销毁线程上所花的时间以及系统资源的开销。通过对多个任务重用线程，线程创建的开销就被分摊到了多个任务上了，而且由于在请求到达时线程已经存在，所以消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。另外，通过适当地调整线程池中的线程数目可以防止出现资源不足的情况。

线程池能够对线程进行方便的管理。比如使用ScheduledThreadPool来设置延迟N秒后执行任务，并且每隔M秒循环执行一次。

能控制线程池中的并发数。避免了因为大量的线程争夺CPU资源造成阻塞。

线程同步（Thread Synchronization）

如果同一个资源被多个线程同时访问，很可能会被破坏。如果两个任务以一种会引起冲突的方式访问一个公共资源，则称两者为竞争状态。若其没有竞争状态，则称其为线程安全的。

为避免竞争状态，应防止多个线程同事进入程序的某一特定部分，程序中这样的部分成为临界区。

解决竞争状态的方法便是使线程同步。

实现线程同步的方法

一个同步方法在执行前需要加锁。锁是一种实现资源排他的机制。对于实例方法，要给调用的对象加锁，对于静态对象，要给类加锁。

synchronized关键字

此关键字可用与方法，也可用于表达式。

java


synchronized ( expr ) {
 //do something
}

public sychronized func () {}

利用锁同步可显式的使用锁和状态来同步线程。

一个锁是Lock接口的实例，其提供了加锁和释放锁的方法。 ReentrantLock是lock的具体体现，用于创建相互排斥的锁。

demo:

public void deposit(int amount) {
lock.lock(); // Acquire the lock
try {
int newBalance = balance + amount;
// This delay is deliberately added to magnify the
// data-corruption problem and make it easy to see.
Thread.sleep(5);
balance = newBalance;
}
catch (InterruptedException ex) {
}
finally {
lock.unlock(); // Release the lock
}
}

避免死锁

多个线程需要从几个共享对象上获取锁时，可能会导致死锁。

利用资源排序避免死锁

线程间的协作

可使用条件(Condition)实现线程的通信，指定其在某种条件下做什么。

**条件(Condition)**是通过Lock对象的newCondition()方法创建的对象。通过其await(),signal(),signall()实现线程的相互通信。

await()：让当前线程进入等待，直到条件发生（发出条件信号）
signal()/signalAll()：唤醒一个和所有线程

条件必须依赖与锁才可使用。无锁儿直接使用其方法会抛出IllegalMonitorStateExecption异常。

阻塞队列

java中为多线程提供了阻塞对列，同步可在对列中实现，所以不用在使用锁和条件。它提供了两个附加操作：当队列中为空时，从队列中获取元素的操作将被阻塞；当队列满时，向队列中添加元素的操作将被阻塞。

阻塞队列常用于生产者和消费者的场景，生产者线程可以把生产结果存到阻塞队列中，而消费者线程把中间结果取出并在将来修改它们。

队列会自动平衡负载，如果生产者线程集运行的比消费者线程集慢，则消费者线程集在等待结果时就会阻塞；如果生产者线程集运行的快，那么它将等待消费者线程集赶上来。

作为BlockingQueue的使用者，我们再也不需要关心什么时候需要阻塞线程，什么时候需要唤醒线程，因为这一切BlockingQueue都给你一手包办了。

BlockingQueue的核心方法

1、放入数据

（1）put(E e):put方法用来向队尾存入元素，如果队列满，则等待。　　　

（2）offer(E o, long timeout, TimeUnit unit)：offer方法用来向队尾存入元素，如果队列满，则等待一定的时间，当时间期限达到时，如果还没有插入成功，则返回false；否则返回true；

2、获取数据

（1）take()：take方法用来从队首取元素，如果队列为空，则等待；

（2）drainTo():一次性从BlockingQueue获取所有可用的数据对象（还可以指定获取数据的个数），通过该方法，可以提升获取数据效率；不需要多次分批加锁或释放锁。

（3）poll(time):取走BlockingQueue里排在首位的对象,若不能立即取出,则可以等time参数规定的时间,取不到时返回null;

（4）poll(long timeout, TimeUnit unit)：poll方法用来从队首取元素，如果队列空，则等待一定的时间，当时间期限达到时，如果取到，则返回null；否则返回取得的元素；

一些状态

抛出异常：当队列满时，再向队列中插入元素，则会抛出IllegalStateException异常。当队列空时，再向队列中获取元素，则会抛出NoSuchElementException异常。
返回特殊值：当队列满时，向队列中添加元素，则返回false，否则返回true。当队列为空时，向队列中获取元素，则返回null，否则返回元素。
一直阻塞：当阻塞队列满时，如果生产者向队列中插入元素，则队列会一直阻塞当前线程，直到队列可用或响应中断退出。当阻塞队列为空时，如果消费者线程向阻塞队列中获取数据，则队列会一直阻塞当前线程，直到队列空闲或响应中断退出。
超时退出：当队列满时，如果生产线程向队列中添加元素，则队列会阻塞生产线程一段时间，超过指定的时间则退出返回false。当队列为空时，消费线程从队列中移除元素，则队列会阻塞一段时间，如果超过指定时间退出返回null。

并行编程

java可用Fork/Join框架实现并行编程在此框架中，一个分解（Fork)可视为运行在一个线程上的独立任务。

将一个问题分解为多个不重叠的子问题（可独立解决），再合并子问题的解答以获得整体的解答。框架使用ForkJoinTask类定义一个任务，在一个ForkJoinPool实例中执行任务。 ForkJoinTask是用于任务的基类，它是一个类似线程的实体，但比普通的线程要轻量级的多，因为巨量的任务可以被ForkJoinPool中的少数线程所执行。

demo:

import java.util.concurrent.RecursiveAction;
import java.util.concurrent.ForkJoinPool;
public class ParallelMergeSort {
public static void main(String[] args) {
final int SIZE = 7000000;
int[] list1 = new int[SIZE];
int[] list2 = new int[SIZE];
for (int i = 0; i < list1.length; i++)
list1[i] = list2[i] = (int)(Math.random() * 10000000);
long startTime = System.currentTimeMillis();
parallelMergeSort(list1); // Invoke parallel merge sort
long endTime = System.currentTimeMillis();
System.out.println("\nParallel time with "
+ Runtime.getRuntime().availableProcessors() +
" processors is " + (endTime - startTime) + " milliseconds");
startTime = System.currentTimeMillis();
MergeSort.mergeSort(list2); // MergeSort is in Listing 23.5
endTime = System.currentTimeMillis();
System.out.println("\nSequential time is " +
(endTime - startTime) + " milliseconds");
}
public static void parallelMergeSort(int[] list) {
RecursiveAction mainTask = new SortTask(list);
ForkJoinPool pool = new ForkJoinPool();
pool.invoke(mainTask);
}
private static class SortTask extends RecursiveAction {
private final int THRESHOLD = 500;
private int[] list;
SortTask(int[] list) {
this.list = list;
}
@Override
protected void compute() {
if (list.length < THRESHOLD)
java.util.Arrays.sort(list);
else {
// Obtain the first half
int[] firstHalf = new int[list.length / 2];
System.arraycopy(list, 0, firstHalf, 0, list.length / 2);
perform the task
sort a small list
split into two parts
// Obtain the second half
int secondHalfLength = list.length - list.length / 2;
int[] secondHalf = new int[secondHalfLength];
System.arraycopy(list, list.length / 2,
secondHalf, 0, secondHalfLength);
// Recursively sort the two halves
invokeAll(new SortTask(firstHalf),
new SortTask(secondHalf));
// Merge firstHalf with secondHalf into list
MergeSort.merge(firstHalf, secondHalf, list);
}
}
}
}

Java中的lambda表达式

Fri, 01 Nov 2019 00:00:00 +0000

lambda表达式

Lambda 表达式，也可称为闭包，它是推动 Java 8 发布的最重要新特性。Lambda 允许把函数作为一个方法的参数（函数作为参数传递进方法中）。使用 Lambda 表达式可以使代码变的更加简洁紧凑。

语法

lambda 表达式的语法格式如下：

java

(parameters) -> expression 或 (parameters) ->{ statements; }

以下是lambda表达式的重要特征:

**可选类型声明：**不需要声明参数类型，编译器可以统一识别参数值。
**可选的参数圆括号：**一个参数无需定义圆括号，但多个参数需要定义圆括号。
**可选的大括号：**如果主体包含了一个语句，就不需要使用大括号。
**可选的返回关键字：**如果主体只有一个表达式返回值则编译器会自动返回值，大括号需要指定明表达式返回了一个数值。

Lambda 表达式的结构

让我们了解一下 Lambda 表达式的结构。

一个 Lambda 表达式可以有零个或多个参数
参数的类型既可以明确声明，也可以根据上下文来推断。例如：(int a)与(a)效果相同
所有参数需包含在圆括号内，参数之间用逗号相隔。例如：(a, b) 或 (int a, int b) 或 (String a, int b, float c)
空圆括号代表参数集为空。例如：() -> 42
当只有一个参数，且其类型可推导时，圆括号（）可省略。例如：a -> return a*a
Lambda 表达式的主体可包含零条或多条语句
如果 Lambda 表达式的主体只有一条语句，花括号{}可省略。匿名函数的返回类型与该主体表达式一致
如果 Lambda 表达式的主体包含一条以上语句，则表达式必须包含在花括号{}中（形成代码块）。匿名函数的返回类型与代码块的返回类型一致，若没有返回则为空

lambda实例

Lambda 表达式的简单例子:

java


// 1. 不需要参数,返回值为 5 
() -> 5

// 2. 接收一个参数(数字类型),返回其2倍的值 
x -> 2 * x

// 3. 接受2个参数(数字),并返回他们的差值 
(x, y) -> x – y

// 4. 接收2个int型整数,返回他们的和 
(int x, int y) -> x + y

// 5. 接受一个 string 对象,并在控制台打印,不返回任何值(看起来像是返回void) 
(String s) -> System.out.print(s)

lambda表达式的实现原理

在 Java 中，Lambda 表达式是对象，他们必须依附于一类特别的对象类型——函数式接口(functional interface)。函数式接口是只包含一个抽象方法声明的接口。当你试图传入lambda表达式的时候，实际上它是将你传入的表达式隐式的转换并赋值给一个函数式接口，再通过其调用函数。

如：

java


 @FunctionalInterface
interface Inner {
 void print(int num);
}

public static void wapper(int num, Inner func) {
 func.print(num);
 }

java


wapper(10, e -> {
 for (int i = 0; i < e; i++) {
 System.out.print("HelloWorld\t");
 }
 });

和下面的写法等价

 Inner innerFunc = (int e) -> {
 for (int i = 0; i < e; i++) {
 System.out.print("HelloWorld\t");
 }
 };
 wapper(10, innerFunc);

进程的同步与互斥

Fri, 01 Nov 2019 00:00:00 +0000

进程的同步与互斥

[TOC]

进程的同步

引入

在多进程的系统中，进程是并发执行的，进程具有“异步”的天性，异步性指的是各并发执行的进程以各自独立的、不可预知的速度向前推进。

我们知道多进程存在对共享资源的访问，如果对异步性不加控制，那么多进程的不可预知的执行次序会导致对共享数据的脏读、误读、幻读等莫名错误，这样的话，我们的进程拿不到准确的数据，多进程的并发优势反而得不偿失。

为了能避免异步性带来的副作用，我们就引入了“进程同步”，这是个辅助手段，主要解决异步性带来的“不可预知性”。

进程同步机制就是针对解决异步进程间的执行次序的“不可预知性”，保证多个进程之间按照某种设计好的、程序能控制的执行次序，以达到对共享资源访问的能控性、有效性、准确性

进程同步的控制机制

基于 P 、 V 操作的信号量机制

最早出现的用来解决进程同步与互斥问题的机制 , 包括一个称为信号量的变量及对它进行的两个原语操作。

==key==

一个信号量的建立必须经过说明 , 即应该准确说明 s 的意义和初值 , 信号量的值仅能由 PV 原语来改变。P 操作是申请资源 , 它使信号量值减 1 , 若结果非负 , 该进程继续 , 否则该进程被封锁 ;V 操作是释放资源 , 它使信号量值增 1 ，若结果大于零 , 该进程继续 , 否则从该信号量的等待队列中移出一个进程 , 解除它的等待状态。

管程机制

概念引入：

为实现进程间的同步在每个并发进程中都要设置大量的同步操作原语 , 这不仅给编程带来麻烦 , 且会因 P 操作使用不当而导致数据的不定性或死锁;

同时操作系统的结构不够清晰。因此后来又提出了一种集中式同步进程 ———**管程 **。

基本思想：将共享变量和对它们的操作集中在一个模块中 , 操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰 , 便于维护和修改 , 易于保证正确性。
从语言的角度看，管程主要有以下特性：（1）模块。管程是一个基本程序单位，可以单独编译;
（2）抽象。管程是中不仅有数据，而且有对数据的操作;
（3）封装。管程外可以调用管程内部定义的一些函数，但函数的具体实现外部不可见;对于管程中定义的共享变量的所有操作都局限在管程中，外部只能通过调用管程的某些函数来间接访问这些变量。
为了保证共享变量的数据一致性，管程应互斥使用。
管程通常是用于管理资源的，因此管程中有进程等待队列和相应的等待和唤醒操作。

在管程入口有一个等待队列，称为入口等待队列。当一个已进入管程的进程等待时，就释放管程的互斥使用权；当已进入管程的一个进程唤醒另一个进程时，两者必须有一个退出或停止使用管程。在管程内部，由于执行唤醒操作，可能存在多个等待进程（等待使用管程），称为紧急等待队列，它的优先级高于入口等待队列。因此，一个进程进入管程之前要先申请，一般由管程提供一个enter过程；离开时释放使用权，如果紧急等待队列不空，则唤醒第一个等待者，一般也由管程提供外部过程leave。
管程内部有自己的等待机制。管程可以说明一种特殊的条件型变量：var c:condition；实际上是一个指针，指向一个等待该条件的PCB队列。
- 对条件型变量可执行wait和signal操作： wait(c):若紧急等待队列不空，唤醒第一个等待者，否则释放管程使用权。执行本操作的进程进入C队列尾部； signal(c):若C队列为空，继续原进程，否则唤醒队列第一个等待者，自己进入紧急等待队列尾部。
总结：管程(monitor)是一种基本的，高级的同步构造，是为了解决信号量因不正确的使用而导致的一些时序错误而提出的一种高级语言构造。管程也是进程同步的一种方式，相比于其他进程同步方式，管程将共享变量和对它们的操作集中在一个模块中，操作系统或并发程序就由这样的模块构成。这样模块之间联系清晰，便于维护和修改，易于保证正确性。管程只是保证了同一时刻只有一个进程在管程内活动,即管程内定义的操作在同一时刻只被一个进程调用(由编译器实现).但是这样并不能保证进程以设计的顺序执行,因此需要设置condition变量,让进入管程而无法继续执行的进程阻塞自己。

会合机制

会合机制的提出

在不具有公共内存的分布式操作系统中，要使用P，V操作或管程机制存在着十分大的问题–信号灯量和管程共享变量存放在何处？

如果分步式系统中有两个主机H1和H2，它们之间并没有公共内存，H1中有进程P1，H2中有进程P2，如果有一个信号量(或管程共享变量)S，那S放在何处呢？

如果放在H1中，显然P2无法访问到S；同理，如果放在H2中,S对P1又是不可访问的。

显然，P，V操作和管程都是以进程所操作的对象为核心的，而这些对象在无公共内存的分布式操作系统中的存储是一个不可克服的困难。

因此，自然希望在分布式操作系统中的同步机制应该避开这些被动的成分，而以主动成分–进程直接进行相互作用。因而，产生了会合这一种同步机制。

会合的一般形式 一个进程可以有许多入口，一个入口对应一段程序，一个进程可以调用另一个进程的入口。当一个进程调用另一个进程的入口，而且被调用的进程已准备好接受这个调用时，会合就发生了。

当调用者发出调用请求时，被调用的进程未准备接受这个调用时，则调用者等待；反之，当被调用者准备接受调用，而当前尚无调用者时，则被调用者等待。即先到达会合处者等待后到达者。

当多个进程调用同一个进程的同一个入口时，被调用者按先来先服务（FCFS）的次序接受调用。入口处可以携带调用参数，还可以有返回参数，以实现信息的交换。被调用者可以选择会合的入口。

Petri 网

利用Petri网进行程序设计的内容较为抽象和晦涩，在此仅大概介绍一下，有兴趣可以自行查找相关资料。

Petri 网是一种适于描述和分析异步并发系统的有力工具。Petri 网是德国的C.A.Petri 于 1962 年在他的博士论文中首先提出的 , 用以构造系统模型及动态特性分析。在计算机科学的许多领域 , 如并行计算、分布式数据库设计等 , Petri网系统已起到了越来越重要的作用。

( 1) Petri 网是以图形表示的模型 , 直观性强

( 2) Petri 网中的托肯（Petri网中的一个成分）流动表现了系统的动态演变过程。

( 3) Petri 网能准确地刻画系统的一些重要特性 , 如 : 并发、冲突、同步、异步、死锁、饥饿、溢出等。

( 4) 有一套严格的数学理论和分析方法 , 支持对系统模型的各种性质的分析和性能评价。

Petri网是一种适合于描述异步并发现象的系统模型，它既有严格的数学定义，又有直观的图形表示，借由它可以很好的表示程序的运行过程以及状态（并发、冲突、同步、异步、死锁、饥饿、溢出等 )。通过对网图的分析、同步合成和共享合成，将串行进程并行化 , 中间过程运用从粗到细的逐步精炼思想 , 最终获得一个高效、正确的并行程序。

demo:

进程的互斥

引入

“进程互斥“与“进程同步“本质上都是在围绕同一个话题在讨论，即如果保证多进程对**共享资源（如，内存数据、打印机、摄像头）**访问的可控性、有效性和正确性；

所以，共享资源才是研究的核心对象

我们在这需要讨论的是，在某个时间段内，因为存在多个进程的“异步”运行、存在对共享资源的“乱序”持有及改动，所以，如果这个“时间段”不让进程的发生切换，即限制这个时间段内，只允许一个进程开展任务，任务完成之前，该进程不释放当前持有的共享资源，其他的进程在这段时间内也不能抢占这个资源；

这种在“时间段”角度下，解决并发访问共享资源问题的机制，就叫做“进程互斥”

进程互斥的四大原则

1.空闲让进。当临界资源处于空闲状态，允许一个请求进入临界区的进程立即进入临界区，从而有效的利用资源。

2.忙则等待。已经有进程进入临界区时，意味着相应的临界资源正在被访问，所以其他准备进入临界区的进程必须等待，来保证多进程互斥。

3.有限等待。对要求访问临界资源的进程，应该保证该进程能在有效的时间内进入临界区，防止死等状态。

4.让权等待。当进程不能进入临界区，应该立即释放处理机，防止进程忙等待。

进程互斥的实现机制

下面介绍历史上对进程互斥的实现方法：

软件实现

单标志法

问题：违背“空闲让进”的原则

单标志法在一些情况下确实能达到互斥访问的效果，但是这个算法也存在很大的缺陷，比如上面的turn初始为0，如果P0进程一直还未曾执行过临界区代码，那么临界资源就不会被P0占用，并处于空闲状态，但是这种情况下，P1进程也只能看着临界资源空闲也没法占有，因为P1在第5部被while循环“卡住”了。

双标志先检查法

问题：双标志先检查法的算法设计中忽视并发进程存在异步性。违反“忙则等待”原则

具体来说，如果上图中的P0进程和P1进程在交替运行后，分别执行完了第1步和第5步，并且还未曾执行第2步和第6步，这种情况在不可预知的异步性下，是完全有可能发生的，但是如果真发生这种执行状况，那么P0和P1就都可以进入临界区了，原本想到达的互斥效果，就失败了；

这个算法错误的根本原因在于：进入区的“检查”（while轮训）和“上锁”（设置flag）两个处理不是一气呵成的；“检查”后，“上锁”前的这个时间间隙有可能会发生进程切换，导致其他进程“有机可乘”；当然，如果“检查”和“上锁”是一个不可分割的原子操作，那么这个算法的问题就可以解决了**；**

双标志后检查法

问题：与双标志先检查法一样，忽略了并发进程的异步性。

因此，双标志后检查法虽然解决了“忙则等待”的问题，但是又违背了“空闲让进”和“有限等待”原则，会因各进程都长期无法访问临界资源而产生“饥饿”现象；

Peterson算法

从Peterson算法的while条件的设计，可以看出，它综合了单标志算法和双标志检查算法的优点，做到了兼顾“公平性”和“互斥性”；

问题：依然没有遵循让权等待的原则。

事实上运用进程同步一些的机制（信号量，管程等）也能实现临界资源的互斥，在此不多说。

硬件实现

中断屏蔽方法

缺点：

不适用于多核CPU，因为关中断指令只对执行该指令的CPU有效，如果是多核CPU，那么这个指令不会影响其他核的中断处理机制；因此，这种方式只能保证执行关中断指令的这个核不进行进程切换，但是其他核的进程还是有可能丝毫不受阻拦的访问该临界资源，所以总体上看，还是没法保证进程对临界资源的互斥访问；

开关中断指令是特权指令，只能在内核态下执行，因此用户态进程无法使用这个功能，否则必须切换至内核态下；

TestAndSet指令

TSL指令是用硬件实现的，执行的过程不允许被中断，只能一气呵成 所谓“硬件实现”，可以理解为TSL看似是一堆指令的集合，但是这一堆指令可以在硬件上只需要一个时钟周期就可完成，所以这一堆指令是不会被中断，不会被破坏的；

TSL指令逻辑的C语言描述，注意这里只是描述，真实的执行过程就是一个瞬间的硬件操作而已；

cpp


//lock 表示当前临界区是否被加锁
bool TestAndSet(bool *lock){
 bool old=*lock;
 *lock=true;
 return old;
}

这段描述的核心就是共享变量lock，对于多个进程竞争临界资源时，这个共享的lock变量，是全局的、独一无二的；

下面来分析一下这段描述：

cpp


// 将TestAndSet 配合 while一起使用
while(TestAndSet(&lock)) ;
//临界区代码
lock=false;
//剩余区代码

while会陷入死循环，直到lock出现过一次false，就跳出循环接着往下执行，并且跳出循环后，lock最终还是被设成true；

因为TestAndSet()函数是硬件实现的，属于原子操作，所以当进程共享的变量lock被其他进程修改成false之后，TestAndSet能保证当前进程对lock**“瞬间”**上锁。

这个“瞬间”过程可以描述为：

获得lock的false空闲锁状态；

将lock设为true，即上锁；

基于false作为返回值来跳出while死循环；

Swap指令

Swap指令和上面的TSL指令一样，也是通过硬件实现的，执行过程不允许被中断，只能一气呵成

cpp


//swap指令的作用是交换两个变量的值。
void Swap(bool *a , bool *b){
 bool temp=*a;
 *a=*b;
 *b=temp;
}

与TSL指令类似，它能保证a、b两个变量在**“瞬间”**一定被交换成功。

cpp


//lock表示当前临界区是否被加锁。
bool old=true;
while(old==true){
 Swap(&lock,&old);
}
//临界区代码
lock=false;
//剩余区代码

while会陷入死循环，直到lock出现一次false，old就被换成false，并跳出循环，跳出循环后，lock自身变成了old的true，即实现了**“瞬间”**上锁；

这个**“瞬间”**过程的慢动作回放如下：

lock出现false，即空闲锁状态；

old被换成false，lock被换成true，即上锁；

while条件不满足，跳出死循环

关于TSL和Swap：

元素布局与定位

Thu, 01 Nov 2018 00:00:00 +0000

元素布局与定位

position 位置属性

其中有relative，absolute，static，fixed

1.relative：相对布局，相对于原来的文档流中的位置（默认位置），有left，right，top，bottom。

2.static：即默认文档流的位置

3.absolute：绝对位置，脱离出常规文档流，其原有的元素位置被回收，被其他元素顶替。其本身则相对于顶级元素body元素定位布局

关于定位的重要概念：定位上下文

4.fixed:固定定位，完全移除文档流，与absolute绝对定位类似。但它是相对于视口（浏览器窗口或者屏幕），因此它不会随着窗口的滚动而移动。

定位上下文

相对定位的参考元素，只有其存在才可进行相关的定位

display 显示属性

属性值有block、inline，和none。它可以更改元素的显示模式，如将块级元素以行内元素显示。
其中对于设定为none属性值的元素，它们都不会在页面中显示出来，原本所占有的空间也会被回收

ps:回顾

块级元素，比如段落、标题、列表等，在浏览器中上下堆叠显示。

行内元素，比如a、span、img，在浏览器中左右并排显示，只有前一行没有空间的时候才会显示到下一行。

背景

背景属性： 1.颜色：

background-color

2.图片及与其相关的属性：

background-image：url图片路径/图片文件名）添加背景图片
background-repeat：选择图片的重复方式，有 no—repeat，repeat-x，-y等

3.背景的位置：

background-position：用于控制背景的位置布局，控制的方法有关键字、百分比、与像素（ps：注意其基准点的不同）

4.背景的尺寸：

background-size：用来控制背景图片的尺寸。
控制方法：
1.百分比：按比例缩放
2.像素：固定缩放
3.cover：拉大图片，使其完全填满背景区，保持宽高比
4.contain：缩放图片，使其恰好适合背景区，保持宽高比

5.背景粘附：

background-attachment：控制滚动元素内背景图片是否随滚动元素而滚动。
如：background-attachment：fixed；

6.简写背景属性：

即将‘-’后面的内容省略，直接将属性只写在括号内。如：

body{background:url(.../...) fixed no-repeat}

ps:CSS允许添加多背景图片，其中先添加的图片位于上层。

字体

字体样式的属性：

1.font-family:字体族，字体类型，可继承。

设置字体栈:以防字体无效，多罗列出一些字体以备用，如：

body{font-family:"trebuchet ms"(当字体名字有空格时，用”“括起来),tahoma,sans-sreif;}
//按先后顺序优先

2.font-size:字体大小，有相对单位与绝对单位，相对单位可继承。

绝对单位：像素与一些如同x-small等基准大小

相对单位：百分比、em、rem。

如果给某个元素设定了相对字体大小，则该元素的字体大小要相对于最近的设定过字体大小的祖先元素来确定。

rem相对单位：相对与HTML根元素的大小。集两种单位的优点于一身。

3.font-style:字体样式，设定是正体还是斜体

属性值：italic（斜体）、oblique（斜体）、normal（正体）。

4.font-wight:字体粗细

属性值：100……等以及bold和normal等

5.font-variant:字体变化

属性值：normal，small-caps 6.font(简写属性):

示例：

p{font:bold italic small-caps .9em helvetica,arial,san-serif;}

文本属性

p{
text-indent:3em;
letter-spacing：2em；
word-spacing：2em；
text-decoration：underline；
text-align:center;
text-height：1.5（即为字体的1.5倍）；
span：vertical-align：60%；
}

1.text-indent:文本缩进,正值向右缩进。属性可被子元素继承，且继承的是依据父元素计算的具体数值。

2.letter-spacing:在默认基础上改变字符间距,无论如何一定要使用相对单位，以便缩放。

3.word-spacing：单词间距，类似。

4.text-decoration:文本装饰，主要用于链接添加下划线。

属性值：underline、overline、line-through、blink、none

5.text-align:文本对齐

属性值：left，right，center、justify（两端对齐）。

6.line-height：行高，与外边距不同，不叠加，其余类似。属性值为任意的值，不用添加单位。可用于除去大标题的空白。
7.text-transformation：用于转换字母的大小写。
8.span：垂直对齐，属性值为任意数值或者一些关键字。用于书写上标或者下标。

web字体大揭秘

可调用远程服务器中的字体给浏览器使用。