libatbus 的大幅优化
最近零碎的事太多了,拖了好久没写blog。一些小的碎片话的东西也不值得写,另一方面是这次大幅优化了 atframework 的一些流程细节,特别是针对我们这两年来业务的需求,对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。
最近零碎的事太多了,拖了好久没写blog。一些小的碎片话的东西也不值得写,另一方面是这次大幅优化了 atframework 的一些流程细节,特别是针对我们这两年来业务的需求,对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。
之前耳闻 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 。
年初的时候再知乎上看到有人分享 PALM树 树的文章,看简介是专为多核并发而设计的树形结构。比较好奇所以抽时间来看了看它的设计原理和是如合做到高并发的。
之前写了 《协程框架(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 吧。
Github Action 上线有一阵子了,大概两周前我的所有账号也是都陆陆续续开发了beta测试的权限。然后就来研究了下这个新的 CI 系统是怎么回事。看介绍,和之前碰到的一些CI系统不太一样的地方是,Github是做了一个商店的功能。这样大家就可以自己定义自己的Action,然后方便别人复用。同时也可以统一自己的或者组织在构建过程中的一些公共流程。
最近有几个其他项目组的童鞋给我之前的 转表工具链-xresloader 提了几个需求。然后我也根据我们近期一些需求点对转表工具链一起给这套工具做了点功能增强和细节上的一些改进。 这篇blog差不多是这些东西的 CHANGELOG了吧。
前段时间我尝试给 atframework 的 libatapp 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 libatapp 所依赖的通信组件 libatbus 里内部协议是msgpack , 而 msgpack 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波 libatbus 的功能,增加一些跨版本向前向后兼容功能,和一些简单的验证功能(仅仅是为了防止误操作导致的问题)。具体的变更等我弄完了再发一篇。
最近抽空继续对 libcopp 进行了更新和小幅优化。 首先的Merge了 boost.context 1.70.0 。这次boost.context的更新似乎和它写进 CHANGELOG 里的并不完全一致,匹配的只看到 macho 架构的脏数据操作。 不过另外它增加了新的平台支持 mips64,我目前还是简单导入了,但是平台检测工具还没有写,如果要使用是可以通过编译参数切过去的,不过我感觉没人会这么用吧?我自己用都得看一下之前怎么写的。
我们项目组最近在学习UE,然后就涉及导表这个东东。之前我已经做过一个功能比较全面并且跨平台的Excel导出protobuf、msgpack、xml、lua、json、javascript等的工具 xresloader 。并且做了方便服务器集成的CLI工具和方便策划、前端用的GUI工具。那么这次很自然地就让它能够导出UE所支持的内容就行了。然后额外增加了基于protobuf插件形式的多key索引和自动生成一些支持蓝图和非蓝图的常用接口代码。
年前被同事安利了这个分布式最终一致性的存储系统 Anna 。初略看了一眼Paper,似乎很是牛X。说是支持任意规模的扩展,并且性能不低于 pedis。于是抽空来看看并了解下这套系统的设计特点和这种夸张的单机性能和扩展性的来源。
系统名词 | 扩容设计 | 内存模型 | 针对单个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 |
一致性说明:
最近的新闻里 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
编译和运行。
过年啦,最近在看一些非技术性的东西,Anna 的Paper也还没看完。随手优化了下Blog的主题,修复和优化了一些小问题。然后来Merge了一下 boost.context 最新 1.69.0 版本的asm部分到 libcopp。
之前看过 《大规模分布式存储系统:原理解析与架构实战》 ,这个系统设计还是挺有意思的,里面提及了Google的一整套系统都有论文,而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了,这段时间就陆陆续续的看完了这三篇Paper,可怜我的渣渣英语,所以看得比较慢。
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 也已经够了。
前段时间看到说Lua 5.4用了一种新的通用随机数算法,替换掉本来内部使用的CRT的随机数引擎。我看了一下大致的实现,CPU和空间复杂度任然保持了一个较低的水平,并且循环节和说是随机性都还不错。我们游戏项目中原本对大量随机数场景的随机数算法使用的是基于线性同余的TAUS88,但是使用过程中发现这个算法分布上还是有一些不是很理想,所以就想把这个新的科研成果也用进我们项目中试试看效果。
Web前端的组件技术刷新真的是日新月异,前段时间看到很多童鞋分享了webpack的使用,刚好之前做我们游戏里Web版的GM工具的时候正在想怎么用简单的方式,做模块分离并且又不需要引入重量级的第三方库或组件,也不需要太繁琐的流程(毕竟只是个小工具)。
我们的Web版GM工具长差不多这个样子,全静态页面。
因为分成了好几个模块,然后由于用的是bootstrap的。上面的Tab和下面的内容还有处理逻辑的函数都分了三大块,在不同的位置。在内容持续增加以后,全都写在一个html里太不方便了,而如果走ajax加载,调试和本地编辑都挺麻烦。
蛮久前入门了一下 Rust 语言。它的设计模型非常地吸引C/C++的开发者。但是学习语言嘛还是要练习一下,之前也用它给我们项目写了个命令行小工具。这回拿来写个小型的服务器程序吧。