C++小协程栈和临时变量及作用域的栈溢出问题分析
背景 近期在给一个项目换一些底层接口的日志处理部分。把原始的类 printf 的格式化方式换成 fmtlib / C++ 20 Text Formatting 的方案。 然后发现，替换完一段未执行的代码后，会发生内存写坏的情况。
2025/8/3
articleCard.readMoreI
游戏服务的可观测性能力建设（C++生态）
前言 近年来可观测性领域越来越成熟，游戏服务的可观测性能力建设日益成为提升产品质量与运维效率的关键环节。随着游戏系统架构的不断复杂化，传统的监控和故障排查方式已难以满足业务高可用和用户体验优化的需求。通过健全的可观测性体系，可以实现对游戏服务全链路的实时监控、异常检测与分析，助力技术团队及时发现和定位问题，推动产品持续优化与稳定迭代，从而为玩家提供更加流畅和可靠的游戏体验。
2025/5/24
articleCard.readMore指标上报的多线程优化和多拉取源点优化
前言 我给我们的服务器框架深度集成了一些可观测性的能力。使用 opentelemetry-cpp 作为接入层。 在指标方面，我们允许业务层自由地定制化指标上报和拉取，并以此实现策略控制。上报的时候有Pull模式接口（异步接口），也有Push模式接口（同步接口）。 为了减少 opentelemetry-cpp 内部的视图合并开销，性能最佳，我们尽量使用异步接口。 但是这种情况下由于 opentelemetry-cpp 内部存在后台Processor线程、Exporter线程等，指标的采集往往需要跨线程操作。 这就要求我们上报代码逻辑需要保证线程安全。
2025/5/21
articleCard.readMore协程(libcopp)的Channel功能和CPU命中率优化
背景 设计 《libcopp对C++20协程的接入和接口设计》 的时候，由于C++20协程的promise和awaitable是链式关联的。所以当时设计promise和awaitable之间通过一个共享的context来通信交互。当时第一版实现直接使用了 std::shared_ptr 来管理共享引用，也预留了个规划是未来可以改成非线程安全的引用来减少不必要的Cache Miss开销。
2025/3/13
articleCard.readMore通用RPC代码生成器
背景 我们项目组需要接入多种RPC接入和工具转换流程，并且每种接入层有自己的扩展和定制需求。为了提高开发效率，我们需要一个通用的RPC代码生成器，能够支持多种RPC接入层级的代码生成，同时支持自定义插件和模板。并且自由增加自定义插件而不需要变更构建系统流程。以便提供最佳的灵活性且能支持protobuf的所有特性。
2025/2/14
articleCard.readMore实现strong_rc_ptr(比shared_ptr更快的引用计数智能指针)
背景 我们的新项目有个比较复杂的全区全服交易行系统，其中搜索和推荐是高实时性全区服多维度排序的，并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。 当有订单发生变化时，它不仅仅会影响全服状态下搜索和推荐条件的结果变化，也会同时影响商品维度的聚合，交易行层面的数据聚合。
2024/10/9
articleCard.readMore手夯一个STL allocator和对象内存分析组件
前言 我们项目组前段时间排查和分析压测环境下的某些业务模块大量索引结构的内存问题。通用的工具比如 jemalloc+jeperf 或者 tcmalloc+gperf 的组合过于底层，一方面开启跟踪开销较高，另一方面也是会产生过多噪音数据影响判断。所以我针对我们的智能指针（包含 std::shared_ptr 和我最近写了个非线程安全的版本的 strong_rc_ptr ， 这个后面有空再分享）和STL容器实现了allocator来帮助动态的手动插桩来分析问题。 最终的效果是可以通过一键替换类型申明的Allocator来插入动态控制和插桩统计的能力，这里分享一下手夯标准STL allocator的一些实现细节，方便其他小伙伴如果需要做类似的实现来参考。
2024/8/22
articleCard.readMorestd::condition_variable 的信号丢失问题
背景 这篇分享拖更了好久了。问题起源于去年我们项目组接入 opentelemetry-cpp 的时候，在进程优雅退出的时候偶现超时，虽然可以直接kill进程没啥影响但是退出不“优雅”的话总归会破坏发布流程，增加人工介入的成本。这里记录一下问题可能其他的组件有类似的用法也会有相似的问题。
2024/8/2
articleCard.readMore踩坑一处（GCC）STL `std::async` 实现BUG导致的crash问题
前言 近期发现项目组使用新版本的 opentelemetry-cpp 的时候偶现崩溃。崩溃的位置在STL的 std::future 析构的地方，而这个 std::future 由 std::async创建。 比较违反直觉，这里记录分享一下分析和解决过程方面其他碰到的小伙伴们。
2024/7/21
articleCard.readMoreGCC 14的一个warning to error BUG
背景 早先社区报过 opentelemetry-cpp 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链，主要也是把GCC升级到GCC 14，这时候发现有些第三方工具构建失败。 这里记录一下以防后续其他人碰到参考。
2024/5/31
articleCard.readMore给xresloader（Excel导表工具）增强UE读表支持（包含蓝图,Blueprint）
前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点： 跨平台（java 11 or upper） Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构，包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能） 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码 支持别名表，用于给数据内容使用一个易读的名字 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效 支持通过protobuf协议插件控制部分输出 支持自动合表，把多个Excel数据表合并成一个输出文件 支持公式 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map 支持空数据压缩（裁剪）或保留定长数组 支持基于正则表达式分词的字段名映射转换规则 支持设置数据版本号 Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。 Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux） 提供GUI批量转换工具（支持Windows、macOS、Linux） CLI/GUI批量转换工具支持include来实现配置复用 xresloader 包含了多个组件，其中最主要的部分分别是。
2023/11/14
articleCard.readMoreOpentelemetry社区在gRPC的几个链接问题(静态库和动态库混用,musl工具链,符号裁剪)
前言 opentelemetry-cpp 在标准上报协议OTLP里是支持使用 gRPC 作为传输协议的。但是，当 gRPC 被作为静态库同时链接进多个动态库时，在一些平台上会有一些问题。这是 gRPC 本身的一些实现方式导致的。 一直拖到今天才来比较完整得写这个问题的具体成因和解决方案，实际上也有一些其他库有相似实现的也会有相同的问题，所以分享出来看看有没有其他同学也可能碰到可以参考一下。
2023/10/29
articleCard.readMoreExcel转表工具(xresloader)的新验证器（验证外部Excel和文本数据，唯一性和自定义规则）
前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点： 跨平台（java 11 or upper） Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构，包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能） 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码 支持别名表，用于给数据内容使用一个易读的名字 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效 支持通过protobuf协议插件控制部分输出 支持自动合表，把多个Excel数据表合并成一个输出文件 支持公式 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map 支持空数据压缩（裁剪）或保留定长数组 支持基于正则表达式分词的字段名映射转换规则 支持设置数据版本号 Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。 Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux） 提供GUI批量转换工具（支持Windows、macOS、Linux） CLI/GUI批量转换工具支持include来实现配置复用 xresloader 包含了多个组件，其中最主要的部分分别是。
2023/8/20
articleCard.readMoreprotobuf v22和gRPC v1.55版本升级的依赖变化和upb适配
前言 近期的 protobuf v22和 gRPC v1.55 版本在构建流程层面引入了一些比较大的变化。 最初我关注到这个问题是在我参与的一个社区项目 opentelemetry-cpp 的issue中（ https://github.com/open-telemetry/opentelemetry-cpp/issues/2095 ）。 直到后来，我们在自己的构建系统 cmake-toolset 对 protobuf 和 gRPC 也进行了升级。所以顺带给社区的项目也提交了一些相关的Patch，在这里分享一下可能其他同学也会碰到。
2023/6/18
articleCard.readMore关于protobuf近期版本（v20/v3.20+）和 gRPC v1.54版本在某些编译环境下的一些链接和编译问题
前言 年初的时候我们项目组的构建系统( cmake-toolset )里把 protobuf 升级到了 v20/v3.20 版本, gRPC 也升级到了 v1.54 版本。然而这两个版本在Linux的ELF ABI和MacOS的Macho ABI下都出现了一些符号未定义的问题（当然也包含Android和iOS）。 这些问题也不仅限于 protobuf v20/v3.20 和 gRPC v1.54，后续的版本有些修复了，有些没有。在官方完全修复之前，我们自己打了一些patch去修复这些问题。
2023/6/17
articleCard.readMorexresloader-Excel导表工具链的近期变更汇总
前言 xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。 主要功能特点： 跨平台（java 11 or upper） Excel => protobuf/msgpack/lua/javascript/json/xml 完整支持协议结构，包括嵌套结构和数组嵌套 同时支持protobuf proto v2 和 proto v3 支持导出proto枚举值到lua/javascript代码和json/xml数据 支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能） 支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 DataTable 加载代码 支持别名表，用于给数据内容使用一个易读的名字 支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效 支持通过protobuf协议插件控制部分输出 支持自动合表，把多个Excel数据表合并成一个输出文件 支持公式 支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map 支持空数据压缩（裁剪）或保留定长数组 支持基于正则表达式分词的字段名映射转换规则 支持设置数据版本号 Lua输出支持全局导出或导出为 require 模块或导出为 module 模块。 Javascript输出支持全局导出或导出为 nodejs 模块或导出为 AMD 模块。 提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux） 提供GUI批量转换工具（支持Windows、macOS、Linux） CLI/GUI批量转换工具支持include来实现配置复用 xresloader 包含了多个组件，其中最主要的部分分别是。
2023/4/19
articleCard.readMore打通游戏服务端框架的C++20协程改造的最后一环
前言 我们终于在年初的时候最后完成了整体服务器框架对C++20协程的支持和接入。虽然之前陆陆续续抽时间改造一些组件，让它支持C++20协程，期间也记录了一些早期的设计思路和踩的坑（包括 《libcopp接入C++20 Coroutine和一些过渡期的设计》和《libcopp对C++20协程的接入和接口设计》），其中不乏一些C++20协程使用上可能打破我们常规思路细节和编译器的BUG。而且这些都是各个组件的改造，并没有最后整合到一起。
2023/4/9
articleCard.readMoreOpentelemetry-cpp的Logs模块标准更新(涉及近期版本:1.8-1.9的BREAK CHANGES)
背景 Opentelemetry-cpp 是可观测领域，opentelemetry (CNCF基金会孵化项目)的C++ SDK接入层。 opentelemetry 里面主要是分链路跟踪(Trace)、指标(Metrics)、日志(Logs)三大块。 同时 opentelemetry 有一个标准规范文档 opentelemetry-specification ，而SDK实现主要就是来对这个标准规范文档的特定语言实现。 由于日志(Logs)这一块一直处于Experimental阶段，所以很长时间以来 C++ SDK接入层 都没有及时更新跟进规范的变化。
2023/2/25
articleCard.readMore给cmake-toolset和工具链(curl等)加HTTP/2和HTTP/3支持
前言 前段时间集成一些公司内组件的时候发现它依赖 nghttp2 。正好之前一直有给我的构建工具(cmake-toolset)里的构建 curl 的流程加 HTTP/2 和 HTTP/3 的计划。 所以这波一次性搞定了。 构建工具 cmake-toolset 和 curl 首先，curl 是支持多种第三方库作为 HTTP/2 和 HTTP/3（QUIC）算法库的。比如 nghttp3+ngtcp2，或者微软家 msquic，或者Google家 quiche。 其中HTTP/3只能选一个，互相是冲突的。而Google的quiche官方仅有对bazel构建系统的支持，而我的cmake-toolset是cmake生态的。 这里选用 nghttp3+ngtcp2 的组合，主要是为了和其他的模块共享依赖。
2023/1/30
articleCard.readMore又开新坑之 coredns 插件: nftables和filter
背景 传说中的下一代 iptables 的 nftables 已经出来了好长时间了。现在主流发行版的内核也都已经更新到了对 nftables 支持足够好的版本。 在2年多前我也初步体验过了 nftables ，当时写了个 《nftables初体验》 。并且开始使用 nftables 来实现对家里软路由的管理。 而去年的时候，我也尝试用 nftables 实现了双拨（详见: 《折腾一下nftables下的双拨》）并且可以搭配TPROXY透明代理使用。
2022/10/4
articleCard.readMore关于opentelemetry-cpp社区对于C++ Head Only组件单例和符号可见性的讨论小记
前言 前段时间有人在 opentelemetry-cpp 提出了api组件在动态库中单例无法工作的 issue ，( https://github.com/open-telemetry/opentelemetry-cpp/issues/1520 ) 。 opentelemetry 是可观测性领域的开源项目，目标是统一链路跟踪、数据指标和日志的服务、上报、协议和接口规范，目前属于 CNCF基金会 孵化项目。而 opentelemetry-cpp 则是 opentelemetry 中对标准规范SDK的C++实现。
2022/10/3
articleCard.readMore填个转表工具 xresloader 去年的坑（数组尾部裁剪）
前言 xresloader 是一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript、UE-Csv、UE-Json等数据格式的工具。 并且整个工具链还包含了基于模板引起生成读表代码的 xres-code-generator ，方便产品/策划使用的 GUI批量执行工具 - xresconv-gui 和方便CI集成和程序使用的 命令行批量执行工具 - xresconv-cli。
2022/8/28
articleCard.readMore集成 upb 和 lua binding 的踩坑小记
前言 最近新项目重新评估了一下protobuf的C/C++ -> Lua binding 方案。之前，使用最广泛的 Lua binding 方案应该是 云风 的 pbc 。但是这个库已经是作者弃坑好多年的状态了。我之前使用 pbc 的时候刚碰上 protobuf 3.0 刚出来，当时打了patch来适配 protobuf 3.0 ，还修复了一些其他问题。这个Patch有些推给了上游，有些因为和上游的某些机制冲突没有推。我了解到的很多其他项目也或多或少的打了自己的Patch，大多数也没往上游推。基本上 pbc 已经处于一个失维的状态，所以这次新项目就干脆来寻求更好，或者说仍然有良好活跃度的解决方案。于是就看向了 upb 。
2022/8/21
articleCard.readMorelibcopp对C++20协程的接入和接口设计
前言 最近开的坑有点多。有点忙不过来了所以好久没写Blog了。这个C++20的协程接入一直在改造计划中，但是一直没抽出时间来正式实施。 在之前，我写过一个初版的C++20协程接入 《libcopp接入C++20 Coroutine和一些过渡期的设计》 。当时主要是考虑到 Rust也有和C++类似的历史包袱问题，所以参考了一些Rust协程改造过程中的设计。 但是后来尝试在项目中使用的时候发现还是有一些问题。首先C++20的协程并不是零开销抽象，所以强行用Rust的模式反而带来了一定开销和理解上的难度。其次原先的设计中 generator 是按类型去实现外部接入的。但是实际接入SDK的过程中我们有相当一部分类型相同但是接入流程不同的情况，再加上现在各大编译器也都已经让C++20协程的特性脱离 experimental 阶段了，有一些细节有所变化。所以干脆根据我们实际的使用场景，重新设计了下组织结构。
2022/7/24
articleCard.readMore再度优化GCC、LLVM、Clang、libc++、libc++abi等套件的构建脚本
前言 一直以来，我都维护了完整的 GCC 工具链构建工具 和 LLVM,Clang,libc++,libc++abi工具链构建工具 。 一方面是为了测试和体验新版本编译器的功能和利用一些更现代化的工具检查代码中的风险，另一方面也是为了给我得很多开源仓库做多版本适配。 其中所有的编译期依赖项（不包括 tar,awk等可执行程序的工具）都是自己构建的，这样也能管理好某些新版本组件需要的新版本依赖项，并且做到跨发行版兼容。同时很多发行版自带的 LLVM+Clang 套件都缺斤少两，有的缺少 clang-analyzer ，有的缺少 clang-format ，也有的缺少 libc++ 和 libc++abi 或者缺少sanitizer组件。我也是根据自己的需要编译并输出了大多数开发工具，甚至还有一些开发库以便二次开发（比如用libclang写工具来复用libcang的AST功能）。
2022/4/18
articleCard.readMore游戏服务的分布式事务优化（二）- 事务管理
前言 接上文 《游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块》 在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 最开始的实现并不通用，后来我对这个事务的实现做了进一步的优化和重构，抽离成了较为通用的模块，并对之前没全部完成的功能做了进一步完善。 此篇为重构内容的第二部分，主要聚焦于事务管理。
2022/4/17
articleCard.readMore游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块
前言 在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 但是时间原因，但是写的第一版是深入我们当时的游戏业务的，第一版仅用在好友服上，既不通用测试也不完善。 后来逐渐把公会服务和聊天的功能也采用或部分采用这里的分布式事务的组件来实现，发现有大量的相似代码。 并且由于分布式事务的流程本身比较复杂，其他人接手的时候看起来就会比较吃力，所以我一直有计划重构这一块代码并且实现为更加通用且灵活的模块。 最近也是基本完成了这部分的工作，通用接口主要分为两部分。第一部分是 Write Ahead Log(WAL) 模块，第二部分是事务管理模块。 本此分享主要专注于第一部分 Write Ahead Log(WAL) 。
2022/4/11
articleCard.readMore记录一些bazel适配用编译选项
之前搞 opentelemetry-cpp 的时候接触了下 bazel 构建系统。这玩意儿用起来有一点坑，特别是使用自定义编译环境的时候。 在使用我自己编译的很新版本的 GCC 和 clang+libc++ 的时候，涉及对libssp的检测和 LD_LIBRARY_PATH 环境变量在 bazel 中各个步骤中的传递，这里记录一下适配脚本。
2022/2/15
articleCard.readMore测试现代化硬件C++浮点数性能和一致性
前言 很久很久以前，浮点数的性能和跨平台跨硬件架构一致性是无法获得保证的，所以我们一般在需要强一致性和高性能的游戏服务器中会禁用浮点数，转而使用自己实现的定点数。 这么多年过去了，前段时间想看看现代化硬件下是否仍然有性能问题和是否能够保证一致性，做了些简单的测试，这里记录一下。
2022/1/27
articleCard.readMore适配Boringssl和OpenSSL 3.0
前言 openssl 3.0发布好一阵子了，我的 atframe_utils 其实也挺早前就完成了对 openssl 3.0 和 boringssl 的适配。但是由于懒，一直没写这篇文章。在升级 [openssl] 3.0 和 boringssl 还是碰到了一些问题的，有些是由于接口变化，有些是由于功能支持还有些也和构建系统相关。还是有必要记录一下，至少能方便以后查找。
2021/12/12
articleCard.readMore近期cmake-toolset的一些适配问题
前言 偷懒了好久没有写分享了，最近的时间也是花费了很多时间大量优化了之前游戏服务器框架和组件的很多细节。其中，相对独立且同时也被其他的项目使用的一个工具则是基于 cmake 和 git 且兼容 vcpkg 的构建系统 cmake-toolset 。之所以要写这么个构建工具主要是要提供比 vcpkg 更宽容的兼容性（没办法我们公司的编译环境比较古老），并且提供更进一步的定制化能力（包含但不限于功能开关和下载源，这些东西 vcpkg 也是很后期才有了个初步的支持）。那么先来记录一下构建系统适配过程中的一些问题吧。
2021/12/6
articleCard.readMoreC++20 Text Formatting/fmtlib 适配问题小记
前言 C++20 正式发布已经有一段时间了。其中 Text Formatting 是一个我个人比较感兴趣的新组件。它主要是解决了之前字符串格式化库 ( printf 系 ) 的效率问题和运行时安全的问题。 并且新的格式设置的形式也比较友好。相关规范和用法可以参见:
2021/9/5
articleCard.readMore再次重构LLVM+Clang+libcxx+libc++abi+其他相关工具的构建流程
背景 我们有时候写一些基础性类库或者实验新功能的时候，常常需要使用到最新版本的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等等）的工具链。
2021/8/30
articleCard.readMore重构基于CMake的构建工具链
背景 对大型项目来说，必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言，依赖管理一直是一个比较头大的问题。 很多老式的系统和工具都会尝试去走相对标准化的安装过程，比如说用 pkg-config 或者用系统自带的包管理工具装在系统默认路径里。 当然这样很不方便，也不容易定制组件。我使用 cmake 比较多，所以一直以来在我的 atframework 项目集中有一个 utility 项目 atframe_utils，里面包含一些常用的构建脚本。 并且在 atsf4g-co 中实现了一些简单的包管理和构建流程。
2021/6/6
articleCard.readMore新版GCC和LLVM+Clang终于Release啦
可能是疫情的原因，GCC好久没发布啦。最近总于又Release了，还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆祝一下，顺带更新一波构建脚本把这两年的一些改动列举一下。
2021/5/16
articleCard.readMore折腾一下nftables下的双拨
背景 我们小区终于有联通线路啦，之前一直用的联通的手机号。它套餐满一定额度以后送一条宽带，本着不用白不用的精神，那必须不能浪费。还好我之前设置软路由得时候就预留了两个网口作wan，所以新增得联通得线路直接插那个口上就行了。（吐槽一下联通给得光猫竟然是8年前生产的老古董）
2021/5/16
articleCard.readMore[C++20] Module partitions和符号交叉引用（声明和实现分离）
C++20 开始支持 Module 了。在以前C++为了解决循环依赖问题，经常会把类或者函数声明写前面，实现写后面。然后中间的代码就可以实现内部模块的内聚而互相引用。比如:
2021/3/26
articleCard.readMore[Rust] 实现一个线程安全且迭代器可以保存的链表
背景 今年有个想法，重新设计 libatbus 然后用 Rust 实现出来，然后可以加入一些云原生的支持。这需要一个定时器模块，我看了下 Rust 现有的几种定时器的实现，大多是基于堆或树的结构的，没有找到jiffies定时器的实现，所以想自己实现一个算了。这个定时器的实现又需要类似 C++ 的 std::list::iterator 的 插入和删除某个迭代器对其他迭代器没有影响 的特性，但是 Rust 的数据结构都不是这种设计模型。所以就决定自己写一个吧。
2021/3/10
articleCard.readMore基于protobuf的代码生成
前言 前段时间我用 Python 和 Mako 模板引擎重新梳理了我们项目中的一些重复的流程。重构了所有的RPC系统。这个工作其实完成了挺久了，但是迫于懒一直拖着没写完这篇记录，就一直没发。
2021/2/9
articleCard.readMore几个使用protobuf中C++接口的Arena的坑
前言 protobuf 从3.0版本开始对C++增加了Arena接口，可以用于使用连续的内存块分配内部对象，并且可以更容易精确地控制对象地生命周期，最终达到减少内存碎片地目的。最近我给我们项目的部分接口流程进行相关地改造，在大多数使用 protobuf 的地方都增加了对Arena的支持，但是在接入过程中也碰到了一些问题和坑。
2020/11/11
articleCard.readMoreAmazon Aurora DB存储引擎论文阅读小记
前言 前段时间接触到腾讯云的一个新数据库产品 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》 是对其重点部分的存储服务的。
2020/11/8
articleCard.readMore近期对libatapp的一些优化调整(增加服务发现和连接管理,支持yaml等)
最近给 libatapp 增加了一系列改造，非常多且琐碎，这里简单记录下吧。 首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 libatbus 是不依赖 protobuf 的，现在 既然已经依赖 protobuf 了就转为 protobuf 管理了。同时现在还支持YAML配置，使用 yaml-cpp 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 Envoy proxy 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 YAML转protobuf 、 conf/ini转protobuf 和 指定层级配置导出到protobuf 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。
2020/10/4
articleCard.readMorexresloader转表工具链增加了一些新功能(map,oneof支持，输出矩阵，基于模板引擎的加载代码生成等)
xresloader 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。支持把Excel配置输出成 protobuf二进制、xml、json、lua、javascript、nodejs、msgpack、UE的Json格式及支持蓝图的代码、UE的Csv格式及支持蓝图的代码。
2020/8/29
articleCard.readMore在游戏服务器中使用分布式事务
前言 游戏业务通常有个特点是模块相关性非常高，模块之间的联动也非常密集且复杂。要保持各个相关模块的数据一致性，同时又兼顾效率和，没有一个通用的方法。通常的做法是走有损服务（也叫柔性服务）和自动修复的方式。比如支付服务一般的做法是在2PC的基础上增加redo log，对于发放和订单确认这两方，如果失败了会尝试几次补发。又或者好友系统或者公会，因为涉及多个对象的数据相互索引，一些做法是玩家在线的时候定期去检查数据是否正确，如果不正确走修复流程。
2020/6/27
articleCard.readMorelibcopp接入C++20 Coroutine和一些过渡期的设计
前言 最近GCC 10.1.0 发布，三大编译器（MSVC、GCC、Clang）都已经支持了C++20协程，之前给 libcopp 接入 C++20协程 的计划也就提上了日程。C++20协程 在创建、切换开销和内存分配上和传统有栈协程相比有着无可比拟的优势。但是C++20全面普及还有相当长一段时间，所以我们设计的重要目标之一就是能够让以后的迁移更容易且更平滑地进行，本文则是记录了 libcopp 接入 C++20协程 时地一些性能上和平滑接入上的思考和成果。
2020/5/22
articleCard.readMorelibatbus 的大幅优化
最近零碎的事太多了，拖了好久没写blog。一些小的碎片话的东西也不值得写，另一方面是这次大幅优化了 atframework 的一些流程细节，特别是针对我们这两年来业务的需求，对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。
2020/4/17
articleCard.readMorenftables初体验
前言 之前耳闻 nftables 是下一代 iptables 。前段时间配了一台主机，折腾成家里的软路由。就一并来尝鲜一系列新东西，其中就包括 nftables 。nftables 和 iptables 、ebtables 等一样，都是对底层 xtables 的封装，目前看来 nftables 比 iptables 更简洁易用，更易读，更容易理解，扩展性和也更好。但是目前各个发行版中对 nftables 的支持还比较参差不齐，导致 nftables 很多功能比 iptables 还是有所缺失，所以个人感觉短期内还是替代不了 iptables （比如 tproxy 功能需要 linux kernel 4.19+， 而即便是 CentOS 8 的内核版本也只是 4.18 ，所以都不支持 ）。 nftables 所支持的功能列表及所以来的内核版本和内核模块可以在这里找到 https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables 。
2020/2/11
articleCard.readMore容器配置开发环境小计
前言 这段时间折腾了好久容器搭建开发环境和家里软路由趟的一些坑。这里先记录一下使用容器搭开发环境的一些流程和问题。 开发环境一般里面会包含很多的工具和开启一些服务。 我自己的环境测试和搭建了 ubuntu 、 centos 、 archlinux 。 开启了 systemd ， 支持网络代理+vscode远程开发， 支持 docker 和 podman ，支持k8s，开启了 sshd 。 所有的构建脚本及 Dockerfile 都放在 https://github.com/owent-utils/docker-setup 了，有需要的小伙伴可以自取。
2020/1/20
articleCard.readMorePALM Tree - 适合多核并发架构的B+树 - 论文阅读小记
介绍 年初的时候再知乎上看到有人分享 PALM树 树的文章，看简介是专为多核并发而设计的树形结构。比较好奇所以抽时间来看了看它的设计原理和是如合做到高并发的。
2019/11/3
articleCard.readMore跨平台协程库 - libcopp 简介
前段时间有同事联系我想看看可能推广我之前写的协程库 libcopp，虽然 libcopp 已经用到过好几个项目上，这几年也断断续续地写了一些实现细节的文章，但是也但确实需要系统、概览性地介绍下 libcopp ，所以就有了这篇文章。
2019/10/23
articleCard.readMoreC++20 Coroutine 性能测试 (附带和libcopp/libco/libgo/goroutine/linux ucontext对比)
前言 之前写了 《协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比》 和 《C++20 Coroutine》 ，但是一直没写 C++20 Coroutine 的测试报告。 现在的草案版本比我当时写 《C++20 Coroutine》 的时候有了一点点更新，cppreference 上有文档了(https://en.cppreference.com/w/cpp/language/coroutines) 。里面列举的标准文档是P0912R5，这个文档目前还没完工，详情可以看他的来源N4775。不过内容上暂时还没有太大的变化，今天我就照着之前的方式来benchmark一波 C++20 Coroutine 吧。
2019/10/5
articleCard.readMore尝鲜Github Action
前言 Github Action 上线有一阵子了，大概两周前我的所有账号也是都陆陆续续开发了beta测试的权限。然后就来研究了下这个新的 CI 系统是怎么回事。看介绍，和之前碰到的一些CI系统不太一样的地方是，Github是做了一个商店的功能。这样大家就可以自己定义自己的Action，然后方便别人复用。同时也可以统一自己的或者组织在构建过程中的一些公共流程。
2019/9/21
articleCard.readMore一些xresloader（转表工具）的改进
前言 最近有几个其他项目组的童鞋给我之前的 转表工具链-xresloader 提了几个需求。然后我也根据我们近期一些需求点对转表工具链一起给这套工具做了点功能增强和细节上的一些改进。 这篇blog差不多是这些东西的 CHANGELOG了吧。
2019/9/12
articleCard.readMoreprotobuf、flatbuffer、msgpack 针对小数据包的简单对比
前言 前段时间我尝试给 atframework 的 libatapp 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 libatapp 所依赖的通信组件 libatbus 里内部协议是msgpack ， 而 msgpack 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波 libatbus 的功能，增加一些跨版本向前向后兼容功能，和一些简单的验证功能（仅仅是为了防止误操作导致的问题）。具体的变更等我弄完了再发一篇。
2019/8/3
articleCard.readMore协程框架(libcopp) 小幅优化
最近抽空继续对 libcopp 进行了更新和小幅优化。 首先的Merge了 boost.context 1.70.0 。这次boost.context的更新似乎和它写进 CHANGELOG 里的并不完全一致，匹配的只看到 macho 架构的脏数据操作。 不过另外它增加了新的平台支持 mips64，我目前还是简单导入了，但是平台检测工具还没有写，如果要使用是可以通过编译参数切过去的，不过我感觉没人会这么用吧？我自己用都得看一下之前怎么写的。
2019/6/22
articleCard.readMoreExcel转表工具(xresloader) 增加protobuf插件功能和集成 UnrealEngine 支持
前言 我们项目组最近在学习UE，然后就涉及导表这个东东。之前我已经做过一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript等的工具 xresloader 。并且做了方便服务器集成的CLI工具和方便策划、前端用的GUI工具。那么这次很自然地就让它能够导出UE所支持的内容就行了。然后额外增加了基于protobuf插件形式的多key索引和自动生成一些支持蓝图和非蓝图的常用接口代码。
2019/6/8
articleCard.readMoreAnna（支持任意扩展和超高性能的KV数据库系统）阅读笔记
前言 年前被同事安利了这个分布式最终一致性的存储系统 Anna 。初略看了一眼Paper，似乎很是牛X。说是支持任意规模的扩展，并且性能不低于 pedis。于是抽空来看看并了解下这套系统的设计特点和这种夸张的单机性能和扩展性的来源。 主流分布式KVS的比较 系统名词 扩容设计 内存模型 针对单个Key的一致性策略 针对多个Key一致性策略 Masstree 多核 共享内存 线性(Linearizable) 无 Bw-tree 多核 共享内存 线性(Linearizable) 无 PALM 多核 共享内存 线性(Linearizable) 无 MICA 多核 共享内存 线性(Linearizable) 无 Redis 单核 N/A 线性(Linearizable) 串行化(Serializable) COPS, Bolt-on 分布式 消息队列 最终一致性(Eventual) 因果一致性(Causal) Bayou 分布式 消息队列 最终一致性(Eventual), 单调读/写, Read Your Writes 最终一致性(Eventual) Dynamo 分布式 消息队列 线性(Linearizable), 最终一致性(Eventual) 无 Cassandra 分布式 消息队列 线性(Linearizable), 最终一致性(Eventual) 无 PNUTS 分布式 消息队列 线性写, 单调读 无 CouchDB 分布式 消息队列 最终一致性(Eventual) 无 Voldemort 分布式 消息队列 线性(Linearizable), 最终一致性(Eventual) 无 HBase 分布式 消息队列 线性(Linearizable) 无 Riak 分布式 消息队列 最终一致性(Eventual) 无 DocumentDB 分布式 消息队列 最终一致性(Eventual), Session, Bounded Staleness, 线性(Linearizable) 无 Memcached 多核&分布式 共享内存&消息队列 线性(Linearizable) 无 MongoDB 多核&分布式 共享内存&消息队列 线性(Linearizable) 无 H-Store 多核&分布式 消息队列 线性(Linearizable) 串行化(Serializable) ScyllaDB 多核&分布式 消息队列 线性(Linearizable), 最终一致性(Eventual) 无 Anna 多核&分布式 消息队列 最终一致性(Eventual), 最终一致性(Eventual), Item Cut, Writes Follow Reads, 单调读/写, Read Your Writes, PRAM Read Committed, Read Uncommitted 一致性说明:
2019/4/21
articleCard.readMoreC++20 Coroutine
前言 最近的新闻里 C++20 已经确认的内容里已经有了协程组件，之前都是粗略看过这个协程草案。最近抽时间更加系统性的看了下接入和实现细节。 我的测试代码都是在MSVC下开启 /await 选项后测试的，在我本地的Linux clang环境中，可以通过 $LLVM_CLANG_PREFIX/bin/clang++ -std=c++2a -O0 -g -ggdb -stdlib=libc++ -fcoroutines-ts -lc++ -lc++abi -Wl,-rpath=$LLVM_CLANG_PREFIX/lib/ test.cpp 编译和运行。
2019/3/5
articleCard.readMorelibcopp merge boost.context 1.69.0
过年啦，最近在看一些非技术性的东西，Anna 的Paper也还没看完。随手优化了下Blog的主题，修复和优化了一些小问题。然后来Merge了一下 boost.context 最新 1.69.0 版本的asm部分到 libcopp。
2019/2/11
articleCard.readMoreGoogle去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感
前言 之前看过 《大规模分布式存储系统：原理解析与架构实战》 ，这个系统设计还是挺有意思的，里面提及了Google的一整套系统都有论文，而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了，这段时间就陆陆续续的看完了这三篇Paper，可怜我的渣渣英语，所以看得比较慢。
2019/2/1
articleCard.readMoreRust玩具-企业微信机器人通用服务
新玩具-企业微信机器人 这个机器人其实蛮久前就做好了，现在才写了点分享出来。 最近企业微信不断地开放了机器人的接口，所以我想想拿来做一些开发工具集成也是挺不错的，顺便也是为了继续熟悉一下 Rust 的编程习惯。 那么这次就大量使用 futures 来实现这个机器人的接口服务，这也是即将到来的无栈协程语法糖 await 的基石。
2019/1/4
articleCard.readMore使用ELK辅助监控开发测试环境服务质量和问题定位
什么是ELK？ ELK 是 elasticsearch + logstash + kibana的缩写。这一套是现在比较流行的日志全文索引系统了。我之前的项目也有用它来做过日志分析，这次主要是拿来搭建开发测试环境的监控和分析系统，顺带记录一下部署脚本和流程。 其中 elasticsearch 是日志索引系统，我按两个master，3个数据和处理节点来部署。 logstash 和 kibana 因为是开发测试环境使用，量级不大，所以只部署了一个节点。但是在使用过程中发现 elasticsearch 在jre的GC的时候还是有较长时间的 Stop The World 的问题，而且这期间的数据会倍丢弃。所以为了缓解这个状况，又引入了 redis 作为消息队列使用。然后使用两组pipeline，一个从 client -> logstash -> redis ，另一个从 redis -> logstash -> elasticsearch 来传输。这样如果在 elasticsearch GC的 Stop The World 结束的时候会把数据补回去。 外面更大型的部署也有用 kafka 或者更进一步优化的 pulsar。不过我们目前的应用也不太需要 kafka 和 pulsar 那种数据落地和强一致性，使用 redis 也已经够了。
2018/11/17
articleCard.readMore2018年的新通用伪随机数算法(xoshiro / xoroshiro)的C++(head only)实现
前段时间看到说Lua 5.4用了一种新的通用随机数算法，替换掉本来内部使用的CRT的随机数引擎。我看了一下大致的实现，CPU和空间复杂度任然保持了一个较低的水平，并且循环节和说是随机性都还不错。我们游戏项目中原本对大量随机数场景的随机数算法使用的是基于线性同余的TAUS88，但是使用过程中发现这个算法分布上还是有一些不是很理想，所以就想把这个新的科研成果也用进我们项目中试试看效果。
2018/10/18
articleCard.readMoreWebpack+vue+boostrap+ejs构建Web版GM工具
前言 Web前端的组件技术刷新真的是日新月异，前段时间看到很多童鞋分享了webpack的使用，刚好之前做我们游戏里Web版的GM工具的时候正在想怎么用简单的方式，做模块分离并且又不需要引入重量级的第三方库或组件，也不需要太繁琐的流程（毕竟只是个小工具）。 我们的Web版GM工具长差不多这个样子，全静态页面。 因为分成了好几个模块，然后由于用的是bootstrap的。上面的Tab和下面的内容还有处理逻辑的函数都分了三大块，在不同的位置。在内容持续增加以后，全都写在一个html里太不方便了，而如果走ajax加载，调试和本地编辑都挺麻烦。
2018/10/17
articleCard.readMoreRust的第二次接触-写个小服务器程序
JUST PRACTICE 蛮久前入门了一下 Rust 语言。它的设计模型非常地吸引C/C++的开发者。但是学习语言嘛还是要练习一下，之前也用它给我们项目写了个命令行小工具。这回拿来写个小型的服务器程序吧。
2018/9/12
articleCard.readMore理解和适配AEAD加密套件
什么是AEAD 按照维基百科的说法。AEAD的全称是Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE)。也就是带附加数据的加密和验证算法。 我们很多涉及IO的系统收发数据的时候一般会加上一些校验码，以便检测IO错误。而对外的socket里，这个校验码还有一个功能是挡掉一些不正常的数据。如果这时候如果我们的数据需要带上加密的话，那就是AE了。然后AEAD就是在AE的基础上，增加一些自定义数据，用于防止猜解。
2018/7/2
articleCard.readMoreatsf4g-co的进化：协程框架v2、对象路由系统和一些其他细节优化
前言 年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多，一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱，仅当作一个参照和小计吧。
2018/6/23
articleCard.readMore协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比
协程系统优化 libcopp很早就实现完成了v2版本，现在迁移进atsf4g-co/tree/sample_solution以后也把v2分支正式并入了主干。原来的版本切出到v1分支并且停止维护了。 libcopp v2内存布局 开发libcopp v2版本的最大目的是优化allocator的接口和内存碎片。 原来的allocator虽然是可定制的，但是是内置的。每次创建一个allocator对象，不同allocator之间共享数据只能通过全局数据或者TLS数据。现在则可以传入allocator了。这也是为后续的共享栈池做准备。
2018/5/29
articleCard.readMore可执行文件压缩
前言 最近看Rust相关东西的时候看到一篇关于压缩可执行文件的文章。压缩可执行文件对嵌入式开发特别有用，但是延伸一下用来减少我们游戏行业里预编译的工具二进制包大小和Android/iOS的库也是蛮有用的。 原文见这里： https://jamesmunns.com/blog/tinyrocket/ 基本流程 Release编译，移除调试符号文件，开启最小化size优化(-Oz) 使用LLVM的全量LTO 使用xargo重新编译标准库(std)和核心库(core)（这个C/C++不容易模仿，而且编译选项十分难搞） 移除jemalloc（服务器程序还是留着比较好，内置的malloc实现一般碎片比较厉害。虽然C/C++默认也不是jemalloc，很多项目为了新能还是会用它） 移除panic的详情信息（这个仅适用于Rust） strip（由GNU的binutils提供），参考命令: strip [二进制] UPX进一步压缩加壳 尝试改造优化 然后尝试使用上面的流程改造我们的 gmtools-cli 。原先我是直接开LTO+Release编译的，编出的文件大小为4.4MB（4520728字节）。
2018/4/24
articleCard.readMore初识Rust
前言 虽然我主要使用C++，但是最近也想学点现代化的新语言。初步想的是从golang和Rust里先选一个。 这两年golang在国内很火，最大的特点莫过于语言层面提供了协程支持，能够极大地简化异步逻辑地理解。我之前也接触过一点，还写了个goroutine压力测试对比我的libcopp的性能。但是golang的语法我实在不喜欢，特别是那个不管啥类型声明都是反着来，感觉在复杂的类型下会非常反人类。而且听用过的人说golang的GC还很不稳定。另外之前有新闻说golang正在准备2.0，2.0版本即将加入泛型支持，然后导致很多语法不兼容和语法分析得重写。所以我还是懒得踩这个坑了，至少等2.0出来再说。 Rust是Mozilla搞出来想拿来重写Firefox的。说实话Mozilla和Google还有点差距，导致Rust的发展还比较慢。对比起来就是感觉golang很快就提供了一些快速可用的原型给大型项目使用，标准库也足够丰富。而Rust还纠结在底层、语言层面的优化和最求极致。很多组件都还不成熟，编程设计模型也还没完全统一。 但是接触了一点Rust以后，我发现Rust真的是挠到了C++程序员的痒点，语言层面解决了用C++得费很多脑力和用各种奇技淫巧实现并且还不能完全阻止被绕过的质量控制问题，而且保留了C++很多编译期推断得高级特性。并且和C++一样，提供给你能力，但不限定你方法提供 零成本抽象（zero-cost abstractions） 或者说叫 零开销（zero-overhead）。
2018/4/24
articleCard.readMore使用restructedtext编写xresloader文档
离上一次写Blog过了好久啦。这次拖这么长时间主要是因为最近学习了一个新的文本标记语言 – ReStructuredText 。并且重新整理了Excel导表工具-xresloader工具集的文档，写文档真是好废好废时间啊。 好多项目用ReStructuredText来写文档来着，比如cmake，再比如python。然后现在有比较容易上手的readthedocs来托管文档，和github的集成也还不错。所以我打算把一些项目的文档也迁移上去。毕竟 README.md 还是弱了些。 其实ReStructuredText也支持 Markdown 。但是使用 Markdown 写文档还是略麻烦，特别是涉及跨文档引用和多行表格的时候，而且 Markdown 各个平台的组件和扩展还都不一样，没有统一标准。在这些方面ReStructuredText就强大多了。不过这也是有代价的，那就是ReStructuredText的语法规则比 Markdown 复杂得多。
2018/4/4
articleCard.readMoreatframework的etcd模块化重构
前言 最近在抽时间整理之气的游戏服务器框架和解决方案里atsf4g-co，现在的架构是使用etcd的是atproxy。简单得说就是服务集群是分组的，每个分组有分组代理服务atproxy做组间通信。然后atproxy之间使用etcd来做分组服务的服务发现和保活，并且以此来实现平行扩容。 之前做服务间通信组件libatbus的时候也提到了有一个暂时没实现的功能，就是全局路由表的自动通知。但是这个功能的实现主要也是用于后面不同种服务间感知到哪些节点是可用的，哪些是不可用的。而且我的简单实现必然是走心跳的模式，因为心跳的形式肯定不能把心跳设置得太短，同时也要考虑网络异常抖动和断线重连和丢包，所以肯定不是丢一个心跳包就认为丢失。所以故障或者扩缩容期间的感知时间就会比较长一些。另外就是因为可能有网络孤岛问题，所以可能短期内数据不一致（当然肯定会保证最终一致性）。 再加上由于libatbus是支持多级父子节点关系的，所以变化通知和同步包就要考虑自己与父节点、兄弟节点、自己与子节点的不同关系并作不同的同步流向，会比较复杂。比如：子节点下线，既要通知父节点，又要通知兄弟节点。那么这时候给兄弟节点通知就有两个通路，一个是经由父节点中转，另一种是直接发。当然这时候并不一定和兄弟节点有直接通路。所以可能兄弟节点会收到两次通知，一次来自兄弟节点，另一次来自公共父节点。然后又会有其他问题，就是万一又收到一条冲突的消息，来自父节点和来自兄弟节点的顺序是没有保证的，这里又得加入版本机制。总的来说，细节会比较复杂，具体在实现libatbus的这个功能的时候在谈吧。 上面说的libatbus的功能暂时没实现的最重要原因是etcd可以比较完美的解决上面的延迟问题和不一致问题。缺点就是请求的消耗会高于使用libatbus的通信机制。不过这玩意本身不是高频操作，而且故障和容灾本身不是一个频发的事情所以关系不大。而之前etcd的接入是直接写死在atproxy里的，那么这次重构的目的主要就是能够抽象出模块化的工具，以便后面不同的服务可以根据需要取用。 统一管理驱动管理器和模块化 按现在的功能划分，etcd的接入总共被分为3个模块，etcd_cluster、etcd_keepalive和etcd_watcher以及一个通用工具etcd_packer。etcd_packer用于对etcd的一些通用的打解包操作。 etcd_cluster etcd v3版本内部的通信已经使用了grpc。本来我是想等他的grpc接口进入官方文档并且提供出的grpc的proto再接入的，可是它一直没有整理出直接grpc的proto文件列表。另外我看了一下它的proto文件里用到了一些gogoprotobuf的扩展，其他语言不一定可以无缝接入。考虑到etcd使用了grpc-gateway提供HTTP+JSON的网关层，所以我还是基于他的HTTP接入层来做。因为这里身频次不高，也没有那么在意性能。而且一组etcd服务的QPS也就在十万的级别，只要管理好连接，不要老新建立和关闭连接，HTTP的性能还是够的。
2018/2/21
articleCard.readMoreC++的backtrace
开始之前 很多语言的log模块都有一个功能，就是在打log的时候能够追溯调用栈，有的时候对查bug能有点帮助。之前我也想过给我们的log模块加上C++的backtrace的功能，迟迟一直没有做主要是两个原因：一是C++的backtrace在各个平台和编译器上都不太一样，比较冗杂；二是C/C++在编译优化之后，调用行之类的信息和甚至一些函数可能就被优化没了。所以能提供的信息就相当有限。前两天刚好有朋友问有没有提供这个，所以就花了点时间整理了下适配方案。
2018/1/9
articleCard.readMoreECDH椭圆双曲线（比DH快10倍的密钥交换）算法简介和封装
前面有几篇blog就提到我有计划支持使用ECDH密钥交换。近期也是抽空把以前的DH密钥交换跨平台适配从atgateway抽离出来，而后接入了ECDH流程。 背景 对DH和ECDH算法的具体原理这里不做具体介绍了，可以点击链接看。DH和ECDH的主要的作用就是在通信双方发送一些公有参数，保留私有参数，而后通过一系列计算双方都能够得到一个一致的结果。而这个运算的逆运算复杂度过高，在有限时间内不可解（至少量子计算机问世以前不可解），以保证密钥安全性。除了维基百科外，我还看到篇文章图画的很好看的：http://andrea.corbellini.name/2015/05/30/elliptic-curve-cryptography-ecdh-and-ecdsa/ 。而DH和ECDH得区别简单来说就是，前者使用了一个大素数和两个随机数，而后者使用了ECC算法和两个随机点。 实际应用中，有些加密算法的密钥碰撞计算难度反而比破解DH和ECDH要容易（比如atgateway支持的XXTEA算法，这个算法很简单所以也非常高效）。所以有些工程实践中会每隔一段时间再走一次密钥交换流程来更换密钥。
2017/11/10
articleCard.readMoreprotobuf-net的动态Message实现
这本来是个早就可以写的分享。因为代码几周前就迁移并准备好了。而且这也是之前项目的工具，因为可以抽离出来通用化所以单独整理出来。 这个项目起源于我们之前哪个项目，客户端想要在Unity的C#里动态加载配置，而protobuf-net一方面大量使用反射而性能不太行，另一方面使用的时候得生成C#代码才行。客户端原来的做法是把消息扁平化了，使用protobuf-net得底层读写接口直接操作基本数据类型。这就失去了结构化带来的一系列好处。再加上后来我引入了跨平台导表工具，使用结构化得数据会非常方便，而手动把这个数据打散到客户端读取接口显然很浪费人力而且容易出错。所以我就干脆也使用protobuf-net的底层读写接口做了现在的DynamicMessage的支持，API设计是结合pbc和protobuf官方的API流程的。
2017/11/1
articleCard.readMorepbc的proto3接入
Protobuf 的 proto3发布也有挺长一段时间了。现在很多新项目慢慢转变用proto3来开发。这篇文章主要记录一下我在给pbc写对proto3支持时的一些信息，也许对其他童鞋也有点助益。抛砖引玉一下。 简介 pbc是云风开发的一个纯C的读写protobuf的很小巧的库，配合上它提供的lua-5.1和lua-5.3的binding可以很容易地在lua里完成对pb文件的注册和打解包。应该很多人都知道这个组件。 但是后来云风自己又发明了个sproto，然后主推在他的skynet框架中使用sproto，于是pbc就不再有功能维护了。 我们之前的也尝试直接使用了proto3，也是因为在迁移期，所以并没有使用全部的特性。但是仍然有一些向前不兼容的细节需要处理一下，所以有了这个改造
2017/9/17
articleCard.readMoreatgateway内置协议流程优化-加密、算法协商和ECDH
之前就有计划优化游戏服务器框架网关层的内部协议了，这次泰国旅游回来，新公司入职前，正海有空来做这件事。 加密协商 以前提到过，最初决定重构这个流程是因为我觉得之前的方法，如果以后要扩展新的算法的话非常的麻烦。而后我看了一下shadowsocksr对多种加解密算法的实现方法，觉得还不错。就打算用类似的方法重写一下。当然也是因为写第一版的时候没考虑太多关于加解密方面的细节，还是优先实现出工程上可用的东西。这次就先稍微深入看了下像openssl和mbedtls的一些实现，特别是下面会提到的cipher的实现。并以这个为基础来实现以后可能的增加加密算法的扩展。
2017/9/9
articleCard.readMore整理一波软件源镜像同步工具+DevOps工具
上个月，同学的公司，格奕，突然间跪了。这个月基本属于休息+四处溜达。同时空闲的时候也想整理下之前做得一些之前的做得一些小工具们。在不泄密的情况下开源出来吧（其实也就是想找github存放一下而已，也没什么特别NB的东西）。
2017/8/17
articleCard.readMoreBlog切换到Hugo
其实很早就想把Blog迁移到静态化的博客系统了。不过一直没花时间来搞，当然主要原因还是懒。 这次下决心搞主要是因为，之前VPS迁移到Vultr，然后它的主机默认是没有交换区的。后来老是收到网站崩溃告警，每次去看都是MariaDB挂掉了，然后查了一下是内存不足。 然后，调整了几次参数，发现都不能解决问题。我这么个小站搞个高配机器显然是浪费。这种小网站都能耗尽1GB的内存我也是醉了。所以后来就干脆迁移到静态博客系统算了。
2017/7/17
articleCard.readMorelibcopp v2的第一波优化完成
之前测出来libcopp还有一些列优化点，但是要破坏之前的API，所以整理了一下优化的想法和方案。 预留空间和合并分配 之前有太多的堆内存分配了，导致很多碎片。那么第一个想法就是协程对象可以分配在栈上，runner也可以分配在栈上。然后还可以加一个自定义预留长度。每个对象对齐到sizeof(long)，总长度对齐到64 Bytes。
2017/7/1
articleCard.readMorelibcopp(v2) vs goroutine性能测试
本来是没想写这个对比。无奈之前和call_in_stack的作者聊了一阵，发现了一些libcopp的改进空间。然后顺便看了新的boost.context的cc部分的代码，有所启发。想给libcopp做一些优化，主要集中在减少分配次数从而减少内存碎片；在支持的编译器里有些地方用右值引用来减少不必要的拷贝；减少原子操作和减少L1cache miss几个方面。 之后改造了茫茫多流程和接口后出了v2版本，虽然没完全优化完，但是组织结构已经定型了，可以用来做压力测试。为了以后方便顺便还把cppcheck和clang-analyzer的静态分析工具写进了dev脚本。然后万万没想到的是，在大量协程的情况下，benchmark的结果性能居然比原来还下降了大约1/3。
2017/6/10
articleCard.readMorelibcopp的线程安全、栈池和merge boost.context 1.64.0
线程安全 前段时间看到了一个完成读比较高的协程库-libgo，里面提供了线程安全的协程实现，并且也是使用锁。本来我并没有给libcopp里的功能加锁的打算，因为上层dispatcher还是比较容易做到安全分发的，所以原来并不保证线程安全。而且线程安全这种问题单元测试比较难写，可能还得碰点运气。但是思来想去，还是为线程安全做点什么吧。反正也不是很复杂。 由于我并没有给utils加互斥锁的跨平台适配，所以先就直接用了自旋锁，来锁住需要考虑线程安全的地方。其实需要加锁的地方并不多，无非是管理器的增删查和task的next函数需要加锁。这些逻辑都很短，功能也很简单，并不会占用太多时间，所以自旋锁的问题也不大。而且以后真发现有问题，换掉也不是什么难事儿。
2017/5/13
articleCard.readMoreGCC 7和LLVM+Clang+libc++abi 4.0的构建脚本
之前的版本发完，有空来更新一下之前的gcc和llvm+clang工具链的编译脚本了。其实GCC 7是才release没多久但是llvm 4.0发布其实有一段时间了。
2017/5/9
articleCard.readMorelibatbus的几个藏得很深的bug
在写这篇文章前，我突然想到以前流行了一段时间的服务器面试题：当一个BUG只有几百万分之一的概率会出现，怎么办？这个问题在这个BUG里只是毛毛雨而已，因为这次的BUG的出现概率是夸张的三亿分之一。
2017/4/24
articleCard.readMore用cmake交叉编译到iOS和Android
最近看了下最新版本的cmake的文档，很惊喜地发现他已经支持直接设置Android和OSX的一些变量了，然后有瞄了一眼NDK，发现里面现在也停工官方的cmake支持。
2017/4/16
articleCard.readMore开源项目得一些小维护
其实我那几个特别是工具类得开源项目一致都有维护和更新，但是每次更新得量和要点并不怎么突出所以一致也没写点什么。但是偶尔吗也会碰到一些稍微值得记录的东西，但是又不多所以很多都遗漏掉了。
2017/3/4
articleCard.readMoreatapp的c binding和c#适配
这两天在做服务器框架的C的接口导出和C#的接入。之所以要做这么个东西是因为之前的服务器框架（atsf4g-co）已经完成了通信层面和基本设计模式的细节部分，而且基本算是最大化性能了吧。但是现在的项目的战斗引擎是从以前Unity游戏上抽象而来的，全部由C#编写。再加上最近再考虑接入实时战斗，这样就不能像之前一样用一个简单的通信方式了，必须使用一个高效并且实时性更高通信机制。需要能够处理好比较高的集中式的组播和容灾的通信方式。于是就有了把之前的C++的框架抽离出API来驱动逻辑的想法。这样也比较容易地兼顾开发成本和性能之间地权衡。 C Binding 那么抽离出框架地目的是抽象出应用底层，这个刚好是atapp做的事，而且atapp的层面对外暴露的接口数量也比较少，使用比较简单，所以索性就直接对它下手了。
2017/2/16
articleCard.readMore对象路由系统设计
起源 现在的手游也开始越来越复杂，以前少量交互线上保存的服务器架构越来越不能满足现在越来越偏向PC端MMORPG的需求。比如现在手游也引入了地图服务、公会服务等等。特别是地图服务需要能够动态切换服务节点、并且由于广播量巨大，导致我们得用更多级的缓存和更复杂的负载均衡。这些缓存和负载均衡都会涉及缓存失效、同步、更新、发现延迟等问题，所以越来越需要一个路由系统来解决这些问题。
2017/2/5
articleCard.readMore2016年总结
又好久没写blog啦。诶最近好懒啊。正好过年在家里有点空，写完我那些lib的patch之后还有一点时间写一下2016年的总结吧。 之前两年的总结有点流水账，我还是写得随意一点好了，也没必要凑字数。
2017/2/4
articleCard.readMore近期的一个协程流程BUG
最近一直没什么时间整理近期碰到的问题，今天思考了一下之前碰到的一个临时处理的BUG，顺便写点东西清理一下思路。 其实严格来说这个BUG更应该是一个流程试用问题，不过这个问题应该是需要能在协程库里检测并抛出错误来。
2017/1/3
articleCard.readMore重写了llvm+clang+libc++和libc++abi的构建脚本
由于之前整理的服务器框架已经完成了，就需要用各种静态分析工具跑一遍。原来的llvm+clang的编译脚本是从GCC那个脚本copy过来然后改的，使用的时候各种问题。所以干醋重新折腾一遍，重写了。
2016/11/19
articleCard.readMoreatsf4g完整游戏工程示例
近期仍然在搭建完整的游戏服务器架构。基于atsf4g（asynchronously-tree server framework fo game）的完整解决方案终于接近完成。基本框架之前其实已经做完了，但是之前解决的只是基本的框架层代码，不包含任何特定的交互模型、协议模型、配置服务等等。这回就整理了一个只包含登入登出逻辑的完整工程，另外优化了一些小细节和周边工具的支持。
2016/10/23
articleCard.readMoreatframework基本框架已经完成
好久没写blog了。最近空闲时间都在加紧完成atframework框架。总算是搞完了，并且搭建了一个静态介绍页。以后有空慢慢加文档进去。 主页: https://atframe.work/ Github: https://github.com/atframework/ 目前这个项目已经是一个小型游戏服务器的完整框架，包括服务器间实例的管理、客户端和服务器的内部协议和通信机制。并且实现了纯C的port。 然后https://github.com/atframework/atsf4g-co/tree/master/sample/atgw_cli_inner_hello里提供了c++的客户度端的代码示例，https://github.com/atframework/AtgwInnerCli-CSharp里提供了C#的客户端代码示例。 使用的都是同一个纯C的协议porting。这样无论cocos还是unity框架接入都不困难了。其他的框架也可以直接用这个纯C的porting来接入。
2016/9/23
articleCard.readMore游戏服务器的不停服更新
我们目前的游戏第一次测试的时候笔记送匆忙，导致上线之后频繁更新。 比如BOSS战由于大区的人数和预期不一样导致的难度调整，或者是任务链或者数值调整，再加上一些BUG。
2016/8/1
articleCard.readMore对atbus的小数据包的优化
atbus是我按之前的思路写得服务器消息通信中间件，目标是简化服务器通信的流程，能够自动选择最优路线，自动的断线重连和通信通道维护。能够跨平台并且高效。
2016/7/9
articleCard.readMoreAndroid和IOS的TLS问题
这个问题起源于以前给客户端写的一个log模块，然后里面为了线程安全且多线程下不互相写乱，并且因为这些系统基本都用比较高版本的编译器，都支持C++11了，所以就用了C++11的TLS功能。
2016/7/9
articleCard.readMorepbc的一个陈年老BUG
近期跟了一下pbc的lua-binding的一个老BUG，起源是我们客户端报了一个奇怪的问题，我们游戏里的某些功能的optional字段，服务器并没有下发数据，但是客户端竟然能读到。
2016/7/4
articleCard.readMoreboost.context-1.61版本的设计模型变化
前言 之前写了个C++的协程框架libcopp，底层使用的是boost.context实现，然后剥离了对boost的依赖。然而这样意味着我必须时常跟进boost.context的更新。 顺带提一下这个协程库已经在我们线上服务器版本中使用了。 从最初的boost版本（我忘了从哪个版本开始了）一直到1.60版本，boost.context的变化都不大，都只是补全一些新的架构和体系结构，还有就是修复一些小细节的BUG，再就是增加了对valgrind的支持（之前写过一个Merge记录提到过）。新增的功能也只有execution_context(现在叫execution_context_v1)，这个东西我的libcopp里其实包含了这个功能，并且本身做得比它要功能丰富，所以没有接入的必要。另外在1.60版本的时候尝试使用Windows里的fiber（当然默认是关闭的），在1.61版本里被移除了。这些细节都不是特别重要，主要还是1.61版本的变化。
2016/6/15
articleCard.readMore接入letsencrypt+全面启用HTTP/2
之前我的域名只有owent.net和www.owent.net买了SSL证书，现在有letsencrypt可以拿到免费的SSL签证，就稍微花了点时间把我的域名的其他部分接入了letsencrypt签证系统。另外根据其他人的一些配置建议，提高了HTTPS的安全性配置和性能配置（主要是缓存）。另外原本我的blog就已经启用了spdy，然而现在新版本的nginx（1.10）已经release，原先的spdy模块被取消，新增了http/2模块。但是直接换nginx掉包是不行滴（后面有说原因），所以顺带自己处理了一下HTTP/2和nginx新版本的问题。 并且也对公司里的域名和webserver也这么搞了一下。全面启用HTTPS。
2016/5/7
articleCard.readMore理解Raft算法
前言 最近在分布式系统一致性方面，Raft算法比较火啊。所以就抽时间看了下这个算法。 之前已经有Paxos算法，用于解决分布式系统最终一致性问题，而且已经有了zookeeper这个成熟的开源实现。那么这个Raft算法有啥用呢？按照Raft官网的说法，这个算法的错误容忍和性能和Paxos算法类似，但是拥有更加简单易懂的设计。 看过Paxos算法的童鞋们都知道，这货复杂地和屎一样，为了实现去中心化而考虑了各种复杂的边界条件和时序下的可靠性。而Raft算法则根据实际应用中的需要，简化了设计模型，不采用去中心化设计，而是自动选举中心节点，并且在各种情况和时序下可以保证能够正确的选举出中心节点并保证数据的一致性。而且也正是由于能够选举出唯一的主节点（Leader）使得整个通信流程非常地简单，并且易于理解和维护。 那么它是如何做到这些的呢？ 基本算法设计 Raft的基本设计可以参照官网介绍 https://raft.github.io/ 官方网站上的图例可以点击节点，然后模拟节点crash或者超时或者收到请求时的通信流程。其实也是一个javascript的简单实现，有利于我们理解Raft算法的流程。
2016/3/18
articleCard.readMore