第三届中国 Rust 开发者大会 Rust 构建分布式账务系统 在 Fintech 公司落地 Rust 项目的经验分享 Airwalle x 胡宇 Airwallex 我们是一家跨境支付领域的 Fintech 独角兽 关于我们 E2 轮 Fintech 独角兽，业务遍布全球 关于我们： Airwallex 墨尔本 新加坡 伦敦 深圳 香港 北京 旧金山 上海 东京 提供高效，低成本的数字银行服务 关于我们： Airwallex 从设计架构到实现细节 项目介绍 分布式账务系统 Fintech 互联网 正确性 bug= 资损 bug 不可怕，快速迭代 可靠性 丢数据 = 资损 允许数据丢失 性能 超低延迟 + 高吞吐 超高吞吐 交易日志 审计，监管 调试使用 分布式账务系统 Fintech 领域中的软件与互联网软件的不同 需求分析 支付处理： ● 转账 高可用：在部分节点失效的情况下，依旧可以提供正确的 服务 超低延迟：实时交易，超低响应延迟 水平扩展性：利用分布式事务实现钱包集群的的水平扩 展，应对高达 100 万 TPS 的流量 可演化性：业务逻辑与底层 API 解耦，当业务发生改变 时，底层 API 不用改变 分布式账务系统 设计理念 - Rust 是我们可靠的基石 分布式账务系统 存算分离 API 解耦 读写分离 层级账号 Rust ● 事务层与账户层分

新一代分布式高性能图数据库的构建 北京海致星图科技有限公司 2023-06-18 沈游人 数据库与大数据专场 海致简介—企业级知识图谱开创者 专业顶尖技术团队支撑 超 700 人团队，其中 80% 为技术人员，创始团队在完成全球第一个中文知 识图谱网站研发后，探索知识图谱技术在企业领域的应用。 2021 年，海致院 士专家工作站成立，站内清华大学计算机博士生占比达 90% 以上。 实时风控对图库的性能挑战（ OLTP 毫秒级响应） • 海致图平台产品服务于金融、政府行业有大量业务经验积累（接近客户需求） • 现有开源产品无法满足要求（受限于基础架构设计，优化性能有限） 新一代分布式图数据库需具备的特性 特性 信 雅 达 • 高可用 • 一致性（事 务） • 高性能 • 低资源消耗 • 易用 • 功能丰富 AtlasGraph 关键特性 云原生 Cloud-Native ，可扩展的分析引擎支持更复 杂的数据挖掘和机器学习场景 MPP Massively Parallel Processing 架构，大规模集群 分布式存储及并行计 算， Shared Nothing 模式支 持存储计算分离 高性能 基于 Rust 开发的分布式存储引 擎及图计算引擎，精细的内存 管理设计，内置索引系统，支 持毫秒级的并发查询响应速度 易用 AQL(Atlas Graph Query

常见操作所花费的时间 • 图中加法 (add) 和乘法 (mul) 都指的整数。 • 区别是浮点的乘法和加法基本是一样速度。 • L1/2/3 read 和 Main RAM read 的时间指的是 读一个缓存行（ 64 字节）所花费的时间。 • 根据计算： 125/64*4≈8 • 即从主内存读取一次 float 花费 8 个 cycle ， 符合小彭老师的经验公式。 • “right” 和“ wrong” 相差不多，符合我的预期 。 第 2 章：缓存与局域性 针对不同数据量大小的带宽测试 • 我们试试看 a 不同的大小，对带宽有什么影响。 针对不同数据量大小的带宽测试（续） • 可见数据量较小时，实际带宽甚至超过了 理论带宽极限 42672 MB/s ！ • 而数据量足够大时， 才回落到正常的带宽 。 • 这是为什么？ CPU 内部的高速缓存 • 原来 CPU 的厂商早就意识到了内存延迟高，读写效率低 器——虽然小，但是读写速度却特别快。这片小而快的 存储器称为缓存（ cache ）。 • 当 CPU 访问某个地址时，会先查找缓存中是否有对应的 数据。如果没有，则从内存中读取，并存储到缓存中； 如果有，则直接使用缓存中的数据。 • 这样一来，访问的数据量比较小时，就可以自动预先加 载到这个更高效的缓存里，然后再开始做运算，从而避 免从外部内存读写的超高延迟。 缓存的分级结构 查看高速缓存大小： lscpu • 可以看到我们

里构建，即： make -C build -j4 // 调用本地的构建系统执行 install 这个目标，即安 装 -D 选项：指定配置变量（又称缓存变量） • 可见 CMake 项目的构建分为两步： • 第一步是 cmake -B build ，称为配置阶段（ configure ），这时只检测环境并生成构建规则 • 会在 build 目录下生成本地构建系统能识别的项目文件（ Makefile 或是 .sln ） • 第二步是 cmake --build build ，称为构建阶段（ build ），这时才实际调用编译器来编译代码 • 在配置阶段可以通过 -D 设置缓存变量。第二次配置时，之前的 -D 添加仍然会被保留。 • cmake -B build -DCMAKE_INSTALL_PREFIX=/opt/openvdb-8.0 • ↑ 设置安装路径为 /opt/openvdb-8 -DCMAKE_BUILD_TYPE=Release • ↑ 设置构建模式为发布模式（开启全部优化） • cmake -B build ← 第二次配置时没有 -D 参数，但是之前的 -D 设置的变量都会被保留 • （此时缓存里仍有你之前定义的 CMAKE_BUILD_TYPE 和 CMAKE_INSTALL_PREFIX ） -G 选项：指定要用的生成器 • 众所周知， CMake 是一个跨平台的构建系统，可以从 CMakeLists

协议支持  基于 InfluxDB 单机引擎研发 分布式方案  OpenTSDB 协议  内存时序数据库  存储计算分离架构  分级存储  永久代  CeresDB 开源 2022.6 2023.3  开源版本 CeresDB 开始研 发 2023.6  1.2.2 版本发布  优化了写入性能  优化了分布式方案 CeresDB – 目标 解决时间线高基数问题 解决时间线高基数问题 • 能高效处理好 APM 型时序数据 • 同时能高效处理好高基数时间线场景 提供原生分布式方案 • 大规模部署 • 提供高可用、高可靠的服务 • 支持水平扩容 • 支持高效的分布式查询 - Tokio Preemption - Future Cancellation Rust 生产实践 生产实践 – Tokio 为什么使用 Tokio ？ 1. 业界使用最广泛，测试齐全。

编译器如何自动优化：从汇编角度看 C++ 5.C++11 起的多线程编程：从 mutex 到无锁并行 6.并行编程常用框架： OpenMP 与 Intel TBB 7.被忽视的访存优化：内存带宽与 cpu 缓存机制 8.GPU 专题： wrap 调度，共享内存， barrier 9.并行算法实战： reduce ， scan ，矩阵乘法等 10.存储大规模三维数据的关键：稀疏数据结构 11.物理仿真实战：邻居搜索表实现 显然不是。甚至在两个处理器上同时运行两个线程也不见得可以获得两倍的性能。相似的 ，大多数多线程的应用不会比双核处理器的两倍快。他们应该比单核处理器运行的快，但 是性能毕竟不是线性增长。 • 为什么无法做到呢？首先，为了保证缓存一致性以及其他握手协议需要运行时间开销。在 今天，双核或者四核机器在多线程应用方面，其性能不见得的是单核机器的两倍或者四倍。 这一问题一直伴随 CPU 发展至今。 并发和并行的区别 • 运用多线程的方式和动机，一般分为两种。 grain ）将矩阵进行分块。块内部小区 域按照常规的两层循环访问以便矢量化，块外 部大区域则以类似 Z 字型的曲线遍历，这样 能保证每次访问的数据在地址上比较靠近，并 且都是最近访问过的，从而已经在缓存里可以 直接读写，避免了从主内存读写的超高延迟。 • 下次课会进一步深入探讨访存优化，详细剖析 这个案例，那么下周六 14 点敬请期待。 第 6 章：并发容器 std::vector 扩容时会移动元素

Rows level lock , 读写性能都非常优秀 读写性能都非常优秀 • 能够承载大数据量的存储和访问 能够承载大数据量的存储和访问 • 拥有自己独立的缓冲池，能够缓存数据和索引 拥有自己独立的缓冲池，能够缓存数据和索引 MySQL 架构设计—应用架构 强一致性 对读一致性的权衡，如果是对读写实时性要求非常高的话， 就将读写都放在 M1 上面， M2 只是作为 standby 。 访问频繁，考虑 访问频繁，考虑 Master/Slave Master/Slave 读写分离；数据库分表、数据库切片（分 读写分离；数据库分表、数据库切片（分 布式），也考虑使用相应缓存服务帮助 布式），也考虑使用相应缓存服务帮助 MySQL MySQL 缓解访问 缓解访问 压力 压力 系统优化 系统优化  配置合理的 配置合理的 MySQL MySQL 服务器，尽量在应用本身达到一 服务器，尽量在应用本身达到一 1024 MySQL 服务器同时处理的数据库连接的最大 数量 query_cache_size 0 ( 不打开 ） 128M 查询缓存区的最大长度，按照当前需求，一 倍一倍增加，本选项比较重要 sort_buffer_size 512K 128M 每个线程的排序缓存大小，一般按照内存可 以设置为 2M 以上，推荐是 16M ，该选项对 排序 order by ， group by 起作用 record_buffer

，那就没办法全部装在高效的寄存器 仓库里，而是要把一部分“打翻”到一级缓存中，这时对这些寄存器读写的速度就和一级缓存 一样，相对而言低效了。若一级缓存还装不下，那会打翻到所有 SM 共用的二级缓存。 • 此外，如果在线程局部分配一个数组，并通过动态下标访问（例如遍历 BVH 时用到的模 拟栈），那无论如何都是会打翻到一级缓存的，因为寄存器不能动态寻址。 • 对于 Fermi 架构来说，每个线程最多可以有 经典案例：矩阵转置 • 为什么需要多维？直接手动求模运算获取 x ， y 坐标不行吗？看右边这个例子。 • 回顾一下：我们第七课讲过， CPU 上的 并行 for ，通常会做循环分块提升缓存局 域性。但是如果我们是传统的两层的 for 循环就低效了，对于矩阵转置这种需要 y 方向非连续访问而言，循环分块会带来很 大提升。 • 所以该怎么做才能让 GPU 也循环分块呢 ？ 经典案例：矩阵转置 • 很简单，只需要使用二维的 blockDim 和 gridDim ，然后在核函数里分别计算 x 和 y 的扁平化线程编号就行了！他会自动变 成 循环分块一样的效果，有利于缓存局域 性。 • 顺便一提 Taichi 没有用多维的 blockDim ，他统一用一维的网格跨步循环 来扁平化高维循环，这就是为什么我们用 Taichi 的 for 处理二维、三维数据的

更高效。其实 sizeof(std::mutex) = 40 字节，而 sizeof(tbb::spin_mutex) = 1 字节…… 小彭老师解决：访问者模式 把写入过的块地址缓存起来，可以避免多次访问全局表的开销。缓存在访问 者 (accessor) 的成员 map 里。访问者对象被我用 OpenMP 标记为 firstprivate ，意味着这个 map 是线程局部的，因此对他的访问不需要加锁， parallel for collapse(2) 遍历二维区间。 把 func 捕获为 firstprivate ，从而支持用 lambda 捕获的访问者模式。 实现访问者模式 • 额，总之就是每一层都有一个缓存。 第 5 章：量化整型 使用 int ：每个占据 4 字节 • 记得我第七课说过，一个简单的循环体往 往会导致内存成为瓶颈（ memory- bound ）。 • 右边就是一个很好的例子。 足稀疏数据结构“按需分配”的需求。且由于分页是硬件自动 来做的，比我们软件哈希和指针数组的稀疏更高效，写起来 就和普通的二维数组没什么两样，就好像顺序访问。也用不 着什么访问者缓存坐标和块指针了，硬件的 TLB 就是我们 的访问者缓存，而且超快不需要用户自己写。 • 垃圾回收可用 madvice 提前释放一段页面。 • 除此之外， mmap 还有一个好处，他会保证其内存（被读 取访问时）是零初始化的。

编译器如何自动优化：从汇编角度看 C++ 5.C++11 起的多线程编程：从 mutex 到无锁并行 6.并行编程常用框架： OpenMP 与 Intel TBB 7.被忽视的访存优化：内存带宽与 cpu 缓存机制 8.GPU 专题： wrap 调度，共享内存， barrier 9.并行算法实战： reduce ， scan ，矩阵乘法等 10.存储大规模三维数据的关键：稀疏数据结构 11.物理仿真实战：邻居搜索表实现 通常认为利用同时处理 4 个 float 的 SIMD 指令可以加速 4 倍。但是如果你的算法不 适合 SIMD ，则可能加速达不到 4 倍；也有因为 SIMD 让访问内存更有规律，节约了指 令解码和指令缓存的压力等原因，出现加速超过 4 倍的情况。 第 1 章：化简 编译器优化：代数化简 编译器优化：常量折叠 编译器优化：举个例子 编译器优化：我毕竟不是万能的 结论：尽量避免代码复杂化，避免使用会造 编译器，可以用 #pragma GCC unroll 4 表示把循环体展开为 4 个 相当于： 对小的循环体进行 unroll 可能是 划算的，但最好不要 unroll 大的 循环体，否则会造成指令缓存的压 力反而变慢！ 重复了四次 不建议手动这样写 ，会妨碍编译器的 SIMD 矢量化。 第 6 章：结构体 两个 float ：对齐到 8 字节 成功 SIMD 矢量化！ 三个 float