我们目前的游戏第一次测试的时候笔记送匆忙，导致上线之后频繁更新。 比如BOSS战由于大区的人数和预期不一样导致的难度调整，或者是任务链或者数值调整，再加上一些BUG。

atbus是我按之前的思路写得服务器消息通信中间件，目标是简化服务器通信的流程，能够自动选择最优路线，自动的断线重连和通信通道维护。能够跨平台并且高效。

这个问题起源于以前给客户端写的一个log模块，然后里面为了线程安全且多线程下不互相写乱，并且因为这些系统基本都用比较高版本的编译器，都支持C++11了，所以就用了C++11的TLS功能。

近期跟了一下pbc的lua-binding的一个老BUG，起源是我们客户端报了一个奇怪的问题，我们游戏里的某些功能的optional字段，服务器并没有下发数据，但是客户端竟然能读到。

前言

之前写了个C++的协程框架libcopp，底层使用的是boost.context实现，然后剥离了对boost的依赖。然而这样意味着我必须时常跟进boost.context的更新。

顺带提一下这个协程库已经在我们线上服务器版本中使用了。

从最初的boost版本（我忘了从哪个版本开始了）一直到1.60版本，boost.context的变化都不大，都只是补全一些新的架构和体系结构，还有就是修复一些小细节的BUG，再就是增加了对valgrind的支持（之前写过一个Merge记录提到过）。新增的功能也只有execution_context(现在叫execution_context_v1)，这个东西我的libcopp里其实包含了这个功能，并且本身做得比它要功能丰富，所以没有接入的必要。另外在1.60版本的时候尝试使用Windows里的fiber（当然默认是关闭的），在1.61版本里被移除了。这些细节都不是特别重要，主要还是1.61版本的变化。

之前我的域名只有owent.net和www.owent.net买了SSL证书，现在有letsencrypt可以拿到免费的SSL签证，就稍微花了点时间把我的域名的其他部分接入了letsencrypt签证系统。另外根据其他人的一些配置建议，提高了HTTPS的安全性配置和性能配置（主要是缓存）。另外原本我的blog就已经启用了spdy，然而现在新版本的nginx（1.10）已经release，原先的spdy模块被取消，新增了http/2模块。但是直接换nginx掉包是不行滴（后面有说原因），所以顺带自己处理了一下HTTP/2和nginx新版本的问题。

并且也对公司里的域名和webserver也这么搞了一下。全面启用HTTPS。

前言

最近在分布式系统一致性方面，Raft算法比较火啊。所以就抽时间看了下这个算法。

之前已经有Paxos算法，用于解决分布式系统最终一致性问题，而且已经有了zookeeper这个成熟的开源实现。那么这个Raft算法有啥用呢？按照Raft官网的说法，这个算法的错误容忍和性能和Paxos算法类似，但是拥有更加简单易懂的设计。

看过Paxos算法的童鞋们都知道，这货复杂地和屎一样，为了实现去中心化而考虑了各种复杂的边界条件和时序下的可靠性。而Raft算法则根据实际应用中的需要，简化了设计模型，不采用去中心化设计，而是自动选举中心节点，并且在各种情况和时序下可以保证能够正确的选举出中心节点并保证数据的一致性。而且也正是由于能够选举出唯一的主节点（Leader）使得整个通信流程非常地简单，并且易于理解和维护。

那么它是如何做到这些的呢？

基本算法设计

Raft的基本设计可以参照官网介绍 https://raft.github.io/

官方网站上的图例可以点击节点，然后模拟节点crash或者超时或者收到请求时的通信流程。其实也是一个javascript的简单实现，有利于我们理解Raft算法的流程。

libatbus

经过茫茫长时间的编写+过年在家无聊补充和修正单元测试，再加上这两天的整理，终于把以前的这个关于服务器通信中间件的基本功能和相应的单元测试完成啦。还是可以热烈庆祝一下的。

使用_Markdown_写blog已经很久了，近期接触并且看了下流传已久的gitbook平台，感觉做得确实不错。、

之前写blog的时候一直用得是stackedit，是因为stackedit的对_Markdown_做了很多扩展，功能很强大，有自动目录、流程图、时序图等等，然后可以浏览器直接开很方便。但实际上这些功能写出的东西虽然不错，但是放到比如github上的时候，github不支持。目前大多数平台对_Mardown_的扩展都只是到了和github差不多的地步，没有到stackedit的程度。这也导致同样写得东西，复制到github或者其他的平台的时候还得过一遍样式，比较麻烦。而且这些扩展的功能也用得不太多。另外stackedit时不时被墙然后访问很不稳定也是挺麻烦的一件事儿。

再来说这个gitbook，看中他是觉得它做了一个可持续集成的功能。就是github _push_完以后可以通知gitbook然后让gitbook自动构建文档内容。这点和比如jenkins和travis等等的CI系统很像。然后支持构建成pdf、epub（开源电子书格式）、mobi（kindle电子书格式）和在线书籍。然后版式也挺漂亮，还支持模板，引用等等，感觉确实蛮适合出版发行的。虽然目前为止_Markdown_的功能丰富程度比起Latex还差不少，但是上手难度也比Latex低不少。还是非常有潜力的，而且gitbook支持用javascript写得插件，以后变数也可以很多。

使用Markdown写blog已经很久了，近期接触并且看了下流传已久的gitbook平台，感觉做得确实不错。、

之前写blog的时候一直用得是stackedit，是因为stackedit的对Markdown做了很多扩展，功能很强大，有自动目录、流程图、时序图等等，然后可以浏览器直接开很方便。但实际上这些功能写出的东西虽然不错，但是放到比如github上的时候，github不支持。目前大多数平台对Mardown的扩展都只是到了和github差不多的地步，没有到stackedit的程度。这也导致同样写得东西，复制到github或者其他的平台的时候还得过一遍样式，比较麻烦。而且这些扩展的功能也用得不太多。另外stackedit时不时被墙然后访问很不稳定也是挺麻烦的一件事儿。

再来说这个gitbook，看中他是觉得它做了一个可持续集成的功能。就是github push完以后可以通知gitbook然后让gitbook自动构建文档内容。这点和比如jenkins和travis等等的CI系统很像。然后支持构建成pdf、epub（开源电子书格式）、mobi（kindle电子书格式）和在线书籍。然后版式也挺漂亮，还支持模板，引用等等，感觉确实蛮适合出版发行的。虽然目前为止Markdown的功能丰富程度比起Latex还差不少，但是上手难度也比Latex低不少。还是非常有潜力的，而且gitbook支持用javascript写得插件，以后变数也可以很多。

所以我决定也尝尝鲜，首先是吧blog里的文章记录转移过来，然后后面的开源项目的wiki或者文档也用这玩意构建。因为我用Markdown写博文的时候本来就备份了一份在github，所以有现成的仓库，然后把目录结构和配置调整成gitbook所支持的就可以了。话说好像已经很多国内的文档和开源书籍用这个生成了。

前言

由于我们的客户端的元素和资源比较多，cocos框架的各种库质量参差不齐，导致了有些地方加载速度实在很慢。并且没有一个统一的内存管理机制导致了整个内存占用不太好控制。

近期的活动比较零散，主要的业余精力都放在了libatbus上了。但是这个一时半会也写不完，所以能整理出来的东西不多。就说下最近跟进的开源代码吧。

首先是，跨平台协程框架 libcopp 跟进merge了boost 1.60 的context组件，这部分改动不多。仅仅是例行合并。

之前做了一个转Excel表到lua/二进制/json/xml的工具-xresloader。目的一方面是方便策划。另一方面是统一客户端和服务器的转表模式，并且要灵活适应环境变化。

最初做的时候考虑到既要方便Windows下策划和前端使用，又要方便后台部署在服务器上使用，甚至要集成在一些自动化的系统里。所以必须要跨平台。

libcopp更新 (merge boost 1.59 context)

之前由于兴趣写了一个协程框架，目前这个框架已经投入项目中使用。

这个框架的上下文部分是使用了boost.context，但是从开始写libcopp到现在，boost.context也更新了几个版本。而之前几次merge基本都是简单地跟进了make_fcontext和jump_fcontext两个函数，这次就再稍微翻了一遍其他部分的代码。

boost.context的变化

首先是它在非windows栈分配的时候，增加了valgrind的适配。不过boost.context里的不同平台的栈缓冲区其实结构差不多，但是boost的实现里给复制粘贴了很多遍，所以我就干脆把这些地方合并啦。减少了一些重复代码。

小记最近踩得两个C++坑

记一下最近踩得两个C++独有的暗坑，其中一个和ABI相关。第二个坑其实之前研究过，但是没有实例，这次算是碰到了个典型的实例。

坑一：常量引用失效

在项目中碰到的实例的大致流程是:

Redis全异步高可用Driver设计稿

前言

现在Redis的集群功能已经Release。但是并没有一个官方直接提供的高可用性的API可以使用。有的只有解决方案，Sentinel和Cluster。所以有必要自己设计一套高可用的Driver层以供业务使用。

之前有搜集过一些常用的命令脚本，其中有vim的部分。但是vim内置的很多功能那些个命令显然是不够的，而且那些记录的很多也不常用，于是想到专门开一个页面记录vim常用的命令集。

前言

搭建自动化构建（jenkins）的过程中碰到了挺多问题，需要装各种插件解决。为了方便下次部署，这里先记录一下用到的插件及用途

Jenkins插件

  1. Ant Plugin java打包工具
  2. Authorize Project 项目权限管理
  3. Clang Scan-Build Plugin clang静态分析（尚未使用）
  4. Cppcheck Plug-in cppcheck静态代码分析
  5. Credentials Plugin 登入凭据管理
  6. Dashboard View 总览
  7. disk-usage plugin 磁盘使用量统计
  8. Doxygen Plug-in doxygen插件（没使用成功，我还是自己命令行生成的）
  9. Email Extension Plugin 定制化邮件
  10. embeddable-build-status 提供接口嵌入构建状态到外部系统
  11. Environment Injector Plugin 把参数化构建的参数导入到环境变量
  12. GIT client plugin 和GIT plugin
  13. Github和Gitlab集成插件
  14. Gravatar插件
  15. Matrix Authorization Strategy Plugin和Matrix Project Plugin 项目矩阵授权策略
  16. Maven Integration plugin 更高级的java构建工具
  17. openid和OpenID4Java API
  18. Publish Over SSH
  19. Release Plugin
  20. Slave SetupPlugin 、slave-status、SSH Slaves plugin、Windows Slaves Plugin
  21. SSH Agent Plugin、SSH Credentials Plugin
  22. Static Analysis Utilities
  23. Xcode integration 用于集成xcode工程文件 上面没有链接的插件属于我没有主动去使用（自动开启或者装了没用过的）的。没写注解的是反正一看就知道什么意思。

Written with StackEdit.