版本号

1. 悲观锁 悲观锁介绍（百科）： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 使用场景举例 ：以MySQL InnoDB为例 商品goods表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单，那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。 1如果不采用锁，那么操作方法如下： //1.查询出商品信息 select status from t_goods where id=1; //2.根据商品信息生成订单 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status为2 update t_goods set status=2; 上面这种场景在高并发访问的情况下很可能会出现问题。 前面已经提到，只有当goods status为1时才能对该商品下单，上面第一步操作中，查询出来的商品status为1。但是当我们执行第三步Update操作的时候

先构造一条数据出来 PUT /test_index/test_ type / 1 { "test_field" : "test test" } 模拟两个客户端，都获取到了同一条数据 GET test_index/test_ type / 1 其中一个客户端，先更新了一下这个数据，同时带上数据的版本号，确保说，es中的数据的版本号，跟客户端中的数据的版本号是相同的，才能修改。 PUT /test_index/test_ type / 1 ?version= 1 { "test_field" : "test client 1" } 另外一个客户端，尝试基于version=1的数据去进行修改，同样带上version版本号，进行乐观锁的并发控制。 PUT /test_index/test_ type / 1 ?version= 1 { "test_field" : "test client 2" } 会发现会返回错误信息： { " error ": { " root_cause ": [ { " type ": "version_conflict_engine_exception" , " reason ": "[test_type][1]: version conflict, current version [2] is different than the one provided

原文地址为： Mac系统打开命令行终端及查看操作系统版本号的方法 Mac系统打开命令行终端及查看操作系统版本号的方法 Mac系统打开命令行终端的方法： Mac系统终端查看操作系统版本号的方法： <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" " http://www.apple.com/DTDs/ </plist> 转载请注明本文地址： Mac系统打开命令行终端及查看操作系统版本号的方法 文章来源: Mac系统打开命令行终端及查看操作系统版本号的方法

我们使用node开发时，经常需要依赖一些模块，我们进行了下载之后，便一直在该版本的模块环境下进行开发，但是线上的服务器一般都是根据依赖来配置文件，重新下载各个模块，但是保不齐某个模块的版本已经更新了，这时线上的包会更新到最新的版本，但你的代码还是依据老版本来写的，这时可能会产生一些不知名的Bug, 首先看npm包的版本号的格式X.Y.Z,版本好的格式遵循semver 2.0规范，其中X为主版本号，只有更新了不向下兼容的API时进行修改主版本号，Y为次版本号，当模块增加了向下兼容的功能时进行修改，Z为修订版本号，当模块进行了向下兼容的bug修改后进行修改,这就是“语义化的版本控制”。 默认情况下，当用--save或者--save-dev安装一个模块时，npm通过脱字符(^)来限定所安装模块的主版本号，而该脱字符对于不同的版本号有不同的更新机制 ^1.2.1 代表的更新版本范围为 >=1.2.1 && < 2.0.0 ^0.2.1 代表的更新版本范围为 >=0.2.1 && < 0.3.0 ^0.0.2 代表的更新版本范围为 0.0.2（相当于锁定为了0.0.2版本） ##### 对于上述字符的版本控制，我们可以来进行一个尝试: 首先可以看到package.json中对于vuex的版本依赖为^2.3.1 然后查看以下项目中安装的vuex模块的版本号 果然没错，改版本号为2.3.1

前言 随着互联网的发展，各种高并发、海量处理的场景越来越多。为了实现高可用、可扩展的系统，常常使用分布式，这样避免了单点故障和普通计算机cpu、内存等瓶颈。 但是分布式系统也带来了数据一致性的问题，比如用户抢购秒杀商品多台机器共同执行出现超卖等。有些同学容易将分布式锁与线程安全混淆，线程安全是指的线程间的协同。如果是多个进程间的协同需要用到分布式锁，本文总结了几种常见的分布式锁。 基于数据库 悲观锁―事务 比如用户抢购秒杀商品的场景，多台机器都接收到了抢购的请求，可以将获取库存、判断有货、用户付款、扣减库存等多个数据库操作放到一个事务，这样当一台机器与数据库建立链接请求了抢购商品这个事务，另外的机器只能等这个机器将请求完成才能操作数据库。在实际应用场景中，常常库存与交易是两个独立的系统，这时的事务是一个分布式事务，需要用到两段式、三段式提交。 优点：是比较安全的一种实现方法。 缺点：在高并发的场景下开销是不能容忍的。容易出现数据库死锁等情况。 乐观锁―基于版本号 乐观锁常常用于分布式系统对数据库某张特定表执行update操作。考虑线上选座的场景，用户A和B同时选择了某场次电影的一个座位，都去将座位的状态设置为已售。 设想这样的执行序列： 1、用户A判断该座位为未售状态； 2、用户B判断该座位为未售状态； 3、用户A执行update座位为已售； 4、用户B执行update座位为已售。

1 、保证我们拿到的是最新代码： svn update 假设最新版本号是 28 。 2 、然后找出要回滚的确切版本号： svn log 假设根据 svn log 日志查出要回滚的版本号是 25 ，此处的 something 可以是文件、目录或整个项目 如果想要更详细的了解情况，可以使用 svn diff - r 28 : 25 "" 3 、回滚到版本号 25 ： svn merge - r 28 : 25 "" 为了保险起见，再次确认回滚的结果： svn diff "" 发现正确无误，提交。 4 、提交回滚： svn commit - m "Revert revision from r28 to r25,because of ..." 提交后版本变成了 29 。 分类: 软件使用 svn 转自： https://www.cnblogs.com/helloweworld/p/4024605.html 来源：博客园 作者： xh_Blog 链接：https://www.cnblogs.com/xh_Blog/p/11684393.html

1、保证我们拿到的是最新代码： svn update 假设最新版本号是28。 2、然后找出要回滚的确切版本号： svn log 假设根据svn log日志查出要回滚的版本号是25，此处的something可以是文件、目录或整个项目 如果想要更详细的了解情况，可以使用svn diff -r 28:25 "" 3、回滚到版本号25： svn merge -r 28:25 "" 为了保险起见，再次确认回滚的结果： svn diff "" 发现正确无误，提交。 4、提交回滚： svn commit -m "Revert revision from r28 to r25,because of ..." 提交后版本变成了29。 分类: 软件使用svn 转自： https://www.cnblogs.com/helloweworld/p/4024605.html 来源：博客园 作者： xh_Blog 链接：https://www.cnblogs.com/xh_Blog/p/11684393.html

Zookeeper的几个概念：（接下来将从这几个概念书写Zookeeper的内部工作流程） 数据模型 节点特性 版本 Watcher ACL 　 <1> 数据模型 ： 　　Zookeeper的视图很热Unix文件系统很像。但没有引入文件和文件目录相关概念；而是使用“数据节点”概念，称为ZNode； 　　ZNode是ZK中最小的数据单元，每个ZNode上可以保存数据，也可以挂载子节点；即形成了一种层次化空间树； 　 事务ID : ZK中，事务是指能够改变zk服务器状态的操作，一般包括数据节点创建与删除，数据节点内容更新和客户端会话创建与失效等操作；对于每一个事务请求，zk都会为其分配一个全局唯一的事务ID,用ZXID表示，是一个64位的数字；每一个ZXID对应一个事务操作； <2> 节点特性： 　　 ZK中每个数据节点都是有生命周期；具体取决于数据节点的类型； 　　节点类型可以分为：持久节点，临时节点，顺序节点； 　　在节点的创建过程中，可以组合使用，于是有以下四种组合： 　　　　（1）持久节点：该节点一旦被创建，就会一直存在于ZK服务器上，直到有删除操作来主动清除这个节点； 　　　　（2）持久顺序节点：ZK中，每个父节点会为其第一级子节点维护一份顺序，用于记录下每个节点的先后顺序。 　　　　（3）临时节点：临时节点生命周期和客户端会话绑定在一起，客户端会话失效，这个节点被自动清理掉

解决缓存问题,发布前添加版本号 文件夹结构 const gulp = require('gulp'); // 文件清理 const clean = require('gulp-clean'); // 加版本号 const assetRev = require('gulp-asset-rev'); // 使用gulp-htmlmin压缩html gulp.task('htmlminTask', function() { gulp.src('src/*.html') //创建一个流，用于从文件系统读取 Vinyl 对象 .pipe(assetRev()) //管道方法 .pipe(gulp.dest('dist/')) //创建一个用于将 Vinyl 对象写入到文件系统的流 gulp.src('src/index.html') .pipe(assetRev()) .pipe(gulp.dest('dist/')) gulp.src(['src/**/*.html']) .pipe(assetRev()) .pipe(gulp.dest('dist/')) }) // 文件复制 gulp.task('copyTask', function() { gulp.src('src/asset/css/**/*') .pipe(gulp.dest('dist/asset/css/')) gulp

1.CAS导致ABA问题： CAS算法实现一个重要前提需要取出内存中某时刻的数据并在当下时刻比较并交换，那么在这个时间差中会导致数据的变化。 比如：线程1从内存位置V中取出A，这时线程2也从V中取出A，线程2进行了一些操作将值改成了B，然后线程2又将V的数据改回A；此时线程1进行CAS操作发现内存中仍然是A，然后线程1操作成功。 尽管线程1的CAS操作成功，但是 不代表这个过程就是没有问题的 。 解决ABA问题： 利用原子引用+修改版本号 （类似时间戳），每次需要获取到版本最新的值进行处理。 2.原子引用AtomicReference ABA问题出现示例： package com.mort.test; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicReference; public class TestAtomicReference { static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100); public static void main(String[] args) { new Thread(() -> { // 执行ABA操作