共享锁

mysql锁机制分为表级锁和行级锁： 共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select …for update语句，加共享锁可以使用select … lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select …from…查询数据，因为普通查询没有任何锁机制。 案发现场

转载： https://www.cnblogs.com/wezheng/p/8366029.html 目前，我们已经探讨了许多关于数据库锁的问题，锁能够有效地解决并发的问题，但这也带来了一个严重的缺点，那就是死锁。 死锁在操作系统中指的是两个或两个以上的进程在执行的过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或者系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 在操作系统中，死锁的处理是一个重要的话题，也已经有较为成熟的解决方法，如银行家算法等，在这边我们就不再阐述，只讨论数据库中的死锁。 数据库中常见的死锁原因与解决方案有： 1. 事务之间对资源访问顺序的交替 出现原因： 一个用户A 访问表A（锁住了表A），然后又访问表B；另一个用户B 访问表B（锁住了表B），然后企图访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要等用户A释放表A才能继续，这就死锁就产生了。 解决方法： 这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源 2.

1.乐观锁和悲观锁 乐观锁:读多写少，读数据默认其他线程不会修改该数据，默认不上锁，但是在更新的时候在该期间判断数据有没有更新。（在写时读取版本号，若发生改变，则重新读取--比较--修改） 悲观锁：写少读多，每次读写操作的时候都会上锁。 如Synchronized是悲观锁，AQS框架下的锁（ReenTrantLock）则先尝试cas乐观锁去获取锁，获取不到则会转换为悲观锁 注：AQS框架指提供了一种实现阻塞锁和一系列依赖的FIFO等待队列同步器框架 2.自旋锁 持有锁的线程在很短的时间内释放资源，等待竞争的线程不需要进入阻塞状态，只需要等待一定的时间（自旋）等持有锁的线程释放锁即可立即获取锁，避免用户进行和内河的切换消耗 注：1.如果在设置等待的最大时间内仍然没有释放锁，则会停止自旋进入阻塞状态 2.若持有锁的线程需要长时间占有锁，则不适合用自旋锁 3.公平锁和非公平锁 公平锁：公平锁指的是锁的分配机制是公平的。加锁前检查是否有排队的等待线程，先到先得 非公平锁：按随机、就近原则分配的锁机制称为不公平锁。加锁前不考虑排队等待问题，直接尝试获取，获取不到自动到队尾等待， 注：1.非公平锁性能比公平锁高5到10倍。因为公平锁需要在多核的情况下维护一个队列 2.synchronized是非公平锁，ReentrantLock默认的lock()方法采用的是非公平锁 4.共享锁和独占锁 独占锁

在并发编程中，经常会遇到多个线程访问同一个共享变量，当同时对共享变量进行读写操作时，就会产生数据不一致的情况。 为了解决这个问题 JDK 1.5 之前，使用 synchronized 关键字，拿到 Java 对象的锁，保护锁定的代码块。JVM 保证同一时刻只有一个线程可以拿到这个 Java 对象的锁，执行对应的代码块。 JDK 1.5 开始，引入了并发工具包 java.util.concurrent.locks.Lock，让锁的功能更加丰富。 常见的锁 synchronized 关键字锁定代码库 可重入锁 java.util.concurrent.lock.ReentrantLock 可重复读写锁 java.util.concurrent.lock.ReentrantReadWriteLock Java 中不同维度的锁分类 可重入锁 指在同一个线程在外层方法获取锁的时候，进入内层方法会自动获取锁。JDK 中基本都是可重入锁，避免死锁的发生。上面提到的常见的锁都是可重入锁。 公平锁 / 非公平锁 公平锁，指多个线程按照申请锁的顺序来获取锁。如 java.util.concurrent.lock.ReentrantLock.FairSync 非公平锁，指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程先获得锁。如 synchronized、java.util

.NET Core WebApi RESTful规范 RESTful API 最佳实践 理解RESTful架构 接口版本控制 Support multiple versions of ASP.NET Core Web API ASP.NET Core API 版本控制 配置使用流程 使用方法 Startup类ConfigureServices方法中加入services.AddApiVersioning（） Startup类Configure方法中加入app.UseApiVersioning() 控制器或接口上面应用添加ApiVersion("1.0")特性。 访问形式 通过查询字符串方式实现访问，具体格式： api/values?api-version=1.0 通过重写接口路由方式实现访问，路由修改为：[Route("api/v{version:apiVersion}/[controller]")]；具体格式： api/v1/values 通过Header指定字段实现访问。 Swagger .NetCore WebApi —— Swagger版本控制 .NetCore WebApi——Swagger简单配置 跨域策略 依赖注入 ASP.NET Core依赖注入使用自带的IOC容器 ASP.NET Core使用Autofac实现IOC注入 ASP.NET

锁汇总 👉 乐观锁 分为三个阶段：数据读取、写入校验、数据写入。 假设数据一般情况下不会造成冲突，只有在数据进行提交更新时，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回错误信息，让用户决定如何去做。fail-fast机制。 https://github.com/aalansehaiyang/technology-talk/blob/master/system-architecture/%E9%94%81%E6%9C%BA%E5%88%B6.md 👉 悲观锁 正如其名，它指对数据被外界（可能是本机的其他事务，也可能是来自其它服务器的事务处理）的修改持保守态度。在整个数据处理过程中，将数据处于锁定状态。悲观锁大多数情况下 依靠数据库的锁机制实现，以保证操作最大程度的独占性 。如果加锁的时间过长，其他用户长时间无法访问，影响程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是长事务而言，这样的开销往往无法承受。 👉 分布式锁 分布式集群中，对锁接口QPS性能要求很高，单台服务器满足不了要求，可以考虑将锁服务部署在独立的分布式系统中，比如借助分布式缓存来实现。 基于 redis分布式锁 基于 zookeeper实现的分布式锁 👉 可重入锁 可重入锁，也叫做递归锁，是指在同一个线程在调外层方法获取锁的时候，再进入内层方法会自动获取锁。ReentrantLock

一篇文章带你读懂MySQL MySQL的官方文档 作为一名开发人员来说，数据库知识是必不可少的，博主曾经年少无知的时候因为不了解数据库而被京东拒之门；无论是基于文件的Sqlite,还是工程上使用很多的MySQL、PostgreSQL/SQL Server；但是都没有对数据库有一个清晰的体系认识，所以拿出一段时间来研究数据库，希望对看到这篇文章的各位能有所帮助； MySQL是一个跨平台的开源关系型数据库，目前MySQL已经被广泛的运用到中小型的网站项目中去，由于其体积小，成本低，速度快这些特点，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。随着MySQL在互联网上被广泛使用，在数据库领域的地位爆炸式的提升，大量的使用MySQL作为公司业务的数据库； MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件。 MySQL是一种 关系数据库管理系统 ，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。 MySQL所使用的 SQL

如果有人问你“数据库事务有哪些特性”？你可能会很快回答出原子性、一致性、隔离性、持久性即ACID特性。那么你知道InnoDB如何保证这些事务特性的吗？如果知道的话这篇文章就可以直接跳过不看啦(#^.^#) 先说结论： redo log重做日志用来保证事务的持久性 undo log回滚日志保证事务的原子性 undo log+redo log保证事务的一致性 锁（共享、排他）用来保证事务的隔离性 重做日志 redo log 重做日志 redo log 分为两部分：一部分是内存中的重做日志缓冲（redo log buffer），是易丢失的；二部分是重做日志文件（redo log file），是持久的。InnoDB通过Force Log at Commit机制来实现持久性，当commit时，必须先将事务的所有日志写到重做日志文件进行持久化，待commit操作完成才算完成。 InnoDB在下面情况下会将重做日志缓冲的内容写入重做日志文件： master thread 每一秒将重做日志缓冲刷新到重做日志文件; 每个事务提交时 当重做日志缓冲池剩余空间小于1/2时 为了确保每次日志都写入重做日志文件，在每次将日志缓冲写入重做日志文件后，InnoDB存储引擎都需要调用一次fsync（刷盘）操作。但这也不是绝对的。用户可以通过修改innodb_flush_log_at_trx

在并发编程中，经常会遇到多个线程访问同一个共享变量，当同时对共享变量进行读写操作时，就会产生数据不一致的情况。 为了解决这个问题 JDK 1.5 之前，使用 synchronized 关键字，拿到 Java 对象的锁，保护锁定的代码块。JVM 保证同一时刻只有一个线程可以拿到这个 Java 对象的锁，执行对应的代码块。 JDK 1.5 开始，引入了并发工具包 java.util.concurrent.locks.Lock，让锁的功能更加丰富。 常见的锁 synchronized 关键字锁定代码库 可重入锁 java.util.concurrent.lock.ReentrantLock 可重复读写锁 java.util.concurrent.lock.ReentrantReadWriteLock Java 中不同维度的锁分类 可重入锁 指在同一个线程在外层方法获取锁的时候，进入内层方法会自动获取锁。JDK 中基本都是可重入锁，避免死锁的发生。上面提到的常见的锁都是可重入锁。 公平锁 / 非公平锁 公平锁，指多个线程按照申请锁的顺序来获取锁。如 java.util.concurrent.lock.ReentrantLock.FairSync 非公平锁，指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程先获得锁。如 synchronized、java.util

锁的基本类型 　　数据库上的操作可以归纳为两种：读和写。 　　多个事务同时读取一个对象的时候，是不会有冲突的。同时读和写，或者同时写才会产生冲突。因此为了提高数据库的并发性能，通常会定义两种锁：共享锁和排它锁。 使用的是innodb数据库, 两种锁 1.共享锁 (s锁)：表示对数据进行读操作。因此多个事务可以同时为一个对象加共享锁。（如果试衣间的门还没被锁上，顾客都能够同时进去参观） 产生共享锁的sql： begin； sql：select * from ad_plan lock in share mode; commit sequelize: try { 　　 const transaction = await this.ctx.model.transaction({ autocommit: true, isolationLevel: 'SERIALIZABLE' }); const platformResult = await this.ctx.model.PlatformInfo.findOne( { where: { platform_id, }, transaction, lock: transaction.LOCK.SHARE, } ); await transaction.commit(); } catch(error) { await transaction