G2EX

0x00 简介 最近两年工作中对区块链技术接触较多，接下来可能要告一段落了。期间对 go-ethereum 进行过联盟链改造，使用 Raft 共识算法把以太坊的 TPS 提升到了 1K+。这里总结一下 Raft 算法，既是对自己经历对一种记录，也算是对他人对帮助。 Raft 算法是一个非常好理解（相比 Paxos 算法来说），也是一个非常受欢迎的共识算法，比如常用的服务发现、共享配置以及一致性保障的 etcd 和 Counsul 都使用了 Raft 算法来保证一致性。 0x01 什么是分布式共识算法 在分布式计算领域中有一个非常有名的 CAP 定理：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。 一致性是指节点数据的一致，即所有节点在同一时间的数据完全一致。如果细分的话，一致性又可以分为强一致、弱一致和最终一致。比如我们经常使用的多副本关系型数据库满足的是强一致性，又因为要同时满足高可用，那么就弱化了分区容忍性（可以使用简单的网络拓扑来减少分区出错的可能）；公有的比特币、以太坊网络是属于最终一致，因为它们必须优先满足可用性和分区容忍性。 分布式网络中所有节点要想达成一致，就需要一个算法来促成这个一致，这个算法就是共识算法。我们常听说的 挖矿、PoS、DPoS、PBFT、Raft 都属于解决一致性的算法。 0x02 理解 Raft Raft 中，节点通过心跳消息来保持通信，一个节点只会处于以下三种状态中的一种： Follower（跟从者） Candidate（候选人） Leader（领导者） 最开始时，所有的节点都是 follower，如果 follower 收不到 leader 的心跳消息，那么 follower 会变为 candidate，并向其他节点发起投票，如果该 candidate 节点收到了半数以上的选票（包括投给自己的一票），那么它就当选为新的 leader。这个过程被称为 leader 选举 的过程。 接下来，leader 节点将带领所有节点对分布式网络中对数据更改达成一致，这个过程被称为 日志同步 。 日志同步的过程如下： Leader 收到客户端到数据提交请求，lea

0x00 背景 使用 Hexo + Github Pages 搭建博客后，每次更新文章需要使用 hexo d -g 会在本地生成 public 静态博客网站和向 Github 推送的 .deploy_git 文件夹。 .deploy_git 文件夹内容和 public 文件夹一致，但多了 Github 博客项目的仓库信息与提交信息。最终， .deploy_git 文件夹内的全部内容被推送到 Github 仓库中，由 Github Pages 服务完成静态网站的解析。 当切换工作环境后，需要重新安装 Nodejs 以及配置 Hexo 和它的依赖。而且每次更新文章后，都要 hexo d -g 手动部署。这样多次重复的工作非常低效，因此结合现在非常流行的 CI/CD 概念和工具，可以为 Hexo + Github Pages 博客集成 Travis CI 自动部署的能力。当推送博客仓库到 Github 后，由 Travis 自动获取当前 commit 并进行构建，把生成的静态网站推送到 Github Pages 分支。 0x01 理解 Hexo 的自动化部署 下图是 Hexo 手动部署的流程，hexo-blog 可以是本地一个项目，也可以是 Github、Gitlab 等仓库，本地配置好 Hexo 环境后，由 ① 触发部署，将本地生成的静态博客网站 .delpoy_git 推送到 Github 的静态博客仓库中。 当引入 Travis 后，整个流程变成了下图所示的流程。hexo-blog 项目必须是一个 Github 仓库了，当有文章更新，本地由 ① 触发，把 Hexo-blog 的源码推送到 Github，剩下的工作由 Travis 完成：获取 Github hexo-blog 仓库中最新的 commit，运行我们定义的 .travis.yml 并把生成的静态博客网站 .deploy_git 推送 Github 静态博客仓库 xxx.github.io。 注意，这里要区分 Github 中的两个仓库：静态 blog repo 和 Hexo blog repo。前者是博客网站的静态网站项目，由 Github Pages 托管和解析；后者是 Hexo 项目，前者的内容是由后者生成的。 0x02 如何配置自动化部