pre-commit

1、分布式事务 高可用是指系统无中断的执行功能的能力，代表了系统的可用程度，是进行系统设计时必须要遵守的准则之一。 而高可用的实现方案，无外乎就是冗余，就存储的高可用而言，问题不在于如何进行数据备份，而在于如何规避数据不一致对业务造成的影响。 对于分布式系统而言，要保证分布式系统中的数据一致性就需要一种方案，可以保证数据在子系统中始终保持一致，避免业务出现问题。 这种实现方案就叫做分布式事务，要么一起成功，要么一起失败，必须是一个整体性的事务。 针对分布式系统的特点，基于不同的一致性需求产生了不同的分布式事务解决方案， 追求强一致的两阶段提交、追求最终一致性的柔性事务和事务消息 等等。各种方案没有绝对的好坏，抛开具体场景我们无法评价，更无法能做出合理选择。在选择分布式事务方案时，需要我们充分了解各种解决方案的原理和设计初衷，再结合实际的业务场景，从而做出科学合理的选择。 2、理论基础 在讲解具体方案之前，有必要了解一下分布式中数据设计需要遵循的理论基础，CAP 理论和 BASE 理论，为后面的实践铺平道路。 2.1 CAP 理论 CAP，Consistency Availability Partition tolerance 的简写： Consistency： 一致性，对某个客户端来说，读操作能够返回最新的写操作结果。 Availability： 可用性

随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。在 分布式一致性 一文中主要介绍了分布式系统中存在的一致性问题。本文将简单介绍如何有效的解决分布式的一致性问题,其中包括什么是 分布式事务 ， 二阶段提交 和 三阶段提交 。 分布式一致性回顾 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有 二阶提交协议 （Two Phase Commitment Protocol）、 三阶提交协议 （Three Phase Commitment Protocol）和 Paxos算法 。 分布式事务 分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果

分布式一致性理论 CAP 理论 一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。 如下： 选项 描述 C(Consistence) 一致性 ，指数据在多个副本之间能够保持一致的特性（ 严格的一致性 ）。 A(Availability) 可用性 ，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 P(Network partitioning) 分区容错性 ，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 Base 理论 BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。 既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ） 基本可用 允许出现响应时间损失或者功能损失。 软状态 允许系统中的数据存在中间状态

代码评审 代码评审（CodeReview），顾名思义是对代码进行评审，是软件工程的活动之一。 通过代码评审可以保证代码质量，促进团队知识共享……好处多多。 版本控制与代码评审 软件工程的各个活动总是离不开工具的支持。 代码评审工具首先必须和版本控制工具相结合的。 现在主流的两种版本控制工具：SVN和GIT。 GIT有个Google开发的代码评审工具Gerrit，可以在提交前进行代码评审，评审通过之后才允许提交到版本库。 其次，代码托管平台GitLab（号称是GitHub的开源实现）也可以用来进行代码评审（把代码fork过去，用pull request的方式实现代码评审）。 如果版本控制工具是GIT，当然优先选择用Gerrit或者GitLab来尝试做代码评审了。 但是如果版本控制工具是SVN呢？这目前还没有发现很好的解决方案。 所以问题来了，在技术选型上，该选择什么工具来进行代码评审呢？ 代码评审工具选型 关于代码评审，有很多支持工具，可以查看： 简单实用的Code Review工具 开源的代码评审工具有： ReviewBoard 、 Facebook Phabricator 、 Codestriker 、 Groogle 、 Rietveld 、 JCR（Java Code Reviewer） 、 Jupiter 、 ReviewClipse 商业版的代码评审工具有：

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

I'm trying to implement a process so that the manager can Review the code of all developers before the developers can check in to TFS 2013. Is there any process to require a review of the code by a human being before it is added to a real project? I'm using TFS 2013 with Visual Studio 2013. TFS 2013 supports this out of the box, and is very straight forward to use. Developer needs to file a request for review in the team explorer: Go to Team Explorer Open pending changes Under "Actions" menu, choose Request Review Specify the reviewer, and send. The target user (in your case, the manager) will

I seem to be getting nowhere with this. Either searching the web for a script, etc. Anyone got a script that you can just edit the out-of-box pre-commit.tmpl in a Windows environment that requires x chars to be entered in for a comment on commit in Tortoise Subversion globally so that all members on the team are required whereas this requirement is pushed down to the clients from SVN server? I don't know the scripting language and this should be something pretty damn simple without me taking the time to figure out scripting for the next 3 hours. This is a .bat file to require there is a

1、什么是分布式事务？ 答：指一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。从本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务产生的原因？ 2.1 数据库分库分表    当数据库单表数据达到千万级别，就要考虑分库分表，那么就会从原来的一个数据库变成多个数据库。例如如果一个操作即操作了01库，又操作了02库，而且又要保证数据的一致性，那么就要用到分布式事务。 2.2 应用SOA化    所谓的SOA化，就是业务的服务化。例如电商平台下单操作就会产生调用库存服务扣减库存和订单服务更新订单数据，那么就会设计到订单数据库和库存数据库，为了保证数据的一致性，就需要用到分布式事务。 总结：其实上面两种场景，归根到底是要操作多数据库，并且要保证数据的一致性，而产生的分布式事务的。 3、分布式事务解决方案 3.1 两阶段提交（2PC）    XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、Mysql等数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交回滚。 XA实现分布式事务的原理如下： 总结   二阶段提交看起来确实能够提供原子性的操作，但是它存在几个缺点： 1、

Subversion本身有很好的扩展性，用户可以通过钩子实现一些自定义的功能。所谓钩子实际上是一种事件机制，当系统执行到某个特殊事件时，会触发我们预定义的动作，这样的特殊事件在Subversion里有很多。那么SVN的钩子有哪些呢？下面简单介绍下： 服务器钩子： 锁定的2种 pre-lock 钩子在每次有人尝试锁定文件时执行。可以防止完全锁定，或者用来创建控制哪些用户可以锁定哪些路径的复杂策略。如果钩子发现已存在锁，也可以决定是否允许用户“窃取”这个锁。 post-lock 在路径锁定后执行。通常用来发送锁定事件邮件通知。 解锁的2种 pre-unlock 钩子在某人企图删除一个文件上的钩子时发生。可以用来创建哪些用户可以解锁哪些文件的策略。制定解锁策略非常重要。如果用户 A 锁定了一个文件，允许用户B 打开这个锁？如果这个锁已经一周了呢？这种事情可以通过钩子决定并强制执行。 post-unlock 在一个或多个路径已经被解锁后执行。通常用来发送解锁事件通知邮件。 提交的3种 start-commit 它在提交事务产生前已运行，通常用来判定一个用户是否有权提交。版本库传给该程序两个参数：到版本库的路径，和要进行提交的用户名。如果程序返回一个非零值，会在事务产生前停止该提交操作。如果钩子程序要在stderr中写入数据，它将排队送至客户端。 pre-commit 在事务完成提交之前运行