版本号

springCloud简介 　　尽管springCloud带有“cloud”字样，但它并不是云计算解决方案，而是在SpringBoot基础上构建的，用于快速构建分布式系统的通用的工具集。从技术架构上降低了对大型系统构建的要求，使我们以非常低的成本（技术或者硬件）搭建一套高效、分布式、容错的平台，但Spring Cloud也不是没有缺点，小型独立的项目不适合使用，另外对分布式事务的支持暂时也没有。 springcloud特点 　　上面我们说了，springCloud是基于springboot开发的，那么springboot拥有的特点，springcloud也都有： 约定优于配置。 适用于各种环境。开发，部署在PC server或各种云环境（例如阿里云，AWS等）均可。 隐藏了组件的复杂性，并提供声明式，无XML的配置方式。 开箱即用，快速启动。 轻量级的组件。springcloud整合的组件大多比较轻量，例如Eureka，zuul,等等。都是各自领域轻量级的实现。 组件丰富，功能齐全。spring cloud为微服务架构提供了非常完整的支持，例如配置管理，服务发现，断路器，微服务网关等。 选型中立，丰富。例如：spring cloud支持使用Eureka,Zookeeper或Consul实现服务发现。 灵活。spring cloud的组成部分是解耦的，开发人员可按需灵活挑选技术选型。

mysql的存储引擎架构把查询处理及其他系统任务和数据的存储/提取相分离 1.1 mysql逻辑架构 　　第一层：链接处理、授权认证、安全等大多数基于网络的工具或者服务都有类似的架构 　　第二层：核心服务，查询解析、分析、优化、缓存、所有的内置函数（日期、时间等），所有跨存储引擎的功能，存储过程、触发器、视图等 　　第三层：存储引擎，负责数据的存储和提取 　　1.1.1 连接管理与安全性 　　　　每个客户端连接都会在服务器进程中拥有一个线程，服务器会缓存线程， 　　1.1.2 优化与执行 　　　　mysql会解析查询，并创建解析书，然后优化。 　　　　在查询之前，会先检查查询缓存 1.2 并发控制 　　1.2.1 读写锁 　　　　读锁和写锁 　　　　1.2.2 锁颗粒 　　　　　　表锁： 　　　　　　行级锁：可以最大程度的支持并发，只在存储引擎层实现 1.3 事务 　　原子性、一致性、隔离性、持久性 　　1.3.1 隔离级别 　　　　未提交读：事务的修改，即使没有提交，对其他事务也都是可见的。脏读 　　　　提交读：一个事务只能看见已经提交的事务的修改。不可重复读 　　　　可重复读：保证了同一个事务中多次读取同样记录的结果是一致的，mvcc，mysql默认隔离级别 　　　　可串行化：强制事务串行执行 　　1.3.2 死锁 　　　　各种死锁检测和死锁超时机制

依赖管理 注意上篇文章我们搭建的springboot项目pom.xm文件有如下配置： 继承了 spring-boot-starter-parent < parent > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-parent </ artifactId > < version > 2.1.4.RELEASE </ version > < relativePath /> <!-- lookup parent from repository --> </ parent > spring-boot-starter-parent 提供了项目默认的java版本 1.8，默认的编码UTF8，同时依赖 spring-boot-dependencies ，提供了dependency Management管理依赖的版本号，这样子项目在依赖具体jar包时无需指定具体版本号，统一继承parent的版本号； 但是不是所有的项目都希望继承 spring-boot-starter-parent，由于自己公司的项目可能还依赖自己的parent，此时还想使用dependency Management管理依赖的版本号，可以引入如下依赖且scope设置成scope=import

https://www.cnblogs.com/lunlunshiwo/p/10361298.html 在我接触Flutter之前，做过一个比较失败的基于DCloud的HTML5+技术的app，做过几个RN项目。在这两种不同机制的app升级方案中，RN采用的是微软的CodePush技术。而那个比较失败的项目采用的是检查版本号，下载安装包的方法。而在这个Flutter项目中，我在写app更新方法时，查资料的时候查到一篇文章，文章大概意思讲解了一下Flutter实行CodePush的可能性。但是，我并未找到可能实现的方法。因此，采用了简单粗暴的进行app升级。 服务器的操作 为了检验版本号和下载app安装包，我们在服务器某文件夹下放置两个文件，第一个为 version.json 文件，内容为： { "android": "1.0.1" } 这个文件用于保存版本号，我们可以写一个读取方法来读取这个版本号： Future<bool> checkNewVersion() async { try { final res = await http.get(downLoadUrl + '/version.json'); if (res.statusCode == 200) { final Map<String, dynamic> body = json.decode(res.body); if

版本控制比较普遍的 3 种命名格式 : 一、GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 示例 : 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式 : 主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于 0 的整数。 应根据下面的约定使用这些部分： Major

　　DBMS中并发控制的任务是确保多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性 　　乐观锁和悲观锁是并发控制主要采用的技术手段。 　　无论是乐观锁还是悲观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库中有乐观锁和背锅所的盖面，其他很多地方都有类似的概念。 　　针对不同的业务场景，应该选用不同的并发控制方式，所以，不要把乐观锁和悲观锁下一的理解为DBMS中的概念，更不要把他们和数据库中提供的锁机制混为一谈。其实，在DBMS中，悲观锁正式利用数据库本身的锁机制来实现的。 　　悲观锁 　　在关系数据库中，悲观锁是一种并发控制的方法，它可以组织一个事务一影响其他用户的方式来修改数据。如果一个事务执行的操作嗾使某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。 　　悲观锁主要用于数据征用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。 　　悲观锁指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往一句数据库提供的锁机制（也只有数据库层提供的锁机制擦能真正保证数据访问的排他性，否则，及时在本系统中实现了加锁机制，也无法保证外部系统不会修改数据） 　　在数据库中

前言 最新下了个最新版的夜神模拟器，然后adb devices发现连不上模拟器了，报adb server version (36) doesn't match this client (39); killing... 从报错信息看是adb版本不匹配导致的，接下来讲如何解决这个问题 环境： 夜神模拟器 6.0.9.0 系统adb版本号 1.0.39 遇到问题 1.从官网下载夜神模拟器 【下载地址】 ，我下载的版本是V6.0.9.0，傻瓜式下一步安装后，adb devices连手机 adb devices C:\Users\admin>adb devices List of devices attached adb server version (36) doesn't match this client (39); killing... * daemon started successfully 2."adb server version (36) doesn't match this client (39)"这个意思是说当前夜神模拟器的adb版本是36，android-sdk里面的adb版本是39,不匹配导致的。 解决办法，把android-sdk里面的adb(39)版本复制出来，替换nox模拟器里面的nox_adb(36)版本就可以了 查看adb版本号 1.查看当前android

    鉴于肺活量有限，在潜水了半年多之后上岸来透透气觉着是时候写点东西了，能力有限都是记录平常工作中遇到的问题以及解决方法，如果再能帮到有相似问题的同仁，那就算是额外收获了！【抱拳】     其实写这个的初衷也是，之前几个系统上线部署的时候写过自动上线部署的脚本，但每次发布完之后，可能本地没有保存副本，导致再上线的时候又得去登系统再做部分修改，再部署脚本太繁琐了（主要还是记性不好），每次去网上找相关的部署脚本，基本大同小异也不知道到底文章的源头是谁。自己想要的也找不到，俗话说自己动手丰衣足食废话不多说直接上脚本。 写脚本之前先交代一下整个升级的流程：     上边的流程大体是这样，其实整体并不难，复杂的是之前的各种判断。看下脚本是写成了两个脚本文件，上线部署和失败后的回退脚本，应用启停的脚本过会再提供。 #!/bin/bash # # SCRIPTNAME:sdwan_version.sh # DATE: 2020/03/13 # author: Mright # version: V1.3 # desc: # V1.2:增加version.info文件到应用用户目录下，保存即将部署的应用版本号以及当前生产上部署的 # 版本号，应用部署完成后将版本号回写到version.info中 # V1.3:调整version.info内容可记录不同应用版本号

何谓悲观锁与乐观锁 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。 （1）悲观锁： 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。 （2）乐观锁: 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中 java.util.concurrent.atomic 包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。 两种锁的使用场景 从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景）

俗话说：不想当项目经理的程序猿不是好的架构师。 相信每一个有上进心的程序猿，都有一个架构师的梦。 近期完毕了一个中小型的项目，让我有了一些感受和想法，于是决定新开一个系列——《菜鸟要做架构师》。 经常看我博客的人应该了解，我写了好几个“菜鸟”系列了。有非常多人问我，你都是大牛了，怎么写博客还叫菜鸟？有人认为太过低调了。也有人认为这是在装B。事实上呢。我是认为自己真的还仅仅是个菜鸟。 就光拿计算机行业来说吧。就有太多太多的知识我不懂，甚至连听都没听过。 记得高中有位老师说的话让我印象特别深刻，大概意思是：越是一知半解的人，往往越是喜欢高谈阔论；越是知识渊博的人。往往越认为自己欠缺非常多（ 哎呀，如今说这句话。有点装B的嫌疑，罪过罪过.... ）。所以我认为要保持一颗谦卑的心，才干够不断的学习并提高自己，所以用“菜鸟”二字来自勉。好了，好像扯的有点远。以下咱们进入正题。 项目背景： 这个项目是给廊坊市政府做的，本来这个项目是别的公司做的。后来由于种种原因，不做了，留下一个半成品。我接手的时候。他们给了源代码和数据库，另一些简单说明。 差点儿没有不论什么需求和设计文档。经过多方联系和沟通。他们给出的答复是：没有文档！最后经过大家讨论认为在他们的基础上继续开发，成本较高（须要弄清楚他们的代码以及数据库，他们给的库总共同拥有四百多张表）。所以最后决定又一次开发。 重构： 尽管文档一无全部