隔离级别
https://baijiahao.baidu.com/s?id=1611918898724887602&wfr=spider&for=pc
数据库的锁
共享锁:事务进行操作时 其他事物只可以读不可以修改
排它锁:其他事务既不可以修改也不可以读
mysql有行级锁、页级锁、表级锁
https://blog.csdn.net/Michaeles/article/details/86484385
悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。
乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。 乐观锁不能解决脏读的问题。
乐观锁与悲观锁
悲观锁(Pessimistic Lock),就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
两种锁各有优缺点
不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。
乐观锁应用
使用自增长的整数表示数据版本号。更新时检查版本号是否一致,比如数据库中数据版本为6,更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较,如果相等,则可以更新,如果不等则有可能其他程序已更新该记录,所以返回错误。
使用时间戳来实现.
注:对于以上两种方式,Hibernate自带实现方式:在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段。
悲观锁应用
需要使用数据库的锁机制,比如SQL SERVER 的TABLOCKX(排它表锁) 此选项被选中时,SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。
在实际生产环境里边,如果并发量不大且不允许脏读,可以使用悲观锁解决并发问题;但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.
悲观锁会造成访问数据库时间较长,并发性不好,特别是长事务。
乐观锁在现实中使用得较多,厂商较多采用。
binlog
binlog是一个二进制格式的文件,用于记录用户对数据库更新的SQL语句信息,例如更改数据库表和更改内容的SQL语句都会记录到binlog里,但是对库表等内容的查询不会记录。
当有数据写入到数据库时,还会同时把更新的SQL语句写入到对应的binlog文件里,这个文件就是上文说的binlog文件。使用mysqldump备份时,只是对一段时间的数据进行全备,但是如果备份后突然发现数据库服务器故障,这个时候就要用到binlog的日志了。
主要作用是用于数据库的主从复制及数据的增量恢复。
聚簇索引和非聚簇索引
聚簇索引:主键上的索引,储存物理地址
非聚簇索引:其他键上的索引,需要引用聚簇索引
如果聚簇索引过大,非聚簇索引也会过大
什么是强一致性
强一致性
简言之,在任意时刻,所有节点中的数据是一样的。
例如,对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。
顺序一致性
系统的所有进程的顺序一致,而且是合理的。即不需要和全局时钟下的顺序一致,错的话一起错,对的话一起对。
弱一致性
如果能容忍后续的访问只能访问到部分或者全部访问不到,则是弱一致性。
分布式事务的解决方案
CAP定理
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的,他指出WEB服务无法同时满足一下3个属性:
一致性(Consistency) : 客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) : 每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) : 即使出现单个组件无法可用,操作依然可以完成
具体地讲在分布式系统中,在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性。显然,任何横向扩展策略都要依赖于数据分区。因此,设计人员必须在一致性与可用性之间做出选择。
解决方案:
两阶段提交(2PC)
补偿事务(TCC)
本地消息表(异步确保)
MQ 事务消息
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
数据库范式
https://www.cnblogs.com/lca1826/p/6601395.html
数据库索引类型
https://blog.csdn.net/zsl1766189860/article/details/80191977
事务如何可靠
https://www.cnblogs.com/a-phper/p/10313948.html