pre-commit

本文是翻译作品，作者是Piotr Nowojski和Michael Winters。前者是该方案的实现者。 原文地址是https://data-artisans.com/blog/end-to-end-exactly-once-processing-apache-flink-apache-kafka 2017年12月Apache Flink社区发布了1.4版本。该版本正式引入了一个里程碑式的功能：两阶段提交Sink，即TwoPhaseCommitSinkFunction。该SinkFunction提取并封装了两阶段提交协议中的公共逻辑，自此Flink搭配特定source和sink（特别是0.11版本Kafka）搭建精确一次处理语义(下称EOS)应用成为了可能。作为一个抽象类，TwoPhaseCommitSinkFunction提供了一个抽象层供用户自行实现特定方法来支持EOS。 用户可以阅读 Java文档 来学习如何使用TwoPhaseCommitSinkFunction，或者参考 Flink官网文档 来了解FlinkKafkaProducer011是如何支持EOS的，因为后者正是基于TwoPhaseCommitSinkFunction实现的。 本文将深入讨论一下Flink 1.4这个新特性以及其背后的设计思想。在本文中我们将： 1.

2PC: 事务提交分为两个阶段 准备阶段：事务管理器通知资源管理器准备分支事务，记录事务日志，并告知事务管理器准备结果。 提交/回滚阶段：如果所有的资源管理器在准备阶段都明确返回成功，则事务管理器向所有的资源管理器发起事务提交指令完成变更。否则，事务管理器像所有的资源管理器发送回滚指令。 2PC的不足： 同步阻塞：对于任何指令，都必须要有明确的响应才能继续下一步操作。否则一致处于阻塞状态，占用资源。 过于保守：任何一个节点失败都会导致事务回滚。 事务协调者单点故障：如果协调者在第二阶段出现故障，那么其他参与者会一直处于锁定状态。 以上任何一点的出错，都将导致数据不一致问题。 3PC：是2PC的改进版本，它利用超时机制解决同步阻塞问题。事务提交分为三个阶段 询问阶段（CanCommit）: 事务协调者向参与者发送事务请求，询问是否可以完成指令，参与者只要回答是或不是 ，不需要做真正的事务操作，这个阶段会有超时终止机制。 准备阶段（PreCommit）: 事务协调者会根据参与者的反馈结果决定是否继续执行，如果在询问阶段所有参与者都返回可以，则事务协调者会向所有参与者发送PreCommit请求，参与者收到请求后写redo和undo日志，执行事务操作但是不提交事务，然后返回ACK响应等待事务协调者的下一步通知。如果在询问阶段任意参与者返回不能执行操作的结果

导读 在上一篇文章 《【分布式事务】基于RocketMQ搭建生产级消息集群？》 中给大家介绍了基于RocketMQ如何搭建生产级消息集群。因为 本系列文章最终的目的是介绍基于RocketMQ的事物消息来解决分布式系统中的数据一致性问题 ，所以先给大家率先介绍了RocketMQ消息集群的搭建。 原本是想着在这篇文章中直接介绍RocketMQ的事务消息特性，但是在梳理的过程中作者发现对于 分布式事务的概念 ，可能还会有很多同学不理解或者理解得不是很深刻的地方，而跳过这些基本概念直接去学习上层的实践可能并不是一件很好的事情，因此在这篇文章中，作者打算重点给大家先介绍下分布式事务相关的基本概念，诸如 分布式事务、2PC、3PC、TCC 之类的基本问题，之后再单独去介绍RocketMQ事务消息相关的实践。 数据库事务的概念 在讲述分布式事务的概念之前，我们先来回顾下事务相关的一些概念。 事务的基本概念： 就是一个 程序执行单元，里面的操作要么全部执行成功，要么全部执行失败 ，不允许只成功一半另外一半执行失败的事情发生。例如一段事务代码做了两次数据库更新操作，那么这两次数据库操作要么全部执行成功，要么全部回滚。 事务的基本特性 ： 我们知道 事务有4个非常重要的特性 ，即我们常说的（ ACID ）。 Atomicity（原子性） :是说事务是一个不可分割的整体，所有操作要么全做，要么全不做

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。 相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing） ”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤： 从 A 账户取 100 元

1. 前言 HotStuff提出了一个三阶段投票的BFT类共识协议，该协议实现了safety、liveness、responsiveness特性。通过在投票过程中引入门限签名实现了 O ( n ) 的消息验证复杂度。Hotstuff总结出对比了目前主流的BFT共识协议，构建了基于经典BFT共识实现pipeline BFT共识的模式。 HotStuff是基于View的的共识协议，View表示一个共识单元，共识过程是由一个接一个的View组成。在一个View中，存在一个确定Leader来主导共识协议，并经过三阶段投票达成共识，然后切换到下一个View继续进行共识。假如遇到异常状况，某个View超时未能达成共识，也是切换到下一个View继续进行共识。 Basic hotStuff基础版本的共识协议，一个区块的确认需要三阶段投票达成后再进入下一个区块的共识。pipeline hotStuff是流水线的共识协议，提高了共识的效率。 2. 协议内容 2.1. 协议基础 2.1.1. 名词解释 BFT: 全称是Byzantine Fault tolerance， 表示系统可以容纳任意类型的错误，包括宕机、作恶等等 SMR: 全称是State Machine Replication， 一个状态机系统，系统的每个节点都有着相同的状态副本 BFT SMR protocol:

#!/bin/sh repos="$1" txn="$2" res="ok" # make sure that the log message contains some text. svnlook=/usr/local/svn/bin/svnlook $svnlook log -t "$txn" "$repos" | egrep "[^[:space:]]+" >/dev/null || unset res if [ "$res" != "ok" ] then echo "you must input some comments for you commit" >&2 exit 1 fi # all checks passed, so allow the commit. exit 0 来源： oschina 链接： https://my.oschina.net/u/4368242/blog/4345601

SourceTree/git解决pre-commit hook failed的问题 参考文章： （1）SourceTree/git解决pre-commit hook failed的问题 （2）https://www.cnblogs.com/soyxiaobi/p/9679092.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4284321/blog/4490081

commit message 应该如何写才更清晰明了？团队开发中有没有遇到过让人头疼的git commit？本文分享在git commit规范建设上的实践，规定了commit message的格式，并通过webhook在提交时进行监控，避免不规范的代码提交。 Git每次提交代码都需要写commit message，否则就不允许提交。一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作……但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。基于以上这些问题，我们希望通过某种方式来监控用户的git commit message，让规范更好的服务于质量，提高大家的研发效率。 初期我们在互联网上搜索了大量有关git commit规范的资料，但只有Angular规范是目前使用最广的写法，比较合理和系统化，并且有配套的工具（IDEA就有插件支持这种写法）。最后综合阿里巴巴高德地图相关部门已有的规范总结出了一套git commit规范。 commit message格式 <type>(<scope>): <subject> type(必须) 用于说明git commit的类别，只允许使用下面的标识。

集中式与分布式 集中式 分布式 分布式事务 一致性协议 2PC：Two-Phase Commit二阶段提交协议 3PC:Three-phase Commit 三阶段提交协议 Paxos算法 RAFT算法 总结 集中式与分布式 集中式 就是将所有的业务都部署在一个中心主机（节点）上，所有的功能都由这个主机集中处理。 特点 部署结构简单、不需要考虑多个主机之间的分布式协作问题。 分布式 分布式系统：指将 硬件 或者 软件组件部署在不同的网络计算机上 ，彼此之间仅 仅通过消息传递 进行通信和协调的系统。 特点 分布性 ：多台计算机可空间上随意分布，跨机房、跨城市都可以。 对等性 ：分布式系统中没有主/从之分，都是对等的节点或者服务。 副本 ：指分布式系统对 数据或服务冗余 ，以此提供高可用。 数据副本 ：是指在不同的节点上持久化一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取到该数据，这是分布式系统数据丢失问题最为有效的手段。 服务副本 ：指多个节点提供同样的服务，每个节点都有能力接收来自外部的请求并进行相应的处理。 **并发性：**分布式系统中的多个节点，可能会并发地操作一些共享资源，诸如数据库或分布式存储等。 **缺乏全局时钟：**一个典型的分布式系统是由一系列在空间上随意分布的进程组成，进程彼此之间通过消息进行通信。因此，无法判断两个事件谁先谁后。 可使用逻辑时钟。 *

导航 写一个axios-ts吧！学习Rollup（一） 写一个axios-ts吧！Rollup搭建typescript库（二） 写一个axios-ts吧！学习Prettier（三） Prettier是什么 Prettier 是一个代码格式化的工具，它会按照某一规范格式化代码。 为什么要使用Prettier 我的理解 通用的样式指南比团队讨论的要好，与其浪费大量时间讨论，不如 npm i 一下。所以为什么不用其他的而是用 Prettier 呢？ Prettier 是唯一全自动化的。希望停下讨论风格，虽然是有效的，但是时间浪费太多。到底用哪种风格，单引号还是双引号？不要再研究了，换个思路，我们要不要使用 Prettier ？只要大家选择同意就可以了。 使用 Prettier 的好处就是： 节省时间 避免低级错误 只管写代码，格式化交给 Prettier 结合 githook 减少 PR 中的样式问题 跟其他工具良好的结合 总之一句话，格式化用 Prettier 就对了。 怎么使用 官方文档 prettier官网 开始学习 ClI 使用 prettier 命令运行 Prettier ，选几个常用的，具体移步 prettier官网 --check / -c 检查文件是否已格式化，将结果打印到控制台，错误码： 0: 正确 , 1: 格式不正确 , 2: prettier出现错误 。