版本号

一.分布式锁要解决的问题 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 这把锁要是一把可重入锁（避免死锁） 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条） 这把锁最好是一把公平锁（根据业务需求考虑要不要这条） 有高可用的获取锁和释放锁功能 获取锁和释放锁的性能要好 二.基于数据库实现原理 1.新建锁表记录 CREATE TABLE `methodLock` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名', `desc` varchar(1024) NOT NULL DEFAULT '备注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成', PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT

问题导读: 1.zookeeper观察者什么时候调用？ 2.传统远程轮询服务存在什么问题？ 3.zk中回调服务的机制是什么？ 4.zk中watcher为什么不永久注册？ 5.什么是znode？ 在阅读之前首先明确个概念： 1.什么是znode？ 2.什么是客户端？ 我们使用 znode 这个术语来表示 ZooKeeper的数据节点 。 znode维持一个stat结构，它包含数据变化的 版本号 、ACL变化和时间戳，以允许cache 校验 和协调化的更新。每当znode的数据变化时，版本号将增加。一个客户端收到数据时，它也会收到数据的版本号。 保存在每个znode中的数据都是自动读写的。读操作获取znode的所有数据，写操作替换掉znode的所有数据。每个节点有一个访问控制表（ACL）来限制谁能做哪些操作。 Zookeeper中的角色主要有以下三类，如下表所示： <ignore_js_op> 系统模型如图所示： <ignore_js_op> 传统轮询远程service服务 传统远程的service往往是这样服务的，服务提供者在远程service注册自己的服务，服务调用者不断去远程service轮询看看是否服务提供者有没有提供服务或者更新服务。所以有弊端，就是延时比较高，而且因为很多不必要的空轮询带来高的负载和网络损耗，这种模式到zk里面就应该是这样。 <ignore_js_op>

在企业数据库设计中，经常会遇到一个需求，就是希望把操作之前的数据保留下来，能够看到操作之前是什么数据，操作之后是什么数据。对于这种需求，我们可以使用保留历史数据或者使用版本来实现。 为了能够保留历史数据，在版本设计时有以下方案： 一、使用版本号 版本号是一种常见的版本设计方案，就是在要进行历史数据保留的表上面增加一个版本号字段，该字段可以是DateTime类型，也可以是int类型，每进行数据操作时，都是创建一个新的版本，版本是只增不减的，所以只需要拿到最大一个版本号，就能得到最新的业务数据。 版本号除了能够用于留存历史数据外，还有一个功能就是避免并发编辑操作。比如我们有一个对象A，当前的版本是1，两个用户同时打开了该对象的编辑页面，进行数据更改。先是甲用户提交更改，这个时候系统把对象的ID和版本进行查询，发现要修改的数据最新版本是1，所以成功修改，保存了对象A的新版本2。这个时候用户乙也提交了修改。系统把对象的ID和版本1进行查询，发现要修改的数据最新版本是2，不符合要求，所以拒绝用户乙的修改。用户乙只有刷新界面，拿到最新的版本2，再进行修改。 ID 单号 金额 版本号 1 EXP123 100 1 在使用版本号的情况下，对单据的金额进行修改，修改后创建新的版本号2： ID 单号 金额 版本号 1 EXP123 100 1 2 EXP123 120 2 二、使用生效、失效时间

服务发现并没有怎样的高深莫测，它的原理再简单不过。只是市面上太多文章将服务发现的难度妖魔化，读者被绕的云里雾里，顿觉自己智商低下不敢高攀。 服务提供者是什么，简单点说就是一个HTTP服务器，提供了API服务，有一个IP端口作为服务地址。服务消费者是什么，它就是一个简单的进程，想要访问服务提供者提供的服务来干一些事情。一个HTTP服务器既可以是服务提供者对外提供服务，也可以是消费者需要别的服务提供者提供的服务，这就是服务依赖，没有你我就不是我自己。复杂的服务甚至有多个服务依赖。 服务发现有三个角色，服务提供者、服务消费者和服务中介。服务中介是联系服务提供者和服务消费者的桥梁。服务提供者将自己提供的服务地址注册到服务中介，服务消费者从服务中介那里查找自己想要的服务的地址，然后享受这个服务。服务中介提供多个服务，每个服务对应多个服务提供者。 服务中介就是一个字典，字典里有很多key/value键值对，key是服务名称，value是服务提供者的地址列表。服务注册就是调用字典的Put方法塞东西，服务查找就是调用字典的Get方法拿东西。 当服务提供者节点挂掉时，要求服务能够及时取消注册，比便及时通知消费者重新获取服务地址。 当服务提供者新加入时，要求服务中介能及时告知服务消费者，你要不要尝试一下新的服务。 Redis作为服务中介 Redis里面有丰富的数据结构，拿来存储服务字典再合适不过了

Zookeeper提供了Java API方便我们来操作zk服务，可以通过maven引入zk的相关依赖包。通过org.apache.zookeeper.Zookeeper类创建连接zk服务器的示例对象，在创建过程中给定zk服务器地址、会话持续时间以及监视器三个参数，当连接创建成功后，通过Zookeeper实例提供的接口来和服务器进行交互。Pom文件依赖内容如下： <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.4.5</version> （一）创建连接 使用 Zookeeper类 来表示连接，创建的该实例对象有四个构造方法来调用，不过一般最常用的是下面两个构造方法的调用：ZooKeeper(connectString,session-Timeout,watcher)和ZooKeeper(connectString,sessionTimeout,watcher,canBeRead-Only)；其中第一个构造方式底层调用第二个构造方法，只是canBeReadOnly参数设置为false。connectString参数为zk集群服务器的连接url，当给定路径的时候，表示所有的操作都是基于该路径进行操作的(路径只可以添加到最后)。例如: “hh:2181,hh:2182

　　NPM是随同NodeJS一起安装的包管理工具，能解决NodeJS代码部署上的很多问题，常见的使用场景有以下几种： 　　允许用户从NPM服务器下载别人编写的第三方包到本地使用。 　　允许用户从NPM服务器下载并安装别人编写的命令行程序到本地使用。 　　允许用户将自己编写的包或命令行程序上传到NPM服务器供别人使用。 　　由于新版的nodejs已经集成了npm，所以之前npm也一并安装好了。同样可以通过输入 "npm -v" 来测试是否成功安装。命令如下，出现版本提示表示安装成功: 　　$ npm -v 　　2.3.0 　　如果你安装的是旧版本的 npm，可以很容易得通过 npm 命令来升级，命令如下： 　　$ sudo npm install npm -g 　　/usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js 　　npm@2.14.2 /usr/local/lib/node_modules/npm 　　如果是 Window 系统使用以下命令即可： 　　npm install npm -g 　　使用淘宝镜像的命令： 　　cnpm install npm -g 　　使用 npm 命令安装模块 　　npm 安装 Node.js 模块语法格式如下： 　　$ npm install 　　以下实例

如果你想更清晰地学习git，你必须要了解3个重要区域。 工作区：即开发者的工作目录 暂存区：修改已被记录，但尚未录入版本库的区域 版本库：存储变化日志及版本信息 当你在工作区进行开发工作时，git会记录你的改动，此时，你使用git add指令，该工作区的内容会被加入到暂存区，你仍然可以对你提交的文件进行撤回操作，然后你使用git commit指令，暂存区的内容会被提交到版本库。 每个文件/目录发生的版本变化，我们都可以追溯，命令为 git log 常用格式： git log 查看项目的日志 git log 查看某文件的日志 git log . 查看本目录的日志 至于每个命令的具体效果，可以试一试，看看打印信息。 如果感觉日志有点乱，可以输入 git log --pretty=oneline 可以看到，我们对该项目进行了五次修改，形成了五个版本，现在，我们学习一下版本切换。 我们现在将版本回退到最初始的时候，输入 git reset --hard HEAD^^^^ 你想回退几个版本就输入几个"^"符号。 这个时候版本就被回退到了初始时候，你可以回去看看你的工作目录，看看是不是回到了我们最开始时候的工作状态。 该指令只能用来回退版本，而且它不能清楚地知道指针的指向。所以我们用版本号来进行版本的切换。 版本号很长，但是我们不需要写出全部的版本号，只需要你写的版本号与别的版本不一致就可以。

在 深入理解乐观锁与悲观锁 一文中我们介绍过锁。本文在这篇文章的基础上，深入分析一下乐观锁的实现机制，介绍什么是CAS、CAS的应用以及CAS存在的问题等。 线程安全 众所周知，Java是多线程的。但是，Java对多线程的支持其实是一把双刃剑。一旦涉及到多个线程操作共享资源的情况时，处理不好就可能产生线程安全问题。线程安全性可能是非常复杂的，在没有充足的同步的情况下，多个线程中的操作执行顺序是不可预测的。 Java里面进行多线程通信的主要方式就是共享内存的方式，共享内存主要的关注点有两个：可见性和有序性。加上复合操作的原子性，我们可以认为Java的线程安全性问题主要关注点有3个：可见性、有序性和原子性。 Java内存模型 （JMM）解决了可见性和有序性的问题，而锁解决了原子性的问题。这里不再详细介绍JMM及锁的其他相关知识。但是我们要讨论一个问题，那就是锁到底是不是有利无弊的？ 锁存在的问题 Java在JDK1.5之前都是靠 synchronized 关键字保证同步的，这种通过使用一致的锁定协议来协调对共享状态的访问，可以确保无论哪个线程持有共享变量的锁，都采用独占的方式来访问这些变量。独占锁其实就是一种悲观锁，所以可以说 synchronized 是悲观锁。 悲观锁机制存在以下问题： 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。

　　ElasticSearch是多用户操作的 ，需要保证数据的一致性，它用乐观锁保证数据的一致性，用户每次操作一次文档，它的版本号就会自动加1，用户对文档操作时，不需要对文档加锁、解锁，只需要指定要操作的版本。当版本号一致时，ElasticSearch会允许该操作顺利执行，而当版本号存在冲突时，ElasticSearch会提示冲突并抛出异常。ElasticSearch的版本号的取值范围是1到2^63-1。 　　1、内部版本控制 　　使用的是_version，下面是个简单例子： POST /lib2/books/_bulk {"index":{"_id":1}} {"title":"Html5","price":45} 　　显示版本号是3，"_version": 3，结果如下： { "took": 19, "errors": false, "items": [ { "index": { "_index": "lib2", "_type": "books", "_id": "1", "_version": 3, "result": "updated", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "_seq_no": 7, "_primary_term": 1, "status": 200 } } ] } 　

缺陷报告： 测试人员发现缺陷通过缺陷报告记录缺陷 测试人员通过缺陷报告将缺陷告知给开发方 利用缺陷报告对缺陷进行跟踪和管理 缺陷报告是测试人员和开发人员之前的重要沟通方式 当提交缺陷给开发人员后，开发人员会进行修改，修改完成后开发人员会把新版本交给测试人员进行测试。测试人员需要对缺陷进行管理。 假设测试人员提了20个bug，但开发人员只改了10bug就把新版本交给测试人员了，测试人员需要根据READNE进行查看开发人员修改的部分，测试人员关闭bug的时候最好注明版本号。其次版本号是依次增大的，版本号大的包含版本号小的修改完成的bug。 缺陷的描述： 将发现缺陷的过程（步骤、数据）记录清楚，使开发人员能够再现（重现）该bug。 要求：逻辑清晰、用语专业准确、容易理解（易读）、不做任何评价。 来源： https://www.cnblogs.com/lj12/p/11409630.html