Mer's Blog

Ceph-读写流程：客户端写流程分析(二)

Mon, 29 May 2023 03:36:46 +0000

本文接上文对 Filer::write_trunc 及之后的流程做了梳理和总结.

正文

本文是 Ceph 读写流程：客户端写流程分析的后续，前文包括 ll_open 和 ll_write 的处理流程。

Client 通过 Filer::write_trunc 写文件时会做两件事：通过 Striper::file_to_extents 做一次客户端条带化，将要写入的部分转换为对象的 extent 集合；接着通过 objecter->sg_write_trunc 进行写入

void write_trunc (...)
{
 vector<ObjectExtent> extents;
 Striper::file_to_extents(cct, ino, layout, offset, len, truncate_size,
			 extents);
 objecter->sg_write_trunc(extents, snapc, bl, mtime, flags,
		 truncate_size, truncate_seq, oncommit, op_flags);
}

而在 sg_write_trunc 中，objecter 会向每个 ObjectExtent 对应的 OSD 发送 op 请求，这里通过 write_trunc 完成，考虑 extents.size() == 1 的情况如下：

Ceph-Fuse Perms heap-buffer-overflow 问题

Sun, 23 Apr 2023 08:20:53 +0000

Ceph-fuse 带 Address-Sanitizer 跑发现只要 MDS 切换就会导致客户端 heap-buffer-overflow (ASAN 信息附在最后)

问题分析

带 debuginfo 的情况下 ASAN 报的信息还是比较全的，说踩内存的地方在 src/messages/MClientRequest.h:151 的 MClientRequest::set_gid_list 函数中，并且指出这里尝试读了一个野指针，看下 MClientRequest::set_gid_list 函数这里的行为：

	void set_gid_list(int count, const gid_t *gids) {
		gid_list.reserve(count);
		for (int i = 0; i < count; ++i) {
→ gid_list.push_back(gids[i]);
		}
	}

可以看到这里问题就在 gids 上，看一下这个指针是哪里传进来的：

Ceph MDS InodeTable 分配流程和故障分析

Fri, 14 Apr 2023 00:33:43 +0000

本文对 Ceph 中 inode 分配流程进行了总结，并解释了 MDS 重启过程中可能遇到的一个故障

inode 分配流程

在 Ceph 中我们创建目录、文件、软链接时都需要为其分配一个 inode 作为唯一标识，这一分配过程在 Server::prepare_new_inode 中完成，而分配的依据，也就是哪些 inode 还没有被分配，哪些
被分配了还没有生效（落盘）则是记录在 InoTable 中:

class InoTable : public MDSTable {
...
private:
 interval_set<inodeno_t> free; // unused ids
 interval_set<inodeno_t> projected_free;
...

其中 free 记录的就是没有被分配的 inode 集合，而 projected_free 则是从 free 中剔除了已经被分配但是还没有落盘的部分，因此 projected_free 是 free 的子集，同时显然分配也首先要在 projected_free 中来做。

Ceph MDS MetaBlob 分析

Thu, 06 Apr 2023 07:28:29 +0000

CephFS 中会把多种事件记录在不同类型的 LogEvent 中，其中最常见的也是最重要的就是读写流程中处理客户端请求时记录的 EUpdate 事件，而在 EUpdate 中又会把元数据的状态保存在 MetaBlob 结构中，本文就主要对 MetaBlob 结构以及其中保存的内容做一个总结。

MetaBlob 类定义看上去比较复杂，实际最重要的成员只有三个：

class EMetaBlob {

public:
 // my lumps. preserve the order we added them in a list.
 std::vector<dirfrag_t> lump_order;
 std::map<dirfrag_t, dirlump> lump_map;
 std::list<fullbit> roots;

其中 lump_order 保存从根目录到父母路的 Dir 分片信息 dirfrag_t，lump_map 中保存 dirfrag_t 到 dirlump 的映射关系， dirlump 中保存的就是相关的元数据信息，最后 roots 保存的就是 root 节点的 fullbit 信息，fullbit 表示一个存在的 dn + inode，相对的 MetaBlob 中使用 null_bit 结构保存一个不存在的 dentry

Paxos 算法以及 Ceph 实现

Wed, 05 Apr 2023 14:57:58 +0000

本文包含 Paxos、Multi-Paxos 算法的原理以及 Ceph 中对 Paxos 算法的实现。

Basic Paxos 和 Multi-Paxos

Paxos 和 raft 算法看过不少次，但是始终属于一知半解，也没有个记录，这次把 Paxos 和 Multi-Paxos 的原理和 ceph 中 Paxos 的实现都记录一下：

首先是 Paxos 算法，朴素的 Paxos 算法是不包含 leader 角色的：

proposer (提议者): 提出提案，包含提案编号（proposal ID）和一个要协商的值（Val）
acceptor (决策者)：参与决策，回应收到的来自 proposer 的提案，当多数 acceptor 赞成时提案通过，一般来说一个 proposer 同时也是一个 acceptor

Basic Paxos 算法通过两阶段通过一个决议：

Ceph 读写流程：客户端写流程分析

Sat, 01 Apr 2023 10:01:16 +0000

本文对 Ceph 客户端写流程进行了梳理和总结，包括 ll_open 和 ll_write 的处理流程。

正文

首先用户需要通过 ll_open 打开文件并拿到 fh，第一步先做权限检查，进入 may_open, 这里会根据用户带回的 flags 确定 want 是 MAY_WRITE 还是 MAY_READ, 接着通过一次 getattr 拿到文件的 mode, 当然这里 getattr 不是每次都发，只有 client 认为自己的所持有的文件权限不是最新的时候才会发，具体有两种情况：

开启 acl 并且没有拿过文件的 xattr (acl 设置是外带在 xattr 中的，不在 inode 里)
caps_issued_mask 认为当前 client 的 caps 不足以保证所持有的权限为最新时

Client::_getattr 判断是否需要发送请求

int Client::_getattr(Inode *in, int mask, const UserPerm& perms, bool force)
{
 bool yes = in->caps_issued_mask(mask, true);

 if (yes && !force)
 return 0;
...
// force 和 mask:
int Client::_getattr_for_perm(Inode *in, const UserPerm& perms)
{
 int mask = CEPH_STAT_CAP_MODE;
 bool force = false;
 if (acl_type != NO_ACL) {
 mask |= CEPH_STAT_CAP_XATTR;
 force = in->xattr_version == 0;
 }
 return _getattr(in, mask, perms, force);
}

简单解释一下第二点就是如果 client 没有持有 As （开启 acl 的话还需要 Xs）那么就需要向 mds 发 getattr
拿到 perm 之后做一个 inode_permission 检查一下 mode (如果设了 acl 那就检查 acl)

Ceph 读写流程：file_to_extents 过程分析

Thu, 30 Mar 2023 06:02:08 +0000

本文介绍 Ceph 中条带化的相关概念并对 Striper::file_to_extents 的流程进行了分析和总结。

在 Client::_write 中客户端通过 filer->write_trunc 对文件进行写入，write_trunc 其中分为两步:

通过 Striper::file_to_extents 对请求进行拆分，也就是将对文件的读写请求转换为对对象的读写请求
通过 objecter->sg_write_trunc 把数据写到 object 中

本文主要对其中的第一步，也就是 Striper::file_to_extents 的过程进行分析。

Ceph 中的 Stripping

在正式开始先简单介绍一下 Ceph 中条带化（Stripping）读写的相关概念：

为什么要使用 Stripping

最主要的原因就是由于单个存储设备存在吞吐量限制，例如一块机械硬盘的写入能力最大也不过 200MB/s, 在与内存、固态缓存甚至是万兆网络的吞吐量对比下无疑就是整个系统中最大的短板，那么条带化就是用来解决存储设备性能瓶颈，提高存储系统吞吐量的东西。

那么什么是条带化，说的准确一点就是把信息的连续部分存储在多个存储设备上，说人话就是把一个文件切成多份放在不同的磁盘上，每次对文件中一段内容的读写会同时发给多个盘，这样的话我们实际的写入速度就变成了多个磁盘的写入速度总和。

Ceph 中的条带化的概念大致和其他存储没有区别，只不过在 Ceph 中所有的存储最后都会落到 object 也就是对象上，而对象的存储是没有条带化的，因此文件的条带化实际上是在客户端上进行的，也就是我们本文的主要内容 file_to_extents 的过程

Ceph 挂载点压缩提示 File changed as we read it 问题分析

Mon, 27 Mar 2023 06:50:07 +0000

使用 CephFS 的同学可能会发现如果在 CephFS 挂载点下去压缩文件的时候有时候会提示 File changed as we read it，有时候还会导致
CRC 失败，本文对 File changed as we read it 问题出现的原因进行了分析并给出了解决办法，希望能对大家有所帮助。

问题现象

首先这个问题可能导致的现象比较多样，最基础的就是把一个压缩文件解压一下然后立马压缩，这时就会提示 File changed as we read it 如下：

[root@An1Uit ceph-fuse]# ./tar.sh
tar: cmake-3.7.2/Tests/LinkFlags: 在我们读入文件时文件发生了变化
tar: cmake-3.7.2/Tests/SimpleCOnly: 在我们读入文件时文件发生了变化
tar: cmake-3.7.2/Tests/ObjC++: 在我们读入文件时文件发生了变化

那除了这个现象以外还可能导致一些应用的 CRC 校验失败，或者 nfs 的 REMOTE I/O ERROR

Ceph MDS Stuck in Client Replay 问题分析

Sun, 26 Mar 2023 04:34:54 +0000

最近一直在做 MDS 高可用方面的工作，发现 MDS （带 IO）重启时可能会长时间卡在 Client Replay 状态。这里对问题的原因做了一下分析，并给出了现有的以及未来的解决办法，希望能对大家有所帮助。

问题现象梳理

通过 ceph -s 看到 MDS 的状态长时间在 client replay 状态不变化：

[root@node2 ~]# ceph -s
 cluster:
 ...
 mds: cephfs: 1/1 {0=node2=up:clientreplay}

查看 MDS 状态会发现 clientreplay_queue 不为空，但是如果打开 MDS 日志会发现 MDS 什么都没做（除了心跳）：

如何实现一个最小堆

Sat, 25 Mar 2023 17:36:41 +0000

本文介绍如何使用 C++ 实现一个通用的、线程安全的最小堆

顺便一提，写此文的时候突然想到了多年以前（16、17年）盛行的 Mooc，当时国内有很多类似的慕课网站，也有很多优秀的课程，我的基础数据结构和算法就是一位 ACM 铜牌的老师教的，至今受用，但是现在好像很少看到此类网站了，还是比较可惜的。

进入正题，最小堆本身是一个完全二叉树，保证每一个节点都不会大于其左右子节点，要实现一个最小堆的两个核心函数是 sift_up 和 sift_down，用于调整最小堆结构以符合定义。

首先给出 MinHeap 的基本定义和成员变量：

template <std::three_way_comparable T>
class MinHeap
{
 std::shared_mutex mtx;
 std::vector<T> vec;
};

这里 vec 用于保存最小堆的各个节点（完全二叉树很适合用数组保存），而 std::three_way_comparable 则是对容器元素类型的 concept 约束，要求元素类型必须是可比较的，毕竟不可比较的话也就没有“最小”的概念了。

sift_down 和 sift_up 是相反的一组用于调整堆的操作，sift_down 用于将一个元素向下调整至满足最小堆的条件，sift_up 则相反，由此可以知道对于任何一个完全二叉数我们只需要上到下执行 sift_down 或者从下到上执行 sift_up 就可以使得堆中的每一个节点都满足最小堆的条件

C++ Coroutine: 通用异步任务 Task

Sat, 25 Mar 2023 12:19:31 +0000

本文使用协程实现了一个通用的异步任务执行类 Task，支持设置回调函数并将在 Task 完成后执行回调。

Task、TaskPromise 和 TaskAwaiter 覆盖到了大部分的协程执行过程，把这几个类的实现理解了那基本上就可以说已经理解了 c++ 协程的工作方式。

阅读下面这段代码的方式建议通过 main 函数开始，对照运行结果一点一点来看。

Source Code

#include <iostream>
#include <coroutine>
#include <functional>
#include <exception>
#include <optional>
#include <atomic>
#include <utility>
#include <chrono>
#include <thread>
#include <list>
#include <condition_variable>
#include <algorithm>
#include <atomic>

#define debug(info) std::cout << __LINE__ << " " << __func__ << ": " << info << std::endl;

template<typename Task>
struct Result
{
 // 初始化为默认值
 explicit Result() = default;

 // 当 Task 正常返回时用结果初始化 Result
 explicit Result(Task &&value) : _value(value) 
 {
 debug("Construct from value");
 }

 // 当 Task 抛异常时用异常初始化 Result
 explicit Result(std::exception_ptr &&exception_ptr) : _exception_ptr(exception_ptr)
 {
 debug("Construct from exception_ptr");
 }

 // 读取结果，有异常则抛出异常
 Task get_or_throw()
 {
 if (_exception_ptr)
 {
 std::rethrow_exception(_exception_ptr);
 }
 return _value;
 }

 private:
 Task _value{};
 std::exception_ptr _exception_ptr;
};

template<template<typename> class Task, typename R>
struct TaskAwaiter {
 explicit TaskAwaiter(Task<R> &&task) noexcept
 : task(std::move(task))
 {
 debug("Construct from task");
 }

 TaskAwaiter(TaskAwaiter &&completion) noexcept
 : task(std::exchange(completion.task, {}))
 {
 debug("Construct from completion");
 }

 TaskAwaiter(TaskAwaiter &) = delete;

 TaskAwaiter &operator=(TaskAwaiter &) = delete;

 constexpr bool await_ready() const noexcept
 {
 debug("");
 return false;
 }

 void await_suspend(std::coroutine_handle<> handle) noexcept
 {
 debug("");
 std::cout << handle.address() << std::endl;
 // 当 task 执行完之后调用 resume
 task.finally([handle]() {
 handle.resume();
 });
 }

 // 协程恢复执行时，被等待的 Task 已经执行完，调用 get_result 来获取结果
 R await_resume() noexcept
 {
 debug("");
 return task.get_result();
 }

 private:
 Task<R> task;
};

template<template<typename> class Task, typename ResultType>
struct TaskPromise
{
 auto initial_suspend() noexcept
 {
 debug("");
 return std::suspend_never{};
 }
 auto final_suspend() noexcept
 {
 debug("");
 return std::suspend_always{};
 }

 Task<ResultType> get_return_object()
 {
 return Task{std::coroutine_handle<TaskPromise>::from_promise(*this)};
 }

 void unhandled_exception()
 {
 debug("");
 std::lock_guard lock(completion_lock);
 result = Result<ResultType>(std::current_exception());
 completion.notify_all();
 // 调用回调
 notify_callbacks();
 }

 void return_value(ResultType value)
 {
 debug("");
 std::lock_guard lock(completion_lock);
 result = Result<ResultType>(std::move(value));
 completion.notify_all();
 // 调用回调
 notify_callbacks();
 }

 ResultType get_result()
 {
 debug("from TaskPromise");
 // 如果 result 没有值，说明协程还没有运行完，等待值被写入再返回
 std::unique_lock lock(completion_lock);
 if (!result.has_value()) {
 debug("hasn't value now");
 // 等待写入值之后调用 notify_all
 completion.wait(lock);
 } else {
 debug("already has value now");
 }
 // 如果有值，则直接返回（或者抛出异常）
 return result->get_or_throw();
 }

 void on_completed(std::function<void(Result<ResultType>)> &&func)
 {
 debug("");
 std::unique_lock lock(completion_lock);
 // 加锁判断 result
 if (result.has_value()) {
 debug("already has value");
 // result 已经有值
 auto value = result.value();
 // 解锁之后再调用 func
 lock.unlock();
 func(value);
 } else {
 debug("waiting for execution");
 // 否则添加回调函数，等待调用
 completion_callbacks.push_back(func);
 }
 }

 // 注意这里的模板参数
 template<typename _ResultType>
 auto await_transform(Task<_ResultType> &&task)
 {
 debug("");
 return TaskAwaiter<Task, _ResultType>{std::move(task)};
 }

 private:

 // 回调列表，我们允许对同一个 Task 添加多个回调
 std::list<std::function<void(Result<ResultType>)>> completion_callbacks;
 
 void notify_callbacks()
 {
 debug("");
 auto value = result.value();
 for (auto &callback : completion_callbacks) {
 debug("call callback function from completion_callbacks");
 callback(value);
 }
 // 调用完成，清空回调
 completion_callbacks.clear();
 }

 // 使用 std::optional 可以区分协程是否执行完成
 std::optional<Result<ResultType>> result;

 std::mutex completion_lock;
 std::condition_variable completion;
};

template<typename ResultType>
struct Task
{

 // 声明 promise_type 为 TaskPromise 类型
 using promise_type = TaskPromise<Task, ResultType>;

 ResultType get_result()
 {
 debug("from Task");
 return handle.promise().get_result();
 }

 Task &then(std::function<void(ResultType)> &&func)
 {
 debug("task id = " + std::to_string(task_id));
 std::cout << handle.address() << std::endl;
 handle.promise().on_completed([func](auto result) {
 try {
 func(result.get_or_throw());
 } catch (std::exception &e) {
 // 忽略异常
 }
 });
 return *this;
 }

 Task &catching(std::function<void(std::exception &)> &&func)
 {
 debug("task id = " + std::to_string(task_id));
 handle.promise().on_completed([func](auto result) {
 try {
 // 忽略返回值
 result.get_or_throw();
 } catch (std::exception &e) {
 func(e);
 }
 });
 return *this;
 }

 Task &finally(std::function<void()> &&func)
 {
 debug("task id = " + std::to_string(task_id));
 std::cout << handle.address() << std::endl;
 handle.promise().on_completed([func](auto result) { func(); });
 return *this;
 }

 explicit Task(std::coroutine_handle<promise_type> handle) noexcept: handle(handle), task_id(cnt)
 {
 ++cnt;
 debug("Construct from handle, task id = " + std::to_string(task_id));
 std::cout << handle.address() << std::endl;
 }

 Task(Task &&task) noexcept: handle(std::exchange(task.handle, {})), task_id(cnt)
 {
 ++cnt;
 debug("Move Construct from task, task id = " + std::to_string(task.task_id) << "->" << std::to_string(task_id));
 std::cout << handle.address() << std::endl;
 }

 Task(Task &) = delete;

 Task &operator=(Task &) = delete;

 ~Task() {
 if (handle) handle.destroy();
 }

 private:
 std::coroutine_handle<promise_type> handle;
 static std::atomic<int> cnt;
 const int task_id;
};

template <typename T>
std::atomic<int> Task<T>::cnt = 0;

Task<int> simple_task2() {
 debug("task 2 start ...");
 using namespace std::chrono_literals;
 std::this_thread::sleep_for(1s);
 debug("task 2 returns after 1s.");
 co_return 2;
}

Task<int> simple_task3() {
 debug("in task 3 start ...");
 using namespace std::chrono_literals;
 std::this_thread::sleep_for(2s);
 debug("task 3 returns after 2s.");
 co_return 3;
}

Task<int> simple_task() {
 debug("task start ...");
 auto result2 = co_await simple_task2();
 debug("returns from task2: " + std::to_string(result2));
 auto result3 = co_await simple_task3();
 debug("returns from task3: " + std::to_string(result3));
 co_return 1 + result2 + result3;
}

int main() {
 auto simpleTask = simple_task();
 std::cout << "======================" << std::endl;
 simpleTask.then([](int i) {
 debug("simple task end: " + std::to_string(i));
 }).catching([](std::exception &e) {
 debug("error occurred" + std::string{e.what()});
 });
 std::cout << "======================" << std::endl;
 try {
 auto i = simpleTask.get_result();
 debug("simple task end from get: " + std::to_string(i));
 } catch (std::exception &e) {
 debug("error: " + std::string{e.what()});
 }
 return 0;
}

运行结果分析

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0

// 这里通过 auto simpleTask = simple_task(); 构建第一个 Task1 0x5562ea17feb0
250 Task: Construct from handle, task id = 0
0x5562ea17feb0
// 构建协程类第一步 initial_suspend
100 initial_suspend: 
// 这里因为 suspend_never 所以继往下走
295 simple_task: task start ...
// 通过 auto result2 = co_await simple_task2(); 构建第二个 Task2 0x5562ea180fe0
250 Task: Construct from handle, task id = 1
0x5562ea180fe0
100 initial_suspend: 
279 simple_task2: task 2 start ...
282 simple_task2: task 2 returns after 1s.
// 一直走到 co_return 2; 进入 TaskPromise::return_value
126 return_value: 
// 通过 result = Result<ResultType>(std::move(value)); 用 value(2) 构建了一个 Result
26 Result: Construct from value
// 中间调了 completion.notify_all(); 但是这里没有 wait
// 继续在 TaskPromise::return_value 中 notify_callbacks();
181 notify_callbacks: 
// co_return 之后这个协程 0x5562ea180fe0 就结束了 (还没释放，因为 finial 是 suspend_always)
105 final_suspend: 
// 这里把 co_return 的结果给到 Task1 的 TaskPromise
170 await_transform: 
// await_transform 返回一个 TaskAwaiter, 把刚刚的 Task2 存起来了（移动拷贝）
257 Task: Move Construct from task, task id = 1->2
0x5562ea180fe0
55 TaskAwaiter: Construct from task
// 这里先判断 ready, 直接返回 false
70 await_ready: 
// false 的情况下需要 suspend (注意这里传入的参数 handle 是 Task1 的 handle)
76 await_suspend: 
0x5562ea17feb0
// 这里 task.finally([handle]() { 就是刚刚存起来的 Task2
// 传了一个回调去 handle.resume();
241 finally: task id = 2
0x5562ea180fe0
// handle.promise().on_completed([func](auto result) { func(); });
149 on_completed: 
// 这里判断了一下 result 有没有值, 那么这里因为是 Task2 的 Promise 
// 所以 result 在刚刚 return_value 填充上了
153 on_completed: already has value
// 这里是通过刚刚的回调调到的 Task1 Promise 的 handle.resume()
87 await_resume: 
// 这里 return task.get_result(); 这里的 task 是刚刚传到 TaskAwaiter 的 Task2
207 get_result: from Task
136 get_result: from TaskPromise
// 这里还是一样的 result 是 value(2)
144 get_result: already has value now
// 这里因为 TaskAwaiter 在 finally 中 resume 了 Task1 的 handle 所以继续进行
297 simple_task: returns from task2: 2
// 通过 auto result3 = co_await simple_task3(); 构建 Task3 0x5562ea180fe0
250 Task: Construct from handle, task id = 3
0x5562ea180fe0
// 后面 Task3 执行和返回的过程大部分都一样的
100 initial_suspend: 
287 simple_task3: in task 3 start ...
290 simple_task3: task 3 returns after 2s.
126 return_value: 
26 Result: Construct from value
181 notify_callbacks: 
105 final_suspend: 
170 await_transform: 
257 Task: Move Construct from task, task id = 3->4
0x5562ea180fe0
55 TaskAwaiter: Construct from task
70 await_ready: 
76 await_suspend: 
0x5562ea17feb0
241 finally: task id = 4
0x5562ea180fe0
149 on_completed: 
153 on_completed: already has value
87 await_resume: 
207 get_result: from Task
136 get_result: from TaskPromise
144 get_result: already has value now
// 一直到这里同样 Task1 通过 Task3 的回调被 resume 继续执行
299 simple_task: returns from task3: 3
// 这里 co_return 1 + result2 + result3; 调到 return_value
126 return_value: 
// 这里和前面一样同样构建了 Result
26 Result: Construct from value
181 notify_callbacks: 
// 这里 Task 也走完了, suspend
105 final_suspend: 
======================
// 刚刚所有的过程只在声明了 simpleTask 之后就执行完了
// 接着调用 simpleTask.then()
213 then: task id = 0
0x5562ea17feb0
// 那这里同样之前已经有值了
149 on_completed: 
153 on_completed: already has value
// 这里通过 on_completed 调回到 lambda 回调 debug("simple task end: " + std::to_string(i));
306 operator(): simple task end: 6
// 这里 catch 了一下异常，但是因为没有异常所以没有触发 debug("error: " + std::string{e.what()});
227 catching: task id = 0
149 on_completed: 
153 on_completed: already has value
======================
// try-catch 里的逻辑也类似
207 get_result: from Task
136 get_result: from TaskPromise
144 get_result: already has value now
313 main: simple task end from get: 6

References

渡劫 C++ 协程（4）：通用异步任务 Task

Ceph Client 中的 LRU 设计

Wed, 08 Mar 2023 13:38:20 +0000

在 Ceph 中 Client 和 MDS 部分的 lru 实现和淘汰策略稍有不同，但作用都是用来管理 dentry 等结构，方便及时将不使用的文件和目录清出内存，这里主要关注 lru 的实现而不关注 dentry 的淘汰时机。

首先看下 LRU 的结构：

// lru.h
class LRU {
// ...
private:
 using LRUList = xlist<LRUObject*>;
 LRUList top, bottom, pintail;
}

这里和大部分 LRU 的实现类似， ceph 也使用一个双向链表作为 lru 的基础结构（也就是这里的 xlist，基本可以当作一个双向链表看待）。只不过 ceph 同时使用了三个链表 top、bottom 和 pintail 来细化 lru 的不同位置。

C++20 Asio With Boost 获取 B 站徽章（直播间牌子）

Sat, 25 Feb 2023 14:17:24 +0000

本文介绍了如何使用 C++20 with Asio (Boost 版本) 完成一个简单的客户端用于获取 B 站徽章。

强烈推荐昨天发现的一个视频《Why C++20 is the Awesomest Language for Network Programming》，可以去油管上搜一下，总时长一个小时，比较长但是讲的很好，听的巨舒服，上次有这种感觉还是听那个 c10k 问题的视频。

总之先看一下程序执行的效果：

1
2
3

➜ bili-medal git:(master) ./build/main {my_cookie}
当前登录账号的 mid 为 29248492
当前登陆账号所佩戴的直播间徽章为 "ASAKI", 等级为 15 级

贴一下主要逻辑：

awaitable<void> start(asio::io_context &ctx, const std::string &cookie)
{
 const std::string host = "api.bilibili.com";

 // 解析域名
 auto [e1, endpoint] = co_await tcp::resolver(ctx).async_resolve(host, "https", use_nothrow_awaitable);

 // ssl_ctx 用于建立 https 连接
 ssl::context ssl_ctx {ssl::context::sslv23};
 ssl_socket socket {ctx, ssl_ctx};

 static_assert(std::is_same_v<std::decay_t<decltype(socket.next_layer())>, tcp::socket>);

 // 建立 tcp 连接
 ssl_ctx.set_default_verify_paths();
 auto [e2, _] = co_await asio::async_connect(socket.lowest_layer(), endpoint, use_nothrow_awaitable);

 // https 握手，建立 https 连接
 auto [e3] = co_await socket.async_handshake(ssl::stream_base::client, use_nothrow_awaitable);

 std::string mid;
 {
 // 创建并发送一个 api 请求到 B 站服务器，获得返回结果并解析 mid 字段
 auto request = make_request(http::verb::get, host, "/x/web-interface/nav", cookie);
 auto response = co_await async_send_request(socket, request);
 auto data = json::parse(beast::buffers_to_string(response.body().data()));
 mid = data["data"]["mid"].dump();
 }
 std::cout << "当前登录账号的 mid 为 " << mid << std::endl;

 std::string medal_id, medal_name, medal_level;
 {
 // 创建并发送一个 api 请求到 B 站服务器，获得返回结果并解析直播间徽章
 auto request = make_request(http::verb::get, host, "/x/space/acc/info?mid="+mid, cookie);
 auto response = co_await async_send_request(socket, request);
 auto data = json::parse(beast::buffers_to_string(response.body().data()));
 medal_id = data["data"]["fans_medal"]["medal"]["medal_id"].dump();
 medal_level = data["data"]["fans_medal"]["medal"]["level"].dump();
 medal_name = data["data"]["fans_medal"]["medal"]["medal_name"].dump();
 }
 std::cout << "当前登陆账号所佩戴的直播间徽章为 " << medal_name << ", 等级为 " << medal_level << " 级" << std::endl;
}

整体流程我觉得是比较清晰的，基本上对 https 请求过程有所了解的话应该能容易能理解这里做了什么。

ChatGPT 注册教程

Sat, 18 Feb 2023 12:55:03 +0000

ChatGPT 推出已经有一段时间了，但是由于地区政策国内很多小伙伴都还没有能有机会区体验 AI 的魅力，这里就给大家介绍一下如何注册和使用 ChatGPT

前期准备

要使用 ChatGPT, 你需要如下几样东西：

1
2
3

- 一个科学且靠谱的上网办法
- 一个邮箱用于接收验证码
- 一个 Google 账号用于快速注册登录 (可选)

接着切换你的代理节点，尝试打开 ChatGPT 的登陆页面

如果你看到如下画面：

恭喜你此节点可以用于访问 ChatGPT，但如果 ChatGPT 提示 Access Deined,那就说明此节点被列入黑名单，需要换一个节点再试。

另外需要注意的一点是，尽量优先尝试使用非香港节点登录 ChatGPT

确认节点是否可用的原因是等下会用到一个接码平台用于注册 ChatGPT，要花几块钱，这里如果没有可用节点的话，等下充值甚至注册了没法用就很难受。

开始注册

前期准备完成以后点击 Sign up 进入 ChatGPT 的注册页面，显示如下：

如何向 STL 算法中传入重载函数

Fri, 01 Jul 2022 04:02:45 +0000

本文分享如何向 STL 算法中传入重载函数，来自 Jonathan 2017 年在 Fluent C++ 上发起的一个挑战

1
2
3

The STL is a fantastic tool to make your code more expressive and more robust. If you’re a C++ developer and want to become proficient, it is essential that you learn the STL.

But there is one case where we can’t apply STL algorithms right out of the box: when the function passed has overloads.

大概意思是说 STL 本身非常好用，但是如果传递一个具有重载的函数就会使得 STL 失效。

RAC 集群访问过程分析

Fri, 15 Apr 2022 09:09:54 +0000

本文介绍了通过 WireShark 分析的在 RAC11gR2 集群访问中连接建立的过程

环境

环境：

主机：192.168.40.37

SCAN节点：192.168.40.234

节点1：192.168.40.230 vip：192.168.40.231

节点2：192.168.40.232 vip：192.168.40.233

连接过程

主机与scan节点进行三次握手，建立tcp连接（目的端口1521）
主机向scan节点发送Oracle-TNS（Transparent Network Substrate Protocol）Request，主要携带信息如下：

Packet Type: Connect (1)
Connect
 Version: 314
 Service Options: 0x0041
 Session Data Unit Size: 8192
 Maximum Transmission Data Unit Size: 32767
 NT Protocol Characteristics:0xc60e, Hangon to listener connect, Confirmed release, Callback IO supported, ASync IO Supported, Generate SIGURG signal, Urgent IO supported, Full duplex IO supported
 Value of 1 in Hardware: 0100
 Connect Flags 0:0x41, NA services wanted
 Connect Flags 1:0x41, NA services wanted
 Trace Cross Facility Item 1: 0x00000000
 Trace Cross Facility Item 2: 0x00000000
 Trace Unique Connection ID: 0x0000000000000000
 Connect Data: (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=MER)(CID=(PROGRAM=E:\Navicat?for?Oracle\navicat.exe)(HOST=DESKTOP-PSOJPQF)(USER=MER)))(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.40.234)(PORT=1521)))

scan返回TNS Response, Redirect消息

Windows7 下安装 Oracle RAC11gR2

Tue, 12 Apr 2022 03:24:51 +0000

本文介绍了如何在 Window7 环境下安装 Oracle RAC11gR2 的方法以及安装过程中遇到的一些问题的解决方法

资源

win64_11gR2_grid
win64_11gR2_database_1of2
win64_11gR2_database_2of2

以上资源可在官网下载

安装文档以 Rac11gR2OnWindows.pdf 为准，由于文档上面有很多步骤比较省略，且更接近真实环境下的配置方案，因此找了一篇安装步骤非常接近官方文档的博客¹作为参考，同时结合其他博客进行安装

首先给出网络拓扑结构如下，后面遇到问题可以返回来作为参照

正式开始配置

配置步骤

虚拟机准备

创建一个 Windows7 虚拟机（使用 VMware® Workstation 15 pro）
安装 jdk （版本应在 1.5 及以上）
为虚拟机添加一块网卡
克隆虚拟机

✴︎节点名称配置

修改主机名、统一用户名密码，分别更改两台服务器的主机名为 cluster1 和 cluster2，需要重启后生效，两台服务器统一使用 administrator 用户，并且保持密码一致。

Nginx 多阶段 Http 请求处理流程

Mon, 11 Apr 2022 09:42:32 +0000

Nginx 通过将各个阶段的所有模块按序的组织成一条执行链，以流水线的形式依次进行处理。

执行链及流程

nginx执行链的定义如下：

typedef struct {
 ngx_http_phase_handler_t *handlers; /*执行链*/
 ngx_uint_t server_rewrite_index;
 ngx_uint_t location_rewrite_index;
} ngx_http_phase_engine_t;

执行链节点的数据结构定义如下：

struct ngx_http_phase_handler_s {
 ngx_http_phase_handler_pt checker;
 ngx_http_handler_pt handler;
 ngx_uint_t next;
};

对于执行链节点，相同阶段具有相同的checker函数，handler中则保存的是挂载至该阶段的模块处理函数，一般在checker函数中会执行当前节点的handler函数

执行链的执行流程是按照执行链顺序向前执行，但某个阶段需要回跳或跳过之后的某些执行阶段，next字段保存的就是跳跃的目的索引。

各个阶段如下：

NGX_HTTP_POST_READ_PHASE

接受完请求头之后的第一个阶段，位于uri重写之前，默认情况下该阶段被跳过;

nginx源码中仅有realip模块在POST_READ阶段对客户端ip进行了替换，且该模块并未被默认编译进nginx

POST_HEAD阶段的checker函数仅调用对应的handler函数，随后对返回值进行处理，当handler返回NGX_OK时进入下一阶段

NGX_HTTP_SERVER_REWRITE_PHASE

server级别的uri重写阶段，执行于server块内，location块外的重写指令。

nginx的rewrite模块在此阶段提供url重写指令rewrite和变量指令set，以及逻辑控制指令if、break和return以供用户完成一些简单的需求而不必注册handler

该阶段的请求未被匹配至具体的location中

SERVER_REWRITE阶段的checker函数同样调用handler函数，但处理方式稍有不同，当handler返回NGX_DECLINED时进入下一阶段

NGX_HTTP_FIND_CONFIG_PHASE

这一阶段根据重写过的uri查找对应的location，可能被执行多次

通过ngx_http_core_find_location函数完成对r->loc_conf的设置，然后调用ngx_http_update_location_config更新请求相关配置

NGX_HTTP_REWRITE_PHASE

location级别的重写阶段，该阶段执行location基本的重写指令，可能被执行多次。

与SERVER_REWRITE的逻辑基本相同，使用相同的handler函数，只是执行的时机不同。

NGX_HTTP_POST_REWRITE_PHASE

该阶段不能挂载handler，仅用于检查REWRITE阶段是否进行uri重写，若发生重写则返回再次执行REWRITE阶段，默认限制的重写次数为10次

Manacher's Algorithm（求最长回文子串）

Sat, 25 Jul 2020 09:47:41 +0000

本文讲述 Manacher 算法（马拉车算法）的原理以及如何利用 Manacher 算法获取最长回文子串。

给定一个字符串s，找到这个字符串的最长回文子串

Example 1:
1
2
3
Input: "babad"
Output: "bab"
Note: "aba" is also a valid answer.
Example 2:
1
2
Input: "cbbd"
Output: "bb"

要找到一个字符串中的最长回文子串有以下几种方法：

暴力搜索，算法复杂度O(N³)
动态规划，算法复杂度O(N²)
Manacher算法，算法复杂度O(N)

而本文的主角就是Manacher’s algorithm，一起来看看它的实现

核心思想

Manacher算法的核心思想在于搜索以每个字符为中心的回文子串长度，并利用先前搜索的结果加快后续回文子串长度的计算

其中从中心向两边搜索是Manacher和动态规划方法相比暴力搜索降低复杂度的关键，而利用先前的搜索结果加快后续回文子串计算则是Manacher算法能够以不可思议的O(N)复杂度完成回文串查找的关键

过程

以Manacher算法的一个中间过程为例

s：给定的字符串

P：手动维护，P[i]保存以i位置为中心的最长子串长度

Center：当前最近的回文子串中心

关于

Mon, 01 Jan 0001 00:00:00 +0000

这里是 Mer 的个人博客，记录技术学习、源码阅读和问题分析。

文章主要涉及 Ceph、C++、算法与系统开发。希望这些笔记既能帮助自己回顾，也能给遇到相似问题的人一些参考。

联系与订阅

阅读说明

技术文章有其适用版本和时间背景。较早的文章保留了当时的分析，请结合文章日期和实际软件版本阅读。

旧文的“存档更新”来自历史站点文件的提交记录，不一定表示正文在当天修改过。