pre-commit

【推荐阅读】微服务还能火多久？>>> 众所周知，数据库能实现本地事务，也就是在同一个数据库中，你可以允许一组操作要么全都正确执行，要么全都不执行。这里特别强调了本地事务，也就是目前的数据库只能支持同一个数据库中的事务。但现在的系统往往采用微服务架构，业务系统拥有独立的数据库，因此就出现了跨多个数据库的事务需求，这种事务即为“分布式事务”。那么在目前数据库不支持跨库事务的情况下，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。废话不多说，那就开始吧～ 什么是事务？ 事务由一组操作构成，我们希望这组操作能够全部正确执行，如果这一组操作中的任意一个步骤发生错误，那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作，要么全都正确执行，要么全都不要执行。 事务的四大特性 ACID 说到事务，就不得不提一下事务著名的四大特性。 原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求，一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃

问题描述： 本地使用source tree推送代码，抛如下异常 pre -commit hook failed (add --no-verify to bypass) 1 进入项目所在的.git文件夹(cd .git) 2 再进入hooks文件夹 3 删除pre-commit文件 rm -rf pre-commit 4 SourceTree也可以正常推送。重新git commit -m ‘xxx’ git push即可。 ———————————————— 版权声明：本文为CSDN博主「工匠解码」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/MrZhangXL/java/article/details/96887759 来源： oschina 链接： https://my.oschina.net/u/4410289/blog/3229328

本文作者：nonoren1985 Libra技术系列解读 往期回顾 move语言简介 move语法、解释器和验证器 本期详解“LibraBFT共识机制” Libra白皮书中关于共识机制的描述 Libra 区块链采用了基于 LibraBFT 共识协议的 BFT 机制来实现所有验证者节点就将要执行的交易及其执行顺序达成一致。这种方法可以在网络中建立信任，因为即使某些验证者节点(最多三分之一的网络)被破坏或发生故障，BFT共识协议的设计也能够确保网络正常运行。与其他一些区块链中使用的“工作量证明”机制相比，这类共识协议还可实现高交易处理量、低延迟和更高能效的共识方法。 1. libra共识简介 Libra的共识采用的是LibraBFT共识，是一个为Libra设计的鲁棒的高效的状态复制系统。它基于一种新型的BFT共识算法，HotStuff(BFT Consensus in Lens of Blockchain)，在扩展性和一致性上达到了较高的水平。LibraBFT 在HotStuff的基础上引入显示的活跃机制并提供了具体的延时分析。LibraBFT在3f+1个验证节点之间收集投票，这些验证者可能是诚实的节点也可能是拜占庭节点。在网络中有2f+1个诚实节点的前提下，Libra能够抵御f个验证节点的双花攻击和分叉攻击。LibraBFT在一个有全局统一时间（GST），并且网络最大延时（ΔT

1 一致性 1.1 简述 一致性，是指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的 假设一个具有N个节点的分布式系统，当其满足以下条件时，我们说这个系统满足一致性： 全认同 : 所有N个节点都认同一个结果 值合法 : 该结果必须由N个节点中的过半节点提出 可结束 : 决议过程在一定时间内结束，不会无休止地进行下去 1.2 面临着的问题 消息传递异步无序 : 现实网络不是一个可靠的信道，存在消息延时、丢失，节点间消息传递做不到同步有序 节点宕机 : 节点持续宕机，不会恢复 节点宕机恢复 : 节点宕机一段时间后恢复，在分布式系统中最常见 网络分化 : 网络链路出现问题，将N个节点隔离成多个部分 拜占庭将军问题 : 节点或宕机或逻辑失败，甚至不按套路出牌抛出干扰决议的信息 假设现实场景中也存在这样的问题： 周五 我：晚上下班吃鸡 周六凌晨 xc：好的 // 消息延迟 我：... --------------------------------- 我：晚上下班吃鸡 xc：No (两小时后) xc：No problem！ // 宕机节点恢复 我：... --------------------------------- 我：晚上下班吃鸡 ... // 节点宕机 --------------------------------- 我：晚上下班吃鸡 cx:好，我们去大保健！ //

同一个工程项目，为了方便管理，git 的 commit 信息最好按照一定的格式规范，以便在需要的时候方便使用。什么是方便的时候，比如出现了一个线上 bug，所以需要回滚操作，知道了提交信息可以方便的定位问题。代码 review 的时候也知道了该次 commit 干了什么，所以 commit 标准化好处很多，不再举例。 实现 可以马上想到的是利用 shell 结合 git hook 实现在 git commit 阶段检查输入是否符合规范。符合就通过，不符合就终止，并给出提示信息。 规范是什么 常见的分类有下面几种： build：修改项目的的构建系统（xcodebuild、webpack、glup等）的提交 ci：修改项目的持续集成流程（Kenkins、Travis等）的提交 chore：构建过程或辅助工具的变化 docs：文档提交（documents） feat：新增功能（feature） fix：修复 bug pref：性能、体验相关的提交 refactor：代码重构 revert：回滚某个更早的提交 style：不影响程序逻辑的代码修改、主要是样式方面的优化、修改 test：测试相关的开发 轮子 在 github 上有 commitlint 这个项目，它可以很方便的在工程中做配置，并允许你自定义上面说的「规范」、「分类」。 commitlint ：用于检查提交信息 husky