<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blablabla on I'm OWenT</title><link>//owent.net/categories/blablabla.html</link><description>Recent content in Blablabla on I'm OWenT</description><generator>Hugo</generator><language>zh-cn</language><copyright>&lt;a rel="license" href="https://github.com/owent/blog-hugo/blob/master/LICENSE.md"&gt;&lt;img alt="知识共享许可协议" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/80x15.png" /&gt;&lt;/a&gt;</copyright><lastBuildDate>Thu, 30 Apr 2026 18:00:45 +0000</lastBuildDate><atom:link href="//owent.net/categories/blablabla/index.xml" rel="self" type="application/rss+xml"/><item><title>国产大模型编码能力实测(GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro)</title><link>//owent.net/2026/2607.html</link><pubDate>Thu, 30 Apr 2026 18:00:45 +0000</pubDate><guid>//owent.net/2026/2607.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;这两天 DeepSeek V4 Pro 刚上线，小米那边也送了一个月的 Mimo Token plan。我本来就在试着用 AI 做一个完整工具，正好顺手把几个国产大语言模型都拉进来跑了一轮：GLM 5.1、Kimi K2.6、Mimo v2.5 Pro 和 DeepSeek V4 Pro。&lt;/p&gt;</description></item><item><title>国产大模型（GLM 5.1、Kimi K2.6）真实场景效果和 Coding Plan 额度测试</title><link>//owent.net/2026/2606.html</link><pubDate>Wed, 22 Apr 2026 22:45:45 +0000</pubDate><guid>//owent.net/2026/2606.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;今年国产大模型是真的热闹。新模型一出来，宣传话术一个比一个猛。&lt;/p&gt;
&lt;p&gt;尤其是最近出来的 GLM 5.1。&lt;/p&gt;
&lt;p&gt;&lt;img src="//owent.net/2026/2606-glm5.1.png" alt="2606-glm5.1.png" loading="lazy" /&gt;&lt;/p&gt;
&lt;p&gt;还有 Kimi K2.6。&lt;/p&gt;
&lt;p&gt;&lt;img src="//owent.net/2026/2606-kimi-k2.6.jpg" alt="2606-kimi-k2.6.jpg" loading="lazy" /&gt;&lt;/p&gt;
&lt;p&gt;海报和宣传图看着都很唬人，但真到自己拿去干活的时候，往往还是会闻到一点“跑分没输过，实战没稳过”的味道。所以我干脆把最近几个真实使用场景里的体验记了下来。&lt;/p&gt;</description></item><item><title>新版本libatapp的连接管理——从etcd服务发现到拓扑驱动的自动重连</title><link>//owent.net/2026/2605.html</link><pubDate>Fri, 27 Mar 2026 16:45:45 +0000</pubDate><guid>//owent.net/2026/2605.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;在&lt;a href="../2604"&gt;上一篇文章&lt;/a&gt;中，介绍了 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 从静态子网树到动态拓扑注册表的路由设计变更。新的拓扑模型解决了代理层无法弹性伸缩和跨区域隔离的问题，但路由只是底层基座——上层应用框架 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 才是真正面对业务开发者的接口。&lt;/p&gt;</description></item><item><title>新版本libatbus的设计变更——从树形路由到拓扑驱动</title><link>//owent.net/2026/2604.html</link><pubDate>Fri, 27 Mar 2026 16:08:45 +0000</pubDate><guid>//owent.net/2026/2604.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;很久很久以前，我为了解决以前项目中bus通信膨胀的问题设计了 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。&lt;/p&gt;</description></item><item><title>Protobuf又一坑 - C++标准和ABI兼容性</title><link>//owent.net/2026/2603.html</link><pubDate>Sun, 11 Jan 2026 01:15:45 +0000</pubDate><guid>//owent.net/2026/2603.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;前段时间例行升级我为游戏框架写的构建系统 &lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt; 时，又遇到了 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 的一个新 ABI 兼容性问题。&lt;/p&gt;
&lt;p&gt;这已经不是第一次被 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 的 ABI 兼容性问题“教育”了。这篇把问题拆开讲清楚，并给出一套可落地的规避方案，供遇到类似问题的同学参考。&lt;/p&gt;</description></item><item><title>AI真好用-给Blog主题统一加mermaid,chart.js,excalidraw,draw.io的多种引入方式支持</title><link>//owent.net/2026/2602.html</link><pubDate>Thu, 01 Jan 2026 18:15:45 +0000</pubDate><guid>//owent.net/2026/2602.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;在很久以前，我给我的Blog的主题加了 &lt;a href="https://gohugo.io/"&gt;Hugo&lt;/a&gt; 的针对 &lt;a href="https://mermaid.js.org/"&gt;Mermaid&lt;/a&gt; 和 &lt;a href="https://www.chartjs.org/"&gt;Chart.js&lt;/a&gt; shortcodes 的支持。但是之支持迁入代码的方式。
如果文档很复杂，在Markdown里写大段的代码体验观感也不是很好。
而现在很多Markdown生态里是支持通过代码块的方式嵌入的。
同时现在很多插件可以直接按文件后缀编辑文件，然后直接指向文件的形式引用进来，这样可维护性会好很多。&lt;/p&gt;</description></item><item><title>给内网部署Squid-通用HTTP下载缓存</title><link>//owent.net/2026/2601.html</link><pubDate>Thu, 01 Jan 2026 17:15:45 +0000</pubDate><guid>//owent.net/2026/2601.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;近期，公司代理侧的流量负担持续上升；在高峰期访问常见开发资源（包管理器、SDK、依赖镜像、CDN 文件等）会出现明显抖动。为降低重复下载带来的外网带宽开销与峰值波动，决定在内网引入一套“通用下载缓存代理”。&lt;/p&gt;</description></item><item><title>UE使用CodeChecker和clang-tidy生成静态分析报告</title><link>//owent.net/2025/2507.html</link><pubDate>Mon, 22 Dec 2025 00:15:45 +0000</pubDate><guid>//owent.net/2025/2507.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;现代化的C++项目可以借助多种静态分析工具来检查和发现潜在问题，包括空指针访问风险、未定义行为（UB）、内存错误等。&lt;/p&gt;
&lt;p&gt;在我们的项目中，服务器工程基于 CMake 构建系统，可以方便地利用社区支持来集成这些静态分析工具，如 &lt;a href="https://clang.llvm.org/extra/clang-tidy/"&gt;clang-tidy&lt;/a&gt;、&lt;a href="https://clang-analyzer.llvm.org/"&gt;clang-analyzer&lt;/a&gt;、&lt;a href="https://codechecker.readthedocs.io/"&gt;CodeChecker&lt;/a&gt; 等。然而，另一部分 C++ 代码运行在 UE（Unreal Engine）引擎中。由于 UE 在编译流程上做了一些特殊扩展，再加上 UBT（UnrealBuildTool）工具在某些能力上的限制，直接开启静态分析会遇到一些问题：&lt;/p&gt;</description></item><item><title>找出UE的循环依赖</title><link>//owent.net/2025/2506.html</link><pubDate>Sun, 21 Dec 2025 17:15:45 +0000</pubDate><guid>//owent.net/2025/2506.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;在大型 UE（Unreal Engine）项目中，&amp;ldquo;模块/插件&amp;quot;是维持工程可维护性的基本手段。但随着工程规模增长，很容易出现循环依赖问题：&lt;/p&gt;</description></item><item><title>C++小协程栈和临时变量及作用域的栈溢出问题分析</title><link>//owent.net/2025/2505.html</link><pubDate>Sat, 02 Aug 2025 17:15:45 +0000</pubDate><guid>//owent.net/2025/2505.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;近期在给一个项目换一些底层接口的日志处理部分。把原始的类 &lt;code&gt;printf&lt;/code&gt; 的格式化方式换成 &lt;a href="https://fmt.dev/"&gt;fmtlib&lt;/a&gt; / &lt;a href="https://en.cppreference.com/w/cpp/utility/format.html"&gt;C++ 20 Text Formatting&lt;/a&gt; 的方案。&lt;/p&gt;
&lt;p&gt;然后发现，替换完一段未执行的代码后，会发生内存写坏的情况。&lt;/p&gt;</description></item><item><title>游戏服务的可观测性能力建设（C++生态）</title><link>//owent.net/2025/2504.html</link><pubDate>Fri, 23 May 2025 20:15:45 +0000</pubDate><guid>//owent.net/2025/2504.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;近年来可观测性领域越来越成熟，游戏服务的可观测性能力建设日益成为提升产品质量与运维效率的关键环节。随着游戏系统架构的不断复杂化，传统的监控和故障排查方式已难以满足业务高可用和用户体验优化的需求。通过健全的可观测性体系，可以实现对游戏服务全链路的实时监控、异常检测与分析，助力技术团队及时发现和定位问题，推动产品持续优化与稳定迭代，从而为玩家提供更加流畅和可靠的游戏体验。&lt;/p&gt;</description></item><item><title>指标上报的多线程优化和多拉取源点优化</title><link>//owent.net/2025/2503.html</link><pubDate>Wed, 21 May 2025 00:39:45 +0000</pubDate><guid>//owent.net/2025/2503.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;我给我们的服务器框架深度集成了一些可观测性的能力。使用 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 作为接入层。
在指标方面，我们允许业务层自由地定制化指标上报和拉取，并以此实现策略控制。上报的时候有Pull模式接口（异步接口），也有Push模式接口（同步接口）。
为了减少 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 内部的视图合并开销，性能最佳，我们尽量使用异步接口。
但是这种情况下由于 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 内部存在后台Processor线程、Exporter线程等，指标的采集往往需要跨线程操作。
这就要求我们上报代码逻辑需要保证线程安全。&lt;/p&gt;</description></item><item><title>协程(libcopp)的Channel功能和CPU命中率优化</title><link>//owent.net/2025/2502.html</link><pubDate>Wed, 12 Mar 2025 20:58:45 +0000</pubDate><guid>//owent.net/2025/2502.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;设计 &lt;a href="https://owent.net/2022/2206.html"&gt;《libcopp对C++20协程的接入和接口设计》&lt;/a&gt; 的时候，由于C++20协程的promise和awaitable是链式关联的。所以当时设计promise和awaitable之间通过一个共享的context来通信交互。当时第一版实现直接使用了 &lt;code&gt;std::shared_ptr&lt;/code&gt; 来管理共享引用，也预留了个规划是未来可以改成非线程安全的引用来减少不必要的Cache Miss开销。&lt;/p&gt;</description></item><item><title>通用RPC代码生成器</title><link>//owent.net/2025/2501.html</link><pubDate>Thu, 13 Feb 2025 17:06:45 +0000</pubDate><guid>//owent.net/2025/2501.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;我们项目组需要接入多种RPC接入和工具转换流程，并且每种接入层有自己的扩展和定制需求。为了提高开发效率，我们需要一个通用的RPC代码生成器，能够支持多种RPC接入层级的代码生成，同时支持自定义插件和模板。并且自由增加自定义插件而不需要变更构建系统流程。以便提供最佳的灵活性且能支持protobuf的所有特性。&lt;/p&gt;</description></item><item><title>实现strong_rc_ptr(比shared_ptr更快的引用计数智能指针)</title><link>//owent.net/2024/2405.html</link><pubDate>Tue, 08 Oct 2024 20:45:45 +0000</pubDate><guid>//owent.net/2024/2405.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;我们的新项目有个比较复杂的全区全服交易行系统，其中搜索和推荐是高实时性全区服多维度排序的，并且要支持比较复杂的标签交集查询和属性范围查询的自由组合。
当有订单发生变化时，它不仅仅会影响全服状态下搜索和推荐条件的结果变化，也会同时影响商品维度的聚合，交易行层面的数据聚合。&lt;/p&gt;</description></item><item><title>手夯一个STL allocator和对象内存分析组件</title><link>//owent.net/2024/2404.html</link><pubDate>Wed, 21 Aug 2024 23:51:45 +0000</pubDate><guid>//owent.net/2024/2404.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;我们项目组前段时间排查和分析压测环境下的某些业务模块大量索引结构的内存问题。通用的工具比如 &lt;a href="https://github.com/jemalloc/jemalloc"&gt;jemalloc+jeperf&lt;/a&gt; 或者 &lt;a href="https://github.com/google/tcmalloc"&gt;tcmalloc+gperf&lt;/a&gt; 的组合过于底层，一方面开启跟踪开销较高，另一方面也是会产生过多噪音数据影响判断。所以我针对我们的智能指针（包含 &lt;code&gt;std::shared_ptr&lt;/code&gt; 和我最近写了个非线程安全的版本的 &lt;code&gt;strong_rc_ptr&lt;/code&gt; ， 这个后面有空再分享）和STL容器实现了allocator来帮助动态的手动插桩来分析问题。
最终的效果是可以通过一键替换类型申明的Allocator来插入动态控制和插桩统计的能力，这里分享一下手夯标准STL allocator的一些实现细节，方便其他小伙伴如果需要做类似的实现来参考。&lt;/p&gt;</description></item><item><title>std::condition_variable 的信号丢失问题</title><link>//owent.net/2024/2403.html</link><pubDate>Fri, 02 Aug 2024 15:30:45 +0000</pubDate><guid>//owent.net/2024/2403.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;这篇分享拖更了好久了。问题起源于去年我们项目组接入 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 的时候，在进程优雅退出的时候偶现超时，虽然可以直接kill进程没啥影响但是退出不“优雅”的话总归会破坏发布流程，增加人工介入的成本。这里记录一下问题可能其他的组件有类似的用法也会有相似的问题。&lt;/p&gt;</description></item><item><title>踩坑一处（GCC）STL `std::async` 实现BUG导致的crash问题</title><link>//owent.net/2024/2402.html</link><pubDate>Sun, 21 Jul 2024 02:32:45 +0000</pubDate><guid>//owent.net/2024/2402.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;近期发现项目组使用新版本的 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 的时候偶现崩溃。崩溃的位置在STL的 &lt;code&gt;std::future&lt;/code&gt; 析构的地方，而这个 &lt;code&gt;std::future&lt;/code&gt; 由 &lt;code&gt;std::async&lt;/code&gt;创建。
比较违反直觉，这里记录分享一下分析和解决过程方面其他碰到的小伙伴们。&lt;/p&gt;</description></item><item><title>GCC 14的一个warning to error BUG</title><link>//owent.net/2024/2401.html</link><pubDate>Thu, 30 May 2024 20:39:45 +0000</pubDate><guid>//owent.net/2024/2401.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;早先社区报过 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 在GCC 14中编译不通过的问题。最近我也是先升级我们项目组的工具链，主要也是把GCC升级到GCC 14，这时候发现有些第三方工具构建失败。
这里记录一下以防后续其他人碰到参考。&lt;/p&gt;</description></item><item><title>给xresloader（Excel导表工具）增强UE读表支持（包含蓝图,Blueprint）</title><link>//owent.net/2023/2309.html</link><pubDate>Mon, 13 Nov 2023 22:57:45 +0000</pubDate><guid>//owent.net/2023/2309.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。&lt;/p&gt;
&lt;p&gt;主要功能特点：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;跨平台（java 11 or upper）&lt;/li&gt;
&lt;li&gt;Excel =&amp;gt; protobuf/msgpack/lua/javascript/json/xml&lt;/li&gt;
&lt;li&gt;完整支持协议结构，包括嵌套结构和数组嵌套&lt;/li&gt;
&lt;li&gt;同时支持protobuf proto v2 和 proto v3&lt;/li&gt;
&lt;li&gt;支持导出proto枚举值到lua/javascript代码和json/xml数据&lt;/li&gt;
&lt;li&gt;支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）&lt;/li&gt;
&lt;li&gt;支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 &lt;code&gt;DataTable&lt;/code&gt; 加载代码&lt;/li&gt;
&lt;li&gt;支持别名表，用于给数据内容使用一个易读的名字&lt;/li&gt;
&lt;li&gt;支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效&lt;/li&gt;
&lt;li&gt;支持通过protobuf协议插件控制部分输出&lt;/li&gt;
&lt;li&gt;支持自动合表，把多个Excel数据表合并成一个输出文件&lt;/li&gt;
&lt;li&gt;支持公式&lt;/li&gt;
&lt;li&gt;支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map&lt;/li&gt;
&lt;li&gt;支持空数据压缩（裁剪）或保留定长数组&lt;/li&gt;
&lt;li&gt;支持基于正则表达式分词的字段名映射转换规则&lt;/li&gt;
&lt;li&gt;支持设置数据版本号&lt;/li&gt;
&lt;li&gt;Lua输出支持全局导出或导出为 &lt;code&gt;require&lt;/code&gt; 模块或导出为 &lt;code&gt;module&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;Javascript输出支持全局导出或导出为 &lt;code&gt;nodejs&lt;/code&gt; 模块或导出为 &lt;code&gt;AMD&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;提供GUI批量转换工具（支持Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;CLI/GUI批量转换工具支持include来实现配置复用&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 包含了多个组件，其中最主要的部分分别是。&lt;/p&gt;</description></item><item><title>Opentelemetry社区在gRPC的几个链接问题(静态库和动态库混用,musl工具链,符号裁剪)</title><link>//owent.net/2023/2308.html</link><pubDate>Sat, 28 Oct 2023 18:10:45 +0000</pubDate><guid>//owent.net/2023/2308.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 在标准上报协议OTLP里是支持使用 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; 作为传输协议的。但是，当 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; 被作为静态库同时链接进多个动态库时，在一些平台上会有一些问题。这是 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; 本身的一些实现方式导致的。
一直拖到今天才来比较完整得写这个问题的具体成因和解决方案，实际上也有一些其他库有相似实现的也会有相同的问题，所以分享出来看看有没有其他同学也可能碰到可以参考一下。&lt;/p&gt;</description></item><item><title>Excel转表工具(xresloader)的新验证器（验证外部Excel和文本数据，唯一性和自定义规则）</title><link>//owent.net/2023/2307.html</link><pubDate>Sun, 20 Aug 2023 00:19:45 +0000</pubDate><guid>//owent.net/2023/2307.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。&lt;/p&gt;
&lt;p&gt;主要功能特点：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;跨平台（java 11 or upper）&lt;/li&gt;
&lt;li&gt;Excel =&amp;gt; protobuf/msgpack/lua/javascript/json/xml&lt;/li&gt;
&lt;li&gt;完整支持协议结构，包括嵌套结构和数组嵌套&lt;/li&gt;
&lt;li&gt;同时支持protobuf proto v2 和 proto v3&lt;/li&gt;
&lt;li&gt;支持导出proto枚举值到lua/javascript代码和json/xml数据&lt;/li&gt;
&lt;li&gt;支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）&lt;/li&gt;
&lt;li&gt;支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 &lt;code&gt;DataTable&lt;/code&gt; 加载代码&lt;/li&gt;
&lt;li&gt;支持别名表，用于给数据内容使用一个易读的名字&lt;/li&gt;
&lt;li&gt;支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效&lt;/li&gt;
&lt;li&gt;支持通过protobuf协议插件控制部分输出&lt;/li&gt;
&lt;li&gt;支持自动合表，把多个Excel数据表合并成一个输出文件&lt;/li&gt;
&lt;li&gt;支持公式&lt;/li&gt;
&lt;li&gt;支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map&lt;/li&gt;
&lt;li&gt;支持空数据压缩（裁剪）或保留定长数组&lt;/li&gt;
&lt;li&gt;支持基于正则表达式分词的字段名映射转换规则&lt;/li&gt;
&lt;li&gt;支持设置数据版本号&lt;/li&gt;
&lt;li&gt;Lua输出支持全局导出或导出为 &lt;code&gt;require&lt;/code&gt; 模块或导出为 &lt;code&gt;module&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;Javascript输出支持全局导出或导出为 &lt;code&gt;nodejs&lt;/code&gt; 模块或导出为 &lt;code&gt;AMD&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;提供GUI批量转换工具（支持Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;CLI/GUI批量转换工具支持include来实现配置复用&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 包含了多个组件，其中最主要的部分分别是。&lt;/p&gt;</description></item><item><title>protobuf v22和gRPC v1.55版本升级的依赖变化和upb适配</title><link>//owent.net/2023/2306.html</link><pubDate>Sat, 17 Jun 2023 17:01:45 +0000</pubDate><guid>//owent.net/2023/2306.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;近期的 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; v22和 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; v1.55 版本在构建流程层面引入了一些比较大的变化。
最初我关注到这个问题是在我参与的一个社区项目 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 的issue中（ &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp/issues/2095"&gt;https://github.com/open-telemetry/opentelemetry-cpp/issues/2095&lt;/a&gt; ）。
直到后来，我们在自己的构建系统 &lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt; 对 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 和 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; 也进行了升级。所以顺带给社区的项目也提交了一些相关的Patch，在这里分享一下可能其他同学也会碰到。&lt;/p&gt;</description></item><item><title>关于protobuf近期版本（v20/v3.20+）和 gRPC v1.54版本在某些编译环境下的一些链接和编译问题</title><link>//owent.net/2023/2305.html</link><pubDate>Fri, 16 Jun 2023 22:25:45 +0000</pubDate><guid>//owent.net/2023/2305.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;年初的时候我们项目组的构建系统( &lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt; )里把 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 升级到了 v20/v3.20 版本, &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; 也升级到了 v1.54 版本。然而这两个版本在Linux的ELF ABI和MacOS的Macho ABI下都出现了一些符号未定义的问题（当然也包含Android和iOS）。
这些问题也不仅限于 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; v20/v3.20 和 &lt;a href="https://github.com/grpc/grpc"&gt;gRPC&lt;/a&gt; v1.54，后续的版本有些修复了，有些没有。在官方完全修复之前，我们自己打了一些patch去修复这些问题。&lt;/p&gt;</description></item><item><title>xresloader-Excel导表工具链的近期变更汇总</title><link>//owent.net/2023/2304.html</link><pubDate>Tue, 18 Apr 2023 20:27:45 +0000</pubDate><guid>//owent.net/2023/2304.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。&lt;/p&gt;
&lt;p&gt;主要功能特点：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;跨平台（java 11 or upper）&lt;/li&gt;
&lt;li&gt;Excel =&amp;gt; protobuf/msgpack/lua/javascript/json/xml&lt;/li&gt;
&lt;li&gt;完整支持协议结构，包括嵌套结构和数组嵌套&lt;/li&gt;
&lt;li&gt;同时支持protobuf proto v2 和 proto v3&lt;/li&gt;
&lt;li&gt;支持导出proto枚举值到lua/javascript代码和json/xml数据&lt;/li&gt;
&lt;li&gt;支持导出proto描述信息值到lua/javascript代码和json/xml数据（支持自定义插件，方便用户根据proto描述自定义反射功能）&lt;/li&gt;
&lt;li&gt;支持导出 UnrealEngine 支持的json或csv格式，支持自动生成和导出 UnrealEngine 的 &lt;code&gt;DataTable&lt;/code&gt; 加载代码&lt;/li&gt;
&lt;li&gt;支持别名表，用于给数据内容使用一个易读的名字&lt;/li&gt;
&lt;li&gt;支持验证器，可以在数据里直接填写proto字段名或枚举名，或者验证填入数据的是否有效&lt;/li&gt;
&lt;li&gt;支持通过protobuf协议插件控制部分输出&lt;/li&gt;
&lt;li&gt;支持自动合表，把多个Excel数据表合并成一个输出文件&lt;/li&gt;
&lt;li&gt;支持公式&lt;/li&gt;
&lt;li&gt;支持oneof,支持plain模式输入字符串转为数组或复杂结构,支持map&lt;/li&gt;
&lt;li&gt;支持空数据压缩（裁剪）或保留定长数组&lt;/li&gt;
&lt;li&gt;支持基于正则表达式分词的字段名映射转换规则&lt;/li&gt;
&lt;li&gt;支持设置数据版本号&lt;/li&gt;
&lt;li&gt;Lua输出支持全局导出或导出为 &lt;code&gt;require&lt;/code&gt; 模块或导出为 &lt;code&gt;module&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;Javascript输出支持全局导出或导出为 &lt;code&gt;nodejs&lt;/code&gt; 模块或导出为 &lt;code&gt;AMD&lt;/code&gt; 模块。&lt;/li&gt;
&lt;li&gt;提供CLI批量转换工具（支持python 2.7/python 3 @ Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;提供GUI批量转换工具（支持Windows、macOS、Linux）&lt;/li&gt;
&lt;li&gt;CLI/GUI批量转换工具支持include来实现配置复用&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;a href="https://xresloader.atframe.work/"&gt;xresloader&lt;/a&gt; 包含了多个组件，其中最主要的部分分别是。&lt;/p&gt;</description></item><item><title>打通游戏服务端框架的C++20协程改造的最后一环</title><link>//owent.net/2023/2303.html</link><pubDate>Sat, 08 Apr 2023 20:21:45 +0000</pubDate><guid>//owent.net/2023/2303.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;我们终于在年初的时候最后完成了整体服务器框架对C++20协程的支持和接入。虽然之前陆陆续续抽时间改造一些组件，让它支持C++20协程，期间也记录了一些早期的设计思路和踩的坑（包括 &lt;a href="https://owent.net/2020/2004.html"&gt;《libcopp接入C++20 Coroutine和一些过渡期的设计》&lt;/a&gt;和&lt;a href="https://owent.net/2022/2206.html"&gt;《libcopp对C++20协程的接入和接口设计》&lt;/a&gt;），其中不乏一些C++20协程使用上可能打破我们常规思路细节和编译器的BUG。而且这些都是各个组件的改造，并没有最后整合到一起。&lt;/p&gt;</description></item><item><title>Opentelemetry-cpp的Logs模块标准更新(涉及近期版本:1.8-1.9的BREAK CHANGES)</title><link>//owent.net/2023/2302.html</link><pubDate>Sat, 25 Feb 2023 11:39:45 +0000</pubDate><guid>//owent.net/2023/2302.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;Opentelemetry-cpp&lt;/a&gt; 是可观测领域，&lt;a href="https://opentelemetry.io/"&gt;opentelemetry&lt;/a&gt; (CNCF基金会孵化项目)的&lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;C++ SDK接入层&lt;/a&gt;。
&lt;a href="https://opentelemetry.io/"&gt;opentelemetry&lt;/a&gt; 里面主要是分链路跟踪(Trace)、指标(Metrics)、日志(Logs)三大块。
同时 &lt;a href="https://opentelemetry.io/"&gt;opentelemetry&lt;/a&gt; 有一个标准规范文档 &lt;a href="https://github.com/open-telemetry/opentelemetry-specification"&gt;opentelemetry-specification&lt;/a&gt; ，而SDK实现主要就是来对这个标准规范文档的特定语言实现。
由于日志(Logs)这一块一直处于Experimental阶段，所以很长时间以来 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;C++ SDK接入层&lt;/a&gt; 都没有及时更新跟进规范的变化。&lt;/p&gt;</description></item><item><title>给cmake-toolset和工具链(curl等)加HTTP/2和HTTP/3支持</title><link>//owent.net/2023/2301.html</link><pubDate>Mon, 30 Jan 2023 11:39:45 +0000</pubDate><guid>//owent.net/2023/2301.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;前段时间集成一些公司内组件的时候发现它依赖 &lt;a href="https://github.com/nghttp2/nghttp2.git"&gt;nghttp2&lt;/a&gt; 。正好之前一直有给我的构建工具(&lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt;)里的构建 &lt;a href="https://github.com/curl/curl.git"&gt;curl&lt;/a&gt; 的流程加 HTTP/2 和 HTTP/3 的计划。
所以这波一次性搞定了。&lt;/p&gt;
&lt;h2 id="构建工具-cmake-toolset-和-curl"&gt;构建工具 &lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt; 和 &lt;a href="https://github.com/curl/curl.git"&gt;curl&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;首先，&lt;a href="https://github.com/curl/curl.git"&gt;curl&lt;/a&gt; 是支持多种第三方库作为 HTTP/2 和 HTTP/3（QUIC）算法库的。比如 &lt;a href="https://github.com/ngtcp2/nghttp3.git"&gt;nghttp3&lt;/a&gt;+&lt;a href="https://github.com/ngtcp2/ngtcp2.git"&gt;ngtcp2&lt;/a&gt;，或者微软家 &lt;a href="https://github.com/microsoft/msquic"&gt;msquic&lt;/a&gt;，或者Google家 &lt;a href="https://github.com/google/quiche"&gt;quiche&lt;/a&gt;。
其中HTTP/3只能选一个，互相是冲突的。而Google的&lt;a href="https://github.com/google/quiche"&gt;quiche&lt;/a&gt;官方仅有对bazel构建系统的支持，而我的&lt;a href="https://github.com/atframework/cmake-toolset"&gt;cmake-toolset&lt;/a&gt;是cmake生态的。
这里选用 &lt;a href="https://github.com/ngtcp2/nghttp3.git"&gt;nghttp3&lt;/a&gt;+&lt;a href="https://github.com/ngtcp2/ngtcp2.git"&gt;ngtcp2&lt;/a&gt; 的组合，主要是为了和其他的模块共享依赖。&lt;/p&gt;</description></item><item><title>又开新坑之 coredns 插件: nftables和filter</title><link>//owent.net/2022/2210.html</link><pubDate>Mon, 03 Oct 2022 21:23:45 +0000</pubDate><guid>//owent.net/2022/2210.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;传说中的下一代 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; 的 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 已经出来了好长时间了。现在主流发行版的内核也都已经更新到了对 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 支持足够好的版本。
在2年多前我也初步体验过了 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; ，当时写了个 &lt;a href="https://owent.net/2020/2002.html"&gt;《nftables初体验》&lt;/a&gt; 。并且开始使用 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 来实现对家里软路由的管理。
而去年的时候，我也尝试用 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 实现了双拨（详见: &lt;a href="https://owent.net/2021/2104.html"&gt;《折腾一下nftables下的双拨》&lt;/a&gt;）并且可以搭配TPROXY透明代理使用。&lt;/p&gt;</description></item><item><title>关于opentelemetry-cpp社区对于C++ Head Only组件单例和符号可见性的讨论小记</title><link>//owent.net/2022/2209.html</link><pubDate>Sun, 02 Oct 2022 20:43:45 +0000</pubDate><guid>//owent.net/2022/2209.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;前段时间有人在 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 提出了api组件在动态库中单例无法工作的 issue ，( &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp/issues/1520"&gt;https://github.com/open-telemetry/opentelemetry-cpp/issues/1520&lt;/a&gt; ) 。&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;a href="https://opentelemetry.io/"&gt;opentelemetry&lt;/a&gt; 是可观测性领域的开源项目，目标是统一链路跟踪、数据指标和日志的服务、上报、协议和接口规范，目前属于 &lt;a href="https://cncf.io/"&gt;CNCF基金会&lt;/a&gt; 孵化项目。而 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 则是 &lt;a href="https://opentelemetry.io/"&gt;opentelemetry&lt;/a&gt; 中对标准规范SDK的C++实现。&lt;/p&gt;</description></item><item><title>填个转表工具 xresloader 去年的坑（数组尾部裁剪）</title><link>//owent.net/2022/2208.html</link><pubDate>Sat, 27 Aug 2022 20:59:45 +0000</pubDate><guid>//owent.net/2022/2208.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/xresloader/xresloader"&gt;xresloader&lt;/a&gt; 是一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript、UE-Csv、UE-Json等数据格式的工具。
并且整个工具链还包含了基于模板引起生成读表代码的 &lt;a href="https://github.com/xresloader/xres-code-generator"&gt;xres-code-generator&lt;/a&gt; ，方便产品/策划使用的 &lt;a href="https://github.com/xresloader/xresconv-gui"&gt;GUI批量执行工具 - xresconv-gui&lt;/a&gt; 和方便CI集成和程序使用的 &lt;a href="https://github.com/xresloader/xresconv-cli"&gt;命令行批量执行工具 - xresconv-cli&lt;/a&gt;。&lt;/p&gt;</description></item><item><title>集成 upb 和 lua binding 的踩坑小记</title><link>//owent.net/2022/2207.html</link><pubDate>Sat, 20 Aug 2022 17:59:45 +0000</pubDate><guid>//owent.net/2022/2207.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;最近新项目重新评估了一下protobuf的C/C++ -&amp;gt; Lua binding 方案。之前，使用最广泛的 Lua binding 方案应该是 &lt;a href="https://blog.codingnow.com/"&gt;云风&lt;/a&gt; 的 &lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt; 。但是这个库已经是作者弃坑好多年的状态了。我之前使用 &lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt; 的时候刚碰上 protobuf 3.0 刚出来，当时打了patch来适配 protobuf 3.0 ，还修复了一些其他问题。这个Patch有些推给了上游，有些因为和上游的某些机制冲突没有推。我了解到的很多其他项目也或多或少的打了自己的Patch，大多数也没往上游推。基本上 &lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt; 已经处于一个失维的状态，所以这次新项目就干脆来寻求更好，或者说仍然有良好活跃度的解决方案。于是就看向了 &lt;a href="https://github.com/protocolbuffers/upb"&gt;upb&lt;/a&gt; 。&lt;/p&gt;</description></item><item><title>libcopp对C++20协程的接入和接口设计</title><link>//owent.net/2022/2206.html</link><pubDate>Sat, 23 Jul 2022 20:50:45 +0000</pubDate><guid>//owent.net/2022/2206.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;最近开的坑有点多。有点忙不过来了所以好久没写Blog了。这个C++20的协程接入一直在改造计划中，但是一直没抽出时间来正式实施。
在之前，我写过一个初版的C++20协程接入 &lt;a href="https://owent.net/2020/2004.html"&gt;《libcopp接入C++20 Coroutine和一些过渡期的设计》&lt;/a&gt; 。当时主要是考虑到 Rust也有和C++类似的历史包袱问题，所以参考了一些Rust协程改造过程中的设计。
但是后来尝试在项目中使用的时候发现还是有一些问题。首先C++20的协程并不是零开销抽象，所以强行用Rust的模式反而带来了一定开销和理解上的难度。其次原先的设计中 generator 是按类型去实现外部接入的。但是实际接入SDK的过程中我们有相当一部分类型相同但是接入流程不同的情况，再加上现在各大编译器也都已经让C++20协程的特性脱离 experimental 阶段了，有一些细节有所变化。所以干脆根据我们实际的使用场景，重新设计了下组织结构。&lt;/p&gt;</description></item><item><title>再度优化GCC、LLVM、Clang、libc++、libc++abi等套件的构建脚本</title><link>//owent.net/2022/2205.html</link><pubDate>Sun, 17 Apr 2022 23:43:45 +0000</pubDate><guid>//owent.net/2022/2205.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;一直以来，我都维护了完整的 &lt;a href="https://github.com/owent-utils/bash-shell/tree/main/GCC%20Installer"&gt;GCC 工具链构建工具&lt;/a&gt; 和 &lt;a href="https://github.com/owent-utils/bash-shell/tree/main/LLVM%26Clang%20Installer"&gt;LLVM,Clang,libc++,libc++abi工具链构建工具&lt;/a&gt; 。
一方面是为了测试和体验新版本编译器的功能和利用一些更现代化的工具检查代码中的风险，另一方面也是为了给我得很多开源仓库做多版本适配。
其中所有的编译期依赖项（不包括 tar,awk等可执行程序的工具）都是自己构建的，这样也能管理好某些新版本组件需要的新版本依赖项，并且做到跨发行版兼容。同时很多发行版自带的 LLVM+Clang 套件都缺斤少两，有的缺少 &lt;code&gt;clang-analyzer&lt;/code&gt; ，有的缺少 &lt;code&gt;clang-format&lt;/code&gt; ，也有的缺少 &lt;code&gt;libc++&lt;/code&gt; 和 &lt;code&gt;libc++abi&lt;/code&gt; 或者缺少sanitizer组件。我也是根据自己的需要编译并输出了大多数开发工具，甚至还有一些开发库以便二次开发（比如用libclang写工具来复用libcang的AST功能）。&lt;/p&gt;</description></item><item><title>游戏服务的分布式事务优化（二）- 事务管理</title><link>//owent.net/2022/2204.html</link><pubDate>Sun, 17 Apr 2022 01:45:45 +0000</pubDate><guid>//owent.net/2022/2204.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;接上文 &lt;a href="https://owent.net/2022/2203.html"&gt;《游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块》&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;在挺久以前我写过一篇分享 &lt;a href="https://owent.net/2020/2005.html"&gt;《在游戏服务器中使用分布式事务》&lt;/a&gt; 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。
最开始的实现并不通用，后来我对这个事务的实现做了进一步的优化和重构，抽离成了较为通用的模块，并对之前没全部完成的功能做了进一步完善。
此篇为重构内容的第二部分，主要聚焦于事务管理。&lt;/p&gt;</description></item><item><title>游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块</title><link>//owent.net/2022/2203.html</link><pubDate>Sun, 10 Apr 2022 21:36:45 +0000</pubDate><guid>//owent.net/2022/2203.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;在挺久以前我写过一篇分享 &lt;a href="https://owent.net/2020/2005.html"&gt;《在游戏服务器中使用分布式事务》&lt;/a&gt; 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。
但是时间原因，但是写的第一版是深入我们当时的游戏业务的，第一版仅用在好友服上，既不通用测试也不完善。
后来逐渐把公会服务和聊天的功能也采用或部分采用这里的分布式事务的组件来实现，发现有大量的相似代码。
并且由于分布式事务的流程本身比较复杂，其他人接手的时候看起来就会比较吃力，所以我一直有计划重构这一块代码并且实现为更加通用且灵活的模块。
最近也是基本完成了这部分的工作，通用接口主要分为两部分。第一部分是 &lt;strong&gt;Write Ahead Log(WAL)&lt;/strong&gt; 模块，第二部分是事务管理模块。
本此分享主要专注于第一部分 &lt;strong&gt;Write Ahead Log(WAL)&lt;/strong&gt; 。&lt;/p&gt;</description></item><item><title>记录一些bazel适配用编译选项</title><link>//owent.net/2022/2202.html</link><pubDate>Mon, 14 Feb 2022 20:36:45 +0000</pubDate><guid>//owent.net/2022/2202.html</guid><description>&lt;p&gt;之前搞 &lt;a href="https://github.com/open-telemetry/opentelemetry-cpp"&gt;opentelemetry-cpp&lt;/a&gt; 的时候接触了下 &lt;a href="https://bazel.build/"&gt;bazel&lt;/a&gt; 构建系统。这玩意儿用起来有一点坑，特别是使用自定义编译环境的时候。&lt;/p&gt;
&lt;p&gt;在使用我自己编译的很新版本的 &lt;a href="https://github.com/owent-utils/bash-shell/tree/main/GCC%20Installer"&gt;GCC&lt;/a&gt; 和 &lt;a href="https://github.com/owent-utils/bash-shell/tree/main/LLVM%26Clang%20Installer"&gt;clang+libc++&lt;/a&gt; 的时候，涉及对libssp的检测和 &lt;code&gt;LD_LIBRARY_PATH&lt;/code&gt; 环境变量在 &lt;a href="https://bazel.build/"&gt;bazel&lt;/a&gt; 中各个步骤中的传递，这里记录一下适配脚本。&lt;/p&gt;</description></item><item><title>测试现代化硬件C++浮点数性能和一致性</title><link>//owent.net/2022/2201.html</link><pubDate>Thu, 27 Jan 2022 11:39:45 +0000</pubDate><guid>//owent.net/2022/2201.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;很久很久以前，浮点数的性能和跨平台跨硬件架构一致性是无法获得保证的，所以我们一般在需要强一致性和高性能的游戏服务器中会禁用浮点数，转而使用自己实现的定点数。
这么多年过去了，前段时间想看看现代化硬件下是否仍然有性能问题和是否能够保证一致性，做了些简单的测试，这里记录一下。&lt;/p&gt;</description></item><item><title>适配Boringssl和OpenSSL 3.0</title><link>//owent.net/2021/2110.html</link><pubDate>Sun, 12 Dec 2021 15:23:00 +0000</pubDate><guid>//owent.net/2021/2110.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://www.openssl.org/"&gt;openssl&lt;/a&gt; 3.0发布好一阵子了，我的 &lt;a href="https://github.com/atframework/atframe_utils"&gt;atframe_utils&lt;/a&gt; 其实也挺早前就完成了对 &lt;a href="https://www.openssl.org/"&gt;openssl&lt;/a&gt; 3.0 和 &lt;a href="https://github.com/google/boringssl"&gt;boringssl&lt;/a&gt; 的适配。但是由于懒，一直没写这篇文章。在升级 [openssl] 3.0 和 &lt;a href="https://github.com/google/boringssl"&gt;boringssl&lt;/a&gt; 还是碰到了一些问题的，有些是由于接口变化，有些是由于功能支持还有些也和构建系统相关。还是有必要记录一下，至少能方便以后查找。&lt;/p&gt;</description></item><item><title>近期cmake-toolset的一些适配问题</title><link>//owent.net/2021/2109.html</link><pubDate>Sun, 05 Dec 2021 20:10:00 +0000</pubDate><guid>//owent.net/2021/2109.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;偷懒了好久没有写分享了，最近的时间也是花费了很多时间大量优化了之前游戏服务器框架和组件的很多细节。其中，相对独立且同时也被其他的项目使用的一个工具则是基于 &lt;a href="https://cmake.org/"&gt;cmake&lt;/a&gt; 和 &lt;a href="https://git-scm.com/"&gt;git&lt;/a&gt; 且兼容 &lt;a href="https://vcpkg.io"&gt;vcpkg&lt;/a&gt; 的构建系统 &lt;a href="https://github.com/atframework/cmake-toolset/"&gt;cmake-toolset&lt;/a&gt; 。之所以要写这么个构建工具主要是要提供比 &lt;a href="https://vcpkg.io"&gt;vcpkg&lt;/a&gt; 更宽容的兼容性（没办法我们公司的编译环境比较古老），并且提供更进一步的定制化能力（包含但不限于功能开关和下载源，这些东西 &lt;a href="https://vcpkg.io"&gt;vcpkg&lt;/a&gt; 也是很后期才有了个初步的支持）。那么先来记录一下构建系统适配过程中的一些问题吧。&lt;/p&gt;</description></item><item><title>C++20 Text Formatting/fmtlib 适配问题小记</title><link>//owent.net/2021/2108.html</link><pubDate>Sun, 05 Sep 2021 15:48:54 +0000</pubDate><guid>//owent.net/2021/2108.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;C++20 正式发布已经有一段时间了。其中 &lt;code&gt;Text Formatting&lt;/code&gt; 是一个我个人比较感兴趣的新组件。它主要是解决了之前字符串格式化库 ( &lt;code&gt;printf&lt;/code&gt; 系 ) 的效率问题和运行时安全的问题。
并且新的格式设置的形式也比较友好。相关规范和用法可以参见:&lt;/p&gt;</description></item><item><title>再次重构LLVM+Clang+libcxx+libc++abi+其他相关工具的构建流程</title><link>//owent.net/2021/2107.html</link><pubDate>Sun, 29 Aug 2021 20:29:56 +0000</pubDate><guid>//owent.net/2021/2107.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;我们有时候写一些基础性类库或者实验新功能的时候，常常需要使用到最新版本的GCC和Clang。一些Linux发行版的源里和一些工具链（比如MSYS2）里其实自带LLVM套件的包，&lt;a href="https://llvm.org/"&gt;LLVM&lt;/a&gt; 官网也提供一些常见平台的预编译包下载。
那为什么我们还要自己编译呢？如果有注意到的小伙伴可能会发现，很多平台的源和 &lt;a href="https://llvm.org/"&gt;LLVM&lt;/a&gt; 官网 里下载的预编译包，其实是缺失很多组件的。有些没有libc++和libc++abi（CentOS 8），有些没有Sanitizer相关的组件，有些缺失其他的组件。而Clang虽然支持GCC的libstdc++，但是一方面我们写基础性类库还是要优先考虑原生STL库的兼容性，另一方面Clang对libstdc++的支持也不是太好，特别是有些第三方库在这个组合下也是没有适配得很好，同时gdb和libc++的搭配有时候也不是很完善。
所以我们就需要一个组件尽可能开完整地包含LLVM，Clang,libc++,libc++abi还有其他周边工具（各类Sanitizer，clang-tiny,clang-analyzer等等）的工具链。&lt;/p&gt;</description></item><item><title>重构基于CMake的构建工具链</title><link>//owent.net/2021/2106.html</link><pubDate>Sat, 05 Jun 2021 22:38:45 +0000</pubDate><guid>//owent.net/2021/2106.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;对大型项目来说，必然会有很多的依赖项。特别是现代化的组件都会尝试去复用社区资源。而对于C/C++而言，依赖管理一直是一个比较头大的问题。
很多老式的系统和工具都会尝试去走相对标准化的安装过程，比如说用 &lt;a href="https://linux.die.net/man/1/pkg-config"&gt;pkg-config&lt;/a&gt; 或者用系统自带的包管理工具装在系统默认路径里。
当然这样很不方便，也不容易定制组件。我使用 &lt;a href="https://cmake.org/"&gt;cmake&lt;/a&gt; 比较多，所以一直以来在我的 &lt;a href="https://github.com/atframework"&gt;atframework&lt;/a&gt; 项目集中有一个 utility 项目 &lt;a href="https://github.com/atframework/atframe_utils"&gt;atframe_utils&lt;/a&gt;，里面包含一些常用的构建脚本。
并且在 &lt;a href="https://github.com/atframework/atsf4g-co"&gt;atsf4g-co&lt;/a&gt; 中实现了一些简单的包管理和构建流程。&lt;/p&gt;</description></item><item><title>新版GCC和LLVM+Clang终于Release啦</title><link>//owent.net/2021/2105.html</link><pubDate>Sun, 16 May 2021 14:34:34 +0000</pubDate><guid>//owent.net/2021/2105.html</guid><description>&lt;p&gt;可能是疫情的原因，GCC好久没发布啦。最近总于又Release了，还是大版本。并且三大编译器对C++20的支持也都七七八八了。所以特意立贴庆祝一下，顺带更新一波构建脚本把这两年的一些改动列举一下。&lt;/p&gt;</description></item><item><title>折腾一下nftables下的双拨</title><link>//owent.net/2021/2104.html</link><pubDate>Sun, 16 May 2021 14:11:00 +0000</pubDate><guid>//owent.net/2021/2104.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;我们小区终于有联通线路啦，之前一直用的联通的手机号。它套餐满一定额度以后送一条宽带，本着不用白不用的精神，那必须不能浪费。还好我之前设置软路由得时候就预留了两个网口作wan，所以新增得联通得线路直接插那个口上就行了。（吐槽一下联通给得光猫竟然是8年前生产的老古董）&lt;/p&gt;</description></item><item><title>[C++20] Module partitions和符号交叉引用（声明和实现分离）</title><link>//owent.net/2021/2103.html</link><pubDate>Thu, 25 Mar 2021 22:38:52 +0000</pubDate><guid>//owent.net/2021/2103.html</guid><description>&lt;p&gt;C++20 开始支持 &lt;strong&gt;Module&lt;/strong&gt; 了。在以前C++为了解决循环依赖问题，经常会把类或者函数声明写前面，实现写后面。然后中间的代码就可以实现内部模块的内聚而互相引用。比如:&lt;/p&gt;</description></item><item><title>[Rust] 实现一个线程安全且迭代器可以保存的链表</title><link>//owent.net/2021/2102.html</link><pubDate>Tue, 09 Mar 2021 19:19:45 +0000</pubDate><guid>//owent.net/2021/2102.html</guid><description>&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;今年有个想法，重新设计 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 然后用 &lt;a href="https://www.rust-lang.org/"&gt;Rust&lt;/a&gt; 实现出来，然后可以加入一些云原生的支持。这需要一个定时器模块，我看了下 &lt;a href="https://www.rust-lang.org/"&gt;Rust&lt;/a&gt; 现有的几种定时器的实现，大多是基于堆或树的结构的，没有找到jiffies定时器的实现，所以想自己实现一个算了。这个定时器的实现又需要类似 C++ 的 &lt;code&gt;std::list::iterator&lt;/code&gt; 的 &lt;strong&gt;插入和删除某个迭代器对其他迭代器没有影响&lt;/strong&gt; 的特性，但是 &lt;a href="https://www.rust-lang.org/"&gt;Rust&lt;/a&gt; 的数据结构都不是这种设计模型。所以就决定自己写一个吧。&lt;/p&gt;</description></item><item><title>基于protobuf的代码生成</title><link>//owent.net/2021/2101.html</link><pubDate>Tue, 09 Feb 2021 11:39:45 +0000</pubDate><guid>//owent.net/2021/2101.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;前段时间我用 &lt;a href="https://www.python.org/"&gt;Python&lt;/a&gt; 和 &lt;a href="https://www.makotemplates.org/"&gt;Mako&lt;/a&gt; 模板引擎重新梳理了我们项目中的一些重复的流程。重构了所有的RPC系统。这个工作其实完成了挺久了，但是迫于懒一直拖着没写完这篇记录，就一直没发。&lt;/p&gt;</description></item><item><title>几个使用protobuf中C++接口的Arena的坑</title><link>//owent.net/2020/2009.html</link><pubDate>Tue, 10 Nov 2020 16:35:33 +0000</pubDate><guid>//owent.net/2020/2009.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 从3.0版本开始对C++增加了Arena接口，可以用于使用连续的内存块分配内部对象，并且可以更容易精确地控制对象地生命周期，最终达到减少内存碎片地目的。最近我给我们项目的部分接口流程进行相关地改造，在大多数使用 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 的地方都增加了对Arena的支持，但是在接入过程中也碰到了一些问题和坑。&lt;/p&gt;</description></item><item><title>Amazon Aurora DB存储引擎论文阅读小记</title><link>//owent.net/2020/2008.html</link><pubDate>Sat, 07 Nov 2020 19:27:08 +0000</pubDate><guid>//owent.net/2020/2008.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;前段时间接触到腾讯云的一个新数据库产品 &lt;a href="https://cloud.tencent.com/product/cynosdb"&gt;CynosDB&lt;/a&gt; 是基于 &lt;a href="https://aws.amazon.com/rds/aurora/"&gt;Amazon Aurora&lt;/a&gt; 数据库的Paper实现的。我比较感兴趣就来看看它和之前看过的 &lt;a href="https://ai.google/research/pubs/pub39966" title="Spanner: Google's Globally-Distributed Database"&gt;Spanner&lt;/a&gt; 之类有什么不同，也许部分设计也能用在我们游戏业务的服务器中。它的主要的创新点在于重新设计了binlog和存储的部分，所以我也主要就看了两篇Paper： &lt;a href="https://media.amazonwebservices.com/blog/2017/aurora-design-considerations-paper.pdf" title="Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases"&gt;《Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases》&lt;/a&gt; 是一个整体性质的介绍和概述； &lt;a href="https://dl.acm.org/doi/abs/10.1145/3183713.3196937" title="Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes"&gt;《Amazon Aurora: On Avoiding Distributed Consensus for I/Os,Commits, and Membership Changes》&lt;/a&gt; 是对其重点部分的存储服务的。&lt;/p&gt;</description></item><item><title>近期对libatapp的一些优化调整(增加服务发现和连接管理,支持yaml等)</title><link>//owent.net/2020/2007.html</link><pubDate>Sun, 04 Oct 2020 15:43:17 +0000</pubDate><guid>//owent.net/2020/2007.html</guid><description>&lt;p&gt;最近给 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 增加了一系列改造，非常多且琐碎，这里简单记录下吧。&lt;/p&gt;
&lt;p&gt;首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 是不依赖 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 的，现在 既然已经依赖 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 了就转为 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 管理了。同时现在还支持YAML配置，使用 &lt;a href="https://github.com/jbeder/yaml-cpp"&gt;yaml-cpp&lt;/a&gt; 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 &lt;a href="https://www.envoyproxy.io/"&gt;Envoy proxy&lt;/a&gt; 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 &lt;em&gt;YAML转&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 、 &lt;em&gt;conf/ini转&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 和 &lt;em&gt;指定层级配置导出到&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。&lt;/p&gt;</description></item><item><title>xresloader转表工具链增加了一些新功能(map,oneof支持，输出矩阵，基于模板引擎的加载代码生成等)</title><link>//owent.net/2020/2006.html</link><pubDate>Sat, 29 Aug 2020 14:07:45 +0000</pubDate><guid>//owent.net/2020/2006.html</guid><description>&lt;p&gt;&lt;a href="https://github.com/xresloader/xresloader"&gt;xresloader&lt;/a&gt; 是一组用于把Excel数据结构化并导出为程序可读的数据文件的导表工具集。它包含了一系列跨平台的工具、协议描述和数据读取代码。支持把Excel配置输出成 protobuf二进制、xml、json、lua、javascript、nodejs、msgpack、&lt;a href="https://www.unrealengine.com/"&gt;UE&lt;/a&gt;的Json格式及支持蓝图的代码、&lt;a href="https://www.unrealengine.com/"&gt;UE&lt;/a&gt;的Csv格式及支持蓝图的代码。&lt;/p&gt;</description></item><item><title>在游戏服务器中使用分布式事务</title><link>//owent.net/2020/2005.html</link><pubDate>Sat, 27 Jun 2020 12:19:45 +0000</pubDate><guid>//owent.net/2020/2005.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;游戏业务通常有个特点是模块相关性非常高，模块之间的联动也非常密集且复杂。要保持各个相关模块的数据一致性，同时又兼顾效率和，没有一个通用的方法。通常的做法是走有损服务（也叫柔性服务）和自动修复的方式。比如支付服务一般的做法是在2PC的基础上增加redo log，对于发放和订单确认这两方，如果失败了会尝试几次补发。又或者好友系统或者公会，因为涉及多个对象的数据相互索引，一些做法是玩家在线的时候定期去检查数据是否正确，如果不正确走修复流程。&lt;/p&gt;</description></item><item><title>libcopp接入C++20 Coroutine和一些过渡期的设计</title><link>//owent.net/2020/2004.html</link><pubDate>Fri, 22 May 2020 15:36:58 +0000</pubDate><guid>//owent.net/2020/2004.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;最近GCC 10.1.0 发布，三大编译器（MSVC、GCC、Clang）都已经支持了&lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20协程&lt;/a&gt;，之前给 &lt;a href="https://github.com/owent/libcopp/"&gt;libcopp&lt;/a&gt; 接入 &lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20协程&lt;/a&gt; 的计划也就提上了日程。&lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20协程&lt;/a&gt; 在创建、切换开销和内存分配上和传统有栈协程相比有着无可比拟的优势。但是C++20全面普及还有相当长一段时间，所以我们设计的重要目标之一就是能够让以后的迁移更容易且更平滑地进行，本文则是记录了 &lt;a href="https://github.com/owent/libcopp/"&gt;libcopp&lt;/a&gt; 接入 &lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20协程&lt;/a&gt; 时地一些性能上和平滑接入上的思考和成果。&lt;/p&gt;</description></item><item><title>libatbus 的大幅优化</title><link>//owent.net/2020/2003.html</link><pubDate>Thu, 16 Apr 2020 20:51:58 +0000</pubDate><guid>//owent.net/2020/2003.html</guid><description>&lt;p&gt;最近零碎的事太多了，拖了好久没写blog。一些小的碎片话的东西也不值得写，另一方面是这次大幅优化了 &lt;a href="https://github.com/atframework/"&gt;atframework&lt;/a&gt; 的一些流程细节，特别是针对我们这两年来业务的需求，对 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 进行了一次大重构。这里记录一下重构的内容吧。&lt;/p&gt;</description></item><item><title>nftables初体验</title><link>//owent.net/2020/2002.html</link><pubDate>Mon, 10 Feb 2020 17:12:00 +0000</pubDate><guid>//owent.net/2020/2002.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;之前耳闻 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 是下一代 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; 。前段时间配了一台主机，折腾成家里的软路由。就一并来尝鲜一系列新东西，其中就包括 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 。&lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 和 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; 、&lt;a href="http://ebtables.netfilter.org/"&gt;ebtables&lt;/a&gt; 等一样，都是对底层 xtables 的封装，目前看来 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 比 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; 更简洁易用，更易读，更容易理解，扩展性和也更好。但是目前各个发行版中对 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 的支持还比较参差不齐，导致 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 很多功能比 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; 还是有所缺失，所以个人感觉短期内还是替代不了 &lt;a href="https://nftables.org/projects/iptables/index.html"&gt;iptables&lt;/a&gt; （比如 tproxy 功能需要 linux kernel 4.19+， 而即便是 &lt;a href="https://www.centos.org/"&gt;CentOS 8&lt;/a&gt; 的内核版本也只是 4.18 ，所以都不支持 ）。 &lt;a href="https://nftables.org/projects/nftables/index.html"&gt;nftables&lt;/a&gt; 所支持的功能列表及所以来的内核版本和内核模块可以在这里找到 &lt;a href="https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables"&gt;https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables&lt;/a&gt; 。&lt;/p&gt;</description></item><item><title>容器配置开发环境小计</title><link>//owent.net/2020/2001.html</link><pubDate>Sun, 19 Jan 2020 21:43:50 +0000</pubDate><guid>//owent.net/2020/2001.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;这段时间折腾了好久容器搭建开发环境和家里软路由趟的一些坑。这里先记录一下使用容器搭开发环境的一些流程和问题。&lt;/p&gt;
&lt;p&gt;开发环境一般里面会包含很多的工具和开启一些服务。 我自己的环境测试和搭建了 &lt;a href="https://ubuntu.com/"&gt;ubuntu&lt;/a&gt; 、 &lt;a href="https://centos.org/"&gt;centos&lt;/a&gt; 、 &lt;a href="https://www.archlinux.org/"&gt;archlinux&lt;/a&gt; 。 开启了 &lt;a href="https://en.wikipedia.org/wiki/Systemd"&gt;systemd&lt;/a&gt; ， 支持网络代理+vscode远程开发， 支持 &lt;a href="https://www.docker.com/"&gt;docker&lt;/a&gt; 和 &lt;a href="https://podman.io/"&gt;podman&lt;/a&gt; ，支持k8s，开启了 sshd 。 所有的构建脚本及 Dockerfile 都放在 &lt;a href="https://github.com/owent-utils/docker-setup"&gt;https://github.com/owent-utils/docker-setup&lt;/a&gt; 了，有需要的小伙伴可以自取。&lt;/p&gt;</description></item><item><title>PALM Tree - 适合多核并发架构的B+树 - 论文阅读小记</title><link>//owent.net/2019/1913.html</link><pubDate>Sat, 02 Nov 2019 17:09:58 +0000</pubDate><guid>//owent.net/2019/1913.html</guid><description>&lt;h2 id="介绍"&gt;介绍&lt;/h2&gt;
&lt;p&gt;年初的时候再知乎上看到有人分享 &lt;a href="http://www.vldb.org/pvldb/vol4/p795-sewall.pdf" title="PALM: Parallel Architecture-Friendly Latch-FreeModifications to B+ Trees on Many-Core Processors"&gt;&lt;strong&gt;PALM树&lt;/strong&gt;&lt;/a&gt; 树的文章，看简介是专为多核并发而设计的树形结构。比较好奇所以抽时间来看了看它的设计原理和是如合做到高并发的。&lt;/p&gt;</description></item><item><title>跨平台协程库 - libcopp 简介</title><link>//owent.net/2019/1912.html</link><pubDate>Tue, 22 Oct 2019 21:53:00 +0000</pubDate><guid>//owent.net/2019/1912.html</guid><description>&lt;p&gt;前段时间有同事联系我想看看可能推广我之前写的协程库 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt;，虽然 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt; 已经用到过好几个项目上，这几年也断断续续地写了一些实现细节的文章，但是也但确实需要系统、概览性地介绍下 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt; ，所以就有了这篇文章。&lt;/p&gt;</description></item><item><title>C++20 Coroutine 性能测试 (附带和libcopp/libco/libgo/goroutine/linux ucontext对比)</title><link>//owent.net/2019/1911.html</link><pubDate>Sat, 05 Oct 2019 14:52:00 +0000</pubDate><guid>//owent.net/2019/1911.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;之前写了 &lt;a href="https://owent.net/2018/1806.html"&gt;《协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比》&lt;/a&gt; 和 &lt;a href="https://owent.net/2019/1904.html"&gt;《C++20 Coroutine》&lt;/a&gt; ，但是一直没写 &lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20 Coroutine&lt;/a&gt; 的测试报告。&lt;/p&gt;
&lt;p&gt;现在的草案版本比我当时写 &lt;a href="https://owent.net/2019/1904.html"&gt;《C++20 Coroutine》&lt;/a&gt; 的时候有了一点点更新，&lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;cppreference&lt;/a&gt; 上有文档了(&lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;https://en.cppreference.com/w/cpp/language/coroutines&lt;/a&gt;) 。里面列举的标准文档是&lt;a href="https://owent.net/2019/1904.html"&gt;P0912R5&lt;/a&gt;，这个文档目前还没完工，详情可以看他的来源&lt;a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4775.pdf"&gt;N4775&lt;/a&gt;。不过内容上暂时还没有太大的变化，今天我就照着之前的方式来benchmark一波 &lt;a href="https://en.cppreference.com/w/cpp/language/coroutines"&gt;C++20 Coroutine&lt;/a&gt; 吧。&lt;/p&gt;</description></item><item><title>尝鲜Github Action</title><link>//owent.net/2019/1910.html</link><pubDate>Sat, 21 Sep 2019 13:21:58 +0000</pubDate><guid>//owent.net/2019/1910.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/features/actions"&gt;Github Action&lt;/a&gt; 上线有一阵子了，大概两周前我的所有账号也是都陆陆续续开发了beta测试的权限。然后就来研究了下这个新的 CI 系统是怎么回事。看介绍，和之前碰到的一些CI系统不太一样的地方是，&lt;a href="https://github.com"&gt;Github&lt;/a&gt;是做了一个商店的功能。这样大家就可以自己定义自己的Action，然后方便别人复用。同时也可以统一自己的或者组织在构建过程中的一些公共流程。&lt;/p&gt;</description></item><item><title>一些xresloader（转表工具）的改进</title><link>//owent.net/2019/1909.html</link><pubDate>Wed, 11 Sep 2019 19:49:58 +0000</pubDate><guid>//owent.net/2019/1909.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;最近有几个其他项目组的童鞋给我之前的 &lt;a href="https://xresloader.atframe.work/"&gt;转表工具链-xresloader&lt;/a&gt; 提了几个需求。然后我也根据我们近期一些需求点对转表工具链一起给这套工具做了点功能增强和细节上的一些改进。 这篇blog差不多是这些东西的 CHANGELOG了吧。&lt;/p&gt;</description></item><item><title>protobuf、flatbuffer、msgpack 针对小数据包的简单对比</title><link>//owent.net/2019/1908.html</link><pubDate>Sat, 03 Aug 2019 10:59:58 +0000</pubDate><guid>//owent.net/2019/1908.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;前段时间我尝试给 &lt;a href="https://github.com/atframework/"&gt;atframework&lt;/a&gt; 的 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 所依赖的通信组件 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 里内部协议是&lt;a href="https://msgpack.org/"&gt;msgpack&lt;/a&gt; ， 而 &lt;a href="https://msgpack.org/"&gt;msgpack&lt;/a&gt; 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 的功能，增加一些跨版本向前向后兼容功能，和一些简单的验证功能（仅仅是为了防止误操作导致的问题）。具体的变更等我弄完了再发一篇。&lt;/p&gt;</description></item><item><title>协程框架(libcopp) 小幅优化</title><link>//owent.net/2019/1907.html</link><pubDate>Sat, 22 Jun 2019 12:26:58 +0000</pubDate><guid>//owent.net/2019/1907.html</guid><description>&lt;p&gt;最近抽空继续对 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt; 进行了更新和小幅优化。 首先的Merge了 &lt;a href="https://www.boost.org/libs/context/"&gt;boost.context&lt;/a&gt; 1.70.0 。这次&lt;a href="https://www.boost.org/libs/context/"&gt;boost.context&lt;/a&gt;的更新似乎和它写进 &lt;a href="https://www.boost.org/users/history/version_1_70_0.html"&gt;CHANGELOG&lt;/a&gt; 里的并不完全一致，匹配的只看到 macho 架构的脏数据操作。 不过另外它增加了新的平台支持 mips64，我目前还是简单导入了，但是平台检测工具还没有写，如果要使用是可以通过编译参数切过去的，不过我感觉没人会这么用吧？我自己用都得看一下之前怎么写的。&lt;/p&gt;</description></item><item><title>Excel转表工具(xresloader) 增加protobuf插件功能和集成 UnrealEngine 支持</title><link>//owent.net/2019/1906.html</link><pubDate>Sat, 08 Jun 2019 12:47:58 +0000</pubDate><guid>//owent.net/2019/1906.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;我们项目组最近在学习UE，然后就涉及导表这个东东。之前我已经做过一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript等的工具 &lt;a href="http://github.com/xresloader/"&gt;xresloader&lt;/a&gt; 。并且做了方便服务器集成的CLI工具和方便策划、前端用的GUI工具。那么这次很自然地就让它能够导出UE所支持的内容就行了。然后额外增加了基于protobuf插件形式的多key索引和自动生成一些支持蓝图和非蓝图的常用接口代码。&lt;/p&gt;</description></item><item><title>Anna（支持任意扩展和超高性能的KV数据库系统）阅读笔记</title><link>//owent.net/2019/1905.html</link><pubDate>Sun, 21 Apr 2019 11:38:16 +0000</pubDate><guid>//owent.net/2019/1905.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;年前被同事安利了这个分布式最终一致性的存储系统 &lt;a href="http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf"&gt;Anna&lt;/a&gt; 。初略看了一眼Paper，似乎很是牛X。说是支持任意规模的扩展，并且性能不低于 &lt;a href="https://github.com/fastio/pedis"&gt;pedis&lt;/a&gt;。于是抽空来看看并了解下这套系统的设计特点和这种夸张的单机性能和扩展性的来源。&lt;/p&gt;
&lt;h1 id="主流分布式kvs的比较"&gt;主流分布式KVS的比较&lt;/h1&gt;
&lt;table&gt;
 &lt;thead&gt;
 &lt;tr&gt;
 &lt;th&gt;系统名词&lt;/th&gt;
 &lt;th&gt;扩容设计&lt;/th&gt;
 &lt;th&gt;内存模型&lt;/th&gt;
 &lt;th&gt;针对单个Key的一致性策略&lt;/th&gt;
 &lt;th&gt;针对多个Key一致性策略&lt;/th&gt;
 &lt;/tr&gt;
 &lt;/thead&gt;
 &lt;tbody&gt;
 &lt;tr&gt;
 &lt;td&gt;Masstree&lt;/td&gt;
 &lt;td&gt;多核&lt;/td&gt;
 &lt;td&gt;共享内存&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Bw-tree&lt;/td&gt;
 &lt;td&gt;多核&lt;/td&gt;
 &lt;td&gt;共享内存&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;PALM&lt;/td&gt;
 &lt;td&gt;多核&lt;/td&gt;
 &lt;td&gt;共享内存&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;MICA&lt;/td&gt;
 &lt;td&gt;多核&lt;/td&gt;
 &lt;td&gt;共享内存&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Redis&lt;/td&gt;
 &lt;td&gt;单核&lt;/td&gt;
 &lt;td&gt;N/A&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Serializability"&gt;&lt;strong&gt;串行化(Serializable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;COPS, Bolt-on&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Causal_consistency"&gt;&lt;strong&gt;因果一致性(Causal)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Bayou&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;, 单调读/写, &lt;a href="http://www.dbms2.com/2010/05/01/ryw-read-your-writes-consistency/"&gt;&lt;strong&gt;Read Your Writes&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Dynamo&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Cassandra&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;PNUTS&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;线性写, 单调读&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;CouchDB&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Voldemort&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;HBase&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Riak&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;DocumentDB&lt;/td&gt;
 &lt;td&gt;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://www.allthingsdistributed.com/2007/12/eventually_consistent.html"&gt;&lt;strong&gt;Session&lt;/strong&gt;&lt;/a&gt;, &lt;a href="http://pbs.cs.berkeley.edu/"&gt;&lt;strong&gt;Bounded Staleness&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Memcached&lt;/td&gt;
 &lt;td&gt;多核&amp;amp;分布式&lt;/td&gt;
 &lt;td&gt;共享内存&amp;amp;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;MongoDB&lt;/td&gt;
 &lt;td&gt;多核&amp;amp;分布式&lt;/td&gt;
 &lt;td&gt;共享内存&amp;amp;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;H-Store&lt;/td&gt;
 &lt;td&gt;多核&amp;amp;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Serializability"&gt;&lt;strong&gt;串行化(Serializable)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;ScyllaDB&lt;/td&gt;
 &lt;td&gt;多核&amp;amp;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Linearizability"&gt;&lt;strong&gt;线性(Linearizable)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;无&lt;/td&gt;
 &lt;/tr&gt;
 &lt;tr&gt;
 &lt;td&gt;Anna&lt;/td&gt;
 &lt;td&gt;多核&amp;amp;分布式&lt;/td&gt;
 &lt;td&gt;消息队列&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/Eventual_consistency"&gt;&lt;strong&gt;最终一致性(Eventual)&lt;/strong&gt;&lt;/a&gt;, Item Cut, Writes Follow Reads, 单调读/写, &lt;a href="http://www.dbms2.com/2010/05/01/ryw-read-your-writes-consistency/"&gt;&lt;strong&gt;Read Your Writes&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/PRAM_consistency"&gt;&lt;strong&gt;PRAM&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;td&gt;&lt;a href="https://jepsen.io/consistency/models/read-committed"&gt;&lt;strong&gt;Read Committed&lt;/strong&gt;&lt;/a&gt;, &lt;a href="https://jepsen.io/consistency/models/read-uncommitted"&gt;&lt;strong&gt;Read Uncommitted&lt;/strong&gt;&lt;/a&gt;&lt;/td&gt;
 &lt;/tr&gt;
 &lt;/tbody&gt;
&lt;/table&gt;
&lt;blockquote&gt;
&lt;p&gt;一致性说明:&lt;/p&gt;</description></item><item><title>C++20 Coroutine</title><link>//owent.net/2019/1904.html</link><pubDate>Mon, 04 Mar 2019 20:38:00 +0000</pubDate><guid>//owent.net/2019/1904.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;最近的新闻里 C++20 已经确认的内容里已经有了协程组件，之前都是粗略看过这个协程草案。最近抽时间更加系统性的看了下接入和实现细节。&lt;/p&gt;
&lt;p&gt;我的测试代码都是在MSVC下开启 &lt;code&gt;/await&lt;/code&gt; 选项后测试的，在我本地的Linux clang环境中，可以通过 &lt;code&gt;$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&lt;/code&gt; 编译和运行。&lt;/p&gt;</description></item><item><title>libcopp merge boost.context 1.69.0</title><link>//owent.net/2019/1903.html</link><pubDate>Mon, 11 Feb 2019 10:35:32 +0000</pubDate><guid>//owent.net/2019/1903.html</guid><description>&lt;p&gt;过年啦，最近在看一些非技术性的东西，&lt;a href="http://db.cs.berkeley.edu/jmh/papers/anna_ieee18.pdf"&gt;Anna&lt;/a&gt; 的Paper也还没看完。随手优化了下Blog的主题，修复和优化了一些小问题。然后来Merge了一下 &lt;a href="https://www.boost.org/libs/context/"&gt;boost.context&lt;/a&gt; 最新 1.69.0 版本的asm部分到 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt;。&lt;/p&gt;</description></item><item><title>Google去中心化分布式系统论文三件套(Percolator、Spanner、F1)读后感</title><link>//owent.net/2019/1902.html</link><pubDate>Thu, 31 Jan 2019 22:49:50 +0000</pubDate><guid>//owent.net/2019/1902.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;之前看过 &lt;a href="https://read.douban.com/ebook/10179010/"&gt;《大规模分布式存储系统：原理解析与架构实战》&lt;/a&gt; ，这个系统设计还是挺有意思的，里面提及了Google的一整套系统都有论文，而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了，这段时间就陆陆续续的看完了这三篇Paper，可怜我的渣渣英语，所以看得比较慢。&lt;/p&gt;</description></item><item><title>Rust玩具-企业微信机器人通用服务</title><link>//owent.net/2019/1901.html</link><pubDate>Thu, 03 Jan 2019 17:08:50 +0000</pubDate><guid>//owent.net/2019/1901.html</guid><description>&lt;h2 id="新玩具-企业微信机器人"&gt;新玩具-企业微信机器人&lt;/h2&gt;
&lt;p&gt;这个机器人其实蛮久前就做好了，现在才写了点分享出来。 最近企业微信不断地开放了机器人的接口，所以我想想拿来做一些开发工具集成也是挺不错的，顺便也是为了继续熟悉一下 &lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt; 的编程习惯。 那么这次就大量使用 &lt;a href="https://crates.io/crates/futures"&gt;futures&lt;/a&gt; 来实现这个机器人的接口服务，这也是即将到来的无栈协程语法糖 &lt;a href="https://crates.io/crates/futures-await"&gt;await&lt;/a&gt; 的基石。&lt;/p&gt;</description></item><item><title>使用ELK辅助监控开发测试环境服务质量和问题定位</title><link>//owent.net/2018/1812.html</link><pubDate>Sat, 17 Nov 2018 02:00:00 +0000</pubDate><guid>//owent.net/2018/1812.html</guid><description>&lt;h2 id="什么是elk"&gt;什么是ELK？&lt;/h2&gt;
&lt;p&gt;ELK 是 &lt;a href="https://www.elastic.co/cn/products/elasticsearch"&gt;elasticsearch&lt;/a&gt; + &lt;a href="https://www.elastic.co/cn/products/logstash"&gt;logstash&lt;/a&gt; + &lt;a href="https://www.elastic.co/cn/products/kibana"&gt;kibana&lt;/a&gt;的缩写。这一套是现在比较流行的日志全文索引系统了。我之前的项目也有用它来做过日志分析，这次主要是拿来搭建开发测试环境的监控和分析系统，顺带记录一下部署脚本和流程。&lt;/p&gt;
&lt;p&gt;其中 &lt;a href="https://www.elastic.co/cn/products/elasticsearch"&gt;elasticsearch&lt;/a&gt; 是日志索引系统，我按两个master，3个数据和处理节点来部署。 &lt;a href="https://www.elastic.co/cn/products/logstash"&gt;logstash&lt;/a&gt; 和 &lt;a href="https://www.elastic.co/cn/products/kibana"&gt;kibana&lt;/a&gt; 因为是开发测试环境使用，量级不大，所以只部署了一个节点。但是在使用过程中发现 &lt;a href="https://www.elastic.co/cn/products/elasticsearch"&gt;elasticsearch&lt;/a&gt; 在jre的GC的时候还是有较长时间的 &lt;em&gt;&lt;strong&gt;Stop The World&lt;/strong&gt;&lt;/em&gt; 的问题，而且这期间的数据会倍丢弃。所以为了缓解这个状况，又引入了 &lt;a href="https://redis.io/"&gt;redis&lt;/a&gt; 作为消息队列使用。然后使用两组pipeline，一个从 client -&amp;gt; &lt;a href="https://www.elastic.co/cn/products/logstash"&gt;logstash&lt;/a&gt; -&amp;gt; &lt;a href="https://redis.io/"&gt;redis&lt;/a&gt; ，另一个从 &lt;a href="https://redis.io/"&gt;redis&lt;/a&gt; -&amp;gt; &lt;a href="https://www.elastic.co/cn/products/logstash"&gt;logstash&lt;/a&gt; -&amp;gt; &lt;a href="https://www.elastic.co/cn/products/elasticsearch"&gt;elasticsearch&lt;/a&gt; 来传输。这样如果在 &lt;a href="https://www.elastic.co/cn/products/elasticsearch"&gt;elasticsearch&lt;/a&gt; GC的 &lt;em&gt;&lt;strong&gt;Stop The World&lt;/strong&gt;&lt;/em&gt; 结束的时候会把数据补回去。 外面更大型的部署也有用 &lt;a href="https://kafka.apache.org/"&gt;kafka&lt;/a&gt; 或者更进一步优化的 &lt;a href="https://pulsar.apache.org/"&gt;pulsar&lt;/a&gt;。不过我们目前的应用也不太需要 &lt;a href="https://kafka.apache.org/"&gt;kafka&lt;/a&gt; 和 &lt;a href="https://pulsar.apache.org/"&gt;pulsar&lt;/a&gt; 那种数据落地和强一致性，使用 &lt;a href="https://redis.io/"&gt;redis&lt;/a&gt; 也已经够了。&lt;/p&gt;</description></item><item><title>2018年的新通用伪随机数算法(xoshiro / xoroshiro)的C++(head only)实现</title><link>//owent.net/2018/1810.html</link><pubDate>Thu, 18 Oct 2018 13:43:31 +0000</pubDate><guid>//owent.net/2018/1810.html</guid><description>&lt;p&gt;前段时间看到说&lt;a href="https://github.com/lua/lua/blob/f59e6a93c0ad38a27a420e51abf8f13d962446b5/lmathlib.c#L571"&gt;Lua 5.4&lt;/a&gt;用了一种新的通用随机数算法，替换掉本来内部使用的CRT的随机数引擎。我看了一下大致的实现，CPU和空间复杂度任然保持了一个较低的水平，并且循环节和说是随机性都还不错。我们游戏项目中原本对大量随机数场景的随机数算法使用的是基于线性同余的TAUS88，但是使用过程中发现这个算法分布上还是有一些不是很理想，所以就想把这个新的科研成果也用进我们项目中试试看效果。&lt;/p&gt;</description></item><item><title>Webpack+vue+boostrap+ejs构建Web版GM工具</title><link>//owent.net/2018/1811.html</link><pubDate>Tue, 16 Oct 2018 17:10:50 +0000</pubDate><guid>//owent.net/2018/1811.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;Web前端的组件技术刷新真的是日新月异，前段时间看到很多童鞋分享了&lt;a href="https://webpack.js.org/"&gt;webpack&lt;/a&gt;的使用，刚好之前做我们游戏里Web版的GM工具的时候正在想怎么用简单的方式，做模块分离并且又不需要引入重量级的第三方库或组件，也不需要太繁琐的流程（毕竟只是个小工具）。&lt;/p&gt;
&lt;p&gt;我们的Web版GM工具长差不多这个样子，全静态页面。&lt;/p&gt;
&lt;p&gt;&lt;img src="//owent.net/2018/1811-01.png" alt="1811-01.png" loading="lazy" /&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src="//owent.net/2018/1811-02.png" alt="1811-02.png" loading="lazy" /&gt;&lt;/p&gt;
&lt;p&gt;因为分成了好几个模块，然后由于用的是bootstrap的。上面的Tab和下面的内容还有处理逻辑的函数都分了三大块，在不同的位置。在内容持续增加以后，全都写在一个html里太不方便了，而如果走ajax加载，调试和本地编辑都挺麻烦。&lt;/p&gt;</description></item><item><title>Rust的第二次接触-写个小服务器程序</title><link>//owent.net/2018/1809.html</link><pubDate>Wed, 12 Sep 2018 12:29:50 +0000</pubDate><guid>//owent.net/2018/1809.html</guid><description>&lt;h2 id="just-practice"&gt;JUST PRACTICE&lt;/h2&gt;
&lt;p&gt;蛮久前入门了一下 &lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt; 语言。它的设计模型非常地吸引C/C++的开发者。但是学习语言嘛还是要练习一下，之前也用它给我们项目写了个命令行小工具。这回拿来写个小型的服务器程序吧。&lt;/p&gt;</description></item><item><title>理解和适配AEAD加密套件</title><link>//owent.net/2018/1808.html</link><pubDate>Sun, 01 Jul 2018 20:49:50 +0000</pubDate><guid>//owent.net/2018/1808.html</guid><description>&lt;h2 id="什么是aead"&gt;什么是AEAD&lt;/h2&gt;
&lt;p&gt;按照维基百科的说法。AEAD的全称是Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE)。也就是带附加数据的加密和验证算法。&lt;/p&gt;
&lt;p&gt;我们很多涉及IO的系统收发数据的时候一般会加上一些校验码，以便检测IO错误。而对外的socket里，这个校验码还有一个功能是挡掉一些不正常的数据。如果这时候如果我们的数据需要带上加密的话，那就是AE了。然后AEAD就是在AE的基础上，增加一些自定义数据，用于防止猜解。&lt;/p&gt;</description></item><item><title>atsf4g-co的进化：协程框架v2、对象路由系统和一些其他细节优化</title><link>//owent.net/2018/1807.html</link><pubDate>Fri, 22 Jun 2018 23:22:15 +0000</pubDate><guid>//owent.net/2018/1807.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多，一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱，仅当作一个参照和小计吧。&lt;/p&gt;</description></item><item><title>协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比</title><link>//owent.net/2018/1806.html</link><pubDate>Mon, 28 May 2018 20:23:31 +0000</pubDate><guid>//owent.net/2018/1806.html</guid><description>&lt;h1 id="协程系统优化"&gt;协程系统优化&lt;/h1&gt;
&lt;p&gt;&lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt;很早就实现完成了v2版本，现在迁移进&lt;a href="https://github.com/atframework/atsf4g-co/tree/sample_solution"&gt;atsf4g-co/tree/sample_solution&lt;/a&gt;以后也把v2分支正式并入了主干。原来的版本切出到v1分支并且停止维护了。&lt;/p&gt;
&lt;h2 id="libcopp-v2内存布局"&gt;libcopp v2内存布局&lt;/h2&gt;
&lt;p&gt;开发&lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt; v2版本的最大目的是优化allocator的接口和内存碎片。&lt;/p&gt;
&lt;p&gt;原来的allocator虽然是可定制的，但是是内置的。每次创建一个allocator对象，不同allocator之间共享数据只能通过全局数据或者TLS数据。现在则可以传入allocator了。这也是为后续的共享栈池做准备。&lt;/p&gt;</description></item><item><title>可执行文件压缩</title><link>//owent.net/2018/1805.html</link><pubDate>Tue, 24 Apr 2018 10:58:05 +0000</pubDate><guid>//owent.net/2018/1805.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;最近看&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;相关东西的时候看到一篇关于压缩可执行文件的文章。压缩可执行文件对嵌入式开发特别有用，但是延伸一下用来减少我们游戏行业里预编译的工具二进制包大小和Android/iOS的库也是蛮有用的。&lt;/p&gt;
&lt;p&gt;原文见这里： &lt;a href="https://jamesmunns.com/blog/tinyrocket/"&gt;https://jamesmunns.com/blog/tinyrocket/&lt;/a&gt;&lt;/p&gt;
&lt;h1 id="基本流程"&gt;基本流程&lt;/h1&gt;
&lt;ol&gt;
&lt;li&gt;Release编译，移除调试符号文件，开启最小化size优化(-Oz)&lt;/li&gt;
&lt;li&gt;使用LLVM的全量LTO&lt;/li&gt;
&lt;li&gt;使用xargo重新编译标准库(std)和核心库(core)（这个C/C++不容易模仿，而且编译选项十分难搞）&lt;/li&gt;
&lt;li&gt;移除&lt;a href="https://github.com/jemalloc/jemalloc"&gt;jemalloc&lt;/a&gt;（服务器程序还是留着比较好，内置的malloc实现一般碎片比较厉害。虽然C/C++默认也不是&lt;a href="https://github.com/jemalloc/jemalloc"&gt;jemalloc&lt;/a&gt;，很多项目为了新能还是会用它）&lt;/li&gt;
&lt;li&gt;移除panic的详情信息（这个仅适用于&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;）&lt;/li&gt;
&lt;li&gt;strip（由GNU的&lt;a href="https://www.gnu.org/software/binutils/"&gt;binutils&lt;/a&gt;提供），参考命令: &lt;code&gt;strip [二进制]&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://upx.github.io/"&gt;UPX&lt;/a&gt;进一步压缩加壳&lt;/li&gt;
&lt;/ol&gt;
&lt;h1 id="尝试改造优化"&gt;尝试改造优化&lt;/h1&gt;
&lt;p&gt;然后尝试使用上面的流程改造我们的 &lt;strong&gt;gmtools-cli&lt;/strong&gt; 。原先我是直接开LTO+Release编译的，编出的文件大小为4.4MB（4520728字节）。&lt;/p&gt;</description></item><item><title>初识Rust</title><link>//owent.net/2018/1804.html</link><pubDate>Mon, 23 Apr 2018 21:54:50 +0000</pubDate><guid>//owent.net/2018/1804.html</guid><description>&lt;h1 id="前言"&gt;前言&lt;/h1&gt;
&lt;p&gt;虽然我主要使用C++，但是最近也想学点现代化的新语言。初步想的是从&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;和&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;里先选一个。&lt;/p&gt;
&lt;p&gt;这两年&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;在国内很火，最大的特点莫过于语言层面提供了协程支持，能够极大地简化异步逻辑地理解。我之前也接触过一点，还写了个&lt;a href="https://gist.github.com/owent/2286768f2586521600c9fd1700cbf845"&gt;goroutine压力测试&lt;/a&gt;对比我的&lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt;的性能。但是&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;的语法我实在不喜欢，特别是那个不管啥类型声明都是反着来，感觉在复杂的类型下会非常反人类。而且听用过的人说&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;的GC还很不稳定。另外之前有新闻说&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;正在准备2.0，2.0版本即将加入泛型支持，然后导致很多语法不兼容和语法分析得重写。所以我还是懒得踩这个坑了，至少等2.0出来再说。&lt;/p&gt;
&lt;p&gt;&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;是Mozilla搞出来想拿来重写Firefox的。说实话Mozilla和Google还有点差距，导致&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;的发展还比较慢。对比起来就是感觉&lt;a href="https://golang.org/"&gt;golang&lt;/a&gt;很快就提供了一些快速可用的原型给大型项目使用，标准库也足够丰富。而&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;还纠结在底层、语言层面的优化和最求极致。很多组件都还不成熟，编程设计模型也还没完全统一。&lt;/p&gt;
&lt;p&gt;但是接触了一点&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;以后，我发现&lt;a href="https://rust-lang.org/"&gt;Rust&lt;/a&gt;真的是挠到了C++程序员的痒点，语言层面解决了用C++得费很多脑力和用各种奇技淫巧实现并且还不能完全阻止被绕过的质量控制问题，而且保留了C++很多编译期推断得高级特性。并且和C++一样，提供给你能力，但不限定你方法提供 &lt;strong&gt;零成本抽象（zero-cost abstractions）&lt;/strong&gt; 或者说叫 &lt;strong&gt;零开销（zero-overhead）&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>使用restructedtext编写xresloader文档</title><link>//owent.net/2018/1803.html</link><pubDate>Tue, 03 Apr 2018 17:22:42 +0000</pubDate><guid>//owent.net/2018/1803.html</guid><description>&lt;p&gt;离上一次写Blog过了好久啦。这次拖这么长时间主要是因为最近学习了一个新的文本标记语言 &amp;ndash; &lt;a href="https://en.wikipedia.org/wiki/ReStructuredText"&gt;ReStructuredText&lt;/a&gt; 。并且重新整理了&lt;a href="https://github.com/xresloader/"&gt;Excel导表工具-xresloader工具集&lt;/a&gt;的文档，写文档真是好废好废时间啊。&lt;/p&gt;
&lt;p&gt;好多项目用&lt;a href="https://en.wikipedia.org/wiki/ReStructuredText"&gt;ReStructuredText&lt;/a&gt;来写文档来着，比如&lt;a href="https://cmake.org/"&gt;cmake&lt;/a&gt;，再比如&lt;a href="https://www.python.org/"&gt;python&lt;/a&gt;。然后现在有比较容易上手的&lt;a href="https://readthedocs.com/"&gt;readthedocs&lt;/a&gt;来托管文档，和&lt;a href="https://github.com/"&gt;github&lt;/a&gt;的集成也还不错。所以我打算把一些项目的文档也迁移上去。毕竟 &lt;strong&gt;README.md&lt;/strong&gt; 还是弱了些。&lt;/p&gt;
&lt;p&gt;其实&lt;a href="https://en.wikipedia.org/wiki/ReStructuredText"&gt;ReStructuredText&lt;/a&gt;也支持 &lt;strong&gt;Markdown&lt;/strong&gt; 。但是使用 &lt;strong&gt;Markdown&lt;/strong&gt; 写文档还是略麻烦，特别是涉及跨文档引用和多行表格的时候，而且 &lt;strong&gt;Markdown&lt;/strong&gt; 各个平台的组件和扩展还都不一样，没有统一标准。在这些方面&lt;a href="https://en.wikipedia.org/wiki/ReStructuredText"&gt;ReStructuredText&lt;/a&gt;就强大多了。不过这也是有代价的，那就是&lt;a href="https://en.wikipedia.org/wiki/ReStructuredText"&gt;ReStructuredText&lt;/a&gt;的语法规则比 &lt;strong&gt;Markdown&lt;/strong&gt; 复杂得多。&lt;/p&gt;</description></item><item><title>atframework的etcd模块化重构</title><link>//owent.net/2018/1802.html</link><pubDate>Tue, 20 Feb 2018 22:43:00 +0000</pubDate><guid>//owent.net/2018/1802.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;最近在抽时间整理之气的游戏服务器框架和解决方案里&lt;a href="https://github.com/atframework/atsf4g-co"&gt;atsf4g-co&lt;/a&gt;，现在的架构是使用&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;的是&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atproxy"&gt;atproxy&lt;/a&gt;。简单得说就是服务集群是分组的，每个分组有分组代理服务&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atproxy"&gt;atproxy&lt;/a&gt;做组间通信。然后&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atproxy"&gt;atproxy&lt;/a&gt;之间使用&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;来做分组服务的服务发现和保活，并且以此来实现平行扩容。&lt;/p&gt;
&lt;p&gt;之前做服务间通信组件&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;的时候也提到了有一个暂时没实现的功能，就是全局路由表的自动通知。但是这个功能的实现主要也是用于后面不同种服务间感知到哪些节点是可用的，哪些是不可用的。而且我的简单实现必然是走心跳的模式，因为心跳的形式肯定不能把心跳设置得太短，同时也要考虑网络异常抖动和断线重连和丢包，所以肯定不是丢一个心跳包就认为丢失。所以故障或者扩缩容期间的感知时间就会比较长一些。另外就是因为可能有网络孤岛问题，所以可能短期内数据不一致（当然肯定会保证最终一致性）。&lt;/p&gt;
&lt;p&gt;再加上由于&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;是支持多级父子节点关系的，所以变化通知和同步包就要考虑自己与父节点、兄弟节点、自己与子节点的不同关系并作不同的同步流向，会比较复杂。比如：子节点下线，既要通知父节点，又要通知兄弟节点。那么这时候给兄弟节点通知就有两个通路，一个是经由父节点中转，另一种是直接发。当然这时候并不一定和兄弟节点有直接通路。所以可能兄弟节点会收到两次通知，一次来自兄弟节点，另一次来自公共父节点。然后又会有其他问题，就是万一又收到一条冲突的消息，来自父节点和来自兄弟节点的顺序是没有保证的，这里又得加入版本机制。总的来说，细节会比较复杂，具体在实现&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;的这个功能的时候在谈吧。&lt;/p&gt;
&lt;p&gt;上面说的&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;的功能暂时没实现的最重要原因是&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;可以比较完美的解决上面的延迟问题和不一致问题。缺点就是请求的消耗会高于使用&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;的通信机制。不过这玩意本身不是高频操作，而且故障和容灾本身不是一个频发的事情所以关系不大。而之前&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;的接入是直接写死在&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atproxy"&gt;atproxy&lt;/a&gt;里的，那么这次重构的目的主要就是能够抽象出模块化的工具，以便后面不同的服务可以根据需要取用。&lt;/p&gt;
&lt;h2 id="统一管理驱动管理器和模块化"&gt;统一管理驱动管理器和模块化&lt;/h2&gt;
&lt;p&gt;按现在的功能划分，&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;的接入总共被分为3个模块，etcd_cluster、etcd_keepalive和etcd_watcher以及一个通用工具etcd_packer。etcd_packer用于对&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;的一些通用的打解包操作。&lt;/p&gt;
&lt;p&gt;&lt;img src="//owent.net/2018/1802-01.png" alt="模块关系图" loading="lazy" /&gt;&lt;/p&gt;
&lt;h3 id="etcd_cluster"&gt;etcd_cluster&lt;/h3&gt;
&lt;p&gt;&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt; v3版本内部的通信已经使用了grpc。本来我是想等他的grpc接口进入官方文档并且提供出的grpc的proto再接入的，可是它一直没有整理出直接grpc的proto文件列表。另外我看了一下它的proto文件里用到了一些&lt;a href="https://github.com/gogo/protobuf"&gt;gogoprotobuf&lt;/a&gt;的扩展，其他语言不一定可以无缝接入。考虑到etcd使用了&lt;a href="https://github.com/grpc-ecosystem/grpc-gateway"&gt;grpc-gateway&lt;/a&gt;提供HTTP+JSON的网关层，所以我还是基于他的HTTP接入层来做。因为这里身频次不高，也没有那么在意性能。而且一组&lt;a href="https://coreos.com/etcd"&gt;etcd&lt;/a&gt;服务的QPS也就在十万的级别，只要管理好连接，不要老新建立和关闭连接，HTTP的性能还是够的。&lt;/p&gt;</description></item><item><title>C++的backtrace</title><link>//owent.net/2018/1801.html</link><pubDate>Mon, 08 Jan 2018 17:55:00 +0000</pubDate><guid>//owent.net/2018/1801.html</guid><description>&lt;h1 id="开始之前"&gt;开始之前&lt;/h1&gt;
&lt;p&gt;很多语言的log模块都有一个功能，就是在打log的时候能够追溯调用栈，有的时候对查bug能有点帮助。之前我也想过给我们的log模块加上C++的backtrace的功能，迟迟一直没有做主要是两个原因：一是C++的backtrace在各个平台和编译器上都不太一样，比较冗杂；二是C/C++在编译优化之后，调用行之类的信息和甚至一些函数可能就被优化没了。所以能提供的信息就相当有限。前两天刚好有朋友问有没有提供这个，所以就花了点时间整理了下适配方案。&lt;/p&gt;</description></item><item><title>ECDH椭圆双曲线（比DH快10倍的密钥交换）算法简介和封装</title><link>//owent.net/2017/1472.html</link><pubDate>Fri, 10 Nov 2017 13:30:00 +0000</pubDate><guid>//owent.net/2017/1472.html</guid><description>&lt;p&gt;前面有几篇blog就提到我有计划支持使用ECDH密钥交换。近期也是抽空把以前的DH密钥交换跨平台适配从&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atgateway"&gt;atgateway&lt;/a&gt;抽离出来，而后接入了&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman"&gt;ECDH&lt;/a&gt;流程。&lt;/p&gt;
&lt;h2 id="背景"&gt;背景&lt;/h2&gt;
&lt;p&gt;对&lt;a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange"&gt;DH&lt;/a&gt;和&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman"&gt;ECDH&lt;/a&gt;算法的具体原理这里不做具体介绍了，可以点击链接看。&lt;a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange"&gt;DH&lt;/a&gt;和&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman"&gt;ECDH&lt;/a&gt;的主要的作用就是在通信双方发送一些公有参数，保留私有参数，而后通过一系列计算双方都能够得到一个一致的结果。而这个运算的逆运算复杂度过高，在有限时间内不可解（至少量子计算机问世以前不可解），以保证密钥安全性。除了维基百科外，我还看到篇文章图画的很好看的：http://andrea.corbellini.name/2015/05/30/elliptic-curve-cryptography-ecdh-and-ecdsa/ 。而&lt;a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange"&gt;DH&lt;/a&gt;和&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman"&gt;ECDH&lt;/a&gt;得区别简单来说就是，前者使用了一个大素数和两个随机数，而后者使用了&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_cryptography"&gt;ECC&lt;/a&gt;算法和两个随机点。&lt;/p&gt;
&lt;p&gt;实际应用中，有些加密算法的密钥碰撞计算难度反而比破解&lt;a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange"&gt;DH&lt;/a&gt;和&lt;a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman"&gt;ECDH&lt;/a&gt;要容易（比如&lt;a href="https://github.com/atframework/atsf4g-co/tree/master/atframework/service/atgateway"&gt;atgateway&lt;/a&gt;支持的&lt;a href="https://en.wikipedia.org/wiki/XXTEA"&gt;XXTEA&lt;/a&gt;算法，这个算法很简单所以也非常高效）。所以有些工程实践中会每隔一段时间再走一次密钥交换流程来更换密钥。&lt;/p&gt;</description></item><item><title>protobuf-net的动态Message实现</title><link>//owent.net/2017/1471.html</link><pubDate>Tue, 31 Oct 2017 17:57:00 +0000</pubDate><guid>//owent.net/2017/1471.html</guid><description>&lt;p&gt;这本来是个早就可以写的分享。因为代码几周前就迁移并准备好了。而且这也是之前项目的工具，因为可以抽离出来通用化所以单独整理出来。&lt;/p&gt;
&lt;p&gt;这个项目起源于我们之前哪个项目，客户端想要在Unity的C#里动态加载配置，而&lt;a href="https://github.com/mgravell/protobuf-net"&gt;protobuf-net&lt;/a&gt;一方面大量使用反射而性能不太行，另一方面使用的时候得生成C#代码才行。客户端原来的做法是把消息扁平化了，使用&lt;a href="https://github.com/mgravell/protobuf-net"&gt;protobuf-net&lt;/a&gt;得底层读写接口直接操作基本数据类型。这就失去了结构化带来的一系列好处。再加上后来我引入了跨平台导表工具，使用结构化得数据会非常方便，而手动把这个数据打散到客户端读取接口显然很浪费人力而且容易出错。所以我就干脆也使用&lt;a href="https://github.com/mgravell/protobuf-net"&gt;protobuf-net&lt;/a&gt;的底层读写接口做了现在的&lt;a href="https://github.com/xresloader/DynamicMessage-net"&gt;DynamicMessage&lt;/a&gt;的支持，API设计是结合&lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt;和protobuf官方的API流程的。&lt;/p&gt;</description></item><item><title>pbc的proto3接入</title><link>//owent.net/2017/1470.html</link><pubDate>Sat, 16 Sep 2017 17:57:00 +0000</pubDate><guid>//owent.net/2017/1470.html</guid><description>&lt;p&gt;&lt;a href="https://github.com/google/protobuf"&gt;Protobuf&lt;/a&gt; 的 proto3发布也有挺长一段时间了。现在很多新项目慢慢转变用proto3来开发。这篇文章主要记录一下我在给&lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt;写对proto3支持时的一些信息，也许对其他童鞋也有点助益。抛砖引玉一下。&lt;/p&gt;
&lt;h2 id="简介"&gt;简介&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt;是&lt;a href="https://github.com/cloudwu"&gt;云风&lt;/a&gt;开发的一个纯C的读写&lt;a href="https://github.com/google/protobuf"&gt;protobuf&lt;/a&gt;的很小巧的库，配合上它提供的lua-5.1和lua-5.3的binding可以很容易地在lua里完成对pb文件的注册和打解包。应该很多人都知道这个组件。&lt;/p&gt;
&lt;p&gt;但是后来&lt;a href="https://github.com/cloudwu"&gt;云风&lt;/a&gt;自己又发明了个&lt;a href="https://github.com/cloudwu/sproto"&gt;sproto&lt;/a&gt;，然后主推在他的&lt;a href="https://github.com/cloudwu/skynet"&gt;skynet&lt;/a&gt;框架中使用&lt;a href="https://github.com/cloudwu/sproto"&gt;sproto&lt;/a&gt;，于是&lt;a href="https://github.com/cloudwu/pbc"&gt;pbc&lt;/a&gt;就不再有功能维护了。&lt;/p&gt;
&lt;p&gt;我们之前的也尝试直接使用了proto3，也是因为在迁移期，所以并没有使用全部的特性。但是仍然有一些向前不兼容的细节需要处理一下，所以有了这个改造&lt;/p&gt;</description></item><item><title>atgateway内置协议流程优化-加密、算法协商和ECDH</title><link>//owent.net/2017/1469.html</link><pubDate>Fri, 08 Sep 2017 18:37:00 +0000</pubDate><guid>//owent.net/2017/1469.html</guid><description>&lt;p&gt;之前就有计划优化游戏服务器框架网关层的内部协议了，这次泰国旅游回来，新公司入职前，正海有空来做这件事。&lt;/p&gt;
&lt;h2 id="加密协商"&gt;加密协商&lt;/h2&gt;
&lt;p&gt;以前提到过，最初决定重构这个流程是因为我觉得之前的方法，如果以后要扩展新的算法的话非常的麻烦。而后我看了一下shadowsocksr对多种加解密算法的实现方法，觉得还不错。就打算用类似的方法重写一下。当然也是因为写第一版的时候没考虑太多关于加解密方面的细节，还是优先实现出工程上可用的东西。这次就先稍微深入看了下像&lt;a href="https://www.openssl.org/"&gt;openssl&lt;/a&gt;和&lt;a href="https://tls.mbed.org/"&gt;mbedtls&lt;/a&gt;的一些实现，特别是下面会提到的cipher的实现。并以这个为基础来实现以后可能的增加加密算法的扩展。&lt;/p&gt;</description></item><item><title>整理一波软件源镜像同步工具+DevOps工具</title><link>//owent.net/2017/1468.html</link><pubDate>Thu, 17 Aug 2017 12:33:44 +0000</pubDate><guid>//owent.net/2017/1468.html</guid><description>&lt;p&gt;上个月，同学的公司，格奕，突然间跪了。这个月基本属于休息+四处溜达。同时空闲的时候也想整理下之前做得一些之前的做得一些小工具们。在不泄密的情况下开源出来吧（其实也就是想找github存放一下而已，也没什么特别NB的东西）。&lt;/p&gt;</description></item><item><title>Blog切换到Hugo</title><link>//owent.net/2017/1467.html</link><pubDate>Mon, 17 Jul 2017 12:33:44 +0000</pubDate><guid>//owent.net/2017/1467.html</guid><description>&lt;p&gt;其实很早就想把Blog迁移到静态化的博客系统了。不过一直没花时间来搞，当然主要原因还是懒。&lt;/p&gt;
&lt;p&gt;这次下决心搞主要是因为，之前VPS迁移到Vultr，然后它的主机默认是没有交换区的。后来老是收到网站崩溃告警，每次去看都是MariaDB挂掉了，然后查了一下是内存不足。
然后，调整了几次参数，发现都不能解决问题。我这么个小站搞个高配机器显然是浪费。这种小网站都能耗尽1GB的内存我也是醉了。所以后来就干脆迁移到静态博客系统算了。&lt;/p&gt;</description></item><item><title>libcopp的线程安全、栈池和merge boost.context 1.64.0</title><link>//owent.net/2017/1446.html</link><pubDate>Fri, 12 May 2017 19:45:17 +0000</pubDate><guid>//owent.net/2017/1446.html</guid><description>&lt;!-- toc --&gt;
&lt;h2 id="线程安全"&gt;线程安全&lt;/h2&gt;
&lt;p&gt;前段时间看到了一个完成读比较高的协程库-&lt;a href="https://github.com/yyzybb537/libgo"&gt;libgo&lt;/a&gt;，里面提供了线程安全的协程实现，并且也是使用锁。本来我并没有给&lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt;里的功能加锁的打算，因为上层dispatcher还是比较容易做到安全分发的，所以原来并不保证线程安全。而且线程安全这种问题单元测试比较难写，可能还得碰点运气。但是思来想去，还是为线程安全做点什么吧。反正也不是很复杂。&lt;/p&gt;
&lt;p&gt;由于我并没有给utils加互斥锁的跨平台适配，所以先就直接用了自旋锁，来锁住需要考虑线程安全的地方。其实需要加锁的地方并不多，无非是管理器的增删查和task的next函数需要加锁。这些逻辑都很短，功能也很简单，并不会占用太多时间，所以自旋锁的问题也不大。而且以后真发现有问题，换掉也不是什么难事儿。&lt;/p&gt;</description></item><item><title>GCC 7和LLVM+Clang+libc++abi 4.0的构建脚本</title><link>//owent.net/2017/1431.html</link><pubDate>Tue, 09 May 2017 11:17:55 +0000</pubDate><guid>//owent.net/2017/1431.html</guid><description>&lt;p&gt;之前的版本发完，有空来更新一下之前的gcc和llvm+clang工具链的编译脚本了。其实GCC 7是才release没多久但是llvm 4.0发布其实有一段时间了。&lt;/p&gt;</description></item><item><title>2016年总结</title><link>//owent.net/2017/1334.html</link><pubDate>Fri, 03 Feb 2017 19:08:44 +0000</pubDate><guid>//owent.net/2017/1334.html</guid><description>&lt;p&gt;又好久没写blog啦。诶最近好懒啊。正好过年在家里有点空，写完我那些lib的patch之后还有一点时间写一下2016年的总结吧。&lt;/p&gt;
&lt;p&gt;之前两年的总结有点流水账，我还是写得随意一点好了，也没必要凑字数。&lt;/p&gt;</description></item><item><title>接入letsencrypt+全面启用HTTP/2</title><link>//owent.net/2016/1253.html</link><pubDate>Sat, 07 May 2016 15:10:43 +0000</pubDate><guid>//owent.net/2016/1253.html</guid><description>&lt;p&gt;之前我的域名只有owent.net和www.owent.net买了SSL证书，现在有&lt;a href="https://letsencrypt.org/"&gt;letsencrypt&lt;/a&gt;可以拿到免费的SSL签证，就稍微花了点时间把我的域名的其他部分接入了&lt;a href="https://letsencrypt.org/"&gt;letsencrypt&lt;/a&gt;签证系统。另外根据其他人的一些配置建议，提高了HTTPS的安全性配置和性能配置（主要是缓存）。另外原本我的blog就已经启用了spdy，然而现在新版本的&lt;a href="http://nginx.org/"&gt;nginx&lt;/a&gt;（&lt;a href="http://nginx.org/en/CHANGES-1.10"&gt;1.10&lt;/a&gt;）已经release，原先的spdy模块被取消，新增了http/2模块。但是直接换nginx掉包是不行滴（后面有说原因），所以顺带自己处理了一下HTTP/2和nginx新版本的问题。&lt;/p&gt;
&lt;p&gt;并且也对公司里的域名和webserver也这么搞了一下。全面启用HTTPS。&lt;/p&gt;</description></item><item><title>博客文章和文档迁移到gitbook</title><link>//owent.net/2016/1209.html</link><pubDate>Fri, 15 Jan 2016 21:42:11 +0000</pubDate><guid>//owent.net/2016/1209.html</guid><description>&lt;p&gt;使用_Markdown_写blog已经很久了，近期接触并且看了下流传已久的&lt;a href="gitbook.com"&gt;gitbook&lt;/a&gt;平台，感觉做得确实不错。、&lt;/p&gt;
&lt;p&gt;之前写blog的时候一直用得是&lt;a href="stackedit.io"&gt;stackedit&lt;/a&gt;，是因为&lt;a href="stackedit.io"&gt;stackedit&lt;/a&gt;的对_Markdown_做了很多扩展，功能很强大，有自动目录、流程图、时序图等等，然后可以浏览器直接开很方便。但实际上这些功能写出的东西虽然不错，但是放到比如&lt;a href="github.com"&gt;github&lt;/a&gt;上的时候，&lt;a href="github.com"&gt;github&lt;/a&gt;不支持。目前大多数平台对_Mardown_的扩展都只是到了和&lt;a href="github.com"&gt;github&lt;/a&gt;差不多的地步，没有到&lt;a href="stackedit.io"&gt;stackedit&lt;/a&gt;的程度。这也导致同样写得东西，复制到&lt;a href="github.com"&gt;github&lt;/a&gt;或者其他的平台的时候还得过一遍样式，比较麻烦。而且这些扩展的功能也用得不太多。另外&lt;a href="stackedit.io"&gt;stackedit&lt;/a&gt;时不时被墙然后访问很不稳定也是挺麻烦的一件事儿。&lt;/p&gt;
&lt;p&gt;再来说这个&lt;a href="gitbook.com"&gt;gitbook&lt;/a&gt;，看中他是觉得它做了一个可持续集成的功能。就是&lt;a href="github.com"&gt;github&lt;/a&gt; _push_完以后可以通知&lt;a href="gitbook.com"&gt;gitbook&lt;/a&gt;然后让&lt;a href="gitbook.com"&gt;gitbook&lt;/a&gt;自动构建文档内容。这点和比如&lt;a href="https://jenkins-ci.org/"&gt;jenkins&lt;/a&gt;和&lt;a href="https://travis-ci.org/"&gt;travis&lt;/a&gt;等等的CI系统很像。然后支持构建成pdf、epub（开源电子书格式）、mobi（kindle电子书格式）和在线书籍。然后版式也挺漂亮，还支持模板，引用等等，感觉确实蛮适合出版发行的。虽然目前为止_Markdown_的功能丰富程度比起Latex还差不少，但是上手难度也比Latex低不少。还是非常有潜力的，而且&lt;a href="gitbook.com"&gt;gitbook&lt;/a&gt;支持用javascript写得插件，以后变数也可以很多。&lt;/p&gt;</description></item><item><title>近期活动比较零散</title><link>//owent.net/2015/1203.html</link><pubDate>Mon, 28 Dec 2015 23:51:49 +0000</pubDate><guid>//owent.net/2015/1203.html</guid><description>&lt;p&gt;近期的活动比较零散，主要的业余精力都放在了&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;上了。但是这个一时半会也写不完，所以能整理出来的东西不多。就说下最近跟进的开源代码吧。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;首先是&lt;/strong&gt;，跨平台协程框架 &lt;a href="https://github.com/owent/libcopp"&gt;libcopp&lt;/a&gt; 跟进merge了boost 1.60 的context组件，这部分改动不多。仅仅是例行合并。&lt;/p&gt;</description></item><item><title>关于BUS通信系统的一些思考（三）</title><link>//owent.net/2015/1201.html</link><pubDate>Sun, 08 Nov 2015 17:17:05 +0000</pubDate><guid>//owent.net/2015/1201.html</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;a href="//www.owent.net/2014/1099.html"&gt;接上文关于bus通信系统的一些思考（二）&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;之前的文章内容应该要有修订，但是并没有更新到blog里，而是直接写在了&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;的文档里&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="目录"&gt;目录&lt;/h2&gt;
&lt;!-- toc --&gt;
&lt;h2 id="前言"&gt;前言&lt;/h2&gt;
&lt;p&gt;好久没写总结啦，最近一段时间比较忙，抽出的空闲时间都在不断完善之前提到的一个进程间通信lib的想法和实现（&lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;）。&lt;/p&gt;</description></item><item><title>关于BUS通信系统的一些思考（二）</title><link>//owent.net/2014/1099.html</link><pubDate>Tue, 05 Aug 2014 14:08:20 +0000</pubDate><guid>//owent.net/2014/1099.html</guid><description>&lt;blockquote&gt;
&lt;p&gt;接上文&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h2 id="目录"&gt;目录&lt;/h2&gt;
&lt;!-- toc --&gt;
&lt;h2 id="bus系统的设计思路"&gt;BUS系统的设计思路&lt;/h2&gt;
&lt;p&gt;虽然我很不愿意再设计一套BUS系统，但是现有的一些确实都没有特别符合我的口味的。所以还是尝试设计一个出来。&lt;/p&gt;
&lt;h3 id="结构设计"&gt;结构设计&lt;/h3&gt;
&lt;p&gt;简单来说，我希望BUS系统可以简单、高效、稳定。&lt;/p&gt;</description></item><item><title>关于BUS通信系统的一些思考（一）</title><link>//owent.net/2014/1090.html</link><pubDate>Fri, 01 Aug 2014 14:21:53 +0000</pubDate><guid>//owent.net/2014/1090.html</guid><description>&lt;h2 id="目录"&gt;目录&lt;/h2&gt;
&lt;!-- toc --&gt;
&lt;h2 id="概述"&gt;概述&lt;/h2&gt;
&lt;p&gt;如何保证一个进程或线程能安全稳定地把一段消息发送到另一个进程和线程，甚至是另一台机器的进程或线程，再或是要通过代理转发到另一个进程或线程，一直是一个比较麻烦的问题。&lt;/p&gt;</description></item><item><title>再议 C++ 11 Lambda表达式</title><link>//owent.net/2014/1060.html</link><pubDate>Tue, 03 Jun 2014 20:55:44 +0000</pubDate><guid>//owent.net/2014/1060.html</guid><description>&lt;h2 id="目录"&gt;目录&lt;/h2&gt;
&lt;!-- toc --&gt;
&lt;h2 id="c-的lambda表达式"&gt;C++ 的Lambda表达式&lt;/h2&gt;
&lt;p&gt;C++ 11 标准发布，各大编译器都开始支持里面的各种新特性，其中一项比较有意思的就是lambda表达式。&lt;/p&gt;
&lt;h2 id="语法规则"&gt;语法规则&lt;/h2&gt;
&lt;p&gt;C++ 11 Lambda表达式的四种声明方式&lt;/p&gt;</description></item><item><title>C++11动态模板参数和type_traits</title><link>//owent.net/2014/971.html</link><pubDate>Mon, 27 Jan 2014 16:27:46 +0000</pubDate><guid>//owent.net/2014/971.html</guid><description>&lt;p&gt;C++11标准里有动态模板参数已经是众所周知的事儿了。但是当时还有个主流编译器还不支持。
但是现在，主要的编译器。VC(Windows),GCC(Windows,Linux),Clang(Mac,IOS)都已经支持了。所以就可以准备用于生产环境了。
type_traits没啥好说的。主要是一些静态检测。主要还是要看动态模板参数和他们两的结合使用上。
动态模版参数标准文档见:
&lt;a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf"&gt;http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf&lt;/a&gt;
和
&lt;a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf"&gt;http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf&lt;/a&gt;
虽然贴出来了。估计是没人看得。所以就直接说重点。&lt;/p&gt;</description></item><item><title>C++又一坑:动态链接库中的全局变量</title><link>//owent.net/2014/962.html</link><pubDate>Sat, 04 Jan 2014 17:30:32 +0000</pubDate><guid>//owent.net/2014/962.html</guid><description>&lt;p&gt;前几天我们项目的日志系统出现了一点问题，但是一直没有时间去深究。
昨天在同事的帮助下，无意中猜了一种可能性，结果还真被我猜中了，于是今天就特别研究了一下，记录下来。&lt;/p&gt;</description></item></channel></rss>