Raft 诞生

2013 年, 斯坦福大学的 Diego Ongaro 和 John Ousterhout 发表了 Raft 论文《In Search of an Understanding Consensus Algorithm》,但是这篇论文比较短小,只是简单介绍了一下原理,对一些实现细节部分没有提及。更详细的论文是 Diego Ongaro 的博士论文《CONSENSUS: BRIDGING THEORY AND PRACTICE》。Raft的产生就是为了代替 Paxos, 毕竟 Paxos算法自 1990 年诞生以来，就一直被诟病难以理解,这也导致了后面业界很多基于Paxos的实现都是”Paxos-like”实现。

写这篇文章的目的, 是为了记录下如何解决Git多次提交记录聚合展示的方法。因为一个功能点的开发包括开发,测试等多个环节, 难免就会导致提交很多次commit, 而为了提交记录看起来更清晰, 且和功能点更好对应, 把这些相同目的的commit合并为一个就显得比较有意义了。当然, 也顺便治一下自己的强迫症。

在工作中, 我们会用到很多日期和时间处理的函数, 这里我们为了方便, 来做一个使用总结, 不用每次都去查Google。

索引(在MySQL中也叫做”键(key)”) 是排好序的, 用于快速查找数据的一种数据结构。

索引对于良好的性能非常关键。尤其是当表中的数据量越来越大时,索引对于性能的影响愈发重要。
在数据量较小且负载较低时, 不恰当的索引对性能的可能还不明显，但当数据量逐渐增大时, 性能则会急剧下降。

explain可以查看SQL语句的执行计划。下面, 我们就对explain查询出来的字段做一些使用说明。
返回的信息有10列, 分别是:

接下来一段时间, 会将主要精力投入在SQL优化 以及工作中常用的一些SQL小技巧总结。当然啦, 也会对Hive、Spark SQL 和 Presto 中的SQL使用做一些总结。之前SQL写得比较少, 更多的是用的pyspark进行大数据处理, 后端服务更多的用Mybatis自动生成工具来生成DAO层SQL代码,然后在Service层进行多次调用, 一是因为业务逻辑不复杂, 二是因为性能要求也没那么高。不过, 总感觉SQL这块如果不掌握的话, 可能后面发展会受限。好了, 废话不多说, 我们开始一段时间的 SQL 之旅吧。

正则示例

在公司的日常工作中， 经常会用到 Azkaban。作为一种工作流管理系统, 对我来说, 的确有学习的价值。

本文将会使用最新版的Azkaban源代码, 编译并搭建一套可运行调试的系统。开发工具使用的是IDEA, 运行环境是CentOS7。

从github下载源代码

截止目前，最新的tag版本是: 3.86.0
可以直接点击下载源码: 3.86.0