数据库

数据库基础架构

数据库的锁
1.乐观锁
2.悲观锁
3.行级锁(InnoDB)

  • 共享锁
  • 排它锁
    4.表级锁(MyISAM)
  • 表共享读锁
  • 表独占写锁
    5.页级锁(BDB)

基础锁的知识

  • 对于update, delete, insert 语句在执行的时候, InnDB会自动给涉及的数据集合加上排他锁
  • MyISAM 在执行查询语句select 前,会自动给涉及的所有表加上读锁, 在执行update, delete, insert 前会自动加上写锁,这个过程不需要用户干预

表锁

  • 开销小,加锁快,不会出现死锁,锁定力度大, 发生锁冲突概率高, 并发差

行锁

  • 开销大,加锁慢, 会出现死锁, 发生锁冲突概率低, 并发好
  • 共享锁:也叫读锁,多个用户读取同一个资源,但是不允许其他客户修改,允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁
  • 排他锁:也叫写锁, 写锁是排他的,会阻塞其他的写锁和读锁

InnoDB只支持行锁和表锁, 只有通过检索条件检索数据的时候采用到行级锁,其次则用表锁
MyISAM只支持表锁

乐观锁

乐观锁并未真正加锁,而是在最后提交的时候进行冲突检测
乐观锁的概念中其实已经阐述了他的具体实现细节:主要就是两个步骤:冲突检测和数据更新。其实现方式有一种比较典型的就是Compare and Swap(CAS)技术

悲观锁

select * from xxxx for update
在select 语句后边加了 for update相当于加了排它锁(写锁),加了写锁以后,其他的事务就不能对它修改了!需要等待当前事务修改完之后才可以修改.

MySQL InnoDB默认行级锁。行级锁都是基于索引的,如果一条SQL语句用不到索引是不会使用行级锁的,会使用表级锁把整张表锁住,这点需要注意。

乐观锁和悲观锁比较

在乐观锁与悲观锁的选择上面,主要看下两者的区别以及适用场景就可以了。
1、乐观锁并未真正加锁,效率高。一旦锁的粒度掌握不好,更新失败的概率就会比较高,容易发生业务失败。
2、悲观锁依赖数据库锁,效率低。更新失败的概率比较低。
随着互联网三高架构(高并发、高性能、高可用)的提出,悲观锁已经越来越少的被使用到生产环境中了,尤其是并发量比较大的业务场景。

MyISAM

1.不支持事务
2.插入和查询速度更快
3.适合仅用作数据仓库只使用查询的需求的数据库

数据库高并发架构

数据库分表

  • 1.解决存储问题:将同一张表放到不同的服务器上,进行数据层面的划分,减少单台服务器的压力
  • 1.1.出现的问题:
  • 数据库id, 例如50在每一个分表都出现了,但是我们在查询的时候无法确定
  • 使用SnowFlake
    • SnowFlake 算法,是 Twitter 开源的分布式 id 生成算法。其核心思想就是:使用一个 64 bit 的 long 型的数字作为全局唯一 id。
    • 第一个部分,是 1 个 bit:0,这个是无意义的。
    • 第二个部分是 41 个 bit:表示的是时间戳。
    • 第三个部分是 5 个 bit:表示的是机房 id,10001。
    • 第四个部分是 5 个 bit:表示的是机器 id,1 1001。
    • 第五个部分是 12 个 bit:表示的序号,就是某个机房某台机器上这一毫秒内同时生成的 id 的序号,0000 00000000。
  • 2.解决并发读取延迟问题: 读写分离,创建数据库主从结构
    • 就是写的时候写入主数据库服务器,主数据库会自动同步到从数据库中
    • 读的时候在从数据库中查询
  • 3.数据库架构设计
    • 注意设计并发是数据冲突
    • 可以巧妙使用锁或者唯一约束
    • 写入数据库的时候可以借助redis持续写入,不要直接向数据库发送请求
    • 多使用redis 作为中间的消息队列
  • 4.解决瞬间爆炸的查询如定时抢红包
    • 我们使用消息队列存储参与用户的信息,再写一个多线程程序去消耗队列

负载均衡

Nginx

  • 加权轮询
  • IP哈希
  • 最少连接数
  • 一致性哈希

你可能感兴趣的:(随手笔记)