利用404特性同步文件(ASP版)

很久之前写的了,今天分享出来~

 

Git: There is no tracking information for the current branch.

在执行git pull的时候,提示当前branch没有跟踪信息:

  对于这种情况有两种解决办法,就比如说要操作master吧,一种是直接指定远程master:

  另外一种方法就是先指定本地master到远程的master,然后再去pull:

  这样就不会再出现“There is no tracking information for the current branch”这样的提示了。 ———————————————— 版权声明:本文为CSDN博主「K.Sun」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/sinat_36246371/article/details/79738782

宝塔面板如何卸载

宝塔面板如何卸载?宝塔面板是国内一款简洁易用的服务器管理面板,而有时候我们出于各种各样的原因可能需要卸载宝塔。面板既然能够安装,当然也可以卸载,下面我们介绍下卸载方法。 windows面板卸载 1.打开宝塔面板windows版安装目录,路径为:面板安装数据盘:\BtSoft\ServerAdmin 2.运行 UnInstall.exe 开始面板卸载 3.最后使用注册表清理软件或者360清理,清理注册表才可以清除服务文件。在卸载完成后,重启服务器以确保卸载干净。 linux面板卸载方法 一、脚本卸载 1.你需要先在面板中将通过面板安装的所有软件卸载,如 nginx、mysql、php 等等,然后,进入 SSH 命令行,输入以下命令: /etc/init.d/bt stop && rm -f /etc/init.d/bt && rm -rf /www/server/panel 2.或者脚本卸载更暴力一点的直接是都卸载,命令如下:

  二、后续解决 虽然卸载了面板及面板环境,可是系统还是会残留一些文件,比如 www 目录,网站文件。为防止安装别的面时出现一些错误,我们可以用命令:rm –rf www 强制删除 www 文件夹。 以上是关于宝塔面板如何卸载的介绍,安装宝塔面板需要确保纯净系统安装,西部数码云服务器提供预装好宝塔面板的系统模板,可直接安装使用,如需安装请点击 https://www.west.cn/cloudhost/linux.asp   from:https://www.west.cn/docs/58109.html

Your project is not referencing the ".NETFramework,Version=4.5" framework.

我遇到了 Your project is not referencing the “.NETFramework,Version=4.5” framework. Add a reference to “.NETFramework,Version=4.5” in the “frameworks” section of your project.json, and then re-run NuGet restore. 怎么弄都没法解决,我尝试了git撤销更改也无法解决,最后解决方法:删除/obj文件。 来自stackoverflow ———————————————— 版权声明:本文为CSDN博主「迷惘小书童」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/m0_37080285/article/details/90206495

Docker镜像大小优化不完全指南(.NET)

以我们家庭好医.netcore项目做个示例,来看看怎么进一步优化Docker镜像的大小。 这里以先编译再做镜像的方法为示例,当然你也可以把编译部分也写进Dockerfile里。   0.先来看看编译后的项目文件大小:39.2MB     1.先看一下VS2019默认Dockerfile生成的镜像 先上Dockerfile

  看看生成的镜像大小:265MB   2.用大家常用的slim镜像试试 Dockerfile

  镜像大小还是265MB,并没有变小。   3.用大家不常用的alpine镜像来优化 Dockerfile

  再来看看镜像大小:146MB,是不是很神奇~

CentOS设置时区与时间同步

1.设置时间

  2.安装ntpdate工具

  3.设置系统时间与网络时间同步

 

Git撤销对远程仓库的push&commit提交

撤销push 1. 执行  git log查看日志,获取需要回退的版本号 2. 执行 git reset –-soft <版本号> ,如 git reset --soft 4f5e9a90edeadcc45d85f43bd861a837fa7ce4c7 ,重置至指定版本的提交,达到撤销提交的目的 然后执行 git log 查看 此时,已重置至指定版本的提交,log中已经没有了需要撤销的提交  git reset 命令分为两种: git reset –-soft 与 git reset –-hard ,区别是: 前者表示只是改变了HEAD的指向,本地代码不会变化,我们使用git status依然可以看到,同时也可以git commit提交。后者直接回改变本地源码,不仅仅指向变化了,代码也回到了那个版本时的代码。 3. 执行 git push origin 分支名 –-force ,强制提交当前版本号。 至此,撤销push提交完成。 撤销commit 1. 执行 git log 查看需要撤销的commit的前面一个提交版本的id; 2. 执行 git reset --hard commit_id ,该commit_id为需要撤销的commit的提交的前面一个提交的版本,即需要恢复到的提交的id,重置至指定版本的提交,达到撤销提交的目的 3. 执行 git log 查看,commit提交已撤销   from:https://www.cnblogs.com/chaoxiZ/p/9714085.html

MySQL事务与MVCC如何实现的隔离级别

前言 其实数据库章节基本上的知识点我都写过一遍了,包括这篇事务和MVCC的,但是国庆期间我翻阅资料的时候我发现之前写的还差点意思,例子举得也差点意思,那我就根据我自己最新的理解,加上之前的总结相当于重写了,希望你也有新的收获。   数据库事务介绍   事务的四大特性(ACID) 原子性(atomicity): 事务的最小工作单元,要么全成功,要么全失败。 一致性(consistency): 事务开始和结束后,数据库的完整性不会被破坏。 隔离性(isolation): 不同事务之间互不影响,四种隔离级别为RU(读未提交)、RC(读已提交)、RR(可重复读)、SERIALIZABLE (串行化)。 持久性(durability): 事务提交后,对数据的修改是永久性的,即使系统故障也不会丢失。   事务的隔离级别   读未提交(Read UnCommitted/RU) 又称为脏读,一个事务可以读取到另一个事务未提交的数据。这种隔离级别岁最不安全的一种,因为未提交的事务是存在回滚的情况。   读已提交(Read Committed/RC) 又称为不可重复读,一个事务因为读取到另一个事务已提交的修改数据,导致在当前事务的不同时间读取同一条数据获取的结果不一致。 举个例子,在下面的例子中就会发现SessionA在一个事务期间两次查询的数据不一样。原因就是在于当前隔离级别为 RC,SessionA的事务可以读取到SessionB提交的最新数据。 发生时间 SessionA SessionB 1 begin; 2 select * from user where id=1;(张三) 3 update user set name=’李四' where id=1;(默认隐式提交事务) 4 select * from user where id=1;(李四) 5 update user set name=’王二' where id=1;(默认隐式提交事务) 6 select * from user where id=1;(王二)   可重复读(Repeatable Read/RR) 又称为幻读,一个事物读可以读取到其他事务提交的数据,但是在RR隔离级别下,当前读取此条数据只可读取一次,在当前事务中,不论读取多少次,数据任然是第一次读取的值,不会因为在第一次读取之后,其他事务再修改提交此数据而产生改变。因此也成为幻读,因为读出来的数据并不一定就是最新的数据。 举个例子:在SessionA中第一次读取数据时,后续其他事务修改提交数据,不会再影响到SessionA读取的数据值。此为可重复读。 发生时间 SessionA SessionB 1 begin; 2 select * from user where id=1;(张三) 3 update user set name=’李四' where id=1;  (默认隐式提交事务) 4 select * from user where id=1;(张三) 5 update user set name=’王二' where id=1;(默认隐式提交事务) 6 select * from user where id=1;(张三)   串行化(Serializable) 所有的数据库的读或者写操作都为串行执行,当前隔离级别下只支持单个请求同时执行,所有的操作都需要队列执行。所以种隔离级别下所有的数据是最稳定的,但是性能也是最差的。数据库的锁实现就是这种隔离级别的更小粒度版本。 发生时间 SessionA SessionB 1 begin; 2 begin; 3 update user set name=’李四' where id=1; 4 select * from user where id=1;(等待、wait) 5 commit; 6 select * from user where id=1;(李四)   事务和MVCC原理   不同事务同时操作同一条数据产生的问题 示例: 发生时间 SessionA SessionB 1 begin; 2 begin; 3 查询余额 = 1000元 4 查询余额 = 1000元 5 存入金额 100元,修改余额为 1100元 6 取出现金100元,此时修改余额为900元 8 提交事务(余额=1100) 9 提交事务(余额=900) 发生时间 SessionA SessionB 1 begin; 2 begin; 3 查询余额 = 1000元 4 查询余额 = 1000元 5 存入金额 100元,修改余额为 1100元 6 取出现金100元,此时修改余额为900元 8 提交事务(余额=1100) 9 撤销事务(余额恢复为1000元) 上面的两种情况就是对于一条数据,多个事务同时操作可能会产生的问题,会出现某个事务的操作被覆盖而导致数据丢失。   LBCC 解决数据丢失 LBCC,基于锁的并发控制,Lock Based Concurrency Control。 使用锁的机制,在当前事务需要对数据修改时,将当前事务加上锁,同一个时间只允许一条事务修改当前数据,其他事务必须等待锁释放之后才可以操作。   MVCC 解决数据丢失 MVCC,多版本的并发控制,Multi-Version Concurrency Control。 使用版本来控制并发情况下的数据问题,在B事务开始修改账户且事务未提交时,当A事务需要读取账户余额时,此时会读取到B事务修改操作之前的账户余额的副本数据,但是如果A事务需要修改账户余额数据就必须要等待B事务提交事务。 MVCC使得数据库读不会对数据加锁,普通的SELECT请求不会加锁,提高了数据库的并发处理能力。借助MVCC,数据库可以实现READ COMMITTED,REPEATABLE READ等隔离级别,用户可以查看当前数据的前一个或者前几个历史版本,保证了ACID中的I特性(隔离性)。   InnoDB的MVCC实现逻辑   InnoDB存储引擎保存的MVCC的数据 InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。一个保存了行的事务ID(DB_TRX_ID),一个保存了行的回滚指针(DB_ROLL_PT)。每开始一个新的事务,都会自动递增产 生一个新的事务id。事务开始时刻的会把事务id放到当前事务影响的行事务id中,当查询时需要用当前事务id和每行记录的事务id进行比较。 下面看一下在REPEATABLE READ隔离级别下,MVCC具体是如何操作的。 SELECT InnoDB 会根据以下两个条件检查每行记录: InnoDB只查找版本早于当前事务版本的数据行(也就是,行的事务编号小于或等于当前事务的事务编号),这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的。 删除的行要事务ID判断,读取到事务开始之前状态的版本,只有符合上述两个条件的记录,才能返回作为查询结果。 INSERT InnoDB为新插入的每一行保存当前事务编号作为行版本号。 DELETE InnoDB为删除的每一行保存当前事务编号作为行删除标识。 UPDATE InnoDB为插入一行新记录,保存当前事务编号作为行版本号,同时保存当前事务编号到原来的行作为行删除标识。 保存这两个额外事务编号,使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单,性能很好,并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间,需要做更多的行检查工作,以及一些额外的维护工作。 MVCC只在REPEATABLE READ和READ COMMITIED两个隔离级别下工作。其他两个隔离级别都和 MVCC不兼容 ,因为READ UNCOMMITIED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。 MVCC 在mysql 中的实现依赖的是 undo log 与 read view 。   undo log 根据行为的不同,undo log分为两种:insert undo log 和 update undo log insert undo log: insert 操作中产生的undo log,因为insert操作记录只对当前事务本身课件,对于其他事务此记录不可见,所以 insert undo log 可以在事务提交后直接删除而不需要进行purge操作。 purge的主要任务是将数据库中已经 mark del 的数据删除,另外也会批量回收undo pages 数据库 Insert时的数据初始状态: update undo log: update 或 delete 操作中产生的 undo log。因为会对已经存在的记录产生影响,为了提供 MVCC机制,因此update undo log 不能在事务提交时就进行删除,而是将事务提交时放到入 history list 上,等待 purge 线程进行最后的删除操作。 数据第一次被修改时: 当另一个事务第二次修改当前数据: 为了保证事务并发操作时,在写各自的undo log时不产生冲突,InnoDB采用回滚段的方式来维护undo log的并发写入和持久化。回滚段实际上是一种 Undo 文件组织方式。   ReadView 对于 RU(READ UNCOMMITTED) 隔离级别下,所有事务直接读取数据库的最新值即可,和 SERIALIZABLE 隔离级别,所有请求都会加锁,同步执行。所以这对这两种情况下是不需要使用到 Read View 的版本控制。 对于 RC(READ COMMITTED) 和 RR(REPEATABLE READ) 隔离级别的实现就是通过上面的版本控制来完成。两种隔离界别下的核心处理逻辑就是判断所有版本中哪个版本是当前事务可见的处理。针对这个问题InnoDB在设计上增加了ReadView的设计,ReadView中主要包含当前系统中还有哪些活跃的读写事务,把它们的事务id放到一个列表中,我们把这个列表命名为为m_ids。 对于查询时的版本链数据是否看见的判断逻辑: 如果被访问版本的 trx_id 属性值小于 m_ids 列表中最小的事务id,表明生成该版本的事务在生成 ReadView 前已经提交,所以该版本可以被当前事务访问。 如果被访问版本的 trx_id 属性值大于 m_ids 列表中最大的事务id,表明生成该版本的事务在生成 ReadView 后才生成,所以该版本不可以被当前事务访问。 如果被访问版本的 trx_id 属性值在 m_ids 列表中最大的事务id和最小事务id之间,那就需要判断一下 trx_id 属性值是不是在 m_ids 列表中,如果在,说明创建 ReadView 时生成该版本的事务还是活跃的,该版本不可以被访问;如果不在,说明创建 ReadView 时生成该版本的事务已经被提交,该版本可以被访问。 举个例子:   READ COMMITTED 隔离级别下的ReadView 每次读取数据前都生成一个ReadView (m_ids列表) 时间 Transaction 777 Transaction 888 Trasaction 999 T1 begin; T2 begin; begin; T3 UPDATE user SET name = 'CR7' WHERE id = 1; T4 … T5 UPDATE user SET name = 'Messi' WHERE id = 1; SELECT * FROM user where id = 1; T6 commit; T7 UPDATE user SET name = 'Neymar' WHERE id = 1; T8 SELECT * FROM user where id = 1; T9 UPDATE user  SET name = 'Dybala' WHERE id = 1; T10 commit; T11 SELECT * FROM user where id = 1; 这里分析下上面的情况下的ReadView 时间点 T5 情况下的 SELECT 语句: 当前时间点的版本链: 此时 SELECT 语句执行,当前数据的版本链如上,因为当前的事务777,和事务888 都未提交,所以此时的活跃事务的ReadView的列表情况 m_ids:[777, 888]  ,因此查询语句会根据当前版本链中小于 m_ids 中的最大的版本数据,即查询到的是 Mbappe。 时间点 T8 情况下的 SELECT 语句: 当前时间的版本链情况: 此时 SELECT 语句执行,当前数据的版本链如上,因为当前的事务777已经提交,和事务888 未提交,所以此时的活跃事务的ReadView的列表情况 m_ids:[888]  ,因此查询语句会根据当前版本链中小于 m_ids 中的最大的版本数据,即查询到的是 Messi。 时间点 T11 情况下的 SELECT 语句: 当前时间点的版本链信息: 此时 SELECT 语句执行,当前数据的版本链如上,因为当前的事务777和事务888 都已经提交,所以此时的活跃事务的ReadView的列表为空 ,因此查询语句会直接查询当前数据库最新数据,即查询到的是 Dybala。 总结:使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的 ReadView。   REPEATABLE READ 隔离级别下的ReadView […]

微服务规范

微服务规范 前后端分离 数据库避免大量联合查询 服务设计无状态化 服务拆分最多三层,两次调用: 底层:基础服务层 中间层:组合服务层 上层:对外接口层 提供微服务关系图 统一维护微服务相互调用接口 配置统一到apollo 建议设计独立适配微服务以便调用外部服务 接口实现需幂等 定时任务建议实现在统一的单独微服务中,调用其它微服务接口来实现业务。否则和其它微服务实例一起部署的任务须加锁控制,以避免多实例冲突; 持续集成单元测试、接口测试 容器化并自动构建镜像、kubernetes部署 技术选型: 网关:spring cloud gateway 注册中心: consul 调用: feign 负载均衡:ribbon 熔断限流降级:hystrix 监控:cat, hystrix+trubine 容器:docker+kubernetes 微服务实战 环境准备 玩转Docker 服务注册发现Consul起步 实战课程 微服务概览 大话微服务 Provider微服务实战 Consumer微服务实战 Spring Cloud Gateway实战 Spring Cloud Gateway之Filter实战 微服务之网关——spring cloud gateway简单实践 掌医开放平台gateway服务设计及使用手册 契约测试实战 微服务监控-CAT Sleuth+Zipkin调用链监控实战 Hystrix熔断限流降级&Turbine API监控实战 微服务横向热扩展和自定义负载均衡策略 spring cloud gateway聚合swagger K8S创建服务实践小记 Google Jib:Java容器镜像构建新工具 微服务feign调用失败排查问题思路 微服务demo 微服务demo gitlab仓库

MySQL自定义函数:身份证号15位转18位

 

【mysql】 1292. Truncated incorrect INTEGER value: "

错误分析 一般来讲,找到对应的insert字段,然后看一下是否是由于字段类型不匹配导致的。 例如,表中声明的是bigInt类型,你传值传了个字符串进入。 另外,如果你是通过insert into select的方式,将查询结果导入到新的表中,可能你单独执行select中的内容,是可以查询到相应的结果,但是当你执行insert into语句时,会产生如下错误

在MySQL的论坛上找到一个哥们儿说的内容,也就是说这个1292的错误,有可能并不是错误,而是警告提示。可以通过ignore关键字进行警告屏蔽 所以,我把自己的代码前缀,改成如下格式,即可正常执行导入操作

  ———————————————— 版权声明:本文为CSDN博主「小魏的马仔」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/xuexiiphone/article/details/103426404

MySQL处理JSON数组,数组转字符串

GROUP_CONCAT:group_concat( [distinct] 要连接的字段 [order by 排序字段 asc/desc  ] [separator '分隔符'] ) SUBSTRING_INDEX:substring_index(str,delim,count) str:要处理的字符串 delim:分隔符 count:计数 SUBSTRING:SUBSTRING(string,position) JSON_EXTRACT:取json字符串字段下的某个键的值