流式计算系统是近些年发展较快的领域，虽然发展迅速，但实际上直到现在都没有能让所有人都满意的系统出现，哪怕是 flink/blink。
流式计算的理论基石是 leslie lamport 在 1985 年发表的论文《Distributed Snapshots: Determining
Global States of a Distributed System》。首先将分布式系统中的进程定义为 process，然后将进程间的连接定义为
channel。当需要计算全局状态时，因为没有能够全局同步的时钟，所以需要有别的办法能够记录整个计算集群的状态值。
process 及连接 process 的 channel
Gopher China 讲师尘埃落定，可惜今年没有获得去讲的机会，把之前的内容总结在 Blog 里吧~
由于 MySQL 类带 Schema 类存储系统的设计问题，不支持快速的列扩充，实际业务中，一个业务实体的属性随着业务的发展是一定会膨胀的。这样持续在
MySQL 上加列往往就会捉襟见肘。比如我的历史业务订单表有 50 个字段，虽然会对历史数据进行归档，但在线上还是会有千万甚至亿级的数据，这时候在 MySQL
上加列一般使用 PTOSC 或者 Ghost 来改表，两者设计有区别，但缺点都一样：慢。
在公司内见到无数的人在前仆后继地造规则引擎，起因比较简单，drools 之类的东西是 Java 生态的东西，与 Go
血缘不合，商业规则引擎又大多超重量级，从零开始建设的系统使用起来有很高的学习成本。刚好可能也不是很想写 CRUD，几个人一拍即合，所以就又有了造轮子的师出之名。
要造一个规则引擎，说难实际上也不难。程序员们这时候捡起了学生时代的编译原理书，抄起递归下降、 lex/yacc 或者再先进一点的 antlr 之类的
parser generator 就搞了起来。造的时候说不定还发现噢噢，大多数 parser generator
还有不支持左递归的问题，然后按照它支持的文法写出的
2018 已经过去了，在 2018 年中的时候给自己定了 11 个目标：2018 目标 [http://xargin.com/2018-plan/]
，最优先的目标大部分也完成的差不多了，对 Go
源码的阅读工作量稍微有点低估(剩下一些查漏补缺的东西了)。。后来发现有位国外的兄弟也在干类似的事情，不过比我包装的更好：go-under-the-hood
[https://github.com/changkun/go-under-the-hood]。虽有冲动把我的 Go
语言总结也慢慢向这种开源书的形式靠拢，不过想想，好像也没什么特别大的收益，暂时作罢。
18
之前一直以为 ghost 支持不了 mermaid。。
最近看到某博主在 ghost 中加入了 mermaid 支持，研究了一下步骤，看起来和之前我加讨饭链接的方法差不多：
code injection
在管理界面的 code injection 中增加
具体的版本可以看这里 [https://unpkg.com/mermaid@8.0.0/dist/]。
因为 ghost 的
