前言

接上文 《游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块》

在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 最开始的实现并不通用，后来我对这个事务的实现做了进一步的优化和重构，抽离成了较为通用的模块，并对之前没全部完成的功能做了进一步完善。 此篇为重构内容的第二部分，主要聚焦于事务管理。

前言

在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 但是时间原因，但是写的第一版是深入我们当时的游戏业务的，第一版仅用在好友服上，既不通用测试也不完善。 后来逐渐把公会服务和聊天的功能也采用或部分采用这里的分布式事务的组件来实现，发现有大量的相似代码。 并且由于分布式事务的流程本身比较复杂，其他人接手的时候看起来就会比较吃力，所以我一直有计划重构这一块代码并且实现为更加通用且灵活的模块。 最近也是基本完成了这部分的工作，通用接口主要分为两部分。第一部分是 Write Ahead Log(WAL) 模块，第二部分是事务管理模块。 本此分享主要专注于第一部分 Write Ahead Log(WAL) 。

之前搞 opentelemetry-cpp 的时候接触了下 bazel 构建系统。这玩意儿用起来有一点坑，特别是使用自定义编译环境的时候。

在使用我自己编译的很新版本的 GCC 和 clang+libc++ 的时候，涉及对libssp的检测和 LD_LIBRARY_PATH 环境变量在 bazel 中各个步骤中的传递，这里记录一下适配脚本。

前言

很久很久以前，浮点数的性能和跨平台跨硬件架构一致性是无法获得保证的，所以我们一般在需要强一致性和高性能的游戏服务器中会禁用浮点数，转而使用自己实现的定点数。 这么多年过去了，前段时间想看看现代化硬件下是否仍然有性能问题和是否能够保证一致性，做了些简单的测试，这里记录一下。

前言

openssl 3.0发布好一阵子了，我的 atframe_utils 其实也挺早前就完成了对 openssl 3.0 和 boringssl 的适配。但是由于懒，一直没写这篇文章。在升级 [openssl] 3.0 和 boringssl 还是碰到了一些问题的，有些是由于接口变化，有些是由于功能支持还有些也和构建系统相关。还是有必要记录一下，至少能方便以后查找。

前言

偷懒了好久没有写分享了，最近的时间也是花费了很多时间大量优化了之前游戏服务器框架和组件的很多细节。其中，相对独立且同时也被其他的项目使用的一个工具则是基于 cmake 和 git 且兼容 vcpkg 的构建系统 cmake-toolset 。之所以要写这么个构建工具主要是要提供比 vcpkg 更宽容的兼容性（没办法我们公司的编译环境比较古老），并且提供更进一步的定制化能力（包含但不限于功能开关和下载源，这些东西 vcpkg 也是很后期才有了个初步的支持）。那么先来记录一下构建系统适配过程中的一些问题吧。

前言

C++20 正式发布已经有一段时间了。其中 Text Formatting 是一个我个人比较感兴趣的新组件。它主要是解决了之前字符串格式化库 ( printf 系 ) 的效率问题和运行时安全的问题。 并且新的格式设置的形式也比较友好。相关规范和用法可以参见:

背景

我们有时候写一些基础性类库或者实验新功能的时候，常常需要使用到最新版本的GCC和Clang。一些Linux发行版的源里和一些工具链（比如MSYS2）里其实自带LLVM套件的包，LLVM 官网也提供一些常见平台的预编译包下载。 那为什么我们还要自己编译呢？如果有注意到的小伙伴可能会发现，很多平台的源和 LLVM 官网 里下载的预编译包，其实是缺失很多组件的。有些没有libc++和libc++abi（CentOS 8），有些没有Sanitizer相关的组件，有些缺失其他的组件。而Clang虽然支持GCC的libstdc++，但是一方面我们写基础性类库还是要优先考虑原生STL库的兼容性，另一方面Clang对libstdc++的支持也不是太好，特别是有些第三方库在这个组合下也是没有适配得很好，同时gdb和libc++的搭配有时候也不是很完善。 所以我们就需要一个组件尽可能开完整地包含LLVM，Clang,libc++,libc++abi还有其他周边工具（各类Sanitizer，clang-tiny,clang-analyzer等等）的工具链。

背景

对大型项目来说，必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言，依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程，比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便，也不容易定制组件。我使用 cmake 比较多，所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils，里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。

可能是疫情的原因，GCC好久没发布啦。最近总于又Release了，还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆祝一下，顺带更新一波构建脚本把这两年的一些改动列举一下。

背景

我们小区终于有联通线路啦，之前一直用的联通的手机号。它套餐满一定额度以后送一条宽带，本着不用白不用的精神，那必须不能浪费。还好我之前设置软路由得时候就预留了两个网口作wan，所以新增得联通得线路直接插那个口上就行了。（吐槽一下联通给得光猫竟然是8年前生产的老古董）

C++20 开始支持 Module 了。在以前C++为了解决循环依赖问题，经常会把类或者函数声明写前面，实现写后面。然后中间的代码就可以实现内部模块的内聚而互相引用。比如:

背景

今年有个想法，重新设计 libatbus 然后用 Rust 实现出来，然后可以加入一些云原生的支持。这需要一个定时器模块，我看了下 Rust 现有的几种定时器的实现，大多是基于堆或树的结构的，没有找到jiffies定时器的实现，所以想自己实现一个算了。这个定时器的实现又需要类似 C++ 的 std::list::iterator 的 插入和删除某个迭代器对其他迭代器没有影响 的特性，但是 Rust 的数据结构都不是这种设计模型。所以就决定自己写一个吧。

前言

前段时间我用 Python 和 Mako 模板引擎重新梳理了我们项目中的一些重复的流程。重构了所有的RPC系统。这个工作其实完成了挺久了，但是迫于懒一直拖着没写完这篇记录，就一直没发。

前言

protobuf 从3.0版本开始对C++增加了Arena接口，可以用于使用连续的内存块分配内部对象，并且可以更容易精确地控制对象地生命周期，最终达到减少内存碎片地目的。最近我给我们项目的部分接口流程进行相关地改造，在大多数使用 protobuf 的地方都增加了对Arena的支持，但是在接入过程中也碰到了一些问题和坑。

前言

前段时间接触到腾讯云的一个新数据库产品 CynosDB 是基于 Amazon Aurora 数据库的Paper实现的。我比较感兴趣就来看看它和之前看过的 Spanner 之类有什么不同，也许部分设计也能用在我们游戏业务的服务器中。它的主要的创新点在于重新设计了binlog和存储的部分，所以我也主要就看了两篇Paper： 《Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases》 是一个整体性质的介绍和概述； 《Amazon Aurora: On Avoiding Distributed Consensus for I/Os,Commits, and Membership Changes》 是对其重点部分的存储服务的。

最近给 libatapp 增加了一系列改造，非常多且琐碎，这里简单记录下吧。

首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 libatbus 是不依赖 protobuf 的，现在 既然已经依赖 protobuf 了就转为 protobuf 管理了。同时现在还支持YAML配置，使用 yaml-cpp 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 Envoy proxy 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 YAML转protobuf 、 conf/ini转protobuf 和 指定层级配置导出到protobuf 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。

xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。支持把Excel配置输出成 protobuf二进制、xml、json、lua、javascript、nodejs、msgpack、UE的Json格式及支持蓝图的代码、UE的Csv格式及支持蓝图的代码。

前言

游戏业务通常有个特点是模块相关性非常高，模块之间的联动也非常密集且复杂。要保持各个相关模块的数据一致性，同时又兼顾效率和，没有一个通用的方法。通常的做法是走有损服务（也叫柔性服务）和自动修复的方式。比如支付服务一般的做法是在2PC的基础上增加redo log，对于发放和订单确认这两方，如果失败了会尝试几次补发。又或者好友系统或者公会，因为涉及多个对象的数据相互索引，一些做法是玩家在线的时候定期去检查数据是否正确，如果不正确走修复流程。

前言

最近GCC 10.1.0 发布，三大编译器（MSVC、GCC、Clang）都已经支持了C++20协程，之前给 libcopp 接入 C++20协程 的计划也就提上了日程。C++20协程 在创建、切换开销和内存分配上和传统有栈协程相比有着无可比拟的优势。但是C++20全面普及还有相当长一段时间，所以我们设计的重要目标之一就是能够让以后的迁移更容易且更平滑地进行，本文则是记录了 libcopp 接入 C++20协程 时地一些性能上和平滑接入上的思考和成果。